What I would like to see in the Prop 2

JT Cook

What I would like to see is someway to have the option to secure the source code. Now there isn't enough space to add an eeprom inside the chip, but what if the chip only stored an encryption key that was rewritable? Lets say you go to program the Prop, it will ask for an encryption key, it will program the key inside the Prop, encode the binary which is then written to the external eeprom.

This would also work if a 3rd party would write their Prop 2 programming tool as well. Just have the first 8 or so bytes written to prop for encryption (or all zeros for no encryption), have the compiler encrypt the binary

So that way you only need about 8 or so writable bytes on the Prop itself, and source code can also be secured at the same time. I don't know how far the Prop 2 is in developement if it is too late to add this, or some other solution has been created for it, but that is my two cents on it.

Mike Green

This sort of topic has come up several times before and has been discussed at length. There has been some mention of a possible fusible link location that could be programmed once-only and could be used for a chip serial number or password. There's no way to provide any rewritable storage on-chip because of the chip (manufacturing) process being used. Beyond that, we probably won't hear anything further about features until much later in the design/test process.

Beanie2k

OK, I'm puzzled. I'm by no means an expert at these things but... don't FPGA's also have their mappings stored in off-chip memory? At least all the ones I've seen do. So how do mfr's secure the FPGA code? And couldn't the same method be used for the Prop? Probably a dumb question, but I'd like to know the answer for my own education.

Beau Schwabe

Beanie2k,

What uniquely identifies the Propeller from one Propeller to the next Propeller is the code located external to the Propeller in EEPROM, the dilemma is that anyone could copy the EEPROM and use the code on another Propeller. With a FPGA you can uniquely identify code internally by configuring non-volatile internal RAM. That said, in order to implement non-volatile internal RAM, FPGA uses a different CMOS process than we are using for the Propeller which makes the implementation of FPGA or FPGA techniques an impossibility in the current CMOS process we are using.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 7/16/2007 12:25:50 AM GMT

Peter Jakacki

Hi Beanie2k,

What Paul is probably saying is that you can exactly what you want if you had the $$$money to pay for it. Designing silicon is one thing and you can simulate it till the cows come home but strange things can happen when it comes back from fab, and fabs cost $$$ each time (and time). The simpler silicon processes just cost $$$ rather than $$$$$$ and as a small fabless company you also have to be able to work in with the fab and it's people, something which Parallax have managed (remember that they don't have a fab).

So Parallax don't have the huge resources of a 'megaglobal' which limits them in what they can do process-wise. This is also a good thing because a megaglobal would not be making a Propeller but maybe a more of a arrmm... 'tried and proven' design. Also, we would not be having these discussions with the engineers, we would be lucky to speak to a FAE if that.

Thanks Parallax for your drive and commitment to this refreshing concept that has already borne much fruit. Go forth and multiply.

*Peter*

Beanie2k

Beau Schwabe (Parallax) said...
Beanie2k,

What uniquely identifies the Propeller from one Propeller to the next Propeller is the code located external to the Propeller in EEPROM, the dilemma is that anyone could copy the EEPROM and use the code on another Propeller. With a FPGA you can uniquely identify code internally by configuring non-volatile internal RAM. That said, in order to implement non-volatile internal RAM, FPGA uses a different CMOS process than we are using for the Propeller which makes the implementation of FPGA or FPGA techniques an impossibility in the current CMOS process we are using.

Thanks for the reply Beau. As I mentioned, I am new at this, my last experience with anything similar was programming Altera PLD's back in 1993, so things have changed somewhat, and I have a bit of catching up to do. I was not aware that FPGA's had any non-volatile storage, as the few articles I had read simply mentioned that the fuse maps (or whatever they are called these days) are stored in off-chip memory and are downloaded into volatile RAM on power-up, just like the Propeller. If FPGA's do have a small amount of persistent on-chip storage, then I understand how it could be used for stashing some kind of keying material.

As for the Prop and its security, I note that this issue has been debated at length in other threads and I will leave the debate there. My question has been answered and I again thank you for your reply.

Beanie2k

Post Edited (Beanie2k) : 7/17/2007 2:29:10 AM GMT

Ale

What I would really like to see is an integrated SDRAM controller, that would rock . But I think that with 16 cogs at 160 MHz, it could be solved in software, so more pins is the way to go !
With 28 pins you get 16 MB, not bad

edit: syntax error corrected