Delus, this question made me look in the right place and I see the problem now!
There is a set of flops that all the cogs' OUT and DIR signals pass through. I added those flops to relax timing. All 8 cogs' OUT and DIR signals get OR'd together, then they go through these flops. The output of these flops then go to the actual pins. The thing is, I didn't think to make these flops resettable. That's why the async-cleared pin signals don't show up until after reset and the clock starts toggling. I never noticed this on the FPGA because the main clock was never gated. This means that the chip is getting reset okay - it's just not showing up on the pins immediately.
This can be fixed by modifying our frame circuitry so that the clock is always running during reset. If we resynthesize, we'll change the Verilog to add the resets.
Okay. Reset problem understood. That's not a showstopper, after all.
We still have 44ma quiescent current and possible hold-time and/or memory problems.
Thanks to all you guys for thinking about these issues.
Sounds like you're making progress understanding what went wrong. Is there any chance you can work around these problems and actually run code on this batch of chips or is this just information you can use to avoid the same problems in the next spin?
This can be fixed by modifying our frame circuitry so that the clock is always running during reset. If we resynthesize, we'll change the Verilog to add the resets.
Gating a clock off during reset has Idd advantages ( I've hit some uC where Idd is highest during reset, which can be a pain for low power start-up)
That said, gating any clock is also more dangerous, and you also need to watch out for reset spikes causing runt clock pulses.
( plus you need extreme design care, as seen here, If a clock is gated, you should do that in the FPGA design too )
What is the expected Idd adder for the Startup oscillator ?
Does the reset line have a passive low pass, to ensure impulses under ~ 50ns cannot pass ?
As a preamble statement, in no way i'm a Verilog specialist.
My brain was calibrated in units of nanoseconds using 90 decade's GALs, left untouched since then. I left picosecond units as an inheritance, for my son's brain to bother with.
That being said, recalling from many designs I'd made, that used D FF's, the faster the device I'd used, the more sensitive they were to feedback path hold times, easily showing metastability problems when it turns to synchronous (programm) counters, loadable address generators and the like.
Many times, when things gone worse, I had to use externally gated feedback paths, wasting precious input pins and effectively doubling device counts, as none of the available coding options for the product terms does realy solved my problems.
The last designs made extensive use of non overlapping double rail clock generators, to ensure stable feedback signals between counter stages and gain half a clock cycle in the total function propagation delays.
The greatest advantage I had in those ancient times, beyond their inherent simplicity when compared to the problem Chip and others are now facing, was the fact that the GALs I'd used, does have a consistent known and steady wakeup condition at their outputs after power on, garanteed by design, that helped a lot to stablish initial boundary conditions for circuit's behavior.
Having that previous experience in mind, I'm just wondering if the shortcuts used with TSMC's 180nm rules aware designed feedback paths, meant to attain some speed gain in an inherently slower proccess, when implemented under Freescale's faster constraints optics, does not forces every counter's FF into an almost deterministic metastable behavior.
In my thoughts, in such a scenario, the frenetic switching plaguing almost everything inside the core, including hub and thread sequencing, memory addressing and many other functions, could easily explain the observed erratic behavior and consumed current, because, in fact, there is not an assured steady state at all.
Moreover, despite the fact that RC constants are almost from geometric nature, the ring amplifiers that I'm supposing the oscillator is done with, could easily being tuned into a double switching mode, driven by induced under and overshot spikes.
Those are just the thoughts that can occur to me and my own two cents of contribution.
Glad to hear you found the issue, keep up the awesome work! I think I've seen the idea floated around the forum before but if it's looking like this has a high chance of needing more revisions than the next one you could look into a multi project wafer service like MOSIS for development of your test chips (Though this may require a process switch). This is what we use in academia to bring costs down to something we can stomach (we use CMC here in Canada).
How many pins are being run out to the card edge on the planned breakout board? I forget. Anyhow, if it means that there will be several unused pins, maybe Beau could rerun those pins as test points. That way, if the next version still doesn't work, those test points would potentially be helpful. And if it does work, Parallax could make a limited release of the test version on the existing breakout board. Frankly, I'd be thrilled to get my hands on one that has even fewer available pins than currently planned. If I have only half (32 or 48, maybe?) of the pins to start with, that would still be great.
I was wondering when the next batch of test chips will arrive.
Thanks,
Devin
Hello Devin - it could be a while yet. Taking a guess only gets us in trouble, but I'll do it anyway. And this post will be dated by the time I'm done writing it.
Propeller 2 improvements in VHDL: 3-5 weeks
Synthesis of die core: 10 weeks
Integration of I/O frame with core, plus schematic vs layout verifications: 4 weeks
Fabrication: 16 weeks
Packaging: 2 weeks
Total: ~ 34 weeks
Chip could refine this schedule, but both of us know better by now.
We're R&D-driven by this project. This means the next test chip will be here when it is ready to be here.
That's my mantra: embrace the tangible today; the hypothetical, when it becomes real. I'll get up to speed on the Prop 2, when there is a Prop 2. (Until then, there's still PropCAM documentation to finish: i.e. making the hypothetical tangible. )
Hello Devin - it could be a while yet. Taking a guess only gets us in trouble, but I'll do it anyway. And this post will be dated by the time I'm done writing it.
Propeller 2 improvements in VHDL: 3-5 weeks
Synthesis of die core: 10 weeks
Integration of I/O frame with core, plus schematic vs layout verifications: 4 weeks
Fabrication: 16 weeks
Packaging: 2 weeks
Total: ~ 34 weeks
Chip could refine this schedule, but both of us know better by now.
We're R&D-driven by this project. This means the next test chip will be here when it is ready to be here.
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.
Hopefully my DE2 arrives at the end of the week!
Upgrading from my 1 Cog DE0 to a 5 Cog DE2 is the next best thing to Christmas for me!
You're getting a DE2-115? That's great! Congratulations! I'm sure we'll see some really exciting stuff from you. You certainly did amazing things with the DE0-Nano!
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.
The current estimate for synthesis is six weeks though Chip thinks it can be completed in two. I know from prior experience it usually takes 2-3x longer than expected because the synthesis process uncovers changes in VHDL that further optimize performance or features. So I guessed ten weeks.
Fabrication is usually promised by the foundry at 12 weeks by their sales people. The talk around a conference room table is always different than the reality. There will be forms to complete, purchase order terms to negotiate, timing of payments, and then we actually start waiting. If you include this in the total completion to foundry time then I think it's usually over 12 weeks, so I guessed 16 weeks. That's probably on the long side.
Sapieha pointed out that it is also important that VHDL changes are tested by our customers holding DE2-115 boards. I agree with this, and that time was also not built in. However, it is probably a concurrent effort that runs parallel with Beau's LVS checks. Chip hasn't mentioned much in this regard and I didn't ask him but I'm sure he'll share new cores as they are available. Yesterday when I spoke with him he had been awake for 24 hours already, and when I called at 8:00 am he had been asleep for an hour. We spoke later in the day and he had made some optimization to the serial routines that got him really excited. Then I very briefly bored him with some business details.
Infrequently on the forums we discuss the financial side of another foundry run. Expense is also significant as we enter our 8th year of R&D on this product. Parallax doesn't enter big financial commitments on credit, at least we don't want to use it very much. We have to generate the profit from sales. A conservative estimate of the next round of R&D and Propeller 2 fabrication according to the schedule I suggested above is around $250,000 (salaries, consultants, foundry, packaging, test hardware, etc.). I'm hoping it will be sooner than I guessed, obviously.
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!
That's my mantra: embrace the tangible today; the hypothetical, when it becomes real. I'll get up to speed on the Prop 2, when there is a Prop 2.
-Phil
We spoke later in the day and he had made some optimization to the serial routines that got him really excited. Then I very briefly bored him with some business details.
Ken, thanks for sharing. I really appreciate the perspective. I'm sure many others do too.
Yeah, we can be running stuff while the synthesis is going on. It is likely Chip will build cores as soon as he sleeps and gets changes sorted.
I'm always nervous over the time period, expectations and the need to survive to get there. Thanks again for sharing with us. Lots of people are pulling for you in the hopes this run comes out right. I have good feelings about the product though. It is a winner IMHO. Just gotta get it done.
I'm not sure what changes Chip has made to the serial (Yet) , but a (SERDES) SERializer DESerializer can be implemented quite effectively in software. The question then becomes how fast of a SERDES do you need to prevent bottle-necking in your design?
I'd say any rate one of the internals counter can be set to. It's really just a port-bit accessible shift register.
Now, it would get a little more complicated if one could also turn it into a 32 bit (cascadable?) LFSR..... great for pseudo nose sequences. But that to me is secondary to just a simple SERDES.
Comments
Gating a clock off during reset has Idd advantages ( I've hit some uC where Idd is highest during reset, which can be a pain for low power start-up)
That said, gating any clock is also more dangerous, and you also need to watch out for reset spikes causing runt clock pulses.
( plus you need extreme design care, as seen here, If a clock is gated, you should do that in the FPGA design too )
What is the expected Idd adder for the Startup oscillator ?
Does the reset line have a passive low pass, to ensure impulses under ~ 50ns cannot pass ?
How does that vary with time, temperature and Vdd ?
My brain was calibrated in units of nanoseconds using 90 decade's GALs, left untouched since then. I left picosecond units as an inheritance, for my son's brain to bother with.
That being said, recalling from many designs I'd made, that used D FF's, the faster the device I'd used, the more sensitive they were to feedback path hold times, easily showing metastability problems when it turns to synchronous (programm) counters, loadable address generators and the like.
Many times, when things gone worse, I had to use externally gated feedback paths, wasting precious input pins and effectively doubling device counts, as none of the available coding options for the product terms does realy solved my problems.
The last designs made extensive use of non overlapping double rail clock generators, to ensure stable feedback signals between counter stages and gain half a clock cycle in the total function propagation delays.
The greatest advantage I had in those ancient times, beyond their inherent simplicity when compared to the problem Chip and others are now facing, was the fact that the GALs I'd used, does have a consistent known and steady wakeup condition at their outputs after power on, garanteed by design, that helped a lot to stablish initial boundary conditions for circuit's behavior.
Having that previous experience in mind, I'm just wondering if the shortcuts used with TSMC's 180nm rules aware designed feedback paths, meant to attain some speed gain in an inherently slower proccess, when implemented under Freescale's faster constraints optics, does not forces every counter's FF into an almost deterministic metastable behavior.
In my thoughts, in such a scenario, the frenetic switching plaguing almost everything inside the core, including hub and thread sequencing, memory addressing and many other functions, could easily explain the observed erratic behavior and consumed current, because, in fact, there is not an assured steady state at all.
Moreover, despite the fact that RC constants are almost from geometric nature, the ring amplifiers that I'm supposing the oscillator is done with, could easily being tuned into a double switching mode, driven by induced under and overshot spikes.
Those are just the thoughts that can occur to me and my own two cents of contribution.
Yanomani
1) What is the expected current draw for the Prop. 2 chip when "Asleep" (i.e., mostly waiting) and when running full blast.
2) This also poses the next question - is there a Sleep (low current) type mode in Prop. 2, while the COGS are waiting to do something ?
Thanks in advance - - -
Welcome to the forums!
Unless you what to read through the 2500+ posts here,
http://www.parallaxsemiconductor.com/Products/propeller2specs
I was wondering when the next batch of test chips will arrive.
Thanks,
Devin
Hello Devin - it could be a while yet. Taking a guess only gets us in trouble, but I'll do it anyway. And this post will be dated by the time I'm done writing it.
Propeller 2 improvements in VHDL: 3-5 weeks
Synthesis of die core: 10 weeks
Integration of I/O frame with core, plus schematic vs layout verifications: 4 weeks
Fabrication: 16 weeks
Packaging: 2 weeks
Total: ~ 34 weeks
Chip could refine this schedule, but both of us know better by now.
We're R&D-driven by this project. This means the next test chip will be here when it is ready to be here.
In the meantime, design around Propeller 1!
Did you manage to eke out more test coverage from the current devices ?
This sounds like more than just fixes are being done ?
Propeller 2 improvements in VHDL: 3-5 weeks
.. and users can use Propeller 1 + CPLD, if they need more speed in the IO/Peripherals.
The Lattice MachXO2 pairs well, and the MachXO3 may extend more, but the announcement of MachXO3 seems to have crashed Lattice's web site
1mA....
http://forums.parallax.com/showthread.php/145968-Propeller-2-core-current-draw-(1.8v)?highlight=current+draw
-Phil
Can You ad after that 3-5 weeks test's on FPGA' after Chip generate new Set-up for us.
So we can extensively test that improvements?
That can spare Chip some problems IF anything is broken
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.
If anyone wants to play on the on ramp to Awesome, there's always the DE0 Nano and the DE112!
Edit: I certainly must have meant a DE2-112 - obviously, not having one, I don't know a DE2 from my elbow.
Luckily a kind sole sent me a DE0 Nano so that, and a tube of DIP Props, will see me through the long dark winter ahead.
Hopefully my DE2 arrives at the end of the week!
Upgrading from my 1 Cog DE0 to a 5 Cog DE2 is the next best thing to Christmas for me!
That's a good one Rick!
C.W.
The current estimate for synthesis is six weeks though Chip thinks it can be completed in two. I know from prior experience it usually takes 2-3x longer than expected because the synthesis process uncovers changes in VHDL that further optimize performance or features. So I guessed ten weeks.
Fabrication is usually promised by the foundry at 12 weeks by their sales people. The talk around a conference room table is always different than the reality. There will be forms to complete, purchase order terms to negotiate, timing of payments, and then we actually start waiting. If you include this in the total completion to foundry time then I think it's usually over 12 weeks, so I guessed 16 weeks. That's probably on the long side.
Sapieha pointed out that it is also important that VHDL changes are tested by our customers holding DE2-115 boards. I agree with this, and that time was also not built in. However, it is probably a concurrent effort that runs parallel with Beau's LVS checks. Chip hasn't mentioned much in this regard and I didn't ask him but I'm sure he'll share new cores as they are available. Yesterday when I spoke with him he had been awake for 24 hours already, and when I called at 8:00 am he had been asleep for an hour. We spoke later in the day and he had made some optimization to the serial routines that got him really excited. Then I very briefly bored him with some business details.
Infrequently on the forums we discuss the financial side of another foundry run. Expense is also significant as we enter our 8th year of R&D on this product. Parallax doesn't enter big financial commitments on credit, at least we don't want to use it very much. We have to generate the profit from sales. A conservative estimate of the next round of R&D and Propeller 2 fabrication according to the schedule I suggested above is around $250,000 (salaries, consultants, foundry, packaging, test hardware, etc.). I'm hoping it will be sooner than I guessed, obviously.
SERDES is probably too risky at this point ;-)
Yeah, we can be running stuff while the synthesis is going on. It is likely Chip will build cores as soon as he sleeps and gets changes sorted.
I'm always nervous over the time period, expectations and the need to survive to get there. Thanks again for sharing with us. Lots of people are pulling for you in the hopes this run comes out right. I have good feelings about the product though. It is a winner IMHO. Just gotta get it done.
I'm not sure what changes Chip has made to the serial (Yet) , but a (SERDES) SERializer DESerializer can be implemented quite effectively in software. The question then becomes how fast of a SERDES do you need to prevent bottle-necking in your design?
I'm with Jazzed.
I'd say any rate one of the internals counter can be set to. It's really just a port-bit accessible shift register.
Now, it would get a little more complicated if one could also turn it into a 32 bit (cascadable?) LFSR..... great for pseudo nose sequences. But that to me is secondary to just a simple SERDES.
Cheers,
Peter (pjv)