VHDL Cannot Drive Load pins - vhdl

Using the first snippet of code, I have been getting this error that a bunch of my signals drove no pins. I am pretty certain that this is because in the first snippet of code, the first if statement is never reached. Why would this be so? In the second snippet I modified the code, and all of my problems have been fixed. I made the change as an intuitive impulse, I have no idea why that fixed everything. Could someone explain maybe how the Synthesizer generates the circuit?
First Snippet:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity DataReg is
generic(N: integer := 8);
port(DIN: in std_logic_vector(N - 1 downto 0);
DOUT: out std_logic_vector(N - 1 downto 0);
CLK: in std_logic;
ENABLE: in std_logic;
RESET: in std_logic);
end DataReg;
architecture Behavioral of DataReg is
begin
process(CLK, ENABLE)
begin
if rising_edge(CLK) and ENABLE = '1' then
DOUT <= DIN;
end if;
if rising_edge(CLK) and RESET = '1' then
DOUT <= (others => '0');
end if;
end process;
end Behavioral;
Second snippet: (Fixed code)
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity DataReg is
generic(N: integer := 8);
port(DIN: in std_logic_vector(N - 1 downto 0);
DOUT: out std_logic_vector(N - 1 downto 0);
CLK: in std_logic;
ENABLE: in std_logic
RESET: in std_logic);
end DataReg;
architecture Behavioral of DataReg is
begin
process(CLK, ENABLE)
begin
if rising_edge(CLK) then
if ENABLE = '1' then
DOUT <= DIN;
elsif RESET = '1' then
DOUT <= (others => '0');
end if;
end if;
end process;
end Behavioral;

Because HDL code must be able to represent existing hardware. Therefore when you write RTL (Register Transfer Level) code you have to stick to certain structures. Even the second code you wrote is not correct.
I can't explain all the rules but basically, to use an edge (rising or falling) you can have only one signal. Not OR-es or And-es etc.:
if rising_edge(CLK) then
In such a clocked section your process can have one or two more sensitivity signals. Often there is an asynchronous reset in some exceptional cases there is also an asynchronous set. For those to work you have to place the condition before the clock. Therefore your code is wrong. Your ENABLE and RESET are only looked at when there is a clock edge. Thus putting ENABLE in the sensitivity list is superfluous. You might just as well leave it out.
Furthermore the ENABLE if is before the RESET. Thus if the ENABLE is high your RESET will be ignored. Probably not what you want!
The code for a clocked section is sooo terribly standard that I often copy a template I have laying around. (I always use asynchronous active low reset)
process(clk, reset_n)
begin
if (reset_n='0') then
elsif rising_edge(clk) then
end if; -- reset/clocked
end process;

First of all, the two pieces of code that you present are not even equivalent in the simulator because when ENABLE and RESET are both 1 on a clock edge, the first snippet results in DOUT being 00000000 whereas in the second one it evaluates to DIN.
It is my impression that the sensitivity lists (the part in parentheses after process) are ignored during synthesis by Xilinx Vivado. I consider them a relic from times when simulation tools could not afford deducing which variables should be monitored to determine when variables should be updated. I don't know what other synthesis tools do with them.
Anyway, you specified ENABLE in your sensitivity list, which means that you want to evaluate the process statements if ENABLE changes value. All if-statements evaluate to false unless a rising clock edges is taking place. Therefore, CLK alone in the sensitivity list is sufficient for simulation.
All that being said, you should restrict your code to formats that are explicitly recommended by the synthesis tool vendor. Synthesis tools can only implement a subset of everything that you can write in VHDL. For Vivado, you can find suggested code structure in the synthesis manual (This one is for Vivado 2017.3). On page 71, you will see that they recommend flip-flops of the form:
process(clk) is
begin
if rising_edge(clk) then
if clr = '1' then
dout <= "00000000";
elsif ce = '1' then
dout <= d_in;
end if;
end if;
end process;
You can rename the variables as needed of course. On page 69, you will also see that Xilinx recommends using synchronous implementations (putting everything inside the rising_edge if-statement) over asynchronous implementations. There is much more in the manual, for example about how to write shift registers or RAMs, which you should become familiar with if you want to write code to be synthesized with Vivado. Other vendors have similar documentation with recommended code.

Related

Why do incomplete if statements create latches during synthesis in VHDL?

