2) In the Verilog code, I handled the reset signal as:
always @(posedge clk or negedge res_n)
if (!res_n)
q <= 1'b0;
else
q <= d;
I've read from a few sources that this is how to generate a D flip-flop with an asynchronous 'clear' input. It turns out that this is behaving from power-up such that there is no clear, since res_n is low, as power rises, causing no negative edge event, and clk is still the whole time. This problem is apparent by the I/O pins not going high-z until clk begins cycling while internal res_n is still low, but after the RESn pin is raised. This is a headache, but not a showstopper. I need to figure out how to recode these flip-flops so that we wind up with a truly asynchronous reset, not one that must be practically correlated with clk.
There should be some low level logic report you can read, to verify just how it really did the Async reset.
The negative edge is notional, and should simply enable that block, which then applies the ~reset.
How many registers have this Async reset ?
Purist reset design should also look at reset release, not just Async assert.
Async Assert always wins, but usually a Sync'd release is done, as you do not want some registers seeing a reset still there, & some seeing it gone.
Usually a design is not too worried about one more clock on reset release, and a clocked release avoid aperture nasties.
1) The chip takes way to much quiescent current: 44mA at 1.8V with no clocking. This indicates a likely short somewhere. Where the boundary of the synthesized block meets our frame, things were a little hairy, and I suspect something got shorted. We could only perform LVS (layout-versus-schematic) tests on our frame, and not the synthesized block, so we couldn't do a whole-chip LVS, which would have caught something like that.
Plotting Idd vs Vdd could give some clues as to where this is.
I would also capture of the Icc with a low-impedance pure resistor, and a good scope, so you can see how much is DC (leakage), and how much is clock edge (C loading), and if any seems to be Clock phase variable. (ideally, there should be none, but stuck-nodes will give clock phase components )
How about testing with some combination of low-value resistors in series with the pins (power, ground, I/O)? Maybe reducing internal currents in one set relative to others (or maybe all of them, not relative) could pull the chip into more normal behavior or provide more information of some sort. I really have no idea how the foregoing would be useful (so no need to ask), and I'm just throwing it out there as a brain-storming thing.
The short check was not visual. I was able to flatten the core and remove all active circuitry within the core, which means only the transistors were removed leaving ONLY metal. From there I was able to do a complete LVS with all of our stuff included. If there was a short of the nature suggested, it would have been caught.
Edit: There were two kinds of short checks that were done with regard to the core.
1) Yes, a visual check was done against the entire chip to make sure that Power and Ground were not shorting. This involves selecting one node or the other (Power or Ground) and making sure that the selected opposite remains un-highlighted. Initially this test was missed in the May tapeout because the Core block was not included. (See Note1 below)
2) The second check involved flattening all of the core cells and removing only Poly and Diffusion (Gate, Source, and Drain) within the Core that makeup a transistor. Assuming that the Core logic passed LVS with the synthesis team, this procedure on our part allowed us to LVS the entire block with reasonable certainty with the Core metal in place that we were not creating a short or other signal problem.
Note1: In Check #1 mentioned above, it was originally done without the Core in place, this is why it was missed during the May tapeout. Poly (Gate material) was causing a short between power and ground within the Core which was removed in step #2 so therefore did not show itself. The over site of not including the Core in Check #1 was my fault and was a poor decision. The difference at the time was the amount of time required for the test.... 7 Hours with the Core present, versus 2 hours with the Core removed.
Note2: The hand-off between the Synthesized block and our circuitry was actually par with industry standard for the most part. We provided all of the signal IO's including Power and Ground which abutted to a Core perimeter that we specified with proper DRC padding. The synthesis team connected all of the signal lines, but failed to connect any of the Power or Ground lines. This procedure was odd, and the Power and Ground should have been part of their script. Since it was not, or since it was missed, I manually traversed the perimeter and connected all of the Power and Ground into the Core. If there were any Problems in connection, then Step #1 and Step #2 would have caught the discrepancy.
Thanks for explaining this, Beau. What if instead of all core inputs being connected to their frame outputs and vice-versa, some core and frame outputs were tied together? They wouldn't have been noticed in the check, since they would appear as opens (due to no transistors). I wonder if something like that is going on.
Does anyone have any idea if ~20 square millimeters of 180nm logic (standard cells + RAMs) should have a quiescent current as high as 44mA? I figured the quiescent current would have been about 1mA. Any experience out there with this kind of thing?
Chip & co: I am truly sorry to hear about these problems. We all really appreciate your honesty and info.
Is it possible, and might it be better, to produce a set of chips with just the core ?
i.e. I mean without the I/O portion and just bring out some of the I/O ring that surrounds the core. I know this means that it would be a 2 step process and therefore would take longer, but it may be better in the long run.
So, what I am suggesting is to take the normal core from the synthesis guys and quickly add simple buffers (just using the core voltages) to some of the I/O. Perhaps you could make some pins fixed outputs and some fixed inputs excepting the SPI and TX/RX pins. It might even be possible to make the die larger and your probes might be usable without having to get the die packaged - might save a few $$ and a week or so.
I am not sure of costing, so here is another suggestion...
When I do pcbs I often do more than one on a panel. Can you do more than one die on a panel? One could be the just the core as I suggested above and the other could be the full blown chip. If the chip worked, you would have some real chips. I know you would be up for a new set of masks for the full production, but they may be cheaper than a complete set (since they would be a subset of what you have).
"What if instead of all core inputs being connected to their frame outputs and vice-versa, some core and frame outputs were tied together?" - I would say unlikely, since I still have all of the LVS label names on my side of the LVS.... if one of the signals went astray and shorted to Power, Ground, or another signal it would also show up on my end with a normal LVS.
There should be some low level logic report you can read, to verify just how it really did the Async reset.
The negative edge is notional, and should simply enable that block, which then applies the ~reset.
How many registers have this Async reset ?
Purist reset design should also look at reset release, not just Async assert.
Async Assert always wins, but usually a Sync'd release is done, as you do not want some registers seeing a reset still there, & some seeing it gone.
Usually a design is not too worried about one more clock on reset release, and a clocked release avoid aperture nasties.
Beau, could you get into that big tarball and see if you can find the data showing which standard-cell flops were used?
I made 'reset' release on the inactive edge of the system clock when it is running at 20MHz, but I need to verify that the same edges were ultimately used in the frame and core flip-flops.
"Beau, could you get into that big tarball and see if you can find the data showing which standard-cell flops were used?" - I need a little more information Chip, which FF's are you referring to? Associated Location? ....What I have is going to follow the naming convention in your Schematic, since the LVSing was a 1:1 correlation.
"Beau, could you get into that big tarball and see if you can find the data showing which standard-cell flops were used?" - I need a little more information Chip, which FF's are you referring to? Associated Location? ....What I have is going to follow the naming convention in your Schematic, since the LVSing was a 1:1 correlation.
Well, what feeds into the synthesized block for reset is 'resn'. Inside the block there are 8 flops named 'sel[7:0]', which were intended to be asynchronously reset by 'resn'. Maybe those could be identified. There should be a reference name (aside from an instance name) which will denote which TSMC standard cell was used to implement those flops with the async reset. John sent me the TSMC doc that covers their cells in detail. We could look it up in there.
Does anyone have any idea if ~20 square millimeters of 180nm logic (standard cells + RAMs) should have a quiescent current as high as 44mA? I figured the quiescent current would have been about 1mA. Any experience out there with this kind of thing?
OnSemi likely have some idea, as they will fab similar areas of Logic already, in the same process ?
44mA certainly sounds high, other possible causes are floating nodes or oscillation.
Oscillation should show up on a GHz bw spectrum analyser, as extras to your 30MHz Boot Osc, and floating nodes can vary with time, and applied fields.
Could you sacrifice 1 I/O pin and make it a factory "TEST" pin.
For example:
When this pin is enabled it makes P0-P7 inputs for clock overrides, etc.
Pins P8-P15 could be forced outputs showing some internal clocks and other stiff?
Just an idea
OnSemi likely have some idea, as they will fab similar areas of Logic already, in the same process ?
44mA certainly sounds high, other possible causes are floating nodes or oscillation.
Oscillation should show up on a GHz bw spectrum analyser, as extras to your 30MHz Boot Osc, and floating nodes can vary with time, and applied fields.
Good idea. I'll talk to them on Monday and see if 44mA sounds excessive.
I'll get a pure resistor and feed 1.8V power through it and observe chip-side noise.
Could you sacrifice 1 I/O pin and make it a factory "TEST" pin.
For example:
When this pin is enabled it makes P0-P7 inputs for clock overrides, etc.
Pins P8-P15 could be forced outputs showing some internal clocks and other stiff?
Just an idea
Brian
The trouble is, there are so many things that could be wrong that you're not likely to guess what they are, beforehand.
Ken and I just talked and we figured we need to sit on this for a few days, and let thoughts distill a bit, before deciding what route we take next.
Traversing the "RESn" signal (Green) in the image, I traced it to only one of several buffers... ( CLKBUFX3ZZ --> BUFX12 --> ) The BUFFX12 drove five D-FF's and an additional 1X Buffer (<-- All of those nets in Pink) ... See attached image
Ken and I just talked and we figured we need to sit on this for a few days, and let thoughts distill a bit, before deciding what route we take next.
Chip & Co. It is no secret that we were all cheering for your success and a new chip on Friday but that wasnt to be. This is a good time for all of us to remember that weve had many holds and many delays in other highly technical endeavors too. Even as weve had to wait on NASA through the years.
Your dedication to resolving the problems with the new P2 is unquestionable, but tomorrow is a day of rest. I hope that youll take full advantage of it.
You write You will test Core with lower Voltages.
My question are If You not need at same time even run I/O's at lover Voltage so even that match production technology diferences
Dave and I spent time today going over the Prop2 chips some more. We tried running at lower voltages and with high and low temperatures, to no avail.
There are at least three certain problems, it seems:
1) The chip takes way to much quiescent current: 44mA at 1.8V with no clocking. This indicates a likely short somewhere. Where the boundary of the synthesized block meets our frame, things were a little hairy, and I suspect something got shorted. We could only perform LVS (layout-versus-schematic) tests on our frame, and not the synthesized block, so we couldn't do a whole-chip LVS, which would have caught something like that.
2) In the Verilog code, I handled the reset signal as:
always @(posedge clk or negedge res_n)
if (!res_n)
q <= 1'b0;
else
q <= d;
I've read from a few sources that this is how to generate a D flip-flop with an asynchronous 'clear' input. It turns out that this is behaving from power-up such that there is no clear, since res_n is low, as power rises, causing no negative edge event, and clk is still the whole time. This problem is apparent by the I/O pins not going high-z until clk begins cycling while internal res_n is still low, but after the RESn pin is raised. This is a headache, but not a showstopper. I need to figure out how to recode these flip-flops so that we wind up with a truly asynchronous reset, not one that must be practically correlated with clk.
3) Cog0 seems to launch, and executes part of the booter program from hub ROM, but it acts erratically. I don't know if this is due to hold-time issues resulting from a process change, or perhaps our memories are not working as designed, due to the process change.
I think the way forward is to resynthesize (we really need asynchronous reset behavior) using OnSemi's cells, since OnSemi is going to be a lot less expensive than TSMC, going forward, and their turn-around is quicker. This is probably going to take $100k and 4 months to get straightened out. What a bummer!
Well, is there any way to do the synthesis and get a better verification, or perhaps just operate on more conservative boundaries? If it were me at this stage, I think I would go back and revisit all the basics given this process and vendor. Perhaps there are some answers there, or at the least some assumptions that can be reduced to certainty. Maybe their cells result in a more compact or manageable geometry. Is this lack of full basic verification a synthesis process or cost problem or both?
And this may mean exactly nothing, but did you guys notice the odd bits of color mixed in some COGS and not others in that pie shaped bitmap we saw? The bright blue bits stuck out as being odd. Maybe it was the same for all COGS, but maybe not. Just putting that out there as an observation I've not seen comment on. Hoping that's just me and that's the reason it's not commented on! I've wanted to comment on it before and never did.
Well, I suppose a lot of us could ramble on about a lot of things. I toyed with not posting this at all. I will though, and take a day or days and reset. Get feeling good and fresh and only then continue. You guys are sharp and you have a lot of friends who are thinking good thoughts and who would help, if they could, to see you get it done. Maybe the best help is to simply say, "I believe" and leave it there. I do actually. This is gonna get done and it's gonna be great.
Since the best guesses at this point are that all the problems are related to the synthesis from OnSemi not matching the TSMC process, would it make sense to pull OnSemi in to the synthesis pipeline so that engineers that know their process and pipeline can verify the design before it's taped out?
Chip,
I am no expert, but I think it's entirely possible that the synthesis used for the TSMC process could cause the OnSemi process to 'leak' more current because the transistors switching might overlap, since the synthesis is utilising the process delays. Perhaps the guys from the systhesis or OnSemi may be able to answer this for you. Hopefully you have been chasing problems that could just be due to the different process.
I think the way forward is to resynthesize (we really need asynchronous reset behavior) using OnSemi's cells, since OnSemi is going to be a lot less expensive than TSMC, going forward, and their turn-around is quicker. This is probably going to take $100k and 4 months to get straightened out. What a bummer!
I hate to ask this but doesn't a switch to OnSemi mean a higher per-chip cost to customers? Or would you switch back to TSMC once you have the test chips working? Wouldn't that switch back also require another resynthesis?
I have been watching the thread since Friday...thank you for all the info...too bad the results were not as positive. More synthesis...sounds like a step back, but that could be a good thing. Maybe the leap between the p1 to p2 is too large...maybe the p2 project could be scaled down a little bit. Just increasing the pins, hub memory, and speed would probably satisfy most needs. Those are the three items that i looked forward to on the p2. If the p2 could run at 160mhz, 126k hub memory, and 64 or more pins would be a great step forward. Then the p3 could build on that design. Just my two cents
We haven't done a 180 nm chip for a number of years, the cheaper ones use 150 these days. But 44 mA is VERY excessive for a chip in reset. Even with lots of RAMs all powered up but not clocking the current draw should be well under 1mA. Often times the to get to a low power state the CPU actually has to wake up and then turn stuff off, kind of a chicken and egg problem. After those are shut down the quiescent currents drop below 1 uA.
Can you do any post synthesis simulations? Admittedly we would not hold up a silicon spin 6-7 years ago to do one, as the tools were not up to it, or at least our ability to make sense out of it. Now we routinely run the entire simulation suite post synthesis, takes a couple days of 8-10 CPUs time.
I hate to ask this but doesn't a switch to OnSemi mean a higher per-chip cost to customers? Or would you switch back to TSMC once you have the test chips working? Wouldn't that switch back also require another resynthesis?
Hello David,
We can be transparent about our own business but we also have to be considerate to arrangements with our suppliers and their confidentiality. But since this issue was already brought up and discussed I might as well make the details correct. TSMC has a lower unit cost and a higher startup cost; OnSemi has a higher unit cost and a lower startup cost.
To make the chip business viable for Parallax, we must have a lower unit cost for the medium to long-term. The difference in startup cost is amortized over a small number of chips (perhaps equal to a portion of our monthly revenue). A lower startup cost is nice for shuttles and test chips, but to truly recover our R&D investment we need a lower unit cost.
Would a domestic fab run make the chip more expensive to our customers? Yes, or if we sold a OnSemi chip at the same cost as a TSMC chip it would just lower Parallax gross profit (gross profit is the difference between a sale price and our unit cost - so it's not really "profit" at all as it is diminished to nothing by the time operating costs are covered - never mind recovering prior R&D investments).
Our current Propeller volume customers are in the 1-10K unit range. Their products tend to be more expensive [i.e., machines, terminals, equipment, control systems], often much greater than $500 and not in the competitive consumer electronics area. If this market holds true for P2 then I'll suggest a fairly high-priced chip no matter where it is fabricated.
The current design could go to TSMC, as that is how it was targeted, but the confidence level must be higher that it'll run as designed.
Dave and I spent time today going over the Prop2 chips some more. We tried running at lower voltages and with high and low temperatures, to no avail.
There are at least three certain problems, it seems:
1) The chip takes way to much quiescent current: 44mA at 1.8V with no clocking. This indicates a likely short somewhere. Where the boundary of the synthesized block meets our frame, things were a little hairy, and I suspect something got shorted. We could only perform LVS (layout-versus-schematic) tests on our frame, and not the synthesized block, so we couldn't do a whole-chip LVS, which would have caught something like that.
2) In the Verilog code, I handled the reset signal as:
always @(posedge clk or negedge res_n)
if (!res_n)
q <= 1'b0;
else
q <= d;
I've read from a few sources that this is how to generate a D flip-flop with an asynchronous 'clear' input. It turns out that this is behaving from power-up such that there is no clear, since res_n is low, as power rises, causing no negative edge event, and clk is still the whole time. This problem is apparent by the I/O pins not going high-z until clk begins cycling while internal res_n is still low, but after the RESn pin is raised. This is a headache, but not a showstopper. I need to figure out how to recode these flip-flops so that we wind up with a truly asynchronous reset, not one that must be practically correlated with clk.
3) Cog0 seems to launch, and executes part of the booter program from hub ROM, but it acts erratically. I don't know if this is due to hold-time issues resulting from a process change, or perhaps our memories are not working as designed, due to the process change.
I think the way forward is to resynthesize (we really need asynchronous reset behavior) using OnSemi's cells, since OnSemi is going to be a lot less expensive than TSMC, going forward, and their turn-around is quicker. This is probably going to take $100k and 4 months to get straightened out. What a bummer!
That verilog code should be fine. You might want to look at the reset related papers here to see if they stimulate thought. http://www.sunburst-design.com/papers/
I have been watching the thread since Friday...thank you for all the info...too bad the results were not as positive. More synthesis...sounds like a step back, but that could be a good thing. Maybe the leap between the p1 to p2 is too large...maybe the p2 project could be scaled down a little bit. Just increasing the pins, hub memory, and speed would probably satisfy most needs. Those are the three items that i looked forward to on the p2. If the p2 could run at 160mhz, 126k hub memory, and 64 or more pins would be a great step forward. Then the p3 could build on that design. Just my two cents
If we only had a marketing-driven engineering goal, this is pretty close to what I would also suggest. In short a P8X32A with:
- more pins
- more RAM
- faster speed
- code protect
- ability to download C kernel or Spin interpreter
And then more small design iterations with the next most-commonly requested features. As you pointed out, we're taking a much larger step than this.
Being able to synthesis the whole chip (blob+I/O frame with analog) would provide a tremendous benefit as well.
There are still many P8X32A products to be designed and our FAEs are open for business! In fact, you'll see a new KickStarter project launched this week. Build your products with Propeller 1s.
If we only had a marketing-driven engineering goal, this is pretty close to what I would also suggest. In short a P8X32A with:
- more pins
- more RAM
- faster speed
- code protect
- ability to download C kernel or Spin interpreter
And then more small design iterations with the next most-commonly requested features.
I'm in total agreement. That is how I've always thought it should be done. I realize this discussion is mostly academic now; but yes, it would make more sense to build the brand, the semi business, the Propeller concept incrementally.
There are still many P8X32A products to be designed and our FAEs are open for business! In fact, you'll see a new KickStarter project launched this week. Build your products with Propeller 1s.
Yep! Prop 1 isn't going anywhere soon and it remains a useful part.
I realize this discussion is mostly academic now; but yes, it would make more sense to build the brand, the semi business, the Propeller concept incrementally.
I also support Chip's plan and realize that his visions are bigger than building business [which would be easier with incremental improvements]. He's always been 7-10 years ahead of anything I could possibly envision. By the time I was doing HPLOT and VPLOT on the Apple 2 to draw simple graphics he was making the Sound Ace. When I started to effectively use the BASIC Stamp the SX was already available, and the Propeller is still new to me though I've done several projects with it. The Propeller 2 is the same - another giant leap. When we're all done and gone, it'll have been a more interesting story the way he's writing it. But the story has to be written by paid authors and publishers, too, backed by a customer base who believes in what we're doing (you).
I may be wrong but... That doesn't stop me from commenting...
- more pins
Wouldn't that require a redesign of the die?
Also, not available as DIP.
- more RAM
Not only a new layout to fit the RAM, but also having to change at least some of the instructions to be able to reach that RAM, thereby tossing SW compatibility out of the window?
Will it require changing Process size?
- faster speed
Speed is king... Or not... I understand that the limiting factor here is the PLL?
Yet another redesign.
- code protect
Well, it's possible to build a code protect system that seems to be working.
I'm not going to ask how long it took to implement the one that's in the Prop2, or if it could be retrofitted to a revised P8X32A.
- ability to download C kernel or Spin interpreter
That one probably requires the least amount of work?
Now, tell me, would the sales of a hypotethical P8X32B be worth the development cost?
The fewer of those changes are implemented, the less people will be wanting it.
And the sales of the P8X32B will probably impact the sale of the P8X32A unless it's priced a lot higher.
Incremental upgrades are only interesting if you're not worried about code compatibility.
One important reason for the success of the BS2 series is that there's very little differences in the code. Some changes in timing-dependent commands because of thee diferent cock speeds, but other than that, the only changes is that new commands have been added. Most 'Stock BS2' programs will run unchanged if uploaded to a BS2p24.
This is because everything is 'hidden' with an interpreted language. On the Propeller, though, the nitty gritty is available through Assembler, and there's a lot of code available that's been written for the P8X32A that would need to be rewritten to run on a 'B' model.
Much better then, when doing a new chip design, to put on the Seven League Boots and give the rest of the industry a swift kick, yell 'try to keep up,' and set off...
Comments
There should be some low level logic report you can read, to verify just how it really did the Async reset.
The negative edge is notional, and should simply enable that block, which then applies the ~reset.
How many registers have this Async reset ?
Purist reset design should also look at reset release, not just Async assert.
Async Assert always wins, but usually a Sync'd release is done, as you do not want some registers seeing a reset still there, & some seeing it gone.
Usually a design is not too worried about one more clock on reset release, and a clocked release avoid aperture nasties.
Plotting Idd vs Vdd could give some clues as to where this is.
I would also capture of the Icc with a low-impedance pure resistor, and a good scope, so you can see how much is DC (leakage), and how much is clock edge (C loading), and if any seems to be Clock phase variable. (ideally, there should be none, but stuck-nodes will give clock phase components )
Thanks for explaining this, Beau. What if instead of all core inputs being connected to their frame outputs and vice-versa, some core and frame outputs were tied together? They wouldn't have been noticed in the check, since they would appear as opens (due to no transistors). I wonder if something like that is going on.
Does anyone have any idea if ~20 square millimeters of 180nm logic (standard cells + RAMs) should have a quiescent current as high as 44mA? I figured the quiescent current would have been about 1mA. Any experience out there with this kind of thing?
Is it possible, and might it be better, to produce a set of chips with just the core ?
i.e. I mean without the I/O portion and just bring out some of the I/O ring that surrounds the core. I know this means that it would be a 2 step process and therefore would take longer, but it may be better in the long run.
So, what I am suggesting is to take the normal core from the synthesis guys and quickly add simple buffers (just using the core voltages) to some of the I/O. Perhaps you could make some pins fixed outputs and some fixed inputs excepting the SPI and TX/RX pins. It might even be possible to make the die larger and your probes might be usable without having to get the die packaged - might save a few $$ and a week or so.
I am not sure of costing, so here is another suggestion...
When I do pcbs I often do more than one on a panel. Can you do more than one die on a panel? One could be the just the core as I suggested above and the other could be the full blown chip. If the chip worked, you would have some real chips. I know you would be up for a new set of masks for the full production, but they may be cheaper than a complete set (since they would be a subset of what you have).
"What if instead of all core inputs being connected to their frame outputs and vice-versa, some core and frame outputs were tied together?" - I would say unlikely, since I still have all of the LVS label names on my side of the LVS.... if one of the signals went astray and shorted to Power, Ground, or another signal it would also show up on my end with a normal LVS.
Beau, could you get into that big tarball and see if you can find the data showing which standard-cell flops were used?
I made 'reset' release on the inactive edge of the system clock when it is running at 20MHz, but I need to verify that the same edges were ultimately used in the frame and core flip-flops.
Well, what feeds into the synthesized block for reset is 'resn'. Inside the block there are 8 flops named 'sel[7:0]', which were intended to be asynchronously reset by 'resn'. Maybe those could be identified. There should be a reference name (aside from an instance name) which will denote which TSMC standard cell was used to implement those flops with the async reset. John sent me the TSMC doc that covers their cells in detail. We could look it up in there.
OnSemi likely have some idea, as they will fab similar areas of Logic already, in the same process ?
44mA certainly sounds high, other possible causes are floating nodes or oscillation.
Oscillation should show up on a GHz bw spectrum analyser, as extras to your 30MHz Boot Osc, and floating nodes can vary with time, and applied fields.
Could you sacrifice 1 I/O pin and make it a factory "TEST" pin.
For example:
When this pin is enabled it makes P0-P7 inputs for clock overrides, etc.
Pins P8-P15 could be forced outputs showing some internal clocks and other stiff?
Just an idea
Brian
Good idea. I'll talk to them on Monday and see if 44mA sounds excessive.
I'll get a pure resistor and feed 1.8V power through it and observe chip-side noise.
The trouble is, there are so many things that could be wrong that you're not likely to guess what they are, beforehand.
Ken and I just talked and we figured we need to sit on this for a few days, and let thoughts distill a bit, before deciding what route we take next.
Traversing the "RESn" signal (Green) in the image, I traced it to only one of several buffers... ( CLKBUFX3ZZ --> BUFX12 --> ) The BUFFX12 drove five D-FF's and an additional 1X Buffer (<-- All of those nets in Pink) ... See attached image
Here is a larger version of the attached image...
https://docs.google.com/file/d/0B0DJmXrvrE-IV19faVpJSVI4MkE/edit?usp=sharing
Chip & Co. It is no secret that we were all cheering for your success and a new chip on Friday but that wasnt to be. This is a good time for all of us to remember that weve had many holds and many delays in other highly technical endeavors too. Even as weve had to wait on NASA through the years.
Your dedication to resolving the problems with the new P2 is unquestionable, but tomorrow is a day of rest. I hope that youll take full advantage of it.
You write You will test Core with lower Voltages.
My question are If You not need at same time even run I/O's at lover Voltage so even that match production technology diferences
Well, is there any way to do the synthesis and get a better verification, or perhaps just operate on more conservative boundaries? If it were me at this stage, I think I would go back and revisit all the basics given this process and vendor. Perhaps there are some answers there, or at the least some assumptions that can be reduced to certainty. Maybe their cells result in a more compact or manageable geometry. Is this lack of full basic verification a synthesis process or cost problem or both?
And this may mean exactly nothing, but did you guys notice the odd bits of color mixed in some COGS and not others in that pie shaped bitmap we saw? The bright blue bits stuck out as being odd. Maybe it was the same for all COGS, but maybe not. Just putting that out there as an observation I've not seen comment on. Hoping that's just me and that's the reason it's not commented on!
Well, I suppose a lot of us could ramble on about a lot of things. I toyed with not posting this at all. I will though, and take a day or days and reset. Get feeling good and fresh and only then continue. You guys are sharp and you have a lot of friends who are thinking good thoughts and who would help, if they could, to see you get it done. Maybe the best help is to simply say, "I believe" and leave it there. I do actually. This is gonna get done and it's gonna be great.
I am no expert, but I think it's entirely possible that the synthesis used for the TSMC process could cause the OnSemi process to 'leak' more current because the transistors switching might overlap, since the synthesis is utilising the process delays. Perhaps the guys from the systhesis or OnSemi may be able to answer this for you. Hopefully you have been chasing problems that could just be due to the different process.
Can you do any post synthesis simulations? Admittedly we would not hold up a silicon spin 6-7 years ago to do one, as the tools were not up to it, or at least our ability to make sense out of it. Now we routinely run the entire simulation suite post synthesis, takes a couple days of 8-10 CPUs time.
Hello David,
We can be transparent about our own business but we also have to be considerate to arrangements with our suppliers and their confidentiality. But since this issue was already brought up and discussed I might as well make the details correct. TSMC has a lower unit cost and a higher startup cost; OnSemi has a higher unit cost and a lower startup cost.
To make the chip business viable for Parallax, we must have a lower unit cost for the medium to long-term. The difference in startup cost is amortized over a small number of chips (perhaps equal to a portion of our monthly revenue). A lower startup cost is nice for shuttles and test chips, but to truly recover our R&D investment we need a lower unit cost.
Would a domestic fab run make the chip more expensive to our customers? Yes, or if we sold a OnSemi chip at the same cost as a TSMC chip it would just lower Parallax gross profit (gross profit is the difference between a sale price and our unit cost - so it's not really "profit" at all as it is diminished to nothing by the time operating costs are covered - never mind recovering prior R&D investments).
Our current Propeller volume customers are in the 1-10K unit range. Their products tend to be more expensive [i.e., machines, terminals, equipment, control systems], often much greater than $500 and not in the competitive consumer electronics area. If this market holds true for P2 then I'll suggest a fairly high-priced chip no matter where it is fabricated.
The current design could go to TSMC, as that is how it was targeted, but the confidence level must be higher that it'll run as designed.
That verilog code should be fine. You might want to look at the reset related papers here to see if they stimulate thought. http://www.sunburst-design.com/papers/
If we only had a marketing-driven engineering goal, this is pretty close to what I would also suggest. In short a P8X32A with:
- more pins
- more RAM
- faster speed
- code protect
- ability to download C kernel or Spin interpreter
And then more small design iterations with the next most-commonly requested features. As you pointed out, we're taking a much larger step than this.
Being able to synthesis the whole chip (blob+I/O frame with analog) would provide a tremendous benefit as well.
There are still many P8X32A products to be designed and our FAEs are open for business! In fact, you'll see a new KickStarter project launched this week. Build your products with Propeller 1s.
Yep!
I also support Chip's plan and realize that his visions are bigger than building business [which would be easier with incremental improvements]. He's always been 7-10 years ahead of anything I could possibly envision. By the time I was doing HPLOT and VPLOT on the Apple 2 to draw simple graphics he was making the Sound Ace. When I started to effectively use the BASIC Stamp the SX was already available, and the Propeller is still new to me though I've done several projects with it. The Propeller 2 is the same - another giant leap. When we're all done and gone, it'll have been a more interesting story the way he's writing it. But the story has to be written by paid authors and publishers, too, backed by a customer base who believes in what we're doing (you).
Wouldn't that require a redesign of the die?
Also, not available as DIP. Not only a new layout to fit the RAM, but also having to change at least some of the instructions to be able to reach that RAM, thereby tossing SW compatibility out of the window?
Will it require changing Process size? Speed is king... Or not... I understand that the limiting factor here is the PLL?
Yet another redesign. Well, it's possible to build a code protect system that seems to be working.
I'm not going to ask how long it took to implement the one that's in the Prop2, or if it could be retrofitted to a revised P8X32A. That one probably requires the least amount of work?
Now, tell me, would the sales of a hypotethical P8X32B be worth the development cost?
The fewer of those changes are implemented, the less people will be wanting it.
And the sales of the P8X32B will probably impact the sale of the P8X32A unless it's priced a lot higher.
Incremental upgrades are only interesting if you're not worried about code compatibility.
One important reason for the success of the BS2 series is that there's very little differences in the code. Some changes in timing-dependent commands because of thee diferent cock speeds, but other than that, the only changes is that new commands have been added. Most 'Stock BS2' programs will run unchanged if uploaded to a BS2p24.
This is because everything is 'hidden' with an interpreted language. On the Propeller, though, the nitty gritty is available through Assembler, and there's a lot of code available that's been written for the P8X32A that would need to be rewritten to run on a 'B' model.
Much better then, when doing a new chip design, to put on the Seven League Boots and give the rest of the industry a swift kick, yell 'try to keep up,' and set off...