Data output constraint

Hello,

I asked some time ago for constraints learning materials. It is hard to learn only with reading, I think I should try it.

Here comes the time when I think only that can help me. I have problem with sending data to SD memory. Data output and checksum values seem to be fine, but SD says that there is checksum error. It works with 50MHz. I suppose that there might be some delay between clock and data, maybe you could suggest something else?

Could you help me with applying constraints to let the tools know that they should be more careful with that sensitive data output part of design?

The only constraint, besides LOC for pinout, which I use is: NET "clock" TNM_NET = "tnm_clock"; TIMESPEC "TS_clock" = PERIOD "tnm_clock" 20 ns HIGH 50 %;

But to be honest I don't see much difference with or without it. I just read that it is one of basic and "must be" constraint.

Best regards, Pavel

--------------------------------------- Posted through

formatting link

Reply to
pavel.m
Loading thread data ...

The PERIOD constraint is a good starting point, but it only covers internal paths from one flip-flop or other register (BRAM, DSP48...) to another inside the FPGA.

Checksum errors could very likely indicate an issue with the interface timing, which includes clock to output of the FPGA, and setup/hold time at FPGA inputs.

You need to check the specs on your external device to calculate the allowable setup and hold time at the FPGA. Then you need to add an OFFSET IN BEFORE constraint to ensure that these conditions are met by the design. For example if you determine that you have 3 ns setup and 2 ns hold time with respect to the rising edge of the "clock" net:

OFFSET = IN 3 ns VALID 5 ns BEFORE "clock" RISING ;

This says that the valid data window starts 3 ns before the rising edge of the clock input pin, and stays valid for 5 ns - that is until

2 ns after the rising edge of clock.

You can also constrain the clock to output timing like:

OFFSET = OUT 5 ns AFTER "clock" RISING;

This sets a maximum delay from the clock input pin to an output pad. Note that there is no way to constrain a minimum delay, so if you are using source-synchronous logic, you need to be sure that output timing is met by design. Normally this means placing output flops in the IOB and using a DDR output register for the clock running on a different phase from the data to allow hold time if necessary.

-- Gabor

Reply to
GaborSzakacs

Thank you Gabor for the reply. Good to know that it may be good way for my deliverance :)

Here is fragment of external device documentation: graph:

formatting link
values:
formatting link

For data transfer from external device to FPGA: If todly has max. 14 ns from last clock rising edge, then it has 6 ns setup time? And toh has min. 2.5 ns. Then I should set (if only fraction is possible):

OFFSET = IN 6 ns VALID 8.5 ns BEFORE "clock" RISING ;

?

For data transfer from FPGA to external device, which cause my problem: This part I don't understand. In that constraint should be external device inputhold time? Then:

OFFSET = OUT 2 ns AFTER "clock" RISING;

And that part about timing requirements. Placing output flops in IOB is just assigning signal which I want to send out to the output pin? Like here (data3_out is an output port):

data3_out

Reply to
pavel.m

here

Reply to
pavel.m

This would be correct if the clock input to both devices arrives at the device input pin at the same time (i.e. a typical radial clock distribution network like PCI bus) and the clock period is 20 ns.

No. The OFFSET OUT constrains the *maximum* time from the clock pin to the data output. This really affects the setup time at the external device and should be set to the clock period minus the setup requirement (again assuming a radial clock distribution). The hold time at the external device needs to be met by design, either due to the absolute minimum guaranteed delay from clock to output on the FPGA, or by using a phase-shifted clock.

On the other hand, if you don't have a radial clocking scheme, you need to also deal with the difference in clock arrival time (clock skew) between the FPGA and the external device. And in all instances you should also factor in the board-level propagation delay due to trace lengths. These become more important at higher clock frequencies (for setup time) but are always importantant for hold time regardless of the clock frequency.

Reply to
GaborSzakacs

I believe the proper element to apply the IOB constraint to is the actual register that drives the output. So if data3_out is just a continous assign to data_byte(3) and data_byte(3) is assigned in a clocked process, then data_byte(3) should have the IOB = TRUE attribute. You could also globally push registers into the IOB, but that may affect your ability to meet internal timing.

Actually meeting the timing constraints is most important. If you only need to guarantee a certain input setup and clock to output timing, then you can leave the global IOB setting at "auto" and let the tools decide where to place the registers in order to balance internal and external timing requirements. On the otehr hand, if you have to keep interface skew to a minimum (as in a source-synchronous design) then you will need to push registers in the IOB, because the constraints only control maximum delay and not skew.

Reply to
GaborSzakacs

Dear Gabor,

first of all thank you for your patience. Because I'm not sure about all of this and I feel that I'm not capable to do it myself I have to give more details of my design:

- crystal clock-oscillator generates single 50MHz clock, which comes into FPGA,

- the process where I have to send data out uses rising_edge(clock) instruction,

- there is FSM, where two states are used for sending data out, this is because I use 4 lines for data output and I want to send bytes, so in one state 4 MSB are sent, in second state 4 LSB are sent, something like this:

when WRITE_DATA_MSB =>

data3_out

Reply to
pavel.m

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.