cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
1,766 Views
Registered: ‎02-08-2013

pre.tcl Lack of Usefulness (opinion)

Jump to solution

I just want to strongly state how useless I think the pre.tcl function in the Vivado GUI is. I'm at a loss as to why it would not execute before synthesis begins. I have read AR#51418 and it's ridiculous to suggest faking the time date stamp or be forced to manually alter the state of synthesis flags. 

 

https://forums.xilinx.com/xlnx/board/crawl_message?board.id=Vivado&message.id=2923 has an employee stating "Yes the AR (51418) is valid in Vivado 2014.4. This issue is not yet fixed in the tool", indicating it's a problem and here we are in 2018 and it's still not fixed?

 

There are numerous other postings indicating this is a problem for people.

 

Xilinx either needs to add a real pre synthesis TCL command process or provide a way to select to launch the current pre.tcl either before or after synthesis starts. I can think of many uses when it starts before but few if run from within synthesis. 

 

Please fix this. Thanks.

 

 

 

 

 

 

 

 

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
1,991 Views
Registered: ‎02-08-2013

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

Here is what I ended up doing. Saving and restoring the file timestamp is what worked for me. It does mess with CVS but since the file is updated every build for my use checkin is not necessary.

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA

View solution in original post

18 Replies
Highlighted
Guide
Guide
1,748 Views
Registered: ‎01-23-2009

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

This issue is not yet fixed in the tool", indicating it's a problem and here we are in 2018 and it's still not fixed?

 

You need to be careful in analyzing this statement. From what is said, you can infer that the employee agrees that this is a "bug" that needs "fixing", but you would be reading too much into it. The statement is merely saying that nothing has changed - the behavior is the same now in 2018 as it was in 2014. You should not infer that this means that it is supposed to be (or will ever be) "fixed".

 

In fact, it is not a "bug". It is a reality of how the Vivado project management system works, and a statement of what you can and cannot do seamlessly in a pre.tcl. Specifically, what you are trying to do (modify an RTL file in the pre.tcl) is not a recommended or normal flow - the pre.tcl is not supposed to be used for this.

 

And this is not merely a choice - it is not a simple matter of deciding to flip the order of the "out of date" checking and the pre.tcl... How/where these operations are done are part of whole Vivado design flow - they are in fact parts of very different processes - the "out of date" checking is done as part of the project management by the foreground process, whereas the pre.tcl is executed in the "non-project" background process in a completely different context. I would guess that this behavior will never change...

 

Now, I understand your goal - date stamping a build is a good idea, and is something that we do all the time. However, not through the pre.tcl script - that is the wrong place to do it...

 

If you want this kind of automation (ensuring that each build is identifiable, that it is archived in its own directory, or that it is in any way customized before launching), don't use the GUI for launching your build. If you, instead, use scripted project mode for launching your initial build, there are LOTS of fully supported mechanisms for getting date stamps (or any other information) into your build automatically. This is done as part of your Tcl build script (not the pre.tcl) - you then launch your build with

 

vivado -mode batch -source <build_script.tcl> -tclargs <any build arguments you want>

 

Vivado will even help you write this <build_script.tcl> - once you have a project that you have built in the GUI you can use File -> Project -> Write Tcl... - this will write out a Tcl script required to start "from scratch" and re-create the project state to exactly the same point that you are now.  You can then customize this to add the date stamping and any other build variations you want. Alternatively you can write the script from scratch yourself - there is enough documentation available to do so... It is not trivially easy, but it is not ridiculously complicated either...

 

When done this way, the build launch is automated, but the result (the project) is a full Vivado project - it is completely compatible with the GUI if you open it after the build is complete. So, after the build, you can open the GUI, use all the reporting and analysis capabilities of the GUI and even (if you want) re-run processes (although that breaks your automation). To be clear this is very different from scripted "Non-project" mode (which is an entirely different thing).

 

As a last point, I have seen a lot of people in the forums trying to use the pre.tcl for things that it is not suited for. Since the mechanism for handling the pre.tcl is never going to change, there may be an argument for having a different Tcl script that can be added to the project, which is executed at the beginning of the "launch_runs" process (in the foreground process). Again, this is an entirely different mechanism than the pre.tcl that is launched in the background process...

 

