• Getting real...

    Knusperkeks04/24/2020 at 21:05 0 comments

    Since about two weeks, I have all parts and pcbs on hand and started building up a prototype. So far, it does look quite well and there is nothing wrong with the design! :) The overall status is:

    • Most parts, except the input protection/selection circuitry, are soldered down.
    • FPGA has no shorts/opens, can be programmed via JTAG and most importantly it survived my hot air torture.
    • FT600 is working fine with USB2/3 and a simple loopback test from the PC to the FPGA does work fine. Just my resistor array for series termination is awful for hand soldering! Do you a favour and don't use the standard 4x0402 footprint for hand soldering (pads should be longer and not placed very close to a chip). One could argue that it is not very useful to place gigantic 0805 load caps on a tiny 2.0x1.6mm crystal...I was so sure to have the right 0603s in stock when I designed the board.
    • Both buck converters (TPS62821) are working fine. The 1.1V one is only working in pulse skipping mode for higher efficiency, producing low freq. sawtooth ripple - some heavy computation is needed for the FPGA :D
      Nevertheless, the ripple is about 13mVpp for both (quick measurement with an ADALM2000) which is not too bad.
      A detailed measurement of ripple and current consumption should be done some day...
    • Hyperram is not tested.
    • Configuration flash is not tested.
    • Connector is not soldered down.

    Now I will continue putting together some nMigen code to hopefully check the Hyperram. Once it is known to work (hopefully!), I will put up the design files along with an errata/todo list for future revisions.

    Happy hardware hacking!

  • Bus aware automated length matching verification

    Knusperkeks04/01/2020 at 22:59 0 comments

    When you design a circuit with fast digital buses, sooner or later you come to the point to worry about setup and hold time and the timing skew between the bus signals. Hopefully, your manufacturer provides you some guidelines about the maximum allowed timing skew between certain (groups of) signals. In my case, Cypress has a nice appnote for the hyperram devices. A big "thumbs up" at this point!

    HyperFlash and HyperRAM Layout Guide (Cypress, AN211622)

    By looking at the table, it is easy to imagine that a) manually keeping track of different length matching requirements is error-prone and b) using the toughest requirement for all is not an option. How does KiCad help me with length matching? - Well, it has a nice interactive assistant that helps me adjust the length of one trace (or one diff pair) to a specified value. However, there are a few inconveniences here:

    • How do I specify and save the allowed tolerances for each line in the tool?
    • How can I see which requirements are fine and where tuning is still needed?
    • Actually, KiCad wants to know about a length, but I only care about a relative length tolerance (as long as it is not insanely long)!
    • My FPGA has no matched 50Ω output drivers, so I would like to use a series termination scheme. Therefore, the connection from the FPGA to the hyperram gets split into two separate nets. I really don't want to measure and match lengths on 24 individual nets per ram chip!
    • Vias are not considered.

    The good news, other people had the same problem and came up with ideas! There is a kicad-length-matching-checks script and a modified version by the never resting Greg Davill, but I only found that one later and have not looked into it. To more or less solve all four points listed above, I tried to hack together my own version, loosely based the first script.

    I quite dislike the idea of creating weirdly named net classes (it is also not flexible enough), so I took on an idea Chis Gammel once discussed on TAH. He suggested to put text boxes with additional descriptions and calculations on your KiCad schematic, but outside of the nice printing border. If you generate a pdf version the clutter will be excluded, nevertheless it is easily accessible and less likely to get lost. As a result, I have little text boxes to define all tolerance requirements:

    id: hyperram1_dq
    netnames: "(?:/hyperram/)?HR1_DQ[A-Za-z0-9_-]+"
    merge: "^(?:/hyperram/)?(.*?)(?:_R)?$"
    tolerance: 1.27 mm
    vialength: 1.6 mm

    ID is just the name of this rule definition block, which will be shown in the length matching report later. To define which nets should be considered by the rule, you simply write down a regular expression for the NETNAMES parameter. All nets matching to this regex will then be piped through the MERGE regex. This step splits the net name into a base name and an optional extension and all equal base names will be treated as one big net. In my case, I have "HR1_DQ1" as net name between the FPGA and series termination resistor and then "HR1_DQ1_R" for the connection from the resistor to the hyperram chip. TOLERANCE is the maximum allowed length difference within all nets in this group and VIALENGTH defines how to account for vias. The overall length of the "DQ" lines is not restricted.

    id: hyperram1_rwds_to_dq
    netnames: "(?:/hyperram/)?HR1_RWDS_N[A-Za-z0-9_-]*"
    merge: "^(?:/hyperram/)?(.*?)(?:_R)?$"
    reflength: group hyperram1_dq
    tolerance: 0.635 mm
    vialength: 1.6 mm

    The "RWDS" line must be closely matched to all "DQ" lines, which is expressed by the REFLENGTH parameter. Its arguments "group hyperram1_dq" tells the script to use a dynamic calculated length instead of a static (hard coded) one. Obviously the tolerance in the "hyperram1_dq" is dictated by the RWDS-to-DQ requirement, so it is basically overspecified. As long as you do not specify mutually exclusive rules, there will be no problem.

    The basic workflow is stolen from the other script. You edit your layout while having the script running and as soon as you...

    Read more »