cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
457 Views
Registered: ‎12-12-2019

Scope of TCL variables

(I've read this post: https://forums.xilinx.com/t5/Vivado-TCL-Community/TCL-variable-scope-in-Vivado/m-p/752183#M5489 but it doesn't seem to directly answer my issue)

I'm new at tcl here.  I've got a file called cdc_gen_xdc.tcl that I need to source after synthesis, before implementation.  There's not much in it, just calling some other tcls.  Full contents of cdc_gen_xdc.tcl follows:

------------

source $BASE/submodules/kt_cwag_framework/syn/vivado_auto_cdc.tcl
source $BASE/submodules/kt_cwag_framework/syn/vivado_cross_clock_cdc.tcl
# Generate the Auto CDC contraints for the clock crossings
if {[llength $AUTO_CDC_CLOCKS] > 1} {
vivado_auto_cdc $AUTO_CDC_CLOCKS $AUTO_CDC_RELATED $PROJECT\_auto_cdc.xdc
source $PROJECT\_auto_cdc.xdc

vivado_cross_clock_cdc $PROJECT\_cross_clock_cdc.xdc
source $PROJECT\_cross_clock_cdc.xdc
}

-----------

I've set this to run after synth in my main tcl script (ks_launch_runs.tcl) like this:

set_property STEPS.SYNTH_DESIGN.TCL.POST $BASE/../SFM/SFM1/VirtexB/FW_SRC/cdc_gen_xdc.tcl [get_runs synth_1]

And the property is set correctly.  I can see the correct full path to the file under Run Properties.

 

BUT, here's the problem:  After synthesis runs, it says synthesis failed because:

ERROR: [runtcl-1] can't read "BASE": no such variable

So ks_launch_runs can see $BASE (because the full path to cdc_gen_xdc.tcl shows in the Properties), and the vivado tcl console can see $BASE (if I type "puts $BASE", I can see printed), and if I run cdc_gen_xdc.tcl manually from the tcl console, it works.  But when cdc_gen_xdc.tcl is run as a TCL.POST, it suddenly can't see $BASE (or I assume, my other variables).

 

Any ideas what I'm doing wrong?

0 Kudos
7 Replies
Highlighted
Scholar
Scholar
427 Views
Registered: ‎08-01-2012

Re: Scope of TCL variables

because of the way that Vivado works, each compile phase essentially runs inside a sandbox with no visibility of the environment around it. Hence when your script runs its inside a blank TCL namespace, and cannot see your $BASE variable. It is highly annoying.

The only way around it is to output a file from the main environment that is then read inside the cdc_gen_xdc.tcl file. This file can be another temporary tcl file that simply sets the $BASE variable.

The next kicker is that the because synth and implementation actually run in non-project mode, they have no visibililty of any project settings. They also run inside the <projects>.runs/synth_1 folder,  So finding files can be interesting.

Highlighted
409 Views
Registered: ‎12-12-2019

Re: Scope of TCL variables

Thank you! That really helps! I had my main environment add the variable settings to the top of cdc_gen_xdc.tcl and it seems to be working, at least to get cdc_gen_xdc.tcl to run, on a small toy design.

Now, follow-up: Does that mean that when cdc_gen_xdc.tcl sources the xdc files it creates, they won't be sourced into the project? so the impl run won't see them? (If so, is there a way around that?)
0 Kudos
Highlighted
Guide
Guide
386 Views
Registered: ‎01-23-2009

Re: Scope of TCL variables

We would need to know a LOT more about how you are planning to set up your environment to really answer your question.

But, if you are planning to use project mode (and from what I can see, this is what you are trying to do) what you are trying to do is not recommended. Anything sourced in the tcl.pre or tcl.post scripts is done "outside" the project environment - it is really a backdoor for doing things that you can't do the "normal" way.

Anything having to do with constraints really should (I might almost say "must") be done through the normal mechanisms allowed in project mode - adding a constraint file to your project. The script you have now seems like it was built for "something else" - it could be intended for scripted project mode (where this script is part of a larger script that implements the project without the GUI), or maybe even as part of a non-project mode script.

