cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
anm
Adventurer
Adventurer
727 Views
Registered: ‎02-18-2015

Reload Synthesis and Implementation stages in Vivado

Jump to solution

Hi,

I have been searching around on a way to reload the synthesis and implementation stage after opening a project in Vivado. From what I have found so far the 'write_project_tcl' is a way to recreate (or should I better say reload) the whole design.
The 'write_project_tcl' script is also used as a means to have versioning control, which is something I would like to add to my project.

At the moment, this is the run.tcl script I am using for synthesis and implementation (it follows the Project mode approach):

set project koko

create_project $project . -force -part $::env(XILINX_PART)
set_property board_part $::env(XILINX_BOARD) [current_project]

# set number of threads to 8 (maximum, unfortunately)
set_param general.maxThreads 8

set_msg_config -id {[Synth 8-5858]} -new_severity "info"

set_msg_config -id {[Synth 8-4480]} -limit 1000

if {$::env(BOARD) eq "genesys2"} {
    add_files -fileset constrs_1 -norecurse constraints/genesys-2.xdc
} else {
      exit 1
}

read_ip { \
      "xilinx/xlnx_mig_7_ddr3/xlnx_mig_7_ddr3.srcs/sources_1/ip/xlnx_mig_7_ddr3/xlnx_mig_7_ddr3.xci" \
      "xilinx/xlnx_axi_clock_converter/xlnx_axi_clock_converter.srcs/sources_1/ip/xlnx_axi_clock_converter/xlnx_axi_clock_converter.xci" \
      "xilinx/xlnx_axi_dwidth_converter/xlnx_axi_dwidth_converter.srcs/sources_1/ip/xlnx_axi_dwidth_converter/xlnx_axi_dwidth_converter.xci" \
      "xilinx/xlnx_axi_gpio/xlnx_axi_gpio.srcs/sources_1/ip/xlnx_axi_gpio/xlnx_axi_gpio.xci" \
      "xilinx/xlnx_axi_quad_spi/xlnx_axi_quad_spi.srcs/sources_1/ip/xlnx_axi_quad_spi/xlnx_axi_quad_spi.xci" \
      "xilinx/xlnx_clk_gen/xlnx_clk_gen.srcs/sources_1/ip/xlnx_clk_gen/xlnx_clk_gen.xci" \
}
# read_ip xilinx/xlnx_protocol_checker/ip/xlnx_protocol_checker.xci

set_property include_dirs { "src/axi_sd_bridge/include" "../src/common_cells/include" } [current_fileset]

source scripts/add_sources.tcl

set_property top ${project}_xilinx [current_fileset]

if {$::env(BOARD) eq "genesys2"} {
    read_verilog -sv {src/genesysii.svh ../src/common_cells/include/common_cells/registers.svh}
    set file "src/genesysii.svh"
    set registers "../src/common_cells/include/common_cells/registers.svh"
} else {
    exit 1
}

# Synthesis Stage
set design_stage synth

set file_obj [get_files -of_objects [get_filesets sources_1] [list "*$file" "$registers"]]
set_property -dict { file_type {Verilog Header} is_global_include 1} -objects $file_obj

update_compile_order -fileset sources_1

add_files -fileset constrs_1 -norecurse constraints/$project.xdc

synth_design -rtl -name rtl_1

set_property STEPS.SYNTH_DESIGN.ARGS.RETIMING true [get_runs synth_1]

