Reading from a signal declared as an output in a modport

A

Andreas Ehliar

Guest
A colleague just asked me a SystemVerilog question which I was unable
to answer. Perhaps some SystemVerilog language lawyer on this group
could answer the following question?

Basically: If you define a signal as an output port in an interface by
using a modport, what is supposed to happen if you read from this
signal? Especially if you never write to this signal in the module
itself. Personally I would guess this should be an error, but this
doesn't seem to be the case in practice:

* In ModelSim (6.4a), it seems like you can read this value just as if
it was declared as an input.
* In Precision (2008a.17) it seems to be synthesized as if noone is
driving the signal at all


(Below is a simple design which shows what I mean if my description above
is not clear. Sorry about the extremely descriptive identifier names :))

interface wishbone;
logic stb; // strobe
logic ack; // normal termination
modport master(
output stb,
input ack);
modport slave(
input stb,
output ack);
modport monitor(
output stb,ack);
endinterface: wishbone

module apa(input logic clk,rst,
output reg nisse);

wishbone w();

grmbl a(w);
grmbl2 b(w,nisse);
grmbl_master c(clk,rst,w);

endmodule

module grmbl(wishbone.slave w);
assign w.ack = w.stb;
endmodule

module grmbl2(wishbone.monitor w,output logic a);
assign a = w.ack; // <-- This part reads from an output!
// What is supposed to happen?
endmodule

module grmbl_master(input logic clk,rst,wishbone.master m);
logic toggle;
always_ff @(posedge clk) begin
if(rst) begin
toggle <= 1'b0;
end else begin
toggle <= !toggle;
end
end
assign m.stb = toggle;
endmodule



//Andreas
 
On Thu, 4 Dec 2008 12:14:06 +0000 (UTC), Andreas Ehliar wrote:

If you define a signal as an output port in an interface by
using a modport, what is supposed to happen if you read from this
signal?
This is one of many things I (and others) are pushing to get
cleared up, but there is no clear-cut answer yet.

Unfortunately, the view taken of modports by synthesis people
and that taken by simulator vendors seems to be somewhat
different. One simulator expert recently pronounced that
"a modport is not a fragment of a module's port list; it is
an access control list to an interface" (or something to that
effect). I don't know what his authority for that is, and
I personally believe it's wrong, but if it is the case
then there is presumably nothing wrong with trying to read
a modport output; there are very, very few places in Verilog
where it's illegal to read an output.

Synthesis implementors must be able to synthesise each module
separately. To achieve this in the presence of modports, they
apparently want to treat modport inputs and outputs as if they
were continuous assignments across the (mod)port boundary, just
in the same way as for ordinary module inputs/outputs.
There's nothing crazy about this, but it does have some
weird knock-on effects - especially when you take virtual
interfaces into account.

An open request to comp.lang.verilog: If you encounter a use
case where you think SystemVerilog interfaces/modports ought
to provide a solution, please flag it up; I'm doing my best
to gather real user experiences and desires before shooting
my mouth off about how to improve the language.

Apologies for the rant - it's been troubling me for some time.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On 2008-12-04, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:
An open request to comp.lang.verilog: If you encounter a use
case where you think SystemVerilog interfaces/modports ought
to provide a solution, please flag it up; I'm doing my best
to gather real user experiences and desires before shooting
my mouth off about how to improve the language.
In this case, a student group was bitten by this inconsistency since
their RTL code simulated great in ModelSim without any warnings
whatsoever whereas the synthesized RTL code didn't work correctly
at all. Granted, the Synthesizer probably outputted something
(I didn't see the logfile myself, I only heard about this later on)
which should have raised suspicions for an experienced user. Since
this is our student's first time with SystemVerilog however, a clear
warning message from the synthesis tool would have been nice. Something
like:

"You are trying to read a signal declared as an output modport without
assigning a value to it in this module."


Another pet peeve with the SystemVerilog support in ModelSim:

Why doesn't ModelSim complain if I create a latch in an always_comb
block?


/Andreas
 
Andreas Ehliar <ehliar-nospam@isy.liu.se> writes:

Why doesn't ModelSim complain if I create a latch in an always_comb
block?
According to IEEE1800-2005 it doesn't have to. Would be nice of
course, but requires an extra analysis step. The tool would have to
detect that there is a chance that a signal doesn't get assigned in
all paths through a always_comb block.

For a synthesis tool this is much easier to handler, since all
functionality is already there.

Regards
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)
 
On 2008-12-05, Marcus Harnisch <marcus.harnisch@gmx.net> wrote:
For a synthesis tool this is much easier to handler, since all
functionality is already there.
On the other hand, I would guess that almost all functionality to
figure this out would be available in ModelSim as well. (ModelSim
should have a fairly good idea of this since it would need this
to optimize the RTL code for maximum simulation speed.)

/Andreas
 
On Fri, 5 Dec 2008 05:24:30 +0000 (UTC), Andreas Ehliar wrote:

RTL code simulated great in ModelSim without any warnings
whatsoever whereas the synthesized RTL code didn't work correctly
at all. Granted, the Synthesizer probably outputted something
(I didn't see the logfile myself, I only heard about this later on)
which should have raised suspicions for an experienced user. Since
this is our student's first time with SystemVerilog however, a clear
warning message from the synthesis tool would have been nice. Something
like:

"You are trying to read a signal declared as an output modport without
assigning a value to it in this module."
So it does very much sound as though the simulator is
treating the "output" modport as a reference to the variable
in the interface - so a module having the output modport can
see changes to the interface's signal caused by some
other activity - whereas synthesis treats it as a continuous
assignment from module to interface, making the interface
signal's value invisible in the connected module.

Thanks for the example.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Andreas Ehliar <ehliar-nospam@isy.liu.se> writes:

On the other hand, I would guess that almost all functionality to
figure this out would be available in ModelSim as well. (ModelSim
should have a fairly good idea of this since it would need this
to optimize the RTL code for maximum simulation speed.)
Maybe. Perhaps this is only done if -vopt is enabled (not sure if this
option is a Questa-only thing).

Regards
Marcus
 

Welcome to EDABoard.com

Sponsor

Back
Top