System Verilog Interfaces

[mike v.]

I've read comments that system verilog interfaces are not used much at
all in synthesizable designs. I know that the modport function is not
supported by synopsys design compiler. Are there other known issues
with trying to use interfaces in synthesizable code? I'm trying to
find out specifically what is keeping designers from adopting SV
interfaces.

Thanks

 

[Jonathan Bromley]

On Fri, 26 Mar 2010 22:46:32 -0700 (PDT), "mike v." wrote:

I've read comments that system verilog interfaces are
not used much at all in synthesizable designs.

Here we go again....

I know that the modport function is not
supported by synopsys design compiler.

Not true. Modports *are* supported by DC, at least for
all the basic synthesisable usage models. There are some
features that are not yet supported by DC (or, come to that,
by any other synth tool I know of):
- modport expressions
- interface instances in generate loops
- ... ?

Generally you should *always* use modports on interfaces
that will be synthesised. Non-modport access to the
insides of an interface is effectively the same as using
a "ref" port, and synthesis is rarely happy with that.

Are there other known issues
with trying to use interfaces in synthesizable code?

The most important one, I believe, is that interfaces
don't really solve the problems that designers might
reasonably hope they would - except in some rather
simple cases, where the added trouble of learning and
using interfaces is probably not justified by the
modest improvement in design expressiveness.

I'm trying to find out specifically what is keeping
designers from adopting SV interfaces.

<polemic>

Mostly, it's because designers DON'T CARE ABOUT
ABSTRACTION. RTL designers have been taught, trained,
encouraged, even forced to think about their designs
as a huge ramshackle collection of low-level bits and
pieces "because that's easier to understand" (hah!).
Consequently, when anyone tries to open a discussion
on improving the abstraction level of RTL design,
the conversation degenerates into endless repetition
of a few shibboleths:
- I don't want abstraction. It makes the code too
difficult to understand.
- We can't use sophisticated RTL techniques. Our
brain-dead linting tool wouldn't understand them
and we would never be able to justify them to
project management.
- Verilog is for low-level stuff. If you want
abstraction, use a C-synthesis tool and all
your problems will go away.
- I've been taught to use continuous assignment and
register-only clocked processes for everything, and
I don't intend to change now.
- You don't need interfaces. Connecting your modules
using wildcard .* port connection does the job in
fewer lines of code.

It's hardly surprising that tool vendors have failed
to implement the full feature set of interfaces, and
users have consistently ignored them (except for
virtual interfaces in object-oriented testbenches, a
usage which is far from optimal and can be replaced
by much more effective techniques that don't require
the use of interfaces at all).

So.... I despair. Interfaces are just one of many
initiatives that have come and (nearly) gone over the
past few years in a failed attempt to get RTL designers
to think about something other than wires and gates.
I've been campaigning for at least five years to
get interfaces implemented, adopted and enhanced;
it's been a waste of time, and I have more-or-less
given up now. I suspect the future lies with
script-based code generation tools such as MyHDL,
leaving Verilog to pick up the low-level pieces
after the generation tool has done its work.

</polemic>

Sorry for offloading my frustration on to you.
--
Jonathan Bromley

 

[David Rogoff]

On 2010-03-27 03:21:33 -0700, Jonathan Bromley said:

On Fri, 26 Mar 2010 22:46:32 -0700 (PDT), "mike v." wrote:

I know that the modport function is not
supported by synopsys design compiler.

Not true. Modports *are* supported by DC, at least for
all the basic synthesisable usage models. There are some
features that are not yet supported by DC (or, come to that,
by any other synth tool I know of):

Yes, they work fine in DC and various FPGA tools like Certify.

Generally you should *always* use modports on interfaces
that will be synthesised. Non-modport access to the
insides of an interface is effectively the same as using
a "ref" port, and synthesis is rarely happy with that.

Yeah - If you don't use modports how do you specify direction of signals?

Are there other known issues
with trying to use interfaces in synthesizable code?
I'm trying to find out specifically what is keeping
designers from adopting SV interfaces.

Ignorance, like your original post, and some tools still have issues with them.

- You don't need interfaces. Connecting your modules
using wildcard .* port connection does the job in
fewer lines of code.

