the following is my code:
process(key(0), key(3))
begin
if (key(3) = '0') then
current_state <= restart;
elsif (rising_edge(key(0))) then
current_state <= next_state;
end if;
end process;
key(0) in the code is a pushbutton, so I have a clock which is operating from a push button, but when I use this process statement in my code everything works but there is a bounce with the button that is operating as a clock, can anyone please help with the code required to debounce this push button? For example sometimes when I press the button I miss some states in between, I think this is a bounce issue since everything works when modelled with ModelSim, but missing states with the actual board.
Sorry for any formatting issues and missing tags.
Related
Hello everyone I wrote some VHDL code that implement a UART-TX from my FPGA to my desktop. To trigger data sending I use the signal(debounced ofc) coming from the on-board switch.
As long as the button is pressed data is being sent. Inevitably, for as quick as I can be pushing and releasing this switch, the FPGA sends many UART packet duplicates to the laptop. This is because i directly connected the button signal to the start bit of the UART-TX entity. Therefore, I removed this direct connection and instead use the button to actually generate a short bit pulse to trigger the UART-TX entity just once.
So I did this:
--start_deb is the start bit (debounced? coming from the switch
i_TX_DV_gen: process(start_deb, clk) is
variable counter: natural := 0;
begin
if rising_edge(start_deb) then
i_TX_DV <= '1';
end if;
if i_TX_DV = '1' and rising_edge(clk) then
counter := counter + 1;
if counter > 10_000 then
i_TX_DV <= '0';
counter := 0;
end if;
end if;
end process;
So the trigger bit to the UART entity is set to '1' when I press the button and then after a number of clock cycles (which I unsured smaller than the ones necessary to send one packet) it goes to '0' again avoiding the send any duplicates.
This works in simulation, I attached the waveform:
These are the signals description
clk:system clock
start_n: button signal (pressed when low)
start: not(start_n)
shift_input_n: button signal to select the next byte code.
o_TX_serial: serial output of the TX entity
packet: byte to be sent
i_TX_DV: trigger bit to start UART-TX trasmission
start_deb: start signal but debounced
The problem is that when I download it to my FPGA, the i_TX_DV is set to '1' only the first time.
[
To visualize this I used a FPGA-built-in LED, which produces a light burst every time the i_TX_DV is set to '1'( for its very short amount of time).
]
Therefore, the UART-TX entity is triggered only the first time I pressed the button. Apparently when on FPGA for some reason, i_TX_DV is not set to '1' anymore, or is set to '0' just right after.
I am using the fpga Crosslink-NX Family 8MG289C from Lattice Semiconductor.
Thank you guys, I thought of others ways to include it in a FSM and I ended up modifying the FSM of the UART-TX entity. Basically I don't go back to the idle state as long as the input start button is still pressed. This is a section of the FSM which contains the part I modified
when s_Cleanup =>
o_TX_Active <= '0';
r_TX_Done <= '1';
***if i_TX_DV = '1' then
r_SM_Main <= s_Cleanup;
else
r_SM_Main <= s_Idle;
end if;***
Anyway back at my original implementation, this was the netlist analyzer output for the pulse trigger generator:
It uses a register and a full adder to implement the counter. A register stores the value of i_TX_DV. The two multiplexer at the left are apparently used to either hold the value of the counter, updating it with the next value or "reset" it. The reset apparently is carried in this way: it comes from the d1 constant input data of bottom-left multiplexer wihch is tied to a 0. Therefore at the next clock cycle, when it holds the value it should be resetting itself. For some reason this still didn't work.
I apologize for my careless when writing the VHDL code, but when wiriting the code I just assumed that as long the simulation went well, the synthesis tool would have done the rest. Also I decided to not include too much code in order to be more coincise, because I had done several testing and made sure that all the other entities and modules were working correctly.
I have picked up some VHDL code to maintain that has a reset written in a way I'm not familiar with. I'm not sure if it's valid, and my simulator (Modelsim) is giving warnings that I wouldn't expect. Example of the pattern:
process(clk, reset_n)
begin
if reset_n = '0' then
counter <= (others=>'0');
end if;
if rising_edge(clk) then
case state is
when IDLE =>
if signal_a = signal_b then
state <= DATA;
end if;
when DATA =>
state <= IDLE;
when others =>
end case;
if state = DATA then
counter <= counter + 1;
else
counter <= (others => '0');
end if;
end if;
end process;
Modelsim warns that state, signal_a and signal_b are "read in the process but is not in the sensitivity list". I would not expect that as they are in a clocked block and the process is sensitive to the clock.
Is this a valid coding style for an async reset? I would expect to see elsif rising_edge(clk) instead, but understand this would cause problems here with the mix of other non-reset signals (state).
This pattern likely wont behave as you expect, and also likely wont synthesise (and if it does, it wont match the code).
This code has the clock overriding the reset. If reset is asserted ('0') then the counter will be reset, but if clk is running it will the run as if reset_n is '1'. This is because processes are only triggered by a 'event' on a signal in the sensitivity list, so the reset will only occur when reset_n changes to '0'. This doesnt usually matter in VHDL as the reset branch will have higher priority than the clock. So if it is clocked, the reset branch is taken. But here, because the reset has lower priority, it is as if reset_n is a negitive edge clock.
On the actual hardware, this is different. Sensitivity lists are normally ignored and the hardware is built from the code in the process. I would expect that this will fail to build either because it will complain about no logic matching the template, or dual edge flops are not allowed.
To fix this, either make the clock branch an elsif as you suggested, and you would also need to add state to the reset to avoid an accidental clock enable on state, or move the reset to the bottom of the process, where it will override the clock assignment properly, and allow you to have a mix of reset and non-reset registers in the same process.
I am trying to clean up my VHDL code. I have a signal that is NOT a clk.
Can I write an event change monitor like the following and how do I get it to compile so it can be synthesized? (see code) I have tried several permutations but I cannot get it to compile. Will signal'event compile if signal is not a CLK and if so, how is it done? I see on the web and other literature that it can be done but all examples I see show CLK'event.
signal cntr: unsigned(15 downto 0) := (others => '0');
...
process(CLK):
begin
IF rising_edge(CLK) THEN
if (cntr'event) then
do something;
end if;
or...
if(cntr(0)'event) then
do something;
end if;
END IF;
end process;
I get the following and others
: can't synthesize condition that contains an isolated 'EVENT predefined attribute
rising_edge(CLK) is already an event, making your design synchronous, which is good. As said in comments, only clock signals should use that.
Looking at another even at that time doesn't make sense in synchronous designs, as the 2 signals won't change exactly at the same time, creating a race condition. Or actually a clock within a clock, and the synthesis error...
It may work in simulation, but don't rely on that fact.
The normal way to program in HDL languages is to save the previous value of the signal, on the same clock (for example cntr_d <= cntr) and to compare with that previous value. That allows to find if the signal went up (previously at 0, currently at 1), went down, changed (is different)...
And that method is perfectly fine for synthesis!
I am trying to make a new design. I design it with two processes which are synchronous and asynchronous. I generally give reset in the asynchronous process which is shown first code snippet. However, someone just told me that is a mistake. In her knowledge, I should give the reset statement in the synchronous process. I also checked the schematic for the first one and saw it is connected correctly to flip-flop's resets.
sync_proc : process(clk_i)
begin
if(rising_edge(clk_i)) then
do smt..
end if;
end process sync_proc;
async_proc : process(some signals)
begin
if(reset_i = '1') then
reset smt..
else
do smt..
end if;
end process sync_proc;
Above is my code and below is what she suggested.
sync_proc : process(clk_i)
begin
if(reset_i = '1') then
reset smt..
else(rising_edge(clk_i)) then
do smt..
end if;
end process sync_proc;
I am wondering that, is there any differences between these states? If so, what are they?
Think of a VHDL process as a little bit of software that models a little bit of hardware. With your approach, you have two little bits of hardware driving the same signal, ie a short circuit. With her (correct) approach, you have one little bit of hardware (a flip-flop) driving one signal.
I was given a code for a D Flip-Flop with enable.
process(clk, en)
begin
if rising_edge(clk) then
if en = ‘1’ then
Q <= D;
end if;
end if;
end process;
I was told that I should not use if rising_edge(clk) and en = ‘1’ then .... Why?
Why isn't the if for the en = '1' before the if for clock since the clock is changing more often?
And is it necessary to specify that en in the process parenthesis process(clk, en)?
Some people believe that the VHDL compilers and synthesizers are not able to figure out that it's the same thing as you've shown here. I've never directly compared the output, but I'd be pretty sad if it mattered.
Changing more often doesn't really matter in hardware. In theory, it shouldn't matter. In practice, the compiler will probably incorrectly warn about your sensitivity list if you changed the order of the conditionals.
It is not.
Here is the answer to all 3 of your questions:
If you're coding sequential logic, it is wise to stick to a template. Here is one such template for sequential logic with no asynchronous reset, which all synthesis tools should understand:
process(clock) -- nothing else should go in the sensitivity list
begin
-- never put anything here
if rising_edge(clock) then -- or falling_edge(clock)
-- put the synchronous stuff here
-- ie the stuff that happens on the rising or falling edge of the clock
end if;
-- never put anything here
end process;
So en should not be in the senstivity list and it should not be tested in the same if statement as the clock is tested.
If you think about it, there is another good reason why en should not be in the sensitivity list: the output of a flip-flop with no asyncrhonous reset only changes when the clock changes; it does not change when the D input changes.