• PMOD Adaptation

    Knusperkeks • 07/12/2020 at 21:37 • 0 comments

    In order to do some more useful experiments I finally designed a breakout board with PMOD  connectors. Both PMODs on the sides are standard ones with 3.3V or 5V (selectable by a jumper). The header on the bottom is a double PMOD in the ULX3S style with 40 pins in total, which is a very clever and nice idea. Thanks to the Radiona folks!

    For ease of use and accessibility the headers (especially left and right) should be 90° angled (but the silkscreen for the straight ones is less crowded so I used it here). On the top are 4 additional LEDs for status indications. All signal traces are routed over a solid gnd plane, but without any length matching and impedance consideration (on 2 layers...yeah...).

    I thought, the 2x40 pin Bergstak connector has an equal footprint for plug and receptacle and was nearly right. The only little detail is, that the two positioning pins on the bottom are of different diameter and if you would read the drawing very careful, you could recognise the need for a 180° rotation. Or just get the drill out and fix it...preferably before you soldered both connectors to the pcbs and try to mate them! ;)

    With a specification of 100 mating cycles these were one of the better 0.8mm pitch connectors I found and they are available in many pin counts, heights and even a lower cost version. → Not bad at all :)
    The suggested footprint in the datasheet can be used for handsoldering.

    Current status of the FUSBee5 board:

    • Hyperram is now fully connected (all series resistors are soldered in), but still needs testing → HDL action needed.
    • Placement of the 4x0402 resistor packs should be reconsidered, as it is barely doable for hand assembly.
    • It might be advantageous to replace both fixed frequency CMOS oscillators by a Silabs configurable PLL chip.
    • The 3.3V buck regulator is quieter, as both ram chips are now drawing some idle current and the 1.8V are sourced from the 3.3V via an LDO. The 1.1V rail is still a bit noisy when the FPGA is not really doing much. → Load step response still on the list to be tested, additional Cs needed?
    • The FT600 does not allow to configure the FPGA and only the JTAG option with an external adapter is currently usable. A little µC (as the LUNA project has) would be nice, but also requires some USB2.0 mux action to steal the Micro-USB 2.0 lines temporarily. → Not the prettiest solution and space-wise complicated.
    • I selected M2.5 spacers to mount the FUSBee5 on any main board (MiCE47 had these huge M3 things...), but it seems quite hard to "cheap and easy" buy these things...why?!

    Short term plans:

    • Verify and benchmark the hyperram chips to finish the board bring up.
    • Release the schematic/pcb design files with bugfixes/errata list.
    • Compare the FT600 software options (FTDI vs libusb).

  • Getting real...

    Knusperkeks • 04/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!
    Knusperkeks

  • Bus aware automated length matching verification

    Knusperkeks • 04/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:

    LENGTH MATCHING:
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.

    LENGTH MATCHING:
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 »