cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
5,521 Views
Registered: ‎09-11-2010

Synthesis in 2017.2 seems to hang

I just upgraded from Vivado 2016.2 to 2017.2 and migrated my project.  After about 1 hour and 45 minutes I receive a message that indicates that synthesis was successful with 0 errors and 800 warnings,  but the interface continues to indicate that it is running.  I checked task manager and Vivado  is showing with a single process using minimal CPU.  Typically, I see 2 processes with one consuming about 26%.  I left it running for a total of 5 hours without it completing.  I checked the known issues with 2017.2 and did not see anything that looked like this issue.

 

I am running windows 10 and running synthesis for Avnet Kintex-Ultrascale Development Board (xcku040-fbva676-1-c).

 

Any help would be appreciated.

 

Thanks

0 Kudos
18 Replies
Highlighted
Moderator
Moderator
5,514 Views
Registered: ‎09-15-2016

Hi @tloesch

 

Can you try enabling multithreading and see if it helps. Check the below link, page 1419 for this:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_2/ug835-vivado-tcl-commands.pdf

 

Regards

Rohit

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

 

Regards
Rohit
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

0 Kudos
Highlighted
Moderator
Moderator
5,511 Views
Registered: ‎09-15-2016

Hi @tloesch,

 

>>I receive a message that indicates that synthesis was successful... but the interface continues to indicate that it is running.

Did you check the runme.log to confirm this?

 

How about other designs/example designs? Does it show the same behavior?

Or is this design specific issue?

 

Thanks & Regards,
Prathik
-----------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helps to resolve your query.
Helpful answer -> Give Kudos
-----------------------------------------------------------------------------------------------

 

0 Kudos
Highlighted
Participant
Participant
5,503 Views
Registered: ‎09-11-2010

Thanks for the quick response.  I restarted Synthesis and checked the task manager and there are currently 4 Vivado processes running. So I would assume that multithreading is enabled.  In 2016.2 I usually only saw 2 processes.

 

 

Thanks

 

0 Kudos
Highlighted
Participant
Participant
5,052 Views
Registered: ‎09-11-2010

Here is the message that was recorded runme.log.

---------------------------------------------------------------------------------
Finished Writing Synthesis Report : Time (s): cpu = 01:38:13 ; elapsed = 01:45:46 . Memory (MB): peak = 10557.238 ; gain = 10250.730
---------------------------------------------------------------------------------
Synthesis finished with 0 errors, 0 critical warnings and 884 warnings.

 

I reran Synthesis updating the strategy from Vivado Synthesis Default (Vivado Synthesis 2016) to Vivado Synthesis Default (Vivado Synthesis 2017).  This time it did complete.  Below is the runme.log.

 

---------------------------------------------------------------------------------
Finished Writing Synthesis Report : Time (s): cpu = 01:40:49 ; elapsed = 01:50:13 . Memory (MB): peak = 10558.230 ; gain = 10250.973
---------------------------------------------------------------------------------
Synthesis finished with 0 errors, 0 critical warnings and 884 warnings.
Synthesis Optimization Runtime : Time (s): cpu = 01:36:52 ; elapsed = 01:48:11 . Memory (MB): peak = 10558.230 ; gain = 8932.027
Synthesis Optimization Complete : Time (s): cpu = 01:40:49 ; elapsed = 01:50:31 . Memory (MB): peak = 10558.230 ; gain = 10250.973
INFO: [Project 1-571] Translating synthesized netlist
INFO: [Netlist 29-17] Analyzing 44601 Unisim elements for replacement
INFO: [Netlist 29-28] Unisim Transformation completed in 24 CPU seconds
INFO: [Project 1-570] Preparing netlist for logic optimization
INFO: [Opt 31-138] Pushed 0 inverter(s) to 0 load pin(s).
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_10 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_2 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_3 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_4 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_5 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_6 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_7 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_8 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_9 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel1/BestMoves/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel1/BestMoves/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel1/Evaluate_Move/CheckSumSave/RegArray_reg has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel2/BestMoves/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel2/BestMoves/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel2/Evaluate_Move/CheckSumSave/RegArray_reg has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel3/BestMoves/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel3/BestMoves/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel3/Evaluate_Move/CheckSumSave/RegArray_reg has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel4/BestMoves/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel4/BestMoves/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel4/Evaluate_Move/CheckSumSave/RegArray_reg has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Project 1-111] Unisim Transformation Summary:
  A total of 38205 instances were transformed.
  IBUF => IBUF (IBUFCTRL, INBUF): 3 instances
  RAM32M16 => RAM32M16 (RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMS32, RAMS32): 40 instances
  RAM32X1S => RAM32X1S (RAMS32): 38162 instances

