I'm trying to create a TIG constraint in the UCF file of my project.
Problem is, I just can't get the hierarchical name right.
The structure I'm dealing with is the following (pseudo-code showing the hierarchical position of the signal that needs to be addressed):
m1: module1
g1: for i in 0 to m generate
g2: if x /= 0 generate
m2: module2
reset : in std_logic;
Among others I tried NET "m1/m2/reset" TIG; , NET "m1/g1.g2.m2/reset" TIG; and NET "m1/g1*.g2.m2/reset" TIG; (the last one was inspired from one of the intermediate files produced during synthesis *.xdl).
What is the correct way to address the reset net within m2? I looked at the Xilinx Constraint Guide but found no detailed explanation on this.
A recent XST User Guide might have a section on XST Naming Conventions with subsections on *XST Net Naming Conventions, XST Instance Naming Conventions and XST Name Generation Control. The last telling how to control name generation in the netlist (hierarchy separator, bus delimiter, case, duplication suffix, viewable in Synthesis Properties). Your third example above looks promising. You can get closer to the netlist by viewing schematics or the constraint editor. Can you add TIG to the reset in m1? (it's forward referential).
Related
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.
My VHDL testbench uses some features that are specific to VHDL'2008 but, depending on what exactly I'm testing or which software I'm using for the simulation, it cannot always be compiled in VHDL'2008.
To cope with that, I created 2 versions of this testbench :
The full version, compiled in VHDL'2008.
The light one, with all VHDL'2008 lines deleted, compiled in VHDL'93.
However, maintaining two nearly identical versions of this testbench is really an annoying thing to do, so I would like to merge them in some way.
I first thought I could use a generic and an "IF .. GENERATE" statement but this obviously doesn't allow me to '93-compile a file with '2008 features.
Is there a way to merge these 2 files and still compile the result with VHDL'93 ?
Option 1 -- Pragmas
If the code that uses VHDL 2008 doesn't replaces other pieces of the code (i.e., the code using VHDL 2008 does extra stuff), you can use pragmas such as
vhdl_93_component_u : foo_93 port map ( clk => clk, out => out);
-- rtl_synthesis off
vhdl_2008_component_u : foo_2008 port map ( clk => clk, out => out);
-- rtl_synthesis on
Also, check if your tool accepts enabling and disabling interpretation of pragmas and which pragmas it accepts. -- rtl_synthesis on/off is an example here.
Option 2 -- Different files
If you can split your code in 3 (testbench top, VHDL '93 code, VHDL 2008 code), you can compile only the file you need (assuming same package/architecture/entity names).
If you can't refactor your code to use something like this, I suggest you review the way you are implementing your testbench.
Is there a way/workaround to use statements in a UCF file conditionally, or, can UCF files be included into other UCF files conditionally?
The problem I'm facing is that I have a top module with a set of generics which conditionally instantiate or remove certain submodules from the top module via generate statements.
However, most of these submodules have timing constraints defined in the projects UCF file.
Somewhere during map or par the build process is aborted stating that an instance the UCF file is refering to does not exist (which is correct since the instance was never created due to the choice of generics in the top module).
Whats the best possible way to achieve some sort of "conditional constraint", which can avoid this problem? (beside the obvious preprocessor/script which fingers around in my UCF file)
PS: I'm using the Xilinx ISE 14.4 / Vivado 2012.4 command line tools.
This question has been asked several times:
http://forums.xilinx.com/t5/Design-Entry/include-and-ifdef-for-ucf-files/td-p/77822
http://forums.xilinx.com/t5/Design-Entry/Conditional-inclusion-of-ucf-files/td-p/195684
Short answer is no, not possible unfortunately.
Your best bet is to create 2 separate UCF files and either create a script to point to one or the other or to manually replace it each time you turn on/off your generic switch.
IF you are using Vivado, then you should know that UCF files are no longer supported under the Vivado synthesis. Unless you have to use XST, then you no longer limited to use the out dated UCF file format for your constraints.
Vivado is using XDC constraints, which are a sub set ot TCL, which means you can write a code with conditions to handle your constraints in any way you desire.
You can take a look at the UG 903 from Xilinx for moredetails on how to use the constraints in the latest version of their tools:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug903-vivado-using-constraints.pdf
Another potential solution would be to use Xilinx synthesis attributes.
This can be done to constrain timing of nets, just like the UCF can.
The difference is, attributes can be done inline in VHDL, near the signal declaration.
It's clunky, though.
The right solution likely depends on how many constraints you have.
I upvoted FarhadA's answer, but I wanted to emphasize the point that XDC files are TCL scripts and so they can include conditionals and for loops. So much better than UCF files.
Another advantage of the constraint processing in Vivado is that if it encounters a constraint that does not match the design, it issues a Critical Warning and continues.
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.
In order to ease the visual reading of simulation waves, I would like to assign some signals to "XXXX", but only at simulation time, and thus I want the logical synthesis tool (ISE in my case) to skip those instructions.
Two questions from here:
Is there an equivalent technique of a #ifdef SIMULATION_TIME, like in C ?
Would an assignment to "XXXX" have any influence on the logical synthesis (reset to 0 ? warnings ? nothing ?). If it has no impact at all, then my question is answered. If not, I still need to assign to "XXXX"...
Thanks.
(1) You're looking for
--pragma synthesis_off
-- your simulation-only code
--pragma synthesis_on
(2) You might get some warnings from ISE, especially when these signals drive logic. Just make sure, that the signals have a defined value before you use them. This method should work then, as well.
If you find yourself wanting to use ifdef for arbitrary code selection then you can use the VHDL keywords if generate.
label: if SOME_OPTION = SOME_VALUE generate
some VHDL here
end generate;
This is handy if you need to optionally include some code, however the synthesis on/off is more widely used if the selection is between simulation and synthesis.
One other trick to go with George's answer - if you want a boolean for in_synthesis say:
constant in_simulation : boolean := false
--pragma synthesis_off
or true
--pragma synthesis_on
;
constant in_synthesis : boolean := not in_simulation;
As others have mentioned, there is typically a way to turn off synthesis that is tool dependent (check the ISE docs).
When I need something more sophisticated, I perform pre-processing. Typically, I use makefiles and various *nix flavored text processing tools (sed, awk, perl, &c). This can be as simple or as complex as desired. What started as a way to uncomment different blocks of code for simulation vs. synthesis now extracts register documentation and auto-generates C header files for the SW team.
If you don't want to "roll you own", you can apply one of the many pre-existing implementations (C pre-processer, m4 macro language, &c) to your build process.