VHDL syntheses timestamp

[Arne Pagel]

Hello all,

I want to implement a "build" timestamp into some FPGA Designs (like the C __DATE__ makro).
Optimal would be someting like the 32Bit unix timestamp.

Does anybody know if there is some method to generate a timestamp during the "syntheses time" within
vhdl?

Target system is xilinx spartan3 / xilinx web pack

regards
Arne

 

[Allan Herriman]

On Sat, 21 Apr 2012 22:52:22 +0200, Arne Pagel wrote:

Hello all,

I want to implement a "build" timestamp into some FPGA Designs (like the
C __DATE__ makro).
Optimal would be someting like the 32Bit unix timestamp.

Does anybody know if there is some method to generate a timestamp during
the "syntheses time" within vhdl?

Target system is xilinx spartan3 / xilinx web pack

regards
Arne

I do the same thing in my projects here.

I also have constants for (an auto-incrementing) build number as well as
a source code management system unique tag number.


The bad news is that this can't be done in native VHDL.

The good news is that it's trivial to do if you script your builds (i.e.
you don't use an IDE (such as the ISE GUI) to build your designs).

Create a file with a package which contains the constants, e.g.


package foo is

constant underscore_underscore_date : integer := 0;

end package foo;

package body foo is
end package body foo;


Modify your (probably TCL) build scripts to parse this file and call a
program to patch in a new value for the constant before the file gets
compiled. Any scripting language would do; I use Perl for this.

The autoincrementing build number is a little more complicated - the
script will check out the file; read the value of the constant; increment
it then check the file back in.

Regards,
Allan

 

[HT-Lab]

On 22/04/2012 04:28, Allan Herriman wrote:

On Sat, 21 Apr 2012 22:52:22 +0200, Arne Pagel wrote:

Hello all,

I want to implement a "build" timestamp into some FPGA Designs (like the
C __DATE__ makro).
Optimal would be someting like the 32Bit unix timestamp.

Does anybody know if there is some method to generate a timestamp during
the "syntheses time" within vhdl?

Target system is xilinx spartan3 / xilinx web pack

regards
Arne


I do the same thing in my projects here.

I also have constants for (an auto-incrementing) build number as well as
a source code management system unique tag number.


The bad news is that this can't be done in native VHDL.

The good news is that it's trivial to do if you script your builds (i.e.
you don't use an IDE (such as the ISE GUI) to build your designs).
...


Modify your (probably TCL) build scripts to parse this file and call a
program to patch in a new value for the constant before the file gets
compiled. Any scripting language would do;

Here is a very simple ready made Tcl one:

http://www.ht-lab.com/freeutils/date2hdl/date2hdl.html

Good luck,

Hans
www.ht-lab.com

 

[Arne Pagel]

thanks for you hint,

The bad news is that this can't be done in native VHDL.

I have suspected something like that.

Modify your (probably TCL) build scripts to parse this file and call a
program to patch in a new value for the constant before the file gets
compiled. Any scripting language would do; I use Perl for this.

For my embedded C projects I do some similar stuff, I patch a version and date structure to the
binary output after compiling.
So modifying a vhdl file with the needed information would not be the problem for me.
Currently I am still using the ISE GUI, but I couldn't find any option to run custom a pre-build
command.
I am not sure that I am experienced enough with the build process to drop the GUI since I am using
some IP cores and other GUI settings for my design.

Is there any option to use still the GUI but run some customized programs at some point?
Maybe be adding some lines to some tcl script somewhere?

On the other hand I would be very attractive to have more control over the vhdl build since I always
have some problems determining the files which I should put under subversion revision control.

regards
Arne

 

[Enes Erdin]

On Sunday, April 22, 2012 11:36:05 AM UTC+3, Arne Pagel wrote:

thanks for you hint,

The bad news is that this can't be done in native VHDL.

I have suspected something like that.

Modify your (probably TCL) build scripts to parse this file and call a
program to patch in a new value for the constant before the file gets
compiled. Any scripting language would do; I use Perl for this.

For my embedded C projects I do some similar stuff, I patch a version and date structure to the
binary output after compiling.
So modifying a vhdl file with the needed information would not be the problem for me.
Currently I am still using the ISE GUI, but I couldn't find any option to run custom a pre-build
command.
I am not sure that I am experienced enough with the build process to drop the GUI since I am using
some IP cores and other GUI settings for my design.