1038 Infos, 409 Warnings, 0 Critical Warnings and 0 Errors encountered.
synth_design completed successfully
synth_design: Time (s): cpu = 01:44:51 ; elapsed = 01:54:42 . Memory (MB): peak = 10558.230 ; gain = 10265.332
INFO: [Common 17-1381] The checkpoint 'C:/Lochess_16_2/Search/Search.runs/synth_1/SearchMain.dcp' has been generated.
write_checkpoint: Time (s): cpu = 00:02:24 ; elapsed = 00:01:19 . Memory (MB): peak = 10558.230 ; gain = 0.000
report_utilization: Time (s): cpu = 00:00:04 ; elapsed = 00:00:05 . Memory (MB): peak = 10558.230 ; gain = 0.000
report_utilization: Time (s): cpu = 00:00:04 ; elapsed = 00:00:05 . Memory (MB): peak = 10558.230 ; gain = 0.000
INFO: [Common 17-206] Exiting Vivado at Fri Aug 18 10:34:20 2017...

0 Kudos
Highlighted
Participant
Participant
5,471 Views
Registered: ‎09-11-2010

Below are the messages from runme.log.

 

---------------------------------------------------------------------------------
Finished Writing Synthesis Report : Time (s): cpu = 01:38:13 ; elapsed = 01:45:46 . Memory (MB): peak = 10557.238 ; gain = 10250.730
---------------------------------------------------------------------------------
Synthesis finished with 0 errors, 0 critical warnings and 884 warnings.

 

I restarted synthesis updating the strategy from Vivado Synthesis Default (Vivado Synthesis 2016) to Vivado Synthesis Default (Vivado Synthesis 2017) and it completed successfully.   Below is the ending part of the log.

 

---------------------------------------------------------------------------------
Finished Writing Synthesis Report : Time (s): cpu = 01:40:49 ; elapsed = 01:50:13 . Memory (MB): peak = 10558.230 ; gain = 10250.973
---------------------------------------------------------------------------------
Synthesis finished with 0 errors, 0 critical warnings and 884 warnings.
Synthesis Optimization Runtime : Time (s): cpu = 01:36:52 ; elapsed = 01:48:11 . Memory (MB): peak = 10558.230 ; gain = 8932.027
Synthesis Optimization Complete : Time (s): cpu = 01:40:49 ; elapsed = 01:50:31 . Memory (MB): peak = 10558.230 ; gain = 10250.973
INFO: [Project 1-571] Translating synthesized netlist
INFO: [Netlist 29-17] Analyzing 44601 Unisim elements for replacement
INFO: [Netlist 29-28] Unisim Transformation completed in 24 CPU seconds
INFO: [Project 1-570] Preparing netlist for logic optimization
INFO: [Opt 31-138] Pushed 0 inverter(s) to 0 load pin(s).
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_10 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_2 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_3 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_4 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_5 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_6 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_7 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_8 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell PrincipleVarient/PVarient/RegArray_reg_9 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel1/BestMoves/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel1/BestMoves/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel1/Evaluate_Move/CheckSumSave/RegArray_reg has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel2/BestMoves/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel2/BestMoves/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel2/Evaluate_Move/CheckSumSave/RegArray_reg has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel3/BestMoves/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel3/BestMoves/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel3/Evaluate_Move/CheckSumSave/RegArray_reg has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel4/BestMoves/RegArray_reg_0 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel4/BestMoves/RegArray_reg_1 has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Opt 31-422] The CLOCK_DOMAINS attribute on the BRAM cell SearchParallel4/Evaluate_Move/CheckSumSave/RegArray_reg has been changed from INDEPENDENT to COMMON to match the clocking topology used for the BRAM.
INFO: [Project 1-111] Unisim Transformation Summary:
  A total of 38205 instances were transformed.
  IBUF => IBUF (IBUFCTRL, INBUF): 3 instances
  RAM32M16 => RAM32M16 (RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMD32, RAMS32, RAMS32): 40 instances
  RAM32X1S => RAM32X1S (RAMS32): 38162 instances

