I was hoping you could help me with a problem I encountered while trying to design synchronous circuits.
I have a simple D flip-flop in my design, such as the one shown in the figure below. But when I initialize my inputs and set the reset to 1 in the test bench, the output of the D flip-flop is always undefined (as can be seen in the "Objects" view), even though I explicitly define it to be 0 when reset is high (the code for the D flip-flop is shown below).
This causes errors in larger circuits when I use the flip-flops and the outputs as signals to other components that require a defined input. How can I achieve an output of zero when my reset is high during initialization?
library ieee;
use ieee.std_logic_1164.all;
entity Dff_en is
port (
d : in std_logic;
en : in std_logic;
clk : in std_logic;
reset : in std_logic;
q : out std_logic
) ;
end entity;
architecture rtl of Dff_en is
signal q_next, q_reg : std_logic;
begin
--dff logic
process(clk, reset) is
begin
if(reset = '1') then
q_reg <= '0';
elsif(rising_edge(clk)) then
q_reg <= q_next;
end if;
end process;
-- next-state logic
q_next <= d when (en = '1') else q_reg;
--output
q <= q_reg;
end architecture; -- arch
Your code will only update the q_reg output when there are events on the signals in the sensitivity list (clk, reset). VHDL (and Verilog) require events to trigger changes. With signal initialization, then at time 0 the values are set, but there are no further events to simulate.
Even if you did a run 100 ns, there would be no change in outputs since you have not had any events. Change either clk or reset some time after time 0 and try again.
Related
I'm an amateur when it comes to VHDL and hardware in general but I've been working on a project for school and I came across something that I can't understand.
I have a register (type D FF) that's processing a clock signal to store the input value and, in simulation, it works fine if I use a "Force clock" in it's clk input but if I try to "simulate" a clock by manually changing it with "Force Constant" from zero to one and so forth it doesn't "pick up" on the rising edge.
Is this normal behavior? I assumed it would still detect the rising edge when going from 0 to 1.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity register_D is
generic (
WIDTH : POSITIVE := 1
);
Port ( CLK : in STD_LOGIC;
RST : in STD_LOGIC;
EN : in STD_LOGIC;
D : in STD_LOGIC_VECTOR(WIDTH-1 downto 0);
Q : out STD_LOGIC_VECTOR(WIDTH-1 downto 0));
end register_D;
architecture Behavioral of register_D is
begin
process (CLK, RST, EN)
begin
if (RST='1') then
Q <= (others=>'0');
elsif (rising_edge(CLK) and EN = '1') then
Q <= D;
end if;
end process;
end Behavioral;
Screenshot of me trying to trigger the FF by manually setting the clock (and not working):
Here you can see it working when I switch clk from "Force constant" to "Force clock":
There is something I do not understand about VHDL processes ending with an unconditional wait statement. To illustrate my problem, I need to compare the 2 following snipets :
snipet 1 :
library ieee;
use ieee.std_logic_1164.all;
entity foo is
end entity;
architecture sim of foo is
signal clk : std_logic := '0';
signal s : std_logic;
begin
clk <= not clk after 10 ns;
-- driver1
s <= '0';
-- driver2
process (clk) is
begin
s <= clk;
end process;
end architecture;
There is a double assignment for signal s: Driver1 drives the signal s to '0' while driver2 alternatively drives it to '0' and '1'. As we can see on the waveform graph, when clk is '0', the resulting s is '0' (green segments) but when clk is '1', the resulting s is 'X' (red segments).
=> I understand this behaviour, no problem with that one.
If I modify slightly this code by changing driver1 into a process ended with an unconditional wait instruction :
snipet2 :
library ieee;
use ieee.std_logic_1164.all;
entity foo is
end entity;
architecture sim of foo is
signal clk : std_logic := '0';
signal s : std_logic;
begin
clk <= not clk after 10 ns;
-- driver1
-- s <= '0';
process
begin
s <= '0';
wait;
end process;
-- driver2
process (clk) is
begin
s <= clk;
end process;
end architecture;
Surprisingly, for me, the snipet 2 produces the same waveform as the snipet 1. My understanding is that the instructions inside a process with a final "unconditional" wait statement will stop forever, meaning that their code will be inactive after the first execution run. But if this is truly the case, I would expect that driver1 in snipet 2 is inactive after its first run, and that from that point driver2 remains the only active driver of signal s, always assigning clk's alternative '1's and '0's to it.
Why isn't it the case?
When you assign a signal in a process, a driver is created for that signal from the moment it assigned until the end of simulation. So here, both code snippets are functionally equivalent, you create driver1 from time 0 and driver2 from the first clock.
I am designing a parking-lot gate in VHDL. When I simulate it using Quartus VWF files, I am getting unknown values (X), but I don't know why.
Basically you just have to validate your card (Sin) and the gate opens for 10 seconds.
And when a car exits the parking lot (Sout), it counts the total cars at the moment inside of the parking lot.
I have created the signal Ncarros (to count number of cars) and s_count for the timer.
It all compiles correctly. But when I'm testing it using a VWF file, this is what I get:
Original simulation output
I'm using Altera Quartus Prime Lite Edition.
Can someone check my code and tell me what I'm doing wrong?
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.all;
entity MicroProj is
port (clk : in std_logic;
Sin : in std_logic;
Sout : in std_logic;
cancela : out std_logic;
timerOut : out std_logic);
end MicroProj;
architecture Behavioral of MicroProj is
signal Ncarros : integer := 0;
signal s_count : integer := 0;
begin
process (Sin,Sout,clk)
begin
if (Sin = '0') then
cancela <= '0';
else
if (Ncarros < 99) then
Ncarros <= Ncarros + 1;
cancela <= '1';
if(rising_edge(clk)) then
if(s_count /= 0) then
if(s_count = 499999999) then
timerOut <= '1';
s_count <= 0;
else
timerOut <= '0';
s_count <= s_count + 1;
end if;
else
timerOut <= '0';
s_count <= s_count + 1;
end if;
end if;
end if;
end if;
if (Sout ='1') then
Ncarros <= Ncarros - 1;
end if;
end process;
end Behavioral;
When you simulate with a Vector Waveform File (VWF), Quartus-II actually simulates the behaviour of the synthesized netlist (checked here with Quartus-II 13.1). If you haven't run the step "Analysis & Synthesis", Quartus asks to do so. You have to always run this step manually, when you change your VHDL files before simulating the VWF again. The synthesized netlist is written out as Verilog code which will be the input of the ModelSim simulator. You can find it in the file simulation/qsim/microproj.vo.
As long as Quartus reports warnings (or errors), the behavior of the synthesized design can differ from the VHDL description. And this is the case here as pointed out below. To directly simulate the behavior of your VHDL description, you have to write a testbench.
The following testbench will be a good starter. It assign the same input values as in your VWF file for the first 200 ns. You will have to extend the code at the indicated location to add more signal transitions.
library ieee;
use ieee.std_logic_1164.all;
entity microproj_tb is
end entity microproj_tb;
architecture sim of microproj_tb is
-- component ports
signal clk : std_logic := '0';
signal Sin : std_logic;
signal Sout : std_logic;
signal cancela : std_logic;
signal timerOut : std_logic;
begin -- architecture sim
-- component instantiation
DUT: entity work.microproj
port map (
clk => clk,
Sin => Sin,
Sout => Sout,
cancela => cancela,
timerOut => timerOut);
-- clock generation
clk <= not clk after 10 ns;
-- waveform generation
WaveGen : process
begin
Sin <= '0';
Sout <= '0';
wait for 40 ns; -- simulation time = 40 ns
Sin <= '1';
wait for 70 ns; -- simulation time = 110 ns
Sin <= '0';
wait for 50 ns; -- simulation time = 160 ns
Sin <= '1';
-- Extend here to add more signal transistions
wait;
end process WaveGen;
end architecture sim;
The Quartus Prime Lite Edition includes an installation of the ModelSim Altera Edition. You can setup and start the simulation using ModelSim directly within the Quartus project settings. The simulation output for the first 200 ns using my testbench is as follows:
As you see, the output differs from your simulation of the VWF file because the VHDL design itself is simulated now.
In your VHDL code you described latches for the signals cancela and Ncarros as also reported by the "Analysis & Synthesis" step:
Warning (10492): VHDL Process Statement warning at MicroProj.vhdl(26): signal "Ncarros" is read inside the Process Statement but isn't in the Process Statement's sensitivity list
Warning (10492): VHDL Process Statement warning at MicroProj.vhdl(27): signal "Ncarros" is read inside the Process Statement but isn't in the Process Statement's sensitivity list
Warning (10492): VHDL Process Statement warning at MicroProj.vhdl(48): signal "Ncarros" is read inside the Process Statement but isn't in the Process Statement's sensitivity list
Warning (10631): VHDL Process Statement warning at MicroProj.vhdl(21): inferring latch(es) for signal or variable "cancela", which holds its previous value in one or more paths through the process
Warning (10631): VHDL Process Statement warning at MicroProj.vhdl(21): inferring latch(es) for signal or variable "Ncarros", which holds its previous value in one or more paths through the process
Info (10041): Inferred latch for "Ncarros[0]" at MicroProj.vhdl(20)
Info (10041): Inferred latch for "Ncarros[1]" at MicroProj.vhdl(20)
Info (10041): Inferred latch for "Ncarros[2]" at MicroProj.vhdl(20)
...
Info (10041): Inferred latch for "Ncarros[31]" at MicroProj.vhdl(20)
Info (10041): Inferred latch for "cancela" at MicroProj.vhdl(20)
On Altera FPGAs, latches are implemented using the look-up table (LUT) and a combinational feedback path within the logic element (LE). The state of such a latch is undefined after programming the FPGA. The simulation of the synthesized netlist shows this as 'X'es.
I recommend to fix the latches anyway and transform your code into a fullly synchronous, clock-edge driven design. That is, assign new values to cancela and Ncarros only at the rising edge of the clock. The VHDL code pattern is:
process(clk)
begin
if rising_edge(clk) then
-- put all your assignments to cancela and Ncarros here
end if;
end process;
I'm working for my master thesis and I'm pretty new to VHDL, but still I have to implement some complex things. This is one of the easiest structures I had to write, and still I'm encountering some problems.
It's a FSM implementing a 24bit shift register with an active-low sync signal (to program a DAC). It's just the end of a complex elaboration chain I created for my project. I followed the example model of a FSM as much as I could.
The behavioral simulation works fine, actually the whole elaboration chain I created works perfectly fine as far as the behavioral simulation concerns. However, once I try the Post-translate simulation things start to go wrong: lots of 'X' output signals.
With this simple shift register I DON'T get any 'X', however I can't get to the load_and_prepare_data phase. It seems that the current_state changes (by inspecting some signals), but the elaboration doesn't go on.
Please keep in mind that since I'm new to the language, I have no idea of what timing constraints I should set on this FSM (and I wouldn't know how to write them on the top.ucf anyway)
Can you see what's wrong?
Thanks in advance
EDIT
I followed your advices and cleaned up the FSM by using a single state process. I still have some doubts about "where to put what" but I really like the new implementation. Anyway I now get a clean behavioral simulation but 'X' on all outputs in post translate simulation.
What is causing this?
I'll post the both the new code and the testbench:
----------------------------------------------------------------------------------
-- Company:
-- Engineer:
--
-- Create Date: 14:44:03 11/28/2014
-- Design Name:
-- Module Name: dac_ad5764r_24bit_sr_programmer_v2 - Behavioral
-- Project Name:
-- Target Devices:
-- Tool versions:
-- Description: This is a PISO shift register that gets a 24bit parallel input word.
-- It outputs the 24bit input word starting from the MSB and enables
-- an active low ChipSelect line for 24 clock periods.
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;
-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity dac_ad5764r_24bit_sr_programmer_v2 is
Port ( clk : in STD_LOGIC;
start : in STD_LOGIC;
reset : in STD_LOGIC; -- Note that this reset is for the FSM not for the DAC
reset_all_dac : in STD_LOGIC;
data_in : in STD_LOGIC_VECTOR (23 downto 0);
serial_data_out : out STD_LOGIC;
sync_out : out STD_LOGIC; -- This is a chip select
reset_out : out STD_LOGIC;
busy : out STD_LOGIC
);
end dac_ad5764r_24bit_sr_programmer_v2;
architecture Behavioral of dac_ad5764r_24bit_sr_programmer_v2 is
-- Stati
type state_type is (idle, load_and_prepare_data, transmission);
--ATTRIBUTE ENUM_ENCODING : STRING;
--ATTRIBUTE ENUM_ENCODING OF state_type: TYPE IS "001 010 100";
signal state: state_type := idle;
--signal next_state: state_type := idle;
-- Clock counter
--signal clk_counter_enable : STD_LOGIC := '0';
signal clk_counter : unsigned(4 downto 0) := (others => '0');
-- Shift register
signal stored_data: STD_LOGIC_VECTOR (23 downto 0) := (others => '0');
begin
FSM_single_process: process(clk)
begin
if rising_edge(clk) then
if reset = '1' then
serial_data_out <= '0';
sync_out <= '1';
reset_out <= '1';
busy <= '0';
state <= idle;
else
-- Default
serial_data_out <= '0';
sync_out <= '1';
reset_out <= '1';
busy <= '0';
case (state) is
when transmission =>
serial_data_out <= stored_data(23);
sync_out <= '0';
busy <= '1';
clk_counter <= clk_counter + 1;
stored_data <= stored_data(22 downto 0) & "0";
state <= transmission;
if (clk_counter = 23) then
state <= idle;
end if;
when others => -- Idle
if start = '1' then
serial_data_out <= data_in(23);
sync_out <= '0';
reset_out <= '1';
busy <= '1';
stored_data <= data_in;
clk_counter <= "00001";
state <= transmission;
end if;
end case;
-- if (reset_all_dac = '1') then
-- reset_out <= '0';
-- end if;
end if;
end if;
end process;
end;
And the testbench:
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
--USE ieee.numeric_std.ALL;
ENTITY dac_ad5764r_24bit_sr_programmer_tb IS
END dac_ad5764r_24bit_sr_programmer_tb;
ARCHITECTURE behavior OF dac_ad5764r_24bit_sr_programmer_tb IS
-- Component Declaration for the Unit Under Test (UUT)
COMPONENT dac_ad5764r_24bit_sr_programmer_v2
PORT(
clk : IN std_logic;
start : IN std_logic;
reset : IN std_logic;
data_in : IN std_logic_vector(23 downto 0);
serial_data_out : OUT std_logic;
reset_all_dac : IN std_logic;
sync_out : OUT std_logic;
reset_out : OUT std_logic;
--finish : OUT std_logic;
busy : OUT std_logic
);
END COMPONENT;
--Inputs
signal clk : std_logic := '0';
signal start : std_logic := '0';
signal reset : std_logic := '0';
signal data_in : std_logic_vector(23 downto 0) := (others => '0');
signal reset_all_dac : std_logic := '0';
--Outputs
signal serial_data_out : std_logic;
signal sync_out : std_logic;
signal reset_out : std_logic;
--signal finish : std_logic;
signal busy : std_logic;
-- Clock period definitions
constant clk_period : time := 100 ns;
BEGIN
-- Instantiate the Unit Under Test (UUT)
uut: dac_ad5764r_24bit_sr_programmer_v2 PORT MAP (
clk => clk,
start => start,
reset => reset,
data_in => data_in,
reset_all_dac => reset_all_dac,
serial_data_out => serial_data_out,
sync_out => sync_out,
reset_out => reset_out,
--finish => finish,
busy => busy
);
-- Clock process definitions
clk_process :process
begin
clk <= '0';
wait for clk_period/2;
clk <= '1';
wait for clk_period/2;
end process;
-- Stimulus process
stim_proc: process
begin
-- hold reset state for 100 ns.
wait for clk_period*10;
reset <= '1' after 25 ns;
wait for clk_period*1;
reset <= '0' after 25 ns;
wait for clk_period*3;
reset_all_dac <= '1' after 25 ns;
wait for clk_period*1;
reset_all_dac <= '0' after 25 ns;
wait for clk_period*5;
data_in <= "111111111111111111111111" after 25 ns;
wait for clk_period*3;
start <= '1' after 25 ns;
wait for clk_period*1;
start <= '0' after 25 ns;
wait;
end process;
END;
UPDATE 1
Updated with the last design: this code is not causing any 'X' (can't figure out why, this doesn't but the previous did). However it's not starting (in POST-TRANSLATE simulation) just like the first 3 process machine, and the signal sync_out is stuck at 0 while it should be '1' by default.
UPDATE 2
I've been looking into the tecnology schematic, starting from the problem of the sync_out=0: it's implemented with a FDS, S is the FSM reset signal, D is coming from a LUT3 with I = state&reset&start and INIT = 45 = "00101101". I've looked for this LUT3 in the simulation and I've noticed that it has INIT = "00000000"!
Is there something I'm missing about how to run this simulation? It seems that every LUT in the design have not been set!
UPDATE 3
It seems that the Post-Translate simulation is buggy in some way, or I'm not configuring it correctly for some reason: the Post-Map and the Post-PAR simulations work and display some outputs.
However there is an odd bug: the stored_data register is not updated with the complete data_in vector, after that, the FSM operates correctly and outputs the data stored.
I've looked in the tecnology schematic just after synthesis and for some reason the bits 23,22,21,19,18 are not connected to the corresponding data_in bit. You can see the effect in this screenshot from Post-Map simulation. Same happens in Post-PAR, but it seems that this problems comes directly from the synthesis!
Solved: the strange output comes from the Synthesis optimization. The tool realized that the previous block in the elaboration chain will never output a bit different from 0 for those specific bit. My mistake was assuming that I could test the single block alone: what I was really testing was the block synthetized for the FPGA taking into account everything else in the design!
Thanks to everybody helped me, I'm going to follow your advices!
I prefer the single-process form of state machine, which is cleaner, simpler and much less prone to bugs like sensitivity-list errors. I would also endorse the points in Paebbels' excellent answer. However I don't think any of these are the problem here.
One thing to be aware of in post-synth and post-PAR simulations is that their model of time is different from the behavioural model. The behavioural model follows simple rules as I described in this answer and ensures that in a typical design flow you can go straight to hardware - without post-synth simulation, without worry.
Indeed I only use post-synth or post-PAR simulations if I'm chasing a suspected tool bug. (For FPGA designs, not ASIC, that is!)
However, that simple timing model has its limitations. You may be familiar with problems like a clock signal assigned via signal assignment (usually buried in a 3rd party model where you don't expect it) which consumes a delta cycle, and ensures that your clocked data arrives before your clock instead of after, and everything subsequently occurs one cycle earlier than intended...
In behavioural modelling, a little discipline will keep clear of such troubles. But the same is not true of post-PAR modelling.
Your testbench is probably set up the same way as the behavioural model. And if so, that is likely to be the problem.
Here's what I do in this situation : I claim no formal authority for it, just experience. It also works well when interfacing the FPGA to external memory models with realistic timings.
1) I assume the simple (behavioural) timing model works correctly for all signals INTERNAL to the design.
2) I assume nothing of the sort for inputs and outputs from the design.
3) I take note of the estimated setup and hold timings on the inputs, (a) from the FPGA datasheet or better, (b) from the worst case values shown in the post-synth or post-PAR report, and structure the testbench around them.
Worked example : setup time 1 ns, hold time 2 ns, clock period 10 ns. This means that any input between 2 ns and 9 ns after a clock edge is guaranteed to be corrrectly read. I choose (arbitrarily) 5 ns.
signal_to_fpga <= driving_value after 5 ns;
(Note that Xilinx makes this absurdly counter-intuitive by expressing them as "offset in/out before/after" which refers timings to a previous or future clock edge instead of the one you're looking at)
Alternatively, if the input is fed from a CPU or memory in the real world, I use datasheet timing specifications for that device.
4) I take note of the worst case clk-out timing reported in the datasheet or report, and structure the design around them. (say, 7 ns)
fpga_output_pin <= driving_value after 7 ns;
Note that this "after" clause is obviously ignored by synthesis; however the post-synth back-annotation will introduce something very like it.
5) If this turns out to be not good enough, then (possibly in a wrapper component to avoid polluting the synthesisable code) improve accuracy like
fpga_output_pin <= 'X' after 1 ps, driving_value after 7 ns;
6) I re-run the behavioural simulation. Typically, it now fails, because it was written without realistic timings in mind.
7) I fix those failures. This may include adding realistic delays before testing values output from the design. It can be an iterative process.
Now, I have a reasonable expectation that the post-PAR simulation model will drop straight in to the testbench and work.
Here are some hints to improve your code:
You can remove the Xilinx dependencies to UNISIM, because you are not using any Xilinx Primitves.
Applying attribute ENUM_ENCODING has no effect on state encoding unless you also define the attribute FSM_ENCODING and set it's value to user. One-Hot encoding can be forced by setting FSM_ENCODING to one-hot. Normally synthesis is smart enough to find the best encoding.
read more ...
None of your registers has a default value:
signal current_state : state_type := idle;
Your FSM is no FSM in the eyes of Xilinx synthesis tool (XST). I'm sure if you look into your synthesis report, you won't find that XST reports a FSM for current_state.
So what's wrong with your FSM?
Your FSM has no initial state.
Your FSM has multiple reset states (idle, load_and_prepare_data)
Your FSM has no transition from idle to load_and_prepare_data (reset is no transition)
Writing next_state transitions for the current state can cause XST to think it's no FSM
the default assignment next_state <= current_state; is sufficient.
If you change the type of signal clk_counter to unsigned you can do arithmetic much easier.
increment: clk_counter <= clk_counter + 1;
clear: clk_counter <= (others => '0');
compare: if (clk_counter = 23) then
It's no good style to use the FSM's state signal outside of the FSM processes.
FSM_next_state_process: process(current_state, start, clk_counter, reset_all_dac)
begin
next_state <= current_state;
OutReg_busy <= '1';
OutReg_reset_out <= '1';
OutReg_sync_out <= '1';
clk_counter_enable <= '0';
case (current_state) is
when idle =>
OutReg_busy <= '0';
if (reset_all_dac = '1') then
OutReg_reset_out <= '0';
end if;
when load_and_prepare_data =>
next_state <= transmission;
when transmission =>
clk_counter_enable <= '1';
OutReg_sync_out <= '0';
if (clk_counter = 23) then
next_state <= idle;
end if;
when others =>
next_state <= idle;
end case ;
end process;
I need a flip flop that reacts on the edges of two different signals. Something like this:
if(rising_edge(sig1)) then
bit <= '0';
elsif(rising_edge(sig2)) then
bit <= '1';
end if;
Does such a flip flop exist or is there some other technique i could use?
I need this to be synthesizable on a Xilinx Virtex-5 FPGA.
Thanks
What I'd usually do in this case is to keep a delayed version of both the control signals and generate a pulse one clock wide at the rising edge of each signal. I'd then use these pulses to drive a tiny FSM to generate the 'bit' signal. Here's some VHDL below.
-- -*-vhdl-*-
-- Finding edges of control signals and using the
-- edges to control the state of an output variable
--
library ieee;
use ieee.std_logic_1164.all;
entity stackoverflow_edges is
port ( clk : in std_ulogic;
rst : in std_ulogic;
sig1 : in std_ulogic;
sig2 : in std_ulogic;
bito : out std_ulogic );
end entity stackoverflow_edges;
architecture rtl of stackoverflow_edges is
signal sig1_d1 , sig2_d1 : std_ulogic;
signal sig1_rise, sig2_rise : std_ulogic;
begin
-- Flops to store a delayed version of the control signals
-- If the contorl signals are not synchronous with clk,
-- consider using a bank of 2 delays and using those outputs
-- to generate the edge flags
delay_regs: process ( clk ) is
begin
if rising_edge(clk) then
if rst = '1' then
sig1_d1 <= '0';
sig2_d1 <= '0';
else
sig1_d1 <= sig1;
sig2_d1 <= sig2;
end if;
end if;
end process delay_regs;
-- Edge flags
edge_flags: process (sig1, sig1_d1, sig2, sig2_d1) is
begin
sig1_rise <= sig1 and not sig1_d1;
sig2_rise <= sig2 and not sig2_d1;
end process edge_flags;
-- Output control bit
output_ctrl: process (clk) is
begin
if rst = '1' then
bito <= '0';
elsif sig1_rise = '1' then
bito <= '1';
elsif sig2_rise = '1' then
bito <= '0';
end if;
end process output_ctrl;
end rtl;
I'm a lot more comfortable in verilog, so double check this VHDL (any comments appreciated).
waveforms http://img33.imageshack.us/img33/893/stackoverflowvhdlq.png
This code assumes that the clock is fast enough to capture all the control signal pulses. If the control signals are not synchronous with the clock, I'd keep a further delayed version of the delayed control signal (eg sig_d2) then make the flags from sig_d1 and sig_d2.