Bug in Verilog-XL 1.6b? 
Author Message
 Bug in Verilog-XL 1.6b?

Hello,

Here is part of the "verilog.log" file created by running "verilog" with full trace:

Quote:
> Host command: verilog
> Command arguments:
>     -t

>    :
>    :

> VERILOG-XL 1.6b log file created Oct 25, 1994  11:07:13
>   * Copyright Cadence Design Systems, Inc. 1985, 1988.    *
>   *     All Rights Reserved.       Licensed Software.     *
>   * Confidential and proprietary information which is the *
>   *      property of Cadence Design Systems, Inc.         *

>    :
>    :

> GRAPHICS 1.2c
> Highest level modules:
> top

>    :
>    :

> L728 "../NodeChip.v" (top.node2.chip.edqh): alloc_and_check(sidle_reg, i);
> L764 "../NodeChip.v" (top.node2.chip.edqh): begin
> L765 "../NodeChip.v" (top.node2.chip.edqh): eq.alloc(i);
> L67 "../queue.v" (top.node1.chip.eq): begin

                        ^^^^^
As we can see, eq.alloc(i) is calling

    top.node1.chip.eq.alloc

instead of

    top.node2.chip.eq.alloc

This have to be a bug? Anyone else noticed something like this?

Quote:

>    :
>    :

> L71 "../queue.v" (top.node1.chip.eq): end
> L65 "../queue.v" (top.node1.chip.eq): alloc; >>> RETURNING
> L766 "../NodeChip.v" (top.node2.chip.edqh): -> si.up;
> L767 "../NodeChip.v" (top.node2.chip.edqh):
> L768 "../NodeChip.v" (top.node2.chip.edqh): if(sidle == 1) >>> SKIPPING
> L773 "../NodeChip.v" (top.node2.chip.edqh): end
> L761 "../NodeChip.v" (top.node2.chip.edqh): alloc_and_check; >>> RETURNING

Ole Hermann F?rde


Sat, 12 Apr 1997 20:06:30 GMT  
 Bug in Verilog-XL 1.6b?

   Path: paperboy.wellfleet.com!news-feed-1.peachnet.edu!news.duke.edu!convex!cs.utexas.edu!howland.reston.ans.net!EU.net!sunic!trane.uninett.no!nac.no!nntp.uio.no!mephisto!olefo

   Newsgroups: comp.lang.verilog
   Date: 25 Oct 1994 12:06:30 GMT
   Organization: University of Oslo, Department of Physics
   Lines: 56

   Distribution: world
   NNTP-Posting-Host: mephisto.uio.no

   Hello,

   Here is part of the "verilog.log" file created by running "verilog" with full trace:

        [verilog header and trace deleted]

   > L765 "../NodeChip.v" (top.node2.chip.edqh): eq.alloc(i);
   > L67 "../queue.v" (top.node1.chip.eq): begin
                           ^^^^^
   As we can see, eq.alloc(i) is calling

       top.node1.chip.eq.alloc

   instead of

       top.node2.chip.eq.alloc

   This have to be a bug? Anyone else noticed something like this?

----

Ole,

  I don't think this is a bug, per se. I think you're running into
Cadence's interpretation of search rules regarding non-local calls and
hierarchical search paths.

  According to the OVI spec (this is second hand, I haven't *actually*
read the spec ;-), any task or function call that does not contain an
explicit hierarchical path reference to the task/function is assumed to
be locally defined. However, Cadence provides an implicit search
mechanism to find non-local calls that do not contain a hierarchical
path.  This is one of the many non-OVI "features" Cadence provides to
it's users.

  Other verilog simulators more strictly control non-local task
referencing and would have flagged this as an error.

  BTW, I've assumed your hierarchy to be something like:

        module top;

                logic_block  node1 (...);

                logic_block  node2 (...);

        endmodule

  And "logic_block" has something instantiated as "chip", etc.

  Since your function call in edqh to eq.alloc is being mis-interpreted,
I would suggest trying to make it more explicit by defining it as
something like:

        logic_block.chip.eq.alloc

  Using the module name rather than instance name in the hierarchical
reference should force the call to alloc to find the task/function in
node2 as you expect.

  *** Disclaimer! This is what I've been told, but haven't had a chance to
  *** explictly confirm this within my design environment!!

  Hopefully this will help you out, if not, I apologize for wasting the
