Simple SR Latch Simulation in VHDL(with Xilinx) doesn't oscillate

Question

I've learned that SR-Latch does oscillate when S and R are both '0' after they were just '1' in following circuit VHDL Code.

here is VHDL of SRLATCH

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity SRLATCH_VHDL is
port(
        S : in STD_LOGIC;
        R : in STD_LOGIC;
        Q : inout STD_LOGIC;
        NOTQ: inout STD_LOGIC);
end SRLATCH_VHDL;

architecture Behavioral of SRLATCH_VHDL is
begin

process(S,R,Q,NOTQ)
    begin
        Q <= R NOR NOTQ;
        NOTQ<= S NOR Q;
end process;

end Behavioral;

and followings are process in Testbench code and its simulation results

   -- Stimulus process
   stim_proc: process
   begin        
    S <= '1'; R <= '0'; WAIT FOR 100NS;
    S <= '0'; R <= '0'; WAIT FOR 100NS;
    S <= '0'; R <= '1'; WAIT FOR 100NS;
    S <= '0'; R <= '0'; WAIT FOR 100NS;
    S <= '1'; R <= '1'; WAIT FOR 500NS;
   end process;

and totally I don't have any idea why simulation doesn't reflect...

(click to enlarge)

You haven't provided a [Minimal, Complete and Verifiable example](https://stackoverflow.com/help/mcve) demonstrating oscillation nor does your provided stimuli do so. The cure is to unbalance the delays so one wins. It's the equivalent of providing a consensus term. In clocked flip flops this is where set up and hold time comes from as well as the impetus to use master slave flip flops. We're dealing with the lost art of digital design and an abstraction with zero gate delays. — , Oct 14 '17 at 17:32
If you were to add uniform delays to the assignments of Q and NOTQ: `Q <= R NOR NOTQ after 1 ns; NOTQ <= S NOR Q after 1 ns;` and provide a '0' to '1' transition on both S and R in the same delta cycle (no intervening WAIT) you could demonstrate the [oscillation](https://i.stack.imgur.com/d23rt.png "srlatch_vhdl_with_delay.png") without requiring a waveform display that can show delta cycles or cause a maximum number of delta cycles to be exceeded. — , Oct 14 '17 at 21:22

Paebbels · Accepted Answer · 2017-10-14T16:51:54.943

2

Someone is teaching you wrong knowledge!

SR and RS basic flip-flops (also called latches) don't oscillate. The problem on S = R = 1 (forbidden) is that you don't know the state after you leave S = R = 1 because you can never go to S = R = 0 (save) simultaneously. You will transition for S = R = 1 to S = R = 0 through S = 1; R = 0 (set) or S = 0; R = 1 (reset). This will trigger either a set or reset operation before you arrive in state save.

Be aware that VHDL simulates with discrete time and is reproducing the same simulation results on every run. You can not (easily) simulate physical effects that cause different signal delays per simulation run.

Btw. you VHDL description is also wrong. Q and NOTQ are of mode out, not inout. Use either a proper simulator supporting VHDL-2008 (that allows read back of out-ports) or use an intermediate signal.

edited Oct 14 '17 at 16:51

answered Oct 14 '17 at 16:44

Paebbels

15,573
13
70
139

THANX A LOT :) I just meant that after S=R=1, S=R=0 state do oscillate! I solved this problem. as you answered me, its just about isim thing. time scale is almost same with '0' in isim, so there are isim error that iteration limit '10000' ! I solved it by delaying in definition of behavior :) Thanks for you again :) – Seung Jin Lee Oct 14 '17 at 16:55
The OP is telling you grafting `s <= '0'; r <= '0'; wait for 100 ns;` to the end of the existing stim_proc following `s <= '1'; r <= '1'; wait for 500 ns;` will cause delta cycle oscillations - `simulation stopped by --stop-delta`. The OP's question does not demonstrate the problem not providing a [Minimal, Complete and Verifiable example](https://stackoverflow.com/help/mcve) nor does you answer address the problem he has related anecdotally. – Oct 14 '17 at 17:18
With identical assignment delays to Q and NOTQ you can get a waveform that shows oscillation. Unbalance the delays and one side wins when S and R are both '1'. There's an easy way using a consensus term - google *hazard logic* or *Earle latch* (a D latch with a consensus term to prevent oscillation, J. G. Earle of IBM). There is nothing inherently forbidding S and R to go from both '1' to both '0' simultaneously. In physical implementations it can be quit rare but does occur, usually representing a setup or hold time violation. Routing tends to unbalance delays. – Oct 14 '17 at 17:26
A general cure for clocked flip flops is to used Master Slave flip flops where the setup and hold times can be rigidly characterized. – Oct 14 '17 at 17:29
@paebbels: you should consider fixing this answer or taking it down. Real (and simulated) circuits *do* show metastable output behaviour, including actual oscillations, for exactly this reason - this is what metastability is all about. How long this goes on for depends on, IIRC, the gain-bandwidth product of the relevant output stages, and so is highly technology-dependent, but it always happens. – EML Oct 29 '17 at 12:00
@eml My answer is still correct for physical implementations according to the original question. Yes you can misuse VHDL and the event queue to provoke such a behavior, but it doesn't reflect what's physically happening. At next, don't confuse metastability with oscillation, these are two different effects. Btw. the OP drastically changed his question after I posted my answer. Unfortunately, SO does not notify me if the OP changes his question. – Paebbels Oct 29 '17 at 15:27
@paebbels - sorry, your answer isn't remotely correct, for any physical implementation. Your reasoning would only work for an *infinitely*-fast implementation; draw the circuit and trace it out. Or you could Spice it in 10 minutes - this is trivial in LTspice, or just Google it. This is nothing to do with VHDL. Oscillation is one manifestation of what we call 'metastability'. In most practical circuits an oscillation will show as a glitch, but they are the same thing. Your answer shows that you understood the OP's issue *before* his edit - you say you can't go to `S=R=0` simultaneously. – EML Oct 30 '17 at 08:58

