Reduce synthesis and implementation time in the VIVADO

[Mehdi1357]

Hi guys

I have an RTL design project in the VIVADO 2020 developing environment, and my implementation platform is ARTIX 7.

In my project, I have about 30 trusted and tested VHDL files and cores without the need to change. I always change one of the VHDL files and do not change the other files. It takes about one hour for synthesizing and implementing my design project for the slightest changes.

Is there a way to reduce this time?
Is it possible not to re-synthesize the code that does not need to be changed?

 

[kaz1]

That is a good question and I am struggling with vivado to do just that. According to initial information you do incremental compilation. My understanding is that you start a (mini) project per a selected lower module, compile and fit then generate DCP file. The DCP contains info on fitting for that module and is then pointed at at final top project after choosing incremental approach instead of default.
However I can't compile the lower module because it got so many io pins for the device. So what is going on? Quartus had option of virtual pins but vivado doesn't. So what are we missing here??

 

[TrickyDicky]

This is pretty normal. Just be happy you dont have 1 hour for synthesis and 4 hours for implementation on a build server.

This is a good reason to do lots of testbenching

 

[niciki]

It is not an easy task, but can be done with some assumptions and limitations.

When a design is being created using the project based flow, there is an option to enable Incremental Implementation automatic mode and have the project manage the reference checkpoint for you. This is the simplest way to make use of the Incremental Implementation flow.

Different way to go would be the DFX Flow (Dynamic Function eXchange), in older terminology it was called Partial Reconfiguration.
DFX is based on predefined partitions (PBlocks).
That PBlock (or PBlocks) defines the place on the die, where your module (or modules) will be placed after every modification with the rest of the design untouched.
It is going even further, allowing the modification of an operating FPGA design by loading a dynamic configuration to the predefined regions.

Sources:
UG904 (Vivado Design Suite User Guide, Implementation, p. 97 - Incremental Implementation).
UG909 (Vivado Design Suite User Guide, Dynamic Function eXchange);

 

[ads-ee]

That is a good question and I am struggling with vivado to do just that. According to initial information you do incremental compilation. My understanding is that you start a (mini) project per a selected lower module, compile and fit then generate DCP file. The DCP contains info on fitting for that module and is then pointed at at final top project after choosing incremental approach instead of default.
However I can't compile the lower module because it got so many io pins for the device. So what is going on? Quartus had option of virtual pins but vivado doesn't. So what are we missing here??

You don't start mini projects, you use Vivado's hiearchical design flow to isolate portions of the design into pblocks and place and route those pblocks as separate DCPs (design check points).

There is a document on this flow: https://www.xilinx.com/support/docu...nx2020_1/ug905-vivado-hierarchical-design.pdf

 

[kaz1]

You don't start mini projects, you use Vivado's hiearchical design flow to isolate portions of the design into pblocks and place and route those pblocks as separate DCPs (design check points).

There is a document on this flow: https://www.xilinx.com/support/docu...nx2020_1/ug905-vivado-hierarchical-design.pdf

OK I assumed you get DCP anyway. But to get DCP (through Out Of Context selection=OOC) within main project I encountered these issues:
1) The OOC selection was grayed on me. I realised I have to regenerate all lower ips removing their DCP then I managed to do OOC at higher level.
2) Still after selecting OOC, vivado issued error when trying to generate files. May be to do with my use of generics at that module.
3) When selecting OOC and then getting DCP, what is the point??, why would I lock a module that I have not chosen or seen its fmax?
4) Project allowed me selecting one DCP only. But I might need more.
My hope was that I will try several attempts at module level until I am happy then generate DCP to be delivered to project level.
After all some of those lower ips were having their DCP yet they failed timing at project level.

Surely this design flow is far from clear or being automated.

 

[dpaul]

@Mehdi1357 ,
Incremental synthesis and implementation is one way. If you don't change a lot of logic between consecutive runs it can significantly speed up the compile time.
Here are some useful links:
http://www.xilinx.com/video/hardware/incremental-implementation-vivado.html
http://www.xilinx.com/support/answers/57853.html
I recommend you to use automatic set-points. This can be easily turned on in 'Project Summary' window under 'Incremental Synthesis/Implementation' options.

If it is only synthesis, then ...
Run "synth_design -help" in tcl console of Vivado and you will get the options and directives to use with this command.
i.e. synth_design -effort_level quick
i.e. synth_design -directive runtimeoptimized

Note: Some run time improvements come at the expense of quality of results. This is not always the case, but turning off various optimizations will improve the run time of synthesis.

 

[kaz1]

