LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW FPGA 2020 timing not analyzed against multicycle path constraint

Solved!
Go to solution

Hello,

 

I am targeting a PXIe-7821R FPGA board and am using component level IP (CLIP) to instantiate and compile my VHDL source code within a timed loop operating at 64MHz.  A 64kHz enable is generated with a Tick Count comparing the timed loop to 1000.  This is fed into my CLIP's enable input. 

 

At the end of compilation LabVIEW reports a failure due to timing violations.  When I examine the timing violations, the timing constraint shows a 15.625ns period as expected with a very long combinational path between the source and destination with a total delay of about 50ns.  This is expected.  However, when I create a multicycle path constraint and save it in an xdc file, the constraint seems to get applied (because it doesn't show up in the unapplied_constraints report), but timing still fails, almost as if the timing analysis doesn't take into account the multicycle path constraint.  Other constraints which I know have errors in the same xdc file are not getting applied as expected, so I know the same xdc file is being read.

 

Here is the constraint:

set_multicycle_path -from [get_pins -hierarchical -filter {NAME =~ */u_AZ_FPGA_inst/Goto3_bypass_reg*/C}] -to [get_pins -hierarchical -filter {NAME =~ */u_Analog_Dithering*/u_MATLAB_Function/*/*D}] 5
set_multicycle_path -hold -from [get_pins -hierarchical -filter {NAME =~ */u_AZ_FPGA_inst/Goto3_bypass_reg*/C}] -to [get_pins -hierarchical -filter {NAME =~ */u_Analog_Dithering*/u_MATLAB_Function/*/*D}] 4

 

I have compiled the design in Vivado 2019.1 using the source code produced by LabVIEW FPGA in the source_files directory.  These files are encrypted vhd files.  The use of the constraint and apply_constraints followed by update_timing shows a slightly different path that also fails timing,  The path shows the source is prior to the Goto3_bypass_reg flip flop specified in the constraint.

 

When I look at the toplevel_gen.twr timing report, the path shows the correct source and destinations, but a failing path, as if the multicycle path constraint isn't getting applied during timing analysis.

 

How to I ensure that a multicycle path constraint is used during timing analysis, so that the compile process doesn't fail and so a bit file is produced?

 

 

0 Kudos
Message 1 of 2
(1,111 Views)
Solution
Accepted by topic author Sneed123

Although I have not been able to understand why the tools didn't seem to analyze the compiled design against the multicycle timing constraint I gave it, I have found a work around solution that may be better. I have 'partitioned' the design into two single cycle loops to separate the clock domains per the recommendations in the online help here "Using Single-Cycle Timed Loops to Optimize FPGA VISs (FPGA Module)". This allowed me to clock the slower loop at 1/10th the clock rate and meet timing.

0 Kudos
Message 2 of 2
(1,060 Views)