Shop OBEX P1 Docs P2 Docs Learn Events
Propeller II update - BLOG - Page 82 — Parallax Forums

Propeller II update - BLOG

17980828485223

Comments

  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2013-09-12 17:47
    Cool! I hope whatever issues you do have are easily remedied.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-09-12 17:49
    It lives! Excellent news.
  • User NameUser Name Posts: 1,451
    edited 2013-09-12 17:49
    What a fascinating juncture in the life of a project!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2013-09-12 17:55
    cgracey wrote: »
    We're seeing signs of life...
    You just need some Fozzie bear faces to match your "current" status. Save this one for the wocka wocka
    th.jpeg
    300 x 225 - 11K
    th.jpeg 10.6K
  • jmgjmg Posts: 15,169
    edited 2013-09-12 17:55
    cgracey wrote: »
    We're seeing signs of life...

    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 ?
  • ozpropdevozpropdev Posts: 2,792
    edited 2013-09-12 17:58
    Heart rate is up!
  • DL7PNPDL7PNP Posts: 18
    edited 2013-09-12 18:02
    cgracey wrote: »
    We're seeing signs of life...

    Greatest message of this day! The Propeller is spinning :smile:
  • jazzedjazzed Posts: 11,803
    edited 2013-09-12 18:05
    Congrats. Now, let's see what this baby can do.
  • jmgjmg Posts: 15,169
    edited 2013-09-12 18:19
    cgracey wrote: »
    We're seeing signs of life...

    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 ?
  • cgraceycgracey Posts: 14,134
    edited 2013-09-12 18:30
    jmg wrote: »
    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.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-09-12 18:30
    cgracey wrote: »
    We're seeing signs of life...

    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!
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2013-09-12 18:32
    It's ALIVE!

    ItsAlive.jpg
    492 x 242 - 55K
  • cgraceycgracey Posts: 14,134
    edited 2013-09-12 18:36
    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.
  • KeithEKeithE Posts: 957
    edited 2013-09-12 18:37
    >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.

    Edited to add: and you might see about getting the WAT data just so you know where your process is.
  • cgraceycgracey Posts: 14,134
    edited 2013-09-12 18:39
    KeithE wrote: »
    >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.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-09-12 18:42
    The $64,000.00 question is... is the monitor coming up?
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 14,134
    edited 2013-09-12 18:44
    The $64,000.00 question is... is the monitor coming up?

    Nope. At least, not on the chip we were just playing with. We're hooking up another one now.
  • cgraceycgracey Posts: 14,134
    edited 2013-09-12 18:49
    The new chip we hooked up doesn't do anything. We'll try another.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-09-12 18:50
    what clock speed are you testing at?
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-09-12 19:00
    Why do I have a feeling a lot of us will be sitting on the edge of our seats until late tonight????

    Thank you for the stream of updates - much appreciated by one and all...
    cgracey wrote: »
    Nope. At least, not on the chip we were just playing with. We're hooking up another one now.
  • cgraceycgracey Posts: 14,134
    edited 2013-09-12 19:16
    potatohead wrote: »
    what clock speed are you testing at?

    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.
  • YanomaniYanomani Posts: 1,524
    edited 2013-09-12 19:35
    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?

    Yanomani
  • localrogerlocalroger Posts: 3,451
    edited 2013-09-12 19:39
    Is there a chance you could try single-stepping it with a slow external clock?
  • TubularTubular Posts: 4,686
    edited 2013-09-12 19:51
    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?
  • jmgjmg Posts: 15,169
    edited 2013-09-12 19:56
    cgracey wrote: »
    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)
  • potatoheadpotatohead Posts: 10,261
    edited 2013-09-12 20:02
    The external clock is where I was headed with that. Run it at ideal spec or slower to see whether or not it changes things.
  • jmgjmg Posts: 15,169
    edited 2013-09-12 20:09
    potatohead wrote: »
    The external clock is where I was headed with that. Run it at ideal spec or slower to see whether or not it changes things.

    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 ?
  • jmgjmg Posts: 15,169
    edited 2013-09-12 20:16
    cgracey wrote: »
    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.
  • photomankcphotomankc Posts: 943
    edited 2013-09-12 20:30
    Man I am crossing my fingers for you guys! I hope there are not 'it's dead jim' show stoppers in there.
  • cgraceycgracey Posts: 14,134
    edited 2013-09-12 20:43
    Okay, Everyone.

    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.
Sign In or Register to comment.