1038 Infos, 409 Warnings, 0 Critical Warnings and 0 Errors encountered.
synth_design completed successfully
synth_design: Time (s): cpu = 01:44:51 ; elapsed = 01:54:42 . Memory (MB): peak = 10558.230 ; gain = 10265.332
INFO: [Common 17-1381] The checkpoint 'C:/Lochess_16_2/Search/Search.runs/synth_1/SearchMain.dcp' has been generated.
write_checkpoint: Time (s): cpu = 00:02:24 ; elapsed = 00:01:19 . Memory (MB): peak = 10558.230 ; gain = 0.000
report_utilization: Time (s): cpu = 00:00:04 ; elapsed = 00:00:05 . Memory (MB): peak = 10558.230 ; gain = 0.000
report_utilization: Time (s): cpu = 00:00:04 ; elapsed = 00:00:05 . Memory (MB): peak = 10558.230 ; gain = 0.000
INFO: [Common 17-206] Exiting Vivado at Fri Aug 18 10:34:20 2017...

 

At this point it seems to be running.  Not sure why it kept hanging after the first complete message.  

0 Kudos
Highlighted
Moderator
Moderator
5,434 Views
Registered: ‎09-15-2016

Hi @tloesch,

 

Thanks for the log and information.

 

Actually I did not get one of your points >>[updating the strategy from Vivado Synthesis Default (Vivado Synthesis 2016) to Vivado Synthesis Default (Vivado Synthesis 2017) and it completed successfully]

 

So did changing strategy to default one in 2017.2 helped? or is one of the strategy causing the hang?

 

Thanks & Regards,
Prathik
-----------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helps to resolve your query.
Helpful answer -> Give Kudos
-----------------------------------------------------------------------------------------------

0 Kudos
Highlighted
Participant
Participant
5,417 Views
Registered: ‎09-11-2010

It appeared that changing the strategy from the 2016.2 migrated strategy to the default 2017.2 strategy made a difference, but it now appears that the issue is intermittent.  When I attempted another synthesis it hung at the same spot again.

 

Any help would be appreciated.

 

Thanks

0 Kudos
Highlighted
Moderator
Moderator
5,395 Views
Registered: ‎09-15-2016

Hi @tloesch,

Thanks for the information.

 

Is it possible for you to share the design with the community? Before that, can you please attach the environment variable report to check the system. Here is the TCL command for that. 

report_environment -file C:/<any_path>/env.txt

 

Let us know if that is possible as it will help us further debug this issue. Did you check other designs/example designs?

0 Kudos
Highlighted
Observer
Observer
5,190 Views
Registered: ‎08-29-2017

I'm getting the same intermittent hang in Synthesis. I can clear it by exiting and then restarting Vivado. Cancelling and restarting synthesis just results in another hang.

I'm new to FPGAs and have been making minor changes to the Tutorials for the Arty:

https://github.com/Digilent/Arty/tree/master/Projects/GPIO


I also encountered this in two other designs, the Microblaze example synthesis, and the demo here, modified for the Arty pins:

https://www.xilinx.com/support/documentation/university/Vivado-Teaching/HDL-Design/2013x/Nexys4/Verilog/docs-pdf/Vivado_tutorial.pdf

In all these cases the behavior was the same. Synthesis which normally completed in a minute or so, took many minutes, and after enough time passed (say 10 to 15 minutes), I cancelled and restarted synthesis (hoping that would clear it), then after that did a full exit and restart of synthesis and then it took less than a minute again.

I also get CPU usage during the hang that is very low, 25 to 35% of the CPU.. When synthesis runs successfully, it always uses all of my CPU.

So it appears to me that I'm seeing exactly the same hang. It is happening to me about 1/3 to 1/4 of the time I make any changes.

0 Kudos
Highlighted
Observer
Observer
4,890 Views
Registered: ‎08-29-2017

Here's the trivial design, one verilog file plus constraints that just turn on the leds and switches.