I think anyone who uses .* in synthesizable code should be shot. It's
just way too easy to miss connections and makes source-code debugging
pretty useless. I really do like the .port, construct because it
encourages not changing signal names throughout the hierarchy and makes
it clear when you do.

I've been campaigning for at least five years to
get interfaces implemented, adopted and enhanced;
it's been a waste of time, and I have more-or-less
given up now. I suspect the future lies with
script-based code generation tools such as MyHDL,
leaving Verilog to pick up the low-level pieces
after the generation tool has done its work.

Jonathan, you seem really caught up with a few Interface features that
haven't been implemented. I think they're incredibly useful the way
they are. It makes implementing of standard buses much easier and
cleaner in writing code, writing monitors, and displaying the buses in
waveform viewers. It helped me shink an unmanagable 20k+ line
top-level ASIC file down to about 2k lines making it much easier to get
the signal connections correct and orders of magnitude easier to
re-arrange modules within the hierarchy.

SystemVerilog support is still radiply changing in the big CAE tools. I
just keep pushing the Synopsys and other FAEs to fix/add the features I
want. I don't think giving up on a new and expanding language is the
way to go. I've seen cases of designers going with something like
MyHDL and it's usually a disaster. There's basically no tool support
for them so you end up having to debug the script-generated, and
usually unreadable Verilog code. I don't want anything to do with that.

David

 

[Jonathan Bromley]

On Sat, 27 Mar 2010 15:15:24 -0700, David Rogoff wrote:

I think anyone who uses .* in synthesizable code should be shot. It's
just way too easy to miss connections

