Q: Coding style in violation of IEEE-1364? 
Author Message
 Q: Coding style in violation of IEEE-1364?

Hi,

Is our coding style in violation of IEEE-1364?
Our simulator vendor claims it is relying on undermined behavior
in the Verilog spec and inducing a race condition.  This code
is supposed to replicate two of our state machines.  After
instrumentation with our code coverage tool the simulation
hangs.  The $display's inserted seem to cause the same
behavior.

Here is our example (test1.v) and a fix (test3.v).

Thanks,
/Ed

PS: Is there a tool on the market which detects race
condition like these (assuming our code is at fault)?

% <simulator> test1.v                             # passes
% <simultaor> test1.v +define+HANG    # HANGS!  (This is bad!)

// test1.v:
//
`define ADD_HANG `ifdef HANG if (1) $display("Hang"); `endif
//

module test;
   reg reset,clk,ism_busy,start_ism;
   reg [2:0] bstate_reg,bstate;
   reg [4:0] istate_reg,istate;

   initial begin
      $monitor("Time %0t istate %h, bstate %h start_ism %h ism_busy %h",

               $time,istate_reg,bstate_reg,start_ism, ism_busy);
      clk = 0;
      repeat (10) #10 clk = ~clk;
   end

   initial begin
      #10 reset = 1;
      #10 reset = 0;
   end


      if (reset) begin
         bstate_reg <= 0;
         istate_reg <= 0;
      end
      else begin
         bstate_reg <= bstate;
         istate_reg <= istate;
      end
   end


      start_ism = 0;
      bstate = bstate_reg;
      `ADD_HANG
      case (bstate_reg)
        3'h0: bstate = 3'h1;
        3'h1: bstate = 3'h2;
        3'h2: begin
           start_ism = 1;
           bstate = 3'h4;
        end
        default:;
      endcase
   end


      ism_busy = 1;
      istate = istate_reg;
      `ADD_HANG
      case (istate_reg)
        5'h0: begin
           ism_busy = 0;
           if (start_ism) istate = 5'b1;
        end
        5'h1: istate = 5'b0;
        default:;
      endcase
   end
endmodule
// end of test1.v

% <simulator> test3.v                             # passes
% <simulator> test3.v +define+HANG    # passes!!!!

// test3.v:
//
`define ADD_HANG `ifdef HANG if (1) $display("Hang"); `endif
//

