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.
Related
The logic gate in the RTL view was a latch previously. As an answer suggests, I assign each input with outputs. And the latch turns into a logic gate. I don't know whether it is a correct way to solve the problem. There is also an adder connected to the counter.
I want to eliminate the adder and the logic gate. (??? T^T).
What should I modify?
library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use IEEE.std_logic_unsigned.all;
entity mux8x1 is port( input: in std_logic_vector( 7 downto 0); clk: in std_logic; --s: buffer std_logic; --rst : in std_logic; --d: buffer std_logic; q: out std_logic_vector (7 downto 0) --o: buffer std_logic_vector (3 downto 0) ); end mux8x1;
architecture mux of mux8x1 is signal count : std_logic_vector(3 downto 0);
--signal count_state: std_logic_vector (3 downto 0); signal serial: std_logic;
--shiftregister
signal internal: std_logic_vector (7 downto 0); signal d: std_logic;
begin --【The counter】 process(clk) --variable internal: std_logic_vector (7 downto 0); --variable d: std_logic; --variable initial: std_logic_vector (7 downto 0) :="01010101";
begin
if (clk'event and clk = '1') then
count <= count + 1;
end if;
end process;
--count_state <= count; --To divide the counter
--section1 for the counter --8x1 multiplxer combined with counter
process(count,input,clk) --variable serialin: std_logic; begin --serialin:='0'; if (count(3) <='0') then case count(2 downto 0) is --8 possible states for PToS
when "000"=> serial <=input(0);
when "001"=> serial <=input(1);
when "010"=> serial <=input(2);
when "011"=> serial <=input(3);
when "100"=> serial <=input(4);
when "101"=> serial <=input(5);
when "110"=> serial <=input(6);
when "111"=> serial <=input(7);
when others => serial <= '0'; end case; else serial <='0';
end if; --serial<=serialin; end process;
-- end if; end mux;
The following is the RTL viewer.
enter image description here
The reason that you get a latch, is because you do not apply a signal value to "serial" in any case when the process is started: Then "serial" keeps its old value which leads to a latch at synthesis, where this kept value is taken from.
So it is a good idea to assign a default value to any signal you assign values to in a process.
When you want to get a register (triggered by a clock edge) you must use a process which is only sensitive to a clock signal (and a reset signal) and uses as a condition "rising_edge(clk)". Of course you do not need a default assignment here.
I'm trying to do a circuit consisting of a 2 to 1 multiplexer (8-bit buses), an 8-bit register and an 8-bit adder. These components are all tested and work as expected.
The thing is: if I try to send the output of the Adder to one of the inputs of the
multiplexer (as seen in the image by the discontinued line), the simulation will stop rather suddenly. If I don't do that and just let ain do its thing, everything will run just as it should, but I do need the output of the adder to be the one inputted to the multiplexer.
The simulation is the following:
The code is:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity Sumitas is
port (m : in STD_LOGIC;
clk : in STD_LOGIC;
ain : in STD_LOGIC_VECTOR (7 downto 0);
Add : out STD_LOGIC_VECTOR (7 downto 0));
end Sumitas;
architecture rtl of Sumitas is
component Adder8bit
port (a, b : in STD_LOGIC_VECTOR (7 downto 0);
Cin : in STD_LOGIC;
S : out STD_LOGIC_VECTOR (7 downto 0);
Cout : out STD_LOGIC);
end component;
component GenericReg
generic (DataWidth : integer := 8);
port (en : in STD_LOGIC;
dataIn : in STD_LOGIC_VECTOR (DataWidth - 1 downto 0);
dataOut : out STD_LOGIC_VECTOR (DataWidth - 1 downto 0));
end component;
component GenericMux2_1
generic (DataWidth : integer := 8);
port (a, b : in STD_LOGIC_VECTOR (DataWidth - 1 downto 0);
Z : in STD_LOGIC;
S : out STD_LOGIC_VECTOR (DataWidth - 1 downto 0));
end component;
constant DW : integer := 8;
signal AddOut_s, MuxOut_s : STD_LOGIC_VECTOR (7 downto 0);
signal PCOut_s : STD_LOGIC_VECTOR (7 downto 0);
begin
m0 : GenericMux2_1
generic map (DataWidth => DW)
port map (a => "00000000",
b => AddOut_s,
Z => m,
S => MuxOut_s);
PC : GenericReg
generic map (DataWidth => DW)
port map (en => clk,
dataIn => MuxOut_s,
dataOut => PCOut_s);
Add0 : Adder8bit
port map (a => "00000001",
b => PCOut_s,
Cin => '0',
S => AddOut_s,
Cout => open);
Add <= AddOut_s;
end rtl;
and the testbench:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity bm_Sumitas is
end bm_Sumitas;
architecture benchmark of bm_Sumitas is
component Sumitas
port (m : in STD_LOGIC;
clk : in STD_LOGIC;
ain : in STD_LOGIC_VECTOR (7 downto 0);
Add : out STD_LOGIC_VECTOR (7 downto 0));
end component;
signal clk_s, m_s : STD_LOGIC;
signal Add_s, ain_s : STD_LOGIC_VECTOR (7 downto 0);
constant T : time := 2 ns;
begin
benchmark : Sumitas
port map (m => m_s,
clk => clk_s,
ain => ain_s,
Add => Add_s);
clk_proc: process
begin
clk_s <= '0';
wait for T/2;
clk_s <= '1';
wait for T/2;
end process;
bm_proc : process
begin
m_s <= '0';
wait for 10 ns;
m_s <= '1';
wait for 100 ns;
end process;
ains_proc : process
begin
ain_s <= "00001111";
for I in 0 to 250 loop
ain_s <= STD_LOGIC_VECTOR(TO_UNSIGNED(I, ain_s'length));
wait for T;
end loop;
end process;
end benchmark;
How can I do the thing I want? I'm ultimately trying to simulate a computer I designed. I have every component already designed and I'm coupling them together.
Constructing a Minimal, Complete, and Verifiable example requires filling in the missing components:
library ieee;
use ieee.std_logic_1164.all;
entity Adder8bit is
port (a, b : in STD_LOGIC_VECTOR (7 downto 0);
Cin : in STD_LOGIC;
S : out STD_LOGIC_VECTOR (7 downto 0);
Cout : out STD_LOGIC);
end entity;
architecture foo of adder8bit is
signal sum: std_logic_vector (9 downto 0);
use ieee.numeric_std.all;
begin
sum <= std_logic_vector ( unsigned ('0' & a & cin) +
unsigned ('0' & b & cin ));
s <= sum(8 downto 1);
cout <= sum(9);
end architecture;
library ieee;
use ieee.std_logic_1164.all;
entity GenericReg is
generic (DataWidth : integer := 8);
port (en : in STD_LOGIC;
dataIn : in STD_LOGIC_VECTOR (DataWidth - 1 downto 0);
dataOut : out STD_LOGIC_VECTOR (DataWidth - 1 downto 0));
end entity;
architecture fum of genericreg is
begin
dataout <= datain when en = '1';
end architecture;
with behavioral model substitutes.
(It's not that much work, copy the component declarations paste them, substitute entity for component and add the reserved word is, followed by simple behaviors in architectures.)
It reproduces the symptom you displayed in your simulation waveform:
You can see the essential point of failure occurs when the register enable (ms_s) goes high.
The simulator will report operation on it's STD_OUTPUT:
%: make wave
/usr/local/bin/ghdl -a bm_sumitas.vhdl
/usr/local/bin/ghdl -e bm_sumitas
/usr/local/bin/ghdl -r bm_sumitas --wave=bm_sumitas.ghw --stop-time=40ns
./bm_sumitas:info: simulation stopped #11ns by --stop-delta=5000
/usr/bin/open bm_sumitas.gtkw
%:
Note the simulation stopped at 11 ns because of a process executing repeatedly in delta cycles (simulation time doesn't advance).
This is caused by a gated relaxation oscillator formed by the enabled latch, delay (a delta cycle) and having at least one element of latch input inverting each delta cycle.
The particular simulator used has a delta cycle limitation, which will quit simulation when 5,000 delta cycles occur without simulation time advancing.
The genericreg kept generating events with no time delay in assignment, without an after clause in the waveform, after 0 fs (resolution limit) is assumed.
Essentially when the enable is true the signal will have at least one element change every simulation cycle due to the increment, and assigns the signal a new value for at least one element each simulation cycle without allowing the advancement of simulation time by not going quiescent.
You could note the simulator you used should have produced a 'console' output with a similar message if it were capable (and enabled).
So how it this problem cured? The easiest way is to use a register (not latch) sensitive to a clock edge:
architecture foo of genericreg is
begin
dataout <= datain when rising_edge(en);
end architecture;
Which gives us the full simulation:
I have the following input signal:
addr : IN STD_LOGIC_VECTOR(9 DOWNTO 0);
As far as I know, this means that addr(9) is the most significant bit.
But when run a simulation and assign, say, 128 to it, I get the following:
0(9) 0(8) 0(7) 0(6) 0(5) 0(4) 0(3) 1(2) 0(1) 0(0)
Meaning that the most significant bit is actually addr(0).
The assignment is done through simulation via vector waveform, in Quartus 9.1. I assign an arbitrary value to it.
Here is part of the .vhd file, where I use this:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
ENTITY ram_256x4B IS
PORT(clk, wr_en : IN STD_LOGIC; -- clock, write control signal
addr : IN STD_LOGIC_VECTOR(9 DOWNTO 0); -- read and write addresses
d : IN STD_LOGIC_VECTOR(31 DOWNTO 0); -- data to be written
q : OUT STD_LOGIC_VECTOR(31 DOWNTO 0)); -- memory read output
END ram_256x4B;
ARCHITECTURE comportamental OF ram_256x4B IS
SIGNAL addr_validation_bits : STD_LOGIC;
BEGIN
addr_validation_bits <= addr(9) & addr(8);
END comportamental;
If the valued of addr is 2, I expect addr(9) and addr(8) to be both 0, but instead they are 0 and 1, respectively.
This assigns a STD_LOGIC_VECTOR with 128.
architecture ...
signal addr : STD_LOGIC_VECTOR(9 downto 0);
begin
addr <= std_logic_vector(to_unsigned(128, addr'length));
end;
addr(7) is '1', all other bits are '0'.
I'm trying to connect my FPGA with my laptop using the serial protocol. For that purpose, I implemented the UART protocol on the FPGA side.
The connection between the FPGA and the Laptop is done with the UART-TTL to USB converter. I Get the wrong frame on the Laptop side.
Thus, I analyse my frame continuously using a logic analyzer, I observed that the frame sent wasn't stable, i.e sometimes a wrong frame is received instead of the one sent.
Below is the code for the serial core :
library ieee ;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity TX is
port(
CLK: in std_logic;
START: in std_logic;
BUSY : out std_logic;
DATA: in std_logic_vector(7 downto 0);
TX_LINE: out std_logic
);
end TX;
architecture MAIN of TX is
signal PRSCL : integer range 0 to 5208:=0;
signal index : integer range 0 to 9:=0;
signal DATAFLL : std_logic_vector (9 downto 0);
signal TX_FLAG: STD_LOGIC:='0';
begin
process(CLK)
begin
if(CLK'EVENT and CLK='1') then
if(TX_FLAG='0' and START='1') then
TX_FLAG<='1';
BUSY<='1';
DATAFLL(0)<='0';
DATAFLL(9)<='1';
DATAFLL(8 downto 1)<=DATA;
TX_LINE<='1';
end if;
-- send data , 50MHz /9600=5208 (9600: the baudrate)
IF(TX_FLAG='1') then
IF (PRSCL <5207) then
PRSCL<=PRSCL+1;
else
PRSCL<=0;
end if;
IF(PRSCL=2600)THEN
TX_LINE<=DATAFLL(INDEX);
IF(INDEX<9)THEN
INDEX<=INDEX+1;
ELSE
TX_FLAG<='0';
BUSY<='0';
INDEX<=0;
END IF;
END IF;
END IF;
END IF;
end process ;
end MAIN;
The control unit to instantiate the serial core is below :
library ieee ;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity UART is
port (
CLOCK_50: in std_logic;
SW: in std_logic_vector(3 downto 0);
KEY: in std_logic_vector(1 downto 0);
LEDG : out std_logic_vector (7 downto 0);
UART_TXD : out std_logic;
UART_RXD: in std_logic
);
end UART ;
ARCHITECTURE MAIN OF UART IS
SIGNAL TX_DATA: STD_LOGIC_VECTOR(7 downto 0);
SIGNAL TX_START: STD_LOGIC:='0';
SIGNAL TX_BUSY: STD_LOGIC:='0';
SIGNAL RX_DATA: STD_LOGIC_VECTOR(7 DOWNTO 0);
SIGNAL RX_BUSY: STD_LOGIC:='0';
COMPONENT TX
PORT(
CLK:IN STD_LOGIC;
START:IN STD_LOGIC;
BUSY:OUT STD_LOGIC;
DATA: IN STD_LOGIC_VECTOR(7 downto 0);
TX_LINE:OUT STD_LOGIC
);
END COMPONENT TX;
BEGIN
C1: TX PORT MAP (CLOCK_50,TX_START,TX_BUSY,TX_DATA,UART_TXD);
--C2: RX PORT MAP (CLOCK_50,UART_RXD,RX_DATA,RX_BUSY);
PROCESS(CLOCK_50)
BEGIN
IF(CLOCK_50'EVENT AND CLOCK_50='1')THEN
IF(KEY(0)='1' AND TX_BUSY='0')THEN -- Key(0)='0' MEAN that the key is pressed
TX_DATA<="0000" & SW(3 DOWNTO 0);
TX_START<='1';
LEDG<=TX_DATA;
ELSE
TX_START<='0';
TX_DATA<=(others=>'0') ;
END IF;
END IF;
END PROCESS;
END MAIN;
Thanks for you help.
Best regards,
Any asynchronous input have to be resynchronized before use, otherwise your circuit will become metastable and erratic behaviour will follow. On your top level, sw and key are asynchronous.
A synchronization circuit is typically 2 cascaded flip-flops, only the output of the second flip-flop should be used in your code:
...
signal sw_resync1 : std_logic_vector(3 downto 0);
signal sw_resync2 : std_logic_vector(3 downto 0);
signal key_resync1 : std_logic_vector(3 downto 0);
signal key_resync2 : std_logic_vector(3 downto 0);
begin
RESYNC: process(CLOCK_50)
begin
if (CLOCK_50'event and CLOCK_50 = '1') then
SW_resync1 <= SW;
SW_resync2 <= SW_resync1;
KEY_resync1 <= KEY;
KEY_resync2 <= KEY_resync1;
end if;
end process RESYNC;
...
IF(KEY_resync2(0)='1' AND TX_BUSY='0')THEN -- Key(0)='0' MEAN that the key is pressed
TX_DATA<="0000" & SW_resync2(3 DOWNTO 0);
...
You should also be aware that mechanical inputs (suck as sw and key) should be debounced or you will read several transitions for the same key stroke.
I am a fresh student and the assignment is to build 3 components with testbench and then to arrange them into one structure. All 3 components I have built work great but when I put them together one of the the outputs stays undefined. I tried to trace the signal called dat and it is fine, but probably I am not using correct syntax to assign the dat signal to data_out . The id_led_ind is the second output and it works fine but the data_out is undefined.
Here is the code (i think the problem is in lane 21 - "data_out <= dat")
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity peak_detect is
port(
input : in std_logic_vector (7 downto 0);
data_out : out std_logic_vector (7 downto 0);
reset : in std_logic;
clock : in std_logic;
enable : in std_logic;
id_led_ind : out std_logic);
end peak_detect;
architecture dataflow of peak_detect is
signal a_big_b : std_logic;
signal en : std_logic;
signal dat : std_logic_vector (7 downto 0);
begin
en <= (enable or a_big_b);
data_out <= dat;
end dataflow;
architecture structure of peak_detect is
signal a_big_b : std_logic;
signal en : std_logic;
signal dat : std_logic_vector (7 downto 0);
component comp_8bit is
port(
A : in std_logic_vector (7 downto 0);
B : in std_logic_vector (7 downto 0);
res : out std_logic);
end component;
component dff is
port (
data : in std_logic_vector (7 downto 0);
q : out std_logic_vector (7 downto 0);
clk : in std_logic;
reset : in std_logic;
en : in std_logic);
end component;
component id_sens is
port(
data_in : in std_logic_vector (7 downto 0);
led : out std_logic);
end component;
begin
reg : dff port map (data => input, q => dat, clk => clock, reset => reset, en => enable);
comp : comp_8bit port map (A => input, B => dat, res => a_big_b);
sens : id_sens port map (data_in => dat, led => id_led_ind);
end structure;
There appears to be confusion over having two architectures (dataflow and structure) for the entity peak_detect. The two architectures are mutually exclusive, and the last one analyzed is the default in absence of other configuration specifying one of the architectures directly.
For purposes of evaluating how the components are interconnected and their port mapped connections relate to the port declarations of peak_detect, the first architecture could be commented out (dataflow).
When you disregard the architecture dataflow we find there is no driver for data_out in architecture structure.
You're missing an assignment to data_out using dat as a source in architecture structure, as found in architecture dataflow. Copy or replicate the concurrent signal assignment statement data_out <= dat; into architecture structure.
You can't simply connect data_out to q in the port map of dff because the output of dff is also used as an input to id_sense.
dat is driven by q of dff. That is not how you connect components. port map should be used to connect ports of different components/entities, not signals of any entity to the port of another entity.