Use arrays of modports, not generated modports

In reading the SV12 LRM, beware the second example in 25.5.4, which has regrettably been passed down from earlier revisions. The concept of generated modports doesn’t make much sense to me, at least as it is now defined. (I tried to find a better semantics HERE.)

When you hear the siren song of generated modports, head for arrays of modports instead.

By an “array of modports”, I mean imposing a modport on an array of instances when it’s passed, such as “bot bot(inst_array.mp);”, where mp is a modport for that kind of instance. That is, the modport is imposed on each instance in the array as the array is passed.

Two related entries

In the long-run, I predict the SV community will move to interface classes and channels. But as Keynes said, “The long run is a misleading guide to current affairs. In the long run we are all dead.” So figuring out the best ways to use modports is still important.

Advertisements

3 Comments

  1. Generated modports are bad because they put an extra level of scope hierarchy around each modport. Agreed. But I don’t believe there is any such thing in SV as an “array of modports”. The effect can be obtained only by creating an instance array of interface instances, using sub-interfaces to get modport-like behavior as you have described elsewhere. Once again that introduces an additional level of instance hierarchy and it’s not obvious to me that the result would be tractable for (current) synthesis tools.

    Are you saying that some tools support a “modport array” construct that’s not in the SV-2012 LRM?

    It’s been very interesting for me to watch your development of these ideas. They resonate strongly with my own sense of how modports and interfaces should have worked, but you have articulated the problem far more clearly than I ever was able to do. Thanks for that, and thanks for your championing of the notion of synthesisable interface classes

    Like

    • Hi Jonathan, by an “array of modports”, I mean imposing a modport on an array of instances when it’s passed, such as “bot bot(inst_array.mp);”, where mp is a modport for that kind of instance. That is, the modport is imposed on each instance in the array as the array is passed. This is in the LRM, at least the BNF, and as far as I know all tools support it by now. In any case, I can testify that real SV designs are using that idiom these days.

      I often refer people to your 2007 presentation

      Like

      • Brad, thanks for the publicity but, as so often with these things, there’s plenty in that paper that I would have said or done differently today!

        I mostly do OO verification stuff these days and am not so very familiar with the module-hierarchy parts of the LRM, so you must be gentle on my ignorance. But I struggled to find justification in the LRM for the arrangement you’re describing, although I think this is partly because the description of instance arrays generally is not as clear as it might be. However, I agree that it can be made to work (although I did find one major simulator in which it doesn’t).

        It’s certainly an attractive way of dealing with such things as multiple slave instances on a bus master. Thanks for the tip.

        Like

Tell me (anonymous OK)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s