I never liked the "P8X32A" designation. It's too much of an alphanumeric jumble and doesn't resonate like "SX", "BS2", or "PIC". But, if keeping the "P8X" is necessary, why not simply "P8X2"? It still has three letter/number transitions, though, but one less than the original.
-Phil
P8X2 fails the schoolkid test of ( P8X2 < P8X32) , so it must be an earlier/smaller part, right ?
I never liked the "P8X32A" designation. It's too much of an alphanumeric jumble and doesn't resonate like "SX", "BS2", or "PIC". But, if keeping the "P8X" is necessary, why not simply "P8X2"? It still has three letter/number transitions, though, but one less than the original.
-Phil
Well the current chip is scarcely referred to as P8X32A except when ordering but is always referred to as we know it as the Propeller chip or Prop chip etc. The P2 should likewise have a appropriate part number which I am sure we will hardly ever refer to it as such. If we keep the first 3 characters as was also suggested yet keep the F to denote the fast and furious or flexible nature of the chip we could call it the P8XF128 which also sounds a bit like an experimental fighter.
Well the current chip is scarcely referred to as P8X32A except when ordering but is always referred to as we know it as the Propeller chip or Prop chip etc. The P2 should likewise have a appropriate part number which I am sure we will hardly ever refer to it as such. If we keep the first 3 characters as was also suggested yet keep the F to denote the fast and furious or flexible nature of the chip we could call it the P8XF128 which also sounds a bit like an experimental fighter.
Some companies separate the 'Brand' from the part code, so it does not need one name for both.
eg Lattice have the Mach-XO2 series, with order part codes like this LCMXO2-256HC-4SG32C
Ugh. Yeah, I guess it could be worse. Worse still is Molex, which has both a "part number" and a totally different "catalog number" for each of its connectors!
How about PP2 (Parallax Propeller II)? It's simple, rolls of the tongue, and also happens to be my initials. (Well, actually, my initials are PCP, but that carries some unfortunate connotations.)
It appears Parallax is going to pinout the chip almost exactly the same way as the SSD1963 and it will share the same package.
What about an exposed PAD ? Seems that would be an ideal option, and I've seen packages with relatively small central PADS.
( that suggest the exposed part is smaller than the die, so I guess a simple step design ? ).
This gives better thermal/electrical performance, and a slightly shrunk PAD allows vias inside the pins.
Best of all worlds ?
Yah, the 32 is for i/o pins, so P8x96A (it being the first generation of the new design) would work for me. Make my son happy too, he loved saying p8x32a when he did his presentation for school about his fm radio he used to get himself into the gifted program.
On the other hand, there really needs to be a 2 in there somewhere, to let folks know it's the second generation of the propeller, not just the first gen of a new board. hmm...
p8x96P2?
Still shows off all capabilities, and indicates second generation of processor.
We could make a DIP, like the BS2-IC. It would just have to exceed 0.600" row spacing and move to up to 0.800". That would work nicely. We could put an SDRAM on it (something useful that eats lots of pins), a boot serial FLASH chip, a crystal, voltage regulators (3.3V and 1.8V), and perhaps a USB mini-B connector. We know that there needs to be some compact-format board, as well as a general-purpose experiment board.
Sorry folks for not responding sooner.... Yes, the 15th was a targeted milestone for having the synthesized logic within the inner core completed. There were a few snags with the tool chain doing the synthesized cell placement, and the guys assigned to work on the synthesized placement had other obligations that weren't immediately us. That said, I think we are over that now and on the right track, pushing the date to the 22nd of October. Currently I am not in critical path, but will be soon enough. The term 'when it rains it pours' will be an understatement towards the end of this month.
Currently Chip is finalizing the ROM code which will be distributed across the four HUB RAMs... The location and architecture of the ROM within the RAM dictates how the synthesized logic will communicate to it, therefore as the ROM changes and is updated, so does the synthesized logic. This needs to be finalized on Chips end before I can implement it in layout <-- The proper bit pattern for the ROM code. At the same time, when the synthesized logic is completed (expected date near the 22nd) I will place the finalized logic in the current layout and double check that there are no perimeter violations of the synthesized block. So essentially I will be receiving the ROM sequence and the synthesized logic block right at about the same time on top of one another. Scripting code should make the ROM bit placement easier, but there is always the learning curve of the first block (in this case 1/4th of the ROM) to make sure that the script addresses all of the pitch differences between odd/even rows and columns as well as odd/even ROM bits. Because the cells can be flipped and mirrored to conserve real estate, the downside is that the bit patterns in most cases don't retain the same pitch from an even bit to an odd bit. The same goes for the rows... since NMOS and PMOS transistors are sized differently, when the cells are flipped to utilize sharing power and ground structures more efficiently, the pitch from even rows to odd rows will be different. Now, even to even or odd to odd will have the SAME pitch ... anyway if this doesn't make sense I will try to take a snapshot when I am doing it to illustrate the phenomenon.
... therefore as the ROM changes and is updated, so does the synthesized logic.
So, Beau, are you saying that the content of the ROM affects the overall size and shape of the array of ROM bits, requiring repositioning and rejiggering? I've always thought of ROM as a uniformly-sized rectangular structure, independent of the data it holds.
All of this is very interesting in a "Scientific American" level sort of way. As you explain it (the ROM programming), it makes sense and provides insight into some of just how complex this whole thing is. It's amazing!
"So, Beau, are you saying that the content of the ROM affects the overall size and shape of the array of ROM bits, requiring repositioning and rejiggering? I've always thought of ROM as a uniformly-sized rectangular structure, independent of the data it holds." - Not exactly.... typically you would have a separate ROM and a separate RAM. In this case however a portion of the RAM is converted to ROM by replacing the current RAM bit cells. In addition, the ROM bits must be 'set' or 'cleared'. This setting or clearing amounts to simply setting a via at the correct location. The reason for the RAM/ROM merging is again to save real-estate. With the merged version you only need one set of CAS(Column Address Lines) and RAS (Row Address Lines), plus, you cut the amount of wire congestion into the synthesized logic down by half.
"So it's the placement of the vias that requires resynthesis of the entire logic section when they're changed?" - It's basically an iterative process in which Chip could probably explain better than myself. Most of the ROM is for boot communication/loading purposes. Other aspects that he has assigned to the ROM are equally important and require specific handling. Since the ROM has been under constant massage I don't have an exact pattern or even exact location yet, so even a general placement would be a moot point. Most of the synthesized work has been to meet critical timing paths across the chip while still maintaining a balanced mode of communication between individual COGs.
Re: ROM attributes. I suspect a simple layout would be subject to a decapping type attack or something. Flip a bit, make it jump, etc... Of course, I may be wrong, and either way, I also suspect we will be enlightened!
" I thought the ROM was implemented by just modifying one of the transistors in the 6-t cell so that the bit is stuck in the on or off state. " - Essentially yes, but because the memory bits are differentially driven and read, you have two bit lines per memory bit which makes it more complex than modifying just one of the transistors. It also can't be 'hard set' with just a direct wire connection without violating the reading (or writing) of other bit cells.
Comments
P8X2 fails the schoolkid test of ( P8X2 < P8X32) , so it must be an earlier/smaller part, right ?
Well the current chip is scarcely referred to as P8X32A except when ordering but is always referred to as we know it as the Propeller chip or Prop chip etc. The P2 should likewise have a appropriate part number which I am sure we will hardly ever refer to it as such. If we keep the first 3 characters as was also suggested yet keep the F to denote the fast and furious or flexible nature of the chip we could call it the P8XF128 which also sounds a bit like an experimental fighter.
-Phil
Some companies separate the 'Brand' from the part code, so it does not need one name for both.
eg Lattice have the Mach-XO2 series, with order part codes like this LCMXO2-256HC-4SG32C
-Phil
Allows for generic:
P{num cogs}X{hub size}-{io pins}
I dream of P16X512-128 TQFP-144 at the next geometry shrink in 2-3 years
-Phil
-Phil
Yes.
:0)
Maybe a name contest is in order.
...and look where they are today!!
Contests are always fun and ALWAYS entertaining!!
-Phil
Just occurred to me that the Rayslogic.com DVI Graphics Shield, with some luck, it may work as-is with Prop2...
At least, with a few minor changes, it's a Propeller Platform compatible Prop2 board that also has HD output over DVI/HDMI...
What about an exposed PAD ? Seems that would be an ideal option, and I've seen packages with relatively small central PADS.
( that suggest the exposed part is smaller than the die, so I guess a simple step design ? ).
This gives better thermal/electrical performance, and a slightly shrunk PAD allows vias inside the pins.
Best of all worlds ?
On the other hand, there really needs to be a 2 in there somewhere, to let folks know it's the second generation of the propeller, not just the first gen of a new board. hmm...
p8x96P2?
Still shows off all capabilities, and indicates second generation of processor.
As I recall, there was some sort of milestone scheduled for Oct.15
Eagerly awaiting news...
Currently Chip is finalizing the ROM code which will be distributed across the four HUB RAMs... The location and architecture of the ROM within the RAM dictates how the synthesized logic will communicate to it, therefore as the ROM changes and is updated, so does the synthesized logic. This needs to be finalized on Chips end before I can implement it in layout <-- The proper bit pattern for the ROM code. At the same time, when the synthesized logic is completed (expected date near the 22nd) I will place the finalized logic in the current layout and double check that there are no perimeter violations of the synthesized block. So essentially I will be receiving the ROM sequence and the synthesized logic block right at about the same time on top of one another. Scripting code should make the ROM bit placement easier, but there is always the learning curve of the first block (in this case 1/4th of the ROM) to make sure that the script addresses all of the pitch differences between odd/even rows and columns as well as odd/even ROM bits. Because the cells can be flipped and mirrored to conserve real estate, the downside is that the bit patterns in most cases don't retain the same pitch from an even bit to an odd bit. The same goes for the rows... since NMOS and PMOS transistors are sized differently, when the cells are flipped to utilize sharing power and ground structures more efficiently, the pitch from even rows to odd rows will be different. Now, even to even or odd to odd will have the SAME pitch ... anyway if this doesn't make sense I will try to take a snapshot when I am doing it to illustrate the phenomenon.
-Beau
So, Beau, are you saying that the content of the ROM affects the overall size and shape of the array of ROM bits, requiring repositioning and rejiggering? I've always thought of ROM as a uniformly-sized rectangular structure, independent of the data it holds.
-Phil
"So, Beau, are you saying that the content of the ROM affects the overall size and shape of the array of ROM bits, requiring repositioning and rejiggering? I've always thought of ROM as a uniformly-sized rectangular structure, independent of the data it holds." - Not exactly.... typically you would have a separate ROM and a separate RAM. In this case however a portion of the RAM is converted to ROM by replacing the current RAM bit cells. In addition, the ROM bits must be 'set' or 'cleared'. This setting or clearing amounts to simply setting a via at the correct location. The reason for the RAM/ROM merging is again to save real-estate. With the merged version you only need one set of CAS(Column Address Lines) and RAS (Row Address Lines), plus, you cut the amount of wire congestion into the synthesized logic down by half.
- Beau
-Phil
"So it's the placement of the vias that requires resynthesis of the entire logic section when they're changed?" - It's basically an iterative process in which Chip could probably explain better than myself. Most of the ROM is for boot communication/loading purposes. Other aspects that he has assigned to the ROM are equally important and require specific handling. Since the ROM has been under constant massage I don't have an exact pattern or even exact location yet, so even a general placement would be a moot point. Most of the synthesized work has been to meet critical timing paths across the chip while still maintaining a balanced mode of communication between individual COGs.
Re: ROM attributes. I suspect a simple layout would be subject to a decapping type attack or something. Flip a bit, make it jump, etc... Of course, I may be wrong, and either way, I also suspect we will be enlightened!
" I thought the ROM was implemented by just modifying one of the transistors in the 6-t cell so that the bit is stuck in the on or off state. " - Essentially yes, but because the memory bits are differentially driven and read, you have two bit lines per memory bit which makes it more complex than modifying just one of the transistors. It also can't be 'hard set' with just a direct wire connection without violating the reading (or writing) of other bit cells.