When I compile my project in Quartus (15.0 Webedition) I get following error message:
10430 VHDL Primary Unit Declaration error at nios.vhd: primary unit "NIOS" already exists in library "nios"
In my project files I have the file "NIOS.vhd". After compiling, Quartus generates another file in the db-folder with the name "nios.vhd". This files is not the same as my file "NIOS.vhd" and therefore I get this error message. What is not clear at this point, why Quartus generates another file in the database? How can I get rid of this problem?
See QuartusII Help -
VHDL Primary Unit Declaration error at <location>: primary unit "<name>" already exists in library "<name>" (ID: 10430)
CAUSE: In a primary unit declaration at the specified location in a VHDL Design File (.vhd), you declared the specified primary unit. However, the specified library already contains a primary unit with the same name.
See IEEE Std 1076-2008
13.1 Design units, para 2:
primary_unit ::= entity_declaration
| configuration_declaration
| package_declaration
| package_instantiation_declaration
| context_declaration
| PSL_Verification_Unit
para 5:
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 shall have a simple name that is unique within the given library, and each architecture body associated with a given entity declaration shall have a simple name that is unique within the set of names of the architecture bodies associated with that entity declaration.
1.3 Structure and terminology of this standard, 1.3.1 General, para 4:
In this document, the word shall is used to indicate a mandatory requirement. The word should is used to indicate a recommendation. The word may is used to indicate a permissible action. The word can is used for statements of possibility and capability.
1.3.3 Semantic description, para 2:
The following terms are used in these semantic descriptions with the following meanings:
erroneous: The condition described represents an ill-formed description; however, implementations are not required to detect and report this condition. Conditions are deemed erroneous only when it is impossible in general to detect the condition during the processing of the language.
error: The condition described represents an ill-formed description; implementations are required to detect the condition and report an error to the user of the tool.
The 'shall have' is mandatory in VHDL, where a violation is an ill-formed description and is reported as an error.
It's complaining your declaration of nios doesn't match an existing declaration already in the library. (If they matched the existing declaration would be replaced):
13.1 Design units, para 1:
Certain constructs are 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.
13.5 Order of analysis, para 5:
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 shall be reanalyzed before they can be used again.
So if re-analyzed a primary unit of the same entity class (13.1, primary_unit) you'd replace the primary unit. Try with a different entity class of primary unit and you'll get an error.
Back to QuartusII Help:
ACTION: Compile the two primary units into different libraries or assign them unique names.
You state your working directory contains your analyzed design files and a file named nios.vhd that's a distinct name from your design file NIOS.vhd.
The issue isn't file name, it's primary unit name. In this case it's a primary unit name Altera feels free to use indiscriminately in the process of synthesis. Thankfully it's a primary unit of a different entity class. You'd be left with circular analysis dependencies (from 13.5) that'd be harder to fathom.
You should change your primary unit name, and because it's common to tie primary unit name to file name (while a design file can contain any number of design units), you might also change your design file name.
Related
Reading through the LRM, and it appears to imply anything can be aliased, but when I try the following, ActiveHDL tells me a design unit is expected:
entity some_entity is
.....
end entity;
alias another_name is some_entity;
The LRM states (in 6.6.1) that
An object alias is an alias whose alias designator denotes an object (i.e., a constant, a variable, a signal, or a
file). A nonobject alias is an alias whose alias designator denotes some named entity other than an object.
An alias can be declared for all named entities except for labels, loop parameters, and generate parameters.
Or is it just the case that because an alias is a declarative item, it must exist in an declarative region? But given that an alias takes on the same class as the aliased item, surely it should be allowed in the same region? This appears to compile ok:
package alias_package is
alias another_name is work.some_entity;
end package;
Explanation for the above request: Lets say I want to rename some_entity, but it is used all over my design. Creating an alias to it would allow this, keeping the old name as an alias to the new one. Using the package would be unsuitable here as it would still require name modification at instantiation.
Is this worthy of a request for the next LRM?
Or is it just the case that because an alias is a declarative item, it must exist in an declarative region?
Yes. A design file is comprised of one or more design units and an entity declaration is a design unit. A design unit is comprised of one or more nested declarative regions. The root declarative region (with an optional context clause encompasses the design unit itself and any subordinate secondary design units.
There's no delimiter for declarative regions other than the end of a design unit.
But given that an alias takes on the same class as the aliased item, surely it should be allowed in the same region?
No. A declaration doesn't take effect (it's name doesn't become visible) until after the declaration is complete. Here, after end [entity_simple_name] ;.
A new design unit begins with optional context items (beginning with reserved words library, use or context) followed by a primary unit declaration or secondary unit body (indicated by one of the reserved words entity, architecture, package, configuration, context (here ignoring PSL, tool directives and comments).
Design units are independently analyzed.
The classes of aliases are object and non-object. An alias declaration targets the declaration of a named entity (and some name declarations are implicit).
Is this worthy of a request for the next LRM?
This question is a request for a subjective opinion without a clear use case (providing examples, particularly in a design hierarchy). The reason isn't clear. What work are you trying to avoid?
As an opinion otherwise, no.
There are also parts of the standard that are poorly supported by synthesis vendors that already address modifying binding from the default by exception (configuration declarations containing context specifications or component instantiation with the reserved word configuration).
I am working on a design (VHDL-2002) where user-defined attributes are attached to different design units. The attribute values may be passed through the design hierarchy.
Is there a (common) way to list the values of these attributes at synthesis time? Something like VHDL's report statement, but to be evaluated during synthesis...
My problem is with regard to design analysis, changes to the code, e.g. switching to generics instead of attributes, are undesired.
At the moment Xilinx XST 14.4 is used for synthesis, but I'm open to alternatives.
I'm asking since XST does report the attribute "Detected unknown constraint/property custom_attr", but unfortunately not its value.
I'm using sharpsnmplib open source library to compile MIB files and use them in my custom snmp browser. The issue is that sharpsnmplib cannot compile RMON2-MIB file. And subsequent libraries that use it cannot be compiled as well. As it turns out, the (first) issue is with the text (RMON2-MIB.txt):
LastCreateTime ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes an object that stores the last time its
entry was created.
This can be used for polling applications to determine that an
entry has been deleted and re-created between polls, causing
an otherwise undetectable discontinuity in the data."
SYNTAX TimeStamp
Sharpsnmplib’s textual convention interpreter contains this text:
/*
* RFC2579 definition:
* Syntax ::= -- Must be one of the following:
* -- a base type (or its refinement), or
* -- a BITS pseudo-type
* type
* | "BITS" "{" NamedBits "}"
*
* From section 3.5:
* The data structure must be one of the alternatives defined
* in the ObjectSyntax CHOICE or the BITS construct. Note
* that this means that the SYNTAX clause of a Textual
* Convention can not refer to a previously defined Textual
* Convention.
…
Sharpsnmplib interpreter’s source
RMON2-MIB
RFC 2579
Interesting thing is that TimeStamp IS the textual convention defined in the SNMPv2-TC. And RMON2-MIB defines its own textual convention that uses TimeStamp. There are several other textual conventions in the RMON2-MIB that refer textual conventions from other MIB files.
Thus, if I’ve got it right, RMON2-MIB violates RFC2579. But this doesn’t make sense if RMON2-MIB is actively used MIB file.
What am I missing? How should the RMON2-MIB be properly interpreted?
First, #SNMP's open source MIB parser SharpSnmpLib.Mib is buggy and obsolete, as #SNMP Pro has a new SharpSnmpPro.Mib.
The code you found was even older (my handmade version), so I never expected it able to parse difficult MIB documents.
Second, RMON2-MIB is a very complex one, as it does rely on both SMIv2 core MIBs, as well as several SMIv1 ones. That requires you to have all dependencies properly located (using the correct copies, instead of downloading corrupt ones from the Internet).
Third, there is no conflict between RFC 2579 and RFC 4502 (RMON2-MIB). RMON2-MIB defines its own textual convention that uses TimStamp and that's nothing special or wrong.
I'm having some trouble designing a single port rom onto a spartan 6 board. I use the provided core generator to create block memory and choose single port rom with 32 bit width and 256 depth with a coe file that just counts from 0 to 255. I drop the rom into my vhdl as a component and add the XilinxCoreLib as a library. When I try to generate the programming file I get the translate error:
logical block 'rom1' with type 'rom' could not be
resolved. A pin name misspelling can cause this, a missing edif or ngc file,
case mismatch between the block name and the edif or ngc file name, or the
misspelling of a type name. Symbol 'rom' is not supported in target
'spartan6'.
I'm currently using Xilinx ISE 13.1 if that helps. I feel like this should be really easy to do but I haven't been able to find how to do it.
Edit: Thanks everyone, was a combination of things. Wrong speed grade, and didn't add a copy of the ngc file to my working directory. I'll use arrays in the future.
Easiest way is to forget the vendor tools altogether and simply declare a constant array!
If this is in a package separate from the rest of the design, a few lines of printf's or a simple script can generate the VHDL boilerplate around the contents, which come from your assembler or whatever tool creates the actual data
Since you're adding a Xilinx generated core to your design in ISE, you need to add both the VHD file and the NGC file via "Add Source" via the Project menu.
Even easier, depending on how large your ROM needs to be and what data goes into it, would be to not even bother with a Xilinx core, but to use pure VHDL to declare a constant array and initialization values right in your VHDL file. Here is an example:
type array_ROM is array (0 to NUMBER_OF_ROWS-1) of std_logic_vector (ROM_BITWIDTH-1 downto 0);
signal my_ROM : array_ROM
:=
(
x"12345678",
x"ABCDEF01",
...
x"01010101"
);
Now, you don't put the elipsis (...) in that initialization list, just put rows of constants with bit widths matching ROM_BITWIDTH. The NUMBER_OF_ROWS is the number of address locations you need in the ROM. In this example, ROM_BITWIDTH would have to be set to 32 as I've used 32-bit hexadecimal constants in the initialization list. Being a signal, it's actually modifiable, so if you need it to be constant, just use "constant" instead of signal.
I guess the problem is, as the message says, a misspelling. to get the correct component declaration/instantiation, select your rom.xco in the design-window of ISE. then select "view vhdl instantiation template" from process window. use the component declaration and instantiation described therein.
There are a number of things that can cause this problem, one is that you are using a blocck that was generated for another FPGA family and using it inside the Spartan6. the other is that you may have generated the ROM using an older version of the tool and the wrapper for the ROM has changed since then.
You can either generate a anrray like Brian suggested and forgetting about the tool specific ROM type, or re-generate the IP under your curernt project settings and see how it goes.
How does a compiler detect duplicate definition across translation unit. Suppose there were a extern const variable declaration in an header file. If this header file was used in more than one translation unit - each having a separate definition - each TU object creation would be successful, however when the final executable is created the error is thrown.
Is there a reference table created to account these duplication while linking each of these TU (during the creation of the executable)?
Any link on this topic would be helpful.
Thanks in advance for your explanation.
Normally this would be detected by the linker, rather than the compiler. The linker can then either coalesce the variables (often required for sloppy C/C++ coding) or report an error.
Yes, the linker builds a list of unresolved external references and then eventually goes on to attempt to resolve them one by one.