Open side-bar Menu
 The Breker Trekker

Posts Tagged ‘use cases’

Top 5 Latest Holiday Gifts for the Verification Engineer

Wednesday, December 30th, 2015

It’s becoming somewhat of a tradition here on The Breker Trekker blog to close each year with a list of gifts available from us to verification engineers. We started the series two years ago with an initial list focusing on our core benefits of automatic test case generation, system coverage, and reuse both vertically (IP to system) and horizontally (simulation to silicon). Last year’s post offered five more gifts reflecting additional products and new features added to our overall solution:

#5: Easier sequence specification in UVM testbenches.
#4: Faster coverage closure in UVM testbenches.
#3: Integration of system coverage with other coverage metrics.
#2: Debug of automatic test cases using standard tools.
#1: A fully automated solution for cache coherency verification.

Every one of the ten gifts from 2013 and 2014 is still available today for our customers. In addition, we have continued to evolve our Trek family of products and to deploy it on ever more challenging SoC verification projects. Without further ado, here is our all-new list of holiday gifts for the verification engineer in 2015:


There Is No Silver Bullet for Low-Power Verification

Wednesday, September 23rd, 2015

Anyone who reads The Breker Trekker from time to time needs no convincing from me that verification is a huge challenge for today’s complex chips. Breker’s Trek family of products exists, along with dozens if not hundreds of other EDA products, specifically to address functional verification. There are more technologies, tools, platforms, libraries, and methodologies than any one verification engineer can possibly learn and use on a day-to-day basis.

Why this diversity of solutions? As I first observed in Electronic Engineering Times nearly a decade ago, there is no silver bullet for verification. The problem is both so broad and so deep that no single tool or technology will ever satisfy the need. It takes a mix of solutions, guided by methodologies, to have any chance of first-silicon success. Low-power verification is an area where this is especially true, and unfortunately there is no silver bullet to be found here either.


Guest Post: Rain or Shine for the EDA Cloud?

Wednesday, July 15th, 2015

Recent announcements from IBM and others about supporting EDA tools in the cloud have spurred renewed discussion on this topic, including here at The Breker Trekker. As expected, the recent posts have been very popular with our readers. Those of you who have been following this topic for a while may recall that, almost exactly two years ago, EDA vendor OneSpin announced cloud support for their formal tools. We invited their VP of Marketing, Dave Kelf, to fill us in their experiences since then:

Two years ago OneSpin introduced the cloud version of it’s Design Verification (DV) formal-based products. Some commentators pointed at other failed EDA attempts to make the same move, suggesting more of the same. Others hailed the announcement as a bold move whose time had come. So… did it work out and what have we learned? The results are surprising, and suggest trends that make some EDA solutions a natural fit for the cloud, whereas others are questionable.


What’s so Special about Your SoC Design Data?

Tuesday, June 30th, 2015

Last week on The Breker Trekker, we discussed the resurgence of interest in EDA tools in the cloud. Like our first post on the topic two year’s ago, last week’s entry was very popular. Clearly this is a topic of interest to both our regular and occasional readers. Two more announcements regarding EDA in the cloud also surfaced during the recent Design Automation Conference (DAC), so it does seem as if there is more effort going toward finding a technically and financially successful industry solution.

Last week we summarized five barriers that have helped prevent cloud-based EDA from achieving mainstream adoption:

  • The EDA vendor’s effort to port to a cloud-based platform
  • Worries about GUI and interactive responsiveness
  • Ability to support users of cloud-based tools
  • Lack of an established, proven business model
  • Concerns over security of the design and verification data in the cloud


Is the Forecast Cloudy Yet for EDA?

Wednesday, June 24th, 2015

It has been almost exactly two years since we discussed the possibility of EDA tools in the cloud here on The Breker Trekker. The post was popular then, and it remains so. In fact, of the more than 100 posts we’ve published, our cloud post remains the second most read. This week, the recent news that IBM will make its EDA tools available in the cloud through a partnership with SiCAD brought cloud computing back to the forefront. Let’s discuss what has changed–and what hasn’t–in the past two years.

The idea of users being able to run EDA tools as leased enterprise software on remote machines has been around for years, well before the term “the cloud” was widely used. Synopsys invested a great deal of time and effort into its DesignSphere infrastructure, initially more of a grid application than a cloud solution as we use the term today. But the difference is not very important; the key concepts are the same and they represent a major departure from the time-tested model of customers “owning” EDA tools and running them in-house.


Please Help Us Choose Our Next TrekApp

Wednesday, June 17th, 2015

