It would be nice to define a sort type for each sort column separately.
Actually, it's only possible to define one sort type for all columns to be sorted. But what if one column contains floating point number and another one contains text?

I think the necessary changes should be small.

David,

can you add a wiki item to describe the licensing model?

a test issue. please close

when I try to run the example junit i get the following error

version conflict for package "TclOO": have 1.0.4, need 0.6.1 while executing "package require struct" (file "/home/abunimeh/.Xilinx/Vivado/2018.3/XilinxTclStore/tclapp/xilinx/junit/JUnitAssertionMgr.tcl" line 45)

If our local repo (set through XILINX_TCLAPP_REPO env) is not available (f.e. server offline), our tcl apps (which have already been installed from the local repo) are not loaded.

I would expect all installed apps to be always loaded (they are copied in ~/.Xilinx/Vivado/2014.3/XilinxTclStore) even when our local repo (from where they were installed) is not available.
A critical warning could indicate that the installed app is out of date or doesn't exist in the Vivado installation catalog but if it is already installed, it should be loaded.

Customer reported that the command write_project_tcl does not save the constraint files locations as it does with the other source files

write_project_tcl -no_copy_sources recreate.tcl -force -paths_relative_to "./"

Get following error when installing my own app in Vivado 2014.3:

tclapp::install utils
INFO: [Common 17-660] Loading Tcl app 'utils' into namespace {mycompany::utils}
ERROR: [Common 17-359] Failed to load argument parser (attempt to provide package ::tclapp::support::args 1.0 failed: no version of package ::tclapp::support::args provided).

Same app is working fine in previous versions of Vivado.

modelsim/questa Tcl Store implementation looks for vsim executable through PATH entries. Problem is that executable with such name exists not only in modelsim/questa installations, which causes errors during simulation and forces customers to order PATH elements in specific way. It would be good to add additional condition to make sure that particular vsim is from modelsim/questa, for example if ( vsim.exe && modelsim.exe ) { this is good vsim }.

I added a label.

In the Xilinx TclStore designutils rev. 1.8 , the write_template doesn't seem to implement the -testbench for VHDL feature.
For ex. the following command in Vivado 2014.4 for an opened implemented design returns a message reading "not yet implemented" and an empty file:

TCL Console> ::tclapp::xilinx::designutils::write_template -testbench -vhdl -file C:/M/Temp/footb.vhd

Any chance this will be implemented in the near future?

validate_timing only checks for negative setup slack but will not report a failure for negative hold slack.

ex: The following timing summary does not fail.

`

WNS(ns)      TNS(ns)  TNS Failing Endpoints  TNS Total Endpoints      WHS(ns)      THS(ns)  THS Failing Endpoints  THS Total Endpoints     WPWS(ns)     TPWS(ns)  TPWS Failing Endpoints  TPWS Total Endpoints  
-------      -------  ---------------------  -------------------      -------      -------  ---------------------  -------------------     --------     --------  ----------------------  --------------------  
  0.027        0.000                      0               310450       -0.204       -2.586                     14               309987        0.000        0.000                       0                133736  `

I believe this can be fixed by adding "-setup -hold" switches to the get_timing_paths command.

following command can't work:
set_property ip_repo_paths { $my_ip_dir/a $my_ip_dir/b } [current_project]

the workaround is:
set_property ip_repo_paths [list $my_ip_dir/a $my_ip_dir/b] [current_project]

in 2013.4, insert_buffer.tcl fails lint_files - but does not give much of a message:

Vivado% lint_files -verbose insert_buffer.tcl

while executing

"lint_files insert_buffer.tcl"
Vivado%

Primitives like the MMCM generate signals where the clock is not modeled by Vivado. E.g., Locked. This should be covered by a CDC when it is used.

Thanks.
John

It is inefficient to use a -filter [NAME=xxx] for the tcl commands.
Since the object name is part of the get_xxx command line, it is much more efficient to use:
get_cells xxx
This allows Vivado to get only the objects that match, not all objects in the device.