Is there any option to use still the GUI but run some customized programs at some point?
Maybe be adding some lines to some tcl script somewhere?

On the other hand I would be very attractive to have more control over the vhdl build since I always
have some problems determining the files which I should put under subversion revision control.

regards
Arne

In the past I did something similar (a date stamp not a time stamp) to this but I was running it manually. I wrote a matlab code and I was running it with octave through a batch file via scheduled tasks, many times in a day. But later on I gave up using it because following a synthesis with date stamp was not so good for me besides it was confusing. I went on with a manual version and an automatic build number.

All levels of synthesis in ISE can be run with TCL scripts so instead of using ISE GUI you can run your synthesis with a script file, there are many tutorials for doing this.

Also in order to add a build number to your design simply you will write a function doing file read operation from a build file, increment it and write back again to that file and you will assign the return of the function (your build number) to your signal like :

signal build_no : std_logic_vector(15 downto 0) := MyBuildNumberFunction;

Assume that this assignment is done in a build.vhd file, at every synthesis build no will increase.

 

[Allan Herriman]

On Sun, 22 Apr 2012 03:28:53 +0000, Allan Herriman wrote:

On Sat, 21 Apr 2012 22:52:22 +0200, Arne Pagel wrote:

Hello all,

I want to implement a "build" timestamp into some FPGA Designs (like
the C __DATE__ makro).
Optimal would be someting like the 32Bit unix timestamp.

Does anybody know if there is some method to generate a timestamp
during the "syntheses time" within vhdl?

Target system is xilinx spartan3 / xilinx web pack

regards
Arne


I do the same thing in my projects here.

I also have constants for (an auto-incrementing) build number as well as
a source code management system unique tag number.


The bad news is that this can't be done in native VHDL.

The good news is that it's trivial to do if you script your builds (i.e.
you don't use an IDE (such as the ISE GUI) to build your designs).

Create a file with a package which contains the constants, e.g.


package foo is

constant underscore_underscore_date : integer := 0;

end package foo;

package body foo is end package body foo;


Modify your (probably TCL) build scripts to parse this file and call a
program to patch in a new value for the constant before the file gets
compiled. Any scripting language would do; I use Perl for this.

The autoincrementing build number is a little more complicated - the
script will check out the file; read the value of the constant;
increment it then check the file back in.

For completeness, I should probably point out that the other way of doing
this involves getting the value of your constant from a top-level generic.
Many compilers (e.g. XST) allow the values of generics to be changed from
the command line.

This still needs scripting if you want it to be automated.
Many IDEs will allow generic overrides through the GUI, but it is a
manual process.

Regards,
Allan

 

[Rob Gaddi]

On Sat, 21 Apr 2012 22:52:22 +0200
Arne Pagel <arne@pagelnet.de> wrote:

Hello all,

I want to implement a "build" timestamp into some FPGA Designs (like the C __DATE__ makro).
Optimal would be someting like the 32Bit unix timestamp.

Does anybody know if there is some method to generate a timestamp during the "syntheses time" within
vhdl?

Target system is xilinx spartan3 / xilinx web pack

regards
Arne

I've needed to do this several times, and I agree with everyone else.
It can't be done in native VHDL, and probably can't be done through the
GUI.

For Altera, I've used Tcl to set generics in the build script. For
Xilinx, I've used a Makefile to pass the result of $(date +s) as a
generic on the command line. You can also use any scripting language
as a part of your build process to generate a package file.

Having tried all those approaches, they're all pains in the backside,
and none of them could I find a way to integrate into the GUI based
flow.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[johnp]

On Sunday, April 22, 2012 2:09:44 AM UTC-7, Enes Erdin wrote:

On Sunday, April 22, 2012 11:36:05 AM UTC+3, Arne Pagel wrote:
thanks for you hint,

The bad news is that this can't be done in native VHDL.

I have suspected something like that.

Modify your (probably TCL) build scripts to parse this file and call a
program to patch in a new value for the constant before the file gets
compiled. Any scripting language would do; I use Perl for this.

