I am new on VHDL, I have a push button which I want to detect the it signal when it is pushed, meaning i want to detect the raising edge of the signal push button when it is pressed?
I did research and all what I found was about the detecting the raising edge of a clk.
the problem that I have is that when the push button is pressed the the signal for the push button goes to 1 and stay at 1 until until another even happen so I am interested more when the signal of the push button raise?
Your question in idiomatic English:
I am new to VHDL and have a push button that I want to detect as a
rising edge when pressed.
I did some research and all what I found was about the detecting the
rising edge of a clock.
When the push button is pressed the signal for the push button goes to
'1' and stay at '1' until until another event occurs.
How do I detect the push button rising edge event?
This isn't so much of a VHDL question as it is a digital design question. VHDL comes into play for implementing a solution in VHDL.
See sonicwave's answer to the question VHDL - Incrementing Register Value on Push Button Event which provides an edge detector.
However switch bounce can occur for tens of milliseconds (Maxim web article on switch bounce), potentially generating multiple events, is switch dependent and corrective action also depends on sampling clock rate.
Notice the Maxim web page article mentions membrane switches can be bounce free when new and degrade over time and bounce characteristics are not repeatable.
Some FPGA vendors provide a Schmidt trigger buffer between buttons and claim membrane momentary switches are then 'debounced'. The Maxim web article claims membrane switches may not remain clean over their useful lifetime. These and other types of momentary switches can require debouncing.
debouncing
When debouncing is not provided by the FPGA board the idea is to filter out all these bounces digitally and generate a single event showing the button has been depressed. This requires a clock.
first get the button signal into your clock domain
This requires metastability filtering, which is accomplished by minimizing the delay between two successive flip flops to maximize immunity to events occurring within the metastability region of the first flip flop when the first flip flop sees a setup or hold time violation.
The input to the first flip flop is the button signal, the input to the second flip flop is the output of first flip flop.
The output of the second flip flop is in the clock domain, metastability free when not exceeding the a clock rate representing period comprised of the routing delay between the two flip flops plus the metastability recovery time of the flip flop.
The metastability recovery time of the flip flop is usually represented by the maximum clock rate period in an FPGA.
filtering out bounces
Feed the metastability filtered button signal to a counter as a reset when the button is invalid. When you release the button the counter is cleared.
The size of the counter depends on the clock rate and length of switch bounce, you can require tens of milliseconds.
A terminal count signifies a valid button event and also is used to stop the counter. (Terminal count FALSE is an enable for the counter).
The counter is stopped to provide a single button event.
Also note that when the button input is metastability filtered it acts as a synchronous reset.
Edge detection
Edge detection is done with a flip flop with the terminal count signal as an input and a two input gate, the type of gate and polarity of it's inputs can be used to select which edge of the event (potentially both with an XOR gate) you detect. One input to the gate from the flip flop, the other the terminal count from the counter.
If you've deemed debounce is provided adequately by the FPGA board design you can combine metastability filtering and edge detection without using a debounce counter.
Maxim's application note
If you have a commercially produced FPGA board you shouldn't have to worry about voltage transients outside digital signalling levels, the Maxim article is promoting their protective devices to board designers.
The web article provides an authoritative reference on switch bounce and the bounce waveforms.
FPGA board vendors
Some FPGA board vendors provide debounce circuit reference design code. They'll do this because the counter size is dependent on the reference clock rate, and potentially the clock used is derived by a DPLL.
Depended on if you want safety check for meta-stability or not make a shift register and shift your input signal on a clock and look when there is a difference. The code below is very simple and takes into account that you have a clock in your system.
signal edge_detect : std_logic_vector( 1 downto 0 );
process (clk_i) is
begin
if rising_edge(clk_i) then
edge_detect <= edge_detect(0) & input_signal;
if edge_detect = "01" then
-- do stuff on rising_edge
elsif edge_detect = "10" then
-- do stuff on falling_edge
end if;
end process;
But depended on rising/ falling time of your signal vs. your clock you might want to look into meta-stability also if you get problems with false positives.
Related
We use after [some delay] statement for providing delay and that we can analysis in simulation. But when we will load this model in to FPGA so in actual hardware being made by VHDL code will have affect of delay or this delay is limited to simulation only?
a <= not b after 1s;
So suppose I connected one switch to b and LED to a so will I get one second delay in between pressing the switch and updating LED status?
as said before, the wait statement cannot be synthesized and will only affect the simulation. However, I should add that even in simulation you might not get what you expect. Allow me to explain.
VHDL offers 2 delay models: transport delay and inertial delay, the latter being the default, which you selected by not specifying which model to use.
If b would happen not to be stable in the course of the delay, say it toggles every 500ms, a would not toggle as you may desire. To really introduce pure delay, select the transport delay model as follows:
a <= transport not b after 1s;
Of course, again, this cannot be synthesized and is for simulation purposes only.
When you are simulating you need to provide when things happen and what happens to the inputs. After implementing it on the FPGA, exterior events create the inputs and the simulation has nothing to do about it.
So if I understood your question right, yes, the delay you are showing will only affect the simulation.
EDIT :
Regarding the timer, you know the FPGA's clock frequency. So you can create a variable and increment it on each clk_up (I use CLK = '1' and CLK'Event but there are better ways to do it), and when it reaches the same value as the clock frequency, 1 sec has passed.
Not-so-Pseudo code:
signal clock: unsigned (9 downto 0);
if CLK = '1' and CLK'Event then
clock<= clock + 1;
if clock = "1100100000" then --clock frequency (this is an example)
clock <= "0000000000"
-- 1 secound passed!
end if;
end if;
How do you detect rising edge synchronization of 2 different clocks(different frequencies) in VHDL programming using Xilinx software?
There is a main clock of frequency 31.845 Mhz , and another clock of frequency 29.972 Mhz. So the basic aim is to trigger an action when there is synchronization between the rising edges of 2 clocks. We tried implementing it using flipflops but we could achieve only Level synchronization, not Edge sync.
And we cannot compare the rising edges of 2 different clocks in statements like IF and WAIT in vhdl, So that is out of question.
We are trying to count pulses using a counter. For that, we need to stop the count whenever edge matching takes place. We are trying to implement a method called 'Vernier Interpolation'.
Initially, we used the following statement code, but since rising edges of 2 different clocks (clk0, clk1) cannot be compared in an IF statement, we had to drop it.
if(rising_edge(clk0)=rising_edge(clk1)) then wait;
We then tried using WAIT statements (wait until) but it failed.
Then we tried using flipflops and delay circuits (D flipflop), but it resulted in level sync, and not Edge sync.
Firstly I'm not sure why you would want to do this. What you will get out is a new clock at the beat frequency between the two clocks.
The correct way to do this is to sample both clocks using another clock which is at least twice the frequency of the highest expected input. You could generate this higher clock using one of the PLLs in the device. x2 is a minimum. Ideally use a clock which is much higher than both sampled clocks.
Remember VHDL is not a language, it a description of synthesis of real hardware. So just saying Rising_Edge(clk1) = Rising_Edge(clk2) does not make the 'software' detect edges. All the function Rising_Edge really does is to tell the hardware to connect the clk signal to the clock input of a flipflop.
The proper solution is sample both 'clocks' in a process which is clocked by the a sample clock, look for edges (an edge being two subsequent samples that are different) then AND the result and latch if required.
sample code (untested, sorry no time right now).
entity twoclocks is
port (
op : out std_logic;
clk1 : in std_logic;
clk2 : in std_logic;
sample_clk : in std_logic);
end entity;
architecture RTL of twoclocks is
begin
process sample(sample_clock, clk1, clk2):
begin
if rising_edge(sample_clock):
clk1_d <= clk1;
clk2_d <= clk1;
if clk1_d != clk1 and clk2_d != clk2 then
op <= '1';
else
op <= '0';
end if;
end if;
end process;
end architecture;
The kind of vernier interpolator you want needs to be build using very tight timing constraints, thus you can probably not make it using VHDL alone. You need (a lot of) device specific constraints on resource locations and timing.
Please check out the work by A.Aloisio et al.. Aloisio and colleagues have build a vernier interpolator using specific Xilinx delay elements.
Standard VHDL synthesis is mostly suited for register transfer level descriptions. I.e. clocked/synchronous logic. But to compare these two inputs, you would need to sample them at a frequency of the least common multiple of both frequencies. For 31.845 MHz and 29.972 MHz that is a whopping 954.458340 MHz, which is a lot. I have seen these kind of speeds in FPGA logic though.
... But I'm thinking you might even need to double that, due to Nyquist. Maybe FPGA logic can nowadays handle 2 GHz swichting rate. But I'm not sure.
It might be possible to utilize a GT transceiver for this, but since that would be non-standard use of a such a transceiver, it might be hard to realize.
I am looking to build a VHDL circuit which responds to an input as fast as possible, meaning I don't have an explicit clock to clock signals in and out if I don't absolutely need one. However, I am also looking to avoid "bouncing" where one leg of a combinatorial block of logic finishes before another.
As an example, the expression B <= A xor not not A should clearly never assign true to B. However, in a real implementation, the two not gates introduce delays which permit the output of that expression to flicker after A changes but the not gates have not propagated that change. I'd like to "debounce" that circuit.
The usual, and obvious, solution is to clock the circuit, so that one never observes a transient value. However, for this circuit, I am looking to avoid a dependence on a clock signal, and only have a network of gates.
I'd like to have something like:
x <= not A -- line 1
y <= not x -- line 2
z <= A xor y -- line 3
B <= z -- line 4
such that I guarantee that line 4 occurs after line 3.
The tricky part is that I am not doing this in one block, as the exposition above might suggest. The true behavior of the circuit is defined by two or more separate components which are using signals to communicate. Thus once the signal chain propagates into my sub-circuit, I see nothing until the output changes, or doesn't change!
In effect, the final product I'm looking for is a procedure which can be "armed" by the inputs changing, and "triggered" by the sub-circuit announcing its outputs are fully changed. I'd like the result to be snynthesizable so that it responds to the implementation technology. If it's on a FPGA, it always has access to a clock, so it can use that to manage the debouncing logic. If it's being implemented as an ASIC, the signals would have to be delayed such that any procedure which sees the "triggered" signal is 100% confident that it is seeing updated ouputs from that circuit.
I see very few synthesizable approaches to such a procedural "A happens-before B" behavior. wait seems to be the "right" tool for the job, but is typically only synthesizable for use with explicit clock signals.
I'm trying to understand clock-reset in a chip. In a design what criteria are used to decide whether a flop should be assigned to a value (typically to zero) during reset?
always_ff #(posedge clk or negedge reset) begin : process_w_reset
if(~reset) begin
flop1 <= '0;
....
end else begin
if (condition) begin
flop1 <= something ;
....
end
end
end
always_ff #(posedge clk) begin : process_wo_reset
if (condition) begin
flop1 <= something ;
....
end
end
Is it a bad practice to not to reset a flop which is used later as a control signal in a comb logic? What if the design makes sure that the flop will have a valid value (0 or 1) assigned to it before its used in a comb logic block (i.e. in a if statement or in FSM comb logic) ?
I feel like it's better to always reset all the flops in the design. In that way there won't be any Xs after reset in the chip. However, it seems like for datapath logic, resetting flop might need not be a big deal as it'll be just pipe stages. However if a flop is in control path (i.e. FSM next state comb logic) then it should be reset to a default value. Is my understanding correct? I don't know much about DFT and not sure if it has any other implication.
Assuming that reset means asynchronous reset, as in the code examples.
The answer is partly opinion based, since a design can be made to work with reset of a minimum number of the Flip-Flops (FFs) and all of the FFs.
I suggest that a minimum number of FFs are reset, and typically that leads to reset of most FFs in the control path, and no reset of FFs in the data path. The advantages of this approach are outlined below.
Simulation is often conservative with respect to propagation of uninitialized values, both for Verilog and VHDL, so it is like simulation can check both 0 and 1 values at once when the value is uninitialized.
Bugs due to FFs that are not reset, are therefore likely to show earlier in verification with simulation, and the designer thereby gets valuable feedback about wrong design assumptions, which may lead to corrections in the design that fixes other bugs. Just resetting all the FFs is likely to hide such bugs.
It may seem like design and verification is just easier if all FFs are reset, both in control and data path, since it fixes all those "annoying" X propagation in the design. But it requires an increased number of tests in order to verify all value combinations when X propagation is suppressed through reset.
Implementation gives a smaller load on the reset signal, so it is easier to meet timing of the reset net throughout the chip.
DFT (Design For Test) in general, then adding reset to the FFs will not aid DFT in finding nets stuck at reset value. With a DFT scan chain approach where all the FFs are loaded through the scan chain, then the lack of reset on some FFs will not require more vectors.
Generally you need to think about where the 'X's will propagate in your simulation and which ones matter and which ones are don't care conditions. For example, if you have a block of logic which doesn't start operating until an enable bit is set, so long as the enable bit itself is set and enough upstream logic is reset so reset values will propagate through to the enabled logic in time, you are most likely OK with not reseting the logic in between. However, you do want to reset any logic that feeds back into itself, (for example state machines) otherwise the upstream resets will never be able to establish a known state in the feedback block.
I agree with Morten Zilmer that you should only reset flops that require resetting, although my background is more FPGA than ASIC.
It's worth pointing out there is a gotcha in Verilog / SystemVerilog - if you have a clocked process that drives registers that are reset and registers that aren't you will end up inferring a clock enable or an additional mux on the input of your flip-flop.
This is usually not what was intended.
There is a more detailed explanation in this answer. I also wrote a blog post outlining a mechanism for abstracting away synchronous/asynchronous and active high/low reset.
As a general rule of thumb, you should probably always reset control signals.
For data flops, resetting can cost you area, so it really depends on whether you care about area.
In recent years simulators started to support X propagation modes that allow you to catch some of the X issues in RTL (instead of gate level simulation). It is a good practice to run these to make sure you don't have a reset problem with uninitialized sram or flops.
This would make a Verilog module sensitive to a clock and a reset switch being turned on:
always #(posedge clk, posedge rst)
How would this be changed to being sensitive to a switch being turned off?
If you want your block to be sensitive to a switch being turned off, you'll want a negedge in front of the name of the switch input, for example, "switch_line":
always #(posedge clock, posedge reset, negedge swtich_line)
If you just want to have a flipflop check the status of a switch on every positive edge of the clock cycle,
always #(posedge clock, posedge reset)
if (!switch_line)
// ...
else
// ...
Are you trying to model a flip-flop, latch, or perhaps some new type of hardware? Usually, only flipflops and latches are interested in the clock signal. A flip-flop with an asynchronous reset is modeled as
always #(posedge clock, posedge reset)
For a synchronous reset, drop the reset signal from the sensitivity list.
As per the user's comment, another option is to just plug-in the go signal for the reset signal. When you are hooking up this module, you can do the following:
mymodule UUT(
.clock(clock),
.reset(~go),
//...
);
If you negate go, you'll get the same as behavior as reset, just inverted (e.g. a signal going from 1->0).
Unless you are running at a very low clock frequency the change in button state will be much slower that a clock period. Treating the button input as a async signal is therefore not a good idea. Instead you probably want to sample the input and also probably remove glitches.
As minimum sample the input by a register and then have your control FSM look at that register and when the expected change is detected move to the appropriate state. This means that it will take the design 1-2 cycles to "react" to the button change. But, again, unless the clock frequency is very low, the period will be short enough that no human will notice a few cycles latency.
If you connect the signal to the reset you (1) loose all state info by pressing the button (bad) and suddenly have two reset signals. Hot rodding the design like that might work, but is bad design methodology and will make your design sensitive to noise etc.