Is there a Verilog equivalent of the following statement in VHDL? I have some generic ports that require time values
constant TIME_C : time := 10 ms;
I tried this as a guess, but it failed syntax.
localparam TIME_C = 10 ms;
'ms' doesn't appear to be a reserved keyword in Verilog, but my IDE's editor highlights it blue, so I'm thinking maybe there is a way...
You can do this:
`timescale 1ms/1ms
module foo();
localparam TIME_C = 10;
...
endmodule
In Verilog, it is important to understand that variables or constants representing times are simply numerical values without any context. The timescale of the current module is what determines how the value is interpreted. In the example code above, #TIME_C will create a delay of 10ms because TIME_C equals 10 and the timescale is 1ms.
If you have to feed a time value to a port of a module, make sure you know what the timescale of the module is (if specified).
FYI, SystemVerilog added a few features related to specifying times and timescales.
Related
I am working in a TOP file of a project in VHDL. I have a problem-question concerning the port mapping.
Below, is a part of the code that I am trying to implement and afterwards the description of the context.
generate_microfib:
for i in 0 to 5 generate
fib: microfib
Port Map (
InL => SignalNumber(num(i)*2 + i), --Input Left
OutR => SignalNumber(num(i)*2 + i+1) --Output Right
);
end generate generate_microfib;
The code above creates multiple components of microfib. The microfib, has an input and an output port. What I want to do is connect the left input of the current created component with the right output of the previous created one.
My initial thought was to do it inside the port mapping, but VHDL doesn't give many options for calculations in the for..generate statement. So, I decided to do it in two steps. Meaning that, I first create the desired components and afterwards do the connections (by setting the desired signals equal).
So, my question is: Is it possible to do the connections in a function for example, by setting:
SignalNumber(i)=SignalNumber(i-1)?
I know that the '<=' operator is accepted and not the '=' but I want to show you that my goal is to make those two signals equal and not assign the value of the one to the other.
When I've done things like this, I've used an array-type signal to act as an intermediate placeholder. Then, within the generate loop, you can connect the ports to the indexed locations on the array signal.
So you could try something like this, using std_ulogic as an example port type:
architecture rtl of entity is:
constant N_DEVICES : integer := 5;
signal port_connector : std_ulogic vector(N_DEVICES downto 0);
begin
-- Concurrent statements
generate_microfib : for i in N_DEVICES-1 downto 0 generate
fib : microfib
port map (
InL => port_connector(i+1)
OutR => port_connector(i)
)
end generate generate_microfib;
-- Other stuff
end architecture rtl;
Then, port_connector(N_DEVICES) acts as the input to the chain, and port_connector(0) acts as the output from the chain.
This isn't a function, but it is (relatively) clean and avoids too much of a headache with the generate statement. Functions in VHDL, though, are meant to produce calculated values, not circuit connections, so I would recommend against trying for that anyhow.
I have a VHDL function that returns a std_logic_vector representation of a record and I want the length of that std_logic_vector. I am able to use the length attribute directly on the function. Why does this produce a warning in ModelSim? Am I inviting subtle problems? Googling the warning text did not turn up anything I understood to be helpful.
my_function_returns_slv(my_record)'length;
** Warning: ../src/my.vhd(line#): (vcom-1515) Prefix of predefined attribute "length" is function
call "my_function_returns_slv"
I've written the function to assemble the output by concatenating std_logic_vector representations of the record elements. The length of the record is fixed at compile time, but I do not want to hard code the length. I need the length to create signals for using the function output. So I can't just call 'length on the output of the function (ex: call 'length on a signal holding the function output) because it is not possible to declare an unconstrained signal to hold the output. I could write a similar function to calculate the length of the std_logic_vector, but that would add some significant code, especially for the number of records I have. Should I accept the ModelSim warning and carry on? Should I deal with the extra code from writing functions to assemble the bit width of my records? Is there a better solution altogether?
Helpful record pack/unpack subprograms I am making use of:
http://www.eda-twiki.org/twiki/pub/P1076/RecordReflectionToSlv/standard_functions.vhd
Thanks!
Using the 'length attribute directly on a function can be seen as just taking another part of the function result than the primary output, thus from a conceptual point of view there should be nothing wrong with that.
So I would accept the ModelSim warning, but also take it as an indication that the tool is worried about the construction, so I would check that my other tools, e.g. synthesis tools and code checkers, accept this use of an attribute directly on a function call.
Appears that you can avoid the ModelSim warning by making a function like:
function len(slv : std_logic_vector) return natural is
begin
return slv'length;
end function;
and then this won't result in a ModelSim warning:
signal MY_LEN : natural := len(slv_not(CONST));
So being able to avoid the warning using such encapsulation confirms that the warning is a little flaky in the first place.
"I need the length to create signals for using the function output. So I can't just call 'length on the output of the function (ex: call 'length on a signal holding the function output) because it is not possible to declare an unconstrained signal to hold the output."
A fun work around for sizing signals is:
constant MY_CONST : std_logic_vector := my_function_returns_slv(my_record) ;
signal MySig : std_logic_vector(MY_CONST'range) := MY_CONST ;
We have an LCS for VHDL-2017 that allows signals to be unconstrained and get their constraints from the initialization.
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.
I'm searching the verilog equivalent of the VHDL attribute my_signal'last_eventbut in Verilog. I have googled it without success. Does someone know how to do it ?
The 'last_event attribute is used to know the time since the signal last event.
For example, if at time 15us, signal toto toogles from 0 to 1.
Then at time 20us, toto'last_event returns 5us.
Have you tried looking into some of the verilog system tasks? Specifically the following:
$time; // Return current simulation time in 64-bit integer
$monitor("format", v1, v2, ...); // Invoke only once, and execute (
// automatically when any of the
// variables change value.
You can look at the 'nested-if-else-if' example here http://www.asic-world.com/verilog/vbehave2.html for an example of a test bench that uses these.
You could create a time variable and update it whenever the signal changes
time my_signal_last_change;
always #(my_signal) begin
my_signal_last_change = $time;
end
This works in SystemVerilog; not sure if it would in verilog (you can try changing time to reg[63:0] in case it doesn't)
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.