Verilog-XL questions 
Author Message
 Verilog-XL questions

Quote:

>1.  I got the error message "Output and inout not allowed in function".

No ideas from me here.  Maybe Verilog-XL 2.1.2 has it's own ideas
about what's legal in a function?  Do they claim to be OVI compliant?

Quote:
>2.  The tst.v description below outputs:
> Is the simulator wrong or do I not understand Verilog?

>                efg = def;  // copy previous contents of def.


>                def = efg;  // copy previous contents of efg.

The simulator output looks right to me, at least as far as what *I*
would expect.

The single = assignment updates the variable immediately, therefore
you're in trouble.  One of the assignments will execute first.  The
other will see the new value of the right hand side instead of the old
value as desired.

Use a non-blocking assignment <= or add a delay to the assignments.
i.e.

                efg <= def;  // copy previous contents of def.


                def <= efg;  // copy previous contents of efg.

I've never succeeded in writing logic that makes sense (from a
simulation point of view) without breaking it into combinatorial and
sequential parts.  Of course with this trivial example it doesn't much
matter.  With more complicated logic then it does matter:

// combinatorial



// sequential



I'm told that I can replace " = #1" with "<=" with the same effect.  I
haven't given it much thought to convince myself yet, nor have I tried
it.

Quote:
>3.  The tst2.v description below outputs:


>                abc = def;


>                abc = efg;

> For me, this description seems to be non-synthesizable.....
> This should generate a "x" (don't-care) value for the output of abc.

I agree it probably is non-synthesizable.  But you're wrong about the
output.  You seem to be thinking of wires here.  If you think more in
terms of registers as C variables then your intuition will get you
farther.  How is the register supposed to know that it's output should
be x?

What you've written looks fine to me and should produce behavior like
what you see (although the order of the assignments would be
implementation dependent, i.e. undefined).

If you care about catching mistakes like this and keeping things
synthesizable then feed it through the synthesizer and pay attention
to the warning messages.

Simulators and synthesizers seem to often disagree in this area.  You can
write something that synthesizes fine yet won't simulate (because the
synthesizer knew what you meant) and vice versa as your two examples
illustrate.

Cheers,
-Eric



Fri, 12 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Hi all,

        I have 3 questions for you verilog gurus.  I am using Verilog-XL 2.1.2
and I got the following three problems.

1.  I got the error message "Output and inout not allowed in function".

        I ordered the Verilog LRM from OVI about year and a half ago, and
        the "Formal Syntax Definition" has something else to say.

A.4 of F. S. D. [OVI92]

<function>
        ::= function <range_or_type>? <name_of_function> <instance_attribute>?;
        <tf_declaration>+
        <statement>
        endfunction

<tf_declaration>
        ::= <parameter_declaration>
        ||= <input_declaration>
        ||= <output_declaration>
        ||= <inout_declaration>
        ||= <reg_declaration>
        ||= <time_declaration>
        ||= <integer_declaration>
        ||= <real_declaration>

Maybe I'm reading this wrong?  Could someone please explain?

2.  The tst.v description below outputs:

Compiling source file "tst.v"
Highest level modules:
main

monitor                    0: 1110 0001
monitor                    1: 0001 0001
L11 "tst.v": $finish at simulation time 10
72 simulation events
CPU time: 0.7 secs to compile + 0.3 secs to link + 0.0 secs in simulation
End of VERILOG-XL 2.1.2   Jun 26, 1995  11:17:15

The point of this description is to move the contents of the two registers
(def, efg) back and forth.  I think this is synthesizable and correct.
But the simulation output is wrong.  There is no time when both efg and def
are the same value, as it is displayed at time 1.  Is the simulator wrong
or do I not understand Verilog?

3.  The tst2.v description below outputs:

Compiling source file "tst2.v"
Highest level modules:
main

monitor                    0: xxxx
monitor                    1: 1001
monitor                    3: 0110
monitor                    5: 1001
monitor                    7: 0110
monitor                    9: 1001
L11 "tst2.v": $finish at simulation time 10
72 simulation events
CPU time: 0.6 secs to compile + 0.3 secs to link + 0.0 secs in simulation
End of VERILOG-XL 2.1.2   Jun 26, 1995  11:36:34

For me, this description seems to be non-synthesizable.  I.e. I am trying
to store two values into abc at the same clock edge.  This should generate
a "x" (don't-care) value for the output of abc.  But instead, the contents
of abc go back and forth between the two values.  This is not how I understand
registers to work.  Could someone explain what I am doing wrong?  Note, I
am not considering strengths at this point.  If someone could explain this
without using strengths, that would be great.  If this is not possible,
then any explanation is ok.

--jc
---------------------------- Sample files -------------------------

--- tst.v ---
module main;
        reg [3:0] abc, def, efg;
        reg clk;

        initial
                begin
                $monitor("monitor %d: %b %b", $time, def, efg);
                clk = 0;
                def = 14;
                efg = 1;
                #10 $finish;
                end

        always #1 clk = !clk;


                efg = def;      // copy previous contents of def.


                def = efg;      // copy previous contents of efg.

endmodule
------ end of tst.v --------

------ tst2.v --------
module main;
        reg [3:0] abc, def, efg;
        reg clk;

        initial
                begin
                $monitor("monitor %d: %b", $time, abc);
                clk = 0;
                def = 4'b1001;
                efg = 4'b0110;
                #10 $finish;
                end

        always #1 clk = !clk;


                abc = def;


                abc = efg;

endmodule
----------- End of tst2.v -----

--



Fri, 12 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Quote:

>Hi all,

>    I have 3 questions for you verilog gurus.  I am using Verilog-XL 2.1.2
>and I got the following three problems.

>1.  I got the error message "Output and inout not allowed in function".

>    I ordered the Verilog LRM from OVI about year and a half ago, and
>    the "Formal Syntax Definition" has something else to say.

>A.4 of F. S. D. [OVI92]

><function>
>    ::= function <range_or_type>? <name_of_function> <instance_attribute>?;
>    <tf_declaration>+
>    <statement>
>    endfunction

><tf_declaration>
>    ::= <parameter_declaration>
>    ||= <input_declaration>
>    ||= <output_declaration>
>    ||= <inout_declaration>
>    ||= <reg_declaration>
>    ||= <time_declaration>
>    ||= <integer_declaration>
>    ||= <real_declaration>

>Maybe I'm reading this wrong?  Could someone please explain?

Well, i am no verilog guru, but why would you want outputs and inouts from a
function? It's a contradiction in terms, as a function is supposed to be just
that: a function of it's inputs. A little thought about your problem might lead
to a solution using a task or dedicated module.

- Show quoted text -

Quote:
>2.  The tst.v description below outputs:

>Compiling source file "tst.v"
>Highest level modules:
>main

>monitor                    0: 1110 0001
>monitor                    1: 0001 0001
>L11 "tst.v": $finish at simulation time 10
>72 simulation events
>CPU time: 0.7 secs to compile + 0.3 secs to link + 0.0 secs in simulation
>End of VERILOG-XL 2.1.2   Jun 26, 1995  11:17:15

>The point of this description is to move the contents of the two registers
>(def, efg) back and forth.  I think this is synthesizable and correct.
>But the simulation output is wrong.  There is no time when both efg and def
>are the same value, as it is displayed at time 1.  Is the simulator wrong
>or do I not understand Verilog?

>3.  The tst2.v description below outputs:

>Compiling source file "tst2.v"
>Highest level modules:
>main

>monitor                    0: xxxx
>monitor                    1: 1001
>monitor                    3: 0110
>monitor                    5: 1001
>monitor                    7: 0110
>monitor                    9: 1001
>L11 "tst2.v": $finish at simulation time 10
>72 simulation events
>CPU time: 0.6 secs to compile + 0.3 secs to link + 0.0 secs in simulation
>End of VERILOG-XL 2.1.2   Jun 26, 1995  11:36:34

>For me, this description seems to be non-synthesizable.  I.e. I am trying
>to store two values into abc at the same clock edge.  This should generate
>a "x" (don't-care) value for the output of abc.  But instead, the contents
>of abc go back and forth between the two values.  This is not how I understand
>registers to work.  Could someone explain what I am doing wrong?  Note, I
>am not considering strengths at this point.  If someone could explain this
>without using strengths, that would be great.  If this is not possible,
>then any explanation is ok.

>--jc
>---------------------------- Sample files -------------------------

>--- tst.v ---
>module main;
>        reg [3:0] abc, def, efg;
>        reg clk;

>        initial
>                begin
>                $monitor("monitor %d: %b %b", $time, def, efg);
>                clk = 0;
>                def = 14;
>                efg = 1;
>                #10 $finish;
>                end

>        always #1 clk = !clk;



         ^^^^^^^^^^^^^^^^^^^^^
Quote:
>                efg = def;  // copy previous contents of def.

                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quote:



         ^^^^^^^^^^^^^^^^^^^^^
Quote:
>                def = efg;  // copy previous contents of efg.

                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

- Show quoted text -

Quote:

>endmodule
>------ end of tst.v --------

>------ tst2.v --------
>module main;
>        reg [3:0] abc, def, efg;
>        reg clk;

>        initial
>                begin
>                $monitor("monitor %d: %b", $time, abc);
>                clk = 0;
>                def = 4'b1001;
>                efg = 4'b0110;
>                #10 $finish;
>                end

>        always #1 clk = !clk;



         ^^^^^^^^^^^^^^^^^^^^^
Quote:
>                abc = def;
                ^^^^^^^^^^^



         ^^^^^^^^^^^^^^^^^^^^^

Quote:
>                abc = efg;
                ^^^^^^^^^^^

>endmodule
>----------- End of tst2.v -----

>--


What you have created is the classic definition of a race. No wonder it does not
work, as you are asking the impossible from the simulated system: swap values in
zero time, and without intermediate buffering. The exact outcome of such situa-
tions is dependent on the implementation details of the Verilog simulator one
is using. The correct way to formulate the first example is:



The delayed assignments store the rhs values in temporary variables at the edge
of the clock, but the values appear only after one delay unit on the lhs regs.
Thus, the order of the event scheduling makes no difference to the outcome.
As for your second example, i can see no cure for the race there; no matter what
you do, the simulator will have to decide which rhs value to write into the lhs
last. You will always get garbage. Strengths don't come into this, you are not
playing with wires and gates in your example.

Regards,

Frank Ieromnimon,



Sat, 13 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Quote:

>Hi all,

>    I have 3 questions for you verilog gurus.  I am using Verilog-XL 2.1.2
>and I got the following three problems.

>1.  I got the error message "Output and inout not allowed in function".

... stuff deleted ...

Quote:

>Maybe I'm reading this wrong?  Could someone please explain?

A function returns its value through the function name.  For example,

function [7:0] myfunction;
  input [3:0] someinput;
  ... function body ...
endfunction
... more stuff ...
assign x = myfunction(y);

will return the value through myfunction and the assignm statement assigns it
to x.

If you want other outputs and/or inouts defined, use a task.  If you have
the Cadence on-line doc installed, type openbook and refer to the Verilog-XL
Reference Manual for details on tasks and functions.

Quote:

>2.  The tst.v description below outputs:

... stuff deleted ...
Quote:

>3.  The tst2.v description below outputs:

... stuff deleted ...

Quote:

>---------------------------- Sample files -------------------------

>--- tst.v ---
>module main;
>        reg [3:0] abc, def, efg;
>        reg clk;

>        initial
>                begin
>                $monitor("monitor %d: %b %b", $time, def, efg);
>                clk = 0;
>                def = 14;
>                efg = 1;
>                #10 $finish;
>                end

>        always #1 clk = !clk;


>                efg = def;  // copy previous contents of def.


>                def = efg;  // copy previous contents of efg.

>endmodule
>------ end of tst.v --------

Change the always blocks to something like


  efg <= def;              // This is a non-blocking procedural assignment
  def <= efg;
end

Both def and efg (previous contents) will be evaluated before the assignments
take place at posedge clk instead of immediately.  This should perform the
swap that you want.

- Show quoted text -

Quote:

>------ tst2.v --------
>module main;
>        reg [3:0] abc, def, efg;
>        reg clk;

>        initial
>                begin
>                $monitor("monitor %d: %b", $time, abc);
>                clk = 0;
>                def = 4'b1001;
>                efg = 4'b0110;
>                #10 $finish;
>                end

>        always #1 clk = !clk;


>                abc = def;


>                abc = efg;

>endmodule
>----------- End of tst2.v -----

Try assigning to abc in a continuous assignment.  Your code might look like

module main;
        reg [3:0] def, efg, def_temp, efg_temp;
        reg clk;
        wire [3:0] abc;

        initial
                begin
                $monitor("monitor %d: %b", $time, abc);
                clk = 0;
                def = 4'b1001;
                efg = 4'b0110;
                #10 $finish;
                end

        always #1 clk = !clk;


                def_temp = def;
                efg_temp = efg;
        end

        assign abc = def; // I haven't verified this in simulation but
        assign abc = efg; // this might model what you will expect

endmodule

Quote:
>--


--
Manning Aalsma

Austin, TX                            "my opinions are my own..."


Sat, 13 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Quote:

>No ideas from me here.  Maybe Verilog-XL 2.1.2 has it's own ideas
>about what's legal in a function?  Do they claim to be OVI compliant?

No and no.  From an email reply.  I was told by a member of the IEEE
standards committee that output and inouts are not supported in functions.
But, OVI 2.0 did include it.  This differentiation of functions and tasks
looks too much like Pascal to me.

Quote:
>output.  You seem to be thinking of wires here.  If you think more in
>terms of registers as C variables then your intuition will get you
>farther.

I was trying to write synthesizable Verilog code, so this doesn't sound
like such a good idea.  I often see my friends when they try to write
synthesizable code to write Verilog like a programming language.  There
are many things about C variables that are not like registers.  Questions
2 and 3 are two of them.

Quote:
>How is the register supposed to know that it's output should
>be x?

In terms of hardware, a register is nothing but a flip-flop.  A basic
flip-flop, such as a RS flip-flop, can be made up of nand gates.  Thus,
basically, a register has the same properties of a nand gate.  Using the
following as example:

             -------)
   A -----+--|       )
   B -----|  |        )O--- D
             |       )
   C --------|------)

If C = high, and B = ~A, what is D?  Seems in real hardware, we have to
consider strengths.  But in a simulator, that only verifies the circuit
(just a nand gate in this case), D should be don't-care.

Quote:
>Simulators and synthesizers seem to often disagree in this area.  You can

I'm just curious.  Why did people create languages like Verilog and VHDL,
and call then high-level hardware description languages and yet they do
not describe hardware?  If a description of a digital circuit is not
synthesizable, then it is not a description of a digital circuit.
--jc
--



Sat, 13 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Quote:

>function? It's a contradiction in terms, as a function is supposed to be just

Please don't take this as a flame, but...If the terms are in contradiction,
maybe Verilog is using the wrong term?  After all, this is a hardware
description language, not a symbolic math language.

Quote:
>What you have created is the classic definition of a race.

Race condition in synchronous digital circuits?  I though the point of a
synchronous circuit was to eliminate race conditions.  Note, the register
should sample the input at the position clock edge.  Thus, both inputs must
be valid throughout the setup time of the register.  Which I assume for
this circuit description.

Quote:
>work, as you are asking the impossible from the simulated system: swap values in
>zero time, and without intermediate buffering. The exact outcome of such situa-

I'm sorry, but I don't understand the concept of swapping values in zero
time in hardware.  There is always a slight propagation delay.  But this is
not the problem in this case.  The problem I'm bringing up is the concept
of current state/next state (as in FSM).  In the circuit I provided, the
next state is available at the time of sampling by the clock edge.  Why
can't that be simulated?  It is how hardware works.

Also, everyone who responded seems to like the solution of using the non-
blocking assignment.  It seems to me that there are lots of assignments of
this type in synthesizable descriptions.  So, should all assignments use
non-blocking assignment?  The irony is that non-blocking assignment is
optional-abort for synthesis (according to OVI 2.0).
--jc
--



Sat, 13 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Quote:


>  efg <= def;              // This is a non-blocking procedural assignment
>  def <= efg;
>end

You understand that this will make this description non-synthesizable
and yet this is a natural behavior of registers.  Consider:

          +-----------------------+
          |                       |
          | +-----+      +-----+  |
                +-|D   Q|------|D   Q|  |
      clk __|\   _|  clk_|\   _|  |
            |/   Q|      |/   Q|--+
            +-----+      +-----+

This would flip the two registers back and forth between 0 and 1 at Q.
Assuming both register has asynchronous reset.  For my example given
at the original message, just extend this to 4 bits and use extra circuit
to set the registers to initial values.  The basic connections are the
same.

Quote:
>module main;
>        reg [3:0] def, efg, def_temp, efg_temp;
>        reg clk;
>        wire [3:0] abc;
>        initial
>                begin
>                $monitor("monitor %d: %b", $time, abc);
>                clk = 0;
>                def = 4'b1001;
>                efg = 4'b0110;
>                #10 $finish;
>                end
>        always #1 clk = !clk;

