VHDL syntheses timestamp

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

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

Am Montag, 23. April 2012 18:28:20 UTC+2 schrieb Rob Gaddi:
> It can't be done in native VHDL,=20

It can, but the tools don't synthesize it.
In VHDL you can write code that is run once at the beginning of a simulatio=
n. 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 pro=
cesses by simulation and use the results in synthesis.=20
These one time processes could be used to read /dev/time, to compute comple=
x 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

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

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

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.

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

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 times=
tamps=20
> > in binaries is such a good idea? Whenever I inherit a design that I nee=
d to=20
> > modify then the first thing I do is recreate the original development=
=20
> > environment to the point where I can compile and produce the original=
=20
> > binary. You can't do that when you stuff in timestamps.=20

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

This is a version control (or lack thereof) problem.  Simply use a tool suc=
h 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 ve=
rsion controlled build script that links in your FPGA file into the bigger =
picture...after first providing you the trace file that was captured from t=
he system that identified the software version number in the first place.

> I update my binary=20
> timestamps using a TCL script; I can always disable that script if I need=
 to=20
> 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 s=
hould be more work and effort (and therefore cost) then verifying version n=
umbers with the version control system.  The big word in that sentence thou=
gh 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' a=
nd 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?  H=
opefully that brings up a discussion on version control where they will loo=
k 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

Please listen to Kevin and all the others who recommend good version contro=
l practices with FPGA design. Most of the best version control tools, Subve=
rsion, 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 si=
milar unique identifier into each and every compile.  A precompile tcl scri=
pt 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 identifiab=
le so that the control software could verify that it is running the right f=
pga 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 d=
on't know if your code works (meets timing, etc) and is releaseable until a=
fter you compile.

    Pete

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. 

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.