`timescale 1ns / 1ps

module first_system(
output [3:0]led,
input [3:0]sw
);

assign led[0] = sw[0];
assign led[1] = sw[1];
assign led[2] = sw[0] | sw[1];
assign led[3] = sw[0] & sw[1] & sw[2] & sw[3];

endmodule


This sometimes hangs in synthesis, sometimes in implementation and sometimes generating the bitstream.

So far, programming the device has always worked once I have a bitstream. I've been making trivial changes to the combinatorial logic and then resynthesizing to see if I can nail down what is happening.

Sometimes, changing a preference will fix the problem. Once I unchecked the "opt_design" "is_enabled" checkbox and it worked when I restarted implementation.

I have attached a .zip of my project files with all the cache and run directories for once instance where exiting and restarting Vivado didn't help

The interface and functionality seem good but the stability is terrible so far for me. Unusably unstable.

0 Kudos
Highlighted
Observer
Observer
4,818 Views
Registered: ‎08-29-2017

Here's the env.txt output from the tcl macro above...

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,752 Views
Registered: ‎09-04-2017

Hi,

  I tried running the project that you attached, but i am not able to reproduce the hang that you mentioned.

At all the stages in the flow, vivado goes pretty quick. 

In the project that you have attached i see synthesis and implementation logs, where i see the time taken by each step is pretty small.

 

Thanks,

Nithin

0 Kudos
Highlighted
Participant
Participant
4,742 Views
Registered: ‎09-11-2010

Attached below is the output from the "report environment" command.  What I have found is that if I restart the computer right before running synthesis it will complete successfully, but if I have done anything else prior to running synthesis it will hang.  I noticed that the log indicated that it was using a large amount of memory something around 10GB.  My machine only has 8GB of actual memory, so it may have something to do with memory.  It makes development really slow if you need to restart before every synthesis.  I did not see this problem in 2016.2 with the same project.

 
0 Kudos
Highlighted
Visitor
Visitor
4,721 Views
Registered: ‎03-10-2008

I can solve this issue , but I don't know why. (because I meet the same situation)

 

when the systhesis is frozen, kill one processs (vivado) about 400- 500M  memory process.

 

 

0 Kudos
Highlighted
Participant
Participant
4,710 Views
Registered: ‎03-03-2008

I'm seeing the same thing in 2017.2 ....

For a point of reference where the hang seems to occur ... 

---------------------------------------------------------------------------------
Finished Writing Synthesis Report : Time (s): cpu = 00:10:02 ; elapsed = 00:10:12 . Memory (MB): peak = 2033.074 ; gain = 1696.230
---------------------------------------------------------------------------------
Synthesis finished with 0 errors, 0 critical warnings and 8213 warnings.

The hang occurs here.  If I didn't do what pharaohking suggested (kill the ~500MB vivado task), it would sit at this point forever.  However, when I kill the ~500MB task, the log continues ...

Synthesis Optimization Runtime : Time (s): cpu = 00:06:58 ; elapsed = 00:31:14 . Memory (MB): peak = 2033.074 ; gain = 1081.789
Synthesis Optimization Complete : Time (s): cpu = 00:10:02 ; elapsed = 00:32:26 . Memory (MB): peak = 2033.074 ; gain = 1696.230
INFO: [Project 1-571] Translating synthesized netlist 

and so on ... 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,422 Views
Registered: ‎09-04-2017

Hi,

  Is this still reproducible.

If so, can you try to set this switch in vivado tcl before launching synthesis

 

set_param general.maxThreads 1

 

Thanks,

Nithin

0 Kudos
Highlighted
Newbie
Newbie
3,335 Views
Registered: ‎03-24-2017

I'm seeing the same problem. Was a solution found to fix this behavior?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
3,328 Views
Registered: ‎07-22-2008

When the synthesis process is run, a second Vivado instance is launched through vrs, cmd, and cscript instances.

The original Viviado instance monitors the synth_1 run directory (or whatever the name of the run that is launched) and watches for a file named .vivado.end.rst or .vivado.error.rst.  If it finds the first it indicates that it completed successfully.  If it finds the error.rst file, the main Vivado instance will indicate that the process ended with an error.  If it gets neither, it just continues to indicate that the process is still running.

What should be happening is that the child vivado process completes and closes.  Once it closes, the cscript instance running rundef.js, creates the .vivado.end.rst file and exist, and the shell running runme.bat also exits.

In most  of the cases reported on this thread, it sounds like the child Vivado process is finishing but not exiting.  Thus the parent Vivado process continues to wait for the end.rst file to be created.  Killing the child process (that indicates it has finished) should be safe.

If it is the cmd, or cscript instance that is dying, hanging or otherwise not happily creating the .vivado.end.rst after the child process exits, there is likely a system issue holding or preventing the script from continuing.