What VHDL datatype should I use for a memory address? - vhdl

I'm developing a description of a BIST engine, and I've been asked by my manager to transition from Verilog to VHDL. I'm very rusty with VHDL, and I can't figure out the right datatype to give to the address register in my code. Most of the time, the address is used to index into arrays.
data : std_logic_vector (2**W-1 downto 0);
...
output = data(addr);
Sometimes though, I need to perform bitwise operations (for example, this code that finds the least-significant 1 in the address):
least_one(0) <= addr(0);
PRIORITY_ENCODER : for i in 1 to (W-1) generate
least_one(i) <= addr(i) and not or_reduce(addr(i-1 downto 0));
end generate PRIORITY_ENCODER;
least_one(W) <= not or_reduce(addr);
Finally, I also rely on the address wrapping around without problem when it overflows (i.e. 1111+1 = 0, and 0-1 = 1111).
So, given all these different uses, what datatype or subtype do I give to the address? When I use integer and the related types, I get errors when I perform the bitwise operations:
ncvhdl_p: *E,APNPFX (filename,17|20): can not make sense of P(...)
When I use std_logic_vector or similiar, I get errors trying to use the address as an array index:
ncvhdl_p: *E,INTYMM (filename,52|17): array index type mismatch [6.4]
I seem to be in a no-win situation here. What data type do I use? Please note, the solution must be synthesizable. Thanks

You want bitwise access and wrapping behaviour:
make addr fundamentally an unsigned vector.
Then you need access to it as an integer:
If you need it as an integer on just one line, use the to_integer call on just that line.
If you need it as an integer in more than one place, create another signal to "shadow" it and put a continuous assignment in the architecture
Like this:
signal addr_int:natural;
....
addr_int <= to_integer(addr);

In this case I would use unsigned type.
This will work very similar to how you are used to std_logic_vector operating in terms of generic bit access, but you can also do arithmetic operations on the address and easily convert to/from integer type, if necessary. Plus it doesn't dirty the sense of std_logic_vector with the "dreaded" std_logic_unsigned package.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
...
architecture myarch of myent is
signal address : unsigned(numbits-1 downto 0);
...
begin
-- as an example
addr_counter : process(sysclk, reset)
begin
if reset = '1' then
address <= (others => '0');
elsif rising_edge(sysclk) then
address <= address + 1;
end if;
end process addr_counter;
...

Related

write on invalid address to RAM in VHDL, Verilog, sim behaviour

