I am designing a system that has two separate counters performing simultaneously that both output a 4-bit binary signal to a set of 4 LEDs. One counter's output is always being displayed by the LEDs while the other counter is still counting (just without displaying an output to the LEDs). The toggle is to be activated by a single button press that will switch the output showing on the LEDs from one counter to the other.
I do not know where to even begin including this function in my design. I am not sure if I could include the logic into my top level file and toggle which signal is sent to the LEDs (I am not even sure if this is possible) or if I could include the logic necessary into the counter files. My wrapper file for the program is located below, showing the instantiation of the top level component. The outputs of the counters are tied to the same set of LEDs, one counter has the output of oQ1 and the other oQ2.
component top_level is
Port ( cnt_tog :in STD_LOGIC;
iReset : in STD_LOGIC;
iUp : in STD_LOGIC;
iClk : in STD_LOGIC;
iCnt_en : in STD_LOGIC;
-- oQ1 : out STD_LOGIC_vector(3 downto 0)
oQ2 : out STD_LOGIC_vector(3 downto 0)
);
end component;
BEGIN
-- INSTANTIATION OF THE TOP LEVEL COMPONENT
Inst_top_level: top_level
port map(
cnt_tog => BTN(3),
iReset => BTN(0),
iClk => clk,
iCnt_en => BTN(2),
iUp => BTN(1),
-- oQ1 => LD(3 downto 0)
oQ2 => LD(3 downto 0)
);
END structural;
Related
First I would like to mention that I'm still new to the VHDL World so please bear with me.
Currently, I'm working on an SPI project where I created a generic master module that can send and receive different data widths ranging from 8 to 64 bits. Everything is working fine in my testbench regarding sending and receiving data between the master and the slave.
P.S. The master is synthesizable while the slave is just for simulation purposes.
In the testbench I instantiated many DUTs from the master and the slave, for instance, I created DUT_00 for testing 8bit data width, DUT_01 for 11bit data with, etc. As shown below:
Signal declaration for DUT_00 in my testbench
---------------------------------------------------------------------------------------------------------------------
-- DUT0 Signals
---------------------------------------------------------------------------------------------------------------------
constant data_width_8bit : positive range 8 to 64 := 8; --! data width from the master to the slave
--shared variable s_data_width : positive range 8 to 64 := data_width_00; --! data width from the master to the slave
constant bw_g : positive range 8 to 24 := 24; --! width of baud rate configuration port cbr_i
constant inv_g : natural range 0 to 1 := 0; --! 0: master and slave sample on same edge, 1: master samples on opposite edge as slave
signal clk_tb : std_logic:= '0'; --! system clock
signal rst_tb : std_logic:= '0'; --! system reset synchronous, high activsen_i
signal cbr_0tb :std_logic_vector(bw_g-1 downto 0):= x"00_0001"; --! clock baud rate configuration
signal cpol_0tb :std_logic:= '0'; --! clock polarity selection
signal cpha_0tb :std_logic :='0'; --! clock phase selection
signal sen_0tb :std_logic:='0'; --! slave enable : 1 => slave enabled, 0 => slave disabled
signal sts_0tb :std_logic:='0'; --! slave transfer start (unit pulse)
signal sbusy_0tb :std_logic; --! slave status: 1 => SPI transaction ongoing, 0 => idle
signal stv_0tb :std_logic; --! slave transfer valid (unit pulse)
signal dts_0tb :std_logic_vector(data_width_8bit-1 downto 0):= (others => '0'); --! parallel data to slave
signal dfs_0tb :std_logic_vector(data_width_8bit-1 downto 0); --! parallel data from slave
signal ss_0tb :std_logic; --! slave selection
signal spi_clk_0tb :std_logic; --! master clock
signal mosi_0tb :std_logic; --! serial data to slave (Master Output Slave Input)
signal miso_0tb :std_logic; --! serial data from slave (Master Input Slave Output)
---------------------------------------------------------------------------------------------------------------------
-- Slave Signals
---------------------------------------------------------------------------------------------------------------------
signal dfm_0tb :std_logic_vector(data_width_8bit-1 downto 0); --! parallel data from master
signal dfm_val_0tb :std_logic; --! valid pulse for data from master
signal dtm_0tb :std_logic_vector(data_width_8bit-1 downto 0):= (others => '0'); --! parallel data to master
signal busy_tx_0tb :std_logic; --! slave busy,Do not write data while high
signal dtm_val_0tb :std_logic; --! valid pulse for data to the master
signal sum_0tb :std_logic_vector(data_width_8bit-1 downto 0):= (others => '0'); --! bit counter for the data to the master
DUT_00 instantiation
DUT_Gen: for i in 0 to 4 generate
--! #brief instantiation of SPI master entity
DUT_00: if i = 0 generate
master_00: entity work.SPI_MASTER(rtl_SPI_MASTER)
generic map (
nb_g => data_width_8bit,
bw_g => bw_g,
inv_g => inv_g)
-- Master Ports Mapping
port map(
-------------------------------Master I/O pins------------------------------------------------------
clk_i => clk_tb,
rst_i => rst_tb,
-- HOST IF
cbr_i => cbr_0tb,
cpol_i => cpol_0tb,
cpha_i => cpha_0tb,
-- Control
sen_i => sen_0tb,
sts_i => sts_0tb,
sbusy_o => sbusy_0tb ,
stv_o => stv_0tb,
-- Data
dts_i => dts_0tb,
dfs_o => dfs_0tb,
-- SPI IF
spi_ss_o => ss_0tb,
spi_clk_o => spi_clk_0tb,
spi_mosi_o => mosi_0tb,
spi_miso_i=> miso_0tb );
slave_00: entity work.SPI_SLAVE(beh_SPI_SLAVE)
generic map (
nb_g => data_width_8bit
-- bw_g => bw_g
)
-- Slave Ports Mapping
port map(
-------------------------------Slave I/O pins------------------------------------------------------
clk_i => clk_tb,
rst_i => rst_tb,
cpol_i => cpol_0tb,
cpha_i => cpha_0tb,
sck_i => spi_clk_0tb,
mosi_i => mosi_0tb,
miso_o => miso_0tb,
cs_i => ss_0tb,
dfm_o => dfm_0tb,
dfm_val_o => dfm_val_0tb,
dtm_i => dtm_0tb,
busy_tx_o => busy_tx_0tb,
dtm_val_o => dtm_val_0tb,
sum_o => sum_0tb
-- sck_frq_o => sck_frq_0tb
);
end generate DUT_00;
DUT_01 instanstation
--! #brief instantiation of SPI master entity
DUT_01: if i = 1 generate
master_01: entity work.SPI_MASTER(rtl_SPI_MASTER)
generic map (
nb_g => data_width_11bit,
bw_g => bw_g,
inv_g => inv_g)
-- Master Ports Mapping
port map(
-------------------------------Master I/O pins------------------------------------------------------
clk_i => clk_tb,
rst_i => rst_tb,
-- HOST IF
cbr_i => cbr_1tb,
cpol_i => cpol_1tb,
cpha_i => cpha_1tb,
-- Control
sen_i => sen_1tb,
sts_i => sts_1tb,
sbusy_o => sbusy_1tb ,
stv_o => stv_1tb,
-- Data
dts_i => dts_1tb,
dfs_o => dfs_1tb,
-- SPI IF
spi_ss_o => ss_1tb,
spi_clk_o => spi_clk_1tb,
spi_mosi_o => mosi_1tb,
spi_miso_i=> miso_1tb );
slave_01: entity work.SPI_SLAVE(beh_SPI_SLAVE)
generic map (
nb_g => data_width_11bit
-- bw_g => bw_g
)
-- Slave Ports Mapping
port map(
-------------------------------Slave I/O pins------------------------------------------------------
clk_i => clk_tb,
rst_i => rst_tb,
cpol_i => cpol_1tb,
cpha_i => cpha_1tb,
sck_i => spi_clk_1tb,
mosi_i => mosi_1tb,
miso_o => miso_1tb,
cs_i => ss_1tb,
dfm_o => dfm_1tb,
dfm_val_o => dfm_val_1tb,
dtm_i => dtm_1tb,
busy_tx_o => busy_tx_1tb,
dtm_val_o => dtm_val_1tb,
sum_o => sum_1tb
-- sck_frq_o => sck_frq_1tb
);
end generate DUT_01;
My first question is, instead of creating many DUTs for every different data width, how can I only use one DUT that can handle different data sizes also different baud rates?
Second, how can I make the slave detect the mode that has been used by the master when it sends data without telling the slave explicitly which Phase and polarity have been used?
Sorry if my question wasn't well-stated at the beginning.
Have you written a test plan for your SPI project? How many test cases are required to test a single data width of your SPI project? Once you determine that, you can decide how to solve the problem of having to test multiple data widths.
How many of your data widths do you want to test?
One approach is to create a testbench that instantiates a single SPI module and then use a configuration to specify the generic that sizes the SPI module. Your test cases would also need to have this generic so they could adapt what they do for different sizes.
Unfortunately when there are a large number of test cases, configurations tend to explode - meaning you end up with alot of them. Here the number of configurations you would need is #DataWidthsTested * #TestCases.
So if you restructure your testbench to separate your test cases from your test harness, you can instead create #DataWidthsTested variations of your test harness and have run each of the test cases against that.
If you would like a more detailed example of this, OSVVM has two variations of our verification components - AxiStreamTransmitter and AxiStreamTransmitterVti. They are the same inside. The only thing that is different is how the external connections are done. As a result, we create two separate directories for the test harnesses, testbench (which instantiates AxiStreamTransmitter) and testbenchVti (which instantiates AxiStreamTransmitterVti). Care is taken so that both instances have the same instance label and same port names.
The test cases are written in a way that either component can be used. There are 63 test cases. In our methodology we prefer to use configurations to run our test cases - that means we have 63 configurations. Note the configurations only select the test case to be run and not which version of the AxiStreamTransmitter to be use (it is left to default bind). We have a script that compiles and runs each test case.
At a higher level, we have a script that compiles (RunAllTests.pro vs RunAllTestsVti.pro) that calls the script to compile the test harness and then calls the script to compile and run the test cases. By putting each test harness in a separate library we are able to safely run each test case with the intended test harness.
For more see the OSVVM repository on GitHub. It starts at: https://github.com/OSVVM/OsvvmLibraries
It needs to be cloned recursively as there are submodules. The AxiStream examples are in the directory OsvvmLibraries/AXI4/AxiStream. To get started with OSVVM, see the README.rst which is displayed at the bottom of the page of https://github.com/OSVVM/Documentation
I have a VHDL module for a UART component which sends and receives serial data between an FPGA and PC. It currently works just fine. But how would I use this serial communication to interpret a 2-d matrix of integers in a text file sent from the PC to the FPGA?
More specifically once the text file is sent from the PC to the fpga, how would the 2-d array be stored in memory as such? I am not sure how to do this in vhdl
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity uart is
generic(
-- Default setting:
-- 19,200 baud, 8 data bis, 1 stop its, 2^2 FIFO
DBIT: integer:=8; -- # data bits
SB_TICK: integer:=16; -- # ticks for stop bits, 16/24/32
-- for 1/1.5/2 stop bits
DVSR: integer:= 326; -- baud rate divisor
-- DVSR = 100M/(16*baud rate)
DVSR_BIT: integer:=9; -- # bits of DVSR
FIFO_W: integer:=2 -- # addr bits of FIFO
-- # words in FIFO=2^FIFO_W
);
port(
clk, reset: in std_logic;
rd_uart, wr_uart: in std_logic;
rx: in std_logic;
w_data: in std_logic_vector(7 downto 0);
tx_full, rx_empty: out std_logic;
r_data: out std_logic_vector(7 downto 0);
tx: out std_logic
);
end uart;
architecture str_arch of uart is
signal tick: std_logic;
signal rx_done_tick: std_logic;
signal tx_fifo_out: std_logic_vector(7 downto 0);
signal rx_data_out: std_logic_vector(7 downto 0);
signal tx_empty, tx_fifo_not_empty: std_logic;
signal tx_done_tick: std_logic;
begin
baud_gen_unit: entity work.mod_m_counter(arch)
generic map(M=>DVSR, N=>DVSR_BIT)
port map(clk=>clk, reset=>reset,
q=>open, max_tick=>tick);
uart_rx_unit: entity work.uart_rx(arch)
generic map(DBIT=>DBIT, SB_TICK=>SB_TICK)
port map(clk=>clk, reset=>reset, rx=>rx,
s_tick=>tick, rx_done_tick=>rx_done_tick,
dout=>rx_data_out);
fifo_rx_unit: entity work.fifo(arch)
generic map(B=>DBIT, W=>FIFO_W)
port map(clk=>clk, reset=>reset, rd=>rd_uart,
wr=>rx_done_tick, w_data=>rx_data_out,
empty=>rx_empty, full=>open, r_data=>r_data);
fifo_tx_unit: entity work.fifo(arch)
generic map(B=>DBIT, W=>FIFO_W)
port map(clk=>clk, reset=>reset, rd=>tx_done_tick,
wr=>wr_uart, w_data=>w_data, empty=>tx_empty,
full=>tx_full, r_data=>tx_fifo_out);
uart_tx_unit: entity work.uart_tx(arch)
generic map(DBIT=>DBIT, SB_TICK=>SB_TICK)
port map(clk=>clk, reset=>reset,
tx_start=>tx_fifo_not_empty,
s_tick=>tick, din=>tx_fifo_out,
tx_done_tick=> tx_done_tick, tx=>tx);
tx_fifo_not_empty <= not tx_empty;
end str_arch;
UART is just a communication protocol and as such it is totally clueless about the meaning of the received data. What you can do is interpret the data on the fly instead of doing that later, but I would still advise you do that in a separate module.
The easiest way, if applicable, is knowing a priori the matrix size and/or moving the issue software-side in various flavors.
You can hardwire the known dimensions in your design (e.g. N-by-4 matrix format, hardwire 4 columns) to simplify stuff, but the most generic way of doing things is having the PC doing the work for you (if none of the dimensions is known a priori you cannot work out the size from the number of entries).
You could, e.g., instruct the PC to send something like this
NumberRows
NumberColumns
Value[0][0]
Value[0][1]
.
.
Value[NumberRows-1][NumberColumns-1]
Now you can just save everything you receive in memory and you know where to look at the number of rows and columns and proceed from there.
If you cannot make the PC send anything else than the pure text file, you will have a stream of ASCII characters you have to parse locally. My advice would be to design a module that stores anything up to the separator and upon detecting a separator starts the conversion from ASCII decimal to binary of whatever it has in the buffer, then saves it in memory. Upon separator it should also increment a counter so that when a newline arrives you know the number of columns, while on newline it should increment another counter so that on EOF you know the number of rows.
I want to get the Switch0 value to show on the LEDs.
Here's My Entity :
port(
switchA : in std_logic_vector(7 downto 0)
);
And here's my custom type:
type text_type is array (0 to 7) of std_logic_vector(63 downto 0);
signal text, nexttext, shiftedtext : text_type;
signal countertext, nextcountertext: std_logic_vector(15 downto 0);
I tried this code but it doesn't work!
if(button_n(0)='1')then
nextstate<=Finish;
countertext <= (0 to 7 => switchA , others => '0'); --- Get SwitchA Value!! ---
end if;
Here's a FPGA4U Board image : FPGA4U Board
And at the end, here's an example for enabling some LEDs
when names1 =>
nextstate<=test2;
nextcountertext<=(others=>'0');
nexttext <=("0000000000000000000000000000000000000000000000000000000000000000",
"0000000000000000000000000000000000000000000000000000000000000000",
"0000000000000000000000000000000000000000000000000000000000000000",
"0000000001111100011111110000111000100010000000000000000000000000",
"0000000000010000100010001001000100110010000000000000000000000000",
"0000000000010000100010001001111100101010000000000000000000000000",
"0000000000010000100010001001000100100110000000000000000000000000",
"0000000001111100100010001001000100100010000000000000000000000000");
-- This Code Show "IMAN" on The LEDs!!
Can anyone help me please? I'm really confused.
countertext is a signal that shows you which level(state) you are in;
Eg. if you are in "IMAN" text writing level(it's your first text), nextcountertext will be contertext+1 (=2), and in each level you can check the level you are in, and save the order of showing messages.
The following VHDL is to be used to test bench. I keep getting an error on the first wait statement during analysis : "wait statement must contain condition clause with UNTIL keyword" I have several working test benches written this way. I can't seem to find what the error might be.
`library IEEE;
USE IEEE.std_logic_1164.all;
entity case_ex_TB is end;
architecture simple_test of case_ex_TB is
--- DUT Component Declaration ---
component case_ex
port(
clk, rstN: IN std_logic;
color: OUT std_logic_vector(2 downto 0));
end component;
--- Signals Declaration ---
signal rst, clock: std_logic:='0';
signal color: std_logic_vector(2 downto 0);
begin
DUT: case_ex --- DUT instantiation ---
port map (clk => clock,
rstN => rst,
color => color);
--- Signal's Waves Creation ---
rst <= '1','0' after 50 ns, '1' after 2 us;
clock_crtate: process
begin
while rst = '0' loop
clock <= '1','0' after 50 ns;
wait for 100 ns;
end loop;
clock <= '1';
wait;
end process;
end simple_test;`
You get this error because you have set your testbench as the top-level entity in Quartus-II. The top-level entity must remain the component case_ex, and this component must contain synthesizable code.
To simulate your testbench, you must configure a testbench. Just klick on the plus-sign before "RTL Simulation" and then "Edit Settings". (Names may differ with Quartus version).
Another thing you could note is that, it's necessary to put this file in as a simulation, following the path:
Assignments -> settings -> EDA tool settings -> simulation
and naturally, changing adding a testbench.
Another thing to note is that, if you want to change the top level entity, you just need to follow in Quartus:
Project -> Set as top level entity (in the file you are in)
Also, in the Project navigator, be sure that don't miss the fact that you need every single file you need in order for your program to work.
I want to describe an entity that can either function normally or be put in a test mode. The general design I have is a top level entity that wraps the "real" entity and a test entity.
I am trying to figure out the best way to express this in VHDL, but I get the feeling I'm overcomplicating things.
Consider a small top-level entity (realistically, there are many more I/Os):
entity toplevelobject is
port (
in1 : inout std_logic;
in2 : inout std_logic;
out1 : out std_logic;
out2 : out std_logic;
testline : in std_logic;
testclk : in std_logic;
);
end toplevelobject;
This is supposed to switch between the real functionality and the test mode depending on the state of "testline" (high means test). Note that the test module actually uses everything but clk as an output, even in_*.
architecture test_passthrough of toplevelobject is
-- This is the actual module
component real_module
port (
in1 : in std_logic;
in2 : in std_logic;
out1 : out std_logic;
out2 : out std_logic;
clk : in std_logic;
-- Note absence of "testline"
);
end component;
-- This is the test module, which will just put the clk
-- signal out on all pins, or play a tune, or something
component test_module
port (
in1 : out std_logic;
in2 : out std_logic;
out1 : out std_logic;
out2 : out std_logic;
testclk : in std_logic;
-- Note absence of "testline"
);
end component;
signal real_in1, real_in2 : std_logic;
signal real_out1, real_out2 : std_logic;
signal test_in1, test_in2 : std_logic;
signal test_out1, test_out2 : std_logic;
begin
real_0 : real_module port map (
in1 => real_in1,
in2 => real_in2,
out1 => real_out1,
out2 => real_out2,
clk => clk,
);
test_0 : test_module port map (
in1 => test_in1,
in2 => test_in2,
out1 => test_out1,
out2 => test_out2,
testclk => clk,
);
-- Ports that are outputs on both don't need
-- much special attention
out1 <= real_out1 when testline = '0' else test_out1;
out2 <= real_out2 when testline = '0' else test_out2;
end test_passthrough;
So I have a few questions:
For the inout ports, should I have one big process with a case ... when statement that switches on testline? Or a process for each I/O with an if statement? Theoretically I figure that many smaller processes are executed concurrently instead of sequentially, but will it actually make a difference to simulation or synthesis? For example:
passthrough_in1 : process(testline, in1, test_in1) is
begin
if testline = '0' then
real_in1 <= in1;
else
in1 <= test_in1;
end if;
end process passthrough_in1;
...vs...
passthrough_all : process(in1, test_in1, in2, test_in2, testline) is
case testline is
when '0' =>
real_in1 <= in1;
real_in2 <= in2;
when '1' =>
in1 <= test_in1;
in2 <= test_in2;
end case;
end process passthrough_all;
Is this a sane approach or is there something simpler?
I'm confused about sensitivity — do I need passthrough_in1 (or even passthrough_all to be sensitive to anything other than testline?
Do I need the real_in1/test_in1 to select between the two wrapped entities? Or is there another way to say "if testline is high, connect test_module output in_1 to the toplevelobject I/O in_1?
If I understand you correctly your testmodule drives the (badly named - I assume in the real code they make more sense :) in1,2 ports?
If so, you need to do something like this:
real_in1 <= in1;
in1 <= test_in1 when testline = '1' else 'Z';
That way in non-test-mode the in1 signal will be driven by a 'Z', so the external proper in1 signal can override it.
You can represent this in various other ways (like the processes that you described), all of which should come out being equal in the simulator. The downside of the "all in one process" option is that you'll need to keep what might end up as an enormous sensitivity list up to date. Doing it one process per signal is just a long winded way of what I did above.
To save some code and copy/paste effort, you could potentially push those two lines of code into an entity of their own and then instance it many times - in that case, I'd put the instance and port map all on one line, but that would offend some coding standards...
This all assumes I've understood the problem correctly!
Maybe I don't fully understand what you're trying to do, but in a typical VHDL testbench:
Your "real_module" code is left as it is. No changes are made to it when it is tested.
A second module, akin to your "toplevelobject" is made. This is typically called a testbench module.
The toplevelobject testbench instantiates real_module.
The testbench usually has no inputs, and doesn't really need outputs (depending on the situation and the testing software used).
The testbench has sequential logic that drives the inputs of real_module.
If you're using testing software such as ModelSim, the inputs and outputs of real_module can be plotted over time to watch the behaviour of real_module as it is driven by your testbench.
What software are you using? I can dig up an old testbench example from a university project a couple of years ago if it would be of any help to you.