score 2 · Answer 2 · answered Oct 18 '17 at 08:32

Nice question, and your instructor is right - this circuit will oscillate if both S and R are released at the "same" time. Your issue is that your TB isn't doing this, but this one does:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity TOP is
end entity TOP;

architecture A of TOP is
  signal S,R,Q,NOTQ: std_logic;

  component SRLATCH_VHDL is
    port(
      S    : in    std_logic;
      R    : in    std_logic;
      Q    : inout std_logic;
      NOTQ : inout std_logic);
  end component SRLATCH_VHDL;

begin
  U1 : SRLATCH_VHDL port map(S, R, Q, NOTQ);

  process is
  begin
    S <= '1';
    R <= '1';
    wait for 10 ns;
    S <= '0';
    R <= '0';
    wait;
  end process;
end architecture A;

This will produce infinite delta-delay oscillation:

This isn't a great way to demonstrate asynchronous behaviour, because you are effectively simplifying the physical nature of the circuit, and using the VHDL scheduler to show that there's a problem (with the use of 'delta delays'). A better way to do this is to model real circuit behaviour by adding signal delays (this is exactly what your tools are doing when they back-annotate for timing simulations). Look up signal assignments with after, and the difference between transport and inertial delays. If you draw a circuit diagram, you'll see that the issue arises if both S and R are released in a 'small' time window that doesn't allow the signal propagation around your circuit to complete before the second control signal changes. You now need to write a testbench that changes S and R inside this time window.

Pretty much everything you ever design will be asynchronous, in exactly the same way as your SR circuit. We make circuits 'synchronous' only by ensuring that input signals don't change at the same time. The job of the timing tools is to tell us what 'same' actually means: when you get a report or a datasheet value giving you a setup or a hold time, then that number is simply the numerical version of 'not the same'.

Simple SR Latch Simulation in VHDL(with Xilinx) doesn't oscillate

2 Answers2