• Trek technology will help to achieve a higher level of verification on SoC designs and provide a 2-3X reduction of effort.   Olivier Haller
    Verification Methodology Manager
    ST Microelectronics
  • We have seen 2x improvements in verification productivity using Trek   Jonah Alben
    Senior Vice President
    NVIDIA Corporation
  • The engineering team continues to 'Brekerize' the latest design revisions.   Terry Hulett
    Vice President, Engineering
    NetEffect
  • Their [Breker] SoC verification strategy proposal is solid and we are happy of the improvements it brings to our flow.  Design Verification Engineer
    Verification Guild/ “Anybody use these tools?”
  • Trek is reducing development time, improving coverage and easing communication between the various verification stakeholders   Olivier Haller
    Verification Methodology Manager
    ST Microelectronics
  • I was impressed with how easy it [Trek] was to integrate it into our existing environment. The graph based approach to generating testcases complements our exiting VMM constrained random test-benches very well.   Design Verification Engineer
    Verification Guild/ “Anybody use these tools?”
  • [We] are now using Trek in key areas of future GPU projects   Jonah Alben
    Senior Vice President
    NVIDIA Corporation
  • They [Breker] leverage an already existing testsuite to create more stressful SoC tests   Design Verification Engineer
    Verification Guild/ “Anybody use these tools?”
  • Trek is so verstile, that I was able to plug in a Trek graph that modeled the DUT in place of the DUT (whose RTL for some features wasn't ready) allowing me to develop trek graphs that would test features that weren't even implemented yet.   Design Verification Engineer Verification Guild/ “Anybody use these tools?”
  • In both the SystemC and RTL verification efforts, Breker's Trek product was able to help us find deep state functional bugs quickly and efficiently   Terry Hulett
    Vice President, Engineering
    NetEffect
    • Trek has a natural way of implementing a test environment with knowledge-driven approach of directed tests and the flexibility of incorporating randomness into the scenario generation and checking   Design Verification Engineer
    Verification Guild/ “Anybody use these tools?”
  • Constraint solving is really nice when it works. It's a declarative approach that lets you worry about the what, not the how. Trek uses an more imperative approach: you define a graph structure to be traversed. For trivial scenarios this is less elegant than a set of constraints; but as things become more complex you don't hit the performance cliff of constraint solving.   David Whipp, NVIDIA Corp.
    Verification Guild/ “Anybody use these tools?”
  • With Breker, we can provide a higher level of verification efficiency with improved coverage closure in pre-silicon and post-silicon verification activities for our customers.   François Cerisier
    IC Verification Expert
    EASii IC
  • Viewing the coverage capability of the graph was very effective in visualizing what had and had not been verified (helping answer the question ‘Are we done yet?’).   Design Verification Engineer
    Verification Guild/ “Anybody use these tools?”
  • Trek is more effective on complex designs. It really helps get to deep corner cases that aren't easily hit.   Design Verification Engineer
    Verification Guild/ “Anybody use these tools?”
  • My first impression was to use Trek simply as a testcase creation engine but slowly I'm getting convinced it is useful as "checker" as well - especially the end-to-end checks.   Design Verification Engineer
    Verification Guild/ “Strategy for System-on-Chip Verification”
  • Breker System's Trek tool has been refreshing. A new look at how to do functional verification. As a verification engineer, we all look at outcomes to figure out our testplan. Breker takes that to a new level where we can create graphs based on outcomes and even more power comes when one can apply a static analysis to see if all outcomes can really be reached by what was created.   Verification Engineer
    DeepChip
  • The one that sticks out for me was Breker Trek. I've been keeping an eye on their development of the tool for a while, and saw a demo. I like that it translates from our feature-based verification planning to what looks like straightforward coding of graphs to randomly verify.   Design Verification Engineer
    DeepChip/DAC 10

TECHNOLOGY

TrekSoC is built on top of the Trek graph-based constrain solver. Analogous to the SystemVerilog Constraint Satisfaction Problem (CSP)constraintsolver, the Trek graph-based constraint solver uses graph paths instead of variables as the foundation of constraint solving.

A CSP constraint solver accepts a set of variables (e.g. a, b and c), the legal values for each variable (e.g. each of a, b and c must be between 1 and 10), and a set of constraints that must be satisfied between those variables (e.g. a + b = c ). The constraint solver then finds a random solution (e.g. a=2, b=5, c=7) that satisfies those constraints.

This variable based approach is useful for randomizing individual transactions, but it is difficult to formulate the randomization of an entire scenario using a CSP constraint solver. CSP constraint solving is NP complete and can consume a lot of compute power to solve complex constraints.

A graph-based constraint solver accepts as input a graph of decision points where each decision may be randomized to result in alarge number of possible paths. The solver also accepts a set of constraints (e.g. traversing path segment a implies that path segment b may not be visited) that must be satisfied. The solver then finds a path through the graph that satisfies the set of constraints

By associating actions with each path elementin the graph, it is possible to intuitively formulate randomization of entire scenarios using a graph-based constrain solver. Graph-based constraint solving is O(log N) making is possible to rapidly solve complex scenario constraints.

TrekSoC Services

TrekSoC provides a framework of scenario models that are used to generate C test cases. Each test takes the form of a randomized micro-kernel running applications that drive individual hardware devices to test possible system interactions.

Scenario models may request system services that are provided by TrekSoC. This section describes some of the key services available to scenario models.

Memory Management

This service allows memory buffers to be allocated and freed on demand. Allocated addresses are randomized. Address randomization is biased towards creating cache line collisions to test cache coherency. Allocation is biased towards partial reuse of recently freed buffers to test data ordering. Virtual page tables are handled within this service.

This service also supports memory connectivity testing.

Register Access

This service allows scenario models to request randomization, writing and checking of register values.

This service also supports register connectivity testing.

Scheduler

Tasks may be flexibly scheduled sequentially within a thread or across threads to create producer/consumer scenarios. Threads may be on the same processor or distributed across multiple processors. .

Interrupts and Polls

A scenario model may ask to wait for an interrupt or until a status bit is set. Interrupt handlers and non-blocking poll loops are automatically generated.

System Management

This service will randomly switch clocking and power modes. Scenario models may ask for a specific device to be powered up for the duration of an operation, possibly allowing for intermittent power downs during the operation to test state retention.

Testbench Actions

This service allows scenario models to request arbitrary testbench activity to drive and check I/O interfaces or other testbench events.

GPIO

This service allows scenario models to request specific system GPIO routings.

Debug Facilities

This service allows scenario models to log various levels of diagnostic messages. Diagnostics on thread progress and memory state are automatically generated.

Data Checking

This service allows scenario models to request checking of memory data buffers against an array of expected data. Data checking may be implemented by offloadingmemory contents using backdoor memory access or by comparing checksum signatures, which consumes embedded CPU cycles.

Timing Checks

This service allows scenario models to request checking that the elapsed time between two events falls within a specified range. Timing checks may be implemented using either elapsed simulation time or using an onboard timer if available

Get Started Now