Data output constraint

[pavel.m]

Hello,

I asked some time ago for constraints learning materials. It is hard t
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 wit
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 suppos
that there might be some delay between clock and data, maybe you coul
suggest something else?
Could you help me with applying constraints to let the tools know that the
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 jus
read that it is one of basic and "must be" constraint.

Best regards,
Pavel


---------------------------------------
Posted through http://www.FPGARelated.com

 

[GaborSzakacs]

pavel.m wrote:

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 http://www.FPGARelated.com

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

 

[pavel.m]

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.

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

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

Here is fragment of external device documentation:
graph: http://uppix.net/8/5/1/151d221e03dbb2b8414340f3f08f6.png
values: http://uppix.net/7/0/6/e5514ee21a32972ee177d6a0787b4.jpg

For data transfer from external device to FPGA:
If todly has max. 14 ns from last clock rising edge, then it has 6 ns setu
time? And toh has min. 2.5 ns. Then I should set (if only fraction i
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 devic
inputhold time? Then:

OFFSET = OUT 2 ns AFTER "clock" RISING;

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

data3_out <= data_byte(3);

And somehow use that DDR to allow 2 ns (again?) hold time?

---------------------------------------
Posted through http://www.FPGARelated.com

 

[pavel.m]

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? Lik
here
(data3_out is an output port):

data3_out <= data_byte(3);

I see that placing registers into IOB is something what I should set.
And I read that I can do it for all I/O registers in "Map properties" o
just for selected registers in *.vhd file:

attribute IOB : string
attribute IOB of data3_out: signal is "TRUE";

Is that correct (data3_out is an output port)?
I saw also that it is possible in *.ucf file, but don't know how to do i
with port name usage.

And it is for using the nearest logic to the output pad, what ensures th
lowest setup time, correctly understand? If yes, then I suppose that th
time between that register in IOB and next connected register may b
increased. But I guess that I/O times are more important.



---------------------------------------
Posted through http://www.FPGARelated.com

 

[GaborSzakacs]

pavel.m wrote:

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.

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

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

Here is fragment of external device documentation:
graph: http://uppix.net/8/5/1/151d221e03dbb2b8414340f3f08f6.png
values: http://uppix.net/7/0/6/e5514ee21a32972ee177d6a0787b4.jpg

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 ;

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.

?

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;

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.

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 <= data_byte(3);

And somehow use that DDR to allow 2 ns (again?) hold time?

---------------------------------------
Posted through http://www.FPGARelated.com

 

[GaborSzakacs]

pavel.m wrote:

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 <= data_byte(3);

I see that placing registers into IOB is something what I should set.
And I read that I can do it for all I/O registers in "Map properties" or
just for selected registers in *.vhd file:

attribute IOB : string
attribute IOB of data3_out: signal is "TRUE";

Is that correct (data3_out is an output port)?

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.

I saw also that it is possible in *.ucf file, but don't know how to do it
with port name usage.

And it is for using the nearest logic to the output pad, what ensures the
lowest setup time, correctly understand? If yes, then I suppose that the
time between that register in IOB and next connected register may be
increased. But I guess that I/O times are more important.

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.

---------------------------------------
Posted through http://www.FPGARelated.com

 

[pavel.m]

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 t
do it myself I have to give more details of my design:
- crystal clock-oscillator generates single 50MHz clock, which comes int
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 i
because I use 4 lines for data output and I want to send bytes, so in on
state 4 MSB are sent, in second state 4 LSB are sent, something like this:

when WRITE_DATA_MSB =>

data3_out <= data_byte(3);
data2_out <= data_byte(2);
data1_out <= data_byte(1);
data0_out <= data_byte(0);

state <= WRITE_DATA_LSB;

when WRITE_DATA_LSB =>

data_byte <= some_new_value; --new data

state <= WRITE_DATA_MSB;

data3_out <= data_byte(7);
data2_out <= data_byte(6);
data1_out <= data_byte(5);
data0_out <= data_byte(4);

There is also condition in WRITE_DATA_MSB, when it should finish jumpin
between these two states (when some amount of data bytes will be sen
out).

That "clock", which is used also for that process, must be sent to th
external device with data. Is that topology what you calle
"Source-Synchronous" system? Then I think I should use what you recommend
push registers in the IOB, because in that topology I want minimum skew
And from what you said that registers should be:

attribute IOB : string
attribute IOB of data_byte: signal is "TRUE"; (corrected register name)

And for clock, I don't understand what is "radial clocking scheme".
couldn't find it, but I suppose that it is not what I have, because I sen
my 50 MHz clock from FPGA to the external device. So there is propagatio
delay and other factors which cause that clock on which FPGA works an
clock on external device input pin are different. If these clocks would b
the same ("radial clocking") I could use:

OFFSET = IN 6 ns VALID 8.5 ns BEFORE "clock" RISING ; (as posted before)
OFFSET = OUT 14 ns AFTER "clock" RISING; [this is corrected: 20ns(cloc
period) - 6ns(setup time requirement of external device)]

But I should somehow recalculate that values taking into account tha
delays? How?
I suppose that should be here also Clock Forwarding technique applied fo
clock sending...

Sorry that I ask also for the things that you described, but writing it i
my words and asking you if it is true make me sure that I somethin
understand or not. It is not easy subject and additional factor which make
it harder to understand is that I'm not native english speaker.

Best regards,
Pavel

---------------------------------------
Posted through http://www.FPGARelated.com