There are lots of ways of dealing with constraints - particularly for clock domain crossings. In most cases it is possible to do all kinds of fancy things using scoped XDC files; it may be complicated but it remains "in the project flow", and hence doesn't create all kinds of problems as you continue through the flow (to implementation, and bitstream generation).

So, rather than trying to source this script as is, tell us what you are trying to accomplish, and maybe we can give you some more supported flows for accomplishing what you want.

Avrum

0 Kudos
Highlighted
224 Views
Registered: ‎12-12-2019

Re: Scope of TCL variables

Sorry for the delay on getting back to this.  We had a "good enough" solution and a high-priority issue to work on, so getting this working cleanly got put on the back burner until now.

Here's the basic situation:  We have a product from one team that we are integrating into a product from another team, so we have to reconcile two different work flows.

What I'll call the "old flow" was using a top level vivado_flow.tcl script, which frist did a "synthesis" proc that calls "eval synth_design -part $DEVICE $SYNTH_ARGS -top $PROJECT".  Then would run these two scripts: vivado_auto_cdc and vivado_auto_cdc to generate two xdc files that get sourced into the project.  (this is the part that I've pulled out into a separate file I called cdc_gen_xdc.tcl, above) Then it would write a checkpoint file.  Then it runs a "build_par" proc that opens the checkpoint and ultimately runs "eval opt_design $opt_options".

The "new flow" uses a top level script called ks_launch_runs.tcl, which does things a bit differently.  Rather than eval synth_design and eval opt_design, it uses create_run and launch_runs.

So from what I gather, the "eval synth_design"/"eval opt_design" commands are blocking, in such a way that you can run the xdc-generating tcl scripts and source the resulting xdc files in between then.   but the "launch_runs" method kicks off a run in the background and returns immediately.  So there's no opportunity to run this stuff in between.  Is that correct?

I don't know if it's crucial to run these tcl files every time, or if it would suffice to grab the xdc output and just include it statically in the project, once the code for the clocking mechanisms and clock names are stable.  But is there any way to do so in the "launch_runs" method?

 

Right now, the "good enough" procedure I've been doing has been very manual.  I run ks_launch_runs.tcl, and wait until the synth run is complete.  Then I reset the impl runs, open the synth run, source cdc_gen_xdc.tcl manually from the tcl console, and then restart the impl runs.  This works, but isn't very clean.  I'd like to just kick things off and let them run to completion without manual intervention.

0 Kudos
Highlighted
Guide
Guide
210 Views
Registered: ‎01-23-2009

Re: Scope of TCL variables

The synth_design, opt_design, place_design, route_design, phys_opt_design command are all non-project mode commands.

The launch_runs command is a project mode commands.

These two flows (project mode vs. non-project mode) are fundamentally different. It is going to be difficult to use any script written for one mode in the other mode. You are either going to have to get one of the two teams to change their fundamental approach to interacting with the tool (i.e. you both either use project mode or you both use non-project mode), or you are going to have to figure out a way to do what they are doing "differently" - and there is no formulaic way of doing this migration...

Avrum

Highlighted
197 Views
Registered: ‎12-12-2019

Re: Scope of TCL variables

Thank you for the confirmation.  That's kind of what I'd feared.     I think the solution is to stick with Project mode for now, since that's the flow that we're ultimately delivering into.  I will try to statically generate the xdc manually when anything changes in the clocks and just include the static xdc in the project.

Thanks again.

0 Kudos
Highlighted
Scholar
Scholar
187 Views
Registered: ‎08-01-2012

Re: Scope of TCL variables

You can use most non-project mode commands in project mode. I have a script that uses synth_design to do a quick and dirty elaboration to check for syntax errors or any MARK_DEBUGs left in a release build. This is because synth_design loads the results direct to ram and you can then instantly interrogate it. But I use "launch_runs" in the main build, the reason being is that it pipelines all the OOC builds nicely, as it will build any run required by synth_1 automatically and then do them one by one.

You simply use wait_on_run to block like synth_design does.

launch_runs synth_1 -jobs $max_jobs
wait_on_run synth_1
puts_datetime "Finished Synthesis"

 

0 Kudos