Why is it when we try to synthesize incomplete if statements in VHDL the synthesizer uses latches instead of flip-flops?
An explanation from a digital/circuit standpoint would be greatly appreciated.
The premise of the question is wrong. The latch is not inferred instead of a flip-flop.
Flip-flops are inferred every time a signal goes through a clocked process even with an incomplete IF statement. For example, the following code infers a flip-flop:
process(clock) is
begin
if rising_edge(clock) then
if (A) then
B <= C;
end if;
end if;
end process;
Latches are inferred only in combinatorial logic processes when there is an incomplete IF statement. This is due to the fact that an incomplete if statement requires the storage of information which is not possible with the simpler elements of combinatorial logic (wires and gates).
Short answer: because the behaviour of a latch matches that of an incomplete IF. A register does not.
if (A)
B = C;
If the condition A is true and C changes, the output B follows the input immediately. If A is false B keeps it value. This behavior of the IF statement corresponds with the behavior of a latch. Thus a latch is what is generated.
You can not generate this behaviour with a register.
Unfortunately, I can't answer to oldfart (not enough reputation), so technically the short answer is kinda correct.
But, the long answer has different variables: what kind of design do you implement, what tool do you use and what platform is your target.
E.g. Quartus II 16.1, Cyclone V CSXFC6D6F31C6 such code:
library ieee;
use ieee.std_logic_1164.all;
entity d_latch_test is
port
(
signal clk : in std_logic;
enable : in std_logic;
sr_in : in std_logic;
sr_out : out std_logic
);
end entity;
architecture rtl of d_latch_test is
begin
process (clk)
begin
if (rising_edge(clk)) then
if (enable = '1') then
sr_out <= sr_in;
end if;
end if;
end process;
end rtl;
Quartus Synthesis would not tell you that your code is a latch, but it is a D-flip-flop
But! It has asynchronous input.
So basically you can do a flip-flop from if-statement.

VHDL design - creating if loop within second process not working

