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.
Related
I have been writing VHDL for a short time now, so I feel this is a good time to start making sure my coding is in a good style. I have had trouble finding any good style guides or quick ref. sheets for this. I am thinking of something like the Barr group embedded C standard, but for VHDL.
Does something like this exist?
The following style is recommended by CERN BE-CO-HT
i_ Input signal
o_ Output signal
s_ signal
c_ Constant
g_ Generic
t_ User-Defined Type
There are many other recommendations. You can have a look at coding style followed in CERN BE-CO-HT https://ohwr.org/project/vhdl-style/blob/master/doc/vhdl-coding-style.adoc
In my VHDL design there is a 16-bits std_logic_vector. The bit in position 15 is currently not used and the synthesizer (SynplifyPro) throws a warning saying that bit is not used and will be pruned:
#W:CL190 : DATAGEN.vhd(93) | Optimizing register bit MYREG(15) to a constant 0. To keep the instance, apply constraint syn_preserve=1 on the instance.
#W:CL260 : DATAGEN.vhd(93) | Pruning register bit 15 of MYREG(15 downto 0). If this is not the intended behavior, drive the input with valid values, or an input from the top level.
As suggested by the synthesizer, I have added the required attribute and I was able to get rid of these warnings. To add these attributes, I had to include the Synplify library:
library synplify;
at the top of the file, and then define the attribute as follows:
ATTRIBUTE SYN_PRESERVE : BOOLEAN;
ATTRIBUTE SYN_PRESERVE OF MYREG : SIGNAL IS TRUE;
If I try to run ModelSim on Post-Synthesis everything is fine. However, when I try to run ModelSim on Pre-synthesis, it gives me the error:
** Error: .../DATAGEN.vhd(20): (vcom-1598) Library "synplify" not found.
I believe that the problem is because Pre-Synthesis simulation is not supposed to use this library. In fact, if I remove this everything works. The reason for which I would like to keep using the Pre-Synthesis simulation is because it is much faster than Post-Synthesis. However, this issue forces me to keep commenting out this lib for Pre-synthesis and putting it back for Post-synthesis?
Is it possible to use something like conditional include?
Note: I prefer to keep the unused bits, therefore adding the attribute for avoid pruning works fine for me.
Is it possible to use something like conditional include?
The upcoming VHDL-2019 standard supports conditional compilation and some simulators, for example RivieraPro, have started to support that. With such support you can do things like
`if INCLUDE_SYNPLIFY = "true" then
library synplify;
`end if
I don't think ModelSim has that yet but what you can do is to just define a synplify library with vlib and include that when calling vsim. If you are using VUnit you can simply add the following to your run script
prj.add_library("synplify")
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.
In verilog and VHDL RTL commands to tools can be given as pragma directives as pseudo comments. I want to avoid using any of these pragma directives in my real comments, so what I'd like to have is a comprehensive list of pragma directive triggers. Ones I know about are:
-- pragma
// synthesis
-- synopsys
You can find a comprehensive list here:
http://www.sigasi.com/content/list-known-vhdl-metacomment-pragmas
As long as you don't have a comment starting with the trigger, i.e., -- <trigger> ..., you should be safe.
For example, when using Altera Quartus, avoid comments such as
-- altera code below,
while
-- The following is for altera.
would be fine.
You can probably find several lists like this, but I doubt any of them are complete. (The one zennehoy posted is missing -- psl, among others.) Even if there is a complete list somewhere you never know what pragmas vendors will add in the future, thus you can never be sure.
If you want your code to be as portable as possible you should probably avoid starting comments with common vendor/tool names like zennehoy suggests (such as synopsys, altera, xilinx, lattice, modelsim, etc.) Other than that I'd say you just have to take your chances.