Xilinx Timing Constraings
Rob Gaddi
something that, to my mind, ought to be pretty simple. I'm connected to
an external synchronous logic chip. For now let's call it a regular
74HC74 flip flop, but the details are unimportant. My FPGA outputs D
and CLK to the 74HC74, and reads back Q.
The FPGA has a single global clock net, call it SysClk. I've got a
state machine running on SysClk generating both data and clock for this
widget; the clock is running at a sufficiently low rate that it's being
generated by a simple, rising-edge only, divide-by-N from my master
clock. My logic defines both D and CLK in a way that they're registered
outputs and Q as a registered input with no logic; such that all of them
should be able to be pushed into the IOBs.
The 74HC74 datasheet tells me that I've got setup time (Ts), hold time
(Th), and clock-to-output delay (Tcko). How do I go about communicating
these requirements to the Xilinx toolchain? Clearly it's some
combination of OFFSET constraints, but what are the magic words?
UG612 discusses the use of the REFERENCE_PIN qualifier to indicate that
the output data is referred to the output clock, but the example doesn't
give any advice that would connect those OFFSET constraints to only
define the relationship between D and CLK, not the entire world and CLK.
And I can't seem to find any information whatsoever that would let me
define the relationship between CLK and Q.
I've gone through the Constraints Guide. I've gone through UG612. I've
gone through Austin's 5 part series over on the Xilinx forums. And I'm
still lost. Anyone have any revelations for me?
--
Rob Gaddi, Highland Technology
Email address is currently out of order
Gabor
Basically, you are using a source synchronous output clock to your
flip-flop. There is no constraint to my knowledge that would do
the job you're looking for which is to define the relative timing
on two outputs. This should be correct by design. i.e. if you
push both CLK and Q outputs into IOB flops, using DDR flops if
necessary for the clock, you should have essentially zero timing
difference between CLK and Q if they are switching on the same
edge of the same global clock. Make your Tsu and Th based on
the relative timing to the IOB flops, for example making CLK
go high on the falling edge of the internal clock and changing
Q on the next rising edge to get 1/2 cycle of hold time.
HTH,
Gabor
Christian Widtmann
Hi!
Gabor is right with that there is no constraint that will ensure and
check the setup/hold time that your external FF requires. As he already
said, use an ODDR block to pass your clock on to the external FF, it is
described in the user manual of the FPGA.
You can create a timing report though that gives you the relative output
delay between clock and data, which will enable you to confirm the setup
time for your external FF manually. For this, create a timing group
containing only the CLK and D pin and apply an OFFSET OUT constraint
with reference pin CLK relative to the internal SysClk. This will give
you the report in the .twr file. If the timing is not sufficient, you
can delay either CLK or D by an IODELAY or ODELAY block, which is
described in the FPGA user manual or the HDL library guide.
To constrain and ensure the capture of Q, create a timing group
containing only Q and apply an OFFSET IN BEFORE constraint to it,
relative to your capturing clock, and specify the setup and hold time
that your external FF output signal will exhibit when it is clocked with
the timing as reported by the OFFSET OUT contraint and the external FF
datasheet. You will have to perform this analysis manually (and
theoretically also consider board delays and skews), but if the OFFSET
IN constraint holds and represents the real behavior, your design will
work. Again, you may manually fix a timing violation by an IODELAY or
IDELAY instance on the input pin.
There is also a Timing Constraint guide that you can look for at the
Xilinx homepage, it should provide you with the exact syntax.
Hope I gave you the right keywords ...
Christian
Rob Gaddi
I was afraid that was the answer. Unfortunately I'm running into a
miserable time of things with that answer. I've got 16 pins being
driven from identical signals (the SCLK for 16 simultaneous ADCs). I'm
turning on a few optimizations in the MAP stage in order to try to get
some of the resource count down, including equivalent_register_removal.
Unfortunately, this means that my 16 SCLKs are being equivalented down
to only one flip-flop, which then fails MAP because it can no longer
perform the IOB=FORCE. Basically, the tool cleverly decides to optimize
down my logic without checking to see what constraints it's under.
I went through the Spartan 6 HDL libraries, figuring I'd just give up on
pretty code and instantiate an OFD like I would have on a Spartan 3. No
such luck; they've pulled it out of the library. There's an ODDR, but
that claims to need both of the clocks connected to it. There's an OFD
in the schematic library, but you can't reference it from VHDL.
Turning off equivalent_register_removal doesn't work, because my design,
while only 80% full on LUTs, claims to have no place to place the rest
and fails. And turning off equivalent_register_removal locally in the
entity under question doesn't work, because the tools just flat out
ignore me. This is, of course, all under ISE 11.5. Under version 12.1
the synthesis builds to take 10% more LUTs, making the design even more
unplaceabler.
So many walls, so little time to beat my head against each one.
Brian Drummond
wrote:
>> Basically, you are using a source synchronous output clock to your
>> flip-flop. There is no constraint to my knowledge that would do
>> the job you're looking for which is to define the relative timing
>> on two outputs. This should be correct by design. i.e. if you
>> push both CLK and Q outputs into IOB flops, using DDR flops if
>> necessary for the clock, you should have essentially zero timing
>> difference between CLK and Q if they are switching on the same
>> edge of the same global clock. Make your Tsu and Th based on
>> the relative timing to the IOB flops, for example making CLK
>> go high on the falling edge of the internal clock and changing
>> Q on the next rising edge to get 1/2 cycle of hold time.
>>
>> HTH,
>> Gabor
>
>I was afraid that was the answer. Unfortunately I'm running into a
>miserable time of things with that answer. I've got 16 pins being
>driven from identical signals (the SCLK for 16 simultaneous ADCs). I'm
>turning on a few optimizations in the MAP stage in order to try to get
>some of the resource count down, including equivalent_register_removal.
You should be able to attach an "equivalent-register-removal=no" attribute to
the specific signal in VHDL source, and it should override the global setting
(tools issues apart; i haven't tried on S6).
I don't know if UCF would work - I put it in the source to prevent synthesis
being too clever...
But the documentation doesn't exactly make it obvious that you can override the
(useful) global setting...
>And turning off equivalent_register_removal locally in the
>entity under question doesn't work, because the tools just flat out
>ignore me. This is, of course, all under ISE 11.5. Under version 12.1
>the synthesis builds to take 10% more LUTs, making the design even more
>unplaceabler.
Try it on the signal...
unfortunately you probably can't go back to ISE10, where it works...
- Brian
Rob Gaddi
Alas, no such luck. Tried putting it on the signal in the VHDL, MAP
went along and happily disregarded it come optimization time.
Next step was to turn on KEEP_HIERARCHY on the affected entities in the
UCF. MAP doesn't like that either, and forces me to to turn on the
undocumented XIL_MAP_KEEP_KH_ON_TERMINAL_BLOCKS environment variable in
order to even attempt to build the design. Having done that, MAP again
disregards me, merges the signals, and then complains that it can't fit
the merged signals into IOBs.
Gabor
If you have only a limited number of registers you want to prevent
equivalent removal on, you can work around it by making them
different (slightly) so they cannot be considered equivalent.
For example, usually the behavior right after configuration is
not very important, so I would make a shift register on my
reset signal and use a different bit to reset each of the
otherwise equivalent registers.
regards,
Gabor
Brian Davis
>
> I went through the Spartan 6 HDL libraries, figuring I'd just give up on
> pretty code and instantiate an OFD like I would have on a Spartan 3. No
> such luck; they've pulled it out of the library. There's an ODDR, but
> that claims to need both of the clocks connected to it. There's an OFD
> in the schematic library, but you can't reference it from VHDL.
>
will be properly translated by map regardless of whether they
are in the specific family libraries guide.
Try using instantiated FD 's or FDxE 's with LOC constraints
to put them into the IOBs ( disclaimer: haven't tried this with
12.x & S6, it has worked in older V4/V5 designs )
If you need to use the ODDR's, past families with two clock
inputs on the DDR primitives have worked using a single global
clock net - create a locally inverted clock signal in the HDL which
then should be optimized into a local clock inversion in the IOB
register structure. Or just use two global clocks.
Brian
Sergio
>
> - Show quoted text -
I had a similar problem recently. Using the SAVE attribute prevented
MAP from optimizing my logic away, even with increased effort level.
You can look it up in the XST manual to see the details.
Regards,
Sergio
Jonathan Bromley
>I'm no luck figuring out how to implement the timing constraints for
>something that, to my mind, ought to be pretty simple.
[source-synchronous timing, as pointed out by Gabor]
>I've gone through the Constraints Guide. I've gone through UG612. I've
>gone through Austin's 5 part series over on the Xilinx forums. And I'm
>still lost. Anyone have any revelations for me?
This is kinda easy to do with Altera Timequest. There are
some distinctly non-trivial wrinkles with Timequest but,
whenever Ie tried it, I got really good results without
needing any manual-instantiation or set-dont-touch crud.
I'm slightly surprised that it's so hard to get X to do it.
But then it's always been a source of amazement to me that
the documentation on UCF constraints language was so hard
to get at. Timequest documentation is only a little
better, but tends to rely on the idea that people already
know the Synopsys constraints language and can extrapolate
from that. UCF is like nothing else, so nothing else helps.
<sigh of exasperation>
--
Jonathan Bromley