Intermixing clocking blocks, interfaces and tb code..

[jgg]

Hi everyone,

I'm trying to understand how to properly use clocking blocks and
interfaces in both synthesis code (where the clocking block is
ignored) and test bench code where it is used, and I'm not really sure
what the expected standard behavior should be..

For instance, if I have an interface like this:

interface foo(input logic Clk);
logic A;
logic B;

clocking cki @(posedge Clk);
input A;
output B;
endclocking;
clocking cko @(posedge Clk);
output A;
input B;
endclocking;
modport STB(clocking cki, clocking cko);
modport IN(input A, output B);
modport OUT(output A, input B);
end interface;

This is very similar to examples in the Chris Spear book..

I wan to use this in three ways:
1) To drive from a TB into a module with a foo.IN mod port
2) To monitor from a TB from a module with a foUT mod port
3) To interconnect two modules between foo.IN and foUT

But at least with Questa the clocking block gets in the way - it
considers the clocking block to be driving the signal even if there is
no reference to the clocking block. Ie the inout A in the clocking
block prevents a modport OUT connection because the module is driving
A.

Is this correct? Should a clocking block output be considered a driver
of a variable if there are no references to the clocking block? If so
then how can you effectively use clocking blocks?

Thanks,
Jason

 

[Jonathan Bromley]

On Mon, 21 Jan 2008 16:49:09 -0800 (PST),
jgg <jgunthorpe@gmail.com> wrote:

[a clocking block represents a procedural source for its
output variables]

Is this correct? Should a clocking block output be considered a driver
of a variable if there are no references to the clocking block? If so
then how can you effectively use clocking blocks?

Sore point. And it isn't just clocking blocks that cause this
trouble - a modport with an output in it has a similar effect
even when unused.

