Today is the report of my first day in DAC. I signed up to a full day technical workshop Choosing Advanced Verification Methodology. After the workshop ended at 3:30p, I managed to checked out a few companies in the exhibition floor Vennsa Technologyies, Agnisys Inc and Veritools
Advanced Verification Methodology
The workspace is smaller than I expected. There is only about 20 attendants. It started off with a keynote from Brian Bailey, a verification consultant, on the latest trends in verification. Assertion and ESL seems to be the theme of the day.
We finally see formal verification comes out from academic research and put into use by the industry and developing a good use model. There are 7-8 formal tools venders in the market right now, but looking at historical data in the EDA industry, no matter what previous technology, the market is only big enough for 2 to survive.
ESL is the latest buzz word. The word has many different meaning but basically it means where software and hardware comes together. To verification, ESL means we are building reusable testbench with different abstraction layers. Starting from the top with TLM model to verify the algorithm, then push down to verify the architecture, and then the RTL implementation at the very bottom. TLM 2.0 is the new industry standard and pretty much sweep aside all proprieties prototypes from different vendors. TLM 2.0 still lacks synthesis and no hardware/software interface.
Currently, many people model ESL in SystemC, but both SystemC and System Verilog need a few more revision to fully support ESL. The new ANSI concurrent C/C++ coming out this year many turn SystemC into a obsoleted branch of C/C++. High-level synthesis, C to RTL compiler, is almost an ESL enabler. It separate the architecture from behavioral description. The shift from RTL coding to high-level synthesis would be as disruptive as the shift from schematic capture to RTL coding.
Constraint random generation is a challenge in ESL verification. Current tool does not understand sequential depth and can’t constraint across sequence. Functional coverage is broken. It is merely isolated observation not necessary reflect the verification progress. We need a different metric to provide a direct measure on verification closure.
In ESL development, management will be a new challenge. Now we have to develop the hardware and software in the same development cycle, there will be conflicting schedule between the hardware team and the software team. Communication among different team and clear interface management at the partition between software and hardware implementation is the key.
In the next few years, the speak predicts there will be more research and probably technology break though in these areas: specification capture in verification, sequential equivalent checking, intelligent testbench, assertion synthesis and behavioral indexing.
After the keynote session, it is customer panel. The panel guests are Intel, ARM and nVidia. The ARM and nVidia are assertion expert, the Intel guy is more on ESL. It is Q&A session, but nothing special, the guest only talks about very generic things. They tell us what they do but don’t they us how they do it.
Jasper has the next presentation together with nVidia and ARM gives customer testimony. They talked about their formal verification tool and introduce basic concept like full proof, counter example, partial proof. There are quite a few neat examples of formal verification, like generate an input sequence for a given output trace, answer urgent customer question on whether something is possible in the design, verify dead lock/live lock, checking ‘X’ propagation. Both ARM and nVidia has dedicated assertion team and they said that is important to the success in using assertion in verification.
Synposys presents new updates to VCS simulation. They close the coverage to constraint loop with the Echo testbench technology. It is similar to what Cadence has and it is limited to the coverages that has a direct relationship to the constraint VCS finally has multi-core support. I think Cadence already it in IES 8.2. We should look into using both technologies for Digi. We should work with the CAD group to set up special LSF machines reserved for multi-core jobs.
TSMC talk about its Open Initiation Platform (OIP) for ESL verification. The virtual platform enable hardware/software co-simulation. The testbench is build from the top-down approach. Start with ESL TB to verify the algorithm, then ESL SoC TB to verify the ESL mode, then add cycle accurate adapter to the ESl model and finally the RTL testbench.
Mentors talks about ESL testbench and present a success story of TLM to RTL synthesis verification. They claim the high level synthesis flow save them lots of time and use the same testbench with different abstraction from top to bottom.
There is nothing new in Cadence’s presentation. They just show how vPlan fit in ESL flow.
It is a small company in Toronto based on the research of a prof. from U of Toronto. Their OnPoint debug tool is pretty neat. It is an add-on to the simulation help the designer pin point the bug. Once you have an assertion failure, you can fire the OnPoint GUI. The tool will back trace the logic cone, narrow down and suggest where the bug is about. You can also start the back trace from a given value on the output pin at a given time. I played their demo for almost half an hour and it is a very handy tool if it works as advertised. The idea behind the tools sounds and I think we should evaluation the tool.
This company has two product: IVerifySpec, a web GUI replacement for vManager and iDesignSpec, a half bake solution similar to RDA.
IVerifySpec use SQL database to store the vPlan, but it does not support UCD directly. It has to translate the UCD to an XML offline and import to the database. There is a few nice feature in the GUI, like heat map, traceability matrix, some charts and graphs looks like Google Analysis. However their tool is very immature overall, it does not support multi-level hierarchy in requirement specification, no revision control and data entry via the web interface is very tedious and user unfriendly. I should simply ask Cadence copy those nice report feature into vManager.
iDesignSpec sounds good on paper but the implementation is awkward. You enter the register specification in Word using some funny plug-in. Then the plug-in will generate PDF, HTML, XML, VHDL, OVE, C++ files. Somehow it is the exact opposite of our RDA flow. We enter our register description in XML and generate one thing at a time using scripts. The format of their word plug-in is very ugly. The code and PDF file generated by the plug-in is very primitive. I would say even our old ECBI generator is better than this tool. The only thing useful I learn from this presentation is there are industry standard for register description, SystemRDL and IP-XACT. Maybe our RDA tool should support industry standard as well.
Their flag ship product is Veritools Designer. It’s basically a Debussy Verdi clone. It can view schematic and waveform, source code debugging. They claim their tool is very fast and only cost 1/4. I am always skeptic about those claims and I don’t like they use a their own waveform database format. It means simulator has to dump another waveform through their PLI. The GUI is fast but the design in the demo is not very big. The GUI is quite primitive compare to Simvision and they can’t beat the price of Simvision which comes free with IES. I do agree Simvision is a bit slow but I think investing in faster computer with bigger RAM can solve this problem. They have an add-on tool called Veritool Verifyer. This tool is kinda dumb. If there is an assertion failure, it read in the waveform and let you to test changes to the assertion code without invoking the simulation. I don’t think it is very useful. When an assertion fail, how often it is due to RTL bug and how often it’s just a faulty assertion?