I've written a VHDL design that halves the clock's frequency and outputs this 'data clock' onto the sclk pin. I also have a data pin called 'sda' that I'd like to send data out of. The following code works fine. I see the clock signal out of sclk and sda is permanently set to high. Enable is attached to a push button.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
-- For Main Clock --
library machXO3l;
use machXO3l.all;
--------------------
entity top is
-- entity's pin out.
port(
enable : in std_logic;
sda : out std_logic := '0';
sclk : out std_logic := '0'
);
end entity;
architecture top_behav of top is
signal temp_sclk : std_logic := '0';
signal clk : std_logic;
signal temp_sda : std_logic := '1';
signal stdby : std_logic := '0';
component OSCH
-- Component description that is being used within the entity.
-- synthesis translate_off
generic (NOM_FREQ: string := "24.18");
-- synthesis translate_on
port(
STDBY : in std_logic;
OSC : out std_logic
);
end component;
attribute NOM_FREQ : string;
attribute NOM_FREQ of OSCinst0 : label is "24.18";
begin
OSCinst0: OSCH
-- synthesis translate_off
generic map( NOM_FREQ => "24.18" )
-- synthesis translate_on
-- mapping the OSCH component to our entity pin out.
port map(
OSC => clk,
STDBY => stdby
);
-- DATA CLOCK GENERATION
sclk_p : process(clk, enable)
begin
if (enable = '0') then
temp_sclk <= '0';
elsif (clk'event and clk = '1') then
temp_sclk <= NOT temp_sclk;
end if;
end process;
sclk <= temp_sclk;
sda <= temp_sda;
end top_behav;
The problem is when I create the following process within the architecture, both lines are permanently set to 0. I don't understand why. Simulation works fine. I'm able to synthesize my code and program it on to the FPGA. But when monitoring the pins using a scope, they're just set to low.
sda_p : process(clk, enable)
begin
if (enable = '0') then
temp_sda <= '0';
else
temp_sda <= '1';
end if;
end process;
The following works fine too:
sda_p : process(clk, enable)
begin
temp_sda <= '1';
end process;
I'm using lattice diamond and machx03l evk
In Lattice Diamond, first of all, look at the netlist analyzer (icon and image shown below)
Check to see that the synthesized logic is correct. If the netlist analyzer shows the correct logic, then you need to believe that this is what is going to be synthesized. Then you have removed your uncertainty and there are no more doubts.
Does it indeed show that you are connecting to ground or does it show the correct intended logic to be synthesized?
If it shows that it is correct, then your problem can only be because of your external hardware or your output settings. Please check:
Output settings (red box below)
Pull mode matches your external world (Purple highlight below)
Drive strength (red highlight below)
Check where your pin output is going to. What is your load? Is it affecting what you are driving?
You mentioned that you monitored the signals using a scope, is it the Lattice logic analyzer? or an actual oscilloscope?
If it is using the Lattice Logic Analyzer where you instantiate the analyzer as a logic block inside the FPGA, then the only other reason I can think of is that your clock is not correctly functioning.
If using an oscilloscope, there could still be a problem which can be plausibly explained by the above symptoms and potential problems
In the end, my code was correct but since the machx03l only allows limited RAM flash programming (compared to the machx03lf board), I am using the SPI flash programming interface. Using this interface is a pain - many a times, I have to keep doing a 'Background, flash, erase, verify' when programming the board. Other times the IDE complaints I've got a 'CHECK_ID' error, in which case I resort to use the 'Flash, erase, verify' method. If the latter does work and the board does nothing, always do the former and it should work, given one is confident of their code.

VHDL behavioural D Flip-Flop with R & S

Hi can any of you with more experience with VHDL Quartus II please set me right on this please.
I have the following Entity and behavioural Architecture for a D Flip-Flop with Set and Reset.
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
ENTITY Q1 IS
PORT (D,R,S,CLK : IN std_logic;
Q : OUT std_logic
);
END ENTITY Q1;
ARCHITECTURE behavioural OF Q1 IS
BEGIN
D_FF : PROCESS (CLK,R,S)
BEGIN
IF R = '0' THEN Q <= '0';
ELSIF S = '0' THEN Q <= '1';
ELSIF (rising_edge(CLK)) THEN Q <= D;
END IF;
END PROCESS D_FF;
END ARCHITECTURE behavioural;
When I compile the code using Quartus II I get the following error message :
Warning (335093): TimeQuest Timing Analyzer is analyzing 1 combinational loops as latches.
I think it is a warning for the incomplete output assignments of the R & S inputs, but when I make a D Flip-Flop latch with only the SET input this error message does not appear when compiled. This leaves me thinking maybe I made an error when writing the architecture? If anyone has any answers or useful info that would be much appreciated.
You have described a clock-edge triggered flip-flop (FF) with both an asynchronous reset and an asynchronous set. Only one of them is supported at the same time because AFAIK, all FFs on Altera FPGAs have only an asynchronous reset.
An asynchronous set is emulated on Altera FPGAs by inverting the FF data input and output and then resetting it to low instead of setting it to high. It looks like this:
Don't overlook the inverter on the D input of the FF. If S is low, then the FF itself is asynchronously reset, but due the negation of the Q output afterwars, it behaves as an asynchronous set of output Q of your entity Q1. If S is high, the FF stores the negated input at the rising clock-edge, which is again negated at the output. As you see, the asynchronous reset port of the FF is already used, and thus, cannot be used for an additional asynchronous reset of your entity Q1.
I recommend to use flip-flops with synchronous set and reset instead:
ARCHITECTURE sync_rs OF Q1 IS
BEGIN
D_FF : PROCESS (CLK)
BEGIN
IF (rising_edge(CLK)) THEN
IF R = '0' THEN Q <= '0';
ELSIF S = '0' THEN Q <= '1';
ELSE Q <= D;
END IF;
END IF;
END PROCESS D_FF;
END ARCHITECTURE sync_rs;
Flip flops in FPGA devices usually have either asynchronous set or reset, but not both, so Altera Quartus tries to make the requested circuit with latches instead of dedicated hardware.
However, for most cases that is not what you want, so instead use flip flops with either asynchronous reset or set, or use synchronous set and and reset as Martin Zabel suggested in his answer.
Note that asynchronous reset have an advantage over synchronous reset in high speed designs, since the asynchronous reset does not add any login in the main synchronous data path, which is usually the critical path for high-speed designs.
Finally, for asynchronous reset, it is a good habit to use two if separate statements, with reset last, so clocking is not dependent on assertion of reset. It is not an issue for a single bit flip flop, but if more signals are controlled in the same process, and reset does not apply to all signals, then clocking should not be dependent on reset for those signal without reset, since that will infer latches. Code like:
D_FF : PROCESS (CLK, R)
BEGIN
IF rising_edge(CLK) THEN
Q <= D;
END IF;
IF R = '0' THEN
Q <= '0';
END IF;
END PROCESS D_FF;
Thanks for the reply, I made the R & S inputs asynchronous on purpose. I have been working through a VHDL text book "Free Range VHDL" and have come across the following question in the Exercises:
The question asks for both inputs to be asynchronous. You say this can be emulated with Altera by inverting the input and output and resetting it to low instead of high. Can you expand on this a little? Thanks

VHDL - FSM Control

I'm a beginner and I need a little help . My "current_s" is changing whenever rising edge of the clock detected. But, I want it to change only once when "Dot" or "Dash" is '1'.
I tried to create a signal like: Go_s<=Dot or Dash;
And then tried to use its rising_edge to enable the process, but I've been told that it's not a good idea. But I can't think anything else.
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.all;
-------------------------------------------------------------------------------
Entity Let5 is
Port(
Clk: in std_logic;
Reset: in std_logic;
Dot: in std_logic;
Dash: in std_logic;
one_spc: in std_logic;
three_spc: in std_logic);
END Let5;
-------------------------------------------------------------------------------
Architecture Let5_a of Let5 is
-------------------------------------------------------------------------------
Type state is (Start, A, B, A_1, A_2, B_1, B_2);
Signal current_s: state;
-------------------------------------------------------------------------------
BEGIN
---------------------------------------------------------------------------------
PROCESS(Clk, Reset)
BEGIN
IF(Reset='1')Then
current_s<=Start;
ELSIF(Clk='1' and Clk'event)Then
Case current_s is
When Start =>
IF(Dot='1')Then
current_s<=A;
ELSIF(Dash='1')Then
current_s<=B;
END IF;
When A =>
IF(Dot='1')Then
current_s<=A_1;
ELSIF(Dash='1')Then
current_s<=A_2;
END IF;
When B =>
IF(Dot='1')Then
current_s<=B_1;
ELSIF(Dash='1')Then
current_s<=B_2;
END IF;
When OTHERS => current_s <= Start;
END Case;
END IF;
END PROCESS;
-------------------------------------------------------------------------------
END Let5_a;
Simulation:
Add an conditional update of current_s inside the clocked process, using:
...
elsif (Clk='1' and Clk'event) then
if (Dot = '1') or (Dash = '1') then
case current_s is
...
Then current_s is updated only when the condition (Dot = '1') or (Dash = '1') is TRUE.
It is correct what you have been told, that you should not make an additional signal Go_s checking for rising edge of this, since this is not the way to implement standard synchronous designs. Instead use a signal clock and make updates on rising edge, for example using rising_edge(Clk) instead of Clk='1' and Clk'event, and then make the updated conditional to whatever signal required. FPGAs and tools are made to implement this kind of design.
Actually it ought to work reading Dot or Dash in the way you do now; I suspect something else is the problem.
If Dot is high for three consecutive clock cycles...
in the first, you get to State A.
in the second, you get to State A1.
in the third, ... there is no handler for State A1 so the "when others" clause takes you back to Start.
I suspect you actually want to remain in State A1 (or even State A) until either :
Dot is no longer 1, or:
Dash is 1
and to accomplish this (remain in State A1 instead of retriggering) you need:
When A1 =>
if Dot = '0' then
current_s <= Start;
elsif Dash = '1' then
current_s <= A_2;
end if;
Treat states Bn similarly for Dash.
If I'm misinterpreting and you actually want to remain in State A longer, it should now be clear how to make that happen instead.
Your code has a number of problems, and they are NOT related to Dot and Dash, because it is OK to have one with higher priority than the other. The present state changes at every clock cycle because that is exactly what you told the circuit to do when Dot and/or Dash is '1'. Note that in the states start, A, and B the machine changes to a state that is not in this list (start, A, B), so the WHEN OTHERS statement causes it to return to the start state at the next clock edge, with this repeated indefinitely.
My suggestion is that you draw the intended state transition diagram very carefuly, after which re-writing the code should be straightforward, especially because this is a relatively simple problem.

VHDL FSM set unit input and use output in same state

I am implementing a Mealy-type FSM in vhdl. I currently am using double process, although i've just read a single-process might be neater. Consider that a parameter of your answer.
The short version of the question is: May I have a state, inside of which the input of another component is changed, and, aftwerwards, in the same state, use an output of said component? Will that be safe or will it be a rat race, and I should make another state using the component's output?
Long version: I have a memory module. This is a fifo memory, and activating its reset signal takes a variable named queue_pointer to its first element. After writing to the memory, the pointer increases and, should it get out of range, it is (then also) reset to the first element, and an output signal done is activated. By the way, i call this component FIMEM.
My FSM first writes the whole FIMEM, then moves on to other matters. The last write will be done from the state:
when SRAM_read =>
READ_ACK <= '1';
FIMEM_enable <= '1';
FIMEM_write_readNEG <= '0';
if(FIMEM_done = '1') then --is that too fast? if so, we're gonna have to add another state
FIMEM_reset <= '1'; --this is even faster, will need check
data_pipe_to_FOMEM := DELAYS_FIMEM_TO_FOMEM;
next_state <= processing_phase1;
else
SRAM_address := SRAM_address + 1;
next_state <= SRAM_wait_read;
end if;
At this state, having enable and write active means data will be written on the FIMEM. If that was the last data space on the memory, FIMEM_done will activate, and the nice chunk of code within the if will take care of the future. But, will there be time enough? If not, and next state goes to SRAM_wait_read, and FIMEM_done gets activated then, there will be problems. The fact that FIMEM is totally synchronous (while this part of my code is in the asynchronous process) messes even more?
here's my memory code, just in case:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity memory is
generic (size: positive := 20);
Port ( clk,
reset,
enable,
write_readNEG: in std_logic;
done: out std_logic;
data_in: in STD_LOGIC_VECTOR(7 downto 0);
data_out: out STD_LOGIC_VECTOR(7 downto 0) );
end memory;
architecture Behavioral of memory is
subtype word is STD_LOGIC_VECTOR(7 downto 0);
type fifo_memory_t is array (0 to size-1) of word;
signal fifo_memory : fifo_memory_t :=((others=> (others=>'0')));
--Functionality instructions:
--Resetting sets the queue pointer to the first element, and done to 0
--Each cycle with enable active, a datum from the pointer position is
--written/read according to write_readNEG, and the pointer is incremented.
--If the operation was at the last element, the pointer returns to the first place
--and done is set to 1. When done is 1, enable is ignored.
Begin
process(clk,reset)
variable done_buf : std_logic;
variable queue_pointer: natural range 0 to size-1;
begin
if(reset = '1') then
queue_pointer := 0;
done_buf := '0';
elsif(rising_edge(clk)) then
if(done_buf = '0' and enable = '1') then
case write_readNEG is
when '0' =>
data_out <= fifo_memory(queue_pointer);
when '1' =>
fifo_memory(queue_pointer) <= data_in;
when others => null;
end case;
if(queue_pointer = size-1) then
done_buf := '1';
queue_pointer := 0;--check
else
queue_pointer := queue_pointer + 1;
end if;
end if; --enable x not done if
end if; --reset/rising edge end if
done <= done_buf;
end process;
End Behavioral;
More details inspired by the first comment:
The memory can read the data at the same cycle enable is activated, as seen here:
Notice how the "1", the value when enable is turned active, is actually written into the memory.
Unfortunately, the piece of code is in the asynchronous process! Although I'm VERY strongly thinking of moving to a single-process description.
In contrast to all the circuits I've designed until now, it is very hard for me to test it via simulation. This is a project in my university, where we download our vhdl programs to a xilinx spartan 3 FPGA. This time, we have been given a unit which transfers data between Matlab and the FPGA's SRAM (the functionality of which, I have no idea). Thus, I have to use this unit to transfer the data between the SRAM and my memory module. This means, in order to simulate, my testbench file will have to simulate the given unit! And this is hard..suppose I must try it, though...
first of all, whether to use a single process or a dual process type of FSM notation is a matter of preference (or company coding style rules). I find single process notation easier to write/read/manage.
your enable signal will have an effect on your memory code only after the next rising clock edge. the done signal related to the actual memory state will therefore be available one clock cycle after updating enable. I guess (and hope! but it's not visible in your posted code), your current_state<=next_state part of the FSM is synchronous! therefore your state machine will be in the SRAM_wait_read state by the time when done is updated!
btw: use a simulator! it will help to check the functionality!
thanks for adding the simulation view! strangely your done signal updates on neg. clock edge... in my simulation it updates on pos. edge; as it should, by the way!
to make the situation more clear I suggest, you move the done <= done_buf; line inside the "rising_edge-if" (this should be done anyhow when using synchronous processes!).

Resources