The exhibition floor is over in day 4 and 5. In day 4, I attended user track presentation on verification and a technical session on What input language for HLS. In day 5, I attended a workshop on Software Engineering using Agile Software Development technics

User track presentation on verification

In the presentation Migrating HW/SW co-verification platforms from simulator to emulators, it outlines a few challenges in the flow: 1. compile ASIC/IP vendor simulation model to the emulator. 2. generate the primary clock in emulation. 3. Use transaction based VIP or use emulator specific transactor IP.

In the presentation A Methodology for automatic generation of register bank RTL, related verification environment and firmware headers, it outlines a flow similar to our RDA flow. The difference between RDA and their flow is they support IP-XACT as the register definition flow and using tcl/Java to generate the files. The register XML files is translated into Java class, then registers are read from the Java class to generate the register RTL, vr_ad register files and firmware headers files. Their flow does not support auto-generation of backdoor path in vr_ad, neither does our RDA flow.

In the presentation Utilizing assertion synthesis to achieve an automated assertion-based verification methodology for a complex graphics chip designs, nVidia demonstrate the use of the Nextop tool to generate properties representing design functionality. The flow is pretty much the same as what’s outlined in Nextop’s booth. The presentation has introduced a few new concepts, first is the notation of assertion density, which measures the number of assertion properties required to define the functionality of the design. Then there is the difference between synthesized properties and synthesable properties. The first one refers to the properties auto-generated using Nextop’s flow, the later one refers to the assertion is able to run inside the emulation box. However the specification mining is only as good as the simulation traces feed into tool.

In the presentation A smart debugging strategy for billion-gate SOCs, Samsung present a solution to a common problem we have in verification. When a simulation fails, we need the waveform to debug. On one hand, takes time to rerun the simulation and dump all the waveform. On the other hand, it takes up disk space and slow the simulation down if we start dumping all the waveform in all simulation runs. An approach to solve this problem is save check points in the simulation, then rerun the simulation and dump the waveform from the closest check point to where the simulation fails. We attempted to implement a home grown solution using ncsim’s native save/reload function, but save/reload function has been very buggy and very inefficient in term of snapshot size. The presentation introduces a tool from System Centroid called SSi-1 to automate the flow. It worth to evaluate SSi-1 to see how well it solves the problem of dumping waveform in re-simulation. The only concern is System Centroid is a Korean company and most information in its website is written in Korean.

In the presentation Bug hunting methodology using semi-formal verification techniques, ST Microelectronics introduce a way to combine the formal verification with simulation. The idea is invoke the formal engine in pre-defined search point during the simulation to limit the scope of formal search space. The formal engine can be triggered when a certain RTL condition is met, on interval, on FSM or on coverage.

What Input Language is the best choice for High-Level Synthesis (HLS)?
This is the most heated debate session in DAC. The panel invited speakers from Cadence, Mentor, Synfora, Bluespec, Forte and AutoESL for this show down on their HLS methodology. In this a three way debate, the languages of choices are C/C++, System C and System Verilog. All the speakers are biased one way or another because they are representing their company which invested millions of dollar in a certain language, so they really advocate their choice of language is better than others.

The benefit of using System Verilog over C++ or System C is SV allow the designer specify hardware architecture. The weakness of System C or C++ follows sequential models as it lacks ways to specify concurrent models. Architecture decision cannot be made by the synthesis tool since it is the first order optimization. C++ or System C HLS tool has to use compile directives to specify the hardware architecture.

The benefit of C/C++ is the only language used by both HW/SW developers. Algorithm are modeled in C/C++, so it makes C/C++ the most native input to HLS tool. Modeler or SW developer does not need to learn a new language and there is no need to translation the code in C/C++ to another language. Using C/C++ can postpone defining the architecture by separate the layer of abstraction or even making decision on the HW/SW boundary.

System C is kinda half way between C/C++ and System Verilog. The advocate thinks it has the best of both world, but others thinks it got the worst of the both world. It provides limited language construct to define timing related information and concurrency statements. It can define more accurate hardware architecture than C/C++, but it also carries the burden of a 40 years old programming language that is not design to describe hardware implementation in the first place. However, System C is supported by Cadence, Mentor, Forte and NEC CyberWorkBench, the four biggest HLS tool vendors.

Agile Programming Techniques
I signed up a full day workshop on How to Write Better Software in day 5. The workspace is conducted by IBM internal software training consultants. IBM is huge on agile software development. Agile project focus on four elements, stable, time-boxed short iterations, stakeholder feedback, self-directed teams and sustainable pace. The workspace introduced two agile methodologies, eXtrememe programming (XP) and Scrum.

In XP, there are 12 programming practices, the instructor did not go over all of them in the workspace. The major practices they had mentioned are: 1. Lean-software development, 2. test-driven development (TDD), 3. automation, 4. continuous integration/build and 5. pair programming. Lean-software development apply value stream map to eliminate waste. TDD focus on the idea unit test and re-factoring.

In scrum, the project is divided into 2-4 week sprints. In the beginning of sprint, there is a sprint planning meeting. The product owner determine the priority of all the user stories in the product backlog. Then scrum team will pick the sprint backlog and commit to the sprint goal. Scrum master remove road blocks of the scrum team. A user story describes functional that will be useful to a stakeholder of the system. Within a sprint period, the team should get everything done, (coded, tested, documented) of the picked user stories. The scrum team will conduct short 15 minutes daily scrum meeting to report the progress from yesterday, the plan for tomorrow and road blocks need to resolve. At the end of the sprint period, there is a sprint review meeting and demo of the sprint goal. Unfinished user stories should put back to the product backlog and re-evaluate its priority.

Verification is a huge software project on its own as we already created more lines of code than the RTL design. I think applying Agile programming techniques will help us to improve the quality of work. The workshop is just an introduction to Agile, it outlines what Agile is and its potential benefits, but it leaves out details on the know-how. It would be nice to learn more on how to apply Agile in verification setting as our work is not exactly the same as software development projects in IBM. Moreover, knowing the principles of Agile is one thing, avoiding pit-falls during the execution is another thing. There are many real-life problems need to be sorted out to make an Agile project successful. The workshop did not talk about how to estimate schedule with Agile given that the planning is only done within each sprint, how to manage people within a Agile team, how to deal with free riders or how to deal with difference in skill levels or how to deal some tasks that no one want to work.

Given the workshop is a 3 days IBM internal training squeezed into 1 day, it is understandable that a lot of information is left out. However I am leaving the workspace unsatisfied, I expected to learn more about Agile from the workshop.