The Breker Trekker 
Tom Anderson, VP of Marketing
Tom Anderson is vice president of Marketing for Breker Verification Systems. He previously served as Product Management Group Director for Advanced Verification Solutions at Cadence, Technical Marketing Director in the Verification Group at Synopsys and Vice President of Applications Engineering at … More » Please Welcome the Accellera Portable Stimulus Working GroupFebruary 11th, 2015 by Tom Anderson, VP of Marketing
As you may have seen this morning, the EDA standards organization Accellera officially announced the formation of the Portable Stimulus Working Group (PSWG). This group has the charter to “develop the electronic industry’s first standard for portable test and stimulus. When completed and adopted, this standard will enable a single specification that will be portable from IP to full system and across multiple target implementations.” Regular readers will note that this wording sounds very familiar. At Breker, we’ve been talking about vertical reuse from IP to SoC and horizontal reuse across all verification platforms for years. At times we’ve felt like pioneers with arrows in our back. The formation of the PSWG is a validation that we’ve been heading in the right direction. We’re excited to see the industry embracing the challenges of SoC verification and starting to work on a new standard to address these challenges. Read the rest of Please Welcome the Accellera Portable Stimulus Working Group What to Run on Day One in SoC SimulationFebruary 5th, 2015 by Tom Anderson, VP of Marketing
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. The Evolution of DesignCon and Why Breker Isn’t ThereJanuary 27th, 2015 by Tom Anderson, VP of Marketing
One of the most popular posts in the history of The Breker Trekker was one discussing which conferences were most useful for verification engineers. I mentioned that Breker exhibited at the annual Design and Verification Conference (DVCon) in San Jose, and we’ve since published several popular posts about that show. It remains the most important event for us, our customers, and the functional verification industry in general. We will be there again in March, and will provide more information in an upcoming post. I also mentioned the DesignCon show, held annually in Santa Clara, but did not list it among those that we attend. I always go and walk the floor for an hour or two to say hello to old friends and to see what’s new. However, Breker does not exhibit at this show and is highly unlikely to do so unless there are significant changes in its focus and attendance. This is not a criticism of the show, just an observation. Since DesignCon is happening this week, I thought that it might be fun to review its history and how it has changed. Read the rest of The Evolution of DesignCon and Why Breker Isn’t There What to Run on Day One in the Bring-Up LabJanuary 20th, 2015 by Tom Anderson, VP of Marketing
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 EmulationJanuary 14th, 2015 by Tom Anderson, VP of Marketing
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. Blast from the Past: Verification in SiliconJanuary 7th, 2015 by Tom Anderson, VP of Marketing
Late last year, we published a series of blog posts discussing how the world of large chip designs is moving toward multi-processor, cache-coherent SoCs. This trend is due to several sub-trends, including the addition of one or more processors, the growth in number of processors, the use of shared memory, and the addition of caches to improve memory performance. The result of this movement is clear: large chips are becoming more difficult to verify than ever. Verification teams face challenges at every turn. It’s hard to run a complete SoC-level model in simulation, especially if the team wants to boot an operating system and run production applications. This may be feasible in emulation or FPGA prototyping platforms, but these cost a lot of money. What we’re starting to see is the truly stunning trend that some teams are taping out SoCs without ever having run the entire design together. This means that full-chip verification and debug isn’t happening until first silicon is in the lab. Let’s explore why this is happening. Read the rest of Blast from the Past: Verification in Silicon Top 5 New Holiday Gifts for the Verification EngineerDecember 30th, 2014 by Tom Anderson, VP of Marketing
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. 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: Read the rest of Top 5 New Holiday Gifts for the Verification Engineer Just What is a “Breker” Anyway?December 23rd, 2014 by Tom Anderson, VP of Marketing
As we predicted, last week’s guest post by Lauro Rizzatti on the origin of the names for some EDA companies and their products proved quite popular. We’ve found that mixing in some general industry news among the highly technical posts keeps our blog more lively and draws new readers, some of whom may tune in for the novelty but stay for the technology. Of course, we always welcome your comments as to whether or not we’re providing the type of content that’s interesting and valuable to you. One naming story didn’t make it in before the deadline last week. Verific was one of the EDA companies asked about the origin of their name. President and COO Michiel Ligthart passed the question on to founder and CTO Rob Dekker, who said, “That will remain a mystery. But if you really want to know, ask the giraffe.” To find the giraffe, and maybe the answer, check out Verific’s Web site. To find the origin of the name “Breker Verification Systems” just continue reading. We promise to be less mysterious than Rob. Guest Post: What’s in a Name?December 16th, 2014 by Tom Anderson, VP of Marketing
Much as we like informing you about the latest technical advances at Breker and weighing in on various industry topics, we love to take a break every so often and welcome a guest blogger. The EDACafé statistics show that these usually draw very well, and doubtless they attract a varied set of readers. This week we’re delighted to welcome back emulation expert and verification consultant Lauro Rizzatti, who has chosen to provide us with a fun look at the art and science of naming EDA companies and their products: What’s in a name? Apparently, plenty. Let’s dispense some holiday cheer, kick back and forgo any technical discussion for a look at how a few companies in our industry got their names. Naming companies and products is big business. In fact, an entire industry is devoted to coming up with the perfect name to neatly express a company’s mission and the product portfolio. In some cases, though, companies stick closer to their employees and have contests where they can suggest names. That’s how OneSpin Solutions got its name. An R&D consultant in the U.K. came up with the name and won a case of beer for his efforts. A Math Question: Does IoT = SoC?December 11th, 2014 by Tom Anderson, VP of Marketing
Few electronics-related topics have been more widely discussed in the past year or so than the prospects for the so-called Internet of Things (IoT), sometimes called the Internet of Everything (IoE). Hardware and software vendors have been falling all over themselves trying to ride the presumed IoT juggernaut. EDA has not been immune. In its roundup of attendee feedback from this year’s Design Automation Conference (DAC), the DeepChip site quoted a user saying, “The ubiquity of IoT. After 6 hours into DAC, I was ready to slap the next vendor who used that buzzword.” The trumpeting of IoT was even greater at ARM TechCon, not surprising because of its focus on embedded systems. Here at Breker, we’ve used the term sparingly because it’s not really clear exactly what the IoT will become. Certainly there will be many more nodes of all sorts connected to the Internet in coming years, but there are numerous open questions. Our main interest is whether the IoT will result in an explosion of new SoC designs, and hence a broader market for our verification solutions. This blog post doesn’t provide a firm answer since none is possible yet, but it’s a topic worth addressing. |
|
|
|||||
|
|
|||||
|
|||||
