automatic firmware revision for VHDL

Dear Experts,
i'd like to introduce to my design one register containing a firmware
revision. Very probably the firmware revision would be a data when the
VHDL code was checked out from the CVS repository where I store the
project.

The problem I encounter is how to translate the CVS last-commit data
of the project currently checked out, and translate it into VHDL code
to be a part of the project.

Example:

yesterday i committed at the end of day the whole project, thus when I
check it out today and burn, one of the registers I export should
contain yesterday's date as a firmware revision

i check out the project corresponding to a date 2 weeks ago, the
firmware register should contain a number corresponding to date at
which the version of the project I have checked out was committed.

This would allow very easily match the firmware and CVS source
together.....

any ideas how to do it?

thanks
david

dejfson@gmail.com

<> wrote in message
news:fa17637b-3631-4238-9b79-...
> Dear Experts,
> i'd like to introduce to my design one register containing a firmware
> revision. Very probably the firmware revision would be a data when the
> VHDL code was checked out from the CVS repository where I store the
> project.
>
> The problem I encounter is how to translate the CVS last-commit data
> of the project currently checked out, and translate it into VHDL code
> to be a part of the project.
>
> Example:
>
> yesterday i committed at the end of day the whole project, thus when I
> check it out today and burn, one of the registers I export should
> contain yesterday's date as a firmware revision
>
> i check out the project corresponding to a date 2 weeks ago, the
> firmware register should contain a number corresponding to date at
> which the version of the project I have checked out was committed.
>
> This would allow very easily match the firmware and CVS source
> together.....
>
> any ideas how to do it?
>
> thanks
> david

Can't you use the $Id$/$Revision$ string in your source file and translate
that to a date/version constant with a bit of Tcl?

This might help you a bit :
http://www.ht-lab.com/freeutils/date2hdl/date2hdl.html

Hans
www.ht-lab.com

HT-Lab

Hi Hans,
thanks for reply. In fact I've solved the problem in a very similar
way. Before every compilation I run small TCL script which creates a
single entity having only one 32bit output std_logic_vector. This
vector is fed by output of 'clock seconds' command of TCL. This gives
you exact time of compilation, however it does not give you the date
of last commit into CVS. Thus the time information I get is
approximative.

dejfson@gmail.com

On May 26, 4:22 pm, "dejf...@gmail.com" <dejf...@gmail.com> wrote:
> Hi Hans,
> thanks for reply. In fact I've solved the problem in a very similar
> way. Before every compilation I run small TCL script which creates a
> single entity having only one 32bit output std_logic_vector. This
> vector is fed by output of 'clock seconds' command of TCL. This gives
> you exact time of compilation, however it does not give you the date
> of last commit into CVS. Thus the time information I get is
> approximative.

If you can get the timestamp data into an integer or vector format
externally, you can pass it in to the top level entity via a generic.
Most compilers/synthesizers have command line options to specify
values of top level generics.

Andy

Andy

On 26 May, 17:37, "HT-Lab" <han...@ht-lab.com> wrote:
> <dejf...@gmail.com> wrote in message
>
> news:fa17637b-3631-4238-9b79-...
>
>
>
> > Dear Experts,
> > i'd like to introduce to my design one register containing a firmware
> > revision. Very probably the firmware revision would be a data when the
> > VHDL code was checked out from the CVS repository where I store the
> > project.
>
> > The problem I encounter is how to translate the CVS last-commit data
> > of the project currently checked out, and translate it into VHDL code
> > to be a part of the project.
>
> > Example:
>
> > yesterday i committed at the end of day the whole project, thus when I
> > check it out today and burn, one of the registers I export should
> > contain yesterday's date as a firmware revision
>
> > i check out the project corresponding to a date 2 weeks ago, the
> > firmware register should contain a number corresponding to date at
> > which the version of the project I have checked out was committed.
>
> > This would allow very easily match the firmware and CVS source
> > together.....
>
> > any ideas how to do it?
>
> > thanks
> > david
>
> Can't you use the $Id$/$Revision$ string in your source file and translate
> that to a date/version constant with a bit of Tcl?
>
> This might help you a bit :http://www.ht-lab.com/freeutils/date2hdl/date2hdl.html
>
> Hanswww.ht-lab.com

Hi,

Just out of interest, this is a solution that I implemented on a
previous project (i.e. based on CVS $Revision$ tag).

The problems I had with this
- It was based on the revision of a single file only rather than the
design as a whole. We therefore had to force revision updates of this
file when required (therefore we could have just used a VHDL
constant).
- It didn't handle "hacks". i.e. temporary RTL changes that were not
commited to CVS. Therefore we had different FPGA's

I would be interested to hear what mechanisms other people use on
bigger projects, and a non-ideal world

Steven


with different

moogyd@yahoo.co.uk

Steven,
I've just published the 'final' version on the alteraforum.com. Of
course it does not support hacks. I have serious doubts that there
could exist any solution using hacks as what is not in the cvs is
simply forgotten in time.

link:
http://alteraforum.com/forum/showthread.php?t=2600

dejfson@gmail.com

writes:

> I would be interested to hear what mechanisms other people use on
> bigger projects, and a non-ideal world
>

I embed the "time of compile" into the FPGA, using a TCL script to
create a (very simple) VHDL file.

I also overwrite that VHDL file after synthesis, so you can't
accidentally re-compile an FPGA with the same timestamp in it.

I also embed the timestamp into the UserID of the bitstream, which
means I can very easily read it out using JTAG, which is handy in some
circumstances.

Cheers,
Martin
--

TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Martin Thompson