We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Synthesis going Out-of-Date for Unrelated Changes

by Xilinx Employee on ‎06-20-2017 10:53 AM (2,034 Views)

In the project flow, Vivado keeps track of dependencies. As you invoke a particular step, the tool ensures that the previous step is complete.


For example, if you want to run implementation, Vivado will check that synthesis has been performed and completed.

Dependency management also checks that the previous step has completed with the current set of inputs. That way, the tool ensures that the previous stage’s output is not stale.


For example, say you had performed synthesis, and subsequently you modified one of the RTL files. Even though synthesis is complete, it is stale because an input was modified after synthesis.


In a Vivado context, this situation is called “Out of Date.”


Sometimes, you might see synthesis (or another step) go out of date even when you make changes that should not impact synthesis.


For example, after synthesis you add a “pblock” constraint, which does not impact synthesis. However, synthesis shows up as out of date.


This happens because of the level of granularity at which Vivado tracks dependency.


Synthesis depends on the input HDL, the XDC, and other factors. When the tool sees a change to the XDC (due to the addition of pblocks), it sees an input ingredient change. As a result, synthesis is declared to be out of date.


It does not track individual commands within the XDC, to check whether or not they impact synthesis.


The above has been designed with the philosophy of keeping the dependency tree relatively light-weight, and also to err on the side of being pessimistic.


If you encounter such a situation, go to the “Design Runs” window, right click on the synthesized view and select “Force Up to Date”. Now, you are ready to move to the next stage of the flow. Understand that you have now taken on the responsibility for ensuring that synthesis is actually valid and current.


So, when you force Synthesis to become Up-to-Date, you need to make sure that:


  • You understand the exact change made that caused the synthesis to be Out-of-Date in the first place
  • The specific change should not really impact synthesis

by Scholar ronnywebers
on ‎06-21-2017 12:29 AM

it would be great to have a list of typical/common changes that don't require to run synthesis again. 


Do the following things require you to run synthesis again?


* change PACKAGE_PIN from R19 to T11 in the xdc file

* change timing constraint, i.e. clock frequency in the xdc file


by Historian
on ‎09-14-2017 10:09 AM

I want to point out that you have some amount of control over this.


The specific example given (changing a pblock) can be done in a way such that it does not affect the "up to date" status of synthesis...


Each XDC file added to a project has a property which dictates during which processes it is required. In project mode this are the "USED_IN_SYNTHESIS" and "USED_IN_IMPLEMENTATION" properties.


If you want to isolate your synthesis from changes in constraints that only affect implementation, then set up your projects with different XDC files

  - one file that contains all timing constraints and any other constraints that are required by synthesis and implementation

      - leave the USED_IN... at the default value, which is both USED_IN_SYNTHESIS and USED_IN_IMPLEMENTATION

  - on file that contains only physical constraints

       - these include:

         - I/O locatitions and attributes (I/O standards, drive strength, etc...)

         - internal LOC constraints

         - PBLOCK constraints

       - set only the "USED_IN_IMPLEMENTATION" on this file (and don't set "USED_IN_SYNTHESIS")


With this setup, any change you make to the XDC file that is marked as only "USED_IN_IMPLEMENTATION" will not cause the synthesis to go out of date - the dependency management system in Vivado pays attention to these properies.



About the Author
  • Balachander Krishnamurthy is a Sr. Product Marketing Manager for SDSoC. His responsibilities include product planning, inbound and outbound marketing for Xilinx’s Vivado SDx Design Software. Bala holds a Master's degree in Electrical Engineering from San Jose State University. He has worked at Sun Microsystems and Altera for several years in multiple roles in verification, RTL design, first silicon and board bring-up and as an ASIC Product Manager. He has more than 17 years’ experience in the GPU, CPU, ASIC and FPGA industries. His current focus is FPGA methodology for synthesis, implementation and timing closure.
  • Sanjay is Senior Director, Software Validation, at Xilinx, where he and his team validate the company’s Vivado and SDx tool chains. For more than 20 years, Sanjay has worked in EDA and VLSI in India as well as in Silicon Valley in the United States. He has worked extensively on library characterization and modeling, HDLs (focusing more on Verilog than VHDL), simulation, synthesis, static timing analysis, power, clock domain crossing and synchronization, and rule checker-based verification. Sanjay has been learning Vivado in recent years. He has published three books as co-author and editor: Principles of VLSI RTL Design – A Practical Guide, Constraining Designs for Synthesis and Timing Analysis – Using Synopsys Design Constraints, and Designing with Xilinx FPGAs – Using Vivado. In addition, Sanjay has written numerous articles and papers for trade journals and conferences. He holds three patents related to clock gating and isolation cells. A resident of Hyderabad in India, Sanjay is a graduate of the India Institute of Technology Kharagpur in electronics and electrical communications engineering.