We are working right now to hopefully have a chip tapeout towards the end of January 2012.
The plan is to have beta tests between now and early this summer so that we will have an official release around EXPO time. That's the plan so far, assuming all goes well from here on out.
Yeah, and is there going to be a "beta" release on the documentation? An early read with the understanding that things can change would be a good thing.........
Hello, I just started playing with the Propeller, reading documents and posts etc. I must say I am very impressed both by the Propeller and the community. While reading about the new features of the upcoming chip, I noticed the following snippet about code protection. Since my day job involves a lot of security design and review, I wanted to add my two cents.
"1) Is there a fuse bit for code protection?" - That's the idea. OTP programmable fuses are tricky... since you can't really guarantee a 'complete' open circuit every time, i.e. the connection could just become highly resistive after metal vaporization. You must design the fuse in a way that the Fuse is compared differentially to a 'good' reference fuse that isn't purposefully destroyed. ...That said we are testing our implementation of that idea. The exact coding scheme used afterward is ***TOP SECRET*** ... no, there are a few ideas that have been discussed, and at this point I'm not sure what will be implemented.
I hope it is not too late at this point, but the "TOP SECRET" part was the thing that attracted my attention in the first place. Even with the smiley and subsequent clarification, I felt the need to emphasize that designing a security/cryptography scheme requires a lot of experience. I learned the hard way that reading Schneier's "Applied Crypto" is NOT enough for this purpose . Keeping the design or implementation hidden will not help security at all. Someone will dump the ROM, and figure out the scheme once the chip is out anyway. With a properly designed system, you should be able to disclose the design and implementation without introducing any security weaknesses at all.
A broken security implementation is worse than having none at all. With a broken code protection system, your customers relying on it will get burned. Without it, at least they know what they are getting. They may be able to structure their business model accordingly and accept the risk, or try to design their own schemes that are, of course, their own responsibility.
Having looked at some of the earlier discussions regarding code protection, here are some additional comments:
The security goal is to prevent someone from getting access to the code in the EEPROM. The basic design seems to be that there is a fuse that can be used to store a "key". The bootloader will use this key to decrypt the image when loading it from the EEPROM.
The choice of the encryption scheme (algorithm+mode) is important. Simple block-by-block encryption (ECB mode) would not work.
Consider having an image verification (authentication) scheme which is cryptographically strong (checksum won't do) especially if using a stream cipher. Otherwise, modifying (encrypted) EEPROM contents may lead to gaining control of the device.
Once encryption is enabled, it should either apply to ALL the images (from EEPROM, PC to be executed or burned, etc.) or unprotected software images should be prevented from accessing the key in the fuse.
The fuses should contain at least 128 bit key. 256 would be better.
The encryption (and authentication) should not directly use the "master" key in the fuses. Separate keys should be derived from this master key for encryption and authentication.
Software updates and RMA pose interesting challenges.
Consider having "version" fuses for rollback protection as well.
These are just some comments/questions that came to mind. Documenting the design and all the security assumptions and making it available to the community will help people build secure products rather than just pretending to be secure.
I strongly recommend getting professional help. There are companies that do such security design and analysis work, and no, I am not affiliated with any of them.
I hope this was not too harsh for a first message. There are too many badly designed security schemes out there, and I happen to like Propeller enough that I don't want to see it joining the crowd.
I am no cipher/security expert but I do wonder if if it's really worth expending so much effort on this. Seems to me that the cipher algorithm and the keys (fuses) are both shipped to you "attacker" so ultimately there is no way to stop him discovering your secrets. Or actually NOT discovering your secrets but being able to reproduce the whole thing anyway.
Wow! Now that is a first post! Welcome to Parallax and the propeller. This is exactly what I like about the propeller. It attracts knowledgeable people for industrial strength products yet the barrier for entry level "hobbyists" like me is relatively low.
Interesting points canacar. I think Phil also said strongly that hidden security is bad security (or something like that).
Even so, anything will be better that the code protection we have now.
And, with the millenium copyright act, do you really need good security?
If anybody breaks the security, they could be sued into shutting up, right?
canacar: Welcome to the fabulous prop world.
As for security, I am in two minds... You can implement something yourself to try and hide your code, or... get on with the job and try to beat the crooks by continuing to develop ahead of the game. IIRC Xilinx FPGA security has been broken and they were knowledgeable. These days there are just too many with time to break it for a hobby. however, I would like some form of protection to stop the easy approach of discovery.
Thanks for all the warm comments. Propeller is an exciting new hobby for me. I am relearning/catching up with the things I forgot/missed when I moved from EE to software/security many years ago. I will probably never need code protection, but I would hate to see yet another bad security scheme. I am also curious about where the balance between risk and reward lies in this environment.
This is just risk / reward. Set the bar high enough that the reward would not likely justify the risk. Past that, it's academic.
While I fully agree with potatohead's statement, I suspect that our definitions of "academic" and "high enough" may be somewhat different. I still find myself being amazed by what motivated hackers/attackers are capable of. There are very smart people out there with a lot of time and resources in their hands. It only takes a popular target or an interesting challenge to attract their attention (kind of like most of us, I suppose )
Setting the bar correctly is the main problem. The "code protection" is a new feature. Parallax must think that either their existing customers would benefit from code protection, or they are targeting a new customer base with this feature. This is why they are spending engineering resources, reserving valuable space for the fuses and additional code. Just like any other feature of their chips, it will have an impact on their business/reputation if this new feature does not work as advertised.
While the security business case comes from the customer, Parallax is effectively setting the bounds for security with their design. It is then up to individual customers to set the bar based on these bounds. For the customer to be able to set the bar, they must know the security model/assumptions that Parallax made when building this feature. Therefore, just like any other feature, the code protection feature needs to be designed, analyzed and documented properly. Note that the sentence "There is no code protection support in Propeller" is a very precise statement for the current generation of the chip. It allows the customers to make their business and design decisions with a good deal of accuracy. This should not change when the new security feature is implemented. The documentation/description of the security feature should be almost as precise so that the customers can build their security properly. The biggest mistake is to think that hiding the design or implementation of a security feature increases security.
In my previous post I made a few implicit assumptions about the security model and the "bar":
I was concerned about attackers running their own code to read the fuses and steal the key. This could happen if the volatile storage is encrypted, but code downloaded over serial is not.
Guessing the key offline by trying all possible keys was another concern. It is the reason for suggesting a 128-bit key which will remain there for the lifetime of the device/product.
Modifying the EEPROM contents to exploit weaknesses in the encryption scheme was another concern. This may lead to attacker influencing the execution flow and gaining access to the keys.
The first two concerns raised above are related to software-based attacks. Accessing/modifying the encrypted contents of the EEPROM is also relatively "easy" to do. Such attacks, once found and published, could be applied by anyone with basic software/hardware skills.
I have not considered more difficult attacks such as power/timing attacks against the crypto algorithm to figure out the key, or decapping the chip to read the fuse contents. Preventing some of these are much harder and people worried about them should probably consider smart cards or some form of secure execution environments.
Authentication of the code is as important as encryption. Authentication is needed to make sure the code running on the device is the one that is built by the device developers. Contrary to popular belief, encryption by itself does not guarantee this. In most cases authentication is more useful then code encryption. For insance, it allows the bootloader to pass the bucket to another "authentic" piece of code which can do all sorts of fancy encryption and authentication on the rest of the image.
Once again this turned out to be longer than I expected. One final note is that, in my opinion, not having any code protection is much better than having a bad protection scheme. While a bad scheme may still give a false sense of security to those that only need to fill in a check-box and/or satisfy a requirement, it will be broken for all the users for whom code protection really matters.
canacar: The "code protection" is a new feature. Parallax must think that either their existing customers would benefit from code protection, or they are targeting a new customer base with this feature.
Welcome to the forum, canacar. It's always nice to see new visitors who bring such valuable experience.
My read on the code security is that it's being added to target industrial users of the sort who would set the code protection bit on a PIC to protect their application code. For the most part this stuff isn't rocket science; it's about having your stuff cloned in China and sold cheaper than you can sell it. The bar for this can be pretty low; as you've said there are some very smart people out there, and at a certain point it just gets easier to re-engineer an application (that can fit in < 200K of RAM) than to bang your head against the encryption, decap chips, and so on.
The lack of code protection has been a criticism of the Prop I all along. The Prop is manufactured on a CMOS process which doesn't permit for on-board EEPROM, so it has to boot from an external memory. This was done to provide those clean external I/O lines and static operation. This means you can basically pop the EEPROM out of any Prop I system and, even if you don't bother to reverse engineer it, copy it with a < $100 programmer and create a duplicate system.
The code protection system doesn't have to be bulletproof, just harder than building a typical application from the ground up. Considering the scale of a typical Propeller application, I think anyone who might be tempted to start decapping Propellers and doing power consumption attacks would probably be better served just getting a manual, hanging out on the forums, and figuring out how to write the damn program themselves.
My read on the code security is that it's being added to target industrial users of the sort who would set the code protection bit on a PIC to protect their application code. For the most part this stuff isn't rocket science; it's about having your stuff cloned in China and sold cheaper than you can sell it. The bar for this can be pretty low; as you've said there are some very smart people out there, and at a certain point it just gets easier to re-engineer an application (that can fit in < 200K of RAM) than to bang your head against the encryption, decap chips, and so on.
<snip>
The code protection system doesn't have to be bulletproof, just harder than building a typical application from the ground up. Considering the scale of a typical Propeller application, I think anyone who might be tempted to start decapping Propellers and doing power consumption attacks would probably be better served just getting a manual, hanging out on the forums, and figuring out how to write the damn program themselves.
I completely agree. That is why I did not consider decapping chips a threat. The bar is definitely much lower than that.
Any other method that extracts the key means game over. For instance, if the EEPROM is encrypted but the device still allows loading and running code from RAM, a simple program to dump the key is enough to break the whole scheme. Use of an in-house encryption mechanism, or an incorrect use of an established algorithm may also break code protection. This is why I advocate an open design that is reviewed by security experts. In most cases small modifications to the protocol, or presence of simple countermeasures will determine whether the resulting system is secure or not. Making these changes, however, is much harder once the chip is out.
The lack of code protection has been a criticism of the Prop I all along. The Prop is manufactured on a CMOS process which doesn't permit for on-board EEPROM, so it has to boot from an external memory. This was done to provide those clean external I/O lines and static operation. This means you can basically pop the EEPROM out of any Prop I system and, even if you don't bother to reverse engineer it, copy it with a < $100 programmer and create a duplicate system.
Just like these guys do not have to design their own EEPROM programmers, they wont be the ones coming up with attacks against code protection. The attack they use will be automated. For them, creating a duplicate system will still be as easy as: Dump the EEPROM, run an application to decrypt the EEPROM, clone the system.
The actual attack itself will come form someone else. It may even originate here in the forums when people start worrying about recovering or reusing their "code protected" chips .
That's a good point canacar. While I will say Chip Gracey is one of the most ferociously intelligent people I have ever been privileged to meet, I'd be interested to hear his response.
I hate to whine, but whine I must. Though canacar brought up an interesting discussion, it completely derailed my question about getting a beta copy of the Prop II documentation. If Prop II is near term, I would like to start planning some code projects around it to get a head start for when it comes out.
I hate to whine, but whine I must. Though canacar brought up an interesting discussion, it completely derailed my question about getting a beta copy of the Prop II documentation. If Prop II is near term, I would like to start planning some code projects around it to get a head start for when it comes out.
[/URL]There is also an out of date 1.2 pdf web hosted copy which should probably be removed.
The current revision is 1.3.
The link claims 1.3, but the pages are tagged
"Propeller 2 Detailed Preliminary Feature List v1.1"
and the document is from early November.
Are the numbers in that document still valid for the latest builds ? [ 192K RAM / 2K ROM / 160MHz ]
Counter info is still frustratingly vague
["The counter modes now also feature quadrature encoder accumulation and automatic PWM generation."]
- no mention of MHz or Bits on those features, and no mention of HW capture modes ?
We really hope to be able to control and capture Pin edges to the MHz limit of the silicon, not some imposed lower software loop speed.
Are the numbers in that document still valid for the latest builds ? [ 192K RAM / 2K ROM / 160MHz ]
No, they're not. We will make another update as soon as possible. At this stage the design is in final layout, optimizations are still occurring, and some test/characterization will start shortly before we order the shuttle run.
Much progress has been made and we look forward to issuing revised specifications. All of your interests are the same as ours, yet we won't rush the next update. Talking with Chip quite frequently I'm confident we're making solid progress towards completion. As soon as possible we will provide another update to the specifications.
Thanks Ken,
Look forward to more info, especially around counters & Pin Control
Our wish-list here is to be able to
* Count external edges (80MHz or better ?)
- and at the same time -
* Count internal RefClock (160MHz?)
* Simultaneously Capture those ( and across multiple cogs) with a HW Pin-edge(s) (external, or SW pin toggle)
The best capture designs have a simple FIFO, so very narrow pulses do not confuse things, or get lost
* Manage extension above 32 bits
* Define any edge location to 1/160MHz
Some data-pump limit is ok, but 2 edges should be ok within 1 time unit.
This can mean a small FIFO, or a pair of compare Set/reset registers.
Just curious - bumping - but without rushing or pushing ...
I assume that no news is good news, indicating that you are happily busy with simulations and tapeout design and you are too busy to update the blog?
However, it would be nice to hear how you are doing, since many of us are emotionally sharing admiration, excitement and interest in the new Prop II development. Things are ready when they are ready...
Yes, layout towards tapeout is moving along... I had initially said that we were looking to tapeout towards the end of January. In reality, it looks like mid February, before I am out of the critical design path. Which means that I will essentially be done with the layout and the process towards fabricating Propeller II begins. At first we will make a test run with only a few chips and test various critical timing paths and make any necessary adjustments. Then another tapeout to make sure the changes were correct and then FINALLY the fun can begin for everyone! :-) ...Somewhere in there we will have a handful of beta testers but at the moment that's not on my radar.
Thanks for the update, highly appreciated. I know the tingling feeling when a design - after lots of optimization, tweaking and simulation - goes out from the door. You always feel uncertain if you remembered to test everything or overlook something. Good that you are not forced to keep a precise date.
I wish you good luck with the first tapeout (even though layout is 99% skills, sweat and simulation, but 1% is also luck). Only very few chips in the history of integrated circuits have worked 100% without at least a second mask set. Maybe you have some time to update the Prop II tech specs - after you have released the masks (hardware-vise only - no preliminary timing data will probably be available before the chip is in your test fixture)?
So, just curious. Has a part number been decided yet?
Propeller = P8x32A
Propeller II = P8x92A?
Another useful product idea; wonder if it's feasible: IOP4x32A. P8x32A with 4 cogs, and an external SRAM-like interface that gets access every other hub cycle.
Comments
The plan is to have beta tests between now and early this summer so that we will have an official release around EXPO time. That's the plan so far, assuming all goes well from here on out.
If the test run works, can you sell the extras?
No worries here!
Any updates on the final RAM and ROM sizes that fit ? ( & MHz ? )
I hope it is not too late at this point, but the "TOP SECRET" part was the thing that attracted my attention in the first place. Even with the smiley and subsequent clarification, I felt the need to emphasize that designing a security/cryptography scheme requires a lot of experience. I learned the hard way that reading Schneier's "Applied Crypto" is NOT enough for this purpose
A broken security implementation is worse than having none at all. With a broken code protection system, your customers relying on it will get burned. Without it, at least they know what they are getting. They may be able to structure their business model accordingly and accept the risk, or try to design their own schemes that are, of course, their own responsibility.
Having looked at some of the earlier discussions regarding code protection, here are some additional comments:
The security goal is to prevent someone from getting access to the code in the EEPROM. The basic design seems to be that there is a fuse that can be used to store a "key". The bootloader will use this key to decrypt the image when loading it from the EEPROM.
- The choice of the encryption scheme (algorithm+mode) is important. Simple block-by-block encryption (ECB mode) would not work.
- Consider having an image verification (authentication) scheme which is cryptographically strong (checksum won't do) especially if using a stream cipher. Otherwise, modifying (encrypted) EEPROM contents may lead to gaining control of the device.
- Once encryption is enabled, it should either apply to ALL the images (from EEPROM, PC to be executed or burned, etc.) or unprotected software images should be prevented from accessing the key in the fuse.
- The fuses should contain at least 128 bit key. 256 would be better.
- The encryption (and authentication) should not directly use the "master" key in the fuses. Separate keys should be derived from this master key for encryption and authentication.
- Software updates and RMA pose interesting challenges.
- Consider having "version" fuses for rollback protection as well.
These are just some comments/questions that came to mind. Documenting the design and all the security assumptions and making it available to the community will help people build secure products rather than just pretending to be secure.I strongly recommend getting professional help. There are companies that do such security design and analysis work, and no, I am not affiliated with any of them.
I hope this was not too harsh for a first message. There are too many badly designed security schemes out there, and I happen to like Propeller enough that I don't want to see it joining the crowd.
Best regards ...
Hi, welcome to the forum.
I am no cipher/security expert but I do wonder if if it's really worth expending so much effort on this. Seems to me that the cipher algorithm and the keys (fuses) are both shipped to you "attacker" so ultimately there is no way to stop him discovering your secrets. Or actually NOT discovering your secrets but being able to reproduce the whole thing anyway.
Wow! Now that is a first post! Welcome to Parallax and the propeller. This is exactly what I like about the propeller. It attracts knowledgeable people for industrial strength products yet the barrier for entry level "hobbyists" like me is relatively low.
Again, welcome!
Doc
Even so, anything will be better that the code protection we have now.
And, with the millenium copyright act, do you really need good security?
If anybody breaks the security, they could be sued into shutting up, right?
As for security, I am in two minds... You can implement something yourself to try and hide your code, or... get on with the job and try to beat the crooks by continuing to develop ahead of the game. IIRC Xilinx FPGA security has been broken and they were knowledgeable. These days there are just too many with time to break it for a hobby. however, I would like some form of protection to stop the easy approach of discovery.
While I fully agree with potatohead's statement, I suspect that our definitions of "academic" and "high enough" may be somewhat different. I still find myself being amazed by what motivated hackers/attackers are capable of. There are very smart people out there with a lot of time and resources in their hands. It only takes a popular target or an interesting challenge to attract their attention (kind of like most of us, I suppose
Setting the bar correctly is the main problem. The "code protection" is a new feature. Parallax must think that either their existing customers would benefit from code protection, or they are targeting a new customer base with this feature. This is why they are spending engineering resources, reserving valuable space for the fuses and additional code. Just like any other feature of their chips, it will have an impact on their business/reputation if this new feature does not work as advertised.
While the security business case comes from the customer, Parallax is effectively setting the bounds for security with their design. It is then up to individual customers to set the bar based on these bounds. For the customer to be able to set the bar, they must know the security model/assumptions that Parallax made when building this feature. Therefore, just like any other feature, the code protection feature needs to be designed, analyzed and documented properly. Note that the sentence "There is no code protection support in Propeller" is a very precise statement for the current generation of the chip. It allows the customers to make their business and design decisions with a good deal of accuracy. This should not change when the new security feature is implemented. The documentation/description of the security feature should be almost as precise so that the customers can build their security properly. The biggest mistake is to think that hiding the design or implementation of a security feature increases security.
In my previous post I made a few implicit assumptions about the security model and the "bar":
- I was concerned about attackers running their own code to read the fuses and steal the key. This could happen if the volatile storage is encrypted, but code downloaded over serial is not.
- Guessing the key offline by trying all possible keys was another concern. It is the reason for suggesting a 128-bit key which will remain there for the lifetime of the device/product.
- Modifying the EEPROM contents to exploit weaknesses in the encryption scheme was another concern. This may lead to attacker influencing the execution flow and gaining access to the keys.
The first two concerns raised above are related to software-based attacks. Accessing/modifying the encrypted contents of the EEPROM is also relatively "easy" to do. Such attacks, once found and published, could be applied by anyone with basic software/hardware skills.I have not considered more difficult attacks such as power/timing attacks against the crypto algorithm to figure out the key, or decapping the chip to read the fuse contents. Preventing some of these are much harder and people worried about them should probably consider smart cards or some form of secure execution environments.
Authentication of the code is as important as encryption. Authentication is needed to make sure the code running on the device is the one that is built by the device developers. Contrary to popular belief, encryption by itself does not guarantee this. In most cases authentication is more useful then code encryption. For insance, it allows the bootloader to pass the bucket to another "authentic" piece of code which can do all sorts of fancy encryption and authentication on the rest of the image.
Once again this turned out to be longer than I expected. One final note is that, in my opinion, not having any code protection is much better than having a bad protection scheme. While a bad scheme may still give a false sense of security to those that only need to fill in a check-box and/or satisfy a requirement, it will be broken for all the users for whom code protection really matters.
Best regards
Thanks for the update, we cant wait to get our hands on some of the Beta Chips.
Welcome to the forum, canacar. It's always nice to see new visitors who bring such valuable experience.
My read on the code security is that it's being added to target industrial users of the sort who would set the code protection bit on a PIC to protect their application code. For the most part this stuff isn't rocket science; it's about having your stuff cloned in China and sold cheaper than you can sell it. The bar for this can be pretty low; as you've said there are some very smart people out there, and at a certain point it just gets easier to re-engineer an application (that can fit in < 200K of RAM) than to bang your head against the encryption, decap chips, and so on.
The lack of code protection has been a criticism of the Prop I all along. The Prop is manufactured on a CMOS process which doesn't permit for on-board EEPROM, so it has to boot from an external memory. This was done to provide those clean external I/O lines and static operation. This means you can basically pop the EEPROM out of any Prop I system and, even if you don't bother to reverse engineer it, copy it with a < $100 programmer and create a duplicate system.
The code protection system doesn't have to be bulletproof, just harder than building a typical application from the ground up. Considering the scale of a typical Propeller application, I think anyone who might be tempted to start decapping Propellers and doing power consumption attacks would probably be better served just getting a manual, hanging out on the forums, and figuring out how to write the damn program themselves.
I completely agree. That is why I did not consider decapping chips a threat. The bar is definitely much lower than that.
Any other method that extracts the key means game over. For instance, if the EEPROM is encrypted but the device still allows loading and running code from RAM, a simple program to dump the key is enough to break the whole scheme. Use of an in-house encryption mechanism, or an incorrect use of an established algorithm may also break code protection. This is why I advocate an open design that is reviewed by security experts. In most cases small modifications to the protocol, or presence of simple countermeasures will determine whether the resulting system is secure or not. Making these changes, however, is much harder once the chip is out.
Just like these guys do not have to design their own EEPROM programmers, they wont be the ones coming up with attacks against code protection. The attack they use will be automated. For them, creating a duplicate system will still be as easy as: Dump the EEPROM, run an application to decrypt the EEPROM, clone the system.
The actual attack itself will come form someone else. It may even originate here in the forums when people start worrying about recovering or reusing their "code protected" chips
Best regards ...
Please reply.
Early documentation is here: http://www.parallaxsemiconductor.com/Products/propeller2specs
There is also an out of date 1.2 pdf web hosted copy which should probably be removed.
The current revision is 1.3.
The link claims 1.3, but the pages are tagged
"Propeller 2 Detailed Preliminary Feature List v1.1"
and the document is from early November.
Are the numbers in that document still valid for the latest builds ? [ 192K RAM / 2K ROM / 160MHz ]
Counter info is still frustratingly vague
["The counter modes now also feature quadrature encoder accumulation and automatic PWM generation."]
- no mention of MHz or Bits on those features, and no mention of HW capture modes ?
We really hope to be able to control and capture Pin edges to the MHz limit of the silicon, not some imposed lower software loop speed.
No, they're not. We will make another update as soon as possible. At this stage the design is in final layout, optimizations are still occurring, and some test/characterization will start shortly before we order the shuttle run.
Much progress has been made and we look forward to issuing revised specifications. All of your interests are the same as ours, yet we won't rush the next update. Talking with Chip quite frequently I'm confident we're making solid progress towards completion. As soon as possible we will provide another update to the specifications.
Ken Gracey
Look forward to more info, especially around counters & Pin Control
Our wish-list here is to be able to
* Count external edges (80MHz or better ?)
- and at the same time -
* Count internal RefClock (160MHz?)
* Simultaneously Capture those ( and across multiple cogs) with a HW Pin-edge(s) (external, or SW pin toggle)
The best capture designs have a simple FIFO, so very narrow pulses do not confuse things, or get lost
* Manage extension above 32 bits
* Define any edge location to 1/160MHz
Some data-pump limit is ok, but 2 edges should be ok within 1 time unit.
This can mean a small FIFO, or a pair of compare Set/reset registers.
Just curious - bumping - but without rushing or pushing ...
I assume that no news is good news, indicating that you are happily busy with simulations and tapeout design and you are too busy to update the blog?
However, it would be nice to hear how you are doing, since many of us are emotionally sharing admiration, excitement and interest in the new Prop II development. Things are ready when they are ready...
Cheers,
Christian
Yes, layout towards tapeout is moving along... I had initially said that we were looking to tapeout towards the end of January. In reality, it looks like mid February, before I am out of the critical design path. Which means that I will essentially be done with the layout and the process towards fabricating Propeller II begins. At first we will make a test run with only a few chips and test various critical timing paths and make any necessary adjustments. Then another tapeout to make sure the changes were correct and then FINALLY the fun can begin for everyone! :-) ...Somewhere in there we will have a handful of beta testers but at the moment that's not on my radar.
Thanks for the update, highly appreciated. I know the tingling feeling when a design - after lots of optimization, tweaking and simulation - goes out from the door. You always feel uncertain if you remembered to test everything or overlook something. Good that you are not forced to keep a precise date.
I wish you good luck with the first tapeout (even though layout is 99% skills, sweat and simulation, but 1% is also luck). Only very few chips in the history of integrated circuits have worked 100% without at least a second mask set. Maybe you have some time to update the Prop II tech specs - after you have released the masks (hardware-vise only - no preliminary timing data will probably be available before the chip is in your test fixture)?
Cheers,
Christian
Propeller = P8x32A
Propeller II = P8x92A?
Another useful product idea; wonder if it's feasible: IOP4x32A. P8x32A with 4 cogs, and an external SRAM-like interface that gets access every other hub cycle.
The other might be P28x128A, which would sound more "next gen" and belie the 96 I/O pins. Sort of Z80 vs Z8000.
-Phil
Ahh, so it's a non-scalable part number