( DAC'17 Item 1b ) ------------------------------------------------ [11/09/17]
Subject: Breker TrekSoC takes #2 in #1 "Best of 2017" with Portable Stimulus
"SO NOW I'M SUDDENLY POPULAR???": For the past 200 years, that green leafy
vegetable called "kale" was a dish that black Southern slaves used to make
because it was easy to grow, had minerals & vitamins, and it was filling.
Now, the rich suburban white professionals are scratching and clawing to put
anything "kale" related into everything from (horribly tasting) smoothies to
(disgusting) salads to (nasty ass) cooked greens. "It's good for you!"
Breker is the kale of EDA. In 2003, it was a strange little C++ start-up
that did "graph based functional verification" by automatically generating
test vectors to run in SystemVerilog, Verilog, Vera, SystemC, or Specman
simulators. Their DAC 2007 claim to fame (ESNUG 478 #4) was they could do
a full constrained-random verification project with just 17,000 lines of
Breker Trek code generated by 1 engineer in 2 weeks vs. the same task as
350,000 lines of System Verilog that took 12 engineers 6 months to hand
write. And very cleverly, their CEO, Adnan Hamid, pitched his Trek tool
to be an add-on in the verification game instead of a replacement approach.
"In the end, despite having 1 person against 12, Trek found
50 percent of the bugs. The other 12 found the other half."
- Adnan Hamid, Breker CEO (EET 05/14/2007)
But that was 10 years ago. And it was C-based. And it was for functional
testing of embedded processors. So, like kale, at that time and for years
to follow nobody important gave Breker a second glance.
But now, like kale, since Portable Stimulus has just now moved out of the
claundestine Working Group committee hellhole phase and into the "hey, this
looks like it might actually be real and work now" phase -- Breker is
just now catching the eye of the EDA verification tool buying public. Why?
"Because it's good for you!"
TECHNICAL NOTES: The biggest fear Breker customers had was investing their
whole verification strategy on a small start-up that could go belly up. But
because the Breker C++ approach was made part of the PSWG PSS, that's no
longer a concern.
And there were a few complaints about initial Breker ramp-up, but no where
near the flood of complaints that CDNS Perspec users have -- because Breker
is a graph-based system. Graphics are always easier than scripts. Just
ask Apple. They have an entire multi-billion dollar company built on the
idea that users using graphics are happier than users writing code.
"Always code as if the guy who ends up maintaining your code will
be a violent psychopath who knows where you live."
- John F. Woods on comp.lang.c++ (09/24/1991)
"Any code of your own that you haven't looked at for six or more
months might as well have been written by someone else."
- Eagleson's Law
"I'm a visual thinker, not a language-based thinker. My brain
is like Google Images."
- Temple Grandin, American educator (1947 - present)
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
QUESTION ASKED:
Q: "What were the 3 or 4 most INTERESTING specific EDA tools
you've seen this year? WHY did they interest you?"
---- ---- ---- ---- ---- ---- ----
It was great to see Breker at DAC again, and that they were active in
the Portable Stimulus events as well. It looks like their day has come.
From talking to them at their booth it was clear they would have a tool
capable of supporting PSS once the standard is released.
---- ---- ---- ---- ---- ---- ----
The Breker tools.
SoC level verification is still mostly done by complex, directed,
hand-written C-based tests. They are time-consuming to write and
difficult to re-use on subsequent chips (in spite of trying to
abstract tests from SoC specifics).
We like its:
- vertical reuse from block to full SoC.
- horizonal platform reuse (simulation, emulation, prototyping
and silicon)
- reuse of testbench families from parent SoC to derivative
SoCs
- easy input with a graph-based test definitions, leaving
randomisation where possible.
- bare metal tests and cache coherency tests.
---- ---- ---- ---- ---- ---- ----
I like that the PSWG made Breker's graph-based approach a public
standard. That means other vendors can do it and we're not in
trouble if we buy Trek and Breker goes out of business.
---- ---- ---- ---- ---- ---- ----
Since they founded the ideas, Breker is the best positioned company to
sell full featured tools for the upcoming Portable Stimulus Standard;
especially since the C++ portion of the current draft standard was
developed primarily by them.
We already use Breker for IP, chip, and system level testing. I look
forward to seeing how the adoption of portable stimulus within their
Trek product family will make this more efficient.
---- ---- ---- ---- ---- ---- ----
I used Breker TrekSoC to help me verify a large complex SoC.
It automatically creates C-based testcases with random stimulus, then
analyzes system level coverage, then helps with testcase debug.
1. Test Generation
With system level testing -- because any peripheral can become active
at any point -- we must randomize the sequence of events.
It's quite cumbersome to code these tests manually, as there are 100s
of combinations that include this randomness. First you would need
to figure out all the possible permutations on your own, which is
very hard. Then you would have to code them all.
TrekSoC automatically generates these testcases. To do so, you need a
wrapper for your API to make them 'TrekSoC-compatible'. You specify
the API inputs by wrapping your C code with TrekSoC's built-in Begin
and End statements. All of the wrapped code is then put inside a
graph file as an input to the tool.
You can also add a checking mechanism in your wrapped C code.
2. Coverage analysis
Coverage is the most important part of our verification.
TrekSoC tracks coverage information on which random sequences -- the
order of execution of APIs -- have and have not been covered.
Breker generates the coverage when they generate the tests. If you
think certain tests aren't contributing to coverage, you can skip
them. (We run all the tests it generates.)
By doing this, we don't need to analyze coverage after testcase run.
3. Debug
There are two levels of debug:
- First, identifying where the testcase fails / is hanged.
System level testcases are very hard to debug manually if
they involve traffic from multiple peripherals and your
testcase hangs.
TrekSoC has a test map GUI that makes it very easy to see where
it hanged and the reason for the hang, i.e. what block or API
caused it to fail. For example, if many peripherals are
involved, Breker shows me where it failed/hanged. Then I can
go to that peripheral signal in the simulator.
The graphical test map is color-coded during execution: which
have been executed, which are being executed, and which have
not yet been executed.
- Second, understanding why the testcase failed/hanged.
We go to the simulation vendor's debug environment to do this
step. (Breker does not currently have this.)
Breker's debug cuts the turn-around time on our system level testing.
4. Bring up
For the initial bring up, you give a graph file input. You create a
new graph for a new block, which requires some coding. The coding
process took me about a month, including my learning curve as a
first-time Breker user. Next time it should be even faster.
Once you have created a graph for a specific block, you can reuse it;
i.e. after a single test case has been brought up, you can make simple
tweaks for any design changes.
A couple other Breker TrekSoC features -- that I have not tried out:
- The generated tests are intended to be reusable/portable from
simulation to emulation. However, I only used them for
simulation on my recent project.
- Breker's pre-built 'apps' (e.g. for coherency and ARM).
Overall, I estimate TrekSoC reduced my total verification time on the
SoC by 20% -- excluding the learning time -- even for my first time
using it.
---- ---- ---- ---- ---- ---- ----
It's great to see Breker participating in the industry wide effort to
find a portable stimulus standard, rather than provide a proprietary
solution -- which by definition would be non-portable.
An additional benefit of portable stimulus is the promise that the same
stimulus can be run on all simulators for IP and SoC development, as
well as emulation. And even in the lab, for post-silicon validation.
---- ---- ---- ---- ---- ---- ----
Breker Portable Stimulus
The whole idea of portable stimulus is a good one. The transportability
is obviously beneficial; it gets the system world on the same plane in
terms of verification environment, e.g. SystemVerilog, OVM, and UVM.
I've been doing this for decades, and we've all lived through dealing
with proprietary formats.
The more standards, the better.
---- ---- ---- ---- ---- ---- ----
Breker TrekSoC Portable Stimulus
The overall portable stimulus standard is to address some complexity of
stimulus generation in UVM environment.
Breker has had a proprietary graph-based stimulus generation tools for
years. The added support of the portable stimulus standard will
probably open up some opportunities for Breker for customers who may
worry about getting locked into proprietary tools.
---- ---- ---- ---- ---- ---- ----
Breker TrekSoC:
- Bringing verification methodology to a higher-level. Wrapping
the SystemVerilog based verification environment using C-models.
- The quality of verification is only as good as the C-models
developed for the system. Development is costly if chance of
reuse is low.
- Good for system-level verification, may not be sufficient for
fine-grain block-level verification.
- The Breker user interface seems useful in visualizing coverage
and scenarios.
---- ---- ---- ---- ---- ---- ----
Breker TrekSoC
Breker also has TrekApp for cache coherency and low power verification
of ARM based systems.
Breker claims to already be compatible with the early draft of
Accellera's PSS standard.
---- ---- ---- ---- ---- ---- ----
I found Breker's DAC presentation interesting.
I am a mixed-signal verification engineer, and we are not there yet, so
I haven't used their product.
---- ---- ---- ---- ---- ---- ----
Breker TrekSoC
We've had good results using the Trek tool as a base for what we ended
up calling "graph-based verification methodology". It lets us specify
verification scenarios that are both deep state space exploration (by
generating directed sequences when required) as well as randomization
of these sequences.
We especially liked TrekSoC's C++ friendly input language as well as
its easy integration into our existing Cadence verification framework.
They've given us good tech support, but then again we're a Tier 1
account.
We're looking forward to the first DSL TrekSoC prototype. We want to
see how it matches the upcoming Portable Stimulus standard.
---- ---- ---- ---- ---- ---- ----
Tom Anderson has come to us many times about Breker.
It looks like this year we're finally taking it seriously.
I feel bad that he's not there to get credit for the sale.
---- ---- ---- ---- ---- ---- ----
We're trying to figure out if TrekUVM is doing the same process that
Jasper does to find unreachable states.
---- ---- ---- ---- ---- ---- ----
Breker
---- ---- ---- ---- ---- ---- ----
Learning the Breker way is a chore, but it seems to pay off.
---- ---- ---- ---- ---- ---- ----
Do you have any user comments on Breker TrekSoC-Si being used as a
post-silicon analysis tool? Does it have to be used pre-silicon
first to be effective?
---- ---- ---- ---- ---- ---- ----
Our SW guys like C, so they're cheering for Breker.
Our HW guys like e, so they're cheering for Perspec.
---- ---- ---- ---- ---- ---- ----
Breker and Perspec
(Actually, Breker or Perspec.)
---- ---- ---- ---- ---- ---- ----
Looking at PSS. Perspec, Breker, possibly InFact. We're
a Cadence house, so Perspec gets 1st consideration.
---- ---- ---- ---- ---- ---- ----
Related Articles
Cadence Perspec wins #1 in #1 "Best of 2017" with Portable Stimulus
Breker TrekSoC takes #2 in #1 "Best of 2017" with Portable Stimulus
Mentor InFact was pretty much an early No Show in the PSS tool wars
Spies hint that Synopsys is making a PSS tool, but it wasn't at DAC
Join
Index
Next->Item
|
|
