managing vhdl projects with Makefiles

[alb]

Hi everyone,

this is another attempt to switch to a completely batched mode to manage
my vhdl projects. The rationale behind is that I'd like to get a
directory structure for my projects that is tool independent and I'd
like to use Makefiles to handle vhdl dependencies and development phases
(simulation, synthesis, p&r, ...).

I have read several articles on this subject but none of them was
presenting an end-to-end flow for an example design and I every time
struggled a lot trying to put everything together [1].

I know about 'vmk' tool, but to be honest I haven't found any additional
information on top of the man page. If anyone here is regularly using it
I'd appreciate some examples.

At Cern it has been developed an 'hdlmake' tool to generate makefiles
and much more (like downloading stuff from remote repositories or
launching simulations/synthesis on remote servers), but to be honest I
prefer tools that "do one thing and to it well".

I know that OpenCores.org is striving for a standard structure for
projects and it qualifies some of them as 'Certified Projects' (OCCP) if
they obey to certain rules, including having make-scripts. But to be
honest I lost my way several times in the past.

Any suggestion/comment is welcome.

Al

[1] OT: I have to say that I've been lacking 'laziness' recently and
this is one of the main reasons why I'm still stuck with this silly
business!

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Rob Gaddi]

On Fri, 02 Aug 2013 15:52:24 +0200
alb <alessandro.basili@cern.ch> wrote:

Hi everyone,

this is another attempt to switch to a completely batched mode to manage
my vhdl projects. The rationale behind is that I'd like to get a
directory structure for my projects that is tool independent and I'd
like to use Makefiles to handle vhdl dependencies and development phases
(simulation, synthesis, p&r, ...).

I have read several articles on this subject but none of them was
presenting an end-to-end flow for an example design and I every time
struggled a lot trying to put everything together [1].

I know about 'vmk' tool, but to be honest I haven't found any additional
information on top of the man page. If anyone here is regularly using it
I'd appreciate some examples.

At Cern it has been developed an 'hdlmake' tool to generate makefiles
and much more (like downloading stuff from remote repositories or
launching simulations/synthesis on remote servers), but to be honest I
prefer tools that "do one thing and to it well".

I know that OpenCores.org is striving for a standard structure for
projects and it qualifies some of them as 'Certified Projects' (OCCP) if
they obey to certain rules, including having make-scripts. But to be
honest I lost my way several times in the past.

Any suggestion/comment is welcome.

I've seen those same tools, and given them brief consideration, but at
the end of the day I go back to GNU make. I don't want some
specialized make tool that cares whether I'm writing HDL, C, or
anything else.

That said, dependencies are a horror, and I've found no consistent way
to do it across target platforms; my Xilinx makefiles look entirely
different than my Altera ones, and both of them have serious
limitations relating the source files to the project. The Altera stuff
is particularly touchy; I've found that in order to do anything
meaningful with makefiles I wind up needing to have supplemental Tcl
scripts that my makefile calls through quartus_sh.

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

 

[Theo Markettos]

alb <alessandro.basili@cern.ch> wrote:

Hi everyone,

this is another attempt to switch to a completely batched mode to manage
my vhdl projects. The rationale behind is that I'd like to get a
directory structure for my projects that is tool independent and I'd
like to use Makefiles to handle vhdl dependencies and development phases
(simulation, synthesis, p&r, ...).

What vendor are you using? That's the biggest question here, rather than
the HDL side.

We have makefiles for Altera that will:
Checkout any component repositories needed by the project
Build Bluespec -> Verilog
[or run the Bluespec simulator]
Run Qsys to generate Altera's Verilog IP (including some of the B->V output)
Synthesise the Verilog in Quartus
Download to an FPGA
Load the FPGA memory/flash/etc