net's bandwidth. (but hey, my company builds and sells routers so I like
to see bandwidth getting used fully... ;-) ;-) ;-)

Dan W.
--
Dan Westerberg
Bay Networks Inc.    Billerica MA



Sun, 13 Apr 1997 00:06:08 GMT  
 Bug in Verilog-XL 1.6b?
Hello again,

|>
|>   BTW, I've assumed your hierarchy to be something like:
|>
|>
|>         module top;
|>
|>                 logic_block  node1 (...);
|>
|>                 logic_block  node2 (...);
|>
|>         endmodule
|>
|>
|>   And "logic_block" has something instantiated as "chip", etc.

Your assumption is correct.

|>
|>   Since your function call in edqh to eq.alloc is being mis-interpreted,
|> I would suggest trying to make it more explicit by defining it as
|> something like:
|>
|>         logic_block.chip.eq.alloc
|>
|>   Using the module name rather than instance name in the hierarchical
|> reference should force the call to alloc to find the task/function in
|> node2 as you expect.

Now, I have tried these ways of calling too:

    interface.chip.eq.alloc
    NodeChip.eq.alloc
    chip.eq.alloc

"NodeChip" is the module name of the instance with the name chip. "interface" is what you call
"logic_block".

They all produce the same results as if the call had been:

    eq.alloc

Ole Hermann F?rde



Sun, 13 Apr 1997 20:51:57 GMT  
 Bug in Verilog-XL 1.6b?
Ole Hermann F rde,

Your trace look perfectly normal to me.

L16 is halting the nod2.edqh thread (waiting for 1 time unit).
Then next L16 after that, is picking up the node1.edqh thread after
waiting for 1 time unit.

I don't understand what the problem is?

--
=----------------------------------------------------------------=
= Chris Starr                                ASIC EDA Consultant =

= Phone/Fax: (919) 847-0981                  Raleigh, NC  27615  =
=                                                                =
= ASIC Modeling, Verilog Drivers/Monitors, System-Level          =
= Verification Tools.                                            =
=----------------------------------------------------------------=



Fri, 18 Apr 1997 21:16:21 GMT  
 Bug in Verilog-XL 1.6b?
Ole,

I finally see what your problem is:

  module top;
    interface node1();
    interface node2();
  endmodule

  module interface;
    task alloc;
      $display("In %m");
    endtask
    exdevreq edqh();
  endmodule

  module exdevreq;
    initial begin
      interface.alloc;  // *** What is this?  See below.
      #1 $finish;
    end
    specify specparam tsu = 1; endspecify
  endmodule

Your call to "interface.alloc" in module exdevreq makes no sense.
There are 2 interface modules in this netlist (node1 and node2).
You invocation of the alloc task is ambiguious.  Do you want
Verilog to call the one in node1 or the one in node2?

I have never tried to call a task using this technique/hack.  I can
understand why Verilog is sometimes calling the one in node1 and
at other times calling the one in node2.  What I can't understand
is why this compiles in the first place!  What does Verilint say
about this netlist?  I believe that Verilog is doing its best to
satisfy your request to call the alloc task.  It's probably thinking
that you aren't too picky about which task to call because you say
"interface.alloc" instead of "node1.alloc" or "node2.alloc".  I
still can't understand why this compiles.  Why do think that
"interface.alloc" means something at the hierarchical level of
module exdevreq?

I still don't think this is a bug.  Your example is convoluted and
makes no sense from a design point of view.  Why do you expect the
call to "interface.alloc" to call node1 in one case and node2 in
another?   Verilog must be searching from the heirarchy of module top
to satisfy your request to call "interface.alloc", NOT from the
heirarchy of module interface.

Try substituting "node1.alloc;" for "interface.alloc;".  Then try
"node2.alloc;".  This exhibits a more deterministic behavior.

What is the purpose of this example?  Why are we being asked to
analyze the behavior of some "tricked up" netlist?

=----------------------------------------------------------------=
= Chris Starr                                ASIC EDA Consultant =

= Phone/Fax: (919) 847-0981                  Raleigh, NC  27615  =
=                                                                =
= ASIC Modeling, Verilog Drivers/Monitors, System-Level          =
= Verification Tools.                                            =
=----------------------------------------------------------------=

--
=----------------------------------------------------------------=
= Chris Starr                                ASIC EDA Consultant =

