Parametrisation of a design with interfaces (array of interf

S

siso

Guest
I was looking for a way to parametrise a design which heavily uses
interface constructs. Surprisingly or not - it appears to be a
challenge and I'm struggling to find my way trough. The biggest
trouble being ".... not implemented yet" or even worse - buggy tool
behaviour. The feeling is that I'm stepping on a thin ice.

The question is - has anybody around already been trough a similar
pain?

Some ideas so far:-
- Interface arrays -> DC is not happy with modport arrays (at least)
- Modport expressions -> simulators don't like them ("yet")
- aliases (trying to rewire the stuff inside the interfaces)-> same as
above

The only (kind of OK) way found so far is using packed typedefs inside
the interfaces - they can be parametrised. It doesn't look very nice
though when you try to split a slice from the whole bundle - looks
ugly and confusing.

Your thoughts will be appreciated.

s1s0
 
On Wed, 24 Feb 2010 07:23:51 -0800 (PST), siso wrote:

I was looking for a way to parametrise a design which heavily uses
interface constructs. Surprisingly or not - it appears to be a
challenge
Yup. The combination of language weakness and
incomplete tool support is painful.

The question is - has anybody around already been trough a similar
pain?
Yes, and three published papers to prove it :)

Some ideas so far:-
- Interface arrays -> DC is not happy with modport arrays (at least)
Where do you try to put them? In a generate loop?
I don't think the language supports the concept of
"modport array" directly, but you can put modports
inside a generate loop. The interesting challenge
then is to decide what the blazes they're called,
and how to connect them up internally. Which
brings us to...

- Modport expressions -> simulators don't like them ("yet")
Questa supports them. Dunno about the others.

- aliases (trying to rewire the stuff inside the interfaces)-> same as
above
Do you mean the real SV "alias" construct? That's another poorly
supported language feature.

The only (kind of OK) way found so far is using packed typedefs inside
the interfaces - they can be parametrised. It doesn't look very nice
though when you try to split a slice from the whole bundle - looks
ugly and confusing.
Yes. A good enough reason for abandoning interfaces
(in their present form) altogether.

Your thoughts will be appreciated.
If you can move VERY fast.... On Friday there is a
requirements gathering meeting for SystemVerilog-201X.
Peter Flake and I are both doing short presentations
on interfaces. If you can highlight your application
and indicate what you would like interfaces to do
for you, it may get some mindshare at the meeting.
But I would need to know TODAY!
--
Jonathan Bromley
 
The question is - has anybody around already been trough a similar
pain?

Yes, and three published papers to prove it :)
I think I read at least one of them. If they are publicly available -
I would be happy to have a fresh look. Would you please provide some
links?
Some ideas so far:-
- Interface arrays -> DC is not happy with modport arrays (at least)

Where do you try to put them?  In a generate loop?
I don't think the language supports the concept of
"modport array" directly, but you can put modports
inside a generate loop.  The interesting challenge
then is to decide what the blazes they're called,
and how to connect them up internally.  Which
brings us to...

I've just tried arrays of interfaces (not parametrised) connected
trough module ports and they seem to simulate properly on most popular
platforms. I'll drop an example tomorrow from work. DC however is
rejecting them.
- Modport expressions -> simulators don't like them ("yet")

Questa supports them.  Dunno about the others.

NC doesn't "yet". I have to check VCS as well.
- aliases (trying to rewire the stuff inside the interfaces)-> same as
above

Do you mean the real SV "alias" construct? That's another poorly
supported language feature.

Yes. Looked to me like an alternative to modports, but failed to
compile miserably. Again "not supported YET".
The only (kind of OK) way found so far is using packed typedefs inside
the interfaces - they can be parametrised. It doesn't look very nice
though when you try to split a slice from the whole bundle - looks
ugly and confusing.

Yes.  A good enough reason for abandoning interfaces
(in their present form) altogether.
That sounds scary to me. I've looked at interfaces as one of the few
real innovations in the RTL coding. It seems that the whole focus went
into the verification world, but hey - you have to have an RTL first
in order to verify something?!
Your thoughts will be appreciated.

If you can move VERY fast.... On Friday there is a
requirements gathering meeting for SystemVerilog-201X.
Peter Flake and I are both doing short presentations
on interfaces.  If you can highlight your application
and indicate what you would like interfaces to do
for you, it may get some mindshare at the meeting.
But I would need to know TODAY!
It sounds very tempting (thanks!), but it's a real short notice.
Nevertheless - I would appreciate to see the materials if possible,
and would be happy to share some thoughts over the mail.
In the same time - it was a hope that the solution is not miles away?!
It looks like this type of language features are not really in the top
of the vendors priorities. They seem certainly behind the OVM/VMM/???
and the global warming agenda.

Regards
s1s0
 
On Wed, 24 Feb 2010 15:15:15 -0800 (PST), siso wrote:

It looks like this type of language features are not really in the top
of the vendors priorities. They seem certainly behind the OVM/VMM/???
and the global warming agenda.

Regards
s1s0
It looks as though you and I are singing from the
same hymn sheet.

I sent you a private mail with some additional stuff.
Let me know here if you don't get it.
--
Jonathan Bromley
 

Welcome to EDABoard.com

Sponsor

Back
Top