1. May 1, 2013
On-the-fly design exploration
framework for simulation
May 1, 2013
Lior Altman, HUJI
Avi Green, Intel
Itai Yarom, Synopsys

2. May 1, 2013
It’s worth to find bugs early
2

3. May 1, 2013
Re-spins

4. May 1, 2013
The meaning of re-spin
4

5. May 1, 2013
Verification is Becoming the main Task
• How can we improve the verification flow?
• Can we make it easier to fix bugs?

6. May 1, 2013
The Bug Fix Flow
• Detect – simulation ends with unexpected result
• Debug – what caused the wrong behavior?
• Fix & Verify – provide a fix and verify it.
– Can take several simulation iterations
– The time consuming element is the time it takes to verify the fix
• This influence directly from how many times we rerun the simulation

7. May 1, 2013
Our Solution
• We focus on the “fix & verify” steps
• We want to:
 provide a way to instantly check the fix effect
Validate the specific fix without the need to recompile and
resimulate all the design.
 compare two alternative fixes
 Minimize the number of comp+elab+sim
 Time = #iteration X (compile, elaboration and simulation time)

8. May 1, 2013
assign o = a & b;
always @(x,y,z) begin
x = y;
z = x;
end
assign o = a & b | c;
always @(x,y,z) begin
z = x;
x = y;
end
+ ‘| c’
Changing expressions
order
How does it works

9. May 1, 2013
How does it works

10. May 1, 2013
The Analyze Engine
• The analyze engine builds the
expression tree(s) that we want
to present on the waveform.
• Step 1: Find the statements that
were changed.
• Step 2: Analyze the code and determine all the
statements that will be affected.
• Step 3: Analyze the context of statements
– Assign , Flip-Flop, Mux etc…

11. May 1, 2013
Updating the waveform
We are using a simulator agnostic
approach that uses the simulator
expressions:
For each statement (from
analyzer)
• generate expression (virtual
signals).
• Show them on the Waveform.
No needing to resimulate!!

12. May 1, 2013
Updating the waveform
We are using a simulator agnostic
approach that uses the simulator
expressions:
For each statement (from
analyzer)
• generate expression (virtual
signals).
• Show them on the Waveform.
No needing to resimulate!!

13. May 1, 2013
Performance
• The expression will be calculated on the fly
– The expression can use signals and/or other expressions values.
– This is very fast, since all the values are available.
– It enable us to validate the specific fix without the need to recompile
and resimulate all the design.
• The performance is related to:
– Expressions complexity
– Amount of expressions
– The viewable time window
• This flow can support multiple waveform for different fixes.
– Enable us to compare them and choose which fix to take

14. May 1, 2013
Prove of Concept
• The goal of the project was to show that it can
be done and enable designers to use it
– On-the-fly calculation is available today for
assertions and constraints (in some simulators)
• We enable to run our framework on ‘simple’
logic changes
– No support for complex SystemVerilog constructs
• We consider to release the framework as an
open source for the verification community

15. May 1, 2013
Future Work
• Provide support for more complex logic
• Improve the ability to compare between fixes
• Improve the UI/UX

16. May 1, 2013
Summary
• Chip re-spins occur
more often.
• The effort of a bug fix is
the time it takes to
verify it
• We introduced a
framework to reduce
this time significantly

17. May 1, 2013
On-the-fly design exploration
framework for simulation
May 1, 2013
Q & A
Avi Green Itai Yarom

18. May 1, 2013
Backup

19. May 1, 2013

20. May 1, 2013

21. May 1, 2013

22. May 1, 2013
Flaws that Caused a Re-spin

23. May 1, 2013
Verification Gap

24. May 1, 2013
Verification effort trends