Reason for compile ordering?

[Paddy3118]

Would someone reply with /why/ it is that an instantiated component
must be compiled before that which instantiates it in VHDL?
I find it irksome to create a compile orderwhich may span sources in
multiple libraries and think I would be less annoyed if i knew what
this rule is /for/.

I've been told that VHDL is based on some mil. language that had this
feature (Algol? Ada?), but if so, what is the reason it was added to
its precursor language, and why do we keep it now?

I can see that maybe compiler checks for source code updates against
compiled libraries (a la make), are useful, but I cannot find what
this VHDL compile rule gives you.

- Paddy.

Thanks in advance for your help.

 

[Jonathan Bromley]

On Thu, 7 May 2009 05:58:04 -0700 (PDT), Paddy3118 wrote:

Would someone reply with /why/ it is that an instantiated component
must be compiled before that which instantiates it in VHDL?

Be careful with your terminology; there are two quite different
cases here.

1) COMPONENT instantiation
In this case, a COMPONENT declaration provides a prototype
of the thing you aim to instantiate. This declaration
details the types and names of generics and ports, and
of course the name of the thing, but no more than that.
At some point you will create, and compile, an entity
and architecture to match that component prototype.
But you can compile the instantiating architecture
before that is done. Component instantiation facilitates
a separate-compilation flow, and top-down design.

Of course the component declaration must be compiled first.
You can do this either by putting the component declaration
in the architecture's declarative region, in which case it
obviously gets compiled before the instance, or else you
can put it in a package and "use" that package, in which
case your compilation won't get past the "use" clause until
the package has already been compiled. You are very unlikely
to suffer compile-order difficulties in this case.

A VHDL component is somewhat like a footprint - complete
with pads, pin locations and names, etc - in a PCB layout
package; you can put the footprint down on a PCB long
before you have the chip that will be used to populate
that footprint.

2) DIRECT instantiation
~~~~~~~~~~~~~~~~~~~~~~~
In this case you explicitly instantiate an entity.
instance_name: entity work.component_name port map (...);
No component declaration is needed. Clearly, in this case
the compiler must already know about the "footprint"
(ports, generics) of the entity, otherwise it can't check
that the instantiation makes sense. Direct instantiation
enforces the bottom-up compilation order that you're
probably complaining about, because an entity must have
been compiled before the compiler encounters an instance
of it.

I find it irksome to create a compile orderwhich may span sources in
multiple libraries and think I would be less annoyed if i knew what
this rule is /for/.

Have you ever tried calling a C function with more
arguments than it expects? Fewer? In classic K&R C
there is almost no compile-time checking of function
arguments, and it can cause all manner of hard-to-find
bugs; hence ANSI C's function prototypes. Components
are VHDL's "entity prototypes".

Verilog freely allows you to instantiate a module
without having compiled it, and does not support anything
like VHDL component declarations (prototypes). Such an
instance cannot be checked in any way by the compiler;
you could get the port connections completely wrong, and
the compiler is none the wiser. All that checking gets
done much later, when you elaborate the design (i.e. you
specify a top-level module and ask your simulator or synth
tool to put its structure together). This is very, very
late in the day to be finding out that you completely
screwed-up a connection list somewhere. VHDL stops you
making that error, right up front.

In some VHDL compilers, you can play games with compiler
command line options to simplify things. For example,
ModelSim has the "-just" option; it tells the compiler
to scan source files and compile just one kind of design
unit (entity, architecture, package etc). This flow of
compile commands works in almost all practical cases:

vcom -just p <all my vhdl files> ;# compile packages
vcom -just b <all my vhdl files> ;# compile package bodies
vcom -just e <all my vhdl files> ;# compile entities
vcom -just a <all my vhdl files> ;# compile architectures
vcom -just c <all my vhdl files> ;# compile configurations

Compiling all entities before you try to compile any architecture
will generally fix the majority of compile-order issues.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[JimLewis]

My favorite example that the compile rules prevents is:
Designer A uses shared declarations from an external file
and compiles their design.
Designer B modifies the shared declarations in the external
file and compiles their design.

In VHDL, Designer A must recompile their design before it
can be simulated with designer B's chip.

Also note that dependencies in VHDL are on the primary units
(entity, package declaration, and configurations) and not
architectures. So if you change an architecture in a design
and do not change the entity ports, you can simply recompile
with the vcom -just a <file name> trick that jonathan showed.

Pragmatically speaking, either use the project compile
capability of the simulator or a script file to recompile.
I find that the compilers are fast enough these days that
you can generally run a lazy script that recompiles either your
entire design or a large portion of it and starts a simulation
is faster than typing or using the GUI to recompile one or two
designs and restarting a simulation.

Cheers,
Jim
SynthWorks VHDL Training
www.SynthWorks.com

 

[Paddy3118]

Thanks Jonathan and Jim for spending the time to reply, it's
appreciated.
I gueess my problem is that we always elaborate, in fatc we simulate
before releasing anything. Our flows often combine compilation and
elaboration in a single script.
Because we do projects with both Verilog and VHDl, in practice, we
would find I/O miss-matches at roughly the same time when using either
Verilog or VHDL but with the VHDL flow we have the extra ordering to
do. Both Cadence as well as your example with Mentor seem to recognise
some of the practicalities of VHDL in use versus the languages
definition and provide ways to alleviaate the problem. Is this
insistance on bottom-up compiling really such a win? A better use of
todays multi-cores might be to compile in parallel, disregarding
compile order, then always elaborate (one or multiple top levels in
parallel) for the extra checks that compiling in bottom-up fashion
would give you.

Just a thought, Donald 'Paddy' McCarthy.

 

On 7 Maj, 14:58, Paddy3118 <paddy3...@googlemail.com> wrote:

Would someone reply with /why/ it is that an instantiated component
must be compiled before that which instantiates it in VHDL?
I find it irksome to create a compile orderwhich may span sources in
multiple libraries and think I would be less annoyed if i knew what
this rule is /for/.

I've been told that VHDL is based on some mil. language that had this
feature (Algol? Ada?), but if so, what is the reason it was added to
its precursor language, and why do we keep it now?

I can see that maybe compiler checks for source code updates against
compiled libraries (a la make), are useful, but I cannot find what
this VHDL compile rule gives you.

- Paddy.

Thanks in advance for your help.

If you are using emacs to edit your files you can generate
Makefiles automatically - it/he/she will parse the instantiation
hierachy and reflect that in the generated Makefile.
You can also run emacs in batch mode to generate the Makefile.

As far as I got it, emacs generated makefiles will recompile
entities/architectures that instantiate components (i.e. not
only direct instatiation) if those component's corresponding
entities have changed.
This is strictly not needed, but may put some issues to compile
time instead of elaboration time. Direct instantiated entities
will thus also work.

Note that the emacs generated Makefile can not handle
dependencies towards external libraries.

If you are using modelsim you can use "vmake" to produce a
makefile. vmake gives you a makefile (on stdout) that can be used
to re-create the current vhdl library you have. So once you
are satisfied with your library - run vmake and you get
the Makefile required to recreate that library - with correct
compile order.

All this [makefile stuff] is probably not so interesting when
you are actively working in a design (except that you may save
some time, only recompiling whats necessary) but much more so
when you come back after a year or two, or dive into someone
else's design.

Regards -- Pontus

 

[Paddy3118]

On May 7, 8:51 pm, pontus.stenst...@gmail.com wrote:

On 7 Maj, 14:58, Paddy3118 <paddy3...@googlemail.com> wrote:



Would someone reply with /why/ it is that an instantiated component
must be compiled before that which instantiates it in VHDL?
I find it irksome to create a compile orderwhich may span sources in
multiple libraries and think I would be less annoyed if i knew what
this rule is /for/.

I've been told that VHDL is based on some mil. language that had this
feature (Algol? Ada?), but if so, what is the reason it was added to
its precursor language, and why do we keep it now?

I can see that maybe compiler checks for source code updates against
compiled libraries (a la make), are useful, but I cannot find what
this VHDL compile rule gives you.

- Paddy.

Thanks in advance for your help.

If you are using emacs to edit your files you can generate
Makefiles automatically - it/he/she will parse the instantiation
hierachy and reflect that in the generated Makefile.
You can also run emacs in batch mode to generate the Makefile.

As far as I got it, emacs generated makefiles will recompile
entities/architectures that instantiate components (i.e. not
only direct instatiation) if those component's corresponding
entities have changed.
This is strictly not needed, but may put some issues to compile
time instead of elaboration time. Direct instantiated entities
will thus also work.

Note that the emacs generated Makefile can not handle
dependencies towards external libraries.

If you are using modelsim you can use "vmake" to produce a
makefile. vmake gives you a makefile (on stdout) that can be used
to re-create the current vhdl library you have. So once you
are satisfied with your library - run vmake and you get
the Makefile required to recreate that library - with correct
compile order.

All this [makefile stuff] is probably not so interesting when
you are actively working in a design (except that you may save
some time, only recompiling whats necessary) but much more so
when you come back after a year or two, or dive into someone
else's design.

Regards -- Pontus

Thanks Pontus for your reply.

It is not so much how to create the compile order, it is the need to
do so in the first place that I question.

- Paddy.

 

[Paddy3118]

On May 7, 8:51 pm, pontus.stenst...@gmail.com wrote:

On 7 Maj, 14:58, Paddy3118 <paddy3...@googlemail.com> wrote:



Would someone reply with /why/ it is that an instantiated component
must be compiled before that which instantiates it in VHDL?
I find it irksome to create a compile orderwhich may span sources in
multiple libraries and think I would be less annoyed if i knew what
this rule is /for/.

I've been told that VHDL is based on some mil. language that had this
feature (Algol? Ada?), but if so, what is the reason it was added to
its precursor language, and why do we keep it now?

I can see that maybe compiler checks for source code updates against
compiled libraries (a la make), are useful, but I cannot find what
this VHDL compile rule gives you.

- Paddy.

Thanks in advance for your help.

If you are using emacs to edit your files you can generate
Makefiles automatically - it/he/she will parse the instantiation
hierachy and reflect that in the generated Makefile.
You can also run emacs in batch mode to generate the Makefile.

As far as I got it, emacs generated makefiles will recompile
entities/architectures that instantiate components (i.e. not
only direct instatiation) if those component's corresponding
entities have changed.
This is strictly not needed, but may put some issues to compile
time instead of elaboration time. Direct instantiated entities
will thus also work.

Note that the emacs generated Makefile can not handle
dependencies towards external libraries.

If you are using modelsim you can use "vmake" to produce a
makefile. vmake gives you a makefile (on stdout) that can be used
to re-create the current vhdl library you have. So once you
are satisfied with your library - run vmake and you get
the Makefile required to recreate that library - with correct
compile order.

All this [makefile stuff] is probably not so interesting when
you are actively working in a design (except that you may save
some time, only recompiling whats necessary) but much more so
when you come back after a year or two, or dive into someone
else's design.

Regards -- Pontus

Thanks Pontus for your reply.

It is not so much how to create the compile order, it is the need to
do so in the first place that I question.

- Paddy.

 

[Andy]

On May 7, 8:23 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

Compiling all entities before you try to compile any architecture
will generally fix the majority of compile-order issues.

Compiling all entities and then all architectures in an arbitrary
order will usually work unless you also specify the architecture name
in the instantiation:

instance_name: entity work.entity_name(architecture_name)...

Doing so puts complete configuration control in the existing source
code, not leaving anything up to LRA rules or to separate
configuration files and their requisite component declarations. There
are times when configurations and components give you additional
flexibility, particularly without modifying the "source code", but
most applications simply don't need it. And don't get me started on
configurations of components in a library other than that containing
the configuration...


Some tools (e.g. NC-sim) will automatically scan a list of files,
directories, etc., and given a top level module, will determine the
correct order of compilation for you, then compile it all in that
order. I'v even had it work on a single file where it needed to re-
order the compilation order from what was shown in the file.

Andy

 

[Paddy3118]

On May 7, 1:58 pm, Paddy3118 <paddy3...@googlemail.com> wrote:

Would someone reply with /why/ it is that an instantiated component
must be compiled before that which instantiates it in VHDL?
I find it irksome to create a compile orderwhich may span sources in
multiple libraries and think I would be less annoyed if i knew what
this rule is /for/.

I've been told that VHDL is based on some mil. language that had this
feature (Algol? Ada?), but if so, what is the reason it was added to
its precursor language, and why do we keep it now?

I can see that maybe compiler checks for source code updates against
compiled libraries (a la make), are useful, but I cannot find what
this VHDL compile rule gives you.

- Paddy.

Thanks in advance for your help.

From the answers given so far, (my thanks); it seems that this
compilation ordering restriction allows more static language checking
to be done at compilation, but no more than could be done by un-
ordered compilation followed by machine ordering during elaboration. I
still think you would be more productive by dropping this sometimes
arduous constraint from the language and moving to machine ordering
during elaboration for a slight drop in what can be checked at compile
time. You will have to elaborate to complete the static compiler-type
checks anyway so why not let the computer take the strain?

- Paddy.

 

[Jonathan Bromley]

On Thu, 14 May 2009 22:33:46 -0700 (PDT), Paddy3118 wrote:

From the answers given so far, (my thanks); it seems that this
compilation ordering restriction

First, please get your facts straight. VHDL does *not* require
ordered compilation if you choose to use component declaration
rather than direct entity instantiation. Many folk choose not
to take advantage of this, because they find that direct
instantiation (with the consequent compile-ordering concerns)
is less trouble and at least as flexible.

allows more static language checking
to be done at compilation, but no more than could be done by un-
ordered compilation followed by machine ordering during elaboration.

Yes, but the static checking gets done module-by-module in VHDL,
so your errors are localized. That, surely, is precisely why any
half-decent language separates interface (component declaration,
function prototype) from implementation (entity/architecture,
function body). If you are happy to write all your code and
find critical errors of interconnect only right at the very
end, then good luck to you. If, like me, you prefer to localize
your decisions and have those decisions checked early in the
coding process, then VHDL's way is good.

Verilog is the obvious existence-proof that you can indeed
design a language that does not require such declaration of
module interfaces, and performs all the interface-connectivity
checking at the end of elaboration, long after you've made
all your mistakes.

I still think you would be more productive by dropping this sometimes
arduous constraint from the language and moving to machine ordering
during elaboration for a slight drop in what can be checked at compile
time.

Personally I very much disagree, but you're entitled to your
opinion and many others share it with you.

You will have to elaborate to complete the static compiler-type
checks anyway

Why so? VHDL's rules for all practical purposes ensure that
complete, successful compilation will produce a bunch of
library objects that are guaranteed to elaborate successfully.
Of course you must do the elaboration at some point, but
in VHDL that's not primarily to complete the checking;
it's to build the model that you will simulate/synthesize.

so why not let the computer take the strain?

On this point I totally agree with you. But I don't find
it any strain at all to tell VHDL what I think I'm doing,
so that it can check my assumptions for me.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Nicolas Matringe]

Paddy3118 a écrit :

why not let the computer take the strain?

With emacs VHDL mode I let the computer take the strain of generating a
complete and ordered makefile so that I don't have to bother about
compile order.

Nicolas

 

[Mike Treseler]

Nicolas Matringe wrote:

Paddy3118 a écrit :
[...] why not let the computer take the strain?

With emacs VHDL mode I let the computer take the strain of generating a
complete and ordered makefile so that I don't have to bother about
compile order.

.... or having to look at the makefile,
or bother with a license server.
Right-click, [Make]
Indeed, let the computer do some work.

-- Mike Treseler