hm... after considering this all further I'm going to have to vote for the 16cog/128K prop.· With a good cog-cog communication method (left/right registers, or a virtual I/O port and the TV hardware upgraded to support syncronus serial data transfer)· I think main memory will be less of an issue because of how much processing a chain of cogs could do on the fly.· (JPEG compressed screen buffer? who knows [noparse]:D[/noparse] )· Also any syncronus serial hardware would make·external memory that much faster.·
Too bad about the 3.6v max voltage on the process.· I wonder if 5v operation could be acheved with carefull circuit design such that no transistor ever had to switch more than 2.5v by itself?
my 2 cents,
Marty
P.S. instead of dual ported memory how about cogs get a clk/32 defalt hub access with an interleved·clk/2 DMA channel alocated on a round-robin basis for block memory transfers?
I'd avoid sub 3.3 voltages - there aren't too many components available in reach of the majority of "joe-average" customers. It's a give and take. You'll lose power internally on the micro's die by having a higher voltage - but if you had a lower core-I/O voltage, you'd lose more externally in the conversion to another voltage (i.e. 1.8v to 5v).
Just a comment on 1.8V core supply voltages. There really isn't much of an option anymore. The power dissipation goes up rapidly with supply voltage. At these feature sizes and device densities, you really have to run as much of the device as possible at 1.8V. The higher voltage supply (3.3V) is just for the I/O pin drivers. You can't go higher because the process that allows the tiny channel widths and high performance at low core voltages won't support higher voltage I/O pin drivers and you can't mix processes on the same chip (as I understand it). Pretty much everything that has any significant amount of logic on a chip is going to this model and there will be more and more support for lower and lower logic voltages as time goes on.
Mike Green said...
Just a comment on 1.8V core supply voltages. There really isn't much of an option anymore. The power dissipation goes up rapidly with supply voltage. At these feature sizes and device densities, you really have to run as much of the device as possible at 1.8V. The higher voltage supply (3.3V) is just for the I/O pin drivers. You can't go higher because the process that allows the tiny channel widths and high performance at low core voltages won't support higher voltage I/O pin drivers and you can't mix processes on the same chip (as I understand it). Pretty much everything that has any significant amount of logic on a chip is going to this model and there will be more and more support for lower and lower logic voltages as time goes on.
Yep. The way this works is there are two selectable gate oxides - a thin one for 1.8v/0.18um gate length transistors (core), and a thick one (almost·twice as thick, actually) for 3.3V/0.34um gate length transistors (I/O). Different mask layers define each gate oxide. If they had a gate·oxide option that was 50% thicker than the 3.3V one, we could draw transistors with 0.5um gate lengths and run them at 5V. But, 3.3V is the limit for this particular process.
Regarding 1.8V: For me, the average Joe, I had a mildly rough time adapting from a 5V Way-of-Working to the 3.3V. I think it was relatively easy for obvious reasons (CMOS still works, LED's still light, etc...) Now you suggest 1.8V?!? Honestly, I wouldn't know where to begin with all the peripherials.
Understanding that 1.8V seems to be the way to go for speed and die size, how does that affect me, the average dude? Is it practical for your market?
-Parsko
TANGENT ABOUT THIS THREAD:
This thread has been funny, having followed the whole thing. Chip, you're cracking me up! "What would you guys think...?" "What about this...?" This forum must really work for you guys!
Having followed the progress of this chip from early on, I can kinda see where you want to go with this (@Chip). You seem quite focused on the video and (especially) the real-life voice generation stuff. I admire your ambitions. I get the feeling like you are trying to squeeze out what YOU want (faster Hub access and the pipelining), while satisfying the masses with what they want.
It occured to me a little while ago... The elegance of the Prop. You guys can reuse the mask for each cog, right?? That is why 16 cogs are feasible? I'm extremely interested to hear how you guys go about designing the Silicone, maybe in another thread...
Have to admit I was fighting to stop myself posting about that earlier.
On the 1.8v question, I guess I'm the only person who wouldn't have a problem with it, but then I'm not really interfacing to anything else, so I wouldn't have.
As we're now looking ahead to cogs which will generally be executing one instruction per clock cycle, how about we have a new assembly instruction to wait until the cog has hub access?
With instructions currently taking at least 4 cycles, such an instruction would be of little use, however if it were implemented in v2, instead of just knowing that you'd have to wait an unspecified number of cycles between X and X to ensure that a hub operation has completed, you'd be able to find out for certain that the operation was complete. It would also mean you wouldn't need to put in filler instructions if you really didn't have anything to do until the operation has completed. However, much more important than either of these (from my point of view anyway) is that for timing critical routines, you could call a "wait for cog sync" type instruction early on, and from that point you could cycle count and possibly re-organise your code to ensure the most efficient times to access to the hub.
1.8v outputs would make life harder for a lot of applications, honestly... most of the parts available in the wild are 5 or 3.3. At least with 3.3 if I really need a buffer, I can use a normal 74-series cmos buffer or a 74hc14 if i can't find anything else.... part of the reason why I like Parallax stuff is that it's easy to hack something together for a proof of concept.
We're not talking about 1.8V outputs. The reason for the two supplies (and the notion of "core") is that the internals ("core") of the chip run at 1.8V and the I/O pins run at 3.3V. The chip looks like a 3.3V chip to the outside world, but all of the I/O pins are translated to/from 1.8V. The buffers are included on-chip. Again ... The chip looks like 3.3V logic, but the "inaccessible" insides run at 1.8V. There has to be an external 1.8V supply because an internal regulator would take too much die space and dissipate too much heat.
As we're now looking ahead to cogs which will generally be executing one instruction per clock cycle, how about we have a new assembly instruction to wait until the cog has hub access?
This happens automatically whenever you do a hub instruction. It waits until it can talk to the hub, then it talks to the hub and releases, and goes on to the next instruction. There's no need to stuff filler instructions in-between hub instruction, but it does give you the highest processor utilization.
I vote for the 3.3 volt i/o. That way, boards we design using the present Prop will upgrade easily to the new technology. I think making it 1.8 only would slow its acceptance tremendously. Can we assume that the packaging will be the same as it is now?
No, because PortB will be implemented for a total of 64 I/O. It hasn't been determined if 32 I/O versions will be produced, but it would be possible to do so since the die size will remain the same.
We will begin to need separate 1.8v and 3.3v supply pins, so it would be possible to keep all the ground pins where they are, and make the four (QFN/LQFP) VDD pins into two sets of VDD18 and VDD33 pins. On the DIP version, we'd only get one of each, which isn't very good. On the current (and future) chips, all VDD and VSS pins are double-bonded with two wires for lowest resistance, which in the case of the QFN and LQFP results in 8 wires each of VSS and VDD.
Tracy Allen said...
I vote for the 3.3 volt i/o. That way, boards we design using the present Prop will upgrade easily to the new technology. I think making it 1.8 only would slow its acceptance tremendously. Can we assume that the packaging will be the same as it is now?
Actually, it would be very nice if *writes* to hub memory would not block (until another write or a read to hub memory).
This won't affect correctness/interleaving, but will (could?) give a nice speed boost; if a hub write always took four cycles
(like any other instruction) *unless* the current cog-to-hub write buffer was already full.
First of course is that hub writes now only take four cycles, instead of seven. Next is, you can do 4 instructions for every
hub turnaround rather than 3.
Tracy Allen said...
I vote for the 3.3 volt i/o. That way, boards we design using the present Prop will upgrade easily to the new technology. I think making it 1.8 only would slow its acceptance tremendously. Can we assume that the packaging will be the same as it is now?
Chip, quite a few messages back in this thread you asked about a 1.8v only chip. I assumed the I/Os would be 1.8v. If this wasn't implied, quite a bit of forum bandwidth was 'wasted' on this assumption.
Can the 1.8v for core be on-chip regulated from 3.3v?___ If NOT, then this version of the Prop wouldn't be 'pin compatible with the present Prop, because of the 1.8v power pin.
Don't know what it would take to i/f with 5v logic parts with a 1.8v I/O. I've about 3 dozen 5v to 3.3v current limiting resistors to handle the i/f from 5v to the Prop 3.3v. I have to live with that 'burden'; should be SMD R's but will be through hole R's.
Getting the 160 MHz single-clock instructions and more RAM will be a super bonus. Eagerly awaiting such a 'beast'.
To clarify, the core will be run a 1.8V. To not do so wouldn't be feasible since the transistor channel length must be larger for each transistor. The question was whether the I/O interface to the external world should be 1.8V or 3.3V.
I also had the idea on incorporating onboard regulator, but this is not a viable option. Standard regulation is a no-go because the heat generated will cause the entire chip to heat and cause it to slow down (higher juction temperature = decreased maximum clock rate). Switch regulation would cause all sorts of noise internally in the chip and would be a nightmare to design a robust and glitch-free chip.
Post Edited By Moderator (Chip Gracey (Parallax)) : 11/30/2006 7:41:12 PM GMT
rokicki said...
Actually, it would be very nice if *writes* to hub memory would not block (until another write or a read to hub memory).
This won't affect correctness/interleaving, but will (could?) give a nice speed boost; if a hub write always took four cycles
(like any other instruction) *unless* the current cog-to-hub write buffer was already full.
First of course is that hub writes now only take four cycles, instead of seven. Next is, you can do 4 instructions for every
hub turnaround rather than 3.
Anyway, just a thought.
We could add buffer flops for hub ram writes, but they wouldn't help for reads. I don't think this would be an overall win, though. BTW, hub instructions will take TWO clocks, leaving room for SIX single-clock instructions in-between (assuming an 8 cog architecture).
Yeah, I've changed my mind, it's probably not a win anyway, as you introduce
a subtle complexity (execute a write, set a pin saying it's updated, another cog
reads a stale value) that's not worth any minimal speed improvement anyway.
Paul Baker said...
No, because PortB will be implemented for a total of 64 I/O. It hasn't been determined if 32 I/O versions will be produced, but it would be possible to do so since the die size will remain the same.
WOW!
I missed this one. Finally the 64 I/O Port A and Port B part is being worked on. My count for the pins is as follows:
32 Port A
32 Port B
4 3.3v
4 1.8v
4 ground
2 crystal
1 /RST
1 /BOE
---
78 pins, which fit into a 80-pin QFP package.
Probably should use the remaining pins for ground or the 1.8v power.
I couldn't recall the 84 pin PLCC package, though used a CPLD in that form. With a thru-hole socket, it was fairly easy to connect to this on a 2-layer pcb.
Yeah, I'd like that package, Parallax.
You are welcome Harley... PLCC is probably (IMHO) the easiest surface mount style to prototype with due to readily available thruhole .1" sockets [noparse]:)[/noparse]
Chip, will there be any possibility of you implementing an external memory bus? I have an application in design which would LOVE the power of the new propeller, but needs lots of memory. Im thinking it would be best somehow multiplexed onto the new Port B, so you can either have 64 IO pins or 32 IO pins and external memory.
Comments
No the process doesn't support 5V, only upto 3.6V with it optimized for 1.8V. The oxide is too thin to permit a robust 5V I/O design.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Too bad about the 3.6v max voltage on the process.· I wonder if 5v operation could be acheved with carefull circuit design such that no transistor ever had to switch more than 2.5v by itself?
my 2 cents,
Marty
P.S. instead of dual ported memory how about cogs get a clk/32 defalt hub access with an interleved·clk/2 DMA channel alocated on a round-robin basis for block memory transfers?
I'd avoid sub 3.3 voltages - there aren't too many components available in reach of the majority of "joe-average" customers. It's a give and take. You'll lose power internally on the micro's die by having a higher voltage - but if you had a lower core-I/O voltage, you'd lose more externally in the conversion to another voltage (i.e. 1.8v to 5v).
-Tim
I would look at it as a hybrid IC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Understanding that 1.8V seems to be the way to go for speed and die size, how does that affect me, the average dude? Is it practical for your market?
-Parsko
TANGENT ABOUT THIS THREAD:
This thread has been funny, having followed the whole thing. Chip, you're cracking me up! "What would you guys think...?" "What about this...?" This forum must really work for you guys!
Having followed the progress of this chip from early on, I can kinda see where you want to go with this (@Chip). You seem quite focused on the video and (especially) the real-life voice generation stuff. I admire your ambitions. I get the feeling like you are trying to squeeze out what YOU want (faster Hub access and the pipelining), while satisfying the masses with what they want.
It occured to me a little while ago... The elegance of the Prop. You guys can reuse the mask for each cog, right?? That is why 16 cogs are feasible? I'm extremely interested to hear how you guys go about designing the Silicone, maybe in another thread...
SILICONE...they're getting into that business, too?! ;^) (not only do they look good, but if you tune them right, you can pull in Topeka...)
Sorry, couldn't help it...now getting caffeine...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...
On the 1.8v question, I guess I'm the only person who wouldn't have a problem with it, but then I'm not really interfacing to anything else, so I wouldn't have.
As we're now looking ahead to cogs which will generally be executing one instruction per clock cycle, how about we have a new assembly instruction to wait until the cog has hub access?
With instructions currently taking at least 4 cycles, such an instruction would be of little use, however if it were implemented in v2, instead of just knowing that you'd have to wait an unspecified number of cycles between X and X to ensure that a hub operation has completed, you'd be able to find out for certain that the operation was complete. It would also mean you wouldn't need to put in filler instructions if you really didn't have anything to do until the operation has completed. However, much more important than either of these (from my point of view anyway) is that for timing critical routines, you could call a "wait for cog sync" type instruction early on, and from that point you could cycle count and possibly re-organise your code to ensure the most efficient times to access to the hub.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Chip had asked a later question about interest in a pure 1.8v chip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
This won't affect correctness/interleaving, but will (could?) give a nice speed boost; if a hub write always took four cycles
(like any other instruction) *unless* the current cog-to-hub write buffer was already full.
First of course is that hub writes now only take four cycles, instead of seven. Next is, you can do 4 instructions for every
hub turnaround rather than 3.
Anyway, just a thought.
Can the 1.8v for core be on-chip regulated from 3.3v?___ If NOT, then this version of the Prop wouldn't be 'pin compatible with the present Prop, because of the 1.8v power pin.
Don't know what it would take to i/f with 5v logic parts with a 1.8v I/O. I've about 3 dozen 5v to 3.3v current limiting resistors to handle the i/f from 5v to the Prop 3.3v. I have to live with that 'burden'; should be SMD R's but will be through hole R's.
Getting the 160 MHz single-clock instructions and more RAM will be a super bonus. Eagerly awaiting such a 'beast'.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
I also had the idea on incorporating onboard regulator, but this is not a viable option. Standard regulation is a no-go because the heat generated will cause the entire chip to heat and cause it to slow down (higher juction temperature = decreased maximum clock rate). Switch regulation would cause all sorts of noise internally in the chip and would be a nightmare to design a robust and glitch-free chip.
Post Edited By Moderator (Chip Gracey (Parallax)) : 11/30/2006 7:41:12 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
a subtle complexity (execute a write, set a pin saying it's updated, another cog
reads a stale value) that's not worth any minimal speed improvement anyway.
Never mind.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
-Phil
I missed this one. Finally the 64 I/O Port A and Port B part is being worked on. My count for the pins is as follows:
Probably should use the remaining pins for ground or the 1.8v power.
Sure could use this baby right today!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
I couldn't recall the 84 pin PLCC package, though used a CPLD in that form. With a thru-hole socket, it was fairly easy to connect to this on a 2-layer pcb.
Yeah, I'd like that package, Parallax.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn