I have the following declarations:
signal count:STD_LOGIC_VECTOR (3 downto 0);
signal txbuff:STD_LOGIC_VECTOR (7 downto 0);
dout is a std_logic output
I am using IEEE.NUMERIC_STD.ALL;
I want to use the vector count as an index into txbuff. Among the many things I've tried is the following:
count<=std_logic_vector(unsigned(count)-1);
dout<=txbuff(unsigned(count));
but I get the following error:
Line 99. Wrong index type for txbuff.
You need an integer as the index type. (Or with other arrays, you can use any discrete type, such as as enumeration).
Other answers have showed you how to get there using type conversion functions : I'll ask instead, why not make "count" an integer, like natural range 0 to 15 in the first place? It'll synthesise just the same, and make for cleaner simpler code.
We actually want to convert the number to an integer, not an unsigned or signed.
To do this, we can use to_integer as defined in numeric_std. Here's an example:
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;
entity conv_test is Port (
data_in : in std_logic_vector(7 downto 0);
data_sel : in std_logic_vector(2 downto 0);
data_out : out std_logic
);
end conv_test;
architecture Behavioral of conv_test is
begin
data_out <= data_out(to_integer(unsigned(data_sel)));
end Behavioral;
You need to convert to integer using the to_integer function. Check the parameterised MUX:
architecture RTL of MUX is
begin
-----------------------------------------------------------------------
-- MUX_RTL
-----------------------------------------------------------------------
-- Implements a multiplexer
-----------------------------------------------------------------------
MUX_RTL: process(DATA_IN, ADDR_IN)
variable ADDR_IN_INT : integer range 0 to 2**ADDR_WIDTH-1; -- holds the integer value of the address
begin
ADDR_IN_INT := to_integer(unsigned(ADDR_IN));
DATA_OUT <= DATA_IN(ADDR_IN_INT);
end process MUX_RTL;
end architecture RTL;
Related
Personally, I get sick of typing std_logic_vector in VHDL code... it's too long... how can I alias the type name 'std_logic_vector' to a shorter name like 'v' for vector:
library ieee;
use ieee.std_logic_1164.all;
entity dsn is
end entity dsn;
architecture beh of dsn is
type v is std_logic_vector;
signal mysig1 : v(7 downto 0);
signal mysig2 : v(14 downto 0);
begin
end architecture;
Use an alias
alias v is std_logic_vector;
Use a subtype
subtype x is v(open);
subtype x32 is x(31 downto 0);
You can do better with named subtypes that reflect the purpose of the signal
subtype data is std_logic_vector(31 downto 0);
subtype addr is unsigned(19 downto 0);
in a package used by everything in your design. Now, declarations are not only shorter, but contain more useful information.
I am trying to create a bus/dataflow multiplexer with variable width and number of inputs, and use it as an IP Module in block design with Vivado. So far I have successfully managed to create a 2to1 mux with variable width:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity mux is
Generic ( NUM_BITS : integer);
Port (
SEL : in STD_LOGIC;
A : in STD_LOGIC_VECTOR(NUM_BITS-1 downto 0);
B : in STD_LOGIC_VECTOR(NUM_BITS-1 downto 0);
X : out STD_LOGIC_VECTOR(NUM_BITS-1 downto 0));
end mux;
architecture Behavioral of mux is
begin
X <= A when (SEL = '0') else B;
end Behavioral;
This works. I am able to drop this into the Block Design tool in Vivado, and I am able to customize the block and change the value of "NUM_BITS".
Customizable IP Mux in Block Design
I have almost successfully created a variable input mux with fixed width:
use IEEE.STD_LOGIC_1164.ALL;
package my_pkg is
-- Generic ( NUM_BITS : integer);
type inputs is array(natural range<>) of STD_LOGIC_VECTOR(8 downto 0);
end my_pkg;
library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL;
use work.my_pkg.all;
entity mux is
Generic ( SEL_WIDTH : integer);
Port (
SEL : in STD_LOGIC_VECTOR(SEL_WIDTH-1 downto 0);
INPUT : in inputs(0 downto 2**SEL_WIDTH-1);
OUTPUT : out STD_LOGIC_VECTOR(8 downto 0));
end mux;
architecture Behavioral of mux is
begin
OUTPUT <= INPUT(to_integer(unsigned(SEL)));
end Behavioral;
However, I am not able to drop this into the block design tool because port type needs to be std_logic_vector in order to be recognized by the block design tool.
Block Design Error
I have seen some other posts addressing similar issues:
Using array of std_logic_vector as a port type, with both ranges using a generic - unable to use the provided examples in block design tool
Use generic parameter as port array length - used this to create the code in second portion
But neither of these helped me achieve what I would like.
I would like to combine these two into one multiplexer with BOTH variable inputs and width.
I am using Xilinx Vivado 2020.1
I am currently implementing a MIPS processor in VHDL. The system component (which glues together the ALU, register file, control unit, etc.) has the follow entity description:
entity system is
port (
reset : in std_logic;
sys_clk : in std_logic;
instruction : in std_logic_vector(15 downto 0);
sys_mem_dump : in std_logic := '0'
);
end system;
In the architecture section of this system, I am trying to create "subvariables" of the instruction variable, corresponding to the opcode and registers in use.
architecture Behavioral of system is
instruction_opcode : std_logic_vector(3 downto 0) := instruction(15 downto 12);
instruction_rd : std_logic_vector(3 downto 0) := instruction(11 downto 8); -- destination register
instruction_rs : std_logic_vector(3 downto 0) := instruction(7 downto 4); -- source register
instruction_rt : std_logic_vector(3 downto 0) := instruction(3 downto 0); -- target register
-- a bunch of signals
begin
-- a bunch of port maps
end Behavioral
I've tried signal, variable, shared_variable, and constant, but these result in the register file's addresses not being initialized when I port map one of these variables to it. I've also tried putting these variables in the system entity port, but that also doesn't work. I don't want to split the instruction variable in the system entity port into those four variables either.
agree with paebles: you seem to lack basic VHDL knowledge and should look for this in your book.
You should at least know this method:
architecture Behavioral of system is
signal instruction_opcode : std_logic_vector(3 downto 0);
begin
instruction_opcode <= instruction(15 downto 12);
end architecture;
But you can in fact use aliases:
architecture Behavioral of system is
alias instruction_opcode : std_logic_vector(3 downto 0) is instruction(15 downto 12);
begin
end architecture;
A common thread reflecting your comment
#Paebbels Is it simply not possible to do this in VHDL? I have looked at the synario manual and some other websites, and none of the data object types match this use case.
is that the references you have used are inadequate.
In addition to intermediary signals and object aliases described in JH Bonarius' answer there is a method using index ranges declared as subtypes:
library ieee;
use ieee.std_logic_1164.all;
entity field is
port (
fourbitfield: in std_logic_vector (3 downto 0)
);
end entity;
architecture foo of field is
begin
end architecture;
library ieee;
use ieee.std_logic_1164.all;
entity system is
port (
reset: in std_logic;
sys_clk: in std_logic;
instruction: in std_logic_vector(15 downto 0);
sys_mem_dump: in std_logic := '0'
);
end entity system;
architecture foo of system is
subtype opcode is integer range 15 downto 12;
subtype rd is integer range 11 downto 8;
subtype rs is integer range 7 downto 4;
subtype rt is integer range 3 downto 0;
begin
U1:
entity work.field port map (instruction(opcode));
U2:
entity work.field port map (instruction(rd));
U3:
entity work.field port map (instruction(rs));
U4:
entity work.field port map (instruction(rt));
end architecture;
This analyzes, elaborates and simulates (Not actually doing anything while proving a lack of bounds errors).
An entity is an independent design unit and naturally allows abstraction (port names are associated with actual signals in a port map during elaboration of a component instantiation). All other forms of names or using intermediary objects are forms of abstraction intended for readability and are dictated by style.
In the above instruction(opcode) and it's like are slice names (IEEE Std 1076-2008 8.5 Slice names) providing a discrete range in the form of a integer subtype. You could likewise use slice names with discrete ranges (e.g. 15 downto 12) as actuals in association lists directly without declaring subtypes:
U1:
entity work.field port map (fourbitfield => instruction(15 downto 12));
Using named association between formal port and actual signals shown here can preclude the need for further abstraction. Dictating abstraction impinges on style not required by the VHDL standard.
Your idea of sub signals or variables aligns with slice names in VHDL as easily as the use of intermediary signals. Aliases are simply other names for named entities (including object slices).
Which additional abstraction method if any you use might depend on the sophistication level of anticipated readers.
If someone were to search the vhdl tag on Stackoverflow thoroughly you'd find examples of all three of these methods. A wile reader could edit your question to align with VHDL syntax and submit it as a duplicate.
I found this code which is a part of Exponentiation implementation, I believe this code is for parallel load register, the code had many mistakes, yet I tried to fix it and simplify it(simplification is to make it work), the original code is:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity REG is --Register entity
Port ( CLK,set,reset,In_LOAD : in std_logic;
Din_p: in std_logic_vector(m-1 to 0);
Din_s: in std_logic;
Dout: out std_logic);
end REG;
architecture behavior of REG is
signal Q_temp: std_logic_vector(m-1 down to 0);
begin
Dout<=”0”;
comb:process(In_LOAD,Din_s)
begin
if(In_LOAD=”1”) then Q_temp<=Din_p;end if;
end process comb;
state: process(CLK,set,reset)
begin
if(reset=”1”) then Q_temp<=(others=>”0”);end if;
if(set=”1”) then Q_temp<= (others=>”1”);
elsif(CLK’event and CLK=”1”) then
Q_temp:=Din_p & Q_temp(m-1 down to 1);
end if;
Dout<= Q_temp(0);
end process state;
end behavior;
while the code I modified is:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity REG2 is --Register entity
generic (m: integer := 4);
Port ( CLK,In_LOAD : in std_logic;
Din_p: in std_logic_vector(m-1 to 0);
Dout: out std_logic);
end REG2;
architecture behavior of REG2 is
signal Q_temp: std_logic_vector(m-1 downto 0);
begin
Dout<='0';
process(In_LOAD, Din_p, CLK)
begin
if (CLK'event and CLK='1') then
Q_temp <=Din_p;
elsif (In_LOAD='1') then
Q_temp <= Din_p & Q_temp(m-1 downto 1);
end if;
end process;
Dout <= Q_temp(0);
end behavior;
so my questions are : 1- why I'm getting this error :(Error (10344): VHDL expression error at REG2.vhd(18): expression has 0 elements, but must have 4 elements)?
2- this is a code for parallel load register, right?
thx
Plenty of things are wrong with your code (and the original code).
use the correct quote character " for bit strings and ' for bits instead of ”
downto is one word, not down to
m is not declared; perhaps this is supposed to be a generic?
Assign to Q_temp using signal assignment <= instead of variable assignment :=
Sensitivity lists for both your processes are incomplete
As #Morten mentions: the direction of Din_p should probably downto instead of to
Bonus (pet peeve): don't use IEEE.STD_LOGIC_ARITH and IEEE.STD_LOGIC_UNSIGNED, because they are not properly standardized. Use ieee.numeric_std instead.
I want to use a generic 'p' to define how many outputs a demux will have. Input and all outputs are 1 bit. The outputs, control, and input can be something simple like:
signal control : std_logic_vector(log 2 p downto 0); -- I can use a generic for the log2..
signal input : std_logic;
signal outputs : std_logic_vector(p-1 downto 0);
But what would the mux implementation code be? Is it even possible?
No generics required:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity demux is
port(
control : in unsigned;
input : in std_logic;
outputs : out std_logic_vector
);
end entity demux;
architecture rtl of demux is
-- Check size of input vectors
assert 2**control'length = outputs'length
report "outputs length must be 2**control length"
severity failure;
-- actually do the demuxing - this will cause feedback latches to be inferred
outputs(to_integer(unsigned(control)) <= input;
end architecture;
(Untested, just typed in off the top of my head...)
This will infer latches though - is that what you want?
You need to feed log_p as generic and compute p as you go.
library ieee;
use ieee.std_logic_1164.all;
entity demux is
generic (
log_p: integer);
port(
control : in std_logic_vector(log_p downto 0);
input :in std_logic;
outputs : out std_logic_vector(2**log_p - 1 downto 0)
);
end entity demux;
You need to pass both the number of outputs and the size of the control array as generics, unless you are always using powers of two.
Outside of your (de)mux module (ie: when you instantiate), you can use code to calculate the number of bits for the control bus. I have a function in a common package I use to initialize various configuration constants and generics that get passed to code similar to your (de)mux application:
-- Calculate the number of bits required to represent a given value
function NumBits(val : integer) return integer is
variable result : integer;
begin
if val=0 then
result := 0;
else
result := natural(ceil(log2(real(val))));
end if;
return result;
end;
...which allows you to do things like:
constant NumOut : integer := 17;
signal CtrlBus : std_logic_vector(NumBits(NumOut)-1 downto 0);
my_mux : demux
generic map (
NumOut => NumOut,
NumCtrl => NumBits(NumOut) )
port map (
control => CtrlBus,
...
...