We've had such a discussion here before, and I've proposed a
couple of pragmatic answers - if-generate is an obvious one;
conditional compilation is good; keep two different interfaces,
one for verification and one for design, but with similar
modports on the DUT side (my usual pracrice, even though I
don't much like it); internal resolution of the multiple
drivers within the interface.

The root of this problem is that interfaces and clocking
blocks come from two different donations to the SV language,
and although it's natural to assume that they *should* play
well together, in fact they don't.
--
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.

 

[Mike Treseler]

jgg wrote:

For instance, it is
so awkward (and not at all 'modern') to have large scale not-object
things like programs, modules, interfaces and clocking blocks then
have almost a completely separate but highly overlapping area of
objects in the form of classes.

This seems to be a fundamental problem of hardware description.
I can infer *all* of the wires I need from clean code inside of
a synchronous [block/process] but I am otherwise left with some sort
of netlist description to test or reuse my [module/entity].

-- Mike Treseler

 

[jgg]

On Jan 22, 2:03 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Mon, 21 Jan 2008 16:49:09 -0800 (PST),

Is this correct? Should a clocking block output be considered a driver
of a variable if there are no references to the clocking block? If so
then how can you effectively use clocking blocks?

Sore point. And it isn't just clocking blocks that cause this
trouble - a modport with an output in it has a similar effect
even when unused.

Is that true about mod ports? I have cases like that in my design and
Questa accepts them. That seems really strange since it would seem to
defeat the intended use of interfaces as shortcuts for wiring IN to
OUT ports.

We've had such a discussion here before, and I've proposed a
couple of pragmatic answers - if-generate is an obvious one;

Ah, I've gone back and read some of the interesting posts from you. It
does seem like clocking blocks have quite a number of issues and based
on your postings I'm mildly surprised I'm not having timing issues too
in Questa..

conditional compilation is good; keep two different interfaces,
one for verification and one for design, but with similar

Right.. These interfaces are already being produced by a script, and
now the script just makes 3 copies, and all the classe that touch them
are parameterized/etc/etc. Generally very fugly.. Not at all what I
was hoping for when I first read about interfaces - at least they do
enable the driver/monitor classes to be general and that is the main
thing.

The root of this problem is that interfaces and clocking
blocks come from two different donations to the SV language,
and although it's natural to assume that they *should* play
well together, in fact they don't.

I see - I have to say SV has a very hacked together feeling to it. It
doesn't really feel like a unified language yet, more like a bunch of
different ideas co-existing with the same syntax. For instance, it is
so awkward (and not at all 'modern') to have large scale not-object
things like programs, modules, interfaces and clocking blocks then
have almost a completely separate but highly overlapping area of
objects in the form of classes.

Thanks!
Jason

 

[Jonathan Bromley]

On Tue, 22 Jan 2008 10:52:43 -0800 (PST),
jgg <jgunthorpe@gmail.com> wrote:

a modport with an output in it has a similar effect
[the output acts as if it were a continuous assignment]
even when unused.

Is that true about modports? I have cases like that in my
design and Questa accepts them.

Ah. I'd hoped you wouldn't ask about the way simulators
check this

That seems really strange since it would seem to
defeat the intended use of interfaces as shortcuts for
wiring IN to OUT ports.

I don't think that's the case. Roughly it boils down to this:
Interfaces work just great if you use them as a bundle-o-wires
for connecting designs together, using modports with inputs
and outputs and taking care that there is only one modport
"output" driving any given variable (multiple drivers on
nets are OK, of course). Interfaces are also OK as a
way to link designs to OOP testbenches through the marvel
of virtual interfaces, modports and clocking blocks (in
any reasonable combination!). Trying to write an interface
that meets both of these requirements is likely to cause
trouble with multiple driving sources on variables.

does seem like clocking blocks have quite a number of issues and based
on your postings I'm mildly surprised I'm not having timing issues too
in Questa..

The folk at Mentor have, as far as I'm aware, pre-emptively
implemented the proposed SV-2008 changes to clocking blocks
as part of a round of fixes to their implementation.

Generally very fugly.. Not at all what I was hoping for
when I first read about interfaces

You're preaching to the choir....
--
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.

 

[jgg]

On Jan 22, 1:41 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Tue, 22 Jan 2008 10:52:43 -0800 (PST),

jgg <jguntho...@gmail.com> wrote:
a modport with an output in it has a similar effect

[the output acts as if it were a continuous assignment]

even when unused.
Is that true about modports? I have cases like that in my
design and Questa accepts them.

Ah. I'd hoped you wouldn't ask about the way simulators
check this

That seems really strange since it would seem to
defeat the intended use of interfaces as shortcuts for
wiring IN to OUT ports.

I don't think that's the case. Roughly it boils down to this:
Interfaces work just great if you use them as a bundle-o-wires

Oh, I see what you are saying now, yes, in my instances I have a
single modport that is driving each signal and sometimes a clocking
block too, but I think you are right and I remember removing an OUT
modport in an interface that also had an output clocking block due to
the the multiple driver conflicts..

Thanks a bunch for you time, your answers are very enlightening
Jason

 

[jgg]

On Jan 22, 12:29 pm, Mike Treseler <mike_trese...@comcast.net> wrote:

jgg wrote:
For instance, it is
so awkward (and not at all 'modern') to have large scale not-object
things like programs, modules, interfaces and clocking blocks then
have almost a completely separate but highly overlapping area of
objects in the form of classes.

This seems to be a fundamental problem of hardware description.
I can infer *all* of the wires I need from clean code inside of
a synchronous [block/process] but I am otherwise left with some sort
of netlist description to test or reuse my [module/entity].

I wouldn't go so far as to claim it is a fundamental limitation - but
more or less what you start to run into is how much computation do I
have to do to get to a netlist. Verilog is pretty minimal and things
like SystemC are quite intense.

At least in SV you could already consider an interface to be a form a
degenerate object. Once converted to a virtual interface it has the
majority of the same properties and syntax as a normal class but a
different method of allocation. Similarly if any class could be
allocated statically instead of through new then it would be almost
identical to an interface. Personally it seems to me that interfaces
as a distinct type were maybe a mistake, it would have been more
integrated if you could have a 'virtual module' and then rely on
something similar to modports as the mechanism to create connection
bundles. Add in module inheritance and you are 99% of the way to a
proper object.

As it is today the rules for interfaces are so strange you end up
doing things like compiling an entire large checker as interface
instead of module just so you can nest them in other interfaces and
provide re-usable checking functionality.

Plus with Jonathan's clarification on how programs work, I think it
would have been more integrated and elegant if you could mark a thread
as being scheduled in the reactive region, ie:

reactive always ....
reactive fork ... join

Much clearer for us poor users

Most of this comes from my view of modern SW language design as
pushing toward more language flexibility and less hardwired special
casing. SV is rife with special cases and seems contrary to what the
leading high level languages are moving toward.

But that is all spilt milk. I personally am very curious to see how
the language evolves from here, or if maintaining compatibility with
todays code will fence off too many interesting avenues..

Regards,
Jason