Prop2 FPGA files!!! - Updated 16 October 2017 - Version 24a

1798082848593

Comments

  • I was curious too to know what is new for the 'Lite' version.

    At first I thought it was just a version to let us know that It's Intel Quartus (not Altera). Later, when reading the release notes, I found that they added things for new Cyclone 10 and Arria 10 (like timing and power estimator) . And finally I read the list of service request that were fixed ... (shock) they have one custumer using Quartus 11 and they fixed their service request (/shock) (but no details given).
  • I'm making lots of progress tuning the Verilog. I found simple ways to speed up the CORDIC and the colorspace converter. Also, the S and D mux's have been redesigned to good effect. I'm getting single-cog compiles at 101MHz Fmax. Four cogs are coming in at around 91MHz. That's getting better by the hour, though. I hold off on the 16-cog compiles because they take almost two hours. They used to take three, though. Cleaning up the critical paths has allowed Quartus to get the job done faster.
  • cgracey wrote: »
    I'm making lots of progress tuning the Verilog. I found simple ways to speed up the CORDIC and the colorspace converter. Also, the S and D mux's have been redesigned to good effect. I'm getting single-cog compiles at 101MHz Fmax. Four cogs are coming in at around 91MHz. That's getting better by the hour, though. I hold off on the 16-cog compiles because they take almost two hours. They used to take three, though. Cleaning up the critical paths has allowed Quartus to get the job done faster.

    Excellent news Chip!

    That's a double whammy. Increasing clock speed while reducing compile speed ;)

    It's also casting another look over the code for bugs at the same time, although I guess there is a lower possibility of introducing bugs too.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgraceycgracey Posts: 8,023
    edited May 16 Vote Up0Vote Down
    It's been taking me a while to get v19 out. I've got everything going at 100MHz now and the big A9 compiles are almost complete.

    I've got the new instruction sheet done:

    https://docs.google.com/spreadsheets/d/12LZ9KPEy5FEz8aVAG1DBVur36MB2eTVNT4QZ7wgpc-c/edit?usp=sharing

    I think I'll have the rest of this out tomorrow.
  • jmgjmg Posts: 10,463
    cgracey wrote: »
    It's been taking me a while to get v19 out. I've got everything going at 100MHz now ....

    So 96MHz will be fine, but 108 MHz is just too far ?

    Will the builds set the FPGA PLL for 96MHz, or 100MHz ?

  • jmg wrote: »
    cgracey wrote: »
    It's been taking me a while to get v19 out. I've got everything going at 100MHz now ....

    So 96MHz will be fine, but 108 MHz is just too far ?

    Will the builds set the FPGA PLL for 96MHz, or 100MHz ?

    They are at 100MHz. That gives ~8.33 clocks per 12MHz USB bit. I know 96MHz is a clean 8x of 12MHz, but does it really do anything other than make USB signals look better on a scope? Is any hardware out there sensitive to 1/8th bit of jitter?
  • cgraceycgracey Posts: 8,023
    edited May 16 Vote Up0Vote Down
    The 16-cog compiles are coming in at around 80MHz now. They used to be around 66MHz. So, we are overclocking proportionally the same as before. 108MHz might work, but I'm not very confident it wouldn't be flakey. What do you think?
  • jmgjmg Posts: 10,463
    cgracey wrote: »
    The 16-cog compiles are coming in at around 80MHz now. They used to be around 66MHz. So, we are overclocking proportionally the same as before. 108MHz might work, but I'm not very confident it wouldn't be flakey. What do you think?

    First builds of a new verilog, I would err on conservative.
    cgracey wrote: »
    They are at 100MHz. That gives ~8.33 clocks per 12MHz USB bit. I know 96MHz is a clean 8x of 12MHz, but does it really do anything other than make USB signals look better on a scope? Is any hardware out there sensitive to 1/8th bit of jitter?
    80MHz was 6.6667, and that seems to have communicated at least. Not sure if it meets any USB specs.

    It's hard to be certain, so ideally both need to be tested.

    If HOST code was debugged at 6.667 ok, it seems 8.33 should also be ok.
    The devices I know that lock to USB, do so using the 1ms frame rate, but maybe some try to lock to edges and are more jitter sensitive ?

    Did you look at the thread on Smart Pins, Up/Down Counting aka CLK , DIRN position encode variant support ?
  • I saw the thread, but need to re-read it carefully to understand what's being talked about. I understood there's some need for automatic resetting or position reporting when a 'home' signal is encountered during operation.
  • jmgjmg Posts: 10,463
    cgracey wrote: »
    I saw the thread, but need to re-read it carefully to understand what's being talked about. I understood there's some need for automatic resetting or position reporting when a 'home' signal is encountered during operation.
    That is less important, than supporting AB signals for CLK and DIRECTION, which is really a variant of Quad Encode.
    Rotary encoders commonly use Quad counting, but if you want to 'clip onto' a stepper motor system, CLK and DIRN are more common.

    I'm not sure there are enough signal paths to support Quadrature Counting plus HW reset, and that infers 3 hardware pin connected ?
    I think 3 is quite a jump on Smart pin structure ?
    Some time spec for the Software alternative of Pin -> Interrupt -> SW Zero (either capture, or clear) would be useful to know.
  • jmgjmg Posts: 10,463
    cgracey wrote: »
    They are at 100MHz. That gives ~8.33 clocks per 12MHz USB bit. I know 96MHz is a clean 8x of 12MHz, but does it really do anything other than make USB signals look better on a scope? Is any hardware out there sensitive to 1/8th bit of jitter?

    I find this in a TI pdf
    10. What is the jitter requirement for the 48-MHz signal (pin 27) for the TUSB2046B?
    The clock must meet the USB 2.0 full-speed jitter specification as outlined in Table 7-9 of the full-speed specification (available at http://www.usb.org/developers/docs/).
    The source jitter tolerance TDJ1 has to be between –3.5 ns (min) to 3.5 ns (max).
    TDJ2 has to be between –4 ns to 4 ns.

    That indicates 96 or 108MHz will be needed to get inside those formal limits, but a 160MHz+ part just might be able to use any SysCLK ?.

  • The smart pin has a real quadrature encoding mode, and that occupies the two input signals. It might be easy to bring in a 3rd signal, though. We'll see.

    Maybe I shoulld recompile for 96 MHz. It's possible that our jitter was causing some connection issues, right?
  • jmgjmg Posts: 10,463
    edited May 16 Vote Up0Vote Down
    cgracey wrote: »
    The smart pin has a real quadrature encoding mode, and that occupies the two input signals. It might be easy to bring in a 3rd signal, though. We'll see.
    How many SysCLKs does the interrupt path need, and how much variance does that path have ?
    eg suppose a rough guess of 10 sysclks at 100MHz, which is 100ns - and I'm not sure anyone needs to live-zero, at a speed of > 10MHz ?
    I have seen quad encoders needing to count above 10MHz
    cgracey wrote: »
    Maybe I shoulld recompile for 96 MHz. It's possible that our jitter was causing some connection issues, right?
    96MHz will meet the USB jitter spec numbers above, so it seems to me a better place to start thorough USB testing from.
    Then, when USB is looking solid and stable, 100MHz can be checked (along with 108MHz)

    Is there any testing that needs 100MHz to prove ?
  • evanhevanh Posts: 4,176
    edited May 16 Vote Up0Vote Down
    cgracey wrote: »
    The smart pin has a real quadrature encoding mode, and that occupies the two input signals. It might be easy to bring in a 3rd signal, though. We'll see.
    Save that one for Prop3 thoughts. However a CLK+DIR mode would fit the existing two inputs available. Most of the discussion around this was whether it could be merged into an existing mode.

    There was also a possible CLK+DIR solution with mode %10111 = For periods in X+ clock cycles, count periods using two Smartpin cells. Although I'm not sure on how this mode really works.

    The idea is one Smartpin counts up on A rises with B low say, and the other Smartpin counts up on A rises with B high. Then software subtracts one Z from the other Z to get the total count.

    Maybe I shoulld recompile for 96 MHz. It's possible that our jitter was causing some connection issues, right?
    Some USB 3.0 capable devices were giving grief, although no one knew why. I was just reading that thread the other day, now that I can do some testing too. http://forums.parallax.com/discussion/comment/1402661/#Comment_1402661
  • jmgjmg Posts: 10,463
    evanh wrote: »
    The idea is one Smartpin counts up on A rises with B low say, and the other Smartpin counts up on A rises with B high. Then software subtracts one Z from the other Z to get the total count.
    That's a CLK + Enable and CLK + !Enable mode , also known as gated counter, and that's another missing mode..
    Quad Counting is really a super-set of these that adds a Quad to CLK + Direction precursor, so it just needs a logic bit to bypass/disable that to get CLK+DIRN.
    CLK+Enable may need to map to another counting mode ?

    ie needed in addition to Quad, are the simpler variants of CLK + Direction, & CLK + Enable


  • evanhevanh Posts: 4,176
    jmg wrote: »
    CLK+Enable may need to map to another counting mode ?
    I'm thinking mode %10111 = For periods in X+ clock cycles, count periods provides CLK+ENA.
    ie needed in addition to Quad, are the simpler variants of CLK + Direction, & CLK + Enable
    CLK+DIR can be built from two CLK+ENA's, hence why I'm listing it as a possibility.
  • jmgjmg Posts: 10,463
    evanh wrote: »
    I'm thinking mode %10111 = For periods in X+ clock cycles, count periods provides CLK+ENA.
    That's not how I read the docs..
    The option is edge-to-edge, not edge with enable. I'm sure Chip will clarify.

  • So, the following modes would be good to have:

    1) CLK + UP_DN, where the counter is incremented or decremented on each CLK rise, depending on the state of UP_DN.

    2) CLK + ENA, where the counter is incremented on each CLK rise when ENA is high.

    Pin polarity is settable, of course.

    Is that right?

  • kwinnkwinn Posts: 7,589
    cgracey wrote: »
    So, the following modes would be good to have:

    1) CLK + UP_DN, where the counter is incremented or decremented on each CLK rise, depending on the state of UP_DN.

    2) CLK + ENA, where the counter is incremented on each CLK rise when ENA is high.

    Pin polarity is settable, of course.

    Is that right?

    Those are two very common cases in instruments for frequency measurement and motion control.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • kwinn wrote: »
    cgracey wrote: »
    So, the following modes would be good to have:

    1) CLK + UP_DN, where the counter is incremented or decremented on each CLK rise, depending on the state of UP_DN.

    2) CLK + ENA, where the counter is incremented on each CLK rise when ENA is high.

    Pin polarity is settable, of course.

    Is that right?

    Those are two very common cases in instruments for frequency measurement and motion control.

    I've been looking at the smart pin section that does periodic and continuous measurements. To add these modes is very trivial. We just need to use WYPIN to set sub-modes. It's almost nothing, at all.

    We actually have THREE slots that can do something new.

    Aside from CLK+UP_DN and CLK+ENA, is there one other mode that would be helpful to have that follows the same general scheme?
  • evanhevanh Posts: 4,176
    I'm good with just those two.
  • evanh wrote: »
    I'm good with just those two.

    The third one is free, though. So, what should it be? Sad to waste it.
  • evanhevanh Posts: 4,176
    edited May 16 Vote Up0Vote Down
    If you're going to do sub-mode groupings of modes, then I imagine most of the existing counting modes can be grouped under just a few modes.

    This leaves gaps for future in case of no need for architecture change.
  • Would CLK+RESET be of any use?
  • cgracey wrote: »
    Would CLK+RESET be of any use?

    As in "reset clocked counter to zero on reset pulse"?

  • Seairth wrote: »
    cgracey wrote: »
    Would CLK+RESET be of any use?

    As in "reset clocked counter to zero on reset pulse"?

    That's what I was thinking, but it really doesn't seem useful, does it? Maybe if it would capture on reset, but that's still not useful, it seems.
  • I think I found a very simple way to implement this that's not too disruptive.
  • jmgjmg Posts: 10,463
    edited May 17 Vote Up0Vote Down
    cgracey wrote: »
    I think I found a very simple way to implement this that's not too disruptive.

    That's good to hear, I was hoping it was minor.
    cgracey wrote: »
    Would CLK+RESET be of any use?
    ..... Maybe if it would capture on reset, but that's still not useful, it seems.
    I think there is already an external Capture, but what I'd call a higher precision model ?
    Those high-precision, whole period ones, may be harder to explain and use, than a simple Capture & Reset, so yes, CLK+RESET(capture) sounds useful to me, as a 'spare mode filler'
    With Capture & reset, you need only one edge, whilst the higher precision modes need at least two edges.

    Addit : examples of simple one-edge echo style uses would be any sonar system, from the low precision Ping units (air), and there are linear probes that use speed of sound in metals & Magnetostrictive pulses.
    Those are ~ 5.8mm/us or 17.24ns/0.1mm each way so a 2 metre probe is ~689us echo and a 29MHz SysCLK is 0.1mm LSB, that's right in P2 territory.
  • I've got the two new modes integrated into the smart pins. The net increase amounted to about three 2-input gates per smart pin. Almost nothing.

    I'm recompiling the FPGA images now.
  • cgraceycgracey Posts: 8,023
    edited May 17 Vote Up0Vote Down
    I'm compiling for 120MHz. I'll see how well it works for the 16-cog implementation on the -A9. The only apparent problems at higher speeds that I've noticed were the DACs, but I've since constrained their output delays, along with the DAC clock's, so that there are no setup/hold-time issues. 120MHz will get rid of jitter for USB stuff, as there will be ten full clocks per USB bit.
Sign In or Register to comment.