I have a VHDL entity with a generic parameter list. The architecture to this entity calculates several constants, which are needed to create the intended functionality.
Is it possible to access one of these constants from outside?
Example 1:
Let's say there is a FIFO that decides based on DEPTH and OUTREG what the best implementation is (register based, SRL based or BlockRAM based). Depending on this the minimum delay through the FIFO can vary from 1 to 2 cycles.
Example 2:
Consider the same FIFO to be cross clock compatible. Now the min delay depends also on the choosen sync circuits and the frequency difference.
Example 3:
A division entity needs N cycles to calculate a div b. N depends on BITS, RADIX, OUTREG, IS_SIGNED, ...
Further let's say each entity has a MIN_DELAY constant of type NATURAL which is of interest for other instances.
E.g. the instantiating entity needs to know how long it must at least wait for a result.
I can think of 2 solutions, but I think neither is a nice one.
Solution 1:
I could store the algorithmn for the computation in a package so it's globally accessable. But this is against the encapsulation principle :). The outside world only needs to know the delay value not the algorithmn.
Solution 2:
I could use a valid bit. That's always a good solution in dynamic, adaptive or pipelined systems, but this bit can not be used at synthesis time for further choices or optimizations.
Possible solution 3:
VHDL has the ability to define new attributes, but can they be accessed?
Example entity: alu_div:
constant MIN_DELAY : NATURAL := BITS / log2(RADIX) + 2;
attribute DELAY : NATURAL;
attribute DELAY of alu_div : entity is MIN_DELAY;
Example top:
mydiv : entity work.alu_div
generic map (....)
port map (....);
blk : block
constant my : NATURAL := mydiv'delay;
begin
....
end block;
NEW: Possible solution 4:
I found this SE question, where Jim Lewis noted that hierarchical references should also work with constants.
alias MY_DELAY is <<constant mydiv.DELAY : NATURAL >>;
Get internal signals of vhdl design in ncvhdl (alternative to modelsim's signal spy)
This is a modification of Morten's first entity declaration, in which for the 'module' instantiating alu_div I expect there's a component declaration which provides the declaration for the name alu_div.
There is no attribute decorating that declaration so the instantiation found at label alu_div_0 has no attribute DELAY.
If you were to use direct entity instantiation it might work:
entity alu_div is
constant MIN_DELAY : NATURAL := 42;
attribute DELAY : NATURAL;
attribute DELAY of alu_div : entity is MIN_DELAY;
end entity;
architecture foo of alu_div is
begin
end architecture;
entity test is
end entity;
architecture foo of test is
begin
alu_div_0:
entity work.alu_div ;
MONITOR:
process
begin
wait for 1 ns;
report "alu_div'DELAY = " & natural'image(work.alu_div'DELAY);
wait;
end process;
end architecture;
Which gives:
ghdl -a alu_div.vhdl
ghdl -e test
ghdl -r test
alu_div.vhdl:25:9:#1ns:(report note): alu_div'DELAY = 42
>
The idea is that if you use a direct entity instantiation with a selected name (an expanded name) you're using the declaration in the library noted by the prefix (in this case WORK).
The following demonstrates accessing the value of alu_div'DELAY can be done at elaboration:
entity alu_div is
generic (pickone: natural := 1);
constant MIN_DELAY : NATURAL := 42;
constant TARG_DELAY: natural := MIN_DELAY + pickone;
attribute DELAY : NATURAL;
attribute DELAY of alu_div: entity is MIN_DELAY;
-- attribute DELAY of alu_div : entity is TARG_DELAY;
end entity;
architecture foo of alu_div is
begin
end architecture;
entity test is
end entity;
architecture fie of test is
constant fumble: natural := work.alu_div'DELAY;
component alu_div is
generic (pickone: natural := 1);
end component;
begin
alu_div_0:
alu_div
generic map(1);
MONITOR:
process
begin
report "constant fumble = " & natural'image(fumble);
report "alu_div'DELAY = " & natural'image(work.alu_div'DELAY);
wait;
end process;
end architecture;
And that works:
ghdl -a alu_div.vhdl
david_koontz#Macbook: ghdl -e test
david_koontz#Macbook: ghdl -r test
alu_div.vhdl:60:9:#0ms:(report note): constant fumble = 42
alu_div.vhdl:61:9:#0ms:(report note): alu_div'DELAY = 42
Also following Jonathan's comment that the question was attempting to loop information through the instantiated component supplied by generics I tried switching the entity attribute to depend on a generic (commenting out the one with MIN_DELAY, uncommenting the one with TARG_DELAY) and that results in a different error than Morten supplied:
ghdl -a alu_div.vhdl
alu_div.vhdl:36:13: attribute expression for entity must be locally static
ghdl: compilation error
And that error is singularly helpful and easy to find in the 2008 LRM and is quite specific:
7.2 Attribute specification (paragraph 8):
The expression specifies the value of this attribute for each of the named entities inheriting the attribute as a result of this attribute specification. The type of the expression in the attribute specification shall be the same as (or implicitly convertible to) the type mark in the corresponding attribute declaration. If the entity name list denotes an entity declaration, architecture body, configuration declaration, or an uninstantiated package that is declared as a design unit, then the expression is required to be locally static (see 9.4.1)....
This requirement was introduced in the '93 LRM (5.1 Attribute specification). And researching that we find there was a proposal for out-mode generics in the -1992 standardization effort (approved in -1993).
Also in the '87 Issue Report 40 (IR00040.txt) following the first ISAC rationale report of a discussion of the problem as relates to setting the attribute from within an architecture:
Such a capability would greatly (and negatively) affect at least some
implementations. A straightforward approach to the implementation of
specifications is to decorate the named entity with the information
contained in the specification. However, when the entity appears in
one design unit and the applicable specification appears in another,
many problems result. One cannot analyze the specification without
modifying the library unit containing the entity, which can lead to
potential circular chains of dependence. Moreover, multiple
architectures corresponding to a given entity interface cannot each
supply a different value to the attribute of some interface-resident
entity. Finally, there is no LRM requirement that, if one architecture
attributes some interface-resident entity, then all must, which seems
desirable.
You could note the undesired circular dependencies are also possible with an attribute dependent on a generic. Or similarly with out-mode generics the issue moves from circular dependencies in analysis order (locally static expressions in attribute declarations) to elaboration order (evaluating globally static expressions) which is likely quite a bit harder. out-mode generics show sporadic mention in available records, the last time on the vhdl-200x-mp (Modeling and Productivity) email reflector.
It's not likely the status of either of these will change without someone defining how to deal with late binding (linking loader time) order dependencies.
In the mean time as Brian says the accepted method is to use a package commonly shared, which uses locally static constant declarations (and are declaration order dependent). You could also manage the issue with configuration.
Good question. I have sometimes felt the need for "OUT mode generics" too, whose actual value is computed within the architecture, again to allow the higher levels in a hierarchy to know (and adjust to) the pipeline depth of a processing unit.
It might be worth writing a proposal to allow something of the sort in VHDL-201x and submit it to the standards group but meanwhile we have to live with what we have.
My normal solution is to use a package associated with the unit, holding both the initial constant (instead of a generic) and the dependent quantities. This limits the "encapsulation breakage" to those compilation units that use the package, making them at least readily identifiable.
Within the package the constants are deferred where possible, or parameterless (impure) functions, which amount to the same thing.
A possible approach I haven't explored is that an entity declaration, after the PORT list, also allows zero or more entity_delarative_items. If these may include function declarations, then we could potentially return such information that way.
EDIT : David points out an LRM rule (8.3) that prevents this approach with current VHDL versions : a limited relaxation of that rule might be an alternative to "OUT mode generics".
An entity declaration may also include begin and some passive constructs - such as asserts that a set of generics and port widths are consistent. That way you would have to input all the required values, but at least the build would fail reporting errors if e.g. width and depth were inconsistent.
Agree that it is sometimes very useful with information about implementation
details from the entity, even though it breaks the encapsulation principle, but
for white box verification it can be a great help.
Tried to use entity attribute based on entity like:
entity alu_div is
generic(
BITS : positive;
RADIX : positive);
port(
...);
constant MIN_DELAY : NATURAL := BITS / log2(RADIX) + 2;
attribute DELAY : NATURAL;
attribute DELAY of alu_div : entity is MIN_DELAY;
end entity;
But the module where the alu_div is instantiated is not able to access it
using e.g. alu_div_0'DELAY, since ModelSim gives error:
No attribute specification with designator "DELAY" decorates label "alu_div_0".
One method that is useful for white box verification, where the verification
depends on the implementation, is to make an output port with information from
the implementation, like:
entity alu_div is
...
port(
...
DELAY_O : out natural);
...
end entity;
architecture syn of alu_div is
begin
DELAY_O <= MIN_DELAY;
...
It won't be a true constant, since for simulation it will need a delta cycle
before getting the value, but it may be a sufficient solution in many cases.
Another approach I have used is to live with the restriction that all "generic" information flows into a module by specifying as another generic, the result I want from the derived parameter.
For example,
entity alu_div is
generic(
BITS : positive;
RADIX : positive;
DELAY : positive);
port(
...);
Within the architecture, an ACTUAL_DELAY constant is derived from the other generics (plus port bus-widths, etc) and compared with the given DELAY generic.
If the requested DELAY and ACTUAL_DELAY are identical, all is well.
If the requested DELAY exceeds ACTUAL_DELAY, the architecture can insert pipeline stages to meet the request. The overall design will function as intended, though it may consume more registers than strictly necessary.
Otherwise the requested delay cannot be met, and the architecture asserts with severity FAILURE.
Related
I have an assert in my VHDL code that validates generics passed through the entity of my component. The severity of the assert is set to FAILURE, because I want to quit the simulation if the generics are misused. When simulating with Active-HDL (really any version, but I've specifically used versions 12-14a), the assert is hit when the generics are misused and the simulation exits before doing anything else. When simulating with ModelSim DE (I've only tried 10.6c, 32-bit), however, the assert is not the first thing to be evaluated, and a different error appears for a signal assignment of different array lengths, related to the values of the generics (which is why the assert exists). Here is my MCVE:
example.vhd:
library ieee;
use ieee.std_logic_1164.all;
entity example is
generic
(
INPUT_LEN : integer := 4;
OUTPUT_LEN : integer := 5
);
port
(
my_input : in std_logic_vector(INPUT_LEN-1 downto 0);
my_output : out std_logic_vector(OUTPUT_LEN-1 downto 0)
);
end entity example;
architecture rtl of example is
begin
-- We want this evaluated first.
assert (INPUT_LEN = OUTPUT_LEN)
report "INPUT_LEN and OUTPUT_LEN must be equal!"
severity FAILURE;
-- This is actually what is evaluated first.
my_output <= my_input;
end architecture rtl;
As you can see, my_output and my_input are affected by the values of the generics, and I want the assert to happen first so that a helpful error message will be printed to the console, instead of the current Fatal: (vsim-3420) Array lengths do not match. Left is 32 (31 downto 0). Right is 8 (7 downto 0)..
I compile and simulate using the following two ModelSim commands:
vcom -work work example.vhd
vsim -c -lib work example
My question is, is there a directive for vsim that forces ModelSim to evaluate asserts first? Or more broadly, a command that will look for and evaluate asserts before doing anything else? It seems Active-HDL does it by default, but ModelSim doesn't... I've looked through the documentation for vsim and I've tried the -immedassert flag but that didn't change anything.
I'm also working with very old code that gets used in a lot of different places (and is obviously way more complex than my MCVE), so the best solution would not be to modify the source code.
Thanks for any help.
All concurrent statements are elaborated in process statements or process statements and block statements. The two concurrent statements, the signal assignment and assertion have no guaranteed execution order. Counting on implementation defined apparent ordering results in a non-portable design description.
The assertion can still be ordered. It's possible to get assertions during elaboration.
This can be demonstrated by adding (in this case) a function that returns a boolean as an initial value for an object that never happens to get used (and would be eliminated during synthesis):
library ieee;
use ieee.std_logic_1164.all;
entity example is
generic
(
INPUT_LEN : integer := 4;
OUTPUT_LEN : integer := 5
);
port
(
my_input : in std_logic_vector(INPUT_LEN-1 downto 0);
my_output : out std_logic_vector(OUTPUT_LEN-1 downto 0)
);
end entity example;
architecture rtl of example is
function is_it_safe return boolean is
begin
assert (INPUT_LEN = OUTPUT_LEN)
report "INPUT_LEN and OUTPUT_LEN must be equal!"
severity FAILURE;
return TRUE;
end function;
constant safe: boolean := is_it_safe;
begin
-- We want this evaluated first
assert (INPUT_LEN = OUTPUT_LEN)
report " ORIGINAL INPUT_LEN and OUTPUT_LEN must be equal!"
severity FAILURE;
-- This is actually what is evaluated first.
my_output <= my_input;
end architecture rtl;
The added default values for the generics allow the code to analyzed, elaborated and simulated stand alone (as a Minimal, Complete and Verifiable example).
The report message in the original assertion has been changed for easy identification in case any implementation doesn't include line numbers.
Because the two generics have different default values it's is guaranteed to cause an assertion:
ghdl -a example.vhdl
ghdl -e example
ghdl -r example
example.vhdl:20:9:#0ms:(assertion failure): INPUT_LEN and OUTPUT_LEN must be equal!
./example:error: assertion failed
./example:error: error during elaboration
Line 20 is in the function is_it_safe.
The ordering will hold for Modelsim because objects are elaborated before simulation initialization (where one error or the other occurs now). See IEEE Std 1076-2008 14.4 Elaboration of a declaration, 14.4.2.5 Object declarations and 14.7 Execution of a model, 14.7.5.2 Initialization.
The idea here is to establish an ordered single execution of an assertion that was originally a concurrent statement (which is elaborated into a process with no sensitivity list and a final wait statement with no clauses, See 11.5 Concurrent assertion statements).
Note no answer so far answers the narrow question on how to affect process execution order in Modelsim.
It should not be possible to order concurrent statement execution. The order of the list of all processes executed until they suspend at the beginning of simulation (14.7.5.2) would be implementation defined and non-portable. That's already been demonstrated by the Original Poster.
Moving the assertion or providing a new copy in a function used during elaboration can guaranteed the assertion statement is executed before any assignment statement during initialization.
Also note the idea of an assertion testing the equality of the values of two constants of the same type could be viewed as an anti-pattern somewhat as JHBonarius commented. A fix adopted from programming which has little to do with hardware description and only serves to produce a particular message in the face of a lack of standardized error messages.
VHDL will already catch the error in the original code albeit requiring VHDL or tool implementation familiarity.
With the assertion in a function providing an object value the concurrent assertion statement can be eliminated.
VHDL is a strongly typed language. I am not sure about the construct of Modelsim that let you run the assertions first.
All you can try is type cast the my_output <= my_input as my_output <= std_logic_vector(my_input) this will let Modelsim simulate your design but as soon as you try to RUN your design, it will throw an Error.
Without the type-casting, it won't let you even simulate your design.
You can realize sequential processing by putting it in a process. Example:
library ieee;
use ieee.std_logic_1164.all;
entity example is
generic (
INPUT_LEN : integer := 5;
OUTPUT_LEN : integer := 6);
port (
my_input : in std_logic_vector(INPUT_LEN-1 downto 0);
my_output : out std_logic_vector(OUTPUT_LEN-1 downto 0));
end entity;
architecture rtl of example is
begin
assign_my_output: process(my_input) begin
assert (INPUT_LEN = OUTPUT_LEN)
report "INPUT_LEN and OUTPUT_LEN must be equal!"
severity FAILURE;
my_output <= my_input;
end process;
end architecture rtl;
vcom -work work example.vhd
vsim work.example
run 1 ns
# ** Failure: INPUT_LEN and OUTPUT_LEN must be equal!
I am trying convert two std_logic bits to an integer as follows
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
ENTITY TEST IS
PORT (sw1, sw0 : IN std_logic;
x : OUT integer RANGE 3 DOWNTO 0);
END ENTITY TEST;
ARCHITECTURE dflow OF TEST IS
SIGNAL mes_sel : integer RANGE 3 DOWNTO 0;
BEGIN
mes_sel <= to_integer(unsigned(std_logic_vector(SW1 & SW0)));
x <= mes_sel;
END ARCHITECTURE dflow;
but the compiler does not like the mes_sel assignment. I get the following compiler error message:
Error (10327): VHDL error at Q4.vhd(92): can't determine definition of operator ""&"" -- found 4 possible definitions
Can I not concatenate 2 bit of std_logic to a vector and then convert? Or is it something else?
regards
D
The error message tells you roughly what's wrong, and it's not a problem with the assignment.
GHDL gives a better diagnosis:
ghdl -a test.vhd
test.vhd:13:57: can't resolve overload for operator "&"
test.vhd:13:57: possible interpretations are:
../../src/ieee/numeric_std.v93:66:18: array type "signed"
../../src/ieee/numeric_std.v93:65:20: array type "unsigned"
../../src/ieee/std_logic_1164.v93:69:30: array type "std_logic_vector"
../../src/ieee/std_logic_1164.v93:54:31: array type "std_ulogic_vector"
ghdl: compilation error
VHDL allows overloaded operators, distinguishable by the types of their arguments (in this case, std_logic) and their return types, (in this case ... well... what?)
There are apparently 4 types which have a std_logic_vector() type conversion function declared on them, as well as a & operator taking two std_logic arguments; and ghdl (unlike whatever tool you're using) helpfully lists them.
In such cases, VHDL (unlike some other languages) insists that you pick one, rather than arbitrarily making a hidden (and possibly wrong) choice for you.
You can do this with a type mark. As you actually want an unsigned, the obvious choice is unsigned'() (note the "'" symbol, also used for attributes).
mes_sel <= to_integer(unsigned'(SW1 & SW0));
Note that if VHDL allowed anything simpler, like to_integer(SW1 & SW0) it would be positively dangerous as there is nothing to distinguish between signed and unsigned conversions, making the conversion at least non-obvious, and quite possibly wrong.
I want to map the lower bit (bit0) of a 32 bit output port to a signal and leave the upper bits unconnected (OPEN). Is there a way to treat this mapping as an aggregate?
I've tried the following to no avail:
port map (
some_output => ( 0 => sig_1, others => OPEN)
);
The below is not a valid answer, since it does not adhere to the VHDL standard. This "answer" is however kept here, and not deleted, since it shows what construction to avoid for tool compliance, since some tools apparently accept this non-standard compliant VHDL code.
Example of port mapping without association of all scalar subelement, which is accepted by Altera Quartus II and Mentor ModelSim in some cases, but is also likely to result in warning or error:
port map(
some_output(0) => sig_1,
-- some_output others are simply not included in port mapping
So, as David Koontzs point out in the comment, the VHDL standard (IEEE Std 1076-2008) section "6.5.7 Association lists" describes:
... every scalar subelement of the explicitly declared interface object shall be associated exactly once with an actual (or subelement thereof) in the same association list, and all such associations shall appear in a contiguous sequence within that association list. Each association element that associates a slice or subelement (or slice thereof) of an interface object shall identify the formal with a locally static name.
So it is not valid to only associate some of the scalar subelements, since the standard says "every scalar subelement", and open can't be used for the remaining scalar subelements, since the standard says "Each association element that associates a slice ... of an interface object shall identify the formal with a locally static name.".
Another solution is this:
signal my_vector : STD_LOGIC_VECTOR(3 downto 0);
signal my_vector_float : STD_LOGIC_VECTOR(3 downto 0);
port map (
[...]
some_output(3 downto 0) => my_vector,
some_output(7 downto 4) => my_vector_float,
[...]
);
You can now setup some report filter rules to silence all warning concerning *_float signals.
my problem is that I have an int_array generic in a VHDL entity and I want to set it from my SV tb. Which is the correct SV data type to do it? I tried several possibilities but no one of them was correct.
Thanks in advance.
It's not possible to say exactly. Because the interface between VHDL and SystemVerilog isn't specified in any way, it's up to the simulator vendors to implement it in whatever way they see fit. You'll have to ask your EDA vendor if what you want is possible and if so, which data type you need to use.
Since you didn't provide any code, I'll just have to speculate that you had to define your array type before using it as a generic (as otherwise it doesn't compile):
package my_types_pkg is
type my_array_t is array (0 to 2) of integer range 0 to 255;
end package my_types_pkg;
This is probably how your DUT looks like:
entity dut is
generic (
int_array : my_array_t
);
end dut;
architecture dummy of dut is
begin
end dummy;
Because we've had to define a new type there, Questa requires us to import the type definition into the SystemVerilog world. This is where it gets proprietary. The way Mentor Graphics chose to do this is by compiling the VHDL package with the -mixedsvvh switch:
vcom -mixedsvvh dut.vhd
It's essential that the type is defined inside a VHDL package otherwise it won't get exported. Inside your SystemVerilog file you can just define a localparam of the my_array_t type and use that for your instantiation:
module top;
localparam my_types_pkg::my_array_t my_array = '{ 1, 2, 3 };
dut #(my_array) dut_inst();
endmodule // top
In the code above my_types_pkg is the package defined in VHDL, which was exported to SV with the -mixedsvvh switch.
Now comes the sad part. This doesn't work for me. Even though the types match, vsim still complains that the generic isn't valid. This answer should help you get started, though (what to search for in the docs, for example). Also try taking this case to Mentor Graphics support.
I am preparing for an exam by going through some old ones. One of the questions is:
Write the synthesizable behavioral VHDL code that implements the synchronous FSM in fig...
The FSM has one input, called request, that is of enumeration type with values (r1, r2, r3)...
That makes me want to write this code:
entity fsm is
port ( clk : in std_logic;
request : in my_enum_type
);
end fsm;
And somewhere have a:
type my_enum_type is (r1, r2, r3);
somewhere (I have tried right befor the port declaration and right after the architecture declaration).
But I can't seem to get that to work.
Can I have custom types as inputs or outputs like that?
Yes you can, and I regard it as best practice - it means least work, best understanding, easiest maintenance, and cleanest design.
The trick is to declare the types common to your whole design in a package (I usually call it "Common" :-) and add use work.Common.all before the entity declaration AND in every customer of that entity. More specialised components can have appropriate names, of course!
For example:
package Common is -- untested...
type my_enum_type is (r1, r2, r3);
-- (optional) useful tools
function to_slv (e : my_enum_type) return std_logic_vector;
function to_enum (s : std_logic_vector(my_enum'length downto 0))
return my_enum_type;
end Common;
package body Common is
-- subprogram bodies here
end Common;
Now when you add a value to the enumeration, you ONLY modify "Common" and rebuild the design, while those who follow conventional guidelines are still trying to identify every port and signal where they have to increase the range of their "std_logic_vector" by 1.
Works really well for bus interfaces too, where a record in each direction hides all the individual bus and handshaking signals.
You WILL have to fight brain-dead tools like Xilinx "automatic testbench generator" which will helpfully translate ALL your port types - integer or boolean as well as custom - into std_logic(_vector) and then fail to compile. Just translate them back again.
You can still make a case that at the very top level, all the external FPGA pins should still be std_logic based. And if you ever need to simulate a post-synthesis version of your design, then you will either need to live with std_logic_vector ports, or add a simple wrapper to convert from one form to the other.