module test;
   reg reset,clk;
   wire ism_busy,start_ism;
   reg [2:0] bstate_reg,bstate;
   reg [4:0] istate_reg,istate;

   initial begin
      $monitor("Time %0t istate %h, bstate %h start_ism %h ism_busy %h",

               $time,istate_reg,bstate_reg,start_ism, ism_busy);
      clk = 0;
      repeat (10) #10 clk = ~clk;
   end

   initial begin
      #10 reset = 1;
      #10 reset = 0;
   end


      if (reset) begin
         bstate_reg <= 0;
         istate_reg <= 0;
      end
      else begin
         bstate_reg <= bstate;
         istate_reg <= istate;
      end
   end

   assign start_ism = (bstate_reg == 3'h2) ? 1'b1 : 1'b0;


      bstate = bstate_reg;
      `ADD_HANG
      case (bstate_reg)
        3'h0: bstate = 3'h1;
        3'h1: bstate = 3'h2;
        3'h2: begin
           bstate = 3'h4;
        end
        default:;
      endcase
   end

   assign ism_busy = (istate_reg == 5'h0) ? 1'b0 : 1'b1;


      istate = istate_reg;
      `ADD_HANG
      case (istate_reg)
        5'h0: begin
           if (start_ism) istate = 5'b1;
        end
        5'h1: istate = 5'b0;
        default:;
      endcase
   end
endmodule
// end test3.v

--



Mon, 04 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?


Quote:
> Hi,

> Is our coding style in violation of IEEE-1364?
> Our simulator vendor claims it is relying on undermined behavior
> in the Verilog spec and inducing a race condition.  This code
> is supposed to replicate two of our state machines.  After
> instrumentation with our code coverage tool the simulation
> hangs.  The $display's inserted seem to cause the same
> behavior.

> Here is our example (test1.v) and a fix (test3.v).

> Thanks,
> /Ed

Hi Ed,

I think the problem is that IEEE-1364 does not say anything at all about
this situation. Hence, it is possible that some simulation toools might
cause a hang. In fact, I have seen some simulation hangs due to these
kind of constructs.

Whether the tool hangs, or, gives an o/p that you had intended will
depend on various things, including the simulator being used, the
version, the command-line options, or, maybe, even a seemingly unrelated
modification in some other unrelated part of the code.
Probably, this is why, the code which seems to work fine normally,
starts misbehaving on Instrumentation, or, on adding the $display.

Regards,
sanjay

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Tue, 05 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?
Ed,

your first module hangs for me after 30ns. It appears to be due to recursive
calling of two combinational always blocks which start...


...and...


The first block causes an event on "start_ism" which triggers the second
block, which causes an event on "ism_busy", which triggers the first one,
which causes an event on "start_ism" which triggers the second one - etc.

I notice that "ism_busy" does not appear in the body of the first of these
two blocks, so it should not be necessary to include it in the sensitivity
list. Indeed, when I deleted it from the sensitivity list the simulation
ran to 50ns and completed.

In your second module the assignments to "start_ism" and "ism_busy" are
made outside of the always blocks with continouous assignments, and, more
importantly, they are not inter-dependant, so the recursive loop is broken.

Incidentally, I notice that your first always block triggers on both edges
of the clock. Is that intentional? Normally I would expect to see an edge
triggered block with active high asynchronous reset coded as follows...


If it is intentional, then, just out of interest, can you tell me what your
synthesis tool produces?

If your Verilog was not IEEE-1364 compliant then I would expect the simulator
to flag a syntax error.

Regards, Robert.

Quote:

> Hi,

> Is our coding style in violation of IEEE-1364?
> Our simulator vendor claims it is relying on undermined behavior
> in the Verilog spec and inducing a race condition.  This code
> is supposed to replicate two of our state machines.  After
> instrumentation with our code coverage tool the simulation
> hangs.  The $display's inserted seem to cause the same
> behavior.

> Here is our example (test1.v) and a fix (test3.v).

> Thanks,
> /Ed

> PS: Is there a tool on the market which detects race
> condition like these (assuming our code is at fault)?

> % <simulator> test1.v                             # passes
> % <simultaor> test1.v +define+HANG    # HANGS!  (This is bad!)

> // test1.v:
> //
> `define ADD_HANG `ifdef HANG if (1) $display("Hang"); `endif
> //

> module test;
>    reg reset,clk,ism_busy,start_ism;
>    reg [2:0] bstate_reg,bstate;
>    reg [4:0] istate_reg,istate;

>    initial begin
>       $monitor("Time %0t istate %h, bstate %h start_ism %h ism_busy %h",

>                $time,istate_reg,bstate_reg,start_ism, ism_busy);
>       clk = 0;
>       repeat (10) #10 clk = ~clk;
>    end

>    initial begin
>       #10 reset = 1;
>       #10 reset = 0;
>    end


>       if (reset) begin
>          bstate_reg <= 0;
>          istate_reg <= 0;
>       end
>       else begin
>          bstate_reg <= bstate;
>          istate_reg <= istate;
>       end
>    end


>       start_ism = 0;
>       bstate = bstate_reg;
>       `ADD_HANG
>       case (bstate_reg)
>         3'h0: bstate = 3'h1;
>         3'h1: bstate = 3'h2;
>         3'h2: begin
>            start_ism = 1;
>            bstate = 3'h4;
>         end
>         default:;
>       endcase
>    end


>       ism_busy = 1;
>       istate = istate_reg;
>       `ADD_HANG
>       case (istate_reg)
>         5'h0: begin
>            ism_busy = 0;
>            if (start_ism) istate = 5'b1;
>         end
>         5'h1: istate = 5'b0;
>         default:;
>       endcase
>    end
> endmodule
> // end of test1.v

> % <simulator> test3.v                             # passes
> % <simulator> test3.v +define+HANG    # passes!!!!

> // test3.v:
> //
> `define ADD_HANG `ifdef HANG if (1) $display("Hang"); `endif
> //

> module test;
>    reg reset,clk;
>    wire ism_busy,start_ism;
>    reg [2:0] bstate_reg,bstate;
>    reg [4:0] istate_reg,istate;

>    initial begin
>       $monitor("Time %0t istate %h, bstate %h start_ism %h ism_busy %h",

>                $time,istate_reg,bstate_reg,start_ism, ism_busy);
>       clk = 0;
>       repeat (10) #10 clk = ~clk;
>    end

>    initial begin
>       #10 reset = 1;
>       #10 reset = 0;
>    end


>       if (reset) begin
>          bstate_reg <= 0;
>          istate_reg <= 0;
>       end
>       else begin
>          bstate_reg <= bstate;
>          istate_reg <= istate;
>       end
>    end

>    assign start_ism = (bstate_reg == 3'h2) ? 1'b1 : 1'b0;


>       bstate = bstate_reg;
>       `ADD_HANG
>       case (bstate_reg)
>         3'h0: bstate = 3'h1;
>         3'h1: bstate = 3'h2;
>         3'h2: begin
>            bstate = 3'h4;
>         end
>         default:;
>       endcase
>    end

>    assign ism_busy = (istate_reg == 5'h0) ? 1'b0 : 1'b1;


>       istate = istate_reg;
>       `ADD_HANG
>       case (istate_reg)
>         5'h0: begin
>            if (start_ism) istate = 5'b1;
>         end
>         5'h1: istate = 5'b0;
>         default:;
>       endcase
>    end
> endmodule
> // end test3.v

> --


--
=========================================================================
Robert R Fairlie - IC Design, Motorola, Scotland, Tel.  - +44 1355 356039
=========================================================================


Tue, 05 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?

Quote:

> The first block causes an event on "start_ism" which triggers the second
> block, which causes an event on "ism_busy", which triggers the first one,
> which causes an event on "start_ism" which triggers the second one - etc.

> I notice that "ism_busy" does not appear in the body of the first of these
> two blocks, so it should not be necessary to include it in the sensitivity
> list. Indeed, when I deleted it from the sensitivity list the simulation
> ran to 50ns and completed.

> In your second module the assignments to "start_ism" and "ism_busy" are
> made outside of the always blocks with continouous assignments, and, more
> importantly, they are not inter-dependant, so the recursive loop is broken.

> Incidentally, I notice that your first always block triggers on both edges
> of the clock. Is that intentional? Normally I would expect to see an edge
> triggered block with active high asynchronous reset coded as follows...


> If it is intentional, then, just out of interest, can you tell me what your
> synthesis tool produces?

Robert:

This is an oversimplification of some code
extracted from a >1,000 line file.  In the
original source ism_busy and start_ism are
used to determine the next state in some
of the states.  Also, yes, it should be
posedge.  The real code is supposed to be
synthesizable, obviously this isn't.

/Ed
--



Tue, 05 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?
Received this by email from a former colleague:

  You should know better than that, in the first example you're passing blocking
assigned signals between always blocks... this is a race condition / (i.e. how
things get evaluated is simulator dependant), make them non-blocking
(in effect what the assign does... it introduces a delay of one eval cycle
into the signal).

  it worse that the two always blocks are interlocked (sort of) by these two
signals...

--



Tue, 05 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?


Quote:
>Received this by email from a former colleague:

>  You should know better than that, in the first example you're passing blocking
>assigned signals between always blocks... this is a race condition / (i.e. how
>things get evaluated is simulator dependant), make them non-blocking
>(in effect what the assign does... it introduces a delay of one eval cycle
>into the signal).

>  it worse that the two always blocks are interlocked (sort of) by these two
>signals...

>--


Hi Ed,

As sombody mentioned before, you had two cross coupled combinational
blocks, which effectively generated a combinational loop. The signals
in the loop apparently oscilated and because they never settled, the
simulation time never progressed. This has nothing to do with the
semantics of the language, and I suspect that any simulator would
"hang". Also, the synthesis tool would be able to synthesize, but the
resulting hardware would oscilate. The only difference between the
simulation and the actual hardware is that in the simulation the
oscilation occurs in zero time, whereas in the hardware there are
finite delays.

And now for the main point \begin{commercial} although Verilint would
not detect combinational loops, our new tool, RTL Explorer does detect
such combinational loops (and does much much more). For more info,
contact Avant!, www.avanticorp.com, (510) 413-8000. \end{commercial}

Eli
--
Eli Sternheim
AVANT! Corp.
46871 Bayside Pkwy,
Fremont, CA 94538



Tue, 05 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?
<snip>

Quote:
> And now for the main point \begin{commercial} although Verilint would
> not detect combinational loops, our new tool, RTL Explorer does detect
> such combinational loops (and does much much more). For more info,
> contact Avant!, www.avanticorp.com, (510) 413-8000. \end{commercial}

Hmmm.  Should we be happy with a language (or design methodology)
in which such constructs are legal at all?

or, to put it in historical context:  the fact that C needed lint
surely proved beyond doubt that C was in serious need of change;
how about our present-day HDLs?

must've been drinking too hard tonite

Jonathan Bromley



Tue, 05 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?

Quote:

> Hi Ed,

> As sombody mentioned before, you had two cross coupled combinational
> blocks, which effectively generated a combinational loop. The signals
> in the loop apparently oscilated and because they never settled, the
> simulation time never progressed. This has nothing to do with the
> semantics of the language, and I suspect that any simulator would
> "hang". Also, the synthesis tool would be able to synthesize, but the
> resulting hardware would oscilate. The only difference between the
> simulation and the actual hardware is that in the simulation the
> oscilation occurs in zero time, whereas in the hardware there are
> finite delays.
Jonathan Bromley writes:
> Hmmm.  Should we be happy with a language (or design methodology) in
> which such constructs are legal at all?

> Or, to put it in historical context: the fact that C needed lint
> surely proved beyond doubt that C was in serious need of change; how
> about our present-day HDLs?

In C, C++, fortran, Pascal, Java, (insert Turing complete programming
language here), one can code an infinite loop.

The user <apparently> has an infinite loop, this time coded in
Verilog.  If it was not possible to construct an infinite loop in a
given language, many programs would not be easy to write.  For
example, a GUI program, which waits for users input, looks like:

        while(1) {
           get_something_to_do();
           do_it();
        }

        instead, one would have to write
        for (i = i; i < 1000000; i++) { ... }

        and accept a limitation of 1000000 operations... (probably
adequate for a PC, but :-)

--

   /\//    SureFire Verification Inc.   408-374-4100 x 100
  /\///\   <http://www.surefirev.com>   408-374-4174 FAX
 _\///\/        Formerly Silicon Sorcery
  \//\/    Get my verilog emacs mode from
    \/     <http://www.surefirev.com/verilog-mode.html>



Tue, 05 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?


Quote:

><snip>
>> And now for the main point \begin{commercial} although Verilint would
>> not detect combinational loops, our new tool, RTL Explorer does detect
>> such combinational loops (and does much much more). For more info,
>> contact Avant!, www.avanticorp.com, (510) 413-8000. \end{commercial}

>Hmmm.  Should we be happy with a language (or design methodology)
>in which such constructs are legal at all?

>or, to put it in historical context:  the fact that C needed lint
>surely proved beyond doubt that C was in serious need of change;
>how about our present-day HDLs?

>must've been drinking too hard tonite

>Jonathan Bromley

Combinational loops are legitimate hardware constructs. You would not
want to create one unintentionally, but for example if you want to
build a flipflop from gates you need to use one. Another example is a
clock oscilator. Surely every HDL shoule let you build flipflops and
oscilators.

Eli

--
Eli Sternheim
AVANT! Corp.
46871 Bayside Pkwy,    Fremont, CA 94538



Fri, 08 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?

Quote:




> ><snip>
> >> And now for the main point \begin{commercial} although Verilint would
> >> not detect combinational loops, our new tool, RTL Explorer does detect
> >> such combinational loops (and does much much more). For more info,
> >> contact Avant!, www.avanticorp.com, (510) 413-8000. \end{commercial}

> >Hmmm.  Should we be happy with a language (or design methodology)
> >in which such constructs are legal at all?

> >or, to put it in historical context:  the fact that C needed lint
> >surely proved beyond doubt that C was in serious need of change;
> >how about our present-day HDLs?

> >must've been drinking too hard tonite

> >Jonathan Bromley

> Combinational loops are legitimate hardware constructs. You would not
> want to create one unintentionally, but for example if you want to
> build a flipflop from gates you need to use one. Another example is a
> clock oscilator. Surely every HDL shoule let you build flipflops and
> oscilators.

> Eli

I fully agree that combinational loops are legitimate, but what interested
me particularly about the original construct desrcibed in this thread was
the fact that the loop in question was not actually oscillating. Each
iteration around the loop reassigned the signals to the same value as the
last iteration. It would appear that reassigning a signal its own value
still constitutes an event which is able to trigger an always-block if that
signal is in the always-block's sensitivity list.

Now you might argue that it is a legitimate question to ask "should a block
only trigger if a signal in its sensitivity list *changes value*, rather
than just gets an event?". Perhaps the language could use another event
expression qualifier to add to "posedge" and "negedge", such as "changing"
or whatever.

Regards, Robert
--
=========================================================================
Robert R Fairlie - IC Design, Motorola, Scotland, Tel.  - +44 1355 356039
=========================================================================



Sat, 09 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?
The loop in question is a "scheduling" loop which is the artifact of Verilog
simulator. Most simulators will propagate a blocking assignment immediately
resulting in this problem.

Unfortunately, the Verilog standard does not deal with these fine issues
which catch people by surprize.

-Ashutosh


Quote:




> > ><snip>
> > >> And now for the main point \begin{commercial} although Verilint would
> > >> not detect combinational loops, our new tool, RTL Explorer does
detect
> > >> such combinational loops (and does much much more). For more info,
> > >> contact Avant!, www.avanticorp.com, (510) 413-8000. \end{commercial}

> > >Hmmm.  Should we be happy with a language (or design methodology)
> > >in which such constructs are legal at all?

> > >or, to put it in historical context:  the fact that C needed lint
> > >surely proved beyond doubt that C was in serious need of change;
> > >how about our present-day HDLs?

> > >must've been drinking too hard tonite

> > >Jonathan Bromley

> > Combinational loops are legitimate hardware constructs. You would not
> > want to create one unintentionally, but for example if you want to
> > build a flipflop from gates you need to use one. Another example is a
> > clock oscilator. Surely every HDL shoule let you build flipflops and
> > oscilators.

> > Eli

> I fully agree that combinational loops are legitimate, but what interested
> me particularly about the original construct desrcibed in this thread was
> the fact that the loop in question was not actually oscillating. Each
> iteration around the loop reassigned the signals to the same value as the
> last iteration. It would appear that reassigning a signal its own value
> still constitutes an event which is able to trigger an always-block if
that
> signal is in the always-block's sensitivity list.

> Now you might argue that it is a legitimate question to ask "should a
block
> only trigger if a signal in its sensitivity list *changes value*, rather
> than just gets an event?". Perhaps the language could use another event
> expression qualifier to add to "posedge" and "negedge", such as "changing"
> or whatever.

> Regards, Robert
> --
> =========================================================================
> Robert R Fairlie - IC Design, Motorola, Scotland, Tel.  - +44 1355 356039
> =========================================================================



Sat, 09 Feb 2002 03:00:00 GMT  
 Q: Coding style in violation of IEEE-1364?

I would never be so tacky as to follow-up to my own post :-) I'm posting

Quote:

> I have trouble posting, so I am e-mailing this response.

> Robert made a comment about the blocks waking up when a reg in the
> sensitivity list had not changed value.  If the reg had never changed
> value, the block would not have woken up.  The reg actually did change
> value, it just changed back again before the other block could wake up
> and see it.  The intent was to temporarily use the reg to hold the
> default value before overwriting it with the correct value, but the
> effect is a zero-width glitch that wakes up the fanout.  Note that
> blocks explicitly waiting on posedge or negedge of the reg would also
> wake up, since those both occurred.  Note also that the IEEE standard
> would allow the other block to be woken up in the middle of the zero-
> width glitch and observe the incorrect default value (any process can
> be suspended at any time in favor of any other ready process).  Therefore
> the standard says that the behavior of this code is undefined.

> There are two schools of thought about whether zero-width glitches like
> this should wake up waiters.  One is that the other block asked to be
> woken up on a change, and that change occurred, so it should be woken up.
> The other is that a block should not be woken up on a change that it
> cannot actually see based on the values when it wakes up.  For example,
> it is counter-intuitive to some people that it is possible to wait on
> a posedge of a reg and find the reg to be zero when we are woken up.
> The second approach is less efficient to execute, since it requires
> double-checking the wakeup condition when the block wakes up.

> Verilog-XL usually wakes up on zero-width glitches.  In some situations
> it won't.  NC-Verilog does something similar.  However, there is also a
> command line option in NC-Verilog that will cause it always to ignore
> this kind of zero-width glitches if desired.

--
=========================================================================
Robert R Fairlie - IC Design, Motorola, Scotland, Tel.  - +44 1355 356039
=========================================================================


Sun, 10 Feb 2002 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. IEEE 1364 Verilog PLI-TSC Request for Enhancements, Errata

2. $monitor and IEEE Std 1364

3. Verilog 2001 (1364-2001 IEEE Standard) Question

4. Gate level primitives in IEEE 1364 Verilog standard...

5. IEEE-1364

6. delay_or_event_control construct in IEEE 1364 Verilog

7. IEEE 1364 parser test suite?

8. IEEE 1364 and Verilog-A Courses in Feb in Silicon Valley

9. Verilog is now IEEE 1364 standard

10. The differences of IEEE 1364-1995

11. Where can I find IEEE Par-1364?

12. IEEE 1364 Working Group Minutes

 

 
Powered by phpBB® Forum Software