EDACafe Weekly Review August 6th, 2015


If you live in or near Silicon Valley, you’re fully aware of what a Tesla Model S looks like. They’re everywhere, gliding along silently, leaving behind a wake of enormous marketing cache.

My driving costs are lower than yours are, because I drive a Tesla. My carbon footprint is smaller than yours is, because I drive a Tesla. I’m hip and modern, because I drive a Tesla, so get outta my way. I own a) this parking space, b) the right-of-way at this intersection, c) this lane on the freeway, and d) the right to glare at you if you think you’ve got the right to a, b, or c.

Okay, perhaps a little overstated, but I’ll bet you’ve seen some version of this phenomenon. Yet, had you attended the single, most information rich session at DAC 2015 in San Francisco, you would have learned that a lot of the street cred claimed by Tesla doesn’t actually hold up to close, tech-nomic scrutiny.

On Monday, June 8th, Synopsys’ Patrick Groeneveld and TUM Create’s Sebastian Steinhorst offered a lengthy tutorial [“Electric Vehicles – What’s in it for the EDA Folks?”] during which they blew away the feel-good haze that surrounds EV ownership and revealed numerous harder truths instead.

Life on the Hardware-Software Frontier
August 5, 2015  by Tom Anderson, VP of Marketing

In last week’s post, we spent quite a bit of time talking about the concept of a (realistic) use case that reflected how actual users will eventually manipulate the design being verified. Our focus was on Breker’s graph-based scenario models and how they can easily and concisely capture such use cases. We did some research on the term “use case” and found that it seems to be more common in software design and verification than in hardware verification. That caused us to think about how we at Breker seem to be living on the hardware-software frontier.

It’s not uncommon for hardware designers and software engineers to borrow ideas from each other. Code coverage, for example, was well established in software before it was adopted for hardware design and verification languages. With the move from gates to RTL, hardware became just another form of code and therefore more amenable to software techniques. This is just one example showing that the boundary between hardware and software is fuzzy and changing over time.

You are registered as: [_EMAIL_].

CafeNews is a service for EDA professionals. EDACafe.com respects your online time and Internet privacy. Edit or Change my newsletter's profile details. Unsubscribe me from this newsletter.

Copyright © 2018, Internet Business Systems, Inc. — 25 North 14th Steet, Suite 710 San Jose, CA 95112 — +1 (408) 882-6554 — All rights reserved.