launch_runs synth_1
wait_on_run synth_1
if {[get_property PROGRESS [get_runs synth_1]] != "100%"} {
  error "ERROR: synth_1 failed"
} else {
  open_run synth_1

  exec mkdir -p reports/$design_stage
  exec rm -rf reports/${design_stage}/*

  check_timing -verbose                                                   -file reports/${design_stage}/$project.check_timing.rpt
  report_timing -max_paths 100 -nworst 100 -delay_type max -sort_by slack -file reports/${design_stage}/$project.timing_WORST_100.rpt
  report_timing -nworst 1 -delay_type max -sort_by group                  -file reports/${design_stage}/$project.timing.rpt
  report_utilization -hierarchical                                        -file reports/${design_stage}/$project.utilization.rpt
  report_cdc                                                              -file reports/${design_stage}/$project.cdc.rpt
  report_clock_interaction                                                -file reports/${design_stage}/$project.clock_interaction.rpt
}

# Implementation Stage
set design_stage impl

# set for RuntimeOptimized implementation
set_property "steps.route_design.args.directive" "RuntimeOptimized" [get_runs impl_1]

#launch_runs impl_1
#wait_on_run impl_1
launch_runs impl_1 -to_step write_bitstream
wait_on_run impl_1
if {[get_property PROGRESS [get_runs impl_1]] != "100%"} {
  error "ERROR: impl_1 failed"
} else {
  open_run impl_1

  exec mkdir -p netlists/
  exec rm -rf netlists/*

  ## Output Verilog netlist + SDC for timing simulation
  write_verilog -force -mode funcsim netlists/${project}_funcsim.v
  write_verilog -force -mode timesim netlists/${project}_timesim.v
  write_verilog -force -mode design  netlists/${project}_final.v
  write_sdf     -force netlists/${project}_timesim.sdf

  ## Reports
  exec mkdir -p reports/$design_stage
  exec rm -rf reports/${design_stage}/*
  check_timing                                                              -file reports/${design_stage}/${project}.check_timing.rpt
  report_timing -max_paths 100 -nworst 100 -delay_type max -sort_by slack   -file reports/${design_stage}/${project}.timing_WORST_100.rpt
  report_timing -nworst 1 -delay_type max -sort_by group                    -file reports/${design_stage}/${project}.timing.rpt
  report_utilization -hierarchical                                          -file reports/${design_stage}/${project}.utilization.rpt
}

## Create TCL file to recreate the Project when opening it.
write_project_tcl -all_properties -force recreate.tcl

 

As you can see, at the end I am using the 'write_project_tcl' command to produce a recreate.tcl script.

However, when I am trying to reload the Synthesis and Implementation stages at a later time (while being inside the project folder), using the following command:

vivado -mode tcl -source ./recreate.tcl

 

I get the following errors and the recreation (or reloading) of the project, never happens:

****** Vivado v2019.2 (64-bit)
  **** SW Build 2708876 on Wed Nov  6 21:39:14 MST 2019
  **** IP Build 2700528 on Thu Nov  7 00:09:20 MST 2019
    ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.

source ./recreate.tcl
# set origin_dir "."
# if { [info exists ::origin_dir_loc] } {
#   set origin_dir $::origin_dir_loc
# }
# set _xil_proj_name_ "koko"
# if { [info exists ::user_project_name] } {
#   set _xil_proj_name_ $::user_project_name
# }
# variable script_file
# set script_file "recreate.tcl"
# proc print_help {} {
#   variable script_file
#   puts "\nDescription:"
#   puts "Recreate a Vivado project from this script. The created project will be"
#   puts "functionally equivalent to the original project for which this script was"
#   puts "generated. The script contains commands for creating a project, filesets,"
#   puts "runs, adding/importing sources and setting properties on various objects.\n"
#   puts "Syntax:"
#   puts "$script_file"
#   puts "$script_file -tclargs \[--origin_dir <path>\]"
#   puts "$script_file -tclargs \[--project_name <name>\]"
#   puts "$script_file -tclargs \[--help\]\n"
#   puts "Usage:"
#   puts "Name                   Description"
#   puts "-------------------------------------------------------------------------"
#   puts "\[--origin_dir <path>\]  Determine source file paths wrt this path. Default"
#   puts "                       origin_dir path value is \".\", otherwise, the value"
#   puts "                       that was set with the \"-paths_relative_to\" switch"
#   puts "                       when this script was generated.\n"
#   puts "\[--project_name <name>\] Create project with the specified name. Default"
#   puts "                       name is the name of the project from where this"
#   puts "                       script was generated.\n"
#   puts "\[--help\]               Print help information for this script"
#   puts "-------------------------------------------------------------------------\n"
#   exit 0
# }
# if { $::argc > 0 } {
#   for {set i 0} {$i < $::argc} {incr i} {
#     set option [string trim [lindex $::argv $i]]
#     switch -regexp -- $option {
#       "--origin_dir"   { incr i; set origin_dir [lindex $::argv $i] }
#       "--project_name" { incr i; set _xil_proj_name_ [lindex $::argv $i] }
#       "--help"         { print_help }
#       default {
#         if { [regexp {^-} $option] } {
#           puts "ERROR: Unknown option '$option' specified, please type '$script_file -tclargs --help' for usage info.\n"
#           return 1
#         }
#       }
#     }
#   }
# }
# set orig_proj_dir "[file normalize "$origin_dir/"]"
# create_project ${_xil_proj_name_} ./${_xil_proj_name_} -part xc7k325tffg900-2
ERROR: [Common 17-53] User Exception: Project already exists on disk, please use '-force' option to overwrite: 
     /Projects/Proj/fpga/koko/koko.xpr
     /Projects/Proj/fpga/koko/koko.srcs
     /Projects/Proj/fpga/koko/koko.sim
     /Projects/Proj/fpga/koko/koko.cache
     /Projects/Proj/fpga/koko/koko.hw
     /Projects/Proj/fpga/koko/koko.ip_user_files

 

I am using Vivado 2019.2 on Centos 7.
 
Can someone point me to what I am missing here and I am not able to recreate/reload my design?

Thank you in advance for your responses and time!

Kind regards,
anm


0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
554 Views
Registered: ‎01-23-2009

At quick glance, it appears you are mixing Non-Project Mode commands (read_verilog, read_vhdl, read_ip) with Project Mode commands (launch_runs, etc.).  You don't want to mix Non-Project and Project commands.  You can use add_files instead of individually calling out read_verilog, read_vhdl, read_ip, etc.

I agree with this - you shouldn't mix project and non-project commands, and you should switch to add_files for all of these things. But (and I don't recommend that you keep it this way), this should be harmless; before synthesis these commands (read_verilog, etc...) have the same net effect as the add_files commands.

Another non-project mode command that you have in your script is the "synth_design -rtl". This should not be run in project mode. It is also useless; the results of the elaboration (synth_design -rtl) sort of remain as the in-memory design for parts of the rest of your flow, but it does nothing to the end result - the "launch_runs synth_1" re-runs synthesis from scratch in a separate context - the results of the synth_design -rtl are ignored.

This is weird, but I don't think it is the problem either.

From the log file, I don't see anything else obviously wrong. 

Since you say you can see the design properly when you are in the "start_gui" (the GUI that is started automatically at the end of the script) I would check to make sure you know exactly where you are - you can do 

report_property [current_project]

and look at the results - particularly the "NAME" and "DIRECTORY" properties - this is where your project really is. I would also do 

report_property [get_runs synth_1]
report_property [get_runs impl_1]

And particularly note the DIRECTORY properties of these objects (see below)

I am also confused by your directories. In the same directory as the "ariane.xpr" there should be an "ariane.runs" directory, and under that a synth_1 and and an impl_1. This is where the results of the runs are kept. That whole directory appears to be missing. These should be the directories reported by the "report_property [get_runs synth_1]" (and impl_1). If they are not (i.e the directories are "elsewhere") we need to understand why.

What you should do is, while you are in the "start_gui" (before you exit Vivado) go look at the directory structure and see if this directory is there. If so, then something after the termination of Vivado is deleting or moving this directory - that will definitely account for what you are seeing. All the directories with <project_name>.* are essential to be left completely alone - only then does the project remain intact.

And by the way - once you are in the "start_gui", how do you leave? The correct way would be "stop_gui" - that will return control back to your script.

Avrum

View solution in original post

10 Replies
avrumw
Guide
Guide
715 Views
Registered: ‎01-23-2009

So I'm a bit confused as to what you want to do...

If you want to recreate your project from scratch, then just rerun your original script (in a different directory) - the script looks like it uses scripted project mode correctly

  • create a new project
  • add all sources to it
  • set all synthesis and implementation options on it
  • launch_runs 
    • You can do the synthesis first, or just, as is the case here, launch the implementation run - the tool will automatically run synthesis

So you don't need the write_project_tcl.

If you just want to open the runs that were created by this script then just do that! The easiest way is just to start the GUI, open the project and then open the synthesized or implemented design - they will both be there and "up to date".

If you want to do this in a script then it is pretty simple - the script should

open_project koko.xpr; # not create_project
open_run synth_1; # or open impl_1 if you want the implemented run
... do whatever you want to do here ...
close_project

Nothing more is necessary. That's the good thing about project mode - everything is stored with the project and you can easily re-open it at any time.

Avrum

0 Kudos
anm
Adventurer
Adventurer
701 Views
Registered: ‎02-18-2015

Dear @avrumw ,

thank you very much for your quick response.
I have tried the easy way, meaning starting the GUI and opening the project, but the problem is I cannot open the synthesized and implemented design, as the option is not highlighted. Please see attached image:

Screen Shot 2021-03-17 at 3.12.43 PM.png

I even tried in the Tcl console the command: open_run synth_1

But it gives me an error about synth_1 not have been run before.
So it basically prompts me to re-run both Synthesis and Implementation stages again.

Am I missing something here?

Kind regards,
anm

0 Kudos
avrumw
Guide
Guide
688 Views
Registered: ‎01-23-2009

Something must not be going right during the execution of the original script - are you sure it completes without errors?

If the script completes the launch_runs impl_1 and wait_on_run impl_1, then both the synthesis (synth_1) and implementation (impl_1) runs should be there, up-to-date and ready to be opened.

From what little I can see, I wonder if this is the "right" project that you have opened. First, the project is not named "koko", which would be the name of the project created by the script. Second, I don't see any design sources - I assume your add_sources.tcl adds sources to the project (with add_source commands) - they should show up here.

So something is wrong - this project looks like an "empty" project. Either the original script is not running correctly - maybe it took the else branch of

if {$::env(BOARD) eq "genesys2"} {
    add_files -fileset constrs_1 -norecurse constraints/genesys-2.xdc
} else {
      exit 1
}

Or the project you opened does not correspond to the one created by the script. This project looks like a more or less empty project. 

Avrum

0 Kudos
anm
Adventurer
Adventurer
676 Views
Registered: ‎02-18-2015

My apologies, I tried to cut down on some "unnecessary" information on the scripts posted to make it more simple, cause the hierarchy of the folders/scripts is not what I would call simple (I am in the process of simplifying it though).
I am attaching here 2 Makefiles and the tcl scripts I am using for the generation of the bitstream:

Makefile1 is the master one that creates the 'add_sources.tcl' as you correctly said above. I use from here the "make fpga" option. As you can see, this option enters/cds a folder called 'fpga' where the second Makefile2 and the scripts reside and starts Synthesis/Implementation.
Makefile2 is the one calling the scripts 'prologue.tcl' and 'run.tcl' (I concatenated those 2 in my original post in an attempt to simplify things).
I have added also the generated log from Vivado. As you can see in it, beside the successful generation of the bitstream, I am starting the GUI (last command in my run.tcl script). When the GUI starts I am able to see the P&Red design without a problem.
The problem is that if I close the project and try to re-open it, both Synthesis and Implementation stage are not there to open, which is really strange.

I hope that I have given you sufficient information. Please feel to ask if anything else is needed.
Thank you again for your help @avrumw !

Kind regards,
anm


0 Kudos
miker
Xilinx Employee
Xilinx Employee
658 Views
Registered: ‎11-30-2007

@anm 

At quick glance, it appears you are mixing Non-Project Mode commands (read_verilog, read_vhdl, read_ip) with Project Mode commands (launch_runs, etc.).  You don't want to mix Non-Project and Project commands.  You can use add_files instead of individually calling out read_verilog, read_vhdl, read_ip, etc.

Project Mode manages the generation of the synthesized design checkpoint (<design_name>.dcp) and implemented design checkpoints (<design_name>_opt.dcp, <design_name>_physopt.dcp, <design_name>_placed.dcp, <design_name>_routed.dcp).  However, these design checkpoints are written after running the respective synthesis and implementation processes and they have completed successfully.  If you "re-create" your design, the design checkpoints cannot be "re-loaded" because they have not yet been created.  The design checkpoints are outputs of the synthesis and implementation processes.

Please Reply, Kudos, and Accept as Solution.
anm
Adventurer
Adventurer
639 Views
Registered: ‎02-18-2015

Hi @miker 

thank you very much for your reply. I will update the scripts to use the 'add_files' command instead to not have this mixture of Project/Non-Project commands.

I am attaching you a screenshot of the folder hierarchy. I am inside the ./fpga folder where the .xpr file resides. Inside this folder, there is also a ./fpga/work-fpga folder created by the Makefile2 (as you can see in Makefile2, all the files generated in impl_1 by Vivado are copied there) .
From a quick 'find' I did, I can see that the checkpoints you are mentioning are inside the ./fpga/work-fpga.
So:

./fpga ---> .xpr file

./fpga/work-fpga ---> .dcp file

I think that creates the problem, that when I run Vivado and open the .xpr file inside the ./fpga folder, I cannot find the checkpoints to reload them.

Is it possible after opening the .xpr, to point to a different folder for the .dcp files? What would be the best strategy?

Thank you very much for your advice.

Kind regards,
anm

0 Kudos
miker
Xilinx Employee
Xilinx Employee
626 Views
Registered: ‎11-30-2007


@anm 

If you are moving generated files, this is definitely the source of your problem.  If you want Vivado to "manage" your project, you use Project Mode.  When using Project Mode, you are allowing Vivado to handle all file movement.

I would suggest leaving the design files (including the design checkpoints) exactly where they are created.  You are free to copy files... just don't move/delete the ones Vivado generated.  If you want full control over each source file and each generated file, Non-Project Mode would be better for you.

Please Reply, Kudos, and Accept as Solution.
0 Kudos
avrumw
Guide
Guide
555 Views
Registered: ‎01-23-2009

At quick glance, it appears you are mixing Non-Project Mode commands (read_verilog, read_vhdl, read_ip) with Project Mode commands (launch_runs, etc.).  You don't want to mix Non-Project and Project commands.  You can use add_files instead of individually calling out read_verilog, read_vhdl, read_ip, etc.

I agree with this - you shouldn't mix project and non-project commands, and you should switch to add_files for all of these things. But (and I don't recommend that you keep it this way), this should be harmless; before synthesis these commands (read_verilog, etc...) have the same net effect as the add_files commands.

Another non-project mode command that you have in your script is the "synth_design -rtl". This should not be run in project mode. It is also useless; the results of the elaboration (synth_design -rtl) sort of remain as the in-memory design for parts of the rest of your flow, but it does nothing to the end result - the "launch_runs synth_1" re-runs synthesis from scratch in a separate context - the results of the synth_design -rtl are ignored.

This is weird, but I don't think it is the problem either.

From the log file, I don't see anything else obviously wrong. 

Since you say you can see the design properly when you are in the "start_gui" (the GUI that is started automatically at the end of the script) I would check to make sure you know exactly where you are - you can do 

report_property [current_project]

and look at the results - particularly the "NAME" and "DIRECTORY" properties - this is where your project really is. I would also do 

report_property [get_runs synth_1]
report_property [get_runs impl_1]

And particularly note the DIRECTORY properties of these objects (see below)

I am also confused by your directories. In the same directory as the "ariane.xpr" there should be an "ariane.runs" directory, and under that a synth_1 and and an impl_1. This is where the results of the runs are kept. That whole directory appears to be missing. These should be the directories reported by the "report_property [get_runs synth_1]" (and impl_1). If they are not (i.e the directories are "elsewhere") we need to understand why.

What you should do is, while you are in the "start_gui" (before you exit Vivado) go look at the directory structure and see if this directory is there. If so, then something after the termination of Vivado is deleting or moving this directory - that will definitely account for what you are seeing. All the directories with <project_name>.* are essential to be left completely alone - only then does the project remain intact.

And by the way - once you are in the "start_gui", how do you leave? The correct way would be "stop_gui" - that will return control back to your script.

Avrum

View solution in original post

anm
Adventurer
Adventurer
430 Views
Registered: ‎02-18-2015

@avrumw 

As per you instructions I checked the NAME and the DIRECTORY which are 'ariane' and 'Ariane/fpga/' as expected (screenshot 1 attached).
You are absolutely right about the ariane.runs folder. It should have been there and it is (screenshot 2, 3, 4 attached) while I keep the GUI open. When I close it with the 'stop_gui' command, it disappears (screenshot 5 attached).
I see in the printout (screenshot 6) that after finishing with the 'run.tcl' script, the Makefile2 executes a command that copies all the files generated during implementation inside the 'Ariane/fpga/ariane.runs/impl_1/' folder to a new folder called 'Ariane/fpga/work-fpga/':

 

 

cp ariane.runs/impl_1/ariane_xilinx* ./work-fpga

 

 


Then the Makefile2 runs the following command to create the configuration file .mcs from the generated bitstream:

 

 

vivado -nojournal -mode batch -source scripts/prologue.tcl -source scripts/write_cfgmem.tcl -tclargs work-fpga/ariane_xilinx.mcs work-fpga/ariane_xilinx.bit

 

 

 Based on what you have said, this might be the problem, as the prologue script (shown bellow but also attached in previous post) probably creates a new project called ariane, which automatically overwrites folders associated with the previous run:

 

 

set project ariane

create_project $project . -force -part $::env(XILINX_PART)
set_property board_part $::env(XILINX_BOARD) [current_project]

# set number of threads to 8 (maximum, unfortunately)
set_param general.maxThreads 8

set_msg_config -id {[Synth 8-5858]} -new_severity "info"

set_msg_config -id {[Synth 8-4480]} -limit 1000

 

 

I think we found the source of the problem.
As you can understand those scripts are not mine and I am trying to streamline them. I really appreciate your help.

1.png
6.png
0 Kudos
anm
Adventurer
Adventurer
410 Views
Registered: ‎02-18-2015

@miker @avrumw 

I removed from the Makefile2, the command to create the .mcs configuration file, re-run the whole process and voila!
All the project files remain there and I am able to re-open and load the Synthesis and Implementation stages.
All I need to do now is to change the way the creation of the configuration file is invoked inside the Makefile, in order to not destroy the generated project folders.

Thank you both for your help, I will close this thread now.

Kind regards,
anm

0 Kudos