Jonathan Bromley’s SystemVerilog wish list

On LinkedIn I posted a link in the “SystemVerilog for Design” group to Karen Pieper’s comment that

I will provide a draft PAR to seed the discussion. If there is anything in particular that you would like in the next PAR, please let me know.

Verification engineer Jonathan Bromley responded

thanks for kick-starting this discussion (and, of course, thanks to all the SV committees for their work in getting SV-2009 on to the statute books!).

I have been accumulating a wish-list for some time. Before I log Mantis items for these things, it would be great to see whether others agree with me. So, here goes. Some of these things can dealt with in a fairly obvious way, others don’t have an obvious solution and need lots of analysis. All are in a very shorthand form – I’ll elaborate if anyone is interested…

********* SV-BC (basic language):

* generatable port list (optional/iterated ports) on modules

* resolution of modport connection semantics (Mantis 2114)

* modport as first-class type-like declaration (Mantis 1861)

* a systf to return the complete list of plusargs as a
queue or DA of strings, ordered by order of appearance
on command line/response file

* extensible modules, interfaces and modports
(bind any module_or_generate_item, not only instances?)

* lift restriction on built-in integral types as
members of packed aggregate

* extensible packages (although SV-2009 package export almost
makes up for the lack)

* scalar type as possible RHS of “inside” in place of open_range_list:
if (v inside some_type) …

*********** SV-EC (testbench extensions)

* foreach() over set of values (same syntax as “inside”):
foreach (i inside {[3:7], 9, 1}) begin…end

* foreach() over value-set of scalars (particularly enums):
foreach (T'(e)) begin…end
I’m OK if this only works for enums, but other types would be
good too. May prefer to protect against “foreach (int'(i))” etc.
(i.e. limit it to >{}}
[and possibly bitstream casting?], could make it OK to pack
objects with local/protected members if those are non-packable

* richer set of string methods – search etc.

* regexp string matching (Synopsys already have this)

* subprogram overloading, at least for class methods

* Built-in allocators:
base_class_var = derived_class::new();
base_class_var = type(derived_class_var)::new();
i.e. new() is pretty much like a static method of a class.
Virtual allocator method is then simply “return;”

* “ref static” to permit a ref argument to be restricted
so that it must reference a static variable; such refs
can then safely be accessed from within a fork…join*

* more speculatively… “with” (like array.find with,
randomize() with, etc) as syntactic sugar for lambdas:
functions as first-class objects!

******** SV-CC (C language inteface)

* Standardized vpi_gets() for console interaction with VPI/DPI



Tell me (anonymous OK)

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

You are commenting using your 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