Lets have a BRAM or any other memory under Verilog or VHDL.
For example this:
module raminfr (clk, we, a, di, do);
input clk;
input we;
input [4:0] a;
input [3:0] di;
output [3:0] do;
reg [3:0] ram [31:0];
always #(posedge clk) begin
if (we)
ram[a] <= di;
end
assign do = ram[a];
endmodule
Now lets assume that we have already write valid data to "ram".
Does simulators invavalidate all items in "ram" if address "a" will have invalid value (4'bxxxx) ("we"=1 and clk will have posedge)?
Or it lets values in ram as they were?
For Verilog
The IEEE Std 1800-2009 SystemVerilog standard subsumed both the IEEE Std 1364-2005 Verilog standard and the IEEE Std 1800-2005 SystemVerilog standard. The IEEE Std 1800-2012 SystemVerilog standard supplanted the -2009 version.
See IEEE Std 1800-2012 7.4.6 Indexing and slicing of array:
If an index expression is out of bounds or if any bit in the index expression is x or z, then the index shall be invalid. Reading from an unpacked array of any kind with an invalid index shall return the value specified in Table 7-1. Writing to an array with an invalid index shall perform no operation, with the exceptions of writing to element [$+1] of a queue (described in 7.10.1) and creating a new element of an associative array (described in 7.8.6). Implementations may issue a warning if an invalid index occurs for a read or write operation on an array.
For VHDL
An equivalent VHDL design description might be:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity raminfr is
port (
clk: in std_logic;
we: in std_logic;
a: in std_logic_vector(4 downto 0);
di: in std_logic_vector(3 downto 0);
do: out std_logic_vector(3 downto 0)
);
end entity;
architecture behave of raminfr is
type ram_type is array (0 to 15) of std_logic_vector (3 downto 0);
signal ram: ram_type;
begin
process (clk)
begin
if rising_edge(clk) then
if we = '1' then
ram(to_integer(unsigned(a))) <= di;
end if;
end if;
end process;
do <= ram(to_integer(unsigned(a)));
end architecture;
Where the numeric_std package to_integer function is used to convert the array value of a to an integer index. (VHDL is a bit more flexible here, array indexes can either be integer types or enumerated types, together referred to as discrete types).
Reading the source for to_integer we see it will convert an input unsigned array value containing an 'X' to all 'X's and the 'LEFT value of that being 'X' will return a natural integer subtype value of 0 and optionally report that:
if (XARG(XARG'left) = 'X') then
assert NO_WARNING
report "NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0"
severity warning;
return 0;
end if;
These warnings can be disabled implementation wide by changing the value of NO_WARNING which is locally static. Using to_integer (or with Synopsys package std_logic_arith and function conv_integer) the index will be 0.
Additionally VHDL implementations have the ability to stop simulation on severity warning reports.
While you could handle the result of an assignment with an index provided as an array value differently in (as in 2, 4, 8, 16 or 32 invalidated memory locations depending on the number of 'X' element values of a here), you've already compromised the integrity of your design model state and some corrective should be taken before counting on the simulation results for either a SystemVerilog or VHDL design model.
The overhead of complex fiddling doesn't seem worthwhile in general. These warnings are of a class of warnings that should be reviewed before synthesis.
These warning can occur before array values are reset when their default initial values are metavalues. You can prevent that in most FPGA designs by initializing a and any predecessors so a contains a binary representing value or simply ignoring reports at time 0 before a reset takes affect.
You can also prevent the write to address 0 by initializing we and any predecessor(s) to '0'.
Simulator will not invalidate anything. Instead the write will be ignored.
For reads in such a situation, it will return 'x' though.

Why couldn't I convert this integer into a logic_vector?

I have been trying to convert this Signal of type integer into an std_logic vector and assign the converted value into another signal that has the same width as a VHDL integer
signal temp : std_LOGIC_VECTOR(31 downto 0) := (others => '0');
signal FrameCumulative : integer :=0;
temp <= to_stdlogicvector(to_unsigned(FrameCumulative));
However I get this error:
Error (10346): VHDL error at vga.vhd(107): formal port or parameter
"SIZE" must have actual or default value
I am using use IEEE.NUMERIC_STD.ALL; and use IEEE.STD_LOGIC_1164.ALL;
First I made the mistake of not checking the integer size within VHDL and tried to assign an integer into a 14-bit vector but after I gave it some thought I relised my mistake.
Now according to many on-line resources, what I am doing should work but my synthesiser complains about it.
If you do know the cause for this would you mind ellaborating on your answer rather than just posting the correct code, Thanks!
The function to_unsigned must be provided with a parameter specifying the width of the vector that you want it to produce. The function to_stdlogicvector is also not the correct thing to be using. Your line should look like this:
temp <= std_logic_vector(to_unsigned(FrameCumulative, temp'length));
The function to_unsigned is a conversion function, it must be provided with the target width. Here, as suggested by #BrianDrummond, the width is specified by taking the length attribute from the target vector itself (temp). The std_logic_vector is a type cast, where the unsigned value is simply interpreted directly as an std_logic_vector.

Address of array provided as std_logic_vector

I'm trying to construct a ROM, which has as declaration a : in std_logic_vector(5 downto 0) for the access address. My problem its that I don't know how to access the ROM array with a std_logic_vector, Should I use a cast to integer or what else can I do?
My code:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
--------------------------------------------------------------------------------
entity imem is
GENERIC(CONSTANT N : INTEGER := 32);
port (a : in std_logic_vector(5 downto 0);
result : out std_logic_vector(N-1 downto 0));
end imem;
architecture behavior of imem is
signal addres : integer;
type memory is array (0 to 64) of std_logic_vector(N-1 downto 0) ;
constant myrom : memory := (
2 => x"11111111" , --255
3 => x"11010101" ,
4 => x"01101000" ,
6 => x"10011011" ,
8 => x"01101101" ,
9 => x"00110111" ,
others => x"00000000" ) ;
begin
addres <= signed(a);
result <= memory(addres);
end behavior;
With this code as shown I get the following error:
imem.vhd:25:21: can't match type conversion with type integer
imem.vhd:25:21: (location of type conversion)
imem.vhd:26:21: conversion not allowed between not closely related types
imem.vhd:26:21: can't match type conversion with type array type "std_logic_vector"
imem.vhd:26:21: (location of type conversion)
ghdl: compilation error
Assuming that a is an unsigned address value, then you must first cast it to unsigned, and then to integer. Note that the result should access myrom and not memory type. The code can then be:
addres <= to_integer(unsigned(a));
result <= myrom(addres);
And you can even skip the intermediate addres signal and do:
result <= myrom(to_integer(unsigned(a)));
The memory type is also one longer than required, since the 6-bit a input can only cover 0 .. 63, and not 0 .. 64. A better way to declare the memory type would be through use the the 'length attribute for a, like:
type memory is array (0 to 2 ** a'length - 1) of std_logic_vector(N-1 downto 0);
ghdl semantics are by default strict -1993 which has an impact on Morten's answer's changes
For:
type memory is array (0 to 2 ** a'length - 1) of
std_logic_vector(N-1 downto 0);
we get:
ghdl -a imem.vhdl
imem.vhdl:15:29:warning: universal integer bound must be numeric literal or attribute
Tristan Gingold the author of ghdl authored an Issue Report leading to a Language Change Specification in 2006, which gave explicit permission to then current (-2002) implementations to treat a range with an expression as one bound as convertible to an integer range when the other bound is a universal integer (a literal). The LCS didn't give permission to do the conversion in implementations conforming to earlier versions of the standard. Tristan's ghdl is strictly by the book here and by default is -1993 compliant and generates an error.
There are two ways to deal with the error. Either use the command line option to ghdl during analysis to specify a version of the standard where the range can be converted to type integer or provide the range directly.
From ghdl --help-options we see:
--std=87/93/00/02/08 select vhdl 87/93/00/02/08 standard
Where this command line flag can be passed as in ghdl -a --std=02 imem.vhdl.
Also the range type can be declared directly as in:
type memory is array (natural range 0 to 2 ** a'length - 1) of
std_logic_vector(N-1 downto 0);
Both methods of analyzing type memory work.
And the moral of all this is that VHDL is a tightly typed language.
Notes
-2008 compliance is not fully implemented in current versions of ghdl.)
There's historical support for interpreting the standard to support the conversion anyway. The LCS overcomes ambiguity.
See IEEE Std 1076-1993 3.2.1.1 Index constraints and discrete ranges para 2 and IEEE Std-1076-2008 5.3.2.2 Index constraints and discrete ranges para 2.
Tristan has since changed the --std= options eliminating -2000 compliance as well as the default standard to 93c which introduces a set of standard relaxations to more closely match industry practices of VHDL tool vendors. The user of a more recent version of ghdl can use --std=93 for strict standard compliance. The issue originally hinged on the VASG (VHDL Analysis and Standardization Group) sponsored by DAC not being allowed to issued Interpretations of standards after -1987. It's safe to say there is no single implementation of any VHDL standard that completely adheres to a particular revision.

How can I extract elements from a record using an integer reference in VHDL?

Firstly here is what I'm aiming to do, using made-up VHDL syntax...
type type_johns_record is
first_element : std_logic;
second_element: std_logic_vector(3 downto 0);
third_element : boolean;
end record;
....
....
for ii in johns_record'range loop
if johns_record.type_johns_record'val(ii) = .... then
exit;
end if;
end loop;
Hopefully you can see that I'm trying to reference the elements of a record using similar syntax to that which can be used to reference an enumerated type. This however (of course) does not work. Is there a similar syntax that will work? My solution at the moment is to use a record_info field and work using std_logic_vectors as shown below....
type type_johns_record is record
first_element : std_logic;
second_element : std_logic_vector(3 downto 0);
third_element : boolean;
record_info : type_integer_array(2 downto 0);
end record;
function type_johns_record2slv(d : type_johns_record) return std_logic_vector is
begin
return (d.first_element & d.second_element & bool2sl(d.third_element));
end function;
constant johns_record_zero : type_johns_record := (first_element => '0',
second_element => "0000",
third_element => false,
record_info => (1, 4, 1));
-- can be used with any type for which a record_info is known
function get_record_element(input : std_logic_vector; element_number : integer; record_info : type_integer_array) return std_logic_vector is
variable r : type_slv32_array(record_info'length-1 downto 0);
variable pos : integer := 0;
begin
for ii in record_info'range loop
r(ii)(record_info(ii)-1 downto 0) := input(pos+record_info(ii)-1 downto pos);
end loop;
return r(element_number)(record_info(element_number)-1 downto 0);
end function;
I can then use these functions (which are in a package) as follows...
for ii in johns_record.record_info'range loop
if get_record_element(type_johns_record2slv(johns_record), ii, johns_record.record_info) = conv_std_logic_vector(4, johns_record.record_info(ii)) then
exit;
end if;
end loop;
This really sucks and specifying the record_info is error prone and only marginally less time consuming that writing out individual element comparisons line by line. Please offer a better solution!!!
In the IEEE VHDL Standards group, there are actually two proposals relating to this:
http://www.eda.org/twiki/bin/view.cgi/P1076/RecordMemberAttribute
and
http://www.eda.org/twiki/bin/view.cgi/P1076/RecordIntrospection
This does not mean relax, someone else will address the issue. Instead, we need you to comment on it and/or propose additional use models (to help with justification). All of our work is done by volunteers - just like you - no memberships required for basic participation. Much of our work is done on the TWIKI and email reflector and all with VHDL background are welcome to participate. Drop me an email, I will get you setup - see my Stack Exchange profile for details.
To participate, start here: http://www.eda.org/twiki/bin/view.cgi/P1076/
Current proposals:
http://www.eda.org/twiki/bin/view.cgi/P1076/CollectedRequirements
Meeting information:
http://www.eda.org/twiki/bin/view.cgi/P1076/MeetingMinutes
If you'd like to shorten your implementation code slightly, you could write a custom function for each record type (which you already have to do to convert to slv; this would just be a bit longer) that returns the nth element, like:
function get_record_element(input : johns_record_type; element_number : natural) return std_logic_vector is
begin
case element_number is
when 0 =>
return to_slv(input.first_element);
when 1 =>
return to_slv(input.second_element);
...
end function;
...
if get_record_element(johns_record, 2) = ... then
where to_slv is just a set of helper functions to convert other types. Is that more or less tedious than writing a more generic function and using an extra record element?
Instead of a record, then an array may be used, where the index value are based on an enumerated type, and the array elements are a super-set of the required type. Declaration like:
type johns_elements_t is (FIRST, SECOND, THIRD);
subtype johns_type_t is std_logic_vector(3 downto 0); -- Super-set of required types
type johns_array_t is array (johns_elements_t) of johns_type_t;
signal johns_array : johns_array_t;
Use is then like:
for johns_index in johns_array'range loop
if johns_array(johns_index) = "0000" then
exit;
end if;
VHDL attributes can be used to convert the values in the enumerated type between natural, like for example:
for natural_index in 0 to johns_elements_t'pos(johns_elements_t'high) loop
if johns_array(johns_elements_t'val(natural_index)) = "0000" then
Access to elements must then take into account how the contents is used for each elements accessed by the values in the enumerated type, but that is the case anyway when using a record, but now where is no type checking in the compiler. Another use case is:
if johns_array(FIRST)(0) = '1' then -- Used as std_logic
johns_array(FIRST)(0) <= '0';
...
In synthesis, the tool is likely to remove the unused bits in elements where only a subset of the bits are used, so the final design is not larger.
Also, some synthesis tools (for example Altera Quartus II) does not accept functions that return variable length results like std_logic_vector, so a solution for synthesis should taken that into account, since a functions like get_record_element may result in an error.

VHDL signal dimension issue when reducing a generic value down to 0

How can one handle this case:
entity foo is
generic (
num_instances : natural := 8
);
port (
data_in_per_instance : in std_logic_vector(num_instances-1 downto 0);
data_out_per_instance : out std_logic_vector(num_instances-1 downto 0)
);
end foo;
architecture bar of foo is
component do_stuff is
port(
din : in std_logic;
dout : out std_logic
);
end component do_stuff;
signal sig_per_instance : std_logic_vector(num_instances-1 downto 0);
begin
L1: for i in 0 to num_instances-1 generate
L2: do_stuff
port map(
din => data_in_per_instance(i),
dout => data_out_per_instance(i)
);
end generate;
end bar;
The problem here is that if num_instances is reduced to 0 there will be an error when the signal ranges (num_instances-1 downto 0) are evaluated....
Is there an elegant way around this? All I can come up with is using a function like max(num_instances-1,0) to prevent this problem (but then synthesis may not give me exactly what I want, i.e. nothing).
Is there some way to handle this case a little more seamless?
A simple answer is to wrap the for-generate statement in an if-generate, if num_instances /= 0 generate ... Unfortunately if-generates have no else part, however there is nothing to stop you adding a second if num_instances = 0 generate ... statement to handle that special case.
Alternatively you can wrap the problem part of the for-generate using if-generate.
EDIT: re the need for a correct signal declaration guarded by the if ... generate.
AHA! You may have discovered a legitimate use for VHDL's (in my experience) rarely used "block" statement!
A block statement may contain signal declarations, and can be wrapped in a generate.
So this is valid VHDL:
Normality : block is
-- signal declarations here
begin
-- concurrent code here
end block Normality;
and it can be legally wrapped in a generate statement...
A std_logic_vector with an empty range (for example 3 downto 4) is perfectly legitimate - it's called a "null range" by the LRM. If you create one, then (at least with Modelsim) you will get warnings, which is usually considered poor form. To eliminate those, then Brian's block suggestion is what you'll have do.
Similarly the for..generate will result in an empty loop and no instances. No warnings for this.
I'm intrigued why you'd want a block with no instances in? I'd make num_instances a positive to force at least one of them, but that may not actually what you want!

Resources