ROM takes a lot less chip real estate than RAM. There have been pictures posted showing the layout of the Prop-1. Leaving out the ROM would get you a few K of additional RAM, nowhere near 32K.
As I understand from what has been explained, the P1B (the 64 I/O) layout has been completed for a looong time but the tools to verify this are broken, and there seems no simple way to get around this.
Therefore, what I would like to see (presuming that the existing work on the P1B has to be somewhat ditched)... a P1C with...
Similar process to keep power consumption down, perhaps even lower?
Still 8 cogs
64KB hub space (to keep address compatibility) with a small bootloader (aka P2) in the top 2-4KB and the remainder 60-62KB sram
Yes, it requires more chip space
If possible, cog access to hub improved to 1:8 instead of 1:16
Look at the time critical paths to see if the clock speed can be increased (120+MHz???) - I use 104MHz regularly now!
Extra I/O, maybe 48-64
QFP64 and/or QFP84 package and perhaps DIP64 ???
a DIP64 package was done with Hitachi 64180 using 0.6"wide @ 0.07" pitch - could this be possible and is it required???
An extra instruction to swap I/O banks - instead of using the C bit to select the upper 32 I/O
Perhaps use SPI Flash (similar to P2) ???
Of course, none of this is likely to happen until well after the P2 release, and only if there are sufficient sales generated for P2 and P1 to generate funds for this. So we are most likely looking at 2+ years, and a lot is going to happen in this time frame. So, currently it is a nice discussion topic for us, but IMHO Parallax does not have the time/resources to look at this for the time being.
Similar process to keep power consumption down, perhaps even lower?
Yes, it requires more chip space
Right there, we have a problem : I believe the Prop 1 die is already package-maxed ?
What could be done, is a Prop 2 with the die-expensive MUL opcodes (et al) removed, and shrunk to 4 cores, and on a Power-tuned process, but one small enough to allow more RAM, and packages from maybe TQFP32..TQFP64
I see some Asian vendors offering 64 pin SMD, in a choice of pin-pitch.
Because the threaded details of Prop 2 are such a jump up from Prop 1, any reduced-core device really needs this.
( and I would add fastest possible (HW) block load from QuadDDR SPI, but that has very low silicon cost )
Comments
Therefore, what I would like to see (presuming that the existing work on the P1B has to be somewhat ditched)... a P1C with...
- Similar process to keep power consumption down, perhaps even lower?
- Still 8 cogs
- 64KB hub space (to keep address compatibility) with a small bootloader (aka P2) in the top 2-4KB and the remainder 60-62KB sram
- Yes, it requires more chip space
- If possible, cog access to hub improved to 1:8 instead of 1:16
- Look at the time critical paths to see if the clock speed can be increased (120+MHz???) - I use 104MHz regularly now!
- Extra I/O, maybe 48-64
- QFP64 and/or QFP84 package and perhaps DIP64 ???
- a DIP64 package was done with Hitachi 64180 using 0.6"wide @ 0.07" pitch - could this be possible and is it required???
- An extra instruction to swap I/O banks - instead of using the C bit to select the upper 32 I/O
- Perhaps use SPI Flash (similar to P2) ???
Of course, none of this is likely to happen until well after the P2 release, and only if there are sufficient sales generated for P2 and P1 to generate funds for this. So we are most likely looking at 2+ years, and a lot is going to happen in this time frame. So, currently it is a nice discussion topic for us, but IMHO Parallax does not have the time/resources to look at this for the time being.Right there, we have a problem : I believe the Prop 1 die is already package-maxed ?
What could be done, is a Prop 2 with the die-expensive MUL opcodes (et al) removed, and shrunk to 4 cores, and on a Power-tuned process, but one small enough to allow more RAM, and packages from maybe TQFP32..TQFP64
I see some Asian vendors offering 64 pin SMD, in a choice of pin-pitch.
Because the threaded details of Prop 2 are such a jump up from Prop 1, any reduced-core device really needs this.
( and I would add fastest possible (HW) block load from QuadDDR SPI, but that has very low silicon cost )