SystemVerilog 3.1 LRM (Exceptions and Multiple Inheritance/J

[Paul Baleme]

I've recently been looking at the SystemVerilog 3.1 LRM. I am trying
to figure out how to accomplish multiple-inheritance or Java style
interface/implements constructs. I prefer the Java implementation as
I am in the "multiple-inheritance bad" camp, but I can't figure out
how one would implement certain OO design patterns efficiently in
SystemVerilog without one or the other.

I found a good discussion of C++ multiple-inheritance vs. Java
interfaces at:

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=34&t=000087

SystemVerilog "interfaces" are a different animal (unless I'm missing
something).

SystemVerilog also does not seem to support exceptions.

 

[Jonathan Bromley]

"Paul Baleme" <pbaleme@whoever.com> wrote in message
news:67e2442f.0402051544.7a365a5e@posting.google.com...

I've recently been looking at the SystemVerilog 3.1 LRM.

Interesting question: Why has there been so little mention
of SV3.1 here on comp.lang.verilog? I would have thought
that the whole Verilog community should be interested in
how it progresses.

I am trying
to figure out how to accomplish multiple-inheritance or Java style
interface/implements constructs. I prefer the Java implementation as
I am in the "multiple-inheritance bad" camp, but I can't figure out
how one would implement certain OO design patterns efficiently in
SystemVerilog without one or the other.

I think you may be right, although I'm not enough of a heavy-
duty OO-er to be sure. Can you give a few examples?

SystemVerilog "interfaces" are a different animal
(unless I'm missing something).

Yes, they are a structural construct rather like modules,
and they have little to do with Java-style "interfaces".

SystemVerilog also does not seem to support exceptions.

I think you're right - there is no explicit "catch" or
similar mechanism.

If this were three weeks ago I'd suggest you get yourself
signed up on the SV standards group's email reflector,
but they're all frantically checking over the final
draft of SV3.1a right now so I guess you mught not get
the fastest response!

As a matter of interest, what problems are you hoping
to solve that would be better solved using the techniques
you mention?

Cheers
--

Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Paul Baleme]

"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message news:<bvvm87$cca$1$8300dec7@news.demon.co.uk>...

As a matter of interest, what problems are you hoping
to solve that would be better solved using the techniques
you mention?

I wouldn't say that there are things that cannot be done without
exceptions, or multiple inheritance/Java style interfaces, but they
make things easier. Here are a couple examples:

Exceptions are useful for reducing the amount of error checking that
the test/testbench writers have to deal with. For example, the spec
has the following code snippet in the random constraint section:

if (bus.randomize == 1)
$display("addr = %16h data = %h\n",bus.addr, bus.data);
else
$display("Randomization failed.\n");

This kind of inline exception handling/error checking is tedious and
error prone. It makes the code more verbose and therefore harder to
read. With exceptions, the code could be changed to:

bus.randomize;
$display ("addr = %16h data = %h\n",bus.addr, bus.data);

Where the randomize method might throw a "RandomizationFailed"
exception. There could be a single exception handler at highest level
in the test that would point the user to the randomize method that
failed.

An example for multiple inheritance/Java interfaces is difficult for
me to write up in a brief example, but I'll give it a shot. Let's
pretend that you have some abstract classes that you want certain BFMs
to conform to. You might have one for packet based BFMs, another for
some generic order checking rule module, another that upstream agents
must conform to, another that downstream agents must conform to, etc.
You might want BFMs to conform to different ones. BFM A might need
to conform to 1, 3 and 4. BFM B might need to conform to 2, 3, 4, and
5, etc. Trying to manage this with a strict class hierarch can be
cumbersome. With Java style interfaces, the compiler flags an error
if the BFM does not conform to the interface. The review for
compliance is to simply check that the BFM is implementing that
interface, and relying on the compiler to do the rest.