Avrum

Highlighted
Adventurer
Adventurer
1,747 Views
Registered: ‎02-08-2013

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

I just want to add that there is an inconsistency in how pre.tcl and synthesis play together. If I run a pre.tcl that modifies a file that file's contents and time date stamp are modified. Synthesis will use the new contents and yet after completing synthesis complain that the file has changed. So it's using the original file time date-stamp but the new contents. That is not how it would work.

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
Highlighted
Adventurer
Adventurer
1,746 Views
Registered: ‎02-08-2013

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

@avrumw, I agree with what you said. But it seems time-date stamp is something that a lot of designers would use but to say that I can't use the GUI when I want to do time-date stamping does not seem like the right way to do it. I guess my issue is that this IS a choice made by Xilinx and it's not helpful. I understand they have tried to untie my hands by providing full tcl functionality outside of the GUI and even in concert with it but this one choice of not providing a pre launch tcl script option escapes me.

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
Highlighted
Teacher
Teacher
1,722 Views
Registered: ‎07-09-2009

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

Its been a bug et in Xilxin that they do not suport a process that can be run before synthesis,

 

other tool flows do,

 

its been a bug et in vivado since it first came out 

 

 

and xilinx seem to have no intention of adding this very common functionality that other chip tools have,

 

but there again, I guess there is more money in the big designs,

   and big designs dont use gui, 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Teacher
Teacher
1,720 Views
Registered: ‎07-09-2009

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

@avrumw

 

I agree with you, lets not change pre.tcl,

 

I dont care if  its called prepre.tcl or what ever.

 

lets just have some way of running a tcl  before the synthesis starts,

 

its what other tools have,

     just not xilinx.

 

how hard can it be for xilxin to do that ?

 

is been asked for for years, been acknowledge by xilxin as something that is needed, 

    yet we still dont have the means to do so...

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
Explorer
Explorer
1,695 Views
Registered: ‎01-09-2012

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution
Highlighted
Adventurer
Adventurer
1,680 Views
Registered: ‎02-08-2013

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

@gmarinkovic That looks interesting. It's more complicated than I wanted to get into so I'm going to need to study it for a bit. 

 

@drjohnsmith Even with ISE you could not automatically run any kind of file before the synthesis. Seems like a Xilinx philosophy. 

 

So far I have been successful with this method using a VHDL package to pass in constants.

set temp_time [file mtime $fileDest] # Save the current time/date of the file.

Modify/regenerate the package file

file mtime $fileDest $temp_time # Restore to the original time/date.

 

This is going to mess with my CVS but that may be ok since the file is completely auto generated.

 

 

 

 

 

 

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
0 Kudos
Highlighted
Adventurer
Adventurer
1,992 Views
Registered: ‎02-08-2013

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

Here is what I ended up doing. Saving and restoring the file timestamp is what worked for me. It does mess with CVS but since the file is updated every build for my use checkin is not necessary.

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA

View solution in original post

Highlighted
Explorer
Explorer
1,611 Views
Registered: ‎01-09-2012

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

@rayhaynes

 

Hello Ray, my proposal which I have posted has to be extended for a general purpose use. What I stated was as well my first tries with Xilinx Vivado after porting my designs from EDK. As you can see in my thread I agree with you completely and I was as well asking Xiliinx for the elaborate proc, which was available in EDK but is not available any more in Vivado.

I ended up with following solution:

I create flip-flop primitives with NO clock and all data pins connected to GND or what ever you like. Sounds weird doesn't it?

Then with the tcl script I read the current time and date from my PC and initialize the flip-flops with this bit pattern. This solution is never outdated or cached and appears to work always. If you need help with this approach please let me know.

 

Cheers

Goran

0 Kudos
Highlighted
Adventurer
Adventurer
1,647 Views
Registered: ‎02-08-2013

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

@gmarinkovic,

I like the idea of not having a specially created VHDL file or IP to mess with. I would just create the F/Fs in the CPU register block and then set the initialization value via tcl. So I guess it's a good as time as any for me to learn how to get and set F/F properties via tcl, something I have not mastered yet. Thanks for your suggestion.

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
0 Kudos
Highlighted
Teacher
Teacher
1,629 Views
Registered: ‎07-09-2009

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

