Better To Wait For The Omap 3630?


Status
Not open for further replies.

benjiro

Member
Joined
Aug 20, 2008
Messages
233
Location
Belgium ( Flanders )
Website
Visit site
This is a spinoff from this topic:
http://www.gp32x.de/board/index.php?showt...mp;#entry701617

'argor' said:
PowerVR's SGX530 power consumption of only ~100mW
http://www.beyond3d.com/content/news/711
Quote from the forum linking to the that article got my attention:

"expect the OMAP36xx and 37xx families @45nm shortly"

These are the new 45nm versions:
# OMAP3640 - 800 MHz ARM Cortex A8 + 430 MHz C64x+ DSP + PowerVR SGX530 GPU + ISP (Image Signal Processor)
# OMAP3630 - 600 MHz ARM Cortex A8 + 430 MHz C64x+ DSP + PowerVR SGX530 GPU + ISP (Image Signal Processor)
# OMAP3620 - 600 MHz ARM Cortex A8 + 430 MHz C64x+ DSP + PowerVR SGX530 GPU + ISP (Image Signal Processor)
# OMAP3610 - 600 MHz ARM Cortex A8 + 430 MHz C64x+ DSP

In other words, with the possible April / May delivery date, is there a benefit on just holding off for the OMAP3630 / 3640 cores for mass production off the boards? Its not like another month is going to make a major difference? And the case production en FCC / CE testing can be done with the OMAP 3530 ( 65nm ) core ( those tests are for wifi/bt radiation anyway ;) ).

Giving the fact that the 45nm looks to be close by, we might end up with first batches with a 65nm OMAP, and maybe second or future badgers with a 45nm OMAP. As the 45nm version will be longer in production, there will be a switch to a 45nm OMAP during the Pandora's lifetime.

And i for one, rather hold out for a 45nm version, given the extra amount off possible power saving ( => longer runtime ), and possible higher clock speeds ( this of course is not a sertenty, but in general a die shrink allows for higher clock speeds ).

For instance, the OMAP3640 has a default clock speed off 800Mhz, and a unknown OC speed. One can argue, sure, the OMAP3530 already has a possible 800+Mhz Overclock speed. But as MWeston has been drumming in our ears for a while, that speed is not official as the OMAP3530 is in reality designed for 600Mhz ( and not 1Ghz line most off use assumed ). So, we can not assume that people can use 800Mhz on the OMAP 3530 ( just like with any OC job ).

Any official word from TI on those Craigex?

So people, what do you think about it? Risk waiting a month longer, and get one with more power saving?

This is my opinion, but if the price is the same, and the delay is acceptable, i rather see a 45nm core in the Pandora, giving that the Pandora is a mobile ( battery powered ) device, and thus will in the long run, have a greater benefice?
 
Last edited by a moderator:
Better wait till the year 3000???? Much better technology by then..

I guess this isnt possible and isnt needed at all. We already have a powerful killer machine with a long battery lenght. We don't want anymore delay and I guess craigix and co already paid for the parts...
 
Last edited by a moderator:
'Benjiro' said:
Its not like another month is going to make a major difference
Voice of the board, there :lol:
 
Last edited by a moderator:
Waiting for this release would add another 6 Months min. to the development. Just because Ti says there ready to come out doesn't mean that kernel and driver support will be there. Granted it looks pretty close to the Omap 3530, I still think it will take alot more time for little benefit.

Do you know how long Ti has had the OMAP 3530 out, but there still isn't very many commercial products using it, there is a reason for this it takes time for everyone to catch up when new hardware comes out.

We don't even know what kind of preformance we can get and you already want more.
 
Last edited by a moderator:
Benjiro said:
For instance, the OMAP3640 has a default clock speed off 800Mhz, and a unknown OC speed. One can argue, sure, the OMAP3530 already has a possible 800+Mhz Overclock speed. But as MWeston has been drumming in our ears for a while, that speed is not official as the OMAP3530 is in reality designed for 600Mhz ( and not 1Ghz line most off use assumed ). So, we can not assume that people can use 800Mhz on the OMAP 3530 ( just like with any OC job ).
AFAICR the OMAP3530 processors used on Pandora are guaranteed to work from 600Mhz to 900Mhz, and that doesn't mean we'll be overclocking them.

EDIT: Oh, I forgot. For me the design is superb as it is right now. Let's not be too greedy or needy, please. It's better to want what you already have or otherwise you'll never be happy.
 
Last edited by a moderator:
The devs will not wait. The Pandora design is final and they are preparing for mass production already.
 
'Kevin_H' said:
Just because Ti says there ready to come out doesn't mean that kernel and driver support will be there. Granted it looks pretty close to the Omap 3530, I still think it will take alot more time for little benefit.
From what i read, the OMAP 3530 = OMAP 3530/3540 with the only difference that its a die shrink ( and faster speed on the 3540 ). So, there is not reason for kernel or driver support to change.

Mithrildor: Thats why i also asked for Craigex's opinion. We don't have the contacts at TI to know whats the deal is with the OMAP 36xx serie. Asking never hurts. :)

'joseluisjazz' said:
AFAICR the OMAP3530 processors used on Pandora are guaranteed to work from 600Mhz to 900Mhz, and that doesn't mean we'll be overclocking them.
No, its not. Thats why MWestion has been correcting us a few times already. Its guaranteed to work at 600Mhz, and thats it. Problem is, if the manufacturing process changes, or they decide to start using lower grade OMAP's ( one's that can work on 600Mhz, but not on 800Mhz ), and some programs or people relies on that OC job, then you have a problem. ;)
 
Last edited by a moderator:
'Benjiro' said:
So, we can not assume that people can use 800Mhz on the OMAP 3530 ( just like with any OC job ).

