I am new to VHDL and have had some difficulty in performing the assignment of two different values to the same signal inside a process. For example,
process(CLK)
if rising_edge(CLK) then
OUTPUT0 <= X(0);
OUTPUT1 <= X(1);
OUTPUT2 <= X(2);
LED0 <= VALUE;
OUTPUT0 <= Y(0);
OUTPUT1 <= Y(1);
OUTPUT2 <= Y(2);
LED1 <= VALUE;
end if;
end process;
Note that VALUE is an output dependent on the values assigned to OUTPUT0, OUTPUT1, OUTPUT2.
From what I understand in a process is that the last assignment to the same signal is always applied. What I am trying to do is apply two different sets of values to one set of inputs, map the output and it be done sequentially. I have tried separate processes tied to the same clock, a FSM to attempt to move sequentially and so on. At this point I have exhausted my knowledge of things to try.
My question is: What would be the best way to sequentially assign two values to one input and map its output in order?
EDIT:
As per Brian's suggestion on the state machine I had went ahead and implemented one again and found my error and fixed it. This gave the sequential assignment I was looking for.
I was reading 2 addresses from one instance of 32x1 distributed RAM which is the reason for a sequential assignment. Apologies for not providing the best example. Below is my final implementation:
RAM_READ_FSM : process(CLOCK) -- FSM to read the RAM addresses sequentially
begin
if rising_edge(CLOCK) then
case curr_state is
when S0 => if SW2 = '1' then
RAMADDR0 <= XYVEC(5); -- Y addresses
RAMADDR1 <= XYVEC(6);
RAMADDR2 <= XYVEC(7);
RAMADDR3 <= XYVEC(8);
RAMADDR4 <= XYVEC(9);
LED1 <= RAMOUT;
curr_state <= S1;
else
curr_state <= S0;
end if;
when S1 => if SW2 = '1' then
RAMADDR0 <= XYVEC(0); -- X addresses
RAMADDR1 <= XYVEC(1);
RAMADDR2 <= XYVEC(2);
RAMADDR3 <= XYVEC(3);
RAMADDR4 <= XYVEC(4);
LED2 <= RAMOUT;
curr_state <= S0;
else
curr_state <= S1;
end if;
end case;
end if;
end process;
The signals should be driven from the same process : multiple drivers would interfere with each other..
See Is process in VHDL reentrant? on signal assignment semantics.
now you can see there is need for some delay (even just 2 delta cycles, if the logic calculating VALUE is just a simple signal assignment) between the X and LED0 assignments.
You were on the right lines with a state machine but you didn't say anything about how it failed. Worth adding that to the Q to get a fuller answer.
Meanwhile there is a simple way to add delay :
like
LEDS : process is
begin
wait until rising_edge(CLK);
OUTPUT0 <= X(0);
OUTPUT1 <= X(1);
OUTPUT2 <= X(2);
wait until rising_edge(CLK);
LED0 <= VALUE;
wait until rising_edge(CLK);
OUTPUT0 <= Y(0);
-- etc
end process LEDS;
I've a module that have a 8bit input and a serial output, I want to serialize input data and synchronize it with a clock.
I want to set my data when falling edge then wait when clock rise, when clock fall again I set another data. I don't want to connect the directly reference clock to the output because when I don't use this module I want a 1 state on clock output.
I've tried this code:
process(Clock, ModuleReset)
begin
if ModuleReset = '0' then
OutData <= '0';
OutCK <= '0';
counter <= 7;
elsif falling_edge(Clock) then
OutCK <= '0';
OutData <= Data(counter);
elsif rising_edge(Clock) then
OutCK <= '1';
end if;
end process;
The synthesizer gives me this error:
"Asynchronous load of non-constant data for SCK is not supported"
When I separate the code in two blocks like this:
process(Clock, ModuleReset)
begin
if ModuleReset = '0' then
OutData <= '0';
OutCK <= '0';
counter <= 7;
elsif falling_edge(Clock) then
OutCK <= '0';
OutData <= Data(counter);
end process;
process(Clock)
if rising_edge(Clock) then
OutCK <= '1';
end if;
end process;
I have these two errors:
"Multiple non tristate drivers for net SCK"
"Unresolved tristate drivers for net SCK"
Another code I've tried is:
process(Clock, ModuleReset)
if ModuleEN = '1' then
OutCK <= Clock;
end if;
begin
if ModuleReset = '0' then
OutData <= '0';
OutCK <= '0';
counter <= 7;
elsif falling_edge(Clock) then
OutCK <= '0';
OutData <= Data(counter);
end if;
end process;
But the output clock looks strange with a different frequency.
Your last idea, which I understand ended up working for you, is sub-optimal. If your clock is slow, it should be fine, but I suggest you fix it nevertheless.
if ModuleEN = '1' then
OutCK <= Clock;
else
OutCK <= '1';
end if;
Yields combinational logic with the clock signals for the output. Having the clock used as a logic signal is never recommended, since clocks use clock paths which doesn't route well to general routing resources. The output signal will have potential glitches (very bad for an output interface!) and large delay/skew.
Your first approach, to use a DDR register to forward the clock, is indeed the correct and best approach. With this scheme, your clock only use clock paths, and if both the registers outputing the clock and data are situated in IO blocks, they will have the same output delay with very little skew.
You didn't specify the technology you're using, but I suggest you lookup how to write code that maps to DDR register for your synthesizer. Alternatively, you can manually instantiate the DDR output register primitive, likely ODDR for Xilinx or ALTDDIO_OUT for altera.
The problem with your attempts is indeed that you have multiple drivers for the same signal, or that you assign a signal on both rising and falling edge of a clock. This is not synthesizable.
Try this:
process(Clock, ModuleReset, ModuleEN)
begin
if ModuleEN = '1' then
OutCK <= Clock;
else
OutCK <= '1';
end if;
if ModuleReset = '0' then
OutData <= '0';
counter <= 7;
elsif falling_edge(Clock) then
OutData <= Data(counter);
end if;
end process;
I've a module that have a 8bit input and a serial output, I want to serialize input data and synchronize it with a clock.
I want to set my data when falling edge then wait when clock rise, when clock fall again I set another data. I don't want to connect the directly reference clock to the output because when I don't use this module I want a 1 state on clock output.
I've tried this code:
process(Clock, ModuleReset)
begin
if ModuleReset = '0' then
OutData <= '0';
OutCK <= '0';
counter <= 7;
elsif falling_edge(Clock) then
OutCK <= '0';
OutData <= Data(counter);
elsif rising_edge(Clock) then
OutCK <= '1';
end if;
end process;
The synthesizer gives me this error:
"Asynchronous load of non-constant data for SCK is not supported"
When I separate the code in two blocks like this:
process(Clock, ModuleReset)
begin
if ModuleReset = '0' then
OutData <= '0';
OutCK <= '0';
counter <= 7;
elsif falling_edge(Clock) then
OutCK <= '0';
OutData <= Data(counter);
end process;
process(Clock)
if rising_edge(Clock) then
OutCK <= '1';
end if;
end process;
I have these two errors:
"Multiple non tristate drivers for net SCK"
"Unresolved tristate drivers for net SCK"
Another code I've tried is:
process(Clock, ModuleReset)
if ModuleEN = '1' then
OutCK <= Clock;
end if;
begin
if ModuleReset = '0' then
OutData <= '0';
OutCK <= '0';
counter <= 7;
elsif falling_edge(Clock) then
OutCK <= '0';
OutData <= Data(counter);
end if;
end process;
But the output clock looks strange with a different frequency.
Your last idea, which I understand ended up working for you, is sub-optimal. If your clock is slow, it should be fine, but I suggest you fix it nevertheless.
if ModuleEN = '1' then
OutCK <= Clock;
else
OutCK <= '1';
end if;
Yields combinational logic with the clock signals for the output. Having the clock used as a logic signal is never recommended, since clocks use clock paths which doesn't route well to general routing resources. The output signal will have potential glitches (very bad for an output interface!) and large delay/skew.
Your first approach, to use a DDR register to forward the clock, is indeed the correct and best approach. With this scheme, your clock only use clock paths, and if both the registers outputing the clock and data are situated in IO blocks, they will have the same output delay with very little skew.
You didn't specify the technology you're using, but I suggest you lookup how to write code that maps to DDR register for your synthesizer. Alternatively, you can manually instantiate the DDR output register primitive, likely ODDR for Xilinx or ALTDDIO_OUT for altera.
The problem with your attempts is indeed that you have multiple drivers for the same signal, or that you assign a signal on both rising and falling edge of a clock. This is not synthesizable.
Try this:
process(Clock, ModuleReset, ModuleEN)
begin
if ModuleEN = '1' then
OutCK <= Clock;
else
OutCK <= '1';
end if;
if ModuleReset = '0' then
OutData <= '0';
counter <= 7;
elsif falling_edge(Clock) then
OutData <= Data(counter);
end if;
end process;
This project is about adding user's custom peripheral core to MicroBlaze project on FPGA board "spartan 6 lx9". Using ISE Design Suite 14.6 and EDK.
My problem is being not enough experienced in writing VHDL code. I'm still getting 1-bit unintentional latches on signals: "data_bits" and "latest_value" from <0> til <15>, even though I have used recommended coding style for signal's assignment. I have set default values, but no success... Assignment of signal in each branch of case statement is not an option, since I want to retain value especially for "data_bits" since this vector is being build from several clock cycles. I'm trying to solve this problem for several days.
My questions are:
How I can fixed latches problem in this finite-state machine design? --Answered
I would like to get feedback on my state-machine design, styling etc. --Answered, but there is new code
Any design advice for staying on one state for several clocks cycles, using counters or there is a better technique? --Still expecting some advice
Initial Source Code:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity adc_16bit is
port(
clk : in std_logic;
rst : in std_logic;
data_reg_out : out std_logic_vector(31 downto 0);
control_reg : in std_logic_vector(31 downto 0);
SDO : in std_logic;
SCK : out std_logic;
CONV : out std_logic
);
end adc_16bit;
architecture Behavioral of adc_16bit is
type adc_states is (idle, conversation, clocking_low, clocking_high, receiving_bit, update_data);
signal State, NextState : adc_states;
signal data_bits : std_logic_vector(15 downto 0) := (others => '0');
signal latest_value : std_logic_vector(15 downto 0) := (others => '0');
signal conv_cnt : integer range 0 to 501 := 0;
signal clk_cnt : integer range 0 to 14 := 0;
signal bit_cnt : integer range 0 to 17 := 0;
begin
----------------------------------------------------------------------------------------
-- State Machine Register
----------------------------------------------------------------------------------------
StateReg:
process(clk, rst)
begin
if(clk'event and clk = '1') then
if(rst = '0') then
State <= idle;
else
State <= NextState;
end if;
end if;
end process StateReg;
----------------------------------------------------------------------------------------
-- Signals Register
----------------------------------------------------------------------------------------
TimerReg:
process(clk, rst)
begin
if(clk'event and clk = '1') then
--!default
conv_cnt <= conv_cnt;
clk_cnt <= clk_cnt;
bit_cnt <= bit_cnt;
--latest_value <= latest_value;
--data_bits <= data_bits;
case State is
when idle =>
conv_cnt <= 0;
clk_cnt <= 0;
bit_cnt <= 0;
when conversation =>
if(conv_cnt = 501) then
conv_cnt <= 0;
else
conv_cnt <= conv_cnt + 1;
end if;
when clocking_low =>
if(clk_cnt = 14) then
clk_cnt <= 0;
else
clk_cnt <= clk_cnt + 1;
end if;
when clocking_high =>
if(clk_cnt = 14) then
clk_cnt <= 0;
else
clk_cnt <= clk_cnt + 1;
end if;
when receiving_bit =>
if(bit_cnt = 16) then
bit_cnt <= 0;
else
bit_cnt <= bit_cnt + 1;
end if;
when update_data =>
end case;
end if;
end process TimerReg;
----------------------------------------------------------------------------------------
-- FSM Logic
----------------------------------------------------------------------------------------
FSM_Proc:
process(State, control_reg, conv_cnt, clk_cnt, bit_cnt )
begin
case State is
when idle =>
if(control_reg(0) = '1') then
NextState <= conversation;
else
NextState <= idle;
end if;
when conversation =>
if(conv_cnt = 500) then
NextState <= clocking_low;
else
NextState <= conversation;
end if;
when clocking_low =>
if(clk_cnt = 13) then
NextState <= clocking_high;
else
NextState <= clocking_low;
end if;
when clocking_high =>
if(clk_cnt = 13) then
NextState <= receiving_bit;
else
NextState <= clocking_high;
end if;
when receiving_bit =>
if(bit_cnt = 15) then
NextState <= update_data;
else
NextState <= clocking_low;
end if;
when update_data =>
if(control_reg(0) = '1') then
NextState <= conversation;
else
NextState <= idle;
end if;
end case;
end process FSM_Proc;
----------------------------------------------------------------------------------------
-- FSM Output
----------------------------------------------------------------------------------------
FSM_Output:
process(NextState, latest_value, data_bits, bit_cnt, SDO )
begin
--!default
CONV <= '0';
SCK <= '0';
data_reg_out(31 downto 16) <= (others => '0');
data_reg_out(15 downto 0) <= latest_value;
--data_bits <= data_bits;
--latest_value <= latest_value;
case NextState is
when idle =>
latest_value <= (others => '0');
data_bits <= (others => '0');
when conversation =>
CONV <= '1';
when clocking_low =>
SCK <= '0';
when clocking_high =>
SCK <= '1';
when receiving_bit =>
SCK <= '1';
--data_bits <= data_bits;
data_bits(bit_cnt) <= SDO;
when update_data =>
latest_value <= data_bits;
when others =>
--latest_value <= latest_value;
--data_bits <= data_bits;
end case;
end process FSM_Output;
end Behavioral;
EDIT
Thank you for all your responses! I decided to rewrite my FSM on single process and to add more information regarding my problem in order to make it more understandable for others who has similar problems!
Block Diagram of system:
http://i.stack.imgur.com/odCwR.png
Note: that right now I just want to simulate and verify stand alone adc_core itself without MicroBlaze and AXI interconnection block.
FSM Diagram:
http://i.stack.imgur.com/5qFdN.png
Single process source code:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity adc_chip_driver is
port(
clk : in std_logic;
rst : in std_logic;
data_reg_out : out std_logic_vector(31 downto 0);
control_reg : in std_logic_vector(31 downto 0);
SDO : in std_logic;
SCK : out std_logic;
CONV : out std_logic
);
end adc_chip_driver;
architecture Behavioral of adc_chip_driver is
type states is (idle, conversation, clocking_low, clocking_high, receiving_bit, update_data);
signal state : states;
signal data_bits : std_logic_vector(0 to 15) := (others => '0');
signal latest_value : std_logic_vector(15 downto 0) := (others => '0');
signal conv_cnt : integer range 0 to 500 := 0;
signal clk_cnt : integer range 0 to 13 := 0;
signal bit_cnt : integer range 0 to 15 := 0;
begin
process(clk, rst, control_reg)
begin
if(rst = '0') then
state <= idle;
data_bits <= (others => '0');
latest_value <= (others => '0');
data_reg_out <= (others => '0');
elsif(clk'event and clk = '1') then
--!Default Values
data_reg_out(31 downto 16) <= (others => '0'); --unused bits of register
data_reg_out(15 downto 0) <= latest_value; --data_reg_out is always tided to latast_value;
latest_value <= latest_value; --latest_value is being updated only once
data_bits <= data_bits; --has to retain value
conv_cnt <= conv_cnt;
clk_cnt <= clk_cnt;
bit_cnt <= bit_cnt;
case state is
when idle =>
--signals
conv_cnt <= 0;
clk_cnt <= 0;
bit_cnt <= 0;
--outputs
SCK <= '0';
CONV <= '0';
--logic
if(control_reg(0) = '1') then
state <= conversation;
else
state <= idle;
end if;
when conversation =>
--output
SCK <= '0';
CONV <= '1';
--logic
if(conv_cnt = 500) then
state <= clocking_low;
conv_cnt <= 0;
else
state <= conversation;
conv_cnt <= conv_cnt + 1;
end if;
when clocking_low =>
--ouput
SCK <= '0';
CONV <= '0';
--logic
if(clk_cnt = 13) then
clk_cnt <= 0;
state <= clocking_high;
else
clk_cnt <= clk_cnt + 1;
state <= clocking_low;
end if;
when clocking_high =>
--ouput
SCK <= '1';
CONV <= '0';
--logic
if(clk_cnt = 13) then
clk_cnt <= 0;
state <= receiving_bit;
else
clk_cnt <= clk_cnt + 1;
state <= clocking_high;
end if;
when receiving_bit =>
--signal
data_bits(bit_cnt) <= SDO;
--ouput
SCK <= '1';
CONV <= '0';
--logic
if(bit_cnt = 15) then
bit_cnt <= 0;
state <= update_data;
else
bit_cnt <= bit_cnt + 1;
state <= clocking_low;
end if;
when update_data =>
--signal
latest_value(15 downto 0) <= data_bits(0 to 15);
--ouput
SCK <= '0';
CONV <= '0';
--logic
if(control_reg(0) = '1') then
state <= conversation;
else
state <= idle;
end if;
end case;
end if;
end process;
end Behavioral;
Maybe I could receive some new feedback on single process design?
Also I still do you have unanswered question regarding usage of counters in specific FSM states. I have noticed that usually during second cycle on "clocking_low" and "clocking_high" counter actually starts at 1 instead of 0, I know that in this situation it's not a problem, but I can easily imagine where it could be important. I was thinking about after reset set counters to '-1', but maybe there is better solution?
Your code has a number of problems. To illustrate some of them, I tried to sketch your finite state machine in Figs. 1 and 2 below, based on the VHDL code that you provided.
First and most importantly, the design should begin with a top-level block diagram, showing the circuit ports (as in Fig. 1), followed by a detailed state transition diagram (as in Fig. 2 – incomplete here). Recall, for example, that the circuit outputs (data_reg_out, SCK, and CONV – Fig. 1) are the signals that the FSM is supposed to produce, so it is indispensable that these values be specified in all states (shown inside the state circles in Fig. 2). Once the diagram of Fig. 2 is fixed and completed, writing a corresponding VHDL code should be relatively straightforward (except for the timer - see comments below).
Other problems can be seen directly in the code. Some comments on the four processes follow.
The first process (StateReg), which stores the FSM state, is fine.
The second process (TimerReg) is also registered (under clk’event), which is necessary to build the timer. However, dealing with timers is one of the trickiest parts of any timed FSM, because you MUST devise a correct strategy for stopping/running the timer and also for zeroing it. For this, I suggest that you check reference 1 below, which deals with all possible kinds of FSM implementations from a hardware perspective, including an extensive study of timed FSMs.
The third process (FSM_Proc) defines the next state. It is not registered, which is as it should be. However, to check it, it is necessary to complete first the state transition diagram of Fig. 2.
The last process (FSM_Output) defines the machine outputs. It is not registered, which is as it should be in general. However, the list of outputs is not the same in all states, in spite of the default values. Note, for example, the existence of latest_value and data_bits in state idle, which do not appear in all states, thus causing the inference of latches. Additionally, this process is based on NextState instead of PresentState, which (besides being awkward) might reduce the circuit’s maximum speed.
I hope these comments motivate you to restart from the beginning.
1 V. A. Pedroni, Finite State Machines in Hardware: Theory and Design (with VHDL and SystemVerilog), MIT Press, Dec. 2013.
You get a latch if a signal is not assigned to on all possible paths, as it then becomes stateful.
To avoid the problem, make sure you always assign a value to the signal (one way is to assign a "default" value at the top of the process).
since I want to retain value especially for "data_bits" since this vector is being build from several clock cycles.
"Retaining a value" means state, not purely combinatorial logic. In which case, it should not be in your output process. It should be in your state-update process.
My solution to this has been to always use clocked processes for everything. There is no need to have a separate clocked process for the state register and a separate process for the state transitions. That's a style which was required years ago. In my opinion, you are better off putting everything into a single clocked process and then you cannot get latches.
If you must use two processes then get a VHDL 2008 compiler and use process(all) to ensure that all your signals are correctly in the sensitivity list, and then carefully ensure that every signal you assign to gets an assignment for every logical path through the process. The easiest way to achieve this is often to assign them all some 'default' values at the start of the process.
In a combinational process (like FSM_Output), you should never read a signal and write to the same signal. That is exactly what is going on here, for latest_value and data_bits.
Either create new signals latest_value_r and data_bits_r and copy the values in the clocked process, or stick to a single clocked process with no separate combinational process.
What hardware do you want for data_bits and latest_value? If you want to build a vector over several clock cycles, then you need a storage device. Your choices are: latch (level sensitive storage) and flip-flop (edge sensitive storage). If you don't want latches, then you must code flip-flops.
To code flip-flops use the "if clk='1' and clk'event then", just like you did in TimerReg process. You can alternatively use "if rising_edge(Clk) then" - I like this better for readablity, but the tools don't care either way.
I think where you went wrong is in your planning process. Code is just design capture. What is important is that you plan with a block diagram and know where your design requires flip-flops and where it requires combinational logic. Get this right and the rest is just applying coding templates. So make sure you understand this before you start coding.
It does not matter whether you code with only clocked processes or use a mix of clocked and combinational logic processes. I think the most important thing you do in your coding is make it readable. If you collect opinions, you will see they vary, #Martin and #Brian prefer a single clocked process. I prefer a 2 process statemachine - flip-flop and combinational (present state to next state and ouput decode). You used a 3 process statemachine - for me that is like drawing a bubble diagram to show state transitions and a separate one to show the output transitions. However at the end of the day, they all capture the same intent. As long it is clear to someone reading your code long after you have left, it should be ok.
Fellow SO users,
I'm programming my ADC (ADC0804 which is mounted on a breadboard connected to a Spartan-3 FPGA board). Now, I'm using this ADC to provide digital output for my humidity sensor. The ADC outputs an 8-bit value which I'm displaying on the LEDs on the FPGA board.
Now, I'm writing the state machine in such a way that the ADC would always continue to keep outputting values even when I vary the humidity level. But as for the current implementation I have, eventhough I'm looping back to the first state, I'm not getting a continuous stream of values. I'm only getting one 8-bit value at a time (I.E.; I have to keep pressing the reset button to update the value displayed on the LEDs). The following is my code.
FSM_NEXT_STATE_INIT : PROCESS (CLK, RST)
BEGIN
IF (RST = '1') THEN
CURR_STATE <= STARTUP;
ELSIF (CLK'EVENT AND CLK = '1') THEN
CURR_STATE <= NEXT_STATE;
END IF;
END PROCESS;
START_FSM : PROCESS (CURR_STATE, INTR)
BEGIN
CASE CURR_STATE IS
WHEN STARTUP =>
NEXT_STATE <= CONVERT;
WR <= '0';
READ_DATA <= '0';
WHEN CONVERT =>
IF (INTR = '0') THEN
NEXT_STATE <= READ1;
ELSE
NEXT_STATE <= CONVERT;
END IF;
WR <= '1';
READ_DATA <= '0';
WHEN READ1 =>
NEXT_STATE <= READ2;
WR <= '1';
READ_DATA <= '1';
WHEN READ2 =>
NEXT_STATE <= STARTUP;
WR <= '1';
READ_DATA <= '0';
WHEN OTHERS =>
NEXT_STATE <= STARTUP;
END CASE;
END PROCESS;
PROCESS (CLK, RST)
BEGIN
IF (RST = '1') THEN
Y <= (OTHERS => '0');
ELSIF (CLK'EVENT AND CLK = '1') THEN
IF (READ_DATA = '1') THEN
Y <= D7&D6&D5&D4&D3&D2&D1&D0; --Concatenate the 8-bit ADC output
END IF;
END IF;
END PROCESS;
You'll notice that in state 'READ2', I'm looping back to the beginning (so that I can keep reading values continuously as the states transition) but somehow I don't think this is working. Could anyone please provide some assistance on how to go about solving this?
After a look on the data sheet for the ADC0804 I found following which could be the/a possible reason:
Note: Read strobe must occur 8 clock periods (8/fCLK) after assertion of interrupt to guarantee reset of INTR.
Inserting a WAIT state between CONVERT and READ1 might fix the problem.