>                def_temp = def;
>                efg_temp = efg;
>        end
>        assign abc = def; // I haven't verified this in simulation but
>        assign abc = efg; // this might model what you will expect
>endmodule

Yes, this does produce the result I was looking for.  But why did you
include def_temp and efg_temp?  Seems to me they are never used.  The
purpose of def and efg in the original circuit was to model two sources.
Then I tried to store the contents of these two sources to the same
register.  In real hardware, this seems to be a bad idea.  But when
writing Verilog descriptions spanning multiple tasks.  It is hard
to detect such a mistake.  Thus, I need some way of detecting this
through simulation (verification).  If I had done this using schematic
capture, I would have detected this error.  But when I used Verilog
(with blocking assignment), I got strange behavior.  Also, Why did you use
wire for abc?  Was this required or a preference?

From the responses I got, I guess I should have emphasized that I'm
only interested in synthesizable results.  I guess this is not yet
norm for industry designers using Verilog.  Maybe it's just me, but
I would think other people writing synthesizable descriptions would
run into this same problem.  I'm sure someone else must have made the
mistake of assigning two results to the same register on the same clock
edge.  Maybe I'm not following some special guidelines for writing
synthesizable descriptions?  It was a mistake on my part, yes, but the
simulator should have notified me.  Am I asking too much?
--jc
--



Sat, 13 Dec 1997 03:00:00 GMT  
 Verilog-XL questions
To the people still in school:  Please take a class in engineering or
computer science on Design Automation, in which you have to write an
event-driven logic simulator of your own.  Verilog will make much more
sense if you understand the event queue, etc.

For those out of school, find papers describing the innards of event-driven
simulators.

The Design Automation classes I took also covered the algorithms underneath
different place and route programs, timing analyzers, and logic synthesizers,
making it easier to understand the advantages and limitation of each program,
and how various parameters to these programs can affect the outcome.

Just my 2 cents...



Sun, 14 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Quote:



