How do you smartest design a VHDL state machine for initializing a chip.
My current design is (in pseudo code):
....
....
case state:
when s0 =>
VHDL_CODE_FOR_WRITING_VALUE_TO_REGISTER
state := s1;
when s1 =>
VHDL_CODE_FOR_WRITING_ANOTHER_VALUE_TO_REGISTER
state := s1;
when s2 =>
DO_SOMETHING_ELSE_TO_FINISH_INIT
....
....
end case;
The code in s0 and s1 only differs by the value that is written to the register.
This made me think that there must be a smarter way (which is still Synthesize able)?
What made me think something can be done more clever, is the phrase "Don't repeat yourself", but I'm not sure this applies to VHDL.
If you have common assignments in states s0 and s1, pull it out of the case statement.
case state:
when s0 =>
a <= '0';
b <= '1';
c <= '0';
nextState <= s1;
when s1 =>
a <= '0';
b <= '1';
c <= '1';
nextState <= s2;
when s2 =>
a <= '1';
b <= '0';
c <= '1';
endcase;
...would become...
a <= '0';
b <= '1';
c <= '1';
case state:
when s0 =>
c <= '0';
nextState <= s1;
when s1 =>
nextState <= s2;
when s2 =>
a <= '1';
b <= '0';
endcase;
...or if that isn't suitable, pull the code into a function and call that in each case.
There's nothing VHDL specific about this though.
Although the continuous refrain of VHDL answerers (including me) is "think hardware, not software", this time the software thought process is the one that serves you well :)
The usual don't repeat yourself(DRY) solution is to encapsulate the behaviour you want in a function or procedure. You can do just this in VHDL and any competent tool will be fine with it.
Related
While implementing a state machine on VHDL I was wondering how can I set the output / current state initial condition. I read on one of the questions on here.
One of the answers said we do the initialization before the case structure:
process(currentstate, a)
begin
b <= '1';
c <= '1';
case currentstate is
when s1 =>
if (a = '1') then
c <= '0';
end if;
nextstate <= s2;
However doesn't that make us automatically set b<='1' and c<='1' whenever we get into the process? So if we are at a state say A and we are at the conditions of moving to B whenever we enter the process this directly puts b<='1' and c<='1' isn't that true ?
Or does it actually just run once we start the program and then gets bounded in the case structure ?
Also check this link.
In their FSM implementation they did not specify the initial state how does the compiler or FPGA determine the start state ?
The lines you are looking at are not performing initialization.
b <= '1';
c <= '1';
Remember that VHDL is a hardware description language, not a programming language. What those two assignments do is to set a default assignment for those signals, unless something else contradicts these assignments later in the process. You can assign to the same signal several times in one process, and whichever assignment happens last will take priority. This saves having to write code like:
case State is
when s1 =>
a <= '0';
b <= '1';
c <= '1';
when s2 =>
a <= '1';
b <= '0';
c <= '1';
when s2 =>
a <= '1';
b <= '1';
c <= '0';
end case;
It can end up being quite repetitive and error prone to have the same assignments in many states, so default assignments can really tidy it up:
a <= '1';
b <= '1';
c <= '1';
case State is
when s1 =>
a <= '0';
when s2 =>
b <= '0';
when s2 =>
c <= '0';
end case;
The same pattern works for if statements where you don't want to cover every output signal in every logical branch.
If you want an initial state, there are two approaches that may be applicable depending on the scenario. Here you would assert reset at start-up to set the initial state. Note that the case statement is inside a clocked process:
process (clk)
begin
if (rising_edge(clk)) then
if (reset = '1') then
State <= s1;
else
case State is
when s1 =>
State <= s2;
when s2 =>
State <= s1;
end case;
end if;
end if;
end process;
The other option is to define your state signal with an initial value:
signal State : state_type := s1;
I won't go into the pros and cons of using initial values as there are existing questions that explore this.
Right now I am working on a small project in Vivado, a Mealy FSM. The program must detect a 6 bits sequence 001011, and output "1" when the sequence is detected.
The code concerning the sequence detection is doing just fine, but besides that, it must also use Three Flip Flops: JK, D, and T.
Any advice or suggestions on how to add them?
Thank you for your time.
This is the FSM code:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity sequence is
port(
clk : in std_logic;
reset : in std_logic;
x: in std_logic;
z : out std_logic;
a : out std_logic;
b : out std_logic;
c : out std_logic;
d : out std_logic;
e : out std_logic;
f : out std_logic);
end sequence;
architecture behavioral of sequence is
type state_type is (Q0, Q1, Q2, Q3, Q4, Q5);
signal state, next_state : state_type;
begin
state_register: process (clk, reset)
begin
if (reset = '1') then --if reset is high, goto state Q0
state <= Q0;
elsif (clk'event and clk = '1') then --if not, and rising
state <= next_state; --edge, go to next state
end if;
end process;
next_state_func: process (x, state)
begin
case state is
when Q0 =>
if x = '0' then
next_state <= Q1;
else
next_state <= Q0;
end if;
when Q1 =>
if x = '0' then
next_state <= Q2;
else
next_state <= Q0;
end if;
when Q2 =>
if x = '1' then
next_state <= Q3;
else
next_state <= Q2;
end if;
when Q3 =>
if x ='0' then
next_state <= Q4;
else
next_state <= Q0;
end if;
when Q4 =>
if x = '1' then
next_state <= Q5;
else
next_state <= Q2;
end if;
when Q5 =>
if x = '1' then
next_state <= Q0;
else
next_state <= Q1;
end if;
end case;
end process;
-- This process controls the output of the sequence detector.
-- Each state has it's own output along with 'z' which indicates
-- the entire sequence 001011 has been detected.
output_func: process (x, state)
begin
case state is
when Q0 => z <= '0';
a <= '1';
b <= '0';
c <= '0';
d <= '0';
e <= '0';
f <= '0';
when Q1 => z <= '0';
a <= '0';
b <= '1';
c <= '0';
d <= '0';
e <= '0';
f <= '0';
when Q2 => z <= '0';
a <= '0';
b <= '0';
c <= '1';
d <= '0';
e <= '0';
f <= '0';
when Q3 => z <= '0';
a <= '0';
b <= '0';
c <= '0';
d <= '1';
e <= '0';
f <= '0';
when Q4 => z <= '0';
a <= '0';
b <= '0';
c <= '0';
d <= '0';
e <= '1';
f <= '0';
when Q5 => z <= '1';
a <= '0';
b <= '0';
c <= '0';
d <= '0';
e <= '0';
f <= '1';
end case;
end process;
end behavioral;
[1]: https://i.stack.imgur.com/pVwxL.jpg - and here is the table that contains the State Diagram Table of the FSM.
Your code is wrong. Take a look at the output_func process; this is combinatorial, and just decodes the current state, without looking at x. The a to f outputs aren't necessary, and are just a 6-bit decode of the current state - why? The z output is set when the current state is Q5, which isn't what you want - the whole process is redundant. You need to set z in your main FSM, when the current state is Q5, and x is 1 - ie. on the next_state <= Q0 transition.
On your actual question - you can't force selection of any particular F/F type with this code - the synthesiser will do whatever it wants, which means that it will implement the whole thing in D types, since JKs have been obsolete for the last 20 years. The same is probably true of T types. You need to start again, and pretend that you have a technology and a library with T, D, and JK. Write these yourself as separate entities, and re-write your code to instantiate these components, instead of allowing the synthesiser to infer them. Re-write your FSM to use JKs - the diagram you gave shows you how. In other words, derive the J and K inputs to each F/F. The z output can be a D-type. You should be able to fit in a T somewhere - I've left that as an exercise for you.
In my waveform diagram, I am wondering why my "rdy" value does not change to 1 after 400ns.
And why does my "d" value not output anything after the first two outputs? I've tried finding the error for hours but to no avail. Please help, thank you in advance.
Here is my waveform diagram:
And here is my main code.
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
entity GCD is
port(st , clk: in std_logic; --clk temporarily taken out
d1, d2 : in std_logic_vector(7 downto 0);
dout : out std_logic_vector(7 downto 0);
rdy : out std_logic);
end GCD;
architecture behav of GCD is
type state is (S0, S1, S2, S3, S4, S5, S6, S7);
--temporary clk
--signal clk : std_logic;
signal new_state : state;
signal eq : boolean;
signal eq1 : boolean;
signal lt : boolean;
begin
--State transition
process is
variable curr_state : state:= S0;
begin
if clk = '1' then
case curr_state is
when S0 =>
if st = '1' then curr_state := S1;
end if;
when S1 =>
curr_state := S2;
when S2 =>
if eq and not lt then curr_state := S7;
elsif lt and not eq then curr_state := S4;
elsif not eq and not lt then curr_state := S3;
end if;
when S3 =>
curr_state := S4;
when S4 =>
curr_state := S5;
when S5 =>
if eq1 = true then curr_state := S7;
else curr_state := S6;
end if;
when S6 =>
curr_state := S1;
when S7 =>
if st = '0' then curr_state := S0;
end if;
end case;
new_state <= curr_state;
end if;
wait on clk;
end process;
--Asserted Output Process
process is
variable M, N, dout_val, tmp: std_logic_vector(7 downto 0);
variable rdy_val : std_logic;
variable lt_val, eq_val, eq1_val : boolean;
begin
rdy_val := '0';
case new_state is
when S0 =>
M := d1;
N := d2;
when S1 =>
if (to_integer(M) = to_integer(N)) then eq_val := true;
elsif (to_integer(M) < to_integer(N)) then lt_val := true;
end if;
when S2 =>
when S3 =>
M := N;
N := M;
when S4 =>
if (to_integer(M) = 1) then eq1_val := true;
end if;
when S5 =>
when S6 =>
N := (N - M);
when S7 =>
rdy_val := '1';
dout_val := M;
end case;
dout <= dout_val;
rdy <= rdy_val;
lt <= lt_val;
eq <= eq_val;
eq1 <= eq1_val;
wait on new_state;
end process;
end behav;
And here is my testbench:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use work.all;
entity test_GCD is
end test_GCD;
architecture testbench of test_GCD is
signal m, n ,d: std_logic_vector(7 downto 0);
signal clk, st, rdy : std_logic;
begin
--Component Instantiation
device : GCD
port map( clk => clk, st => st, d1 => m,
d2 => n, dout => d, rdy => rdy);
--Process to Generate Test Data
process is
begin
st <= '0';
wait for 10ns;
m <= "00001001"; --9 , 15
n <= "00001111";
wait for 10ns;
st <= '1';
wait until rdy = '1';
wait for 10ns;
st <= '0';
wait for 10ns;
m <= "00001111"; --15, 9
n <= "00001001";
wait for 10ns;
st <= '1';
wait until rdy = '1';
wait for 10ns;
st <= '0';
wait for 10ns; --15 , 14
m <= "00001111";
n <= "00001110";
wait for 10ns;
st <= '1';
wait until rdy = '1';
wait for 10ns;
st <= '0';
wait for 10ns;
m <= "00010010"; --18 , 36
n <= "00100100";
wait for 30ns;
st <= '1';
wait until rdy = '1';
wait for 10ns;
st <= '0';
wait for 10ns;
m <= "01011011"; --91 = 01011011 , 39 = 00100111
n <= "00100111";
wait for 10ns;
st <= '1';
--wait for 10ns;
wait until rdy = '1';
wait for 10ns;
st <= '0';
wait for 10ns;
m <= "01111111"; --127, 127
n <= "01111111";
wait for 10ns;
st <= '1';
wait until rdy = '1';
wait for 10ns;
wait;
end process;
process is
begin
clk <= '0', '1' after 15ns;
wait for 30ns;
end process;
end testbench;
You're the second one to ask a question here today with the same assignment.
In the third st/rdy set you've upset the timing relation:
st <= '0';
wait for 10ns;
m <= "00010010"; --18 , 36
n <= "00100100";
wait for 30ns;
st <= '1';
wait until rdy = '1';
wait for 10ns;
The previous two sets have wait for 10 ns. This one has 30 ns. What does that do?
You're state machine in the unlabelled state transition process is missing the st <= '1', because it's not looking for it when it occurs, add waveforms down in GCD, try new_state.
There's a fine balance between helping someone and doing their assignment for them.
addendum
Can you elaborate what you mean by I am missing the st<='1' in my state transition? I've declared st as a std_logic so I can't use the "<=" assignment for it. Do you mean I am missing the st<='1' in my testbench?
The idea was to get you to look at the operation of the state machine spread across two unlabelled processes.
Your state machine is operating on the positive clock edge even though your code is not written to be synthesis eligible. The process is driven by only one event, clk and the expression clk = '1'is evaluated in the first if statement condition.
if you add new_state to your waveform dump (show it in the waveform display):
(you can open the image in a separate tab or window, it's a link to itself)
(And notice the first GCD 'answer' is all U's. The second 'answer' also doesn't appear to be the greatest common denominator between 15 and 9, either.)
You'll see your state machine quits transitioning, remaining stuck in S2 which evaluates ltand eqbut doesn't modify them in the Asserted Output Process (and you could use labels instead of comments, any statement can be labelled in VHDL).
We look to the previous state S1, where eq_val and lt_val are assigned. They are dependent on M and N, which are assigned from d1 and d2 in S0.
Back in S2 notice:
when S2 =>
if eq and not lt then
curr_state := S7;
elsif lt and not eq then
curr_state := S4;
elsif not eq and not lt then
curr_state := S3;
end if;
And if you look at eq and lt in the above waveform you see they are both true. How can that be? There is to transition condition for that, you stick in S2.
So how can both conditions be true at the same time?
when S1 =>
if (to_integer(M) = to_integer(N)) then
eq_val := true;
elsif (to_integer(M) < to_integer(N)) then
lt_val := true;
end if;
You are only assigning one of them.
However, the other one remains in it's previous state, latched by new_state.
As a short term demonstration I assigned eq_val and lt_val both false right before they are evaluated. That will leave at most only one true.
Unfortunately that reveals another flaw in your design:
And that's not the subject of your question.
You appear to use a Euclid (GCD) algorithm shown in the flow chart (figure 1) in the PDF found in the link. The Boolean types appears to be an assignment requirement (the other student used them as well). The resulting VHDL expresses this algorithm with at least one more error.
You use N as an accumulator in finding the GCD, and you also change the contents of M. N has three sources, d2, the result of N-M in S6 and swappingMandNinS3(which has the effect of assigningNtoM, andN` to itself, variable assignment is immediate). M and N should be signals, or you need an intermediary value to swap through. (They should be signals).
You can use your waveform display to troubleshoot your design. You should also be aware when you are inferring latches, which occur when you have conditional assignments without the equivalent of an 'else'.
The open source tools I used looking at your design (ghdl and gtkwave) don't capture variables in waveform dumps. I'd suspect DesignWorks 5 doesn't either (and could be wrong).
The impact of this is you can't see what the data is doing during the simulation. Your design is small enough you could have used signals throughout without impacting simulation time significantly. Assigning to eq and lt directly in S1 would require else assignments (false). If you're required to use variables for the assignment you can assign them to signals so they are visible, should DesignWorks 5 not display variables. Once you're done you can remove the signals.
The answer to Why doesn't my “rdy” value change to 1? is that you have inferred latches creating a case you don't detect for branching out of S2.
Once you straighten out the M and N swap in S3 it looks like it may have a good chance or working (there could be another gotcha or two in there).
And when you use tmp to hold the value of M (not using signals):
when S3 =>
tmp := M;
M := N;
N := tmp;
You start getting the right answers:
Without seeing the handout you were given for your project I'd anticipate you worked from pseudo code like found in the linked PDF's figure 1. It may have been written in the anticipation of the use of signals.
Hello I have a state machine that reads from BRAM sends data to a compute core and then writes results back in the BRAM after that the address are incremented so that the next item in the bram can be fed to the compute core. The increment is happening erratically in the state machine. I simulated the code(after stripping down unnecessary stuff) and the increment looks fine in simulation. Can some one please help me to figure out whats wrong. Thanks a bunch for all the help
--The bulk of my glue logic to bring it all together.
process(Bus2IP_Clk,ap_rst,ap_done)
variable in_a_addrb : std_logic_vector(9 downto 0);
variable in_b_addrb : std_logic_vector(9 downto 0);
variable out_r_addrb : std_logic_vector(9 downto 0);
begin
if(ap_rst = '1' ) then
gcd_cs <= wait_for_reset;
in_a_addrb := "0000000000";
in_b_addrb := "0000110010";
out_r_addrb := "0001101110";
elsif (Bus2IP_Clk'event and Bus2IP_Clk = '1') then
gcd_cs <= gcd_ns;
end if;
case gcd_cs is
when wait_for_reset =>
intrpt <= '0';
slv_reg6(0) <= '0';
state_tracker <= "00000000000000000000000000000001";
if(ap_rst = '0')then
gcd_ns <= wait_for_bram_ready;
else
gcd_ns <= wait_for_reset;
end if;
when wait_for_bram_ready =>
state_tracker <= "00000000000000000000000000000010";
if(bram_ready = '1')then
web <= "0";
gcd_ns <= load_input_a;
else
gcd_ns <= wait_for_bram_ready;
end if;
when load_input_a =>
state_tracker <= "00000000000000000000000000000011";
addrb <= in_a_addrb;
in_a <= doutb;
gcd_ns <= load_input_b;
when load_input_b =>
state_tracker <= "00000000000000000000000000000100";
addrb <= in_b_addrb;
in_b <= doutb;
gcd_ns <= start_compute;
when start_compute =>
state_tracker <= "00000000000000000000000000000101";
ap_start <= '1';
gcd_ns <= wait_for_done;
when wait_for_done =>
state_tracker <= "00000000000000000000000000000110";
if(ap_done = '1')then
ap_start <= '0';
web <= "1";
addrb <= out_r_addrb;
dinb <= output;
gcd_ns <= increment_addresses_1;
else
gcd_ns <= wait_for_done;
end if;
when increment_addresses_1 =>
web <= "0";
state_tracker <= "00000000000000000000000000000111";
gcd_ns <= increment_addresses;
when increment_addresses =>
state_tracker <= "00000000000000000000000000001000";
if(in_a_addrb = "0000000111") then
gcd_ns <= stop_compute;
else
in_a_addrb := in_a_addrb +'1';
in_b_addrb := in_b_addrb +'1';
out_r_addrb := out_r_addrb + '1';
gcd_ns <= load_input_a;
end if;
when stop_compute =>
state_tracker <= "00000000000000000000000000001001";
gcd_ns <= stop_compute;
slv_reg6(0) <= '1';
intrpt <= '1';
end case;
in_a_addrb_d <= in_a_addrb;
in_b_addrb_d <= in_b_addrb;
out_r_addrb_d <= out_r_addrb;
end process;
All of your additions are done outside of the clock event. In simulation this may "work" because the process only gets simulated when a signal in the sensitivity list changes. The sensitivity list exists mostly to make simulation more computationally efficient. When you try to implement this into real hardware, items outside of the clock event will become combinational logic that "executes" constantly. This is similar to hooking the output of an inverter to itself without a register in between - it doesn't make any sense. Brian Drummond speaks truth when he says that you should convert this to a regular state machine form to avoid these kinds of errors.
State machines with this kind of architecture can work, despite being more difficult to read and use. The important part is that anything that needs to store information (such as the state) needs to be split into a current and a next, with that transition happening on the clock edge. You do this with the explicit state, but the values of the counters are also part of the machine's state data, and need to receive the same treatment. Using a standard form (with everything occurring on the clock edge) means that you don't have to duplicate all the signals/variables for your storage elements, nor figure out which signals are in fact storage elements, making everything easier.
I am currently writing my first FSM and am unsure of if I have the logic correct. I am tasked with creating a state diagram for the following logic:
A = 00
B = 01
C = 10
D = 11
Output is 1 when:
BDA
BAA
BAD
So I created the following vhdl code to accomplish this:
So every time I get it to output 1 I send it back to B and make count + 1. This is supposed to display on the LED as the number of times it is found in an 18 bit sequence.
Did I approach this in the correct way? I am confused on how I move it through the 18 bit sequence. I am supposed to us the swtiches on the board as my 18 bits which is represented as SW. Would I replace data_in with SW(17 downto 0)?
This is a comment not an answer I putting it in answer as I am not eligible to comment yet.
I think you have some problem in FSM concepts. Also as in the comment said data_in is std_logic not a vector.
you are taking input serially one bit at a time so accordingly write the processes. you can write code to detect the sequences BDA, BAA, BAD that is sequences "011100","010000" and "010011". I would write a simple FSM code so that you can clear you concepts then you can try.
library ieee;
use IEEE.std_logic_1164.all;
entity mealy is
port (clk : in std_logic;
reset : in std_logic;
input : in std_logic;
output : out std_logic
);
end mealy;
architecture behavioral of mealy is
type state_type is (s0,s1,s2,s3); --type of state machine.
signal current_s,next_s: state_type; --current and next state declaration.
begin
process (clk,reset)
begin
if (reset='1') then
current_s <= s0; --default state on reset.
elsif (rising_edge(clk)) then
current_s <= next_s; --state change.
end if;
end process;
--state machine process.
process (current_s,input)
begin
case current_s is
when s0 => --when current state is "s0"
if(input ='0') then
output <= '0';
next_s <= s1;
else
output <= '1';
next_s <= s2;
end if;
when s1 =>; --when current state is "s1"
if(input ='0') then
output <= '0';
next_s <= s3;
else
output <= '0';
next_s <= s1;
end if;
when s2 => --when current state is "s2"
if(input ='0') then
output <= '1';
next_s <= s2;
else
output <= '0';
next_s <= s3;
end if;
when s3 => --when current state is "s3"
if(input ='0') then
output <= '1';
next_s <= s3;
else
output <= '1';
next_s <= s0;
end if;
end case;
end process;
end behavioral;