An example of poor coding is in XilinxTclStore / tclapp / xilinx / designutils / report_hier_util.tcl on line 41:
Rather than:
set childList [get_cells -quiet -hierarchical -filter "NAME =~ $hierCell/* && IS_PRIMITIVE"]
use:
set childList [get_cells -quiet -hierarchical $hierCell/* -filter "IS_PRIMITIVE"]

This is especially obvious in things like get_sites, get_bels, etc. For example:

get_bels -filter [NAME = Tilename/Site_]
will get ALL bels in the device, then filter based on the request.
but
get_bels Tilename/Site_
will ONLY look at the bels in the specified Tilename. This is much faster.

Sterling Babcock

report_failfast fails if running a patched Vivado version.

I am runnning the ::tclapp::xilinx::designutils::report_failfast in Vivado 2018.2_AR72992.

The script exits with error:
-E- expected version number but got "2018.2_0072992"

Luca

This is a question about Tcl scope using Tk commands over tk_tunnel.

I want to have a push running a proc.

rexec {
  proc onClick {} {
    global selected
    if {$selected==true} {
      wm title . checkbutton
    } else {
      wm title . ""
    }
  }
  puts "Starting GUI..."
  tk::toplevel .window
  tk::frame .window.fr
  pack .window.fr -fill both -expand 1
  tk::text .window.fr.tx -width 20 -height 1
  tk::button .window.fr.pb -text "Hi" -width 10 -height 1 -command onClick
  tk::checkbutton .window.fr.cb -text "Show title" -command onClick \
    -onvalue true -offvalue false -variable selected
  .window.fr.cb select
  place .window.fr.cb -x 50 -y 50
  place .window.fr.tx -x 50 -y 80
  place .window.fr.pb -x 50 -y 10
  wm title .window "My Tool"
  wm geometry .window 350x250+300+300
}

I want to run the callback procedure when some widget is clicked.

Please help me with managing the scope. Thanks.

Hello. I ran report_reset_signals on Vivado2019.1. The target device is xazu2eg-sfvc784-1Q-q.
When executed without any options, the execution was completed in one day.
Vivado terminated abnormally when executed with the -verbose option.
Vivado dropped suddenly, there is no log files.

It was confirmed that it ended normally in the example design.
I want a result for my design with verbose option.
It may depend on the design. I can't find the solutions. I want advice.

The PC environment is Windows10 64bit, Memory = 32GB.

I am not getting any apps on xilinx tcl store in vivado while I am refereshing it.

We need to remove these headers - this code is released under BSD 2-clause license - it is not copyright.

Testing issues page for email confirmation

In your README.md file says;

The Tcl Store is an open source repository of Tcl code designed primarily for use with the Xilinx Vivado Design Suite.

However, I can't seem to find any information about what license this repo is under?

You can find info about adding a license file at https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/adding-a-license-to-a-repository

See https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/licensing-a-repository , https://github.blog/2016-09-21-license-now-displayed-on-repository-overview/ and https://opensource.guide/legal/

I would recommend talking to @clavin-xlnx if you need advice.

Following the instructions from https://github.com/Xilinx/XilinxTclStore/wiki/Appowner-Testing-Pull-Request to point Vivado to local repo of XilinxTclStore, we get an error with the latest version of Vivado (2014.3):
ERROR: [Common 17-153] Param 'tclapp.sharedRepoPath' does not exist

This was working fine with previous versions 2014.1 and 2014.2.

Please investigate ASAP and close!

Hello,

I changed the version from 1.0 to 0.1 and updated the copyright information to Topic Embedded Products instead of Xilinx.

Thanks,

Niek van Agt

create_bd_cell is too simple, if we can create cell with property, it will be better.

This is a test.

Hi there. Your readme.md in the top level of the blue pearl app appears to be the "My Company" template. Can you please update it with a Blue pearl specific description of your app?

I have found numerous issues with enable_auto_incremental_compile.tcl. Unfortunately this scripts does not seem to be usable as is and I'm surprised that they are available at all in the Tcl Store.

I've attached a modified working version (tested in Vivado 2016.2) and discussed the changes made below:

Issue 1:
The scripts replaces launch_runs with its own incremental version. The problem is that reset_run (which is called by the GUI first) removes the .dcps that is meant to be reused before launch_runs is actually called. This makes these scripts useless in most cases, unless the user runs launch_runs without reset_runs in the Tcl Console.

reset_run should also be replacedo with an incremental version. The attached fixed versions does exactly that.

Issue 2:

line 259 is invalid as is:

set runs_placed_or_routed [ list ]

It should be:

set runs_placed_or_routed [ list $impl_runs ]

Issue 3:

Just an enhancement:

Replace line 246 as from:

puts "AutoIncrementalCompile: Incremental Flow not enabled as $guideFile for scheme $::tclapp::xilinx::incrcompile::autoIncrCompileScheme does not exist"

to become:

        if {[string length $guideFile] == 0} {
            puts "AutoIncrementalCompile: Incremental Flow not enabled no guide file for scheme $::tclapp::xilinx::incrcompile::autoIncrCompileScheme does exists"
        } else {
            puts "AutoIncrementalCompile: Incremental Flow not enabled as $guideFile for scheme $::tclapp::xilinx::incrcompile::autoIncrCompileScheme does not exist"
        }

Issue 4:

Proc ::tclapp::xilinx::incrcompile::get_placed_or_routed_dcp is flawed in its implementation as it does not create a copy of the checkpoint outside of the implementation directory.

This results in Vivado giving:

CRITICAL WARNING: [Vivado 12-3202] The incremental checkpoint file 'D:/proj/reference_designs/incremental_compile/incremental_compile.runs/impl_1/top_routed.dcp' is in the run directory 'D:/proj/reference_designs/incremental_compile/incremental_compile.runs/impl_1' and will be deleted the next time this run is reset.

It should create a copy of the found checkpoint outside of the implementation directory. This can be done by adding the following just before the last line of the function:

    set impl_dir_cdUp "$impl_dir/../"
    if {[string length $dcpFile] != 0} {
        set dcpFileName [file tail $dcpFile]
        set dcpFileTarget "${impl_dir_cdUp}${dcpFileName}"
        if {[catch {file copy -force $dcpFile $dcpFileTarget}]} {
            puts "AutoIncrementalCompile: Could not create copy of incremental checkpoint: Source = $dcpFile, Destination = $dcpFileTarget."
        } else {
            #puts "Successfully created reference copy of routed checkpoint for incremental reuse. Location: $dcpFileTarget."
        }
        set dcpFile $dcpFileTarget
    } else {
        # When the user resets the run in the GUI, the latest dcp will be removed and we will get in here.
        # However, we might still have a dcp which we've copied to the .runs directory previously that we can use.         
        # Check if it exists and if so reuse it:
        set top [ get_property TOP [current_fileset] ]
        set dcpFileTarget "${impl_dir_cdUp}${top}_routed.dcp"
        if {[file exists $dcpFileTarget] == 0} {
            set dcpFileTarget "${impl_dir_cdUp}${top}_placed.dcp"
            puts "2 = $dcpFileTarget"
        }

        if {[file exists $dcpFileTarget]} {
            set dcpFile $dcpFileTarget
            puts "AutoIncrementalCompile: Reusing previously copied guide file: $dcpFileTarget."
        }
    }

Issue 5:

Change Line 249 from

puts "AutoIncrementalCompile: Incremental Flow enabled for $run with ${refRun}'s guide file ($guideFile) as the reference checkpoint"

to

puts "AutoIncrementalCompile: Incremental Flow enabled for $run with ${refRun}'s guide file ($guideFile) as the reference checkpoint"

to make for easier reading...

Issue 6:

If no reuse checkpoint can be found, the script should correctly reset the previously set INCREMENTAL_CHECKPOINT property! If it isn't not done, Vivado falls over with:

ERROR: [Vivado 12-3280] Incremental checkpoint file 'D:/proj/reference_designs/incremental_compile/incremental_compile.runs/top_routed.dcp' set on run 'impl_1' does not exist.

This can be done using:

reset_property INCREMENTAL_CHECKPOINT $run