tcl is great,

 

the way on other system I have done this is to have a package of "constants" , that is generated by the tcl,

  

so if we had a means of running tcl before the run , then this would work

    as it does in other tools,

 

but not Xilinx, 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Explorer
Explorer
1,614 Views
Registered: ‎01-09-2012

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

@rayhaynes

 

No worries Ray I will contribute what I found out till now using this not very intuitive tool :-)

 

I needed as well the help from Xilinx hence nothing I show you here was invented by my company, but some elementary things came from Xilinx and some of my private time and effort to solve this problem.

I will not forget to mention the very helpful guy called Aidan Mac Creary from Xilinx which made it possible.

But now lets start with the simple things first:

 

1.) Getting the date and time of your computer by:

   set date_raw     [clock seconds]

   set c_date [clock format $date_raw -format %Y]
   scan $c_date "%d" c_date_int
   set c_date_int [expr {$c_date_int}]
   puts "C_DATE_YEAR   : $c_date_int"
   set binYear [dec2bin $c_date_int 32]
   puts "$binYear"

Here you see only the year... the month, day and time is equivalent. Most of the puts are needed because I like having the date as well in the log file for distinguishing the various runs and results on the FPGA.

 

2,) You will need to change the numbers from decimal to binary by Aidan's code:

proc dec2bin {i {width {}}} {
   #returns the binary representation of $i
   # width determines the length of the returned string (left truncated or added left 0)
   # use of width allows concatenation of bits sub-fields

   set res {}
   if {$i<0} {
      set sign -
      set i [expr {abs($i)}]
   } else {
      set sign {}
   }
   while {$i>0} {
      set res [expr {$i%2}]$res
      set i [expr {$i/2}]
   }
   if {$res eq {}} {set res 0}

   if {$width ne {}} {
      append d [string repeat 0 $width] $res
      set res [string range $d [string length $res] end]
   }
   return $sign$res
}

 

 

3:) Now we need to initialize the flip-flop by:

   set x 31
   set y 0
   while {$x>=0} {
      set val [string index $binYear $y]
      set reg */*/*/U0/sys_info_date_inst/gen_year[$x].year_dfpe_inst
      puts "reg is $reg: x is $x : val is $val"
      set_property -verbose INIT $val [get_cells $reg]
      set x [expr {$x - 1}]
      set y [expr {$y + 1}]
   }

Please note: "*/*/*/U0/sys_info_date_inst/gen_year[$x].year_dfpe_inst" Is my VHDL generate loop for the flip-flops called "year_dfpe_inst" and because I use a generate for my 32 bit wide flip-flop register the loop is "gen_year" and has an Index "[$x]". In addition you can see my component is called "sys_info_date_inst" and has a path of "*/*/*/U0/" in my Vivado block design hierarchy.

 

I guess the rest is trivial.

 

Cheers

Goran

Highlighted
Adventurer
Adventurer
1,605 Views
Registered: ‎02-08-2013

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

Thanks for your post but I didn't see it until just now and I had figured it out on my own. Here is what I did, very similar to you but has some differences. Maybe this will help other people.

 

First I moved the running of tcl script to the Implementation pre.tcl slot.

 

I used the same time date portion of tcl script I posted earlier.

 

Like you I converted the time-date to binary using the same routine but then also converted to an array of 1s and 0s

 

set bin_arr [split $bin_tds {}]

 

Then set the INIT property with this loop:

 

for {set i 0} {$i<64} {incr i} {
set_property INIT 1'b[lindex $bin_arr end-$i] [get_cells g_tds[$i].u_tds]
}

 

Then the trick is in the vhdl to manually instantiate (not infer) the flip-flops and put a dont_touch attribute on them.

 

 

g_tds : for i in 0 to 63 generate
attribute DONT_TOUCH of u_tds: label is "TRUE";
begin -- This begin is in addition to the main body begin and allows the attribute to apply to each f/f
u_tds : FDSE generic map (INIT => '0') port map(d => '0', c => '0', ce => '0', s => '0', q => time_date_stamp(i));
end generate;

 

