The Parallax Chip I Really Want...
Brian Fairchild
Posts: 549
I'm under no illusion that I'll ever get one, but for the record, the chip I'd really like is...
16 x 100 MIPS cores (cores 1-16) each with 4k of 32-bit longs for registers, no hubexec, smart pins as previously described
1 additional (identical) core 0 with no IO but with hubexec from central memory
256k of central memory accessed in a strict round robin core0, core1, core0, core2, core0, core3....
central cordic and central big multiplier
that's it, no slot allocation, no tables, no complicated schemes.
I hear the cry "but the core only has 9-bit address fields" to which I reply "so what, that's the last processor, the proposed one bears no resemblance to it, and existing objects won't run without modification anyway."
Plus a decent IDE C compiler, for which I'd pay money, and a set of known working soft-peripherals to get designs off the ground quickly.
The reality is that I'll not see one of those nor any other silicon in the wild for at least a year. Shame really. But, on the up side I can buy M4 based boards now for less than the projected cost of a P16X64A chip and if I bought a DE0-nano I can fit 12 NIOS-IIs in it.
16 x 100 MIPS cores (cores 1-16) each with 4k of 32-bit longs for registers, no hubexec, smart pins as previously described
1 additional (identical) core 0 with no IO but with hubexec from central memory
256k of central memory accessed in a strict round robin core0, core1, core0, core2, core0, core3....
central cordic and central big multiplier
that's it, no slot allocation, no tables, no complicated schemes.
I hear the cry "but the core only has 9-bit address fields" to which I reply "so what, that's the last processor, the proposed one bears no resemblance to it, and existing objects won't run without modification anyway."
Plus a decent IDE C compiler, for which I'd pay money, and a set of known working soft-peripherals to get designs off the ground quickly.
The reality is that I'll not see one of those nor any other silicon in the wild for at least a year. Shame really. But, on the up side I can buy M4 based boards now for less than the projected cost of a P16X64A chip and if I bought a DE0-nano I can fit 12 NIOS-IIs in it.
Comments
To address those 4K registers you will need at least 12 bits. That's another 8 bits per instruction. Are you proposing a 40 bit wide instruction in order to fit them in?
Clearly not as you specified 32-bit longs.
So how are you going to do this? I look forward to seeing your proposed instruction set an instruction encodings.
Or go back to variable length instructions on a LONG boundary just like we used to have variable length instructions on BYTE boundaries in the old days. Remember all the fun of hand disassembling 8 bit machine code?? It will be like deja vu all over again!!
That's it...
(Of course it's way too late for that.)
Except with more pins, more RAM and more COGS.
Sounds great!
That's my .02$ worth!
-joe
EDIT: Yes, port B would provide an additional 32 bits of I/O.
And in fact it would not be hubex, but in fact native because in fact, that is how modern micros (both microcontrollers and microprocessors) work...
Main program and data memory, and registers. In our case we have ~496 registers + ~16 special registers.
Running code in those registers is abnormal in the normal scheme of things.
And absolutely deterministic while running within the cog (core).
Then we keep the same nice regular architecture and instruction encoding style but can extend those src/dst fields to enable addressing millions of HUB registers.
That should satisfy all those who want more memory space in HUB without making crude hacks in the architecture.
I suspect a 40 bit wide architecture would do. But that might be to weird for people to accept.
kwinn Eeew. I can see many reasons for not wanting to do that.
Um, no, we wouldn't want to do that!
I agree that is an opening, but the questions are what Price and what Package ?
Examples : I see latest Cypress PSoC4000 claims from ~29c (but that is 8p, & next size is 2x price), and Nuvoton show ~30c for a TSSOP20 part. - and both those parts have Flash on chip.
A two-chip solution, pitched at 'Low Pin Counts' is a little counter intuitive.
Keeping code and data the same bit width does make for a simpler cleaner design but is not always the most efficient design. One instrument I worked on had an embedded computer with 12 bit program memory and IIRC 36 bit registers. It used the minimum hardware possible for doing the calculations with the precision needed for that application, and could be made at a reasonable cost.
As much as I like the precision and memory space 64 bits makes possible I have to wonder if it is worth the inefficiency of 64 bit instructions on a microcontroller. How much hardware can be placed on a chip for instruction decoding, cpu's, memory, and I/O? If instructions can address gigabytes of memory but the chip has space for megabytes aren't those extra bits in the instructions wasted space?