1. Home
  2. Field-Programmable Gate Arrays
  3. Quartus and source control
  4. Page 2

Quartus and source control

Good timing indeed on this post. Our group is using Subversion. What I am hoping to do is to incorporate the Subversion-stored revision number into the actual design (working on an FPGA). I would love to grab the design's Rev. #, store it as a constant in some register map, which is readable by another system (i.e. seamless, automatic firmware version control).

The way I've thought of doing this is writing some C program which finds the Subversion revision number through command line + some parsing, and then outputs a properly formated VHDL file which maps my rev # to a memory address. That should be a piece of cake, but what I can't figure out is how to get Quartus to execute my C program pre-compilation. I'm thinking I could do it if I cast away my GUI and start using TCL/command like compilation.

All that would probably work, but would take a bit of a learning curve (time our project can't afford) and there seams like there should be a better way. Anyone have any suggestions?

Regards,

Kev> "Derek Simm> |> Is there a recommended source control system?

Reply to
kevinwolfe
Loading thread data ...

Maybe subversion fills in revision headers like CVS. Have a tcl or bash script grab the revision header line, say

-- $Revision: 1.42 $ and convert it to a vhdl package file with a vector constant, say constant revision_c : byte_t := x"8e"; that becomes readback data.

-- Mike Treseler

Reply to
Mike Treseler

CVS is getting very long in the tooth. At some point I recommend you try Subversion; it makes distributed development very smooth, including conflict resolution. There is also a VS plugin (AnkhSVN,

formatting link
as well as a very slick Explorer plugin (TortoiseSVN,
formatting link

Reply to
toby

It doesn't; this is a deliberate design decision.

However, there are several ways of finding revision data from the command line[1] (or makefile). The main gotcha here is that your build might quite easily be from a 'mixed revision' working copy, if you have selectively updated it.

[1] see the Subversion book
formatting link
or built-in help for command summaries.

Reply to
toby

Yea, what I had my eye on was

svn list --verbose {file/dir name}

Conveniently, this lists the file/dir's revision # first. My lack of understanding lies on the Quartus side. Is it possible to run a tcl script before all compilations using the GUI tools? I don't mind myself using the command line, but might have a hard time converting over all the team members.

Kev> Mike Treseler wrote:

Reply to
kevinwolfe

Rather than creating a constant in a package from the source version info, you might be able to use a top level generic, and pass the value for that generic in via the synthesis command line in your build script?

Andy Jones

Reply to
Andy

This strikes me as more trouble than it is worth. Normally there are many source files in a project and each has a different revision number that could change daily. Product releases don't happen nearly that often because of QA testing.

If I wanted to read back something, it would have to do with the overall product release date. I think I would take Andy's advice and just make this some kind of constant that I just type in. Then no one else has to know or worry about it.

-- Mike Treseler

Reply to
Mike Treseler

Mike Treseler kirjoitti:

Subversion has only one version number for whole project. At first it sounded strange, but after half year working with Subversion, that is an excelent thing.

When I make a FPGA version (program file) I make a release from trunk (svn copy). Check out the release to specific version directory and run Quartus and check in program files (sof/pof) to repository.

Since the .sof and .pof have a version number, it can be easily identify source files based on the .pof/.sof version number. (if source_a.vhdl is lower than fpga.pof, then it must be in pof and vice versa)

Antti

Reply to
antti.tyrvainen

We do this to store the time of compile (32 bit int) somewhere that the processor can then read back. Also, I put the compile time in human readable (YYMMDDhh) form into the USERID part of the bitstream so it is easily read back with Impact when people want a quick check.

All done in the scripts, so no-one has to worry about getting it right.

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt
Reply to
Martin Thompson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.