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.
Related
Does VHDL provide a simple mechanism for duplicating enumeration types to allow the creation of objects that can hold the same set of values but cannot be connected or assigned to one another?
The use case would be to have logic types that would represent signals that should not be connected except to a certain other set of signals - e.g. clocks of various frequencies or resets that should not be tied to each other or to a data bit. This way, the compiler can check for those sorts of connection errors and the type names in the code can carry meaning themselves, e.g. clk40mhz_t.
It seems as though one could just copy-paste define an enumeration similar to that for std_ulogic for any such type and define suitable conversion functions. Is there a handier way than that, though?
I’ve tried a straightforward declaration like
type clock_t is std_ulogic;
But since std_ulogic is not a range, this isn’t a valid type declaration.
So I also tried a few other ill-conceived and ill-fated constructions such as std_ulogic’range, range std_ulogic’range, range std_ulogic’left to std_ulogic’right, and (std_ulogic’range).
All were understandably met with compiler errors (compiling with Quartus Prime Pro 22.3).
Our simulator allows VHDL / Verilog mixed and our design uses an IP that written in VHDL (otherwise, our design is mostly in Systemverilog).
We are having problems as parameter overriding is not correctly working and we found the following statements from Simulator's documentation:
"By default, when a Verilog module is instantiated inside a VHDL design unit and default binding is done, VHDL generics are mapped to Verilog parameters using positional mapping."
It is saying that mappings of VHDL generics to Verilog parameters are done using positional mapping, not named mapping. The simulator offers a special option to change the binding rule to "named mapping" and that solved our problem.
My question is which standard specifies the binding rule when it comes to Verilog inside VHDL (or VHDL inside Verilog)?
Or, is this an arbitrary choice the simulator vendor made?
The unfortunate truth is there is no standard for interoperability between standards. Why this is the case may be highly opinionated. But I can say that if more people bring this issue up to their vendors, the more likely it may get addressed.
In VHDL some signal attributes (eg 'TRANSACTION) are implicit signals. Others (eg 'EVENT) are not. Why is this?
The returned VHDL object, its type and value is not restricted by the language. Wheras user-defined attributes are restricted to be constant values.
6.7 Attribute declarations
An attribute is a value, function, type, range, signal, or constant that may be associated with one or more named entities in a description. There are two categories of attributes: predefined attributes and user-defined attributes. Predefined attributes provide information about named entities in a description. Clause 16 contains the definition of all predefined attributes. Predefined attributes that are signals shall not be updated.
User-defined attributes are constants of arbitrary type. Such attributes are defined by an attribute declaration.
§ 6.7 on p. 92, IEEE Standard VHDL Language Reference Manual, IEEE Standard 1076-2008
So built-in attributes can map to almost everything. In case of 'transaction the return object is a signal of type bit.
The attribute or tick syntax is a nice compact thing in the VHDL language. It's used for several purposes.
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.
Is there any way of telling ISE to synthesize my VHDL/Verilog code into combinational circuits consisting only of look-up tables? I would like to avoid multiplexers, multipliers, and the like in the tech schematic... and wouldn't mind having an unoptimized (with many components than is optimal) version because of this preference.
Thanks SOCommunity!
There is a way to do that. Look at the XST user guide for switches that control the use of the primitives you want to avoid:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/xst_v6s6.pdf
or:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/xst.pdf
depending on your target architecture.
For example, to avoid DSP blocks use:
-use_dsp48 no
To avoid automatic packing into BRAMs use:
-auto_bram_packing no
This switch can also be useful:
-slice_utilization_ratio
as will others.
I have a convenient way to look at the available switches, along with some explanation of what they do, on my site:
https://www.boldport.com/flow/#new/options
(click 'Edit', and then 'More options...')
I hope this helps.
In Xilinx you can use the Language templates for this purpose. Select the device you are using and check the available type of LUT's and other components. You can individually instantiate these LUT in your design.
You may have to switch off the "optimization during synthesis" option in XST properties to make this work correctly.
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/ise_p_lt_using_language_templates.htm