Posts Tagged ‘TrekApp’
Thursday, August 18th, 2016
When we first began offering our Trek family of products for what’s now known as portable stimulus, we talked a lot about vertical and horizontal reuse. Vertical reuse means that you can create a scenario model for individual IP blocks and generate test cases to run in their UVM testbenches, then move up to clusters and subsystems. The IP models can simply be plugged together to form a higher-level model from which appropriate higher-level test cases can be generated.
At the full-SoC level, you can generate C test cases that run on your embedded processors. Horizontal reuse is the ability to move from simulation to hardware (acceleration/emulation, FPGA prototypes, and silicon) while generating appropriate tests for these platforms from the same SoC scenario model. We generally described both forms of reuse in a unidirectional flow. However, bidirectionality is very valuable and, we believe, essential for portable stimulus. Let’s cover that topic in today’s blog post.
Thursday, July 14th, 2016
Recently, SemiconductorEngineering published the three–part series “System-Level Verification Tackles New Role” as part of its ongoing “Experts at the Table” discussions. The format is simple–an editor sits down with four or five industry experts to discuss a particular topic–but the debate can be lively and the result educational. Breker participates in these roundtables as often as we can, focusing of course on verification among the many technical topics covered by the site.
In advertising a “new role” for system-level verification, this particular series was not overstating the case. We tend to talk a lot about the evolution of verification in general, especially for system-on-chip (SoC) devices and multi-SoC systems. But in some ways what is happening now with our products and the Accellera portable stimulus standardization effort is more revolutionary than evolutionary. So which is it? We’ll attempt to answer that question in today’s post here on The Breker Trekker blog.
Wednesday, June 29th, 2016
Over the more than three years of posts here on The Breker Trekker blog, you’ve seen us reference our TrekBox runtime component on many occasions. We mention it in many contexts: test case visualization, memory usage visualization, test case status, test case debugging, system-level coverage, performance analysis, I/O interfacing, UVM testbench control, and more. We’ve never had a post on TrekBox itself, so today we rectify that and fill in a few details that we haven’t discussed before.
Some of you are familiar with the term “trickbox” in the context of a simulation testbench. We found a nice concise definition of this term in an ARM patent: “Memory mapped (behavioral) test bench component to facilitate verification.” By writing to designated memory addresses, the processors in the design being verified can send messages to the testbench for various actions. Our TrekBox is of course a play on the “trickbox” name, and it provides many presents inside for those who open it.
Wednesday, June 22nd, 2016
We have a saying here at Breker that the fundamental job of any EDA company in the functional verification space is to “find more bugs, more quickly.” A good verification solution increases design quality by finding more bugs, improves time to market by closing verification faster, or reduces project cost by requiring fewer resources. A great verification solution, which we strive to offer, does all three. Accordingly, we talk a lot about the type of design bugs we can find with less time and effort than traditional methods.
We have another saying at Breker: “A performance shortfall is a functional bug.” A lot of people differentiate between these two cases, but we don’t agree. The specification for your SoC describes its performance goals as well as its functionality. Not meeting your requirements for latency or throughout can render your SoC unsellable just as surely as a broken feature. So we also talk a lot about how our portable stimulus techniques generate test cases for performance verification.
Thursday, March 3rd, 2016
We’ve just returned from our most important trade show of the year: the Design and Verification Conference and Exhibition (DVCon) in San Jose. Sure, DAC is a bigger show, but it covers all of EDA and so lacks the front-end digital focus of DVCon. We previewed the event over our last few blog posts and today we’d like to summarize what happened and make a prediction or two about how this particular DVCon will affect the industry.
The biggest news for us was that portable stimulus seemed to be on everyone’s lips this year. Many of the engineers who stopped by to visit our booth had heard the term and were aware that the Accellera Portable Stimulus Working Group (PSWG) is developing a standard. If they didn’t know what portable stimulus was, they almost surely knew by the end of the show.
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:
Tuesday, November 3rd, 2015
The long-established trade association EDA Consortium (EDAC) has started several new initiatives to extend its membership to IP suppliers and to offer more value to its members through new programs. New EDAC Director Bob Smith has a bunch of innovative ideas and I have little doubt that they will breathe new life into the organization. I had the pleasure of working with Bob when he did some consulting for Breker several years ago, and he’s a true professional.
Last week I attended the first in a series of legal-themed events sponsored by EDAC. I expected that the title “Patents and Patent Litigation: Develop, Strengthen, and Protect Your Intellectual Property” would draw well, and indeed the conference room at SEMI Global Headquarters in San Jose was packed. I won’t attempt to cover the wide range of topics addressed, but I would like to hit a few highlights from the panel discussion and the excellent questions from the moderator and the audience.
Wednesday, October 28th, 2015
Those of us of a certain age will remember the secret decoder rings promoted by various products and TV shows. They generally used a simple substitution code to map letters to numbers. According to Wikipedia these have been offered as recently as 2000, so perhaps they are known to younger readers as well. What’s germane to today’s blog post is that formal services company Oski Technology has cleverly used this device as a graphical element in promoting its “Decoding Formal” Club series.
I’ve reported before from these events, which I believe have been very effective at advocating for formal analysis, sharing tricks and techniques, and demystifying what was once regarded as an arcane academic approach to verification. Last week I attended another Decoding Formal Club forum and, as usual, was impressed by the depth of the presentations. Since formal is always a popular topic among readers of The Breker Trekker, I’m going to share a few highlights from that afternoon.
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
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.