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