@Mehdi1357 ,
Incremental synthesis and implementation is one way. If you don't change a lot of logic between consecutive runs it can significantly speed up the compile time.
Here are some useful links:
http://www.xilinx.com/video/hardware/incremental-implementation-vivado.html
http://www.xilinx.com/support/answers/57853.html
I recommend you to use automatic set-points. This can be easily turned on in 'Project Summary' window under 'Incremental Synthesis/Implementation' options.

If it is only synthesis, then ...
Run "synth_design -help" in tcl console of Vivado and you will get the options and directives to use with this command.
i.e. synth_design -effort_level quick
i.e. synth_design -directive runtimeoptimized

Note: Some run time improvements come at the expense of quality of results. This is not always the case, but turning off various optimizations will improve the run time of synthesis.

Thank dpaul,

For incremental flow it now appears we have two targets:
1) original post was about reducing compilation time.
2) my target is getting a good fit and passing timing then locking the module there.

Intel had an option of smart compilation which was meant to reduce compilation time for minor changes.
And for best fit it had logic lock.

So in Vivado incremental flow how do we get best fit at module level and then pass it to project. Just setting a module as "out of context" doesn't tell me what next. I imagine I will need to set a mini project at module level and get DCP but this is not so explained in Xilinx documents neither Vivado supports virtual pins.

 

[Mehdi1357]

That is a good question and I am struggling with vivado to do just that. According to initial information you do incremental compilation. My understanding is that you start a (mini) project per a selected lower module, compile and fit then generate DCP file. The DCP contains info on fitting for that module and is then pointed at at final top project after choosing incremental approach instead of default.
However I can't compile the lower module because it got so many io pins for the device. So what is going on? Quartus had option of virtual pins but vivado doesn't. So what are we missing here??

I was not familiar with the Incremental implementation before. Using it, the implementation time was reduced by half. It was a great experience for me.

Based on my searches and studies It is recommended for when the design changes are below 5%

Thanks a lot.

--- Updated Jul 19, 2021 ---

@Mehdi1357 ,
Incremental synthesis and implementation is one way. If you don't change a lot of logic between consecutive runs it can significantly speed up the compile time.


Note: Some run time improvements come at the expense of quality of results. This is not always the case, but turning off various optimizations will improve the run time of synthesis.

Thanks a lot, Incremental implementation was a great experience for me

 

[dpaul]

Thank dpaul,

For incremental flow it now appears we have two targets:
1) original post was about reducing compilation time.
2) my target is getting a good fit and passing timing then locking the module there.

Intel had an option of smart compilation which was meant to reduce compilation time for minor changes.
And for best fit it had logic lock.

So in Vivado incremental flow how do we get best fit at module level and then pass it to project. Just setting a module as "out of context" doesn't tell me what next. I imagine I will need to set a mini project at module level and get DCP but this is not so explained in Xilinx documents neither Vivado supports virtual pins.

How much is your device utilization?
Actually the tools do a good job in placing your logic and routing the nets such that timing passes. My experience says that problems for Xilinx FPGAs comes in to picture when device utilization is over 80%. In such a case, with increasing device utilization, your logic will be placed, but the tools find it increasingly difficult to route the nets in a way timing is met (that is why take time to deliver the result).
One way around this *might be* custom place and route, but I am not sure, I have never done it.
In order to "lock the module there" custom placement is recommended.

 

[kaz1]

How much is your device utilization?
Actually the tools do a good job in placing your logic and routing the nets such that timing passes. My experience says that problems for Xilinx FPGAs comes in to picture when device utilization is over 80%. In such a case, with increasing device utilization, your logic will be placed, but the tools find it increasingly difficult to route the nets in a way timing is met (that is why take time to deliver the result).
One way around this *might be* custom place and route, but I am not sure, I have never done it.
In order to "lock the module there" custom placement is recommended.

utilisation not that high:

My focus is on timing closure at project level.
For example one module passes fmax of 530MHz (Ultrascale+).
It includes fft engines. By default the fft engines being ips are set as Out Of Context by project and yet it fails timing. How can I set this OOC generation to show result and constrain it independant of project. I assume I might need to specify xdc for such module.

 

[dpaul]

How are you implementing the fft engines? Are they IP cores from Xilinx?
If they are IP cores then they will come with their own xdc file.

 

[kaz1]

How are you implementing the fft engines? Are they IP cores from Xilinx?
If they are IP cores then they will come with their own xdc file.

Yes fft engines are based on xilinx ip cores.
Interestingly the xdc file generated from Out-of-context flow is set to 10 ns (any ip in fact). but the project level apparently overrides. I tried setting it to 2.034 ns (by force editing) and timing went worse.

As a result I lost trust completely in this out-of-context flow. what is is this 10 ns and who is deciding timing? module or project. Things really don't sync between tool and documentation.