>>  efg <= def;              // This is a non-blocking procedural assignment
>>  def <= efg;
>>end

>You understand that this will make this description non-synthesizable
>and yet this is a natural behavior of registers.  Consider:

I don't think the above description is non-synthesizable.  What you'll get is
a 2-bit shift reg with the output connected back to the input.  At least
Synopsys can synthesize this.  What synthesis tool are you using?

Quote:

>          +-----------------------+
>          |                       |
>          | +-----+      +-----+  |
>            +-|D   Q|------|D   Q|  |
>      clk __|\   _|  clk_|\   _|  |
>            |/   Q|      |/   Q|--+
>            +-----+      +-----+

>This would flip the two registers back and forth between 0 and 1 at Q.
>Assuming both register has asynchronous reset.  For my example given
>at the original message, just extend this to 4 bits and use extra circuit
>to set the registers to initial values.  The basic connections are the
>same.

>>module main;
>>        reg [3:0] def, efg, def_temp, efg_temp;
>>        reg clk;
>>        wire [3:0] abc;
>>        initial
>>                begin
>>                $monitor("monitor %d: %b", $time, abc);
>>                clk = 0;
>>                def = 4'b1001;
>>                efg = 4'b0110;
>>                #10 $finish;
>>                end
>>        always #1 clk = !clk;

>>                def_temp = def;
>>                efg_temp = efg;
>>        end
>>        assign abc = def; // I haven't verified this in simulation but
>>        assign abc = efg; // this might model what you will expect
>>endmodule

>Yes, this does produce the result I was looking for.  But why did you
>include def_temp and efg_temp?  Seems to me they are never used.  The
>purpose of def and efg in the original circuit was to model two sources.

If def and efg are intended to be registered for some odd reason, the assigns
should be

assign abc = def_temp; assign abc = efg_temp;

I don't think you want that, so the temp vars are not needed.  My mistake.

Quote:
>Then I tried to store the contents of these two sources to the same
>register.  In real hardware, this seems to be a bad idea.  But when
>writing Verilog descriptions spanning multiple tasks.  It is hard
>to detect such a mistake.  Thus, I need some way of detecting this
>through simulation (verification).  If I had done this using schematic

Let's say by mistake you have


  abc = def;
  abc = efg;
end

This should only synthesize to one register, namely the abc = efg one since it
was the last assignment parsed in the always block.  You will only detect this with
a pattern in simulation.  However, if you have


  abc = def;


  abc = efg;

Then it will synthesize to two registers.  In Synopsys's case, a warning is issued
telling you that variable abc is driven by multiple processes and simulation/
synthesis mismatches could occur.  If you look at the gates, you might find the 2
registers with their outputs anded together to produce abc.

So it also depends on your coding style what you get in synthesis.  Hope that helps.

Quote:
>capture, I would have detected this error.  But when I used Verilog
>(with blocking assignment), I got strange behavior.  Also, Why did you use
>wire for abc?  Was this required or a preference?