Then connected time_date_stamp signal to my 64 bit cpu readback register.

 

When I look at the post implementation Netlist and check the Init property for the g_tds[*].u_tds cells it's set correctly for all the F/Fs. So this works. The only down side is the time/date is not readable via a functional pre-implementation simulation. But that is better than dealing with a stray time-date stamp vhdl file with a faked file timestamp.

 

Thanks for pointing me this direction which gave me the impetus to learn how to set properties via tcl. I'm not particularly proficient in tcl so please excuse any rough programming on my part. 

 

 

 

 

 

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
0 Kudos
Highlighted
Guide
Guide
1,597 Views
Registered: ‎01-23-2009

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

I have done things like this in the past...

 

I often combine the functionality of the "build_id" register with a scratch register. This makes things a bit easier...

 

Since the register in question is read/writeable (from whatever CPU is running), the synthesis tools will not want to remove it, so there is no need for a DONT_TOUCH. The INIT value controls the reset value, so the value after reset will be the build_id, but after reading it, software can use it as a scratch register (which is always useful for proving connectivity between the CPU and the FPGA/PL portion).

 

If you want to use more than a 32 or 64 bit ID register, you can also use a similar trick with INIT value of  LUT RAMs (distributed RAMs). Since each LUT RAM can hold 64 bits, you can have a 64x32 ID area with just 64 LUTs (16 CLBs in 7 series). With this you can put a fair amount of ID information in addition to the date; things like the user name of the individual that created the build, the revision control TAG number, etc...

 

The only complexity is the same thing described by others - you need to "rotate" the information; LUT0 holds bit 0 of all 64 words, LUT1 holds bit 1, etc... This rotation can be done in Tcl (its a bit messy, but definitely doable).

 

Avrum

0 Kudos
Highlighted
Teacher
Teacher
1,584 Views
Registered: ‎07-09-2009

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

whilst were doing show and tell

 

https://stackoverflow.com/questions/18141851/compile-date-and-time-in-fpga

 

this is the basis I use most of the time,

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Explorer
Explorer
1,576 Views
Registered: ‎01-09-2012

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

@@drjohnsmith

 

Hello John,

 

Well, the link shows hot to use it the Intel/Altera Quartus approach... which is fine and works as well in the tcl scrip flow of Vivado. Since I give my designs sometimes to colleagues I prefer the project mode and a GUI giving a pretty good idea how the firmware works and hos its structured..

The solution we talk about here is one being able to regenerate the compile date and time automatically, without having to remember to call another function before... it should simply work like in EDK the elaborate_proc tag, which  was used to call a tcl script during elaboration phase just before the synthesis starts... that would be the perfect solution... which Vivado does not support :-(

In my designs the version is on one hand the firmware compile time but as well a string for naming the project and some storage for the software version. Hence if we talk about version we mean the project name AND fw AND sw. version readable by register access for presenting them to the user for automatic version check and key element fault reporting.

Now to your proposal: How do you use it in project mode in Vivado?

 

Cheers

Goran

0 Kudos
Highlighted
Teacher
Teacher
1,557 Views
Registered: ‎07-09-2009

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

I think we all agree

 

TCL can solve anything,

 

and Vivado does not allow any way from the gui of running a tcl script before the rest of the vivado process runs,

 

 which is a long running grumble,

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Explorer
Explorer
1,513 Views
Registered: ‎01-09-2012

Re: pre.tcl Lack of Usefulness (opinion)

Jump to solution

@drjohnsmith

@rayhaynes

Gentlemen,

 

I did not state it explicitly but the script is added to the "tcl.pre" in the implementation tab and is called every time you synthesize.

Capture.JPG

 

So, the situation is not that bad as it might appear.

 

Concerning the optimization of the registers: I did it as well like you proposed by adding:

 

   gen_year : for count in 0 to 31 generate
      attribute dont_touch : string;
      attribute dont_touch of year_dfpe_inst: label is "true";
   begin

      year_dfpe_inst: FDPE
      port map
      (
         PRE                      => '0',
         CE                       => '0',
         C                        => i_clk,
         D                        => '0',
         Q                        => o_year(count)
      );

   end generate;

 

Cheers

Goran

 

0 Kudos