FPGA module featuring an ECP5, dual Hyperram, USB 3.0 and 48 IOs.
x-python - 18.82 kB - 04/03/2020 at 22:32
Revision: v1a Licence: CERN-OHL-W V2.0
Adobe Portable Document Format - 558.02 kB - 04/01/2020 at 21:08
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:
Short term plans:
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:
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!
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:
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 »