Initializing Design step never completing.

[tonythomas]

Hello all,

  Requesting some help with an Implementation stage issue:

   I created small Zynq system design including an AXI-GPIO IP and and ILA in the PL and am able to generate a working bitstream for the design.   However, when I tried to re-run the implementation after addition of ports and mapping them to the LED pins, the Implementation stage gets stuck at "Initializing Design" step.

  Here is what I did to add the ports and rerun implementation:

   - Updated block diagram to add external ports.

   - Reset/Regenerated synthesis outputs and re-ran the synthesis.

   - Loaded synthesised design and opened Layout -> IO Planner

   - Mapped the newly added design ports to the LED specific pins (T22 etc.)

   - Saved the port constraint file and did a "Force Update" from the "Design Run" tab.

   - Kicked off implementation.

After that, the "Initializing Design" step runs for ever.   Any inputs towards resolving this is greatly appreciated!

After this happens once, the issue reccurs even after removing the ports/constraints

Thank you,

Tony Thomas.

[balkris]

Share some related information. It may help you. Often it is desirable to use instrumentation (e.g., oscilloscope, logic analyzer, Vivado Logic Analyzer) to measure the amount of time required for a piece of software to execute.   A common technique is to use a general purpose output to generate a pulse which can be measured by the instrumentation.  A typical example of this in the Zynq context is shown in figure 1.

Figure 1: Solution using AXI GPIO

Unfortunately there are situations where the magnitude or variability of the latency introduced by the AXI interconnect, both within the PS as well as in the PL, renders the measurement unusable.   For those cases it is possible to repurpose the ARM event mechanism to create a low latency output. 

At the heart of this technique is ARMs send event (SEV) instruction.  Typically SEV is used to create an event that signals all other CPUs within a multi-processor system.  For example, when Zynq boots CPU0 participates in the boot process while CPU0 is sleeping.  It is not unusual typical to use SEV to wake CPU1 once the boot process is complete.

Fortunately the Zynq designers saw fit to expose the event signals to the PL, i.e., EVENTEVENTO and EVENTEVENTI.  The other part of this solution is to utilize EVENTEVENTO as an output to create a pulse for the instrumentation.

Figure 2: Solution using EVENTEVENTO

Hardware

Constructing a system that utilizes this technique is quite simple.  The first step is to expose the event signals to the PL.  This is accomplished by configuring the Zynq device as shown below.

Figure 3: ZYNQ7 Processing System > Re-customize IP > PS-PL Configuration Dialog (in Vivado 2013.4)

All that remains is to make the PS7 signal EVENTEVENTO available to the instrumentation, as depicted in figure 2.

Software

Software is straightforward as well.  Each time the SEV instruction is executed the EVENTEVENTO signal will toggle.  It is left to the user to insure that EVENTEVENTO is parked in the correct state, e.g., for every SEV that causes a rising edge on EVENTEVENTO insure that there is a second SEV that causes a falling edge.

At the time of this writing the Xilinx standalone BSP does not have a C callable version of the SEV instruction.  The following macro makes invoking the SEV assembly language trivial.

#define sev() __asm__ __volatile__ ("sev" : : : "memory")

Example

Using a hardware design similar to that shown above, the following code produces the waveform shown in figure 4.

while (1) {

      sev(); //high

      for (i = 10; i; i--) ;

      sev(); //low

      for (i = 100; i; i--) ;

}

Figure 4: Vivado Logic Analyzer Waveform

(note: trigger is @ clock #256, ILA clock = 150 MHz)

It should be noted that EVENTEVENTO is not specified to be synchronous with any clock available on the PS/PL boundary.  The user should be careful how EVENTEVENTO is captured by the instrumentation.  The for loop between the SEV instructions was inserted in the above code to insure that the pulse emitted on EVENTEVENTO was sufficiently wide to be captured by an ILA clocked @ 150MHz.  Empirical data shows that in some cases the delay introduced by the for loop is not necessary  (e.g., 667MHz CPU, 150MHz ILA clock).

[siktap]

Which version of tools are you using? This could be a bug.

 To confirm this, can you try this in commandline? You can use the same tcl command to run this.

Basically write a checkpoint after synthesis, open that checkpoint, run opt_Design,place_Design and route_Design.

Hope this helps.

Regards

Sikta

[c_oflynn]

I know this is an old post, but I came across this and didn't see a solution posted. I ended up noticing that even after closing Vivado, there was still a "vivado.exe" process running. I killed that and it seemed to work again.... I had also deleted items in the "impl_1" folder before re-running, but I'm not sure if that step is neccesary (you can't delete them without killing the zombie vivado.exe).

[cyviz]

Hm, there is still some nastyness left of this issue in 2016.2. I'm sharing my experience here as a warning of what to look out for. My project never stopped synthesizing, but the symptoms are the same. (I'm using Win10)

The Vivado GUI was apparently synthesizing, and the green "progress" bar was moving. When I looked at process manager, the [single] Vivado process was using approximate 3% CPU resources (8 core system), and I was expecting full load on one core (10-13%). Leaving it to run overnight confirmed that it was locked up. I believe the GUI and the TCL  processes has lost sync and there was no clear message about this in the log.

I quit the GUI and tried to delete all under .runs folder and noticed something couldn't be deleted. Looking in process

manager again, I saw the zombie process still running. I stopped it, then I was allowed to delete all the .runs files.

Looking again at a normal run, it seems like the Vivado should have at least two processes on a normal synth. I guess this is one for the GUI, and one or more for the actual synth. They are both named vivado.exe.

Finally, yes, deleting the .runs folder seems to get it going again. It will resynth all the IP too.

PS:I have seen this "GUI vs TCL process out of sync" symptom on another occasion. My PC got hard reset during a run. When I got my pc back up, the progress bar kept running just after opening the project. I got a bit suspicious, having doubts that the GUI really would "auto resume" on project load, and got it confirmed. I had to stop and restart to make it run for real.

OOC comment:Xilinx should really add the word Vivado to the accepted words for their forum spellchecker ;)

[andy.cruey]

I just wanted to post for others that may run into this. It's still present in 2017.2 on Win10. After being frustrated for a couple of hours I ran across this post and, sure enough, I closed Vivado and there was a zombie instance of it still running in task manager. I killed that, cleaned up all the stuff I had tried to fix it in my design and settings and my design didn't get stuck in initializing design anymore. 

[navaneetha.cm]

Ending "vivado.exe" process worked in my case. Thank you.