reg's can only be assigned to in a procedural block (i.e. initial, always).
Since abc no longer exhibits register qualities (can't hold data) but behaves
more like a wire due to the concurrent assign statement, it is declared as a
wire vector.  As a corollary, signals of type wire can't be assigned to in a
procedural block.

Quote:

>From the responses I got, I guess I should have emphasized that I'm
>only interested in synthesizable results.  I guess this is not yet
>norm for industry designers using Verilog.  Maybe it's just me, but
>I would think other people writing synthesizable descriptions would
>run into this same problem.  I'm sure someone else must have made the
>mistake of assigning two results to the same register on the same clock
>edge.  Maybe I'm not following some special guidelines for writing
>synthesizable descriptions?  It was a mistake on my part, yes, but the
>simulator should have notified me.  Am I asking too much?
>--jc
>--


--
Manning Aalsma

Austin, TX                            "my opinions are my own..."


Sun, 14 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Quote:
>Hi all,
>    I have 3 questions for you verilog gurus.  I am using Verilog-XL 2.1.2
>and I got the following three problems.
>1.  I got the error message "Output and inout not allowed in function".

>    I ordered the Verilog LRM from OVI about year and a half ago, and
>    the "Formal Syntax Definition" has something else to say.

OVI added function outputs and inouts with the OVI 2.0 standard, but the
major EDA vendors for both simulation and synthesis never adopted the change.
the IEEE 1364 Verilog standard only permits inputs to functions (the way it
used to be before the OVI 2.0 change).  The IEEE 1364 standard has passed
it ballot, and is in the process of being finalized.  The IEEE Verilog
Language Reference Manual should available for order before too long.

Quote:
>2.  The tst.v description below outputs:
>Compiling source file "tst.v"
>Highest level modules:
>main
>monitor                    0: 1110 0001
>monitor                    1: 0001 0001
>L11 "tst.v": $finish at simulation time 10
>72 simulation events
>CPU time: 0.7 secs to compile + 0.3 secs to link + 0.0 secs in simulation
>End of VERILOG-XL 2.1.2   Jun 26, 1995  11:17:15
>The point of this description is to move the contents of the two registers
>(def, efg) back and forth.  I think this is synthesizable and correct.
>But the simulation output is wrong.  There is no time when both efg and def
>are the same value, as it is displayed at time 1.  Is the simulator wrong
>or do I not understand Verilog?

You are using "blocking" assignments (single = token) in the same time step
to swap the registers.  This fails because the first assignment will
overwrite the contents of the second register before the second assignment
is evaluated (the first assignment "blocks" evaluation of the second
assignment until it is complete).  There are multiple ways to model a
swap in the same time step.  One way is to use "non-blocking" assignments
(the <= assignment token).  Such as:


       efg <= def;


       def <= efg;

The non-blocking assignments will evaluate both right hand sides first,
before changing the left hand sides.

You have another error in the stimulus, but it does not show up in this
example.  The clock toggle "#1 clk = !clk" should use the invert operator
( ~ ) instead of the "not true" ( ! ) operator.  The not true operator
does a true false test and returns a 1-bit result.  It happens to work in
your example because clock is scalar, and so a true/false test on its
value gives the same result as inverting it.

Quote:
>3.  The tst2.v description below outputs:
>Compiling source file "tst2.v"
>Highest level modules:
>main
>monitor                    0: xxxx
>monitor                    1: 1001
>monitor                    3: 0110
>monitor                    5: 1001
>monitor                    7: 0110
>monitor                    9: 1001
>L11 "tst2.v": $finish at simulation time 10
>72 simulation events
>CPU time: 0.6 secs to compile + 0.3 secs to link + 0.0 secs in simulation
>End of VERILOG-XL 2.1.2   Jun 26, 1995  11:36:34
>For me, this description seems to be non-synthesizable.  I.e. I am trying
>to store two values into abc at the same clock edge.  This should generate
>a "x" (don't-care) value for the output of abc.  But instead, the contents
>of abc go back and forth between the two values.  This is not how I understand
>registers to work.  Could someone explain what I am doing wrong?  Note, I
>am not considering strengths at this point.  If someone could explain this
>without using strengths, that would be great.  If this is not possible,
>then any explanation is ok.

The Verilog "register" data type is really just a variable that stores
whatever the last value is that was assigned to it.  It does not behave
like a hardware register, which also stores a value, but typically will have
setup and hold requirements and such.  I've always wished that Phil Moorby
had not used the word "register" to describe a variable when he created the
Verilog language.  But he didn't ask me :)

Your example, which uses the blocking assignments to swap values in the
same time step, creates a race condition, where you cannot tell which
order the assignments will be evaluated, but whatever the order is, the
register variables will store the value assigned to them.  Your example
is synthesizable, and will probably generate hardware structure with the
same race condition you have modeled.  Changing the assignments to
non-blocking is also synthesizable, and should synthsize better behaved
structure as well.

Hope this helps...

Stu Sutherland

- Show quoted text -

Quote:
>---------------------------- Sample files -------------------------
>--- tst.v ---
>module main;
>        reg [3:0] abc, def, efg;
>        reg clk;
>        initial
>                begin
>                $monitor("monitor %d: %b %b", $time, def, efg);
>                clk = 0;
>                def = 14;
>                efg = 1;
>                #10 $finish;
>                end
>        always #1 clk = !clk;

>                efg = def;  // copy previous contents of def.

>                def = efg;  // copy previous contents of efg.
>endmodule
>------ end of tst.v --------
>------ tst2.v --------
>module main;
>        reg [3:0] abc, def, efg;
>        reg clk;
>        initial
>                begin
>                $monitor("monitor %d: %b", $time, abc);
>                clk = 0;
>                def = 4'b1001;
>                efg = 4'b0110;
>                #10 $finish;
>                end
>        always #1 clk = !clk;

>                abc = def;

>                abc = efg;
>endmodule
>----------- End of tst2.v -----
>--


--
-- Stuart Sutherland                       Sutherland HDL Consulting --

-- phone (303) 682-8864                    Longmont, CO  80503       --
-- FAX:  (303) 682-8827
--                                                                   --
-- Training & consulting for Verilog HDL, PLI, Synthesis and tools,  --  
-- Publisher of popular "Verilog HDL 2.0 Language Reference Guide"   --
-----------------------------------------------------------------------


Sun, 14 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Quote:

>I don't think the above description is non-synthesizable.  What you'll get is
>Synopsys can synthesize this.  What synthesis tool are you using?

I don't have access to synopsys so I am using OVI 2.0 as my guide.  I'm
beginning to think that was a mistake.  According to OVI 2.0, non-blocking
assignment is an optional-abort with limitations.  I took this to mean
that not all synthesis tools will support it, so it is unreliable.  I
guess I need better sources.

Quote:

>  abc = def;

>  abc = efg;
>Then it will synthesize to two registers.  In Synopsys's case, a warning is issued
>telling you that variable abc is driven by multiple processes and simulation/
>synthesis mismatches could occur.

That's great, but my tests with Verilog-XL didn't give the same warning.
Is this a bug?  I guess my problem with all this is the inconsistancy
between the synthesis tools and simulation tools.  How does industry handle
this?  Just curious.
--jc
--



Sun, 14 Dec 1997 03:00:00 GMT  
 Verilog-XL questions

Quote:

>it ballot, and is in the process of being finalized.  The IEEE Verilog
>Language Reference Manual should available for order before too long.

I know standards committees do not announce the availability of their
documents, but could you let me know, at this address, when this manual
is ready to ship?

Quote:
>The Verilog "register" data type is really just a variable that stores
>whatever the last value is that was assigned to it.  It does not behave
>like a hardware register, which also stores a value, but typically will have

Gee, I thought HDL's were supposed to have data types that behave like the
hardware equivalent. ;-)  But I'm beginning to see your point, and everyone
elses.  I guess I didn't take the notice "register does not imply flip-flop
or latch" seriously enough.  Thanks for the assistance.
--jc
--



Sun, 14 Dec 1997 03:00:00 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Verilog-XL question (important)!

2. Verilog-XL simple question

3. Verilog-XL/NC-Verilog Event Order

4. Retrieving protected Verilog code in Verilog-XL??

5. 1364-95 Verilog vs Verilog-XL

6. Verilog 2.7 (Verilog-XL) Warning message

7. dynamic PLI in Verilog XL

8. Verilog-XL operators

9. mistake in verilog-xl

10. verilog XL & switch RC

11. Combining signals (P1364 vs. Verilog-XL)

12. Read Shell Environment Variables (Strings) into Verilog-XL?

 

 
Powered by phpBB® Forum Software