Shop Learn P1 Docs P2 Docs
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 70 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

16768707273160

Comments

  • jmgjmg Posts: 14,950
    garryj wrote: »
    ...Whatever it is appears to lobotomize the USB smart pins, and when it's in this state, neither a code reload or hardware reset via the PB0 button on the Prop123-A9 board prior to reload works.

    Sounds like maybe the reset coverage in the Verilog is not quite enough ? - as well as maybe some invalid state is being reached, to cause this in the first place ?
    Does the smart pin mode reset on a P0 reset ?

  • FYI
    A P2 reset does not initialize the LUT.
    A reload of the FPGA from PX.exe or a power cycle will initialize the LUT.
  • ozpropdev wrote: »
    FYI
    A P2 reset does not initialize the LUT.
    A reload of the FPGA from PX.exe or a power cycle will initialize the LUT.
    It looks like LUT sharing could be it. The host<->driver command slots weren't getting reset at device disconnect or code startup. I'm still scratching my head a bit, though, as these locations are set as write events triggered by the "other" cog, so even if these locations were "dirty" when coming out of reset, they won't get written to until an eventID gets posted, which by then should be one that's legitimate. But I was able to reproduce the same type of issue that I had this morning that needed an FPGA image reload, but this time it worked after reset and code reload. I guess time will tell...

    @ozpropdev to the rescue again :cool:
  • jmgjmg Posts: 14,950
    garryj wrote: »
    It looks like LUT sharing could be it. The host<->driver command slots weren't getting reset at device disconnect or code startup. I'm still scratching my head a bit, though, as these locations are set as write events triggered by the "other" cog, so even if these locations were "dirty" when coming out of reset, they won't get written to until an eventID gets posted, which by then should be one that's legitimate. But I was able to reproduce the same type of issue that I had this morning that needed an FPGA image reload, but this time it worked after reset and code reload. I guess time will tell...

    Is this saying you have a software work-around, that is reliable in all situations, or does this still need a Verilog fix to avoid lock-out situations ?

  • jmg wrote: »
    Is this saying you have a software work-around, that is reliable in all situations, or does this still need a Verilog fix to avoid lock-out situations ?

    I'm not 100% sure about anything, yet. The issue was fairly rare to begin with, and @ozpropdev's comment steered me to examine my LUT use, which did reveal a problem which *could* result in bad behavior that could survive a reset under certain circumstances. I've only had a single event occur since I made the change that *sometimes* in the past has required an FPGA image reload to get things working again, and this time just a reset and code reload cleared things up.

    So for now, my thinking is that it is/was likely a programmer faux pas and not something that might require a Verilog fix.
  • JRetSapDoogJRetSapDoog Posts: 954
    edited 2016-12-06 02:36
    Gotta hate those hard to reproduce problems.
  • jmgjmg Posts: 14,950
    rjo__ wrote: »
    Thank you very much. Yes, RdPin wc gets rid of the akpin!!!

    The initial extra byte is still there. It occurs any time I recompile the P2 code.

    Here is a consecutive list of the extra first values... each collected after a recompile:

    10000000
    11000000
    11111100
    11110000
    00110000
    11111000
    11111111
    11110000
    00110000
    11000000
    11110000
    11100000
    11111111
    11111000

    Altogether I looked at over 20 values and didn't see a 101 pattern, which you would expect if the value was random. The value seen after power cycling the P123 board was variable.

    Is this extra byte TX at start still an issue ?
    Does it change at all with baud rate ?
    (an earlier post mentioned two Baud formula ?)

    What is the timing of the extra Char, relative to reset-exit ?


  • Where is the latest 1-2-3 A9 image? I recall Chip posting it in another thread for @ozpropdev to test, but I can't remember which one....
  • jmg wrote: »

    That's the one I was looking for. Thanks!
  • RaymanRayman Posts: 12,717
    Are the RGB leds connected to a P2V I/O pin?
  • Rayman wrote: »
    Are the RGB leds connected to a P2V I/O pin?
    No.
    BTW I have found testing with P1V images on A7 & A9 has shown some of the RGB led's are faulty anyway.


  • ozpropdev wrote: »
    Rayman wrote: »
    Are the RGB leds connected to a P2V I/O pin?
    No.
    BTW I have found testing with P1V images on A7 & A9 has shown some of the RGB led's are faulty anyway.

    That's too bad. Is this a design flaw in the board? Is there any way to fix the RGB LED's? They are one thing that attracted me to the A9. Of course, they aren't the main reason I bought it but I certainly considered them a plus.

  • RaymanRayman Posts: 12,717
    Ok, if it's not 100%, I can understand why it's not connected.
    Was just thinking about stuff I could play around with in the GUI.
    Still have several green LEDs and some buttons...
  • David Betz wrote: »
    That's too bad. Is this a design flaw in the board? Is there any way to fix the RGB LED's?
    No design flaw in the board just a heat damage issue for the RGB leds.
    Noy surpising considering the large Cyclone V FPGA on the board.
    I replaced my RGB leds's and verified their operation using a P1V image.

  • ozpropdevozpropdev Posts: 2,783
    edited 2016-12-25 22:35
    <deleted>

  • cgraceycgracey Posts: 13,722
    edited 2017-01-07 23:21
    I added in some instructions which affect the OUT bit for a pin, while also setting or clearing the DIR bit. These instructions provide pipeline data forwarding for the OUTA/OUTB data, but not for the DIRA/DIRB data. So, one of these instructions should not be followed by an instruction which reads or writes the same DIRA/DIRB, as it will read old data. This is the price for having atomic pin-setting instructions which write both OUT and DIR registers.

    The first set (FLTx) clear the DIR bit to float the pin (and affect OUT), while the second set (DRVx) set the DIR bit to drive the pin (and affect OUT):
    CCCC 1101011 CZL DDDDDDDDD 001010000   **   FLTL    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001010001   **   FLTH    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001010010   **   FLTC    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001010011   **   FLTNC   D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001010100   **   FLTZ    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001010101   **   FLTNZ   D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001010110   **   FLTN    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001010111   **   FLTIN   D/#         {WC,WZ}
    
    CCCC 1101011 CZL DDDDDDDDD 001011000   **   DRVL    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001011001   **   DRVH    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001011010   **   DRVC    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001011011   **   DRVNC   D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001011100   **   DRVZ    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001011101   **   DRVNZ   D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001011110   **   DRVN    D/#         {WC,WZ}
    CCCC 1101011 CZL DDDDDDDDD 001011111   **   DRVIN   D/#         {WC,WZ}
    

    I'm almost done with the new PLL setup for the clock pins. After that, we are ready to make the chip. Still waiting for word from OnSemi, though, about the nature of their fuses.
  • So FLTL (for instance) clears DIR and sets OUT low? What would this be used for? Also, are the xxxIN variants setting OUT to the value of IN?
  • jmgjmg Posts: 14,950
    cgracey wrote: »
    The first set (FLTx) clear the DIR bit to float the pin (and affect OUT), while the second set (DRVx) set the DIR bit to drive the pin (and affect OUT):
    Drive from float I think I can follow, as that has H/L and C/NC Z/NZ copies to the pin.
    However, when you float a pin, there is only one action, ie the pin floats ?
    What does the H/L and C/NC Z/NZ N/IN variants do here ?

    cgracey wrote: »
    I'm almost done with the new PLL setup for the clock pins. After that, we are ready to make the chip. Still waiting for word from OnSemi, though, about the nature of their fuses.

    Cool. Did a post-VCO divider make it into the Verilog ?

  • cgraceycgracey Posts: 13,722
    Seairth wrote: »
    So FLTL (for instance) clears DIR and sets OUT low? What would this be used for? Also, are the xxxIN variants setting OUT to the value of IN?

    The FLTx instructions are a little weird, in that they bother to set the OUT bit to some state, while clearing the DIR bit, causing the pin to float. This is useful in cases where you want to float the pin, but set it up for output later, so that you don't need to buffer the next output state, just do a DIRH to drive it.

    FLTIN and DRVIN clear and set the DIR bit, respectively, while sampling the IN bit state into C/NZ, as do all the other DIRx/OUTx/FLTx/DRVx instructions.
  • cgraceycgracey Posts: 13,722
    jmg wrote: »
    cgracey wrote: »
    The first set (FLTx) clear the DIR bit to float the pin (and affect OUT), while the second set (DRVx) set the DIR bit to drive the pin (and affect OUT):
    Drive from float I think I can follow, as that has H/L and C/NC Z/NZ copies to the pin.
    However, when you float a pin, there is only one action, ie the pin floats ?
    What does the H/L and C/NC Z/NZ N/IN variants do here ?

    cgracey wrote: »
    I'm almost done with the new PLL setup for the clock pins. After that, we are ready to make the chip. Still waiting for word from OnSemi, though, about the nature of their fuses.

    Cool. Did a post-VCO divider make it into the Verilog ?

    Yes. There's a 6-bit divider for the XI/crystal, a 10-bit divider for the VCO, and a 4-bit post-VCO divider. The only thing that I had to realize was that the change rate for the VCO bias voltage needed to be proportional to the speed of the divided XI/crystal. After understanding that, it was simple. Way simpler than I thought it would be.
  • evanhevanh Posts: 13,348
    cgracey wrote: »
    ... This is the price for having atomic pin-setting instructions which write both OUT and DIR registers.

    Hmm, pondering ... would combining the two functions (DIRx plus OUTx) into one register be okay? Eg:
    Cog address $1FA is DIR[P0:P15];OUT[P0:P15]
    Cog address $1FB is DIR[P16:P31];OUT[P16:P31]
    Cog address $1FC is DIR[P32:P47];OUT[P32:P47]
    Cog address $1FD is DIR[P48:P63];OUT[P48:P63]

    I'm don't know if this limits the Streamer max data width but obviously software bit bashing will be 16-bit data width limited.
  • cgraceycgracey Posts: 13,722
    edited 2017-01-08 05:29
    evanh wrote: »
    cgracey wrote: »
    ... This is the price for having atomic pin-setting instructions which write both OUT and DIR registers.

    Hmm, pondering ... would combining the two functions (DIRx plus OUTx) into one register be okay? Eg:
    Cog address $1FA is DIR[P0:P15];OUT[P0:P15]
    Cog address $1FB is DIR[P16:P31];OUT[P16:P31]
    Cog address $1FC is DIR[P32:P47];OUT[P32:P47]
    Cog address $1FD is DIR[P48:P63];OUT[P48:P63]

    I'm don't know if this limits the Streamer max data width but obviously software bit bashing will be 16-bit data width limited.

    As some tech support caller from GM Truck and Bus said to me 20 years ago, "That's a mighty, mighty SUCCULENT idea."

    I need to think about the ramifications of doing that. It's no problem for the Streamer to handle that arrangement. I just don't know what it practically means for software. I worry it would cause more awkwardness than it would eliminate. It's very interesting, anyway.
  • jmgjmg Posts: 14,950
    evanh wrote: »
    cgracey wrote: »
    ... This is the price for having atomic pin-setting instructions which write both OUT and DIR registers.

    Hmm, pondering ... would combining the two functions (DIRx plus OUTx) into one register be okay? Eg:
    Cog address $1FA is DIR[P0:P15];OUT[P0:P15]
    Cog address $1FB is DIR[P16:P31];OUT[P16:P31]
    Cog address $1FC is DIR[P32:P47];OUT[P32:P47]
    Cog address $1FD is DIR[P48:P63];OUT[P48:P63]

    I'm don't know if this limits the Streamer max data width but obviously software bit bashing will be 16-bit data width limited.
    The 16b width limit could be a problem, as there could be cases where users want/expect the full 32b BUS to Pin path.

    (I often grumble about 32b MCU's having 16b timers, a 32b MCU with 16b ports is rather similar....)

    Some MCUs handle the Float/Drive handling by having 4 port modes.
    CMOS/OpenDrain/QuasiBiDir/Ip only
    N-MOS open drain is done by OpenDrain mode and simple OUT drive, and P-MOS open drain can be managed by select of CMOS<->IP, with OUT=H


  • jmgjmg Posts: 14,950
    cgracey wrote: »
    jmg wrote: »
    Cool. Did a post-VCO divider make it into the Verilog ?
    Yes. There's a 6-bit divider for the XI/crystal, a 10-bit divider for the VCO, and a 4-bit post-VCO divider.

    Sounds good, and quite competitive now with the NXP offerings :)

  • jmgjmg Posts: 14,950
    cgracey wrote: »
    Yes. There's a 6-bit divider for the XI/crystal, a 10-bit divider for the VCO, and a 4-bit post-VCO divider...

    Just thinking some more about SysCLK management across libraries, and from the other thread in handling HyperRAM, which has a 1us or 4us region tCMS.

    To auto-manage that in a (eg) HyperRAM RAM-Disk driver, you could define a Crystal value at build time, then
    can you then read-back the 6-bit, 10-bit, 4-bit values to extract the current SysCLK ?

    How do those 20 bits memory map ?

  • cgraceycgracey Posts: 13,722
    jmg wrote: »
    cgracey wrote: »
    Yes. There's a 6-bit divider for the XI/crystal, a 10-bit divider for the VCO, and a 4-bit post-VCO divider...

    Just thinking some more about SysCLK management across libraries, and from the other thread in handling HyperRAM, which has a 1us or 4us region tCMS.

    To auto-manage that in a (eg) HyperRAM RAM-Disk driver, you could define a Crystal value at build time, then
    can you then read-back the 6-bit, 10-bit, 4-bit values to extract the current SysCLK ?

    How do those 20 bits memory map ?

    They go to a write-only register via the CLKSET instruction. On Prop1, we just copied those values to bottom RAM locations.
  • MJBMJB Posts: 1,235
    cgracey wrote: »
    FLTIN and DRVIN clear and set the DIR bit, respectively, while sampling the IN bit state into C/NZ, as do all the other DIRx/OUTx/FLTx/DRVx instructions.
    so IN is sampled BEFORE the change in DIR/OUT is applied?



  • cgraceycgracey Posts: 13,722
    MJB wrote: »
    cgracey wrote: »
    FLTIN and DRVIN clear and set the DIR bit, respectively, while sampling the IN bit state into C/NZ, as do all the other DIRx/OUTx/FLTx/DRVx instructions.
    so IN is sampled BEFORE the change in DIR/OUT is applied?



    It can't be any other way, because it takes a few clocks for the pin states to reach INA/INB, then it takes a few clocks for OUT/DIR to reach the pins.
  • RaymanRayman Posts: 12,717
    edited 2017-01-09 20:45
    Just called Parallax Sales to order another P123 board. Unfortunately, they are sold out.

    Not so happy with my options...
    DE2-115 costs more, doesn't give as much and is way too big.
    The BeMicro-A9 seems to have been out of stock for a year.

    Are there any small A9 boards with reasonable cost?
    Any plans to make more P123 boards?
Sign In or Register to comment.