SystemVerilog Interface style (managing continuous and non-c

  • Thread starter Andrew Burnside
  • Start date
A

Andrew Burnside

Guest
Hi

I am using SystemVerilog for a mixture of synthesis and testbench work
for a FPGA design. The interface definition is at the bottom of this
post.

I have a common bus that runs down through multiple design blocks.
This is broken out through muxes in some intermediate modules, rather
than having mux logic in the interface itself.

A <-i/f-> B <-i/f-> C etc.

This works absolutely fine for synthesis - I have a `ifdef SIMULATION
option which takes out clocking blocks
However, I am suffering a problem when trying to using this interface
as a testbench, due to both continuous (normal usage) and procedural
(clocking block) assignments to the same signals.

Ideally, I would like to have an interface that will function in both
modes, as then the test stimulus can be the same for both module test
and integration test.
Does anyone know if this is possible, or is it necessary to have a
special test version of the interface, that is specially included at
the top level?

The problem here being Testbench <-i/f-> A would want the clocking
block version of the interface and A <-i/f-> B would want a continous
assignment version.

Does anyone have thoughts on this?

Cheers

Andrew

P.S. The reason I have the clock as a separate port, is so that in the
testbench version I can pass the clock across to the program block
separately, to skew signals that aren't in the interface clocking
block.
------
//Interface def
`ifndef DATA_H
`define DATA_H
`timescale 1ns/10ps
`define SIMULATION
`ifdef SIMULATION
interface DATABUSINTERFACE(input logic clk);
`else
interface DATABUSINTERFACE;
logic clk;
`endif
//allow clock as an input, when using in testbench
logic wren;
logic rden;
logic [31:0] data_in; //split tristate bus at a higher level to
simplify lower blocks
logic [31:0] data_out;
`ifdef SIMULATION
//Clocking block for test signals
clocking cb @(posedge clk);
default input #1ns output #1ns;
output wren;
output rden;
output data_in;
input data_out;
endclocking

modport Test(clocking cb);
`endif

modport Master
(output clk,
output wren,
output rden,
output data_in,
input data_out
);

modport Slave
(input clk,
input wren,
input rden,
input data_in,
output data_out
);

endinterface : DATABUSINTERFACE

`endif
 
On Mon, 02 Jul 2007 05:35:08 -0700, Andrew
Burnside <andrew.burnside@sli-institute.ac.uk> wrote:


However, I am suffering a problem when trying to using this interface
as a testbench, due to both continuous (normal usage) and procedural
(clocking block) assignments to the same signals.
It should be OK because your target signals are variables (not nets)
in the interface.. The clocking block should update those signals
just after each clock *for which there has been a drive
to the signal*. Similarly, procedural code should update the
variable only when it's written to. Unfortunately, though, there
is some pretty serious ambiguity in the LRM about whether the
modport's output represents a true output port connection, i.e.
a continuous assignment on the target. To alleviate this you
could do one of two things - depends which your synth tool likes:

(1) have two variables in the interface, one driven through the
modport and one doing the real work:

interface sample;

logic the_real_signal;
logic driven_by_modport;

modport MPi(input the_real_signal);

modport MPo(output driven_by_modport);

clocking C @(whatever);
output the_real_signal;
endclocking

always @(driven_by_modport)
the_real_signal = driven_by_modport;

endinterface

Now, the only two things driving the_real_signal are the
clocking and your always block, and all should be well.

(2) make the signal a "ref" rather than an "output" in the
modport, so that procedural assignments to it are definitely
real procedural assignments.
--
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.
 
Thanks Jonathan

I have managed to sort the problem now.

Incidentally, why is there a distinction in SystemVerilog between the
procedural
always_comb a=b;

and continuous
assign a=b;

Perhaps there should be some general guidance on not to use continuous
assignments with interfaces.

Cheers

Andrew
 
On Thu, 05 Jul 2007 00:23:15 -0700,
Andrew Burnside wrote:

Incidentally, why is there a distinction in SystemVerilog between the
procedural
always_comb a=b;

and continuous
assign a=b;
Because they're completely different....

continuous "assign" creates a driver on its target NET;
procedural "always" dynamically performs updates on a target VARIABLE.

In SystemVerilog there's a special concession that allows
continuous assignment (both in its explicit form, and in
some of its many disguises) to drive a VARIABLE, provided
that nothing anywhere else ever makes any assignment to
that variable. In that case, the continuous assign pretty
much becomes equivalent to the corresponding always_comb.
This change in the fundamental Verilog rules now means that
RTL designers almost never need to use nets (wires) in their
synthesisable designs - variables work for everything except
multi-driver buses.

Perhaps there should be some general guidance on not to use continuous
assignments with interfaces.
I don't think so; but, as I said, there are some issues (which
have been discussed, but not fully resolved, in the SystemVerilog
standards committees) relating to the way drivers are or are not
created across modport connections. Only rarely does it make any
difference in practice; you seem to have found one of those cases.
You can read some of the discussion in the (long-ish) thread at
http://www.eda-stds.org/sv-bc/hm/5549.html

As a side issue, I'm currently trying to look more closely at
the usability of interfaces and modports for synthesisable
design, and (only if you have time, and only if you're
interested) I'd be glad to receive your private email
describing your experiences, good and bad, with them.

--
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.
 

Welcome to EDABoard.com

Sponsor

Back
Top