Yes we can. It's guaranteed up to 900, but that uses more power and shortens CPU life, hence why it's default clock is 500 or 600.
We are not underclocking it either, if that's what you're thinking. It throttles itself everywhere from some minimum that I've never bothered to look up, up to a guaranteed 900 MHz.
Imagine the OMAP is your car. It's capable of achieving speeds of 160 KM/h, but at that speed it guzzles gas like there's no tomorrow. Driving around town at 50 KM/h is not underdriving your car, it's just driving slower, and using a lot less gas to do it.
 
Last edited by a moderator:
The 36xx appears to be exactly the same as the 34xx and 35xx except for being 45nm - no new features means that it is hard to justify waiting for it - battery life should already be good enough anyway.

You should know that the 35xx is intended for open projects like pandora and beagleboard, and so all the documentation is available. This is not the case for the 34xx and probably wont be for the 36xx and 37xx either.

Additionally the package and pin out may not be identical, meaning that the pandora team (MWeston) would have to spend time redesigning the PCB schematics.

If this wasn't enough, as others have pointed out, there is no way those will be available in an extra month. I don't understand where 'expect shortly' got translated into a solid release date. In reality it could be 6 months, a year, or more.

Maybe if backwards compatibility for existing designs remains good this could be an option further down the line for later models, but I think waiting could actually kill the project at this point.
 
Last edited by a moderator:
Probably ES samples that will be available. Consider the current SOC was available ~2 years ago as ES - it's taken that long for devices to come to market.
 
Last edited by a moderator:
Ya know, according to Moore's Law, we could hold off for a couple of years and get 512 MB of RAM and a 1GB NAND and 4 SD slots instead.
 
Last edited by a moderator:
'craigix' said:
Probably ES samples that will be available. Consider the current SOC was available ~2 years ago as ES - it's taken that long for devices to come to market.
That is exactly what I was trying to say.

I was just frustrated and it came out all wrong. Engineering is like shooting at a moving target, at sometime you just have to take the shot. If you wait for something bigger and better you will always be waiting.
 
Last edited by a moderator:
QUOTE
I was just frustrated and it came out all wrong. Engineering is like shooting at a moving target, at sometime you just have to take the shot. If you wait for something bigger and better you will always be waiting.


Thinking about Duke Nukem Forever :unsure:
 
Last edited by a moderator:
'WizardStan' said:
'Benjiro' said:
So, we can not assume that people can use 800Mhz on the OMAP 3530 ( just like with any OC job ).

Yes we can. It's guaranteed up to 900, but that uses more power and shortens CPU life, hence why it's default clock is 500 or 600.
We are not underclocking it either, if that's what you're thinking. It throttles itself everywhere from some minimum that I've never bothered to look up, up to a guaranteed 900 MHz.
Can you provide evidence that it's guaranteed to run at 900 MHz? I mean some document from TI says so?
 
Last edited by a moderator:
'Laurent' said:
Can you provide evidence that it's guaranteed to run at 900 MHz? I mean some document from TI says so?
I know, that you ment this as a rhetoric question, but for others:
'MWeston' said:
QUOTE
Firstly, the CPU is a 900 MHz Cortex A8 which has actually been underclocked to 600 MHz.

WRONG!

It's a 600MHz CPU that seems to do well at up to 900MHz under the circumstances it has found itself in the hands of Pandora devs. I wish this particular inaccurate fact could be remedied once and for all. For all we know TI could change the silicon three months from now and suddenly all chips fail at 650MHz. I don't see that happening but it is worth noting.
 
Last edited by a moderator:
Thanks Mali :)
My question was not purely rhetoric, I'm just surprised that people make claims that they can't prove and do it in such a way that other uninformed people might trust them.
 
Last edited by a moderator:
'Laurent' said:
'WizardStan' said:
'Benjiro' said:
So, we can not assume that people can use 800Mhz on the OMAP 3530 ( just like with any OC job ).

Yes we can. It's guaranteed up to 900, but that uses more power and shortens CPU life, hence why it's default clock is 500 or 600.
We are not underclocking it either, if that's what you're thinking. It throttles itself everywhere from some minimum that I've never bothered to look up, up to a guaranteed 900 MHz.
Can you provide evidence that it's guaranteed to run at 900 MHz? I mean some document from TI says so?

Now that you've mentioned it, I don't actually know where the 900 Mhz figure actually came from. The CortexA8 is rated from 600 to "greater than 1GHz" from the ARM white pages. On the other hand, the OMAP3530 data sheet only lists MPU clock speeds of 125, 500, 550, and 600 as being possible. On the other other hand, Notaz, MWeston, and Squidge have all posted that they had great success running at 900 MHz (but not beyond). On the other other other hand, the BeagleBoard, using the same SOC, can only reach 600 Mhz, according to it's spec sheet, and I've not seen anyone suggest otherwise.
So now I'm rightly confused. I've got one too many hands.
 
Last edited by a moderator:
mali said:
'MWeston' said:
QUOTE
Firstly, the CPU is a 900 MHz Cortex A8 which has actually been underclocked to 600 MHz.

WRONG!

It's a 600MHz CPU that seems to do well at up to 900MHz under the circumstances it has found itself in the hands of Pandora devs. I wish this particular inaccurate fact could be remedied once and for all. For all we know TI could change the silicon three months from now and suddenly all chips fail at 650MHz. I don't see that happening but it is worth noting.



Keep repeating this to yourselves gang. Pandora's going to allow people to do overclocking, yes. You're damned nuts if you're writing code that ends up needing it. :D

Keep solidly in mind of what we're seeing in the way of performance on the Pandora with the GP2X straight migrations- I'm curious just precisely what an overclock would allow to happen that's only half again faster that a code clean up would be unlikely to accomplish the same result...
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top