I attended portions of an EE Times “virtual” system-on-chip (SoC) conference last week, and came away with some observations that I’d like to share. There is some irony here. After years of writing about Cadence and other EDA vendors for EE Times, I am now reporting about an EE Times event for the Cadence Industry Insights blog.
This was the first on-line conference and exhibition I have attended in recent times. There are some obvious advantages to this format. You don’t have to travel anywhere, you can listen right from your desktop and “attend” only those presentations that interest you, you can fire off questions to panelists and presenters, and you can participate in live chats. One interesting feature at the EE Times conference was the ability to see who else is attending, and send them e-mails.
There are, however, some differences compared to live conferences. Listening to an on-line conversation and viewing slides is not the same as being in the room. Typing questions is less direct than striding up to a microphone. You don’t physically run into acquaintances in a hallway and have unexpected but helpful conversations. Still, as Grant Martin noted in his blog about the event, there are parts of the format that work fairly well – such as keynotes, webinars, and panel discussions.
SoC Verification Panel
There was some good content at the EE Times event. In particular, there was an SoC verification panel that resulted in a good discussion, particularly about ESL. I would have expected more discussion about IP integration and verification reuse in an SoC conference, but what was said about those topics was interesting. For example:
Brian Bailey, consultant: “Design time has been assisted by bringing in large quantities of IP, but we haven’t really gotten to the point where we can reuse without re-verification. IP may be saving design time, but it’s doing very little to help on the verification side.”
Nick Heaton, senior architect at Cadence: Verification reuse is more than just verification IP. “What we really need to make an impact in the ESL space is the availability of verification at the TLM level, and easy migration from TLM down to RTL. Synthesis is one aspect, but we also need to be able to reuse testbenches, test scenarios, coverage, and reference models between the two abstraction levels.”
Janick Bergeron, Synopsys fellow: The big challenge with virtual prototypes is to get them to talk to other abstraction levels. Once that’s done, the prototype becomes an important element of the verification flow. “You can use it as a reference model and your testbench. You can develop a huge number of tests against your prototype.”
Tom Sandoval, CEO, Calypto: Japanese companies are broadly deploying ESL design and verification methodologies today, allowing “reuse at a completely different level of abstraction.”
Another panel on “Economics of Next Generation SoCs” made some interesting points, most notably the contention that design teams are significantly under-estimating costs to develop SoCs. This may be a good topic for future blogs.
Chats and Exhibits
I listened in on “scheduled chats” on mixed-signal design challenges and EDA in 2020. I have to say I’ve never been drawn to Internet chats. You’re limited by the typing speed and skill of participants, and with the lag between question and answer, you get into overlapping conversations. There was, however, some interesting engineer-to-engineer interaction in the mixed-signal chat.
The “exhibits” basically consisted of graphics with menus that provided access to selected sets of datasheets, tech papers, webinars, and other resources. One option was a “booth chat” with a representative. Cadence was one of the exhibitors.
On-line conferences are relatively easy to produce and attend, and they have a lot of advantages. They will not completely replace live events like the Design Automation Conference. There is still an advantage to being there in person, talking and meeting with people you didn’t expect to meet, and seeing things you didn’t expect to see. But I think we’ll see a lot more on-line conferences in the future, along with some innovative and interesting additions to the format.
OK, I understand what you are after now.
It is true that IUS does not currently support export tasks in a modport, as in your code above. However, you can achieve pretty much the same modelling effect using classes with virtual tasks within an SV interface. The amount of code is pretty small and shouldn't be too intimidating for non-OO people.
I can send you a small example of this approach if you'd like if you send me your email address.
Sorry Stuart, I should have been more specific.
I'm trying to export tasks through a modport in an interface.
(export task write(bit [7:0] addr, bit [31:0] data),
export task read (bit [7:0] addr, output bit [31:0] data));
(import task write(bit [7:0] addr, bit [31:0] data),
import task read (bit [7:0] addr, output bit [31:0] data));
endinterface // tlm
WRT SV Interfaces vs Classes, here's where I'm coming from:
We've got an existing rtl design.
We've got a small design team of hardware engineers who mainly know rtl. Not much OO experience.
We don't use SystemC, 'e' or OVM. As I said, small (very busy) design team with a different skill set.
I need a method to replace individual modules within our RTL design with a TLM model.
Two main reasons for this:
1. Speedup software debug / development. (A lot of low level software is debugged in our RTL simulation).
2. Speedup testbench development.
SV interfaces seem like an easy way to add TLM components to an existing rtl design.
Should be relatively easy to swap TLM and RTL components within the design.
I'll need 4 flavours of SV interfaces:
RTL <-> RTL
TLM <-> RTL
RTL <-> TLM
TLM <-> TLM
Generic interface ports also help with this technique.
IUS does support exporting tasks through SV interfaces, so it is unclear
to me what problem in IUS you are referring to.
Regarding the approach of using SV interfaces (and associated constructs such
as modports) to model TLM interfaces, this idea has been tried in the past
by various verification methodologies, but the industry has mostly converged
on using SV classes to model TLM communication.
Some of the drawbacks in using SV interfaces & modports for modeling TLM include:
- modports and interfaces cannot properly model inheritance relationships, and thus are cumbersome
for modeling TLM interfaces where it is desireable to specify that only a subset of the interface
is present in certain situations.
- interfaces and modports must be statically elaborated. In contrast, TLM components
using SV classes can be dynamically elaborated, making it easy to alter testbench topology
after the DUT has been elaborated.
Some of the benefits in using TLM interfaces based on SV classes as in OVM include:
- Ability to have consistent, interoperable TLM interfaces in multiple languages, including
SV, 'e', and SystemC.
- Ability to easily alter testbench topology -- e.g. easily replace a TLM dut with an RTL
dut. For examples of this, see the examples in the OVM kit available from www.ovmworld.org
OVM provides TLM interfaces based on the OSCI TLM 1.0 standard. These interfaces are based
on the simple and modular "message passing" principle. However, if these interfaces
do not suit your needs, you can also construct your own more elaborate TLM interfaces in OVM
by extending from its port and export classes (as is done for the sequencer interface classes
in OVM 2.0.2).
“What we really need to make an impact in the ESL space is the availability of verification at the TLM level, and easy migration from TLM down to RTL. Synthesis is one aspect, but we also need to be able to reuse testbenches, test scenarios, coverage, and reference models between the two abstraction levels.”
I totally agree.
Using SystemVerilog interfaces to go from TLM to RTL is a great solution.
Develop the TLM models and testbenches by exporting and importing tasks through a SystemVerilog interface.
Using generic interface connections, it's possible to use the same environment to easily go from TLM to RTL.
The only problem?
The IUS simulator doesn't support exporting tasks through SystemVerilog interfaces.
Why doesn't Cadence support one of the most useful TLM features in SystemVerilog?