Each step is only a few lines, so don't need a special tool, but they're
fairly Altera- and project- specific. Up to source code level the directory
structure isn't really important, and then the structure is set by the
synthesis tools. Bluespec figures out the children of a component so we
don't have to list them in the makefile, and the Altera project files
(either Qsys or Quartus) itemise the components, so we don't have to specify
that in the makefile either.

The main part of the work is working out the incantations to run tools from
the command line not via the GUI (and make them obey dependencies).

I'm not as familiar with VHDL as I am with Verilog, but I don't think
there's much different that would apply to VHDL here (some of Altera's IP is
in VHDL, but it doesn't affect the build process).

Theo

 

Yes, batch mode and tool independence, that's something I'd like as well. But not make files. You can see my efforts in this area here:

http://pdt.github.io/ttask.html

and more details (with GHDL, but mostly applies to other sims) here:

http://pdt.github.io/ghdl_extension.html

ttask is something that I'm currently working on, and at the moment it only supports simulation, (Modelsim, Xilinx, GHDL, iverilog), although my plan is to add support for other phases in FPGA development as well.

Basically, you tell it type of project (e.g. modelsim, xilinx-isim, etc), where your source files are (i.e. you don't have to conform to a pre-defined layout), and you tell it some build properties (e.g. build directory, number of simulation threads (which has an impact on how many licenses get checked out **)), then you run tasks for running simulations.

Note that it is only version 0.5, so I'm still adding functionality and I'd wager it has plenty of rough edges as well.

For other phases of FPGA development, I did start to add support for Xilinx ISE, but I abandoned it to focus my efforts on the simulators. There is xilinx-ise.tcl file in the source tree, but that's way, way out of date, to the extent that it's completely broken, hence you won't find any documentation for it. My plan is to fix it, and add support for altera tools, etc.

Paul.

** for paid tools, the free ones including modelsim altera and Xilinx webpack are happy to run parallel simulations.

Note also that I'm primarily developing this under Linux, and all my tests work there. I do run it under Windows however as well, but just the Windows version of Vivado has a bug in it which currently stops my scripts working with it... but I'll fix that and get round to reporting the Vivado bug (xvhdl -work lib=dir doesn't seem to work).

 

[alb]

On 02/08/2013 18:51, Theo Markettos wrote:

alb <alessandro.basili@cern.ch> wrote:
Hi everyone,

this is another attempt to switch to a completely batched mode to manage
my vhdl projects. The rationale behind is that I'd like to get a
directory structure for my projects that is tool independent and I'd
like to use Makefiles to handle vhdl dependencies and development phases
(simulation, synthesis, p&r, ...).

What vendor are you using? That's the biggest question here, rather than
the HDL side.

I use the Libero-Soc workflow which is using ModelSim and Synplify Pro
for simulation and synthesis, while is using Designer for the p&r.

In my simple approach I would have rather had a simple Makefile (GNU
Make) to handle dependencies but use tcl scripts to handle tool options
and the like.

Unfortunately I'm not very skilled in tcl yet (read: I do not know tcl
yet!) and I would have liked to start from an example rather than
starting from scratch.

We have makefiles for Altera that will:
Checkout any component repositories needed by the project
Build Bluespec -> Verilog
[or run the Bluespec simulator]
Run Qsys to generate Altera's Verilog IP (including some of the B->V output)
Synthesise the Verilog in Quartus
Download to an FPGA
Load the FPGA memory/flash/etc

Is you makefile available somewhere? Or any simplified version of it?
I understand the steps are pretty tool-dependent but I guess I can skim
that part out and fit my need in...hopefully.

[]

The main part of the work is working out the incantations to run tools from
the command line not via the GUI (and make them obey dependencies).

I've found this article on Microsemi knowledge-base page:

http://www.actel.com/kb/article.aspx?id=SL5619

I'll give it a try and see how it goes.

 

[alb]

On 02/08/2013 18:01, Rob Gaddi wrote:
[]

this is another attempt to switch to a completely batched mode to manage
my vhdl projects. The rationale behind is that I'd like to get a
directory structure for my projects that is tool independent and I'd
like to use Makefiles to handle vhdl dependencies and development phases
(simulation, synthesis, p&r, ...).
[]

I've seen those same tools, and given them brief consideration, but at
the end of the day I go back to GNU make. I don't want some
specialized make tool that cares whether I'm writing HDL, C, or
anything else.

IMO what makes vmk interesting is that it analyzes your code base and
generates a GNU Makefile to handle dependencies. I'm not sure then how
does it handle simulations/synthesis and so on.

Well, in my case I should say that I'm not dealing with hundreds of
files and I could potentially do a dependency tree by hand, without any
additional hassle. But I guess that my laziness prevents me from doing
something manually if I can automate it .

That said, dependencies are a horror, and I've found no consistent way
to do it across target platforms; my Xilinx makefiles look entirely
different than my Altera ones, and both of them have serious
limitations relating the source files to the project. The Altera stuff
is particularly touchy; I've found that in order to do anything
meaningful with makefiles I wind up needing to have supplemental Tcl
scripts that my makefile calls through quartus_sh.

I would imagine though that while dependencies are handled by Makefile
rules, then actual tasks can be done by external tcl scripts. Already
something similar would make my life way easier than pushing buttons on
that silly GUI.

 

[Theo Markettos]

alb <alessandro.basili@cern.ch> wrote:

On 02/08/2013 18:51, Theo Markettos wrote:
We have makefiles for Altera that will:
Checkout any component repositories needed by the project
Build Bluespec -> Verilog
[or run the Bluespec simulator]
Run Qsys to generate Altera's Verilog IP (including some of the B->V
output)
Synthesise the Verilog in Quartus
Download to an FPGA
Load the FPGA memory/flash/etc

