This has me bugging for quite some time, but is it possible to describe entities in VHDL similar to how templates work in C++ (or to lesser extend generics?). Simply leaving the actual port types to be only decided during synthesize/compilation?
An example would be a multiplexer, say I have a 4 input multiplexer, now I have several bus sizes I use this multiplexer for, -4,6,7,8-. Currently I wrote a different multiplexer for each different bus size; however the output is simply one of the chosen inputs forwarded, and is thus of the same type as the bus.
This seems overly redundant and error prone (choose correct multiplexer at correct times, keep them all in line, update them as I change the bus size). Is there no way to parameterize this?
non generic version below to show the idea.
entity mux_6bit_4input is
port ( input_0 : in std_logic_vector (5 downto 0);
input_1 : in std_logic_vector (5 downto 0);
input_2 : in std_logic_vector (5 downto 0);
input_3 : in std_logic_vector (5 downto 0);
sel : in std_logic_vector (1 downto 0);
output : out std_logic_vector (5 downto 0)
);
end entity mux_6bit_4input;
Maybe I misunderstood the question, but doesn't the common solution using generics solve your problem?
library ieee;
use ieee.std_logic_1164.all;
entity mux_4x1 is
generic (
DATA_WIDTH: integer := 8
);
port (
input_0: in std_logic_vector(DATA_WIDTH-1 downto 0);
input_1: in std_logic_vector(DATA_WIDTH-1 downto 0);
input_2: in std_logic_vector(DATA_WIDTH-1 downto 0);
input_3: in std_logic_vector(DATA_WIDTH-1 downto 0);
sel: in std_logic_vector (1 downto 0);
output: out std_logic_vector(DATA_WIDTH-1 downto 0)
);
end;
architecture behavior of mux_4x1 is
begin
output <=
input_0 when sel = "00" else
input_1 when sel = "01" else
input_2 when sel = "10" else
input_3;
end;
Another solution, if you want to keep things really generic, is to use the cool generic types in VHDL-2008. My simulator doesn't yet support this feature, so here's an example from the excellent book VHDL 2008: Just the New Stuff:
entity generic_mux2 is
generic (type data_type);
port (
sel: in bit;
a, b: in data_type;
z: out data_type
);
end;
architecture rtl of mux2 is
begin
z <= a when sel = '0' else b;
end;
Another option is to use unconstrained arrays:
entity mux_4input is
port (
input_0 : in std_logic_vector ;
input_1 : in std_logic_vector ;
input_2 : in std_logic_vector ;
input_3 : in std_logic_vector ;
sel : in std_logic_vector (1 downto 0);
output : out std_logic_vector
);
end entity mux_4input;
They will inherit their width (and direction) from the signals they are conencted to in the instantiating entity.
It's probably not the right thing to do in this particular case of a mux, rick's answer is what I'd go for, but unconstrained arrays don't get mentioned much, so I thought I'd offer them! In this case, you'd probably also want some asserts to ensure that everything you've wired up is the same width.
Related
I am trying to program an FPU unit in VHDL. I am doing my first steps. I get two errors while executing this instruction:
mantissa1 <= std_logic_vector(resize(unsigned(mantissa1),mantissa1'length + d));
The errors are:
Error: C:/Modeltech_pe_edu_10.4a/examples/fpu/shifter.vhd(38): Illegal type conversion to ieee.std_logic_1164.STD_LOGIC_VECTOR (operand type is not known).
Error: C:/Modeltech_pe_edu_10.4a/examples/fpu/shifter.vhd(36): (vcom-1078) Identifier "unsigned" is not directly visible.
Here is my code
library ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_misc.ALL;
USE ieee.std_logic_unsigned.ALL;
USE ieee.std_logic_arith.ALL;
use ieee.numeric_std.all;
entity fpu is
port (
E1,E2 : IN std_logic_vector( 30 downto 23);
M1,M2 : IN std_logic_vector( 22 downto 0);
S1,S2 : IN std_logic_vector (31 downto 31);
op : IN std_logic_vector (1 downto 0);
SUM : OUT std_logic_vector (45 downto 0);
E : OUT std_logic_vector (7 downto 0);
clk : IN std_logic
);
end entity;
architecture arch_fpu of fpu is
SIGNAL d: integer;
SIGNAL mantissa1 : std_logic_vector (22 DOWNTO 0) ;
SIGNAL mantissa2 : std_logic_vector (22 DOWNTO 0) ;
begin
process(E1,E2,M1,M2,S1,S2,clk)
BEGIN
if((op="01") or (op="00")) then
E<=E1 when E1>E2 else
E2;
d<=abs(conv_integer(E1-E2));
mantissa1 <= std_logic_vector(resize(unsigned(mantissa1),mantissa1'length + d));
end if;
END process;
end arch_fpu;
You are mixing VHDL math libraries. I suggest you use either numeric_std (my preference) or std_logic_unsigned/std_logic_arith, but not both.
There are several other issues as well. You cannot assign the larger (by 'd' bits) manitissa1 value back to manitissa1, you need a target of the appropriate size. Your subtraction of E1-E2 will need some type conversion to be legal, perhaps: signed(E1) - signed(E2)
Honestly, you probably want to rethink the whole approach to what you are trying to do, especially if you expect to synthesize this code into logic.
How do I split 16-bit data into 2 8-bit data?
signal part : std_logic_vector (16 downto 0);
signal part_1 : std_logic_vector (8 downto 0);
signal part_2 : std_logic_vector (8 downto 0);
The part is actually 17 bit, since 16 downto 0 is a 17 bit range, and the part_* are likewise 9 bit.
If the ranges are 15 downto 0 and 7 downto 0, then you can do the split with:
part_1 <= part( 7 downto 0);
part_2 <= part(15 downto 8);
Btw, quote by Martin Fowler / Phil Karlton:
There are two hard things in computer science:
cache invalidation, naming things, and off-by-one errors.
Why are your signals 17 bits and 9 bits long? I think they should be 16 and 8...
signal part : std_logic_vector (15 downto 0);
signal part_1 : std_logic_vector (7 downto 0);
signal part_2 : std_logic_vector (7 downto 0);
begin -- architecture begin
part_1 <= part(15 downto 8);
part_2 <= part(7 downto 0);
Pretty simple stuff... I'm surprised you didn't run across this in looking at a VHDL example.
There's also aggregate target assignment:
library ieee;
use ieee.std_logic_1164.all;
entity foo is
end entity;
architecture fum of foo is
type fie is array (natural range 0 to 1) of std_logic_vector (7 downto 0);
signal part: std_logic_vector (15 downto 0);
signal part_1: std_logic_vector (7 downto 0);
signal part_2: std_logic_vector (7 downto 0);
begin
(part_1, part_2) <= fie'(part(15 downto 8), part(7 downto 0));
end architecture;
Which is admittedly more useful for extracting elements of records in one fell swoop. What's slick here is that there's no place there's any named signal of type fie.
The reason for the aggregate on the right hand side is because the element size has to match on both sides of the assignment operator, both aggregates are treated as if they are type fie.
Doing this with records allows you to extract elements of varying sizes. Extracting fields from CPU machine instruction formats comes to mind. It allows you to use simple names without requiring aliases for element selected names. (There would be no named record).
When the element size is the same on both sides you can simply use a target aggregate:
library ieee;
use ieee.std_logic_1164.all;
entity fie is
end entity;
architecture fum of fie is
signal part: std_logic_vector (2 downto 0);
signal part_1: std_logic;
signal part_2: std_logic;
signal part_3: std_logic;
begin
(part_1, part_2, part_3) <= part;
end architecture;
These aggregates all use positional association. You can also use named association. Record aggregates require an others choice represent at least one element and all the elements have to have the same type (e.g. std_logic_vector).
Just for completeness: you can also use aliases which makes the signal assignment obsolete:
signal part : std_logic_vector (15 downto 0);
alias part_1 : std_logic_vector(7 downto 0) is part(15 downto 8);
alias part_2 : std_logic_vector(7 downto 0) is part(7 downto 0);
I've bought a Spartan 3A development board from Micronova (http://micro-nova.com/mercury) and I've got some problems interfacing with its SRAM.
This board has 30 GPIO pins that are shared with Cypress SRAM and two pins to switch between them.
Obviously, connecting two VHDL modules (one for controlling SRAM and the other to drive GPIO) to the same pin leads to "Multiple driver error" when synthetizing.
So, to solve the problem I've created a third module as a middle controller that connects both modules with another variable for choosing which one to operate.
This works well for output, but when it comes to read input I always get 1, independently of the real value.
I don't know which pins will be used as input and which ones are for output because I would like an independent module that I can use for other projects.
This is what I got so far:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity DMA2 is
Port (
IOphys : inout STD_LOGIC_VECTOR (29 downto 0);
IOin1 : out STD_LOGIC_VECTOR (29 downto 0);
IOin2 : out STD_LOGIC_VECTOR (29 downto 0);
IOout1 : in STD_LOGIC_VECTOR (29 downto 0);
IOout2 : in STD_LOGIC_VECTOR (29 downto 0);
SwitchEn2 : in STD_LOGIC
);
end DMA2;
architecture Behavioral of DMA2 is
begin
IOin2 <= IOphys;
IOin1 <= IOphys;
IOphys <= IOout2 when SwitchEn2 = '1' else IOout1;
end Behavioral;
IOphys are the physical pins on the board, SwitchEn2 is for choosing the driving module and the others are the inputs and outputs of the modules.
You don't seem to be driving your outputs. As a starter, how about defining a tristate driver like so
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity tristate is
port (
signal data_in : out std_logic;
signal data_out : in std_logic;
signal data_tristate : inout std_logic;
signal tristate_select : in std_logic
);
architecture rtl of tristate is
begin
data_in <= data_tristate;
data_tristate <= 'z' when tristate_select = '1' else data_out;
end architecture;
Then selecting between its use like so
entity arbitrate_bus
port(
-- the pins
IOphys : inout STD_LOGIC_VECTOR (29 downto 0);
IOin1 : out STD_LOGIC_VECTOR (29 downto 0);
IOout1 : in STD_LOGIC_VECTOR (29 downto 0);
IO_direction1 : in STD_LOGIC_VECTOR (29 downto 0);
IOin2 : out STD_LOGIC_VECTOR (29 downto 0);
IOout2 : in STD_LOGIC_VECTOR (29 downto 0);
IO_direction2 : in STD_LOGIC_VECTOR (29 downto 0);
SwitchEn2 : in STD_LOGIC
);
architecture like_this of arbitrate_bus is
signal input : STD_LOGIC_VECTOR (29 downto 0);
signal output_selected : STD_LOGIC_VECTOR (29 downto 0);
signal direction_selected : STD_LOGIC_VECTOR (29 downto 0);
begin
output_selected <= IOout1 when SwitchEn2 = '0' else IOout2;
direction_selected <= IO_direction1 when SwitchEn2 = '0' else IO_direction2;
g_ts: for g in output_selected'range generate
begin
u_ts: entity tristate
port map(
data_in => input(g),
data_out => output_selected(g),
data_tristate => IOphys(g),
tristate_select => direction_selected(g)
);
end generate;
IOin1 <= input;
IOin2 <= input;
end architecture;
What value are you assigning to the pins that are supposed to be inputs?
You may be able to infer proper operation if you assign 'Z' to the IOout1 and IOout2 signals when that pin is supposed to be an input, but I recommend you actually instantiate tri-state I/O pins. In addition to multiplexing the output state, you should also multiplex the output enable between the two modules, then your input code should work properly.
So each module generates output signals and a set of output enables. These signals get multiplexed and tied to the one set of physical pins, with the output enables determining which pins are inputs and which are outputs. This way, everything in the FPGA is binary logic and you are not relying on the synthesizer to infer a tri-state bus.
I have the following problem: I have to implement 8 bit left shifter that makes one shift to left, the code of it is:
entity left_shift is
generic ( N: integer := 8);
Port(
Databitsin : in STD_LOGIC_vector(N-1 downto 0);
Databitsout : out STD_LOGIC_vector(N-1 downto 0);
Carry: out std_logic
);
end left_shift;
architecture Behavioral_l of left_shift is
begin
Databitsout(N-1 downto 1)<= Databitsin(N-2 downto 0);
Carry<=Databitsin(N-1);
end Behavioral_l;
then i have to implement another one that has to make one shift to the right
entity Right_shift is
generic ( N: integer := 8);
Port(
Databitsin : in STD_LOGIC_vector(N-1 downto 0);
Databitsout : out STD_LOGIC_vector(N-1 downto 0);
Carry: out std_logic
);
end Right_shift;
architecture Behavioral of Right_shift is
begin
Databitsout(N-2 downto 0)<= Databitsin(N-1 downto 1);
Carry<=Databitsin(0);
end Behavioral;
Now, I have to build a main Module which has to use these 2 components to make cyclically shift (left,right).
How can I do that?
there's different ways to implement cyclical shift (=rotate!). if you add a direction-selector Dir, you can have both directions within one code.
ex.1
add "use IEEE.NUMERIC_STD.all" to make use of numeric_std package functions:
Databitsout<=std_logic_vector(rotate_right(unsigned(Databitsin),1)) when Dir='0' else
std_logic_vector(rotate_left(unsigned(Databitsin),1));
ex. 2
use std_logic_vectors directly:
Databitsout<=Databitsin(0) & Databitsin(N-1 downto 1) when Dir='0' else
Databitsin(N-2 downto 0) & Databitsin(N-1);
carry flag is the same in both:
Carry<= Databitsin(0) when Dir='0' else
Databitsin(N-1);
This sounds a lot like homework, but never-the-less:
Firstly, why do you have to use two components? The elegant solution is to write one component capable of shifting left or right.
If you have some astoundingly good reason to do things the way you've suggested, try instantiating both and multiplexing between the databitsout signals of both depending on the desired diection. To make a cyclic shift instead of a linear one, you need to concatinate the carry bit into the appropriate end of the logic vector array.
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_1164_unsigned.all;
ENTITY alu IS
PORT (a: IN STD_LOGIC_VECTOR (15 DOWNTO 0);
b: IN STD_LOGIC_VECTOR (15 DOWNTO 0);
operation: IN INTEGER (1 TO 10);
result: OUT STD_LOGIC_VECTOR (15 DOWNTO 0);
);
ARCHITECTURE arch-alu OF alu IS
SIGNAL arith, logic: STD_LOGIC_VECTOR (15 DOWNTO 0);
BEGIN
----rest of the code which give values to arith and logic----
WITH operation SELECT
result <= arith WHEN (1 TO 5),
logic WHEN (6 TO 10);
END arch-alu
My query is: Can I put a range after WHEN (as in the code), or I have to specify one by one each possibility of the signal.
Thanks!
According to http://tams-www.informatik.uni-hamburg.de/vhdl/tools/grammar/vhdl93-bnf.html the syntax you've used is permitted by VHDL '93 (the productions to look at there, in order: selected_signal_assignment, selected_waveforms, choices, choice, discrete_range, range) except that the grammar there doesn't seem to allow for the parentheses around the ranges. See also http://www.vhdl.renerta.com/source/vhd00063.htm (which again has no parens around the ranges).
You can use ranges in choices but you should omit the parentheses.
Not that your code fragment contained a lot more errors than just the superfluous parentheses. You had a missing end entity, a superfluous semicolon at the end of the port declaration, and incorrect integer port declaration,... A good VHDL IDE, such as Sigasi HDT, would help you catch these immediately.
Corrected fragment:
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY alu IS
PORT (a: IN STD_LOGIC_VECTOR (15 DOWNTO 0);
b: IN STD_LOGIC_VECTOR (15 DOWNTO 0);
operation: IN INTEGER range 1 TO 10;
result: OUT STD_LOGIC_VECTOR (15 DOWNTO 0)
);
end entity;
ARCHITECTURE arch_alu OF alu IS
SIGNAL arith, logic: STD_LOGIC_VECTOR (15 DOWNTO 0);
BEGIN
--rest of the code which give values to arith and logic----
WITH operation SELECT
result <= arith WHEN 1 TO 5,
logic WHEN 6 TO 10;
END arch_alu;