UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Scholar jprice
Scholar
577 Views
Registered: ‎01-28-2014

vu37p and opt_design hanging in Vivado 2018.3

Jump to solution

I have an experimental out of context design on a xcvu37p with Vivado 2018.3. When I was using project flow, I had no issues but I switched to non project flow to work on some timing closure challenges. Unfortunately my design appears to hang in opt_design. I reduced the amount of logic to a very tiny amount and opt_design eventually completes but after 40 minutes for a very tiny buid. For my actual build it spends hours without completeing though Im going to let it run overnight. I've tried all sorts of combinations of arguments but all of them have the same problem. opt_design hangs with the last output being "Starting Logic Optimization Task.'. For the small build which eventually completes, once it's past this "step" it finishes in less than 3 minutes. I'm a bit stumped and can't go back to the previous version fo Vivado since I can only target the ES. Does anyone have any thoughts on what I can do to work around this issue? If not I'll have to prepare a test case and open a ticket next week.

 

Thanks! 

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
553 Views
Registered: ‎03-29-2013

Re: vu37p and opt_design hanging in Vivado 2018.3

Jump to solution

There is no obvious issue based on the log file, except maybe the fact that there is 7GB physical memory left after loading the design in memory, while peak is already at 18GB, so most likely the process will have to force memory swap during opt_design or later in the flow, which slows things down. Could you check in your succesful run what the memory trend is? Look for these lines:

Time (s): cpu = 00:00:26 ; elapsed = 00:00:13 . Memory (MB): peak = 18615.891 ; gain = 0.000 ; free physical = 7011 ; free virtual = 69938

At this point of the flow, any Memory Interface (MIG) IP or Debug Core (aka Chipscope) IP will be (re)gerenated if it is found to be stale. If the IP cache is properly setup, it will try to re-use the result from the previous run. You should check a complete run to see if these phases get triggered.

Finally, are you sure you are running in out-of-context mode? At the end of synthesis, during final netlist load into memory, I can see the following line:

  IBUF => IBUF (IBUFCTRL, INBUF): 826231 instances

In non-project mode, you need to do "synth_design -mode out_of_context -top xxx" to trigger the OOC mode for the rest of the flow. If not, opt_design is probably trying to handle the huge amount of buffers (rule checks, legalization, etc...), which is something that does not take much time on a normal design where there are at most ~1k IOs.

5 Replies
Xilinx Employee
Xilinx Employee
571 Views
Registered: ‎03-29-2013

Re: vu37p and opt_design hanging in Vivado 2018.3

Jump to solution

Can you share the log file or at least past the opt_design section to this thread?

Thanks,

-Fred

0 Kudos
Scholar jprice
Scholar
568 Views
Registered: ‎01-28-2014

Re: vu37p and opt_design hanging in Vivado 2018.3

Jump to solution

Sure can! Attached the log. This is the full version of the build.

0 Kudos
Xilinx Employee
Xilinx Employee
554 Views
Registered: ‎03-29-2013

Re: vu37p and opt_design hanging in Vivado 2018.3

Jump to solution

There is no obvious issue based on the log file, except maybe the fact that there is 7GB physical memory left after loading the design in memory, while peak is already at 18GB, so most likely the process will have to force memory swap during opt_design or later in the flow, which slows things down. Could you check in your succesful run what the memory trend is? Look for these lines:

Time (s): cpu = 00:00:26 ; elapsed = 00:00:13 . Memory (MB): peak = 18615.891 ; gain = 0.000 ; free physical = 7011 ; free virtual = 69938

At this point of the flow, any Memory Interface (MIG) IP or Debug Core (aka Chipscope) IP will be (re)gerenated if it is found to be stale. If the IP cache is properly setup, it will try to re-use the result from the previous run. You should check a complete run to see if these phases get triggered.

Finally, are you sure you are running in out-of-context mode? At the end of synthesis, during final netlist load into memory, I can see the following line:

  IBUF => IBUF (IBUFCTRL, INBUF): 826231 instances

In non-project mode, you need to do "synth_design -mode out_of_context -top xxx" to trigger the OOC mode for the rest of the flow. If not, opt_design is probably trying to handle the huge amount of buffers (rule checks, legalization, etc...), which is something that does not take much time on a normal design where there are at most ~1k IOs.

Scholar jprice
Scholar
551 Views
Registered: ‎01-28-2014

Re: vu37p and opt_design hanging in Vivado 2018.3

Jump to solution

Well I was defintely doing it in project mode....but not in projectless mode. I did forget to force it when  switched over. I'm surprised at the symptom though. In the past such mistakes would quickly result in an error informing me I had an illegal amount of IO (there is far, far more IO in this out of context design than there are pins). Thanks for pointing out my clear mistake! 

0 Kudos
Xilinx Employee
Xilinx Employee
543 Views
Registered: ‎03-29-2013

Re: vu37p and opt_design hanging in Vivado 2018.3

Jump to solution

Let us know if the runtime issue does not go away after re-running in OOC mode. I'll check with engineering if we can error out sooner (very valid point)!

0 Kudos