Lattice Diamond - how to overcome absurd clock routing requirements?

[axemaster]

Hi, I am writing a simple SPI Slave port for a ECP5 FPGA, using Lattice Diamond software.

The SPI port has a "sclk" signal, which is an input. I don't care about the frequency. I plan for 20MHz but really anything down to 1MHz would be fine.

I have already tested on testbench and my design is synthesizable. However, Lattice is insisting that I MUST input "sclk" on a dedicated clock port. Here's the exact error:

Code: [Select]

ERROR - USER LOCATE of clock driver 'sclk' at an illegal pin 'V21'. Unable to reach a CIB entry point for general route clock sclk_c in the minimum required distance of 1 PLC.
Please check if the pin is a legal clock pin (e.g. dedicated clock pin, GR pin) by
1) Opening 'Tools->Spreadsheet View' on the top
2) Choosing 'Pin Assgnments' tab in the middle
3) Checking 'Dual Function' column (PCLK*, GR*, etc.) for the pin
How can I overcome this nonsense? I can't find any options to suppress this restriction. Does this mean that any signal Lattice Diamond infers as a clock will refuse to route unless it's on the "correct pin", even if it's 1Hz signal???

[BrianHG]

Can we see the HDL?

Sometimes certain uses or constraints/rules/limitations might need to be observed when using a generic IO pin to clock logic or to be used as a generated clock output.

Also, Lattice seems to prefer (as I have seen in their example designs) that you wire each required IO to their IO primitive as a normal course of action as their compiler/fitter seems to only perform the most basic automatic design IO primitive inference compared to compilers such as Altera's and Xilinx's which will take anything you throw at it.  A hassle, but check how their IO primitive's parameter/ports supports defining an IO feeding their logic's local or global clock net.  Google may help you here with the correct search terms.

[BrianHG]

Maybe read here: https://www.eevblog.com/forum/microcontrollers/lattice-diamond-secondary-clock-resources/

[SiliconWizard]

You can read the "General Routing for Clocks" section in the "ECP5 and ECP5-5G sysCLOCK PLL/DLL Design and Usage Guide".
It's not very detailed, but explains the issue.

[Bassman59]

Also, Lattice seems to prefer (as I have seen in their example designs) that you wire each required IO to their IO primitive as a normal course of action as their compiler/fitter seems to only perform the most basic automatic design IO primitive inference compared to compilers such as Altera's and Xilinx's which will take anything you throw at it.

With the exception of DDR primitives, I've never instantiated an I/O or clock buffer primitive in a Lattice design.

[Bassman59]

Hi, I am writing a simple SPI Slave port for a ECP5 FPGA, using Lattice Diamond software.

The SPI port has a "sclk" signal, which is an input. I don't care about the frequency. I plan for 20MHz but really anything down to 1MHz would be fine.

I have already tested on testbench and my design is synthesizable. However, Lattice is insisting that I MUST input "sclk" on a dedicated clock port. Here's the exact error:

Code: [Select]

ERROR - USER LOCATE of clock driver 'sclk' at an illegal pin 'V21'. Unable to reach a CIB entry point for general route clock sclk_c in the minimum required distance of 1 PLC.
Please check if the pin is a legal clock pin (e.g. dedicated clock pin, GR pin) by
1) Opening 'Tools->Spreadsheet View' on the top
2) Choosing 'Pin Assgnments' tab in the middle
3) Checking 'Dual Function' column (PCLK*, GR*, etc.) for the pin
How can I overcome this nonsense? I can't find any options to suppress this restriction. Does this mean that any signal Lattice Diamond infers as a clock will refuse to route unless it's on the "correct pin", even if it's 1Hz signal???

I suspect you're using sclk as a clock to directly drive the shift register, rather than oversampling it (and the CS\ and MISO pin). If so, then the point is that for your sclk to actually drive the flip-flops' clock inputs, it must be on a clock net.

TN1263 says that you can drive a primary clock net from "Internal FPGA Fabric Entries" which implies you should be able to instantiate a primitive to allow that to happen. That is, regular input pin routes to the clock net through the fabric. I can't figure out how to make that happen, but it's surprising (not) that the synthesis can't figure out how to do that.

Now if your board is already built, maybe it's time for a couple of white wires. Or maybe use a PLL to generate a clock sufficient to oversample the SPI inputs. If you haven't built the board, just connect the SPI sclk to a primary clock input pin.

[BrianHG]

Also, Lattice seems to prefer (as I have seen in their example designs) that you wire each required IO to their IO primitive as a normal course of action as their compiler/fitter seems to only perform the most basic automatic design IO primitive inference compared to compilers such as Altera's and Xilinx's which will take anything you throw at it.

With the exception of DDR primitives, I've never instantiated an I/O or clock buffer primitive in a Lattice design.

Nor should it be necessary, but as you see the note I wrote in brackets...
This is only what I have seen in the Lattice tutorial demos.

[TimCambridge]

I have already tested on testbench and my design is synthesizable. However, Lattice is insisting that I MUST input "sclk" on a dedicated clock port.

Route your incoming clock to a DCC.

[Bassman59]

Also, Lattice seems to prefer (as I have seen in their example designs) that you wire each required IO to their IO primitive as a normal course of action as their compiler/fitter seems to only perform the most basic automatic design IO primitive inference compared to compilers such as Altera's and Xilinx's which will take anything you throw at it.

With the exception of DDR primitives, I've never instantiated an I/O or clock buffer primitive in a Lattice design.

Nor should it be necessary, but as you see the note I wrote in brackets...
This is only what I have seen in the Lattice tutorial demos.

I haven't looked at their tutorial demos. I've used the parts in designs, so I'm just reporting what I actually used.

[axemaster]

So I *may* have found a workaround. I added the following command line option to the "Place and Route Design" tab of my strategy. Pic attached.

-exp WARNING_ON_PCLKPLC1=1

It *seems* to allow bypassing the error message. However, I have not yet successfully routed this design (it has very high speed modules), so I am not 100% sure this works yet.