= Phone/Fax: (919) 847-0981                  Raleigh, NC  27615  =
=                                                                =
= ASIC Modeling, Verilog Drivers/Monitors, System-Level          =
= Verification Tools.                                            =
=----------------------------------------------------------------=



Sat, 19 Apr 1997 01:33:22 GMT  
 Bug in Verilog-XL 1.6b?

|> Your call to "interface.alloc" in module exdevreq makes no sense.
|> There are 2 interface modules in this netlist (node1 and node2).
|> You invocation of the alloc task is ambiguious.  Do you want

This contradicts what has been said in a previous followup:

|>   BTW, I've assumed your hierarchy to be something like:
|>
|>         module top;
|>                 logic_block  node1 (...);
|>                 logic_block  node2 (...);
|>         endmodule
|>
|>   And "logic_block" has something instantiated as "chip", etc.
      :
      :
|>   Since your function call in edqh to eq.alloc is being mis-interpreted,
|> I would suggest trying to make it more explicit by defining it as
|> something like:
|>
|>         logic_block.chip.eq.alloc
|>
|>   Using the module name rather than instance name in the hierarchical
|> reference should force the call to alloc to find the task/function in
|> node2 as you expect.


|> .....  Do you want
|> Verilog to call the one in node1 or the one in node2?

Is this clear enough:
If alloc is called from the instance top.node1.edqh, then top.node1.alloc is called.
If alloc is called from the instance top.node2.edqh, then top.node2.alloc is called.

Then my question and problem is: How do this?

The Verilog-XL Reference manual says this (12.5.3 Upwards Name Referencing):

  The name of a module is sufficient to identify the module and its location
  in the hierarchy. A lower-level module can reference items in a module
  above it in the hierarchy if the name of the higher-level module is known.
  The syntax for an upward reference is as follows:

        <name_of_module>.<name_of_item>

This is my interpretation of this:
The module name interface in top.node1.edqh identifies the module
instance top.node1, and the module name interface in top.node2.edqh
identifies the module instance top.node2. Thus, interface.alloc
is not ambiguious, and is my answer.

Am I wrong?

Ole Hermann F?rde



Sat, 19 Apr 1997 19:35:10 GMT  
 Bug in Verilog-XL 1.6b?

Quote:
>Ole,

>I finally see what your problem is:

>  module top;
>    interface node1();
>    interface node2();
>  endmodule

>  module interface;
>    task alloc;
>      $display("In %m");
>    endtask
>    exdevreq edqh();
>  endmodule

>  module exdevreq;
>    initial begin
>      interface.alloc;  // *** What is this?  See below.
>      #1 $finish;
>    end
>    specify specparam tsu = 1; endspecify
>  endmodule

>Your call to "interface.alloc" in module exdevreq makes no sense.
>There are 2 interface modules in this netlist (node1 and node2).
>You invocation of the alloc task is ambiguious.  Do you want
>Verilog to call the one in node1 or the one in node2?

On a side note, this type of bug/mistake exists with the sdf annotator also.
(At least with Cadence Verilog-XL)  In the SDF format if you give a
(INSTANCE module.blah...)  instead of a (INSTANCE instname.blah...) then
it seems to try to find the first instantiation of the module and annotate
the delays inside that, ignoring all other instances of 'module'

(I discovered this with a typo in an SDF file)

I've asked Cadence to at least warn when they encounter a module name where
one would normally expect an instance name.

--

Special Projects, Cent. Eng.
Tektronix, Inc.



Sun, 20 Apr 1997 02:47:26 GMT  
 Bug in Verilog-XL 1.6b?

Quote:
>Your call to "interface.alloc" in module exdevreq makes no sense.
>There are 2 interface modules in this netlist (node1 and node2).
>You invocation of the alloc task is ambiguious.  Do you want
>Verilog to call the one in node1 or the one in node2?

It makes a lot of sense. This is exactly how to access stuff in hierarchical models
that have multiple instantiations of a module (at some higher level in the hierarchy)

Unless the only sharing of information is thru ports. (ugh. netlists)

In the example, the reference IS deterministic. See the verilog manual on
Upwards Name Referencing.

Evidently specparam causes a bug in this.



Mon, 21 Apr 1997 05:53:15 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Verilog-XL `protect bug?

2. Cadence Openbook Verilog-XL Ref BUG.

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. Verilog-XL question (important)!

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

 

 
Powered by phpBB® Forum Software