Is you makefile available somewhere? Or any simplified version of it?
I understand the steps are pretty tool-dependent but I guess I can skim
that part out and fit my need in...hopefully.

Here's the toplevel makefile:
http://www.cl.cam.ac.uk/~atm26/ephemeral/cheri-toplevel-Makefile

There are child makefiles for building Bluespec, ROMs, etc, but they're not
that interesting... Bluespec does its own dependency handling, so the
essence of the build is a single line (with a few alternatives for varieties
of simulator), and the ROMs are standard software build makefiles.

I've found this article on Microsemi knowledge-base page:

http://www.actel.com/kb/article.aspx?id=SL5619

I'll give it a try and see how it goes.

Hmm... I see what you mean. Altera's version of same can be driven from
shell (and so Makefile) rather than TCL. So it's much easier to plumb into
existing infrastructure.

Theo

 

[alb]

Hi Theo,

On 05/08/2013 22:37, Theo Markettos wrote:
[]

Is you makefile available somewhere? Or any simplified version of it?
I understand the steps are pretty tool-dependent but I guess I can skim
that part out and fit my need in...hopefully.

Here's the toplevel makefile:
http://www.cl.cam.ac.uk/~atm26/ephemeral/cheri-toplevel-Makefile

thank you loads! There are quite interesting points in this file. I like
the overall structure and it seems quite user friendly. As a top level
makefile it can recursively enter in all subdir and have everything done.

My directory tree is essentially the following:

constraints/ -- constraint files
rtl/ -- vhdl code
simulation/ -- simulation scripts
synthesis/ -- synthesis scripts
stimuli/ -- testbench with cases and so on

Your example would be perfect as a top level calling each of the
Makefiles present in each subdir.

Currently I've started using 'vmk' and I find it quite interesting. I'm
trying to understand some more details regarding predefined tools and
how to configure new ones.

Apparently it exists also an 'lmk' tool for libraries, but I still
haven't found it anywhere on the net (so far).

One big bit I learned through this quest is that if entities and
architectures are split on separate files (as well as packages'
declarations and packages' bodies), then modifying an architecture (or a
package body), does not trigger a recompilation of any other unit, which
may be quite beneficial for large projects.