hadbadge2019_fpgasoc
hadbadge2019_fpgasoc copied to clipboard
Spritetm
Possible issue with clock on U18
It is hard to gauge the severity of this, but Lattice is pretty adamant that clocks entering the FPGA fabric really ought to do so via a clock pin. Their Diamond tools won't even permit a design where the clock comes in on a general port.
The ECP5 and ECP5-5G device has dedicated pins, called PCLK pins, to bring an external clock source into the FPGA and allow them to be used as FPGA primary clocks. These inputs route directly to the Primary clock net- work, or to Edge clock routing resources. A dedicated PCLK clock pin must always be used to route an external clock source to FPGA logic and I/O.
If an external input clock is being sourced to a PLL, then in most cases the input clock should use a dedicated PLL input pin. SERDES reference clocks also have dedicated SERDES reference clock pins. The ECP5 and ECP5-5G device allows a PLL reference clock or a SERDES reference clock to come from an external Primary Clock (PCLK) pin and route through the Primary clock network to drive the reference clock to the SERDES or the input of a PLL. --TN1263 - ECP5 and EXP5G PLL/DLL Design and Usage Guide -- https://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/EH/TN1263.ashx?document_id=50465
This is also covered in a Lattice FAQ entitled "Why must I use a Primary Clock Input for a clock instead of a general purpose pin?"
Lattice recommends always using Primary Clock (PCLK) inputs for clocks. An exception is when a clock input is routed directly to a single PLL then a dedicated PLL input should be used. If multiple PLLs are using the same input clock then a PCLK Input should be used and preferenced with a "USE PRIMARY ". This will route the clock to all PLLs while keeping the clock on Primary clock routing. ...Lattice does not characterize general routing for clocks and over Process / Voltage / Temperature there can be a huge percentage of variation in jitter, duty cycle distortion, and delay in these clocks. -- http://www.latticesemi.com/en/Support/AnswerDatabase/2/4/7/2475
It looks like the clock signal enters the board on a non-clock pin, U18. This may be the cause of some clock problems. Switching the clock to L18, for example, (currently an LED) which is such a clock pin satisfies the requirement and permits Diamond to proceed.
Well, crap. I'm throwing that on the stupid-bug-list as I can't change the hardware now.
Okay, so as far as I can see, I don't think it should be much of an issue given the osc is routed directly into a PLL and not really used anywhere else in the SoC design. Clock skew because the main clock path is routed over general fabric shouldn't be an issue, the only thing might be the clock getting a bit wobbly before arriving at the PLL, and seeing that things like USB are pretty stable, I doubt that's an issue.
If anything, for the people wanting to use Diamond, both the clock and a PCLK-connected pad are available on the bottom of the badge. Connecting TP2 and TP6 should bring the clock out to C12, which as far as I can see is a PCLK pad. See http://j0h.nl/WfIB for an example.
Another wrinkle... leaving open the possibility of user error, Diamond does not have C12 as a Clock pin (B12 is, D12 is, just not C12), and persists in declining to build. The schematic has C12 as PCLKC1_0, PT44B, Bank 1, and Lattice's reference CSV file also has C12 as a clock. But the Package view in Diamond shows it as a regular pin. Looks like a Diamond bug. Best workaround may be pursuing some kind of "ignore error" option, although a quick search did not reveal it.
Well, that sucks. The only alternative I see is to instantiate an iopad manually on an unused PCLK pin, e.g. D12. Route the 8MHz signal over general fabric to the out of this pin, then route the input as a clock. Somewhat janky, but perhaps it solves the issue.