cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
876 Views
Registered: ‎08-28-2019

Built-in FIFO, common clock, can't select the clock frequency from the generator

When using the FIFO generator to create a common-clock FIFO there is no option for selecting the operating frequency. The resulting out-of-context FIFO defaults to a 10ns/100MHz clock (shows up in the ...ooc.xdc, as well as the ...vhd) whereas my system clock is 4ns/250MHz - to there is a warning about it being synthesized at a different frequency than the one it is used in.

Other than selecting independant clocks and making both clocks the same frequency, how does someone change the clock? It does not appear that I can edit the vhd or xdc files and get the result I am looking for.

Regards,

Bob

0 Kudos
6 Replies
drjohnsmith
Teacher
Teacher
866 Views
Registered: ‎07-09-2009

The trick is the hierachy of constraints,

The IPs timming constraint is read first,

   but in your constraints you also have constraint on the clock that goes to the fpga.

     Your timming clock constraint then overrules the IP constraint, 

I think there is a warning message to this effect when it happens burried in the reports , just dont ask where !

The reason its done this way, is to make the IP re usable,

     To do the initial build of the IP, the tools need a timing constraint, The default is as you say 100 MHz,

then when its used in different designs , the constraints for that design over ride the local IP constraint

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
817 Views
Registered: ‎08-28-2019

I would tend to agree with you that the FIFO's constraints would be overridden. But, that is not what I am observing: the high-level constraint does not appear to be overriding the FIFO's constraint when "common" clocking is selected when building the FIFO, and thus the error/warning/caution - that the FIFO is synthesized at a different clock frequency as the system/logic that is using it.

If I select "independent clocks" and I make the input and output clocks the same frequency (and connect the same clock to both of them) when I synthesize the tool sees that they are common, implements the fifo as a common-clock FIFO - and there are no warnings generated. And, since the clock frequency I used in the generator is the same as the system-clock rate - it has synthesized the FIFO at the higher system clock rate.

0 Kudos
793 Views
Registered: ‎01-22-2015

bob.wittosch@hellastorm.com 

Other than selecting independant clocks and making both clocks the same frequency, how does someone change the clock? It does not appear that I can edit the vhd or xdc files and get the result I am looking for.
Many of the Xilinx IP do not allow us to specify the target frequency for OOC synthesis.  Perhaps this is because synthesis does not depend strongly on frequency for these IP.

Here are some things to remember:

1) Synthesis is only “timing aware”.  That is, with a target frequency, synthesis will sometimes do things in a way that it thinks will help the design pass timing analysis.  However, it is implementation that does the really important things to help your design pass timing analysis.  During implementation, target frequency is replaced by actual clock frequency from your design.

2) If you use OOC synthesis, then your IP could be synthesized with the default (and probably wrong) target frequency.  Later, if you have properly defined/constrained the clocks and if implementation says your design passes timing analysis then your design has really passed timing analysis (even though synthesis used the wrong target frequency).  However, if implementation says your design failed timing analysis then see 3)-below.

3) If you turn-off OOC synthesis then your IP will be synthesized using the actual clock frequency from your design – and will thus be synthesized with the correct target frequency.  This can sometimes (but rarely in my experience) cause a design to pass timing analysis that has otherwise failed timing analysis with OOC synthesis turned-on.

Mark

0 Kudos
731 Views
Registered: ‎08-28-2019

Mark,
I appreciate your reply and have a couple of comments to it (your text in italics):

Many of the Xilinx IP do not allow us to specify the target frequency for OOC synthesis.  Perhaps this is because synthesis does not depend strongly on frequency for these IP.

You may be able to say that if Xilinx and other IP vendors over-design their IP so that the "masses" using it will not run into timing issues but coming from the ASIC world: frequency has significant impact on your ability to close timing, has a significant impact on logic-area (as the faster the logic is driven the more buffering for loading/fanout/etc required), and can never be removed from the flow.

Here are some things to remember:

1) Synthesis is only “timing aware”.  That is, with a target frequency, synthesis will sometimes do things in a way that it thinks will help the design pass timing analysis.  However, it is implementation that does the really important things to help your design pass timing analysis.  During implementation, target frequency is replaced by actual clock frequency from your design.

