Ken, that figure above sure puts my bank balance and monthly expenses into perspective. Given the small scale, I can appreciate what the large scale must be like, good luck!
And keep in mind I don't share these numbers to impress anybody, though it's true the numbers are big. I share them to reinforce that this effort will take everything we've got, that sacrifices will be made to do it, and that we're in the project to finish it.
And keep in mind I don't share these numbers to impress anybody, though it's true the numbers are big. I share them to reinforce that this effort will take everything we've got, that sacrifices will be made to do it, and that we're in the project to finish it.
It is very encouraging that you're in this to finish it in spite of recent setbacks.
Total: ~ 34 weeks. Yikes! That's the end of April next year. No chips for Christmas.
Some of those number seem quite huge: synthesis 10 weeks, fabrication 16 weeks. Is that how long it takes or is it a lot of waiting in line to get you job fitted in?
I have to go an buy a tube of DIP Props to pass the time.
Synthesis probably isn't a complete description. It would also include the place and route, timing closure, (test insertion and pattern generation for the typical flow but it sounds like Parallax doesn't do this),...
This is just for the first parts at Parallax correct? Assuming that everything works perfectly, there's still going to be quite a bit of time spent doing chip qualification (e.g. I would expect split lots given the custom circuits, HTOL,...) before they could get into production. And the time to bring the production testers up (and come up with sufficiently high coverage metrics if functional patterns are used - may require fault grading) which would ideally be in parallel. Not trying to be a killjoy, but people might misinterpret the 34 weeks as time to PRA.
I really want to help out and I'm sure that most people in this forum want to as well. The problem is that I can't help you financially and of course not many can help Chip and Beue in the hw design. What can we do then?
We can promote the Propeller 1 as an alternative to other MCU's on different media channels or at work. (I will do the later). We can create something that is almost impossible to do with other single core MCU's and that makes enough impact on the "pros" in the bussiness to realize the benefits of the Propeller. I work with a lot of different architectures at work and sometimes I thinks to myself "if we only had used the Propeller, problem X would have been sooooo much easier". Many times we end up with designs with many different CPU's on the same board. In some cases the Propeller would have been the perfect match. It would have been great if we forum members could create something totally awesome with the P1 and promote it on YouTube or other media channels? I'm sure I personally havn't tapped a fraction of the full potential of the P1 yet. Most of my efforts has just pushed a few cogs really hard.
That reminds me, Beau, what are the specs of the computer you are using to do all of this work? I seem to recall you said it took days to perform some of the checks. Does the software have support for "compute" farming, where you run a client on a remote computer to do some of the heavy lifting?
The software does not support CPU farming, but I have since upgraded. I have a Quad CPU (Q6600 @2.4GHz) processor with 6 Gigs of main memory and a 120 Gig solid state drive configured as a swap drive ... All Linux platform (which makes a difference when talking swap drive). During an LVS or DRC I have dipped into the swap by about 50 Gigs.
An LVS takes almost exactly 7 hours to run, while a DRC does as well. .... <--- before this process took about 3 days
The LVS/DRC process however is not necessarily the bottleneck unless you have an error you are trying to hunt, but even in those cases I can use a divide and conquer approach to effectively isolate the problematic area. ALL sub-blocks only take a matter of seconds to LVS/DRC, it's when you move up into the hierarchy of the design that it exponentially takes longer to evaluate.
Part of the synthesis time might be confused with simulation time. The synthesis time refers to the glue logic within the core of the design. The simulation time refers to the analog circuitry that Chip will do to re-target the design perimeters correctly for the process. When he is done with that he will hand it off to me where I can make changes to the custom layout. At the same time in parallel, hopefully the core will be under synthesis as to meet critical timing constraints we have provided.
When the core is synthesized, It will then need to be placed within the custom layout, and then once again LVS'd and DRC'd to make sure the core itself doesn't break anything.
When all checks out with DRC and LVS, the paper work and sending the design to the fab starts.
Could you make a digital-only version of the P2 and leave out the fancy analog pin stuff? Wouldn't that allow you to synthesize the entire chip sort of like what you do with the FPGA? I understand that that wouldn't be a saleable product but it might help verify that all of the digital logic works. Would that reduce the risk at all? It seems like a lot of the risk has to do with the interfaces between the synthesized logic and the fancy digital/analog pins.
"Could you make a digital-only version of the P2 and leave out the fancy analog pin stuff?" - You could, but you still have to create some PAD structure (with ESD protection) to support the bond wires going from the chip to the chip package.
"It seems like a lot of the risk has to do with the interfaces between the synthesized logic and the fancy digital/analog pins." - There are several factors at play here, Yes, you could do a "digital only", but you still need to connect to the outside world through the PADS.
Much of the synthesized logic communicates with the "fancy IO pins". If you take that out of the equation, you are at just as much risk testing the logic without the "fancy IO pins". The logic has been tested with the FPGA already.... all be it not all of the COGs, but this essentially is stepped and repeated within the synthesized core. We're at a point now that we must test with the "fancy IO pins" in place. To do so otherwise would be of greater risk towards the finished product.
"Could you make a digital-only version of the P2 and leave out the fancy analog pin stuff?" - You could, but you still have to create some PAD structure (with ESD protection) to support the bond wires going from the chip to the chip package.
"It seems like a lot of the risk has to do with the interfaces between the synthesized logic and the fancy digital/analog pins." - There are several factors at play here, Yes, you could do a "digital only", but you still need to connect to the outside world through the PADS.
Much of the synthesized logic communicates with the "fancy IO pins". If you take that out of the equation, your at just as much risk testing the logic without the "fancy IO pins". The logic has been tested with the FPGA already.... all be it not all of the COGs, but this essentially is stepped and repeated within the synthesized core. We're at a point now that we must test with the "fancy IO pins" in place. To do so otherwise would be of greater risk towards the finished product.
I really want to help out and I'm sure that most people in this forum want to as well. The problem is that I can't help you financially and of course not many can help Chip and Beue in the hw design. What can we do then?
We can promote the Propeller 1 as an alternative to other MCU's on different media channels or at work. (I will do the later). We can create something that is almost impossible to do with other single core MCU's and that makes enough impact on the "pros" in the bussiness to realize the benefits of the Propeller. ...
/Johannes
Time for one to reconcile oneself to the fact that P2 remains a ways off (8 years and counting). In the meantime, in order to keep the ball rolling so to speak, what you suggest makes sense. Interest in the Propeller needs to be cultivated grassroots style. And P1 must be the focus of this grassroots effort, since it is the Propeller for the foreseeable future.
Preaching to the choir is of no use: EE forums (other than Parallax's), co-workers,... wherever it makes sense to do so, plug the P1.
No, not a dumb idea. Just equally as much work to make an all digital version. Especially when the IP for the current analog I/O's have already been tested and proven.
No, not a dumb idea. Just equally as much work to make an all digital version. Especially when the IP for the current analog I/O's have already been tested and proven.
The only reason I suggested it is that I thought you could do an "all synthesized" chip where you didn't have to worry about the interfaces between the synthesized core and the custom pin logic. If you would have to do custom pin logic even for an all-digital version then I guess there is no benefit. Anyway, good luck on the spin! We'll all be looking forward to chips sometime next year.
I have a Quad CPU (Q6600 @2.4GHz) processor with 6 Gigs of main memory... During an LVS or DRC I have dipped into the swap by about 50 Gigs.
At work, we have a build server with a dual-socket 6-core Xeon X5650. HyperThreading brings us to 24 virtual cores, and the machine has 96GB of main memory. It has space for up to 192GB. Would such a machine help you do your work faster? Even on an SSD, dipping into swap slows things down a lot. What is your LoadAverage during LVS and DRC?
At work, we have a build server with a dual-socket 6-core Xeon X5650. HyperThreading brings us to 24 virtual cores, and the machine has 96GB of main memory. It has space for up to 192GB. Would such a machine help you do your work faster? Even on an SSD, dipping into swap slows things down a lot. What is your LoadAverage during LVS and DRC?
I have an SSD on my MacBook Pro and it doesn't seem to have sped up PropGCC builds all that much. I'm wondering if SSD mostly speeds up reads and not writes?
...Especially when the IP for the current analog I/O's have already been tested and proven.
Tested and proven on what process ?
Hopefully the VHDL changes Chip is doing, include some JTAG like test access, as one problem with the present chips is how little test coverage you have.
That means a full errata does not start until the next pass is back, and then the pass after that is to fix the errata.
Are you able to confirm the ESD design, on the die you have now, for the OnSemi process ?
I have an SSD on my MacBook Pro and it doesn't seem to have sped up PropGCC builds all that much. I'm wondering if SSD mostly speeds up reads and not writes?
What's your load average during a PropGCC build? Chances are, you're using little enough ram for GCC that most of the RAM acts as a disk cache so you don't hammer the disk with speed that much. Do you build gcc with -j6 or something along those lines?
What's your load average during a PropGCC build? Chances are, you're using little enough ram for GCC that most of the RAM acts as a disk cache so you don't hammer the disk with speed that much. Do you build gcc with -j6 or something along those lines?
Not sure what my average load is but I build with -p5 and I have 8gb of RAM.
I'm not, sure... sounds like your work machine is pretty powerful. I do know that during an LVS or DRC I absolutely do not want to hash into my Hard drive, so I chose dedicating a SSD for the hashing. <-That's ALL it's used for. Before I was using a regular drive still configured as a swap of comparable size and it was painfully slow, and a few crashed. Since the addition of the SSD I have noticed a considerable performance improvement, so I must have done something correct. Even on the relatively small blocks that used to take hours to run, now only take a matter of minutes. The caveat, is that I used to use the down time between LVS and DRC to write code for the current Propeller.... NOW, I can't say that as much... the LVS/DRC is done before I have a chance to get the code around my head.
Well I am glad to see that we are a step closer to seeing the Propeller II. I have always tryed to promete the use of the Prop1 (P8X32A) by every person and company that I deal with that could put it to use. Considering these delays after the Prop II hits market and recovers the development costs in full, will the design of the Prop 2+, Prop 1B, Prop 3, or what ever is next, go back to the design method of laying everything out by hand from the base polygons up as was done with the Propeller P8X32A? It does seem to be a mothod that has good resaults for Parallax. I would still like to see a faster Prop 1 with PORT B pins available, some time in the future after the Prop II is succesful.
I hate to cut your P1 coding time, but I think the argument could be made that you need to ask for $8k to buy computer parts for yourself. My recommended list:
That will give you 20 cores, 256GB Ram, 6 monitor outputs, and space for 8 - 3.5" hard drives. Move your current Linux install over and I should hope it would just boot up and work.
"... [will you] go back to the design method of laying everything out by hand from the base polygons"
The short answer is no. Chip complexity has gotten to a point where that is impractical. Even if the growth in area could be mostly memory the design time would go from 8 years to 16.
And if it takes you 16 years to do a chip, it would only be obsolete by 14 years.
LOL, I don't think his current linux version would be capable of running that combo. From his screenshots it appears he's running Fedora 14.
I upgraded to an i7-4770 and found that there were a couple of things that needed drivers present in newer versions of Fedora. I was running Fedora 15 on an i5-2910 and it was happy. The new IGP 4600 wasn't fully supported.
I really have to wonder if 20 cores (40 threads) could really be used effectively by his program. The mucho RAM I totally back, but $2k CPUs is a little much, without a known performance metric.
LOL - I am running Fedora 14 ... I stopped trying to upgrade and keep up with the latest version because there were a few driver hoops that I got tired of messing with my current system requirements. Besides I have been in a critical layout mode for a few years and didn't want to mess with trying to make sure a 'new' system would be stable in the middle of a project. ...and Mainly the SIZE of the project has grown exponentially as it nears it's completion, which further complicates moving to a new system.... when the dust settles I will upgrade to the latest version, but for now, it's not a wise decision.
Ken: Thanks for your honesty - it really puts the development in perspective!
I have done a number of 36hr benders in my time, so make sure Chip takes some time out to recover. I know when you are onto something great, it is hard to put it down.
Now, for some further thoughts...
One of the big delays and costs is the Synthesis section. This has already been done for the TSMC process and we know there is a problem with the reset area.
Since (Beau) has control of the outer I/O area, could the reset problem be fixed simply within the I/O area by Beau, and a die set be done by TSMC? I know this would mean an extra step to finalising the P2, but might this be a cheaper way to verify things already done? Meanwhile we could be testing the new FPGA/Verilog code without the need to re-Synthesise until the basics have been verified?
Could the I/O be further modified by removing some of the I/O so that some testing ffs could be inserted there to bring out some of the internal connection signals to the Synthesis area.
To summarise, can you reduce your expenditure to prove the majority is working in a shorter timeline, even if it means slightly longer overall times and increased cost, rather than find another problem after the full respin and expenditure has been done?
Using an SSD for swap was a good idea; now the next easy performance boost would be to max out the ram capability of your machine - if you can run 6GB, you can run 8GB. Then add a second SSD for /tmp.
Of course building a new kick-*** machine beside it to eventually take over would also help. It's pretty easy to make a 6 core / 12 thread socket 2011 machine with 32GB of ram (64GB on some motherboards)
LOL - I am running Fedora 14 ... I stopped trying to upgrade and keep up with the latest version because there were a few driver hoops that I got tired of messing with my current system requirements. Besides I have been in a critical layout mode for a few years and didn't want to mess with trying to make sure a 'new' system would be stable in the middle of a project. ...and Mainly the SIZE of the project has grown exponentially as it nears it's completion, which further complicates moving to a new system.... when the dust settles I will upgrade to the latest version, but for now, it's not a wise decision.
I don't like to ask for freebees. So, let's put a price tag on those add-on boards that I can live with:)
The Prop2 exists... it just isn't in its final form. Tonight, I was at the Micro Center in Westmont Il. I don't think they are ready for the Prop2:)
About sleeplessness... I had irradiation to my brain stem as a side effect of treating metastatic squamous cell carcinoma in my neck... I mention this because after the radiation I had of narcolepsy.
I simply couldn't wake up. Something in my brainstem had been damaged. I was placed on Provigil... which worked like a charm. Except that when I was traveling in Amsterdam, I suddenly went sleepless.
My brain stem suddenly recovered to the point that I no longer needed the Provigil. I understood this, but as an experiment, I decided to continue the Provigil anyway.
On the 11th day, I was absolutely convinced that I should walk through Amsterdam with my eyes shut, because at a certain location I would be knighted by the Queen of England... it was all very real. Sleep is essential. Sleeplessness is not acceptable.
Comments
And keep in mind I don't share these numbers to impress anybody, though it's true the numbers are big. I share them to reinforce that this effort will take everything we've got, that sacrifices will be made to do it, and that we're in the project to finish it.
That is very candid of you. We do appreciate it.
Of course we will love to have the configuration for our FPGA boards for any new changes to bash on.
Synthesis probably isn't a complete description. It would also include the place and route, timing closure, (test insertion and pattern generation for the typical flow but it sounds like Parallax doesn't do this),...
This is just for the first parts at Parallax correct? Assuming that everything works perfectly, there's still going to be quite a bit of time spent doing chip qualification (e.g. I would expect split lots given the custom circuits, HTOL,...) before they could get into production. And the time to bring the production testers up (and come up with sufficiently high coverage metrics if functional patterns are used - may require fault grading) which would ideally be in parallel. Not trying to be a killjoy, but people might misinterpret the 34 weeks as time to PRA.
I really want to help out and I'm sure that most people in this forum want to as well. The problem is that I can't help you financially and of course not many can help Chip and Beue in the hw design. What can we do then?
We can promote the Propeller 1 as an alternative to other MCU's on different media channels or at work. (I will do the later). We can create something that is almost impossible to do with other single core MCU's and that makes enough impact on the "pros" in the bussiness to realize the benefits of the Propeller. I work with a lot of different architectures at work and sometimes I thinks to myself "if we only had used the Propeller, problem X would have been sooooo much easier". Many times we end up with designs with many different CPU's on the same board. In some cases the Propeller would have been the perfect match. It would have been great if we forum members could create something totally awesome with the P1 and promote it on YouTube or other media channels? I'm sure I personally havn't tapped a fraction of the full potential of the P1 yet. Most of my efforts has just pushed a few cogs really hard.
/Johannes
The software does not support CPU farming, but I have since upgraded. I have a Quad CPU (Q6600 @2.4GHz) processor with 6 Gigs of main memory and a 120 Gig solid state drive configured as a swap drive ... All Linux platform (which makes a difference when talking swap drive). During an LVS or DRC I have dipped into the swap by about 50 Gigs.
An LVS takes almost exactly 7 hours to run, while a DRC does as well. .... <--- before this process took about 3 days
The LVS/DRC process however is not necessarily the bottleneck unless you have an error you are trying to hunt, but even in those cases I can use a divide and conquer approach to effectively isolate the problematic area. ALL sub-blocks only take a matter of seconds to LVS/DRC, it's when you move up into the hierarchy of the design that it exponentially takes longer to evaluate.
Part of the synthesis time might be confused with simulation time. The synthesis time refers to the glue logic within the core of the design. The simulation time refers to the analog circuitry that Chip will do to re-target the design perimeters correctly for the process. When he is done with that he will hand it off to me where I can make changes to the custom layout. At the same time in parallel, hopefully the core will be under synthesis as to meet critical timing constraints we have provided.
When the core is synthesized, It will then need to be placed within the custom layout, and then once again LVS'd and DRC'd to make sure the core itself doesn't break anything.
When all checks out with DRC and LVS, the paper work and sending the design to the fab starts.
"Could you make a digital-only version of the P2 and leave out the fancy analog pin stuff?" - You could, but you still have to create some PAD structure (with ESD protection) to support the bond wires going from the chip to the chip package.
"It seems like a lot of the risk has to do with the interfaces between the synthesized logic and the fancy digital/analog pins." - There are several factors at play here, Yes, you could do a "digital only", but you still need to connect to the outside world through the PADS.
Much of the synthesized logic communicates with the "fancy IO pins". If you take that out of the equation, you are at just as much risk testing the logic without the "fancy IO pins". The logic has been tested with the FPGA already.... all be it not all of the COGs, but this essentially is stepped and repeated within the synthesized core. We're at a point now that we must test with the "fancy IO pins" in place. To do so otherwise would be of greater risk towards the finished product.
Preaching to the choir is of no use: EE forums (other than Parallax's), co-workers,... wherever it makes sense to do so, plug the P1.
Tested and proven on what process ?
Hopefully the VHDL changes Chip is doing, include some JTAG like test access, as one problem with the present chips is how little test coverage you have.
That means a full errata does not start until the next pass is back, and then the pass after that is to fix the errata.
Are you able to confirm the ESD design, on the die you have now, for the OnSemi process ?
I'm not, sure... sounds like your work machine is pretty powerful. I do know that during an LVS or DRC I absolutely do not want to hash into my Hard drive, so I chose dedicating a SSD for the hashing. <-That's ALL it's used for. Before I was using a regular drive still configured as a swap of comparable size and it was painfully slow, and a few crashed. Since the addition of the SSD I have noticed a considerable performance improvement, so I must have done something correct. Even on the relatively small blocks that used to take hours to run, now only take a matter of minutes. The caveat, is that I used to use the down time between LVS and DRC to write code for the current Propeller.... NOW, I can't say that as much... the LVS/DRC is done before I have a chance to get the code around my head.
I hate to cut your P1 coding time, but I think the argument could be made that you need to ask for $8k to buy computer parts for yourself. My recommended list:
1x MBD-X9DR3-F-O
1x CSE-745TQ-R800B
4x 3RSH160011R5H-64GQ
2x BX80635E52690V2
1x VisionTek 900614
All are available at NewEgg.
That will give you 20 cores, 256GB Ram, 6 monitor outputs, and space for 8 - 3.5" hard drives. Move your current Linux install over and I should hope it would just boot up and work.
The short answer is no. Chip complexity has gotten to a point where that is impractical. Even if the growth in area could be mostly memory the design time would go from 8 years to 16.
And if it takes you 16 years to do a chip, it would only be obsolete by 14 years.
I upgraded to an i7-4770 and found that there were a couple of things that needed drivers present in newer versions of Fedora. I was running Fedora 15 on an i5-2910 and it was happy. The new IGP 4600 wasn't fully supported.
I really have to wonder if 20 cores (40 threads) could really be used effectively by his program. The mucho RAM I totally back, but $2k CPUs is a little much, without a known performance metric.
I have done a number of 36hr benders in my time, so make sure Chip takes some time out to recover. I know when you are onto something great, it is hard to put it down.
Now, for some further thoughts...
One of the big delays and costs is the Synthesis section. This has already been done for the TSMC process and we know there is a problem with the reset area.
Since (Beau) has control of the outer I/O area, could the reset problem be fixed simply within the I/O area by Beau, and a die set be done by TSMC? I know this would mean an extra step to finalising the P2, but might this be a cheaper way to verify things already done? Meanwhile we could be testing the new FPGA/Verilog code without the need to re-Synthesise until the basics have been verified?
Could the I/O be further modified by removing some of the I/O so that some testing ffs could be inserted there to bring out some of the internal connection signals to the Synthesis area.
To summarise, can you reduce your expenditure to prove the majority is working in a shorter timeline, even if it means slightly longer overall times and increased cost, rather than find another problem after the full respin and expenditure has been done?
Using an SSD for swap was a good idea; now the next easy performance boost would be to max out the ram capability of your machine - if you can run 6GB, you can run 8GB. Then add a second SSD for /tmp.
Of course building a new kick-*** machine beside it to eventually take over would also help. It's pretty easy to make a 6 core / 12 thread socket 2011 machine with 32GB of ram (64GB on some motherboards)
I don't like to ask for freebees. So, let's put a price tag on those add-on boards that I can live with:)
The Prop2 exists... it just isn't in its final form. Tonight, I was at the Micro Center in Westmont Il. I don't think they are ready for the Prop2:)
Rich
About sleeplessness... I had irradiation to my brain stem as a side effect of treating metastatic squamous cell carcinoma in my neck... I mention this because after the radiation I had of narcolepsy.
I simply couldn't wake up. Something in my brainstem had been damaged. I was placed on Provigil... which worked like a charm. Except that when I was traveling in Amsterdam, I suddenly went sleepless.
My brain stem suddenly recovered to the point that I no longer needed the Provigil. I understood this, but as an experiment, I decided to continue the Provigil anyway.
On the 11th day, I was absolutely convinced that I should walk through Amsterdam with my eyes shut, because at a certain location I would be knighted by the Queen of England... it was all very real. Sleep is essential. Sleeplessness is not acceptable.
Rich