GHDL 0.29 for Windows hangs if the number of statements in a process is even on
stackoverflow.
The three test cases work with the -r150 svn ghdl, plus Brian Drummond's OSVVM
library patch file #17858: osvvm_for_svn_r150.patch compiling as an mcode
version under OS X. (gna has an outdated or otherwise invalid SSL certificate,
I make a one time exception every time.)
If anyone can address the issue on stackexchange, feel free.
I also found something while checking the OS X mcode version.
Converting the three test cases to one file by grabbing all the text,
commenting out the intervening text statements and uniquifying the behavior
names:
========
helloworld.vhdl uniquified architectures, three test cases in one source file
========
use std.textio.all;
entity hello_world is
end hello_world;
architecture behaviour1 of hello_world is
begin
process
variable l : line;
begin
write (l, String'("Hello world!"));
writeline (output, l);
wait;
end process;
end behaviour1;
--The following program hangs and doesn't print anything.
use std.textio.all;
entity hello_world is
end hello_world;
architecture behaviour2 of hello_world is
begin
process
variable l : line;
begin
assert false report "Foo" severity note;
write (l, String'("Hello world!"));
writeline (output, l);
wait;
end process;
end behaviour2;
--The following program outputs the two assertions and then the "Hello world!"
message.
use std.textio.all;
entity hello_world is
end hello_world;
architecture behaviour3 of hello_world is
begin
process
variable l : line;
begin
assert false report "Foo" severity note;
assert false report "bar" severity note;
write (l, String'("Hello world!"));
writeline (output, l);
wait;
end process;
end behaviour3;
==========
Looking in the LRM (93):
11.4 Order of analysis
The rules defining the order in which design units can be analyzed are direct
consequences of the visibility rules. In particular:
a. A primary unit whose name is referenced within a given design unit must
be analyzed prior to the analysis of the given design unit.
b. A primary unit must be analyzed prior to the analysis of any
corresponding secondary unit.
In each case, the second unit depends on the first unit.
The order in which design units are analyzed must be consistent with the
partial ordering defined by the above rules.
If any error is detected while attempting to analyze a design unit, then the
attempted analysis is rejected and has no effect whatsoever on the current
working library.
A given library unit is potentially affected by a change in any library unit
whose name is referenced within the given library unit. A secondary unit is
potentially affected by a change in its corresponding primary unit. If a
library unit is changed (e.g., by reanalysis of the corresponding design
unit),then all library units that are potentially affected by such a change
become obsolete and must be reanalyzed before they can be used again.
IEEE 1076-1993 appears to be telling us that if I reanalyze the entity
hello_world the previously analyzed architectures (secondary units) behaviour1
and behaviour2 in the case of the third instance of the entity hello_world,
should be obsolete and require re-analysis.
underline added.
gdhl allowed any of the three to run.
david_koontz@Macbook: ghdl -a helloworld.vhdl
david_koontz@Macbook: ghdl -r hello_world behaviour1
Hello world!
david_koontz@Macbook: ghdl -r hello_world behaviour3
helloworld.vhdl:48:8:@0ms:(assertion note): Foo
helloworld.vhdl:49:8:@0ms:(assertion note): bar
Hello world!
david_koontz@Macbook: ghdl -r hello_world behaviour2
helloworld.vhdl:29:8:@0ms:(assertion note): Foo
Hello world!
This appears to violate the directive must (emphasis added):
0.2 Structure and terminology of this document
...
Additionally, the word "must" is used to indicate mandatory weight. This word
is preferred over the more common "shall," as "must" denotes a different
meaning to different readers of this standard.
a. To the developer of tools that process VHDL, "must" denotes a
requirement that the standard imposes. The resulting implementation is required
to enforce the requirement and to issue an error if the requirement is not met
by some VHDL source text.
b. To the VHDL model developer, "must" denotes that the characteristics of
VHDL are natural consequences of the language definition. The model developer
is required to adhere to the constraint implied by the characteristic.
c. To the VHDL model user, "must" denotes that the characteristics of the
models are natural consequences of the language definition. The model user can
depend on the characteristics of the model implied by its VHDL source text.
Where "must" means compliance is required by the tool developer.
Admittedly this is a seldom encountered case.
You can also peruse
11.1 Design units
Certain constructs may be independently analyzed and inserted into a design
library; these constructs are called design units. One or more design units in
sequence comprise a design file.
design_file ::= design_unit { design_unit }
design_unit ::= context_clause library_unit
library_unit ::=
primary_unit
| secondary_unit
primary_unit ::=
entity_declaration
| configuration_declaration
| package_declaration
secondary_unit ::=
architecture_body
| package_body
Design units in a design file are analyzed in the textual order of their
appearance in the design file. Analysis of a design unit defines the
corresponding library unit in a design library. A library unit is either a
primary unit or a secondary unit. A secondary unit is a separately analyzed
body of a primary unit resulting from a previous analysis.
The name of a primary unit is given by the first identifier after the initial
reserved word of that unit. Of the secondary units, only architecture bodies
are named; the name of an architecture body is given by the identifier
following the reserved word architecture. Each primary unit in a given library
must have a simple name that is unique within the given library, and each
architecture body associated with a given entity declaration must have a simple
name that is unique within the set of names of the architecture bodies
associated with that entity declaration.
Entity declarations, architecture bodies, and configuration declarations are
discussed in Section 1. Package declarations and package bodies are discussed
in Section 2.
which specifies analysis order and can be used to demonstrate the legality of
helloworld.vhdl.
And I simply tried to run the behaviour1 and behavior2 units before expecting
to have to remove the second and third invocations of the entity declarations
for hello_world.
The gcc based version of ghdl running under linux does the correct thing:
david_koontz@lubuntu: ghdl -e hello_world behaviour1
e~hello_world-behaviour1.o: In function `__ghdl_ELABORATE':
e~hello_world-behaviour1:(.text+0x43): undefined reference to
`work__hello_world__ARCH__behaviour1__ELAB'
Elaboration a required step before running, and behaviour1 not being valid,
requiring re-analysis.
Separate elaboration isn't required in the mcode version (see ghdl user manual
3.1.2 Elaboration command) and when invoked:
david_koontz@Macbook: ghdl -e hello_world behavior2
error: cannot find architecture behavior2 of entity "hello_world"
This error message even occurs for the last analyzed secondary unit
(behaviour3).
This sort of implies the analysis order rules need to be enforced specifically
in the mcode version(s). You could note that elaboration (linking) actually
occurs at run time in ghdl. It seems to require adding elaboration tags to the
library configuration (e.g. work-obj93.cf).
Commenting out the second two entity declarations (and their associated use
clauses for good measure) produces the expected behavior in the gcc version of
ghdl. The ability to independently 'elaborate' the various architectures (e.g.
behaviour1.o).
david_koontz@lubuntu: ghdl -e hello_world behaviour1
david_koontz@lubuntu: ghdl -r hello_world behaviour1
Hello world!
(And can you imagine VHDL lawyers worry about this stuff?)
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
