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.

 

[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.

 

[pontus.stenstrom]

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]

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]

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]

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]

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.

 

[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]

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