The Flash SPI_CS (P89) signal looks correct, which can only mean that it's running the booter program. We are not seeing the Flash SPI_CK (P88) toggling like it's supposed to, though, which doesn't make any sense. Those two phenomena should be inseparable.
Perhaps yield related ?
Is the timing of the CS correct (or is that still on an internal Osc at this stage ?)
Does the booter have other fall-back pathways it moves to at this stage ?
Perhaps yield related ?
Is the timing of the CS correct (or is that still on an internal Osc at this stage ?)
Does the booter have other fall-back pathways it moves to at this stage ?
The timing looks all correct. It seems, though, like the cog is not executing all instructions properly. Certain pins aren't transitioning when they should, even though the proper amount of time elapses for those instructions. We'll try another chip and see what happens. It's hard to imagine that the logic wasn't correctly synthesized.
The Flash SPI_CS (P89) signal looks correct, which can only mean that it's running the booter program. We are not seeing the Flash SPI_CK (P88) toggling like it's supposed to, though, which doesn't make any sense. Those two phenomena should be inseparable.
I'm a bit late to the party but congratulations on seeing signs of life! You guys deserve a win after all of the work you've put into this!
Dave is hooking up another chip now. I'm wondering if maybe the problem is that I made the timing too aggressive on the memories, so that there's insufficient setup time, so premature data is being captured.
>Certain pins aren't transitioning when they should
Have you guys tried looking at all of the pins in case an error was made during packaging? I imagine so.
Good idea. We did poke around, at first, and that doesn't seem to be the problem. The problem is that an instruction will execute to toggle a pin one way, and then another way, and one of those instructions doesn't seem to execute, though it's time is taken.
The Flash SPI_CS (P89) signal looks correct, which can only mean that it's running the booter program. We are not seeing the Flash SPI_CK (P88) toggling like it's supposed to, though, which doesn't make any sense. Those two phenomena should be inseparable.
The internal RC oscillator seems to be running at 36MHz. It was designed to run at 20MHz with a low-power 180nm process. This is a fast 180nm process, so everything's hotter. I wonder if process difference could be causing us any trouble.
Hi Chip,
Is there any possibility of RCFAST mode not properly working, so the intenal frequency after power on reset is being self tuned well beyond the intended 20.0 MHz design center range?
The above part was answered by your previous post, during the time I was composing mine.
Does any proccess variations, during chip fab, can account for any bad trimming or RCFAST component misbehavior?
If there is any possibility of the above situation being manifested, could you manage to slightly variate the core voltage supply, in order to slow down the frequency generation, or, in the upper direction, to speed up internal (rom like) ram access time?
You could try a can of freeze spray and see how much it reduces the 36 MHz by
How do you know it's 36 MHz? Is it visible on a cro somehow, or are you deducing that from the startup timing of the SPI select line?
Is there any hint of that 36 MHz (or divided clock) on the SPI CK pin, that you could amplify and lock onto, perhaps simulating an external flash using a DE0 or similar (that could dump boot code at up to 60 MHz).
Does a light resistive load on the SPI CK pin reveal any change?
The internal RC oscillator seems to be running at 36MHz. It was designed to run at 20MHz with a low-power 180nm process. This is a fast 180nm process, so everything's hotter. I wonder if process difference could be causing us any trouble.
If that does not yet feed any PLL, you should still be ok ?
Any Sim you did, should have used the faster process ? - of course, if those faster models said 20Mhz and you measure 36MHz, maybe sim is not that accurate.
What SPI clock would that 36MHz generate ? (if the clock were appearing)
Good idea. We did poke around, at first, and that doesn't seem to be the problem. The problem is that an instruction will execute to toggle a pin one way, and then another way, and one of those instructions doesn't seem to execute, though it's time is taken.
hmm... Assuming the core logic is ok, maybe this could be either the ROM is not correct (so a different opcode is executed), or a pathway bug in the IO area.
I talked to John in Wisconsin who did our synthesis work. I wish I would have talked to him earlier.
By taking that block of standard cells that was synthesized for a high-Vt low-power process and fab'ing in a low-Vt high-speed process, we wound up with oodles of hold-time violations. Hold-time violations have nothing to do with frequency, but with data not remaining stable through the clock edge, effectively skipping what was supposed to be the next state. Chips with hold-time problems won't even work at 1Hz. Setup-time violations, on the other hand, have to do with data not being ready before the clock edge, and occur when some maximum frequency is exceeded. This fab process is so much faster than the one that we targeted the synthesized block for, that our internal RC oscillator is running 80% faster than it was supposed to in the low-power process. No wonder those timing paths that were padded with slower buffers to avoid hold-time problems are now no longer working!
We may be able to get some useful verification done with this new chip, though. By running it at a lower voltage, we can effectively return to a higher-Vt (higher threshold voltage, slower, cooler) process. This might bring the current hold-time-violating paths into compliance. As Dave lowered the voltage on the test setup, he was getting more sensible behavior on the scope. He got down to 1.49V and it failed - but because the brown-out reset was enabled, which is designed to trip at 1.5V. Tomorrow he will disable the brown-out reset and we'll run that thing as low as we can go and perhaps we'll get sensible-enough behavior to see if the monitor works, etc. Maybe we'll even have a Prop2 that runs at 1.1V, or so. The I/O's can run at 3.3V, no problem, as there are no such timing considerations in our own circuitry.
Comments
How much life is the important question..
The issue is always how large is the errata going to be, and are there any drop-dead issues ?
Greatest message of this day! The Propeller is spinning
Perhaps yield related ?
Is the timing of the CS correct (or is that still on an internal Osc at this stage ?)
Does the booter have other fall-back pathways it moves to at this stage ?
The timing looks all correct. It seems, though, like the cog is not executing all instructions properly. Certain pins aren't transitioning when they should, even though the proper amount of time elapses for those instructions. We'll try another chip and see what happens. It's hard to imagine that the logic wasn't correctly synthesized.
Have you guys tried looking at all of the pins in case an error was made during packaging? I imagine so.
Edited to add: and you might see about getting the WAT data just so you know where your process is.
Good idea. We did poke around, at first, and that doesn't seem to be the problem. The problem is that an instruction will execute to toggle a pin one way, and then another way, and one of those instructions doesn't seem to execute, though it's time is taken.
Nope. At least, not on the chip we were just playing with. We're hooking up another one now.
Thank you for the stream of updates - much appreciated by one and all...
The internal RC oscillator seems to be running at 36MHz. It was designed to run at 20MHz with a low-power 180nm process. This is a fast 180nm process, so everything's hotter. I wonder if process difference could be causing us any trouble.
Is there any possibility of RCFAST mode not properly working, so the intenal frequency after power on reset is being self tuned well beyond the intended 20.0 MHz design center range?
The above part was answered by your previous post, during the time I was composing mine.
Does any proccess variations, during chip fab, can account for any bad trimming or RCFAST component misbehavior?
If there is any possibility of the above situation being manifested, could you manage to slightly variate the core voltage supply, in order to slow down the frequency generation, or, in the upper direction, to speed up internal (rom like) ram access time?
Yanomani
How do you know it's 36 MHz? Is it visible on a cro somehow, or are you deducing that from the startup timing of the SPI select line?
Is there any hint of that 36 MHz (or divided clock) on the SPI CK pin, that you could amplify and lock onto, perhaps simulating an external flash using a DE0 or similar (that could dump boot code at up to 60 MHz).
Does a light resistive load on the SPI CK pin reveal any change?
If that does not yet feed any PLL, you should still be ok ?
Any Sim you did, should have used the faster process ? - of course, if those faster models said 20Mhz and you measure 36MHz, maybe sim is not that accurate.
What SPI clock would that 36MHz generate ? (if the clock were appearing)
I think the boot runs from RC, until if has loaded enough to do more to the config.
If the loader looks for a length byte early, you could change the SPIDAT pin, H or L to see if the read path is functioning.
How many bytes does the loader expect to shift in ?
hmm... Assuming the core logic is ok, maybe this could be either the ROM is not correct (so a different opcode is executed), or a pathway bug in the IO area.
I talked to John in Wisconsin who did our synthesis work. I wish I would have talked to him earlier.
By taking that block of standard cells that was synthesized for a high-Vt low-power process and fab'ing in a low-Vt high-speed process, we wound up with oodles of hold-time violations. Hold-time violations have nothing to do with frequency, but with data not remaining stable through the clock edge, effectively skipping what was supposed to be the next state. Chips with hold-time problems won't even work at 1Hz. Setup-time violations, on the other hand, have to do with data not being ready before the clock edge, and occur when some maximum frequency is exceeded. This fab process is so much faster than the one that we targeted the synthesized block for, that our internal RC oscillator is running 80% faster than it was supposed to in the low-power process. No wonder those timing paths that were padded with slower buffers to avoid hold-time problems are now no longer working!
We may be able to get some useful verification done with this new chip, though. By running it at a lower voltage, we can effectively return to a higher-Vt (higher threshold voltage, slower, cooler) process. This might bring the current hold-time-violating paths into compliance. As Dave lowered the voltage on the test setup, he was getting more sensible behavior on the scope. He got down to 1.49V and it failed - but because the brown-out reset was enabled, which is designed to trip at 1.5V. Tomorrow he will disable the brown-out reset and we'll run that thing as low as we can go and perhaps we'll get sensible-enough behavior to see if the monitor works, etc. Maybe we'll even have a Prop2 that runs at 1.1V, or so. The I/O's can run at 3.3V, no problem, as there are no such timing considerations in our own circuitry.