As we have discussed before, we have followed the lead of other EDA vendors by packaging aspects of our advanced verification technologies into pushbutton applications (apps). The first in this product line, our Cache Coherency TrekApp, has been very popular since its introduction last year. As we have covered in depth, this is due in part to the trend of large chips becoming multiprocessor SoCs with multi-level caches. The sudden escalation of cache coherency verification from the CPU developer to the system integrator created strong demand for our nicely bundled solution.

There are many other trends ongoing and emerging in the SoC industry, and we have a long list of ideas for possible TrekApps to help address the challenges that are arising. We would like your help in prioritizing our development efforts. We have established a survey listing ten TrekApps under consideration. Please simply check off the ones of most interest to you by midnight Pacific time on June 30. All submissions will be entered into a drawing for a $50 gift card.


What to Run on Day One in SoC Simulation

Thursday, February 5th, 2015

Two recent blog posts discussed what you should run when you first map your system-on-chip (SoC) design into an emulation platform and when you have your first fabricated chips from the foundry in your bring-up lab. We pointed out that trying to boot an operating system and run applications should not be the first step because production software is not designed to find and debug lingering hardware design errors. We recommended running the multi-threaded, multi-processor, self-verifying C test cases generated and optimized for hardware platforms by our TreSoC-Si product.

As you may know, TrekSoC uses the same graph-based scenario models as TrekSoC-Si, but optimizes the generated test cases for virtual prototypes, simulation, and simulation acceleration. In this post, we ask a similar question: what should you run in simulation when you first have the RTL for your SoC assembled and ready to be verified? Of course our answer will be the test cases generated by TrekSoC.  However, there are some advantages of simulation over hardware platforms that foster a more extensive methodology for verification with Breker’s products.


What to Run on Day One in the Bring-Up Lab

Tuesday, January 20th, 2015

Last week’s blog post raised the question of what you should run when you first map your system-on-chip (SoC) design into an emulation platform. We pointed out that trying to boot an operating system and applications immediately was a challenge because these are complex pieces of production software not designed to find lingering hardware design errors or to debug such errors easily even if detected. On many projects, the production software isn’t even available early enough to be used for design verification.

We strongly recommended running the multi-threaded, multi-processor, self-verifying C test cases generated by our Trek family of products. These “bare metal” test cases run on your SoC’s embedded processors at every stage of the project. TreSoC-Si specifically generates test cases tuned for emulation and FPGA prototype platforms. But what should you run when your fabricated chip first arrives back from the foundry? The answer is the same. TrekSoC-Si also generates test cases for silicon, ideal for use in your bring-up lab. Let’s explore this idea a bit more.


What to Run on Day One of Emulation

Wednesday, January 14th, 2015

Many of you are probably familiar with Lauro Rizzatti, who has written countless articles on the value of emulation for verifying system-on-chip (SoC) designs and been an occasional guest blogger here on The Breker Trekker. Lauro recently published an article in Electronic Engineering Times that really caught our attention. We could not possibly agree more with the title: “A Great Match: SoC Verification & Hardware Emulation” and, as we read through the article, were very pleased with the points he made.

Emulation involves mapping the RTL chip design into a platform that runs much like an actual chip, albeit considerably more slowly. The industry is not always consistent on its terminology, but generally if the platform is connected to a software simulation it’s being used as a simulation accelerator. In this case, the design’s inputs and outputs are connected to the simulation testbench much as they would be when running software simulation of the RTL. In emulation, there’s no simulator or testbench, and so the question becomes what to run on the design.


Top 5 New Holiday Gifts for the Verification Engineer

Tuesday, December 30th, 2014

Last year, we wound up in December with a post on the “Top 5 Holiday Gifts for the Verification Engineer” and it proved very popular despite the holiday timing. To refresh your memory (and ours), here is the 2013 list:

#5: Relief from hand-writing verification test code.
#4: Relief from hand-writing validation diagnostics.
#3: Vertical verification IP reuse from block to system.
#2: Horizontal verification IP reuse from electronic system level (ESL) to silicon.
#1: Effortless system coverage reflecting end-use applications.

As you might expect, every one of these gifts is still available today for users of our Trek family of products. But over the last year we have added two new products, many new features, and deeper integration into existing verification flows. So we’d like to wrap up 2014 with an all-new list of holiday gifts for the verification engineer. We hope you like them as much as you liked last year’s offerings:


DownStream: Solutions for Post Processing PCB Designs
S2C: FPGA Base prototyping- Download white paper
TrueCircuits: IoTPLL

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy