Properly Constraining I/O delays On Arty

[nkraemer]

I am working with an Arty design and I have noticed that while I have no intra-clock timing failures, I still have high severity warnings in the "check timing" portion of my timing summary related to not having constraints for input and output delay (no_input_delay and no_output_delay). Does digilent provide suggested timings for the on-board peripherals (like Ethernet and flash), or do I have to go through all the datasheets myself and estimate the trace delay? I found this thread from 2017, but the question was never resolved.

[zygot]

1 hour ago, nkraemer said:

I have no intra-clock timing failures, I still have high severity warnings in the "check timing" portion of my timing summary related to not having constraints for input and output delay

These warnings do not necessarily mean that you have timing issues. Tools from all vendors will issue warnings about a lack of IO timing constraints. Not all design require timing constraints.

Digilent certainly sells FPGA boards with peripherals that require IO timing constraints. The 1G Ethernet PHY is a good example. Sometimes you can build one of the demos, which tend to be MicroBlaze oriented, and find all of the "*hidden*" timing constraints strewn through the project directories as a guide. Unfortunately, Digilent, as a rule, doesn't support the all HDL design flow so it's hard to find this information. 

1 hour ago, nkraemer said:

do I have to go through all the datasheets myself and estimate the trace delay?

You should go through the datasheets for any external device that you want to connect your FPGA design to, for no other reason but to know what the requirements are,  but you shouldn't have to estimate trace length. Digilent has recently been providing net length reports, when requested, for things like the Genesys2 FMC pin traces. There aren't many Digilent FPGA boards with peripherals that require knowing trace lengths, but you certainly have the right to ask for pertinent information in order to use a product that you've purchased.

Perhaps you could provide a bit more information about what you are doing and what the issues are.

*hidden* meaning that some constraints files associated with IP don't show up in the project source code hierarchy view.

[nkraemer]

Thank you for the quick reply zygot. I'm currently tracking down an intermittent bug in my microblaze design and I want to be able to say with confidence that FPGA timing errors are not the source of the problem. Additionally, I believe it is good practice to have the tools guarantee that timing will be met on all communication buses. I would particularly like to avoid one FPGA build working, changing something unrelated, and then having a subsequent build fail because the tools weren't able to properly account for off-board timing constraints. I understand that certain pins like LEDs or switches don't require external timing constraints, but shouldn't the on-board  QSPI Flash and Ethernet 100M be constrained?

[D@n]

@nkraemer,

There's an ugly bug in the Xilinx Ethernet-Lite core that could show up as an intermittent bug under heavy usage.  Is this the core you are using?

Dan

[nkraemer]

Initially I was but I have switched to a custom MAC since the Etherniet-Lite core doesn't support all the features I want. I'm not certain that the bug is within the new MAC (it may be a firmware bug), but it would be nice to eliminate timing issues as a potential source of error.

[zygot]

2 hours ago, nkraemer said:

Additionally, I believe it is good practice to have the tools guarantee that timing will be met on all communication buses. I would particularly like to avoid one FPGA build working, changing something unrelated, and then having a subsequent build fail because the tools weren't able to properly account for off-board timing constraints.

Unfortunately, having an FPGA build working and then failing after adding seemingly unrelated logic or changes is not an uncommon problem for a number of reasons. Distinguishing off-chip timing issues from intermittent glitches or errors often requires some cleaver debugging strategies.  If you do supply timing constraints for external device signals the tools will report timing failures which helps.

If you are using an Ethernet PHY then you have at least 2 clock domains, transmit and receive clocks. Likely the MicroBlaze is operating in a third domain. It's easy to use a signal sourced by one clock domain in logic within a different clock domain without proper conditioning. This can cause the tools to make poor decisions with respect to optimization or placement. Usually this results in failing paths in your timing report. You mention that you are using a custom MAC design. Since this is likely the only code that sn't Xilinx IP I'd start looking there. All of the FPGA vendors make creating designs involving Ethernet difficult without using their proprietary, and source encrypted, MAC IP. Somehow, you seem to have figured out how to disentangle all of this but it might be the source of your problems. I don't often use MACs or 10/100, or triple-speed Ethernet in my designs but I always verify the robustness of the Ethernet PHY <--> FPGA interface before trying to use it. That's my approach but I'm unique in how I use Ethernet with FPGA device. I certainly wouldn't discount a bug in vendor provided free IP.

I guess that at this point my advice would be to try and isolate your problem from the rest of the design. This is a lot easier to do in an all HDL design which is my non-ZYNQ mantra. Perhaps you can start by add two ILA cores; one for TxD related data and control signals clocked with the Ethernet Txclk and the other for RxD data and control signals clocked with the Ethernet Rxclk. At least you can see what's happening there. Make sure to capture the full 8-bit values in you design. Frankly, I've never done this because it's been a long long time since my last MicroBlaze/NIOS design. I simply avoid this design flow to the extent possible.

Do simulate your design as the simulator sometimes points out problems that you might have missed. Just pay careful attention to all simulator warnings and non-nonsensical behavior.

It's hard to get specific in details reacting to a very non-specific problem statement, especially with limited information.

[zygot]

2 hours ago, nkraemer said:

QSPI Flash and Ethernet 100M be constrained

If you are using Xilinx IP in the board design flow, and you are because that's the only way to do a MicroBlaze design, then there are timing constraints buried somewhere in the project with the IP source. It's a good exercise finding all of these and educational as well. Whatever IP you are using for your FLASH and Ethernet, the constraint files pertinent to them is there somewhere. Good hunting!

[xc6lx45]

one related comment: Accidentally unconstrained IO such as LEDs or switches can cause serious timing issues indirectly: They create difficult-but-not-impossible timing issues that then make P&R much more difficult / slow.

Use e.g. false_path on any "don't-care" / asynchronous IOs. At the same time, double-check that you're bringing inputs in properly with an (*ASYNC_REG="TRUE"*) synchronizer, as this false_path would otherwise increase the risk of metastability events (after the first register) or just plain timing violations (if used directly). The worst case example is probably a dedicated "reset" switch that triggers synchronous reset everywhere in a large clock domain - with false_path there is a high chance that an event hits some parts at clock edge n, others at clock edge n+1. The synchronizer will avoid that.

[nkraemer]

Thanks for the detailed reply and good debugging tips zygot. I'm using a hybrid approach with some Xilix IP cores in the block diagram, and some custom RTL (including ethernet) communicating to the rest of the design over AXI. I was able to use the Verilog Ethernet open source project as a basis for the MAC plus some custom 'glue logic' to convert the axi stream bus to a memory mapped axi interface. While I have simulated basic behavior of the core, I admit I haven't thoroughly verified it.

On 4/24/2020 at 4:34 PM, zygot said:

If you are using Xilinx IP in the board design flow, and you are because that's the only way to do a MicroBlaze design, then there are timing constraints buried somewhere in the project with the IP source. It's a good exercise finding all of these and educational as well. Whatever IP you are using for your FLASH and Ethernet, the constraint files pertinent to them is there somewhere. Good hunting!

I am using Xilinx's IP and the board design flow for the QSPI, but I'm still getting errors about unconstrained i/o timing. Additionally I grep'd the Arty board design files for "qspi" and "delay" and I couldn't find any references to the off board timing. I know that IP can define internal timing constraints, but presumably it needs knowledge of the board to know how to time the off-board signals. It's these off board timings that I'm interested in (at least for the purposes of this post).

On 4/25/2020 at 2:07 AM, xc6lx45 said:

one related comment: Accidentally unconstrained IO such as LEDs or switches can cause serious timing issues indirectly: They create difficult-but-not-impossible timing issues that then make P&R much more difficult / slow.

Use e.g. false_path on any "don't-care" / asynchronous IOs.

Good point xc6lx45, I will do this to make the tool's job easier (although so far timing has been passing with the exception of the no input/output delay constraints).

I think I have appropriately registered incoming signals to avoid meta stability, but it's worth double checking.

[zygot]

2 hours ago, nkraemer said:

I grep'd the Arty board design files

Find all of the files in a Vivado project folder/sub-folders with an .xdc file extension.

2 hours ago, nkraemer said:

I know that IP can define internal timing constraints, but presumably it needs knowledge of the board to know how to time the off-board signals.

So a basic 'rule of thumb' for signal delay down a PCB trace is about 1 ns/foot. Not a lot of PCB traces are that long. It's quite possible that knowing what a PCB signal trace length isn't necessary to implement a robust design.  It's an approximation complicated by a number of PCB layout factors. I'd find a 'golden' project for your board using the peripherals that you want to use, assuming that one is available. If it has timing constraints then use them. If it doesn't then you probably don't need them. It's quite possible to design an SPI or similar serial interface using and HDL so that timing constraints aren't needed. I've done this many times. In these cases I hide the fact that a signal might be a clock from Vivado to keep it from being confused. For instance, I'd clock my SPI master or slave entity with a much higher clock than what sclk will be and make sure to account for any reasonable delays for the data signals with respect to the sclk signal edge. I let Vivado know what the clock rate is for my logic but as far as Vivado knows sclk is just like any other signal. For and SPI interface where sclk is 50 MHz or higher this might not be a reasonable design strategy. Clocks are critical to FPGA synthesis and place and route tools and have a special meaning. Probably the most important timing constraints when there are multiple clock domains are the ones that  distinguish between unrelated clocks domains, indicate multi-cycle timing and prevent timing analysis for those signal that don't need it. The purpose of constraints is to help the tools figure out how to analyze your design. The tools don;t always need our help, depending on the design, clock rates, and device speed.