I want to use four push buttons as inputs and three seven-segment LED displays as outputs. Two push buttons should step up and down through the sixteen RAM locations; the other two should increment and decrement the contents of the currently-displayed memory location. One seven segment display should show the current address (0–F), and two others should display the contents of that location in hexadecimal (00–FF). This is my code to attempt to do this (I haven't implemented the display yet):
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;
do : out unsigned(7 downto 0)
);
end raminfr;
architecture rtl of raminfr is
type ram_type is array (0 to 15) of unsigned(7 downto 0);
signal RAM : ram_type;
signal read_a : unsigned(3 downto 0);
signal a : unsigned(3 downto 0);
signal di : unsigned(7 downto 0);
signal clock : std_logic;
signal key : std_logic_vector(3 downto 0);
begin
U1: entity work.lab1 port map (
clock =>clock,
key => key,
register_counter => a,
value_counter => di
);
process (clk)
begin
if rising_edge(clk) then
if we = '1' then
RAM(to_integer(a)) <= di;
end if;
read_a <= a;
end if;
end process;
do <= RAM(to_integer(read_a));
end rtl;
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity lab1 is
port(
clock : in std_logic;
key : in std_logic_vector(3 downto 0);
value_counter : buffer unsigned(7 downto 0) ;
register_counter : buffer unsigned(3 downto 0)
);
end lab1;
architecture up_and_down of lab1 is
signal value_in_ram : unsigned(7 downto 0);
signal clk : std_logic;
signal we : std_logic;
begin
U1: entity work.raminfr port map (
do=>value_in_ram,
clk=>clk,
we=>we
);
process(clock, value_counter, register_counter)
begin
if rising_edge(clock) then
if (key(3)='0' and key(2)='0' and key(1)='1' and key(0)='0') then
value_counter <= value_counter + "1";
elsif (key(3)='0' and key(2)='0' and key(1)='0' and key(0)='1') then
value_counter <= value_counter - "1";
elsif (key(3)='1' and key(2)='0' and key(1)='0' and key(0)='0') then
register_counter<= register_counter + "1";
value_counter <= value_in_ram;
elsif (key(3)='0' and key(2)='1' and key(1)='0' and key(0)='0') then
register_counter<= register_counter - "1";
value_counter <= value_in_ram;
end if;
end if;
end process;
end architecture up_and_down;
When I try to compile this, I get the following errors repeating over and over:
Error (12051): Project too complex: hierarchy path is too long
Error (12052): Entity "lab1" is instantiated by entity "raminfr"
Error (12052): Entity "raminfr" is instantiated by entity "lab1"
This is obviously due to the fact that I have port mapped each entity in the other, but I don't know any other way to accomplish what I want to accomplish. Can somebody suggest alternatives?
This is a guess since it's not too clear what you want to do. It seems that the problem is one of design : you have a good idea what the end result should do, but it's not clear how to decompose that into components which interact in the simplest way to accomplish the goal.
I am basing this guess on the fact that the active code in "raminfr" stores and loads data independent of the other stuff that has crept in.
So I am going to suggest that "raminfr" be cleaned up as just a memory component WITHOUT any of the other stuff. It can then be embedded in the "lab1" component which handles keys, and stores and displays values from the correct registers. It can also be reused anywhere else you need a memory.
So let's look at raminfr.
entity raminfr is
port (
clk : in std_logic;
we : in std_logic;
do : out unsigned(7 downto 0)
);
end raminfr;
It has a clock, a write enable input, and a data output. But curiously, no address or data inputs! Now, memory is such a standard "design pattern" that deviation from it is probably ill advised, so let's add them...
entity raminfr is
port (
clk : in std_logic;
we : in std_logic;
addr : in unsigned(3 downto 0);
di : in unsigned(7 downto 0);
do : out unsigned(7 downto 0)
);
end raminfr;
Some variants of the memory pattern have other features; read enables, output enables, separate read and write clocks, etc but this simple one will do here.
You can also use generics to customise its size, modifying its data and address bus widths to match. This makes it much more useful and saves a proliferation of similar but different modules...
Let's clean up the architecture to match.
architecture rtl of raminfr is
type ram_type is array (0 to 15) of unsigned(7 downto 0);
signal RAM : ram_type;
signal read_a : unsigned(3 downto 0);
begin
process (clk)
...
end process;
do <= RAM(to_integer(read_a));
end rtl;
Now we can instantiate it in the "lab1" module, connecting up its new ports
U1: entity work.raminfr port map (
addr => register_counter, -- was "a", typo
di => value_counter,
do => value_in_ram,
clk => clk,
we => we
);
and making any supporting changes to the rest of lab1.
This is not the only reasonable decomposition : you could also make "lab1" a simple component without its own storage and bring out other necessary signals as ports. Then you would need a third "top level" entity whose architecture interconnected lab1 and raminfr.
Related
i have created the structural and the behavioral code for a 1-bit ALU,as well as a control circuit .The control circuit decides the operation that will be conducted between two variables : a,b .
Here is my behavioral part of the code :
library ieee;
use ieee.std_logic_1164.all;
package erotima2 is
-- AND2 declaration
component myAND2
port (outnotA,outnotB: in std_logic; outAND: out std_logic);
end component;
-- OR2 declaration
component myOR2
port (outnotA,outnotB: in std_logic; outOR: out std_logic);
end component;
-- XOR2 declaration
component myXOR2
port (outnotA,outnotB: in std_logic; outXOR: out std_logic);
end component;
--fulladder declaration
component fulladder
port(CarryIn,outnotA,outnotB: in std_logic; sum,CarryOut: out std_logic);
end component;
--Ainvert declaration
component notA
port(a: in std_logic; signala: std_logic_vector(0 downto 0); outnotA: out std_logic);
end component;
--Binvert declaration
component notB
port(b: in std_logic; signalb: std_logic_vector(0 downto 0); outnotB: out std_logic);
end component;
--ControlCircuit declaration--
component ControlCircuit
port (
opcode : in std_logic_vector (2 downto 0);
signala,signalb : out std_logic_vector(0 downto 0);
operation : out std_logic_vector (1 downto 0);
CarryIn: out std_logic);
end component;
--mux4to1 declaration
component mux4to1
port(outAND, outOR, sum, outXOR: in std_logic; operation: in std_logic_vector(1 downto 0); Result: out std_logic);
end component;
end package erotima2;
--2 input AND gate
library ieee;
use ieee.std_logic_1164.all;
entity myAND2 is
port (outnotA,outnotB: in std_logic; outAND: out std_logic);
end myAND2;
architecture model_conc of myAND2 is
begin
outAND<= outnotA and outnotB;
end model_conc;
-- 2 input OR gate
library ieee;
use ieee.std_logic_1164.all;
entity myOR2 is
port (outnotA,outnotB: in std_logic; outOR: out std_logic);
end myOR2;
architecture model_conc2 of myOR2 is
begin
outOR <= outnotA or outnotB;
end model_conc2;
--2 input XOR gate
library ieee;
use ieee.std_logic_1164.all;
entity myXOR2 is
port(outnotA,outnotB: in std_logic; outXOR: out std_logic);
end myXOR2;
architecture model_conc3 of myXOR2 is
begin
outXOR <= outnotA xor outnotB;
end model_conc3;
--3 input full adder
library ieee;
use ieee.std_logic_1164.all;
entity fulladder is
port(CarryIn,outnotA,outnotB: in std_logic; sum,CarryOut: out std_logic);
end fulladder;
architecture model_conc4 of fulladder is
begin
CarryOut <= (outnotB and CarryIn) or (outnotA and CarryIn) or (outnotA and outnotB);
sum <= (outnotA and not outnotB and not CarryIn) or (not outnotA and outnotB and not CarryIn) or (not outnotA and not outnotB and CarryIn) or (outnotA and outnotB and CarryIn);
end model_conc4;
--1 input notA
library ieee;
use ieee.std_logic_1164.all;
entity notA is
port(a: in std_logic; signala:std_logic_vector(0 downto 0); outnotA: out std_logic);
end notA;
architecture model_conc6 of notA is
begin
with signala select
outnotA <= a when "0",
not a when others;
end model_conc6;
--1 input notB
library ieee;
use ieee.std_logic_1164.all;
entity notB is
port(b: in std_logic; signalb: std_logic_vector(0 downto 0); outnotB: out std_logic);
end notB;
architecture model_conc5 of notB is
begin
with signalb select
outnotB <= b when "0",
not b when others;
end model_conc5;
--4 input MUX
library ieee;
use ieee.std_logic_1164.all;
entity mux4to1 is
port(outAND, outOR, sum, outXOR: in std_logic; operation: in std_logic_vector(1 downto 0); Result: out std_logic);
end mux4to1;
architecture model_conc7 of mux4to1 is
begin
with operation select
Result<= outAND when "00",
outOR when "01",
sum when "10",
outXOR when OTHERS;
end model_conc7 ;
The behavioral part defines the logic gates of AND,OR,XOR, a full adder for numerical addition and substraction. It also contains a 4-to-1 multiplexer that chooses (depending on the value of the "operation" variable) which operation the alu will do. Lastly there is a function that inverts the variables in order to be more efficient with our logic gate usage( using the DeMorgan theorem so we don't have to create a NOR gate). The control unit initializes the variable inputs, as well as the carryIn variable of the full adder, depending on the variable "opcode". A board with every possible combination
Next is the Control Circuit part of the code, which implements the previous board.
`
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity ControlCircuit is
port (
opcode :in std_logic_vector (2 downto 0);
signala, signalb : out std_logic_vector(0 downto 0);
operation : out std_logic_vector(1 downto 0);
CarryIn : out std_logic);
end ControlCircuit;
architecture model_conc9 of ControlCircuit is
--signal outAND,outOR,outXOR,sum,outnotA,outnotB : std_logic;
--signal operation : out std_logic_vector(1 downto 0);
begin
process(opcode)
begin
case opcode is
--AND--
when "000"=>
operation <= "00";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
--OR--
when "001" =>
operation <= "01";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
--ADD--
when "011" =>
operation <= "10";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
--SUB--
when "010" =>
operation <= "10";
signala <= "0";
signalb <="1";
CarryIn <= '1';
--NOR--
when "101"=>
operation <= "00";
signala <= "1";
signalb <= "1";
CarryIn <= '0';
--xor
when "100" =>
operation <= "11";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
--Adiafores times--
when others =>
operation <= "00";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
end case;
end process;
end model_conc9;
`
Lastly here is the code that uses all the previous parts and and an RTL diagram that shows the code's result
library IEEE;
use ieee.std_logic_1164.all;
use work.erotima2.all;
entity structural is
port (a,b: in std_logic;
opcode : in std_logic_vector ( 2 downto 0);
Result,CarryOut : out std_logic);
end structural;
architecture alu of structural is
signal outAND,outOR,outXOR,sum,outnotA,outnotB,CarryIn : std_logic;
signal signala,signalb : std_logic_vector (0 downto 0);
signal operation : std_logic_vector (1 downto 0);
begin
u0 : myAND2 port map (outnotA,outnotB,outAND);
u1 : myOR2 port map (outnotA,outnotB,outOR);
u2 : myXOR2 port map (outnotA,outnotB,outXOR);
u3 : fulladder port map (CarryIn,outnotA,outnotB,sum,CarryOut);
u4 : notA port map (a,signala,outnotA);
u5 : notB port map (b,signalb,outnotB);
u6 : mux4to1 port map (outAND, outOR,sum, outXOR, operation, Result );
u8 : ControlCircuit port map(opcode,signala,signalb,operation,CarryIn);
end alu;
Now for the tough part, i need to use the 1-bit ALU 16 times as a component, to create a 16-bit ALU. It is important to keep the control circuit independent from the rest of the code. I have tried using an std_logic_vector ( 15 downto 0) but it did not work and i would like to use the previous code segments as a component. Can anyone give any tips or ideas that will help connect 16 1-bit ALUs to a complete 16-bit ALU? Thanks in advance for those who read this massive wall of text.
Your recent comment
Yes i understand that my code is weird but we were intsructed to invert the inputs according to this diagram . As for the duplicate post, i checked before posting and they were implemented only structurally, while in my case i need to write the behavioral part too.
Explains the issue, misspellings aside. You'll notice your architecture structural of entity structural doesn't match the signals shown on the above 1 bit alu diagram which doesn't contain an instantiated ControlCircuit.
If you were to provide a design unit that matched the above diagram you can hook up the 1 bit alu carry chain while deriving the carryin for the lsb from the control block which provides a + 1 and inversion for subtraction:
library ieee;
use ieee.std_logic_1164.all;
entity alu_16_bit is
port (
a: in std_logic_vector (15 downto 0);
b: in std_logic_vector (15 downto 0);
opcode: in std_logic_vector (2 downto 0);
result: out std_logic_vector (15 downto 0);
carryout: out std_logic
);
end entity;
architecture foo of alu_16_bit is
component alu_1_bit is
port (
a: in std_logic;
b: in std_logic;
ainvert: in std_logic;
binvert: in std_logic;
carryin: in std_logic;
operation: in std_logic_vector (1 downto 0);
result: out std_logic;
carryout: out std_logic
);
end component;
component controlcircuit is
port (
opcode: in std_logic_vector(2 downto 0);
ainvert: out std_logic;
binvert: out std_logic;
operation: out std_logic_vector(1 downto 0);
carryin: out std_logic -- invert a or b, add + 1 for subtract
);
end component;
signal ainvert: std_logic;
signal binvert: std_logic;
signal operation: std_logic_vector (1 downto 0);
signal carry: std_logic_vector (16 downto 0);
begin
CONTROL_CIRCUIT:
controlcircuit
port map (
opcode => opcode,
ainvert => ainvert,
binvert => binvert,
operation => operation,
carryin => carry(0) -- for + 1 durring subtract
);
GEN_ALU:
for i in 0 to 15 generate
ALU:
alu_1_bit
port map (
a => a(i),
b => b(i),
ainvert => ainvert,
binvert => binvert,
carryin => carry(i),
operation => operation,
result => result(i),
carryout => carry(i + 1)
);
end generate;
carryout <= carry(16) when operation = "10" else '0';
end architecture;
This represents moving ControlCircuit out of structural - only one copy is needed, renaming structural alu_1_bit and making the ports match.
There's a new top level alu_16_bit containing a single instance of ControlCircuit along with sixteen instances of alu_1_bit elaborated from the generate statement using the generate parameter i to index into arrays values for connections.
This design has been behaviorally implemented independently using the Opcode table you provided the link to:
as well as an independent fulladder used in alu_1_bit and appears functional.
This implies your design units haven't been validated.
I tried implementing a fir filter in VHDL but during the first three clocks I get no output and the error at 0 ps, Instance /filter_tb/uut/ : Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, the result will be 'X'(es)..
Source file (I also have 2 other files for D Flip-Flops):
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;
entity filter is
port ( x: in STD_LOGIC_VECTOR(3 downto 0);
clk: in STD_LOGIC;
y: out STD_LOGIC_VECTOR(9 downto 0));
end filter;
architecture struct of filter is
type array1 is array (0 to 3) of STD_LOGIC_VECTOR(3 downto 0);
signal coef : array1 :=( "0001", "0011", "0010", "0001");
signal c0, c1, c2, c3: STD_LOGIC_VECTOR(7 downto 0):="00000000";
signal s0, s1, s2, s3: STD_LOGIC_VECTOR(3 downto 0) :="0000";
signal sum: STD_LOGIC_VECTOR(9 downto 0):="0000000000";
component DFF is
Port ( d : in STD_LOGIC_VECTOR(3 downto 0);
clk : in STD_LOGIC;
q : out STD_LOGIC_VECTOR(3 downto 0));
end component;
component lDFF is
Port ( d : in STD_LOGIC_VECTOR(9 downto 0);
clk : in STD_LOGIC;
q : out STD_LOGIC_VECTOR(9 downto 0));
end component;
begin
s0<=x;
c0<=x*coef(0);
DFF1: DFF port map(s0,clk,s1);
c1<=s1*coef(1);
DFF2: DFF port map(s1,clk,s2);
c2<=s2*coef(2);
DFF3: DFF port map(s2,clk,s3);
c3<=s3*coef(3);
sum<=("00" & c0+c1+c2+c3);
lDFF1: lDFF port map(sum,clk,y);
end struct;
Testbench:
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use ieee.std_logic_unsigned.all;
ENTITY filter_tb IS
END filter_tb;
ARCHITECTURE behavior OF filter_tb IS
-- Component Declaration for the Unit Under Test (UUT)
COMPONENT filter
PORT(
x : IN STD_LOGIC_VECTOR(3 downto 0);
clk : IN std_logic;
y : OUT STD_LOGIC_VECTOR(9 downto 0)
);
END COMPONENT;
--Inputs
signal x : STD_LOGIC_VECTOR(3 downto 0) := (others => '0');
signal clk : std_logic := '0';
--Outputs
signal y : STD_LOGIC_VECTOR(9 downto 0);
-- Clock period definitions
constant clk_period : time := 10 ns;
BEGIN
-- Instantiate the Unit Under Test (UUT)
uut: filter PORT MAP (
x => x,
clk => clk,
y => y
);
-- Clock process definitions
clk_process :process
begin
clk <= '0';
wait for clk_period/2;
clk <= '1';
wait for clk_period/2;
end process;
-- Stimulus process
stim_proc1: process
begin
x<="0001";
wait for 10ns;
x<="0011";
wait for 10ns;
x<="0010";
wait for 10ns;
--x<="0011";
end process;
END;
Output:
If anyonce could help, I'd appreciate it. I think it has something to do with the inital values of the signals c_i and s_i but I'm not too sure.
Your FIR filter contains flip-flops. These flip-flops have no reset input and so power up in an unknown state. You simulator models this by initialising the flip-flops' outputs to "UUUU" (as the are four bits wide). A 'U' std_logic value represents and uninitialised value.
So, your code behaves as you ought to expect. If you're not happy with that behaviour, you need to add a reset input and connect it to your flip-flops.
You have build a series of three register making up a cascade of registers.
You have not provided a reset so the register contents will be Unknown. You use the registers for calculations without any condition. Thus you arithmetic calculations will see the Unknown values and fail as you have seen.
The first (simplest) solution would be to add a reset. But that is not the best solution. You will no longer get warnings but the first three cycles of your output will be based on the register reset value not of your input signal.
If you have a big stream and don't care about some incorrect values in the first clock cycle you can live with that.
The really correct way would be to have a 'valid' signal transported along side your data. You only present the output data when there is a 'valid'. This is the standard method to process data through any pipeline hardware structure.
By the way: you normally do not build D-ffs yourself. The synthesizer will do that for you. You just use a clocked process and process the data vectors in it.
I have some questions. If I add a reset pin, when will I toggle it from 1 to 0? How can I create this circuit without explicitly using D-ffs?
You make a reset signal in the same way as you make your clock.
As to D-registers: they come out if you use the standard register VHDL code:
reg : process (clk,reset_n)
begin
// a-synchronous active low reset
if (reset_n='0') then
s0 <= "0000";
s1 <= "0000";
s2 <= "0000";
elsif (rising_edge(clk)) then
s0 <= x;
s1 <= s0;
s2 <= s1;
....
(Code entered as-is, not checked for syntax or typing errors)
After writing to each address of Ram and then reading every address of Ram, how would I reinitialize the Ram so that when I write to it again a second time it starts off as if it were the first time writing to it or in other words a clean slate.
Breakdown:
1) write to RAM
2) read from Ram
3) set all ram values back to 0? or can I just go ahead and provide address = 0 begin writing from 0-23 again?
Here is my Ram:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
entity Ram is
Port(
clk : in std_logic;
address : in std_logic_vector(4 downto 0);
write_en : in std_logic;
data_in : in std_logic_vector(15 downto 0);
data_out : out std_logic_vector(15 downto 0)
);
end Ram;
architecture Behavioral of Ram is
type ram_type is array(0 to 23) of std_logic_vector(15 downto 0);
signal Memory : ram_type;
begin
process(clk)
begin
if(rising_edge(clk)) then
if(write_en = '1') then
Memory(to_integer(unsigned(address))) <= data_in;
end if;
data_out <= Memory(to_integer(unsigned(address)));
end if;
end process;
end behavioral;
If you are intending to infer BRAMs in your device it cannot be reset. reset BRAMs is done as part of device configuration. You can always write zeroes (or whetever your initial state is back to the Memory to reinitialize)
However, if you don't care whether it will be synthesized into BRAMs I think the most clean way of doing this is adding a reset port to your system and change your process to take the reset into account. When you want to reset the memory you apply a reset at the input port.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
entity Ram is
Port(
clk : in std_logic;
rstn : in std_logic;
address : in std_logic_vector(4 downto 0);
write_en : in std_logic;
data_in : in std_logic_vector(15 downto 0);
data_out : out std_logic_vector(15 downto 0)
);
end Ram;
architecture Behavioral of Ram is
type ram_type is array(0 to 23) of std_logic_vector(15 downto 0);
signal Memory : ram_type;
begin
process(clk)
begin
if(rising_edge(clk)) then
if(rstn ='0') then
Memory <= (OTHERS => (OTHERS => '0'));
elsif(write_en = '1') then
Memory(to_integer(unsigned(address))) <= data_in;
end if;
data_out <= Memory(to_integer(unsigned(address)));
end if;
end process;
end behavioral;
An additional remark on your code example. If you intend to infer BRAMs your code is "read-before-write". This will result in slower BRAM performance according to WP231 (https://www.xilinx.com/support/documentation/white_papers/wp231.pdf)
I have spent the whole day trying to solve the following problem. I am building a small averaging multichannel oscilloscope and I have the following module for storing the signal:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use IEEE.numeric_std.all;
entity storage is
port
(
clk_in : in std_logic;
reset : in std_logic;
element_in : in std_logic;
data_in : in std_logic_vector(11 downto 0);
addr : in std_logic_vector(9 downto 0);
add : in std_logic; -- add = '1' means add to RAM
-- add = '0' means write to RAM
dump : in std_logic;
element_out : out std_logic;
data_out : out std_logic_vector(31 downto 0)
);
end storage;
architecture rtl of storage is
component bram is
port
(
clk : in std_logic;
we : in std_logic;
en : in std_logic;
addr : in std_logic_vector(9 downto 0);
di : in std_logic_vector(31 downto 0);
do : out std_logic_vector(31 downto 0)
);
end component bram;
type state is (st_startwait, st_add, st_write);
signal current_state : state := st_startwait;
signal next_state : state := st_startwait;
signal start : std_logic;
signal we : std_logic;
signal en : std_logic;
signal di : std_logic_vector(31 downto 0);
signal do : std_logic_vector(31 downto 0);
signal data : std_logic_vector(11 downto 0);
begin
ram : bram port map
(
clk => clk_in,
we => we,
en => en,
addr => addr,
di => di,
do => do
);
process(clk_in, reset, start)
begin
if rising_edge(clk_in) then
if (reset = '1') then
current_state <= st_startwait;
else
start <= '0';
current_state <= next_state;
if (element_in = '1') then
start <= '1';
end if;
end if;
end if;
end process;
process(current_state, start, dump)
variable acc : std_logic_vector(31 downto 0);
begin
element_out <= '0';
en <= '1';
we <= '0';
case current_state is
when st_startwait =>
if (start = '1') then
acc(11 downto 0) := data_in;
acc(31 downto 12) := (others => '0');
next_state <= st_add;
else
next_state <= st_startwait;
end if;
when st_add =>
if (add = '1') then
acc := acc + do;
end if;
we <= '1';
di <= acc;
next_state <= st_write;
when st_write =>
if (dump = '1') then
data_out <= acc;
element_out <= '1';
end if;
next_state <= st_startwait;
end case;
end process;
end rtl;
Below is the BRAM module as copied from the XST manual. This is a no-change type of BRAM and I believe there is the problem. The symptom is that, while this simulates fine, I read only zeroes from the memory when I use the design on the device.
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity bram is
port
(
clk : in std_logic;
we : in std_logic;
en : in std_logic;
addr : in std_logic_vector(9 downto 0);
di : in std_logic_vector(31 downto 0);
do : out std_logic_vector(31 downto 0)
);
end bram;
architecture rtl of bram is
type ram_type is array (0 to 999) of std_logic_vector (31 downto 0);
signal buf : ram_type;
begin
process(clk, en, we)
begin
if rising_edge(clk) then
if en = '1' then
if we = '1' then
buf(conv_integer(addr)) <= di;
else
do <= buf(conv_integer(addr));
end if;
end if;
end if;
end process;
end rtl;
What follows is a description of the chip use and the expected output. "clk_in" is a 50 MHz clock. "element_in" is '1' for 20 ns and '0' for 60 ns. "addr_in" iterates from 0 to 999 and changes every 80 ns. "element_in", "data_in", and "addr" are all aligned and synchronous. Now "add" is '1' for 1000 elements, then both "add" and "dump" are zero for 8000 elements and, finally "dump" is '1' for 1000 elements. Now, if I have a test bench that supplies "data_in" from 0 to 999, I expect data_out to be 0, 10, 20, 30, ..., 9990 when "dump" is '1'. That is according to the simulation. In reality I get 0, 1, 2, 3, ..., 999....
Some initial issues to address are listed below.
The process(current_state, start, dump) in storage entity looks like it is
intended to implement a combinatorial element (gates), but the signal (port)
data_in is not in the sensitivity list.
This is very likely to cause a difference between simulation and synthesis
behavior, since simulation will typically only react to the signals in the
sensitivity list, where synthesis will implement the combinatorial design and
react on all used signals, but may give a warning about incomplete sensitivity
list or inferred latches. If you are using VHDL-2008 then use can use a
sensitivity list of (all) to have the process sensitivity to all used
signals, and otherwise you need to add missing signals manually.
The case current_state is in process(current_state, start, dump) lacks an
when others => ..., so the synthesis tool has probably given you a warning
about inferred latches. This should be fixed by adding the when others =>
with and assign all signals driven by the process to the relevant value.
The use clause lists:
use IEEE.std_logic_unsigned.all;
use IEEE.numeric_std.all;
But both of these should not be used at the same time, since they declare some
of the same identifiers, for example is unsigned declared in both. Since the
RAM uses std_logic_unsigned I suggest that you stick with that only, and
delete use of numeric_std. For new code I would though recommend use of
numeric_std.
Also the process(clk_in, reset, start) in storage entity implements a
sequential element (flip flop) sensitive to only rising edge of clk_in, so
the two last signals in sensitivity list ..., reset, start) are unnecessary,
but does not cause a problem.
I want to use four push buttons as inputs and three seven-segment LED displays as outputs. Two push buttons should step up and down through the sixteen RAM locations; the other two should increment and decrement the contents of the currently-displayed memory location. I have the following two entities:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity DE2_TOP is
port (
KEY : in std_logic_vector(3 downto 0); -- Push button
CLOCK_50: in std_logic;
);
end DE2_TOP;
architecture datapath of DE2_TOP is
begin
U1: entity work.lab1 port map (
key => key,
clock => clock_50,
);
end datapath;
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity raminfr is -STANDARD RAM INFERENCE
port (
clock: in std_logic;
we : in std_logic;
a : in unsigned(3 downto 0);
di : in unsigned(7 downto 0);
do : out unsigned(7 downto 0)
);
end raminfr;
architecture rtl of raminfr is
type ram_type is array (0 to 15) of unsigned(7 downto 0);
signal RAM : ram_type;
signal read_a : unsigned(3 downto 0);
begin
process (clock)
begin
if rising_edge(clock) then
if we = '1' then
RAM(to_integer(a)) <= di;
end if;
read_a <= a;
end if;
end process;
do <= RAM(to_integer(read_a));
end rtl;
and
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity lab1 is
port(
clock : in std_logic;
key : in std_logic_vector(3 downto 0);
);
end lab1;
architecture up_and_down of lab1 is
signal value_in_ram : unsigned(7 downto 0);
signal we : std_logic;
signal value_counter : unsigned(7 downto 0) ;
signal register_counter : unsigned(3 downto 0);
begin
U1: entity work.raminfr port map (
a => register_counter,
di => value_counter,
do => value_in_ram,
clock => clock,
we => we
);
process(clock)
begin
if rising_edge(clock) then
if (key(3)='0' and key(2)='0' and key(1)='1' and key(0)='0') then
value_counter <= value_counter + "1";
elsif (key(3)='0' and key(2)='0' and key(1)='0' and key(0)='1') then
value_counter <= value_counter - "1";
elsif (key(3)='1' and key(2)='0' and key(1)='0' and key(0)='0') then
register_counter<= register_counter + "1";
value_counter <= value_in_ram;
elsif (key(3)='0' and key(2)='1' and key(1)='0' and key(0)='0') then
register_counter<= register_counter - "1";
value_counter <= value_in_ram;
end if;
end if;
end process;
end architecture up_and_down;
I also have the following test bench, where I try to simulate buttons being pressed via KEY:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity DE2_TOP_TEST is
end;
architecture BENCH of DE2_TOP_TEST is
signal KEY : std_logic_vector(3 downto 0);
signal CLOCK_50 : std_logic := '0';
signal hex4, hex5, hex6 : std_logic_vector(6 downto 0);
begin
clock_50 <= not clock_50 after 50 ns;
process
begin
KEY<="0010";
wait for 1 us;
KEY<="0000";
end process;
uut:work.DE2_TOP port map (
KEY=>key,
CLOCK_50=>clock_50,
hex4=>hex4,
hex5=>hex5,
hex6=>hex6
);
end BENCH;
My test bench set up looks like this:
To simulate, I compile all three of the above files, and then simulate DE2_TOP_TEST, but am met with the result that my "KEY" is still undefined, as below (although CLOCK_50 does get the default value that I set):
Anyone know what's causing this?
(1) You have unconnected ports on the entity you are typing to test. The test results are as expected for those inputs - specifically, clk, being undriven.
(2) Having connected clk, you will need to drive it.
signal clk : std_logic := '0';
and
clk <= not clk after 50 ns;
should give a 10MHz clock, check this in the simulator
(3) Drive "KEY" with a specific sequence of values
subtype keys is std_logic_vector(3 downto 0);
constant count_up : keys := "0001";
constant count_dn : keys := "0010";
constant idle : keys := "0000";
-- etc
process
begin
KEY <= count_up;
wait for 1 us;
KEY <= idle;
wait for ...
-- etc
end process;
(4) Bring the OUTPUTS back out into the testbench so that you can check their values. You need to bring them out as ports in the top level (design) entity anyway, if you are going to connect them to a display!
Then (later, once things have started going to plan) you can test them in the testbench process...
wait for 100 ns;
-- after the last press, we should have "07" on the display
assert digit(1) = "0111111" report "Left digit has wrong value" severity ERROR;
assert digit(0) = "0000111" report "Left digit has wrong value" severity ERROR;
A self-checking testbench like this saves debugging by staring at waveforms. You only need the waveforms when the tests are failing...