Yes, synthesis will push clocks (useful skew) to allow larger logic cones between clock edges, but as you say - the implementation must address these timing failures by pipelining/buffering/etc, but the only way you know to make these changes is to synthesize all components, especially IP, at the appropriate target frequency. More often than I'd like I've had timing challenges interfacing to IP - we are only as good as the designers of that IP have taken care to concern theirselves with input/output latencies/logic-levels/loading, etc.

2) If you use OOC synthesis, then your IP could be synthesized with the default (and probably wrong) target frequency.  Later, if you have properly defined/constrained the clocks and if implementation says your design passes timing analysis then your design has really passed timing analysis (even though synthesis used the wrong target frequency).  However, if implementation says your design failed timing analysis then see 3)-below.

I think you are missing the basic point: there should be no reason why the customer doesn't have the ability to modify the target frequency of the IP they are integrating. There should be a setting in the IP configuration, or the ability to change an XDC/SDC, that would allow that IP to run at the customer's target frequency, even if that target changes between projects.

(I messed up here by hitting the "Quote" button to see what it does)


markg@prosensing.com wrote:

bob.wittosch@hellastorm.com 

Other than selecting independant clocks and making both clocks the same frequency, how does someone change the clock? It does not appear that I can edit the vhd or xdc files and get the result I am looking for.
Many of the Xilinx IP do not allow us to specify the target frequency for OOC synthesis.  Perhaps this is because synthesis does not depend strongly on frequency for these IP.

Here are some things to remember:

1) Synthesis is only “timing aware”.  That is, with a target frequency, synthesis will sometimes do things in a way that it thinks will help the design pass timing analysis.  However, it is implementation that does the really important things to help your design pass timing analysis.  During implementation, target frequency is replaced by actual clock frequency from your design.

2) If you use OOC synthesis, then your IP could be synthesized with the default (and probably wrong) target frequency.  Later, if you have properly defined/constrained the clocks and if implementation says your design passes timing analysis then your design has really passed timing analysis (even though synthesis used the wrong target frequency).  However, if implementation says your design failed timing analysis then see 3)-below.

3) If you turn-off OOC synthesis then your IP will be synthesized using the actual clock frequency from your design – and will thus be synthesized with the correct target frequency.  This can sometimes (but rarely in my experience) cause a design to pass timing analysis that has otherwise failed timing analysis with OOC 


Sure, and this is what I ended up doing, but as you build (configure) IP that you want to re-use, having it in separate project directories gives it more control, configurability, and reproducibility (becomes a library/repo element) thus the OOC flow. Xilinx should just change the way they handle IP and allow the customer the option to control how involved they want to be in driving the implementation through the synthesis/timing phases.

Thanks,
Bob

0 Kudos
drjohnsmith
Teacher
Teacher
725 Views
Registered: ‎07-09-2009

"I think you are missing the basic point: there should be no reason why the customer doesn't have the ability to modify the target frequency of the IP they are integrating. There should be a setting in the IP configuration, or the ability to change an XDC/SDC, that would allow that IP to run at the customer's target frequency, even if that target changes between projects."

 

That is the point, the tools do that,

    your constraint in the XDC file over rules the one in the IP ,

There is no need to change th elocal XDC file for the IP.

 

This has come form the ASIC world, where the deisng flows contian the constraints,

the big difference here is this is an FPGA, the options are much less, ( e.g. we can not change transistor size ! )

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
709 Views
Registered: ‎01-22-2015

bob.wittosch@hellastorm.com 

     …there should be no reason why the customer doesn't have the ability to modify the target frequency of the IP they are integrating.
I agree with you.  However, that fact is that many Xilinx IP do not allow you to specify the target clock period/frequency for synthesis (see discussion on page 41 of UG896 (v2019.1)). 

We only need to worry about target clock period for synthesis if we’re using OOC synthesis.  If we’re not using OOC synthesis, then (in Vivado) the IP will be synthesized using the actual clock period/frequency from our design (and not some default clock period). 

Finally, Vivado implementation will always use the actual clock period/frequency from our design.