For my embedded C projects I do some similar stuff, I patch a version and date structure to the
binary output after compiling.
So modifying a vhdl file with the needed information would not be the problem for me.
Currently I am still using the ISE GUI, but I couldn't find any option to run custom a pre-build
command.
I am not sure that I am experienced enough with the build process to drop the GUI since I am using
some IP cores and other GUI settings for my design.

Is there any option to use still the GUI but run some customized programs at some point?
Maybe be adding some lines to some tcl script somewhere?

On the other hand I would be very attractive to have more control over the vhdl build since I always
have some problems determining the files which I should put under subversion revision control.

regards
Arne

In the past I did something similar (a date stamp not a time stamp) to this but I was running it manually. I wrote a matlab code and I was running it with octave through a batch file via scheduled tasks, many times in a day.. But later on I gave up using it because following a synthesis with date stamp was not so good for me besides it was confusing. I went on with a manual version and an automatic build number.

All levels of synthesis in ISE can be run with TCL scripts so instead of using ISE GUI you can run your synthesis with a script file, there are many tutorials for doing this.

Also in order to add a build number to your design simply you will write a function doing file read operation from a build file, increment it and write back again to that file and you will assign the return of the function (your build number) to your signal like :

signal build_no : std_logic_vector(15 downto 0) := MyBuildNumberFunction;

Assume that this assignment is done in a build.vhd file, at every synthesis build no will increase.

I use a Perl script to update a Verilog parameter. You could do a similar thing with VHDL. I manually run the script when I want to embed the current Unix data/time value.

It's not automated, but it does the job for me.

John P

 

[padudle]

This is a good thread.

In out system, the application software would check a version numbe
register at boot time to make sure it was running with the right FPG
design. The problem with my manually updated version register is that
always forgot to update it until after the FPGA build and test work wa
done. To update the version number I had to re-run the FPGA build and, o
course, the testing.

Our FPGA had a PCIe interface so it must configure from an on-board flas
in order to boot in time for PCIe enumeration cycles. The on-boar
configuration flash is readable and writeable across the PCIe bus by th
Linux host. Eventually, I noticed that the Xilinx configuration bit fil
header contains a date and time that is automatically incremented at buil
time.

I tried to get the software guys to just read the bit file header and pars
the date and time out of there. They could have just used those fields a
a unique identifier. In the end, I could never convince them to do that.

I have actually, sent suggestions to Xilinx on this subject but I haven'
heard of any enhancements to support an automatically updated version o
date/time register in the code.



---------------------------------------
Posted through http://www.FPGARelated.com

 

[glen herrmannsfeldt]

padudle <93037@embeddedrelated> wrote:

In out system, the application software would check a version number
register at boot time to make sure it was running with the right FPGA
design. The problem with my manually updated version register is that I
always forgot to update it until after the FPGA build and test work was
done. To update the version number I had to re-run the FPGA build and, of
course, the testing.

If you use a version control systems, such as CVS, SVN,
(and I believe also GIT) there is a way to have it automatically
update a field in the file as it is checked in with the version
number. You should be able to use that to make a hardware readable
register with the version number in it.

-- glen

 

[Sean Durkin]

Kevin Neilson wrote:

