Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎11-13-2009

Clock Period specified during out-of-context, how to change?

So I use a lot of Xilinx IP blocks and instantiate them in my RTL code; often because it is challenging to infer them.


So I recently was working on a project where I created a FIFO, Divider and Accumulator as an example.  Each of those blocks are pretty straight forward to configure.  But one thing stuck out at me about the resulting configuration.  I received the following warning message in Synthesis:


Timing 38-316 Clock period "10.00" specified during outp of context synthesis of instance...


Have in the past ignored this but the design I am working on now has a clock period of 2.5ns and I am failing timing.  Now I see that in the XCI file there is an entry for "FREQ_HZ" often times for each interface.  But changing the XCI file just bring up the "Locked IP run Report Status" message.  If you accept the "update" then the values get changed back.


So what is the PREFERED way to do this?

Thanks so much


0 Kudos
2 Replies
Registered: ‎01-22-2015

Hi Tom,


   Timing 38-316 Clock period "10.00" specified during outp of context synthesis of instance...


This warning is about the target-clock-period (ug896, pg41) used by OOC synthesis. This target-clock-period is specified in an OOC XDC constraints file that is automatically-generated when the IP files are created. The target-clock-period is needed because OOC synthesis is done separately from synthesis for your project and hence the actual clocks in your project are not yet known. As explained by avrumw in <this post> synthesis uses the target-clock-period to make decisions that can help your design achieve timing closure. So ideally, you should manually edit the OOC XDC constraints file and make the target-clock-period equal to the actual-clock-period from your project.   Doing this is not as simple as it sounds and guidance is given by ug896.  However,  <this post> shows that the ug896 guidance is not currently working for some IP (BRAM) and that vemulad has taken action to correct this.  A workaround is described by vemulad that involves managing the IP yourself (rather than letting Vivado manage the IP) – but this was too scary for me to use.


Finally, OOC synthesis is normally used during project development - a time for me when many things are uncertain.  So, during development I ignore the 38-316 warning - as you did.  After development, I turn off OOC synthesis (ie. use Globl synthesis) so that actual project clocks are used for IP synthesis (as I explained above).




Tags (1)
Registered: ‎05-18-2020

Thank you!

Quick side note for others having the problem: Follow this post to disable "Out of context" (OOC) synthesis and enable "Global" synthesis:
Right-click IP core, in Project Manager Source Window, select "Generate Output Products", select "Global" in the section "Synthesis Options".
(repeat for every IP that causes problems or every IP in general)

This will very likely increase synthesis time, so probably it might be a good idea to ignore the error until you run into problems or finalize the project...

0 Kudos