Surprisingly, I disagree. Using .* (or your preference, .name)
in a port map will automatically suppress the usual Verilog
nonsense about implicit declaration of wires - no more
messing around with `default_nettype none and all its
unpleasant side-effects. So, if you miss a connection
(by failing to declare it in the enclosing module), you
will get a fatal elaboration error. I do agree, though,
that it is painfully easy to miss the specification of
a *non-matching* connection and, for example, end up with
the wrong chip-select on your instance.

Using .* really comes into its own when you need to
create a wrapper module that simply echoes out another
module's ports with a very few tweaks, and for the
creation of very simple bring-up testbenches. Generally,
though, I am deeply distrustful of tricks like .* that
are designed to save lines of code. The act of writing
(typing-in) the code is a tiny, tiny fraction of the
total effort on a project. Language constructs that
save some coding time, at the expense of debugging
time, are definitely counter-productive. So I strongly
agree with your general distaste for .*

really do like the .port, construct because it
encourages not changing signal names throughout
the hierarchy and makes it clear when you do.

Right, and like .* it defeats the egregious implicit
wire declaration behaviour, so it's all good.

Jonathan, you seem really caught up with a few Interface features that
haven't been implemented. I think they're incredibly useful the way
they are. It makes implementing of standard buses much easier

I absolutely agree with your motivations for using interfaces,
and generally agree with your enthusiasm for their use. But
there are many things that interfaces ought to be able to do
but they can't, for lack of expressiveness. I don't want to
rehearse my reasoning for that here; I've gone into print
about it too many times already. Some of the lack of
expressive power of interfaces is due to their poor
design and specification in the language standard; some
(notably modport expressions and generated instances)
is due to useful language constructs that are inadequately
implemented by current tools, and thus unusable.

SystemVerilog support is still radiply changing in the big CAE tools. I
just keep pushing the Synopsys and other FAEs to fix/add the features I
want. I don't think giving up on a new and expanding language is the
way to go.

I wish I could share your positive attitude. The context is
that I am within sight of the end of my career, and future SV
enhancements are fast disappearing beyond my "career horizon".
That's a strong demotivator for pushing... sorry.

I've seen cases of designers going with something like
MyHDL and it's usually a disaster. There's basically no tool support
for them so you end up having to debug the script-generated, and
usually unreadable Verilog code. I don't want anything to do with that.

I am very aware that such things are far from perfect, and
probably not ready for mainstream use just yet. But I
nevertheless feel that a layer on top of the core language
is the way to go. It can be developed quickly, in isolation,
without polluting the core language. Experience gained
with it can then be fed into future language developments.

A fine example of that idea comes from Vera - the testbench
automation language promoted by Synopsys. It was originally
a separate tool that bolted on the side of your Verilog
simulator. But the design of Vera was cunningly aligned
with Verilog, and it was comparatively easy to graft it
into the core language - giving us the whole SystemVerilog
OOP and testbench automation feature set. (The scars
of that grafting operation are still visible in quite
a few places, but broadly speaking it was a success.)

I guess I'm kinda hoping that the massive shift in SV,
away from RTL-ish approaches and towards software-like
verification constructs, will wrest ownership of the
language out of the hands of the RTL community - and
thus leave the field open for creative development
of design-oriented bolt-ons in the same way that Vera
led in the development of verification features.

Thanks for the response.
--
Jonathan Bromley

 

[mike v.]

Thanks Jonathan for your response. I recently took a System Verilog
class and I thought I heard the instructor say that modports weren't
supported by DC but obviously I was mistaken. Maybe the instructor
said modport expressions and I only remembered the word modport. The
inability to use interfaces inside a generate block is unfortunate, I
like to use generates to build parameterizable code. So that would
limit the usefulness of interfaces for my purposes.

It doesn't surprise me that hardware designers are slower than
software designers to adopt new features of a language. The
consequences of a bug are much more severe in an ASIC than in firmware
or software. So it seems reasonable that hardware folks are going to
stick with what they know works until they are sure a completely
reliable alternative exists. I haven't seen a lot of RTL designers who
only use assignments and register-only clocked blocks but then I
probably haven't been exposed to anywhere near the variety of
designers as you have. I've been in the same group for about 11 years.
I did see a design once where the designer instantiated gates by hand,
it was completely insane and unreadable. He was an older fellow and
probably did most of his design work with schematics. Some people can
change their practices to take advantage of improved tools and some
can't.

 

[Jan Decaluwe]

On Mar 27, 12:21 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

I suspect the future lies with
script-based code generation tools such as MyHDL,
leaving Verilog to pick up the low-level pieces
after the generation tool has done its work.

Thanks for the publicity. However, describing MyHDL
as "script-based code generation" is bound to give
a wrong impression.

MyHDL is a way to use the Python language as a HDL. You
develop, debug and verify your design with MyHDL/Python.
You can then convert a verified design to Verilog/VHDL to
connect to mainstream design flows.

Conversion is done on a design instance that has been
elaborated by the Python interpreter. This means that
you can do very powerful things to create your design,
without jeopardizing convertibility.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[Jan Decaluwe]

On Mar 28, 12:15 am, David Rogoff <da...@therogoffs.com> wrote:

I've seen cases of designers going with something like
MyHDL and it's usually a disaster.  There's basically no tool support
for them so you end up having to debug the script-generated, and
usually unreadable Verilog code.  I don't want anything to do with that..

"Something like" MyHDL is not MyHDL MyHDL/Python *is* a design
tool.
It doesn't do dumb code generation, but intelligent code conversion of
a verified design instance. Readibility is quite OK (because it
reflects
your input code closely) even though Verilog is used as a back-end
language.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[David Rogoff]

On 2010-03-29 08:40:22 -0700, Jan Decaluwe said:

On Mar 27, 12:21 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:

I suspect the future lies with
script-based code generation tools such as MyHDL,
leaving Verilog to pick up the low-level pieces
after the generation tool has done its work.

Thanks for the publicity. However, describing MyHDL
as "script-based code generation" is bound to give
a wrong impression.

MyHDL is a way to use the Python language as a HDL. You
develop, debug and verify your design with MyHDL/Python.
You can then convert a verified design to Verilog/VHDL to
connect to mainstream design flows.

How does one debug in MyHDL/Python? Do you have a waveform viewer?
Hardware engineers (like me) want/need to see waveforms for
signal/protocol timing. Can I use a Verilog or cpp testbench? Can I
debug my new module connected to hundreds of existing Verilog
modules/IP? Are you expecting users to start from scratch and write
the whole design in MyHDL/Python? I hope not, or just immediately
lost anyone doing a large project, which is presumably the audience who
would want the power of your language.

Conversion is done on a design instance that has been
elaborated by the Python interpreter. This means that
you can do very powerful things to create your design,
without jeopardizing convertibility.

What are the issues with type conversions? How do I specify my module
interfaces (including using SV Interfaces, which was the OT)?

I've done mixed language design/sim before (Verilog, VHDL, e, Vera, c)
and it's always a huge pain. Again, I'm not sure if your environment
even supports mixed sim or just debug followed by conversion to RTL,
which would be extremely limiting. I hope I'm misunderstanding
something here.

David

 

[Jan Decaluwe]

On Mar 30, 12:30 am, David Rogoff <da...@therogoffs.com> wrote:

On 2010-03-29 08:40:22 -0700, Jan Decaluwe said:



On Mar 27, 12:21 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:

I suspect the future lies with
script-based code generation tools such as MyHDL,
leaving Verilog to pick up the low-level pieces
after the generation tool has done its work.

Thanks for the publicity. However, describing MyHDL
as "script-based code generation" is bound to give
a wrong impression.

MyHDL is a way to use the Python language as a HDL. You
develop, debug and verify your design with MyHDL/Python.
You can then convert a verified design to Verilog/VHDL to
connect to mainstream design flows.

How does one debug in MyHDL/Python?  Do you have a waveform viewer?  
Hardware engineers (like me) want/need to see waveforms for
signal/protocol timing.  Can I use a Verilog or cpp testbench?  Can I
debug my new module connected to hundreds of existing Verilog
modules/IP?  Are you expecting users to start from scratch and write
the whole design in MyHDL/Python?   I hope not, or just immediately
lost anyone doing a large project, which is presumably the audience who
would want the power of your language.



Conversion is done on a design instance that has been
elaborated by the Python interpreter. This means that
you can do very powerful things to create your design,
without jeopardizing convertibility.

What are the issues with type conversions?  How do I specify my module
interfaces (including using SV Interfaces, which was the OT)?

I've done mixed language design/sim before (Verilog, VHDL, e, Vera, c)
and it's always a huge pain. Again, I'm not sure if your environment
even supports mixed sim or just debug followed by conversion to RTL,
which would be extremely limiting. I hope I'm misunderstanding
something here.

Look, I am not trying to convince anybody and I'm certainly not
going to irritate people here with lengthy discussions that don't
belong in this newsgroup.

I am simply trying to make sure you have correct information,
which you apparently had not. If you are not interested, it should
at least be for the right reasons If you are, more info is easy
to find.

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[Alan Fitch]

On 27/03/2010 10:21, Jonathan Bromley wrote:

On Fri, 26 Mar 2010 22:46:32 -0700 (PDT), "mike v." wrote:

I've read comments that system verilog interfaces are
not used much at all in synthesizable designs.

Here we go again....

I know that the modport function is not
supported by synopsys design compiler.

Not true. Modports *are* supported by DC, at least for
all the basic synthesisable usage models. There are some
features that are not yet supported by DC (or, come to that,
by any other synth tool I know of):
- modport expressions
- interface instances in generate loops
- ... ?

Generally you should *always* use modports on interfaces
that will be synthesised. Non-modport access to the
insides of an interface is effectively the same as using
a "ref" port, and synthesis is rarely happy with that.

Are there other known issues
with trying to use interfaces in synthesizable code?

The most important one, I believe, is that interfaces
don't really solve the problems that designers might
reasonably hope they would - except in some rather
simple cases, where the added trouble of learning and
using interfaces is probably not justified by the
modest improvement in design expressiveness.

I'm trying to find out specifically what is keeping
designers from adopting SV interfaces.

polemic

Mostly, it's because designers DON'T CARE ABOUT
ABSTRACTION. RTL designers have been taught, trained,
encouraged, even forced to think about their designs
as a huge ramshackle collection of low-level bits and
pieces "because that's easier to understand" (hah!).
Consequently, when anyone tries to open a discussion
on improving the abstraction level of RTL design,
the conversation degenerates into endless repetition
of a few shibboleths:
- I don't want abstraction. It makes the code too
difficult to understand.
- We can't use sophisticated RTL techniques. Our
brain-dead linting tool wouldn't understand them
and we would never be able to justify them to
project management.
- Verilog is for low-level stuff. If you want
abstraction, use a C-synthesis tool and all
your problems will go away.
- I've been taught to use continuous assignment and
register-only clocked processes for everything, and
I don't intend to change now.
- You don't need interfaces. Connecting your modules
using wildcard .* port connection does the job in
fewer lines of code.

It's hardly surprising that tool vendors have failed
to implement the full feature set of interfaces, and
users have consistently ignored them (except for
virtual interfaces in object-oriented testbenches, a
usage which is far from optimal and can be replaced
by much more effective techniques that don't require
the use of interfaces at all).

So.... I despair. Interfaces are just one of many
initiatives that have come and (nearly) gone over the
past few years in a failed attempt to get RTL designers
to think about something other than wires and gates.
I've been campaigning for at least five years to
get interfaces implemented, adopted and enhanced;
it's been a waste of time, and I have more-or-less
given up now. I suspect the future lies with
script-based code generation tools such as MyHDL,
leaving Verilog to pick up the low-level pieces
after the generation tool has done its work.

/polemic

Sorry for offloading my frustration on to you.

Hi Jonathan,
I've pondered this as well.

I agree that being indoctrinated in an RTL mindset is part of the
picture. However I don't think that's the main story.

My theory is that people only either accept or even search for new
methodologies if they suffer pain.

The reason OO gained ground in verification is because it solved a
problem that caused verification engineers pain - the design and re-use
of verification components to allow rapid construction of said environments.

Hardware engineers don't feel any pain using their current methodology.
It works. In fact you could argue that large chip design projects are
consistently more successful than large software projects (NHS anyone?).
Our cellphones, fridges, TVs etc are full of absolutely gigantic chips
with millions (billions?) of transistors that actually work.

Currently in my opinion there *is* some pain starting to be felt by
hardware designers - hardware / software co-design (on-chip processors);
and multi-core.

Regarding abstraction, I suspect that the "problem" interfaces solve is
not a problem. In the ASIC world, designers write scripts to bind blocks
together (or they get their cat to walk on the keyboard, another way to
write a PERL script.). In the FPGA world, they are either designing
small chips where the wiring is manageable; or they are using graphical
tools (e.g. Altera block diagram editor, Xilinx SysGen etc).

Some other random statements:

I sometimes ask attendees on the Expert VHDL course what their biggest
problem is (mostly FPGA designers): the majority reply "place and route
time".

I suspect (and I'd be interested to have figures) that the majority of
FPGA designs are small - hence, again, no pain.

On a recent course I had some delegates who'd decided to start using
*simulation* because using ChipScope or SignalTap had become
un-productive on large designs. So perhaps in your last years of
electronics, you should be promoting simulation first - then abstraction :-;

regards
Alan

--
Alan Fitch
Senior Consultant

Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of
Doulos, unless specifically stated.

 

[Alan Fitch]

On 31/03/2010 11:57, Jonathan Bromley wrote:

On Mar 30, 11:12 am, Alan Fitch<alan.fi...@spamtrap.com> wrote:

My theory is that people only either accept or even search for new
methodologies if they suffer pain.

The reason OO gained ground in verification is because it solved a
problem that caused verification engineers pain - the design and re-use
of verification components to allow rapid construction of said environments.

Hardware engineers don't feel any pain using their current methodology.

Well, this one does But you're almost certainly right, and
it's probably something I should have observed for myself. Sadly
I'm a geek, so I'm overly inclined to go looking for geeky
solutions to problems that don't exist. (Come to that, I
think it's probably fair to say that you're a geek too -
just a better-read and better-balanced one than I am.)

Hi Jonathan,

There's no way I'm better read! I even (gasp!) thought it was "Sellars"
not "Sellar".

Or better-balanced for that matter...

Perhaps I should have said "hardware engineers don't feel enough
pain...", that might be closer to the truth - then the pressure of
project deadlines provides a sufficient dis-incentive to worry about a
lack of new methodologies.

regards
Alan

Thanks for the reality check.

Regards
--
Jonathan Bromley

--
Alan Fitch
Senior Consultant

Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of
Doulos, unless specifically stated.

 

[Jonathan Bromley]

On Mar 30, 11:12 am, Alan Fitch <alan.fi...@spamtrap.com> wrote:

My theory is that people only either accept or even search for new
methodologies if they suffer pain.

The reason OO gained ground in verification is because it solved a
problem that caused verification engineers pain - the design and re-use
of verification components to allow rapid construction of said environments.

Hardware engineers don't feel any pain using their current methodology.

Well, this one does But you're almost certainly right, and
it's probably something I should have observed for myself. Sadly
I'm a geek, so I'm overly inclined to go looking for geeky
solutions to problems that don't exist. (Come to that, I
think it's probably fair to say that you're a geek too -
just a better-read and better-balanced one than I am.)

Thanks for the reality check.

Regards
--
Jonathan Bromley

 

[fpgabuilder]

On Mar 31, 5:36 am, Alan Fitch <alan.fi...@spamtrap.com> wrote:

On 31/03/2010 11:57, Jonathan Bromley wrote:



On Mar 30, 11:12 am, Alan Fitch<alan.fi...@spamtrap.com>  wrote:

My theory is that people only either accept or even search for new
methodologies if they suffer pain.

The reason OO gained ground in verification is because it solved a
problem that caused verification engineers pain - the design and re-use
of verification components to allow rapid construction of said environments.

Hardware engineers don't feel any pain using their current methodology..

Well, this one does  But you're almost certainly right, and
it's probably something I should have observed for myself.  Sadly
I'm a geek, so I'm overly inclined to go looking for geeky
solutions to problems that don't exist.  (Come to that, I
think it's probably fair to say that you're a geek too -
just a better-read and better-balanced one than I am.)

Hi Jonathan,

There's no way I'm better read! I even (gasp!) thought it was "Sellars"
not "Sellar".

Or better-balanced for that matter...

Perhaps I should have said "hardware engineers don't feel enough
pain...", that might be closer to the truth - then the pressure of
project deadlines provides a sufficient dis-incentive to worry about a
lack of new methodologies.

regards
Alan

Thanks for the reality check.

Regards
--
Jonathan Bromley

--
Alan Fitch
Senior Consultant

Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel:  + 44 (0)1425 471223               Email: alan.fi...@doulos.com      
Fax:  +44 (0)1425 471573                http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of
Doulos, unless specifically stated.

Necessity is the mother of invention... what engineers think is
necessary is sometimes not quite seen so by the people who write the
checks...

So far I managed to use interfaces in the following fashion. I am
able to successfully use the environment in Modelsim-DE and synthesize
the RTL in Quartus. Ofcourse it took a bit of learning and
knowledgeable folks such as Jonathan to weigh-in in my discussions on
this group... thanks! -

1. Define a parameterized bus of an interface as a module port in the
top-level. This amounts to explicit declaration of the interface
port. I did not use any generic interface ports. Quartus complained
of the missing interface declaration here. One of the book suggests
that it should not be the case... especially given that the interfaces
are contained in their own files. But to Quartus it did matter.
Interestingly it only needed the name of the file in its compile
list. There was no file-order dependency though.

2. Buses inside the interfaces are parameterized. And I change these
parameters from one place in a test-bench to setup different test
cases. Did not use any generate statements inside the interface
itself. Did not use any modport expressions but ofcourse used
modports.

3. Calling functions inside the simulation specific portion of the
interface block that are defined in one of the test-bench files.
Instantiating these interfaces a parameterized number of times in the
RTL. I understand some may have issues with this... but this was
easiest at the time... I had also to convince the guys who write the
checks. But a better way I agree would be to put the functions in a
package. Will get there.

4. Referencing individual bits (i don't know a better word) of the
interface vector inside a generate block.

All these are likely the least of the interface support provided by
all the vendors... let me know if it isn't. I delightfully live in
the FPGA world where a lot of asic constraints or pressures are not
present. The point though is that just by these few basic interface
features, I have been able to create an environment to run various
what-if-analysis quickly. Especially since I have over a hundred
processing chains each with their own clocks, resets, etc. talking to
some common and some different interfaces and even same file in some
cases.