I've done this with my own makefile, but next time I'd like to try
this with the Synplify callback function. (If you aren't using
Synplify, this probably won't help in your case.) Synplify lets you
write TCL callback functions, for example, one that will run right
before synthesis, so you could theoretically write a simple 3-line
TCL function that would create a date stamp even if you're using the
GUI.

Vivado now allows execution of pre-synthesis TCL scripts that can be
used to generate e.g. a VHDL package file containing version
numbers/time stamps.

Unfortunately, AFAIK this currently (as of Vivado 2013.2) is not usable
in this case, because Vivado will detect the source files have changed
AFTER synthesis, hence it will always complain that your synthesis
results are out-of date. This is a known bug and I was promised that
would be fixed in 2013.1, which obviously it wasn't...

So I'm sticking with my scripted flow.

Greetings,
Sean

 

[Kevin Neilson]

I've done this with my own makefile, but next time I'd like to try this with the Synplify callback function. (If you aren't using Synplify, this probably won't help in your case.) Synplify lets you write TCL callback functions, for example, one that will run right before synthesis, so you could theoretically write a simple 3-line TCL function that would create a date stamp even if you're using the GUI.

 

[Kolja Sulimma]

Am Montag, 23. April 2012 18:28:20 UTC+2 schrieb Rob Gaddi:

It can't be done in native VHDL,

It can, but the tools don't synthesize it.
In VHDL you can write code that is run once at the beginning of a simulation. It would be rather easy for a tool vendor (compared to the other complex tasks done during synthesis) to evaluate the results of these one time processes by simulation and use the results in synthesis.
These one time processes could be used to read /dev/time, to compute complex constants (sine tables, etc.) or to read look up tables from files.

I would be great if vendors implemented this. The language supports it.

Have fun,

Kolja

 

[jt_eaton]

I am curious as to why everyone seems to think that putting timestamps
in binaries is such a good idea? Whenever I inherit a design that I need t

modify then the first thing I do is recreate the original developmen
environment to the point where I can compile and produce the origina
binary.

You can't do that when you stuff in timestamps.


John Eaton



---------------------------------------
Posted through http://www.FPGARelated.com

 

[Rob Gaddi]

On Mon, 08 Jul 2013 10:52:33 -0500
"jt_eaton" <84408@embeddedrelated> wrote:

I am curious as to why everyone seems to think that putting timestamps
in binaries is such a good idea? Whenever I inherit a design that I need to

modify then the first thing I do is recreate the original development
environment to the point where I can compile and produce the original
binary.

You can't do that when you stuff in timestamps.


John Eaton

And yet the first thing I do when my programmer tells me there's a
problem with the FPGA he's talking to is ask him to confirm for me that
he's using the same timestamped build I think he is.

I update my binary timestamps using a TCL script; I can always disable
that script if I need to force a given timestamp. But on some level,
binary reproducibility is dead. All the FPGA vendors are forcing us
into complicated licensing schemes, even for the free versions of the
software, that pretty much guarantee that you won't be able to run a 5
year old version of the tools simply because no one will be willing to
generate you a license file for it.

But hey, who ever wanted repeatability anyhow? FPGA design is only fun
if you have to spend as much time playing "What stupid new thing did the
tools do today?" as you do actually designing logic.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[rickman]

On 7/8/2013 1:15 PM, Rob Gaddi wrote:

On Mon, 08 Jul 2013 10:52:33 -0500
"jt_eaton"<84408@embeddedrelated> wrote:

I am curious as to why everyone seems to think that putting timestamps
in binaries is such a good idea? Whenever I inherit a design that I need to

modify then the first thing I do is recreate the original development
environment to the point where I can compile and produce the original
binary.

You can't do that when you stuff in timestamps.


John Eaton


And yet the first thing I do when my programmer tells me there's a
problem with the FPGA he's talking to is ask him to confirm for me that
he's using the same timestamped build I think he is.

That doesn't absolutely require a timestamp. I have used a version
number that I manually set, negative values for development versions and
positive values for releases. Of course, this is a register to be read
by an MCU so if you don't have the MCU there is no easy way to read the
version number.

How was the timestamp read or verified again?

I update my binary timestamps using a TCL script; I can always disable
that script if I need to force a given timestamp. But on some level,
binary reproducibility is dead. All the FPGA vendors are forcing us
into complicated licensing schemes, even for the free versions of the
software, that pretty much guarantee that you won't be able to run a 5
year old version of the tools simply because no one will be willing to
generate you a license file for it.

I am still running the last version I got from my paid for (ultra low
end) license that expired some four years ago. I have to remember to
request a new license and so far they have not had a problem with new
computers and I'm currently on my third or maybe fourth one. I hope
they don't crap me out at some point, but I'm not sure it would be a
huge problem. As long as the HDL code works with the newer free tools
it shouldn't be a problem.

But hey, who ever wanted repeatability anyhow? FPGA design is only fun
if you have to spend as much time playing "What stupid new thing did the
tools do today?" as you do actually designing logic.

I found a long time ago that it is a *lot* of work to verify that the
tools give you the hardware you expect. Mostly I have to code very
small modules and build up. I try to do that even when I don't need to
verify tool efficiency because it also makes test benches simpler to
write. I write more of them as I build up, but each one only has to
test the new functionality of the combined structure. Then when I need
to verify that the tool is doing a decent job, I can synthesize on the
same small modules I verified and vice versa.

--

Rick

 

[KJ]

On Monday, July 8, 2013 1:15:39 PM UTC-4, Rob Gaddi wrote:

On Mon, 08 Jul 2013 10:52:33 -0500 "jt_eaton" <84408@embeddedrelated> > wrote: > I am curious as to why everyone seems to think that putting timestamps
in binaries is such a good idea? Whenever I inherit a design that I need to
modify then the first thing I do is recreate the original development
environment to the point where I can compile and produce the original
binary. You can't do that when you stuff in timestamps.

And yet the first thing I do when my programmer tells me there's
a problem with the FPGA he's talking to is ask him to confirm for me that
he's using the same timestamped build I think he is.

This is a version control (or lack thereof) problem. Simply use a tool such as Subversion, Sourcesafe, Git, etc. and you won't need to ask your first question either. The programmer should be able to provide you with his version controlled build script that links in your FPGA file into the bigger picture...after first providing you the trace file that was captured from the system that identified the software version number in the first place.

I update my binary
timestamps using a TCL script; I can always disable that script if I need to
force a given timestamp.

The value there is that you can in theory walk up to a system, query it and then get that binary timestamp read back. The cost is that this process should be more work and effort (and therefore cost) then verifying version numbers with the version control system. The big word in that sentence though is 'should'. If you're working with folks who don't like (or understand) version control, or don't like to check things in until they are 'done' and queue up a huge pile of unrelated changes into a check-in then it may be easier to walk up to that system after all...assuming it's accessible.

But even in that situation, the better course is to shame them into this by simply asking how did they verify that they are using your latest FPGA? Hopefully that brings up a discussion on version control where they will look rather foolish if they choose to defend the out of control method.

There is more to this then version control, but using version control is a huge start.

Kevin Jennings

 

[peter dudley]

Please listen to Kevin and all the others who recommend good version control practices with FPGA design. Most of the best version control tools, Subversion, GIT, etc, are free and open now. Check in early and check in often. Don't worry about disk space. Disk drive space is essentially free now.

The original question of this thread was about how to get a timestamp or similar unique identifier into each and every compile. A precompile tcl script sounds like a good approach. It could spit out a little HDL module with the desired info so that it can be read from the fpga by a cpu.

My old company (wisely) tried to make each fpga bitfile uniquely identifiable so that the control software could verify that it is running the right fpga at boot time. It was very difficult to remember to manually edit a bit of HDL just to insert some updated version code.

Software guys often insert the subversion revision code into their compiled software builds. That is ideal but doesn't work with FPGA's because you don't know if your code works (meets timing, etc) and is releaseable until after you compile.

Pete

 

[Petter Gustad]

peter dudley <padudle@gmail.com> writes:

The original question of this thread was about how to get a timestamp
or similar unique identifier into each and every compile. A precompile
tcl script sounds like a good approach. It could spit out a little HDL
module with the desired info so that it can be read from the fpga by a
cpu.

Or you can simply pass a generic/parameter which contains the SHA-1 or
whatever in your synthesis script.

Another common approach is go generate a MIF file or similar RAM
contents file containing the SHA-1/dirty/passed. Typically this RAM will
act like a ROM (e.g. the write signal is never asserted within the FPGA
logic)

My old company (wisely) tried to make each fpga bitfile uniquely
identifiable so that the control software could verify that it is
running the right fpga at boot time. It was very difficult to remember
to manually edit a bit of HDL just to insert some updated version
code.

It's also quite common to use a script to extract the SHA-1 etc. and
insert it automatically.

Software guys often insert the subversion revision code into their
compiled software builds. That is ideal but doesn't work with FPGA's
because you don't know if your code works (meets timing, etc) and is
releaseable until after you compile.

You can still generate the SHA-1 etc. and keep track if that particular
release meet timing etc. elsewhere. Or if you use the mentioned MIF
approach described above you can use a vendor supplied tool to quickly
update the content of the RAM after build to include the timing
information.

//Petter
--
..sig removed by request.

 

[edmoore]

Disadvantages with generating the timestamp from the HDL are that you might want to make changes after synthesis, for example changes to the timing constraints or initialising block rams.

When programming the fpga in slave mode with a cpu, some people read the timestamp embedded in the .bit file, and that works well.