System Design and Verification - All Comments

For automating telne ...

Anonymous — Sat, 06 Mar 2010 02:02:13 GMT

For automating telnet-based testing you can use the open-source 'expect' application.

See for example: www.osix.net/.../article

The value obatined f ...

Anonymous — Thu, 25 Feb 2010 09:02:57 GMT

The value obatined from using a virtual platform greatly surpasses the cost of modeling it. Companies need to get over this barrier as well as start thinking about the results they would get rather than just the enablement. Real ROI calculation adn experience quickly demonstrate this fact.

Virtual Platforms have a wide usage covering architecture, verification, software development, customer enablement, ... To clearly calculate this ROI, companies must think of virtual platform as an infrastructure serving all these use cases with +/- 20% change to a foundation model. Today too many companies focus on a single subset of a use model, thus misquantifying the true return of using virtual platforms.

The additional cha ...

Anonymous — Thu, 25 Feb 2010 07:31:49 GMT

The additional challenge is the maintainence of all these models. In the old days, you could get away with only having RTL models. Now we need RTL models and higher level models. These higher level models are a bit ad-hoc and not standardized.

Some may use Matlab (M), C++, C, systemC, etc. for these higher level models. Interoperability of these models is a problem. Plugging in in different models and mixing abstractions (e.g. part systemC, part RTL, etc.) is also a problem.

Another aspect is the groups that develop the models. Often a systems group developes high level models to gain insight into performance, power, cost, size, etc. These models are often not detailed enough to be of much use to the implentation group, so they will re-code models, primarily in RTL.

In Summary virtual prototyping won't be mainstream unti there is a fully integrated flow from high level models to implementable models. As you hinted at; High Level Synthesis starts to ease this burdon by allowing an implementable flow from high level models. In other words, rather than fixing the problem of inter-operability of disparate models, its better to settle on a higher level of abstraction for implementation, so we can go back to having just one model to maintain.

That is, once we have synthesis flows from virtual platform to implementation, the virtual platform (and all other hight level models) will be disconnected from the downstream implementation, and will continue to be a maintainence problem and avoided whenever possible. --yah think?

This is a great summ ...

Anonymous — Fri, 19 Feb 2010 08:16:11 GMT

This is a great summary of VP benefits, Jason, and I hope that it will be anonymously posted by coffee machines all around the electronics industry. I'm bookmarking it! :)

But ... the problem when one makes the decision to pursue their next design, the Missing Model Syndrome comes back. Part of the answer is ESL, in hand with HLS as you point out, when your high abstraction model of a new IP is done. Then there is IP reuse, TLM and/or RTL, maybe with an assist if an IP-XACT XML file(s) comes along with the individual part or library.

In response to Jonat ...

Anonymous — Wed, 10 Feb 2010 09:18:30 GMT

In response to Jonathan David's remark:

---

e - being a legacy language as well, will likely need some enhancements to be able to effectively address the Mixed-Signal space in which most SOC's sit today.

---

Specman has supported type REAL for years now, with many customers using it in an AMS flow, and others doing some clever statistics capturing & measurement (with vPlans and Enterprise Manager, no less) Looks like we should do a blog post about this ...

Furthermore, the e language REAL syntax & semantics are in the process of being standardized in the next revision of IEEE 1647 targeted for this fall. You can follow (and join) the Working Group here:

www.eda.org/.../WebHome

Team Specman

I hope the ESL vendo ...

Anonymous — Wed, 10 Feb 2010 07:52:43 GMT

I hope the ESL vendors are considering Mixed Signal upfront this time, instead of adding it as an afterthought which is what happened with Verilog, and is finally happening with SystemVerilog.

e - being a legacy language as well, will likely need some enhancements to be able to effectively address the Mixed-Signal space in which most SOC's sit today.

Looks extremly fasci ...

Anonymous — Thu, 04 Feb 2010 15:45:05 GMT

Looks extremly fascinating.

Brian, You raised a ...

Ran Avinun — Sun, 31 Jan 2010 20:00:59 GMT

Brian,

You raised an excellent question. I think your concern is valid and there is a need to consider the implementation implications as you write your SystemC code with the intent to use it for implementation. In the early days of logic synthesis, designers spent a lot of time analyzing their schematic. As experience and confidence built up, they found much less need to do this and started to rely more on other tools. The transition to High-Level Synthesis will be similar and the deliveries haven't changed - the job of a designer is to get reliably into implementation however the job can be done much faster. With the links to synthesis and to high quality checks, Cadence integrated ESL flow addresses these issues in much easier way. Since RTL is just an intermediate step to the gate-level netlist, designers are quickly seeing that (as long as it meets spec,) there is no need to dwell on the RTL.

Cadence is in the best position to address these issues from the following reasons:

1. The developers of the Cadence C-to-Silicon Compiler knew this long ago and therefore embedded the logic synthesis engine and accurate technology libraries into the high-level synthesis tool for tight correlation and predictable time closure.

2. C-to-Silicon database provides cross links between all inputs and outputs (to ensure easy visibility to always drive design changes from top-down).

3. Cadence provides cross link between SystemC and RTL with side-by-side view for both design and verification.

4. Cadence provide Engineering Change Order capabilities for both C-to-Silicon and Conformal so if small changes are required they can be added incrementally.

5. C-to-Silicon Compiler methodology separates the design constraints from design functionality allows re-use of the same functional block in the future with different timing constraints, saving huge amount of time and resources.

6. Collaboration with Calypto allows customers to run Sequentual Equivalency checking between SystemC to RTL combined with Cadence Encounter Conformal alows customers to compare SystemC to gates.

Feedback from the many companies already taping out designs with C-to-Silicon shows that indeed HLS offers big productivity advantages, plus as they gain experience, its only getting better.

Cadence is committed to continue to work on this flow and improve it further in the future.

How is the feedback ...

Anonymous — Fri, 29 Jan 2010 06:02:24 GMT

How is the feedback loop from, say, timing tools. Already it can be tricky to relate timing errors back to RTL. How much harder is it to figure out which C/C++/SystemC construct needs to be changed in order to break up a long timing path?

Higher level programming languages in software and abundant CPU cycles and RAM have virtually eliminated the need for most programmers to ever consider the machine code that will be produced by their high level code. In most cases it seems like RTL designers still have to be very aware of what kind of gates they are inferring. Will ESL designers have to think in terms of what RTL their ESL code is inferring, and then what gates that RTL leads to? In short, does ESL really simplify a designers life, or does it just add to the complication?

Thank you Jason your ...

Anonymous — Thu, 28 Jan 2010 08:55:18 GMT

Thank you Jason your blog is really very helpful!

Great post

Anonymous — Sat, 16 Jan 2010 18:42:17 GMT

Great post

Android System Verification Part 6

System Design and Verification — Sat, 16 Jan 2010 03:17:24 GMT

Welcome to Part 6 of Android System Verification. It's getting hard to trace back to the previous

Android System Verification Part 6

System Design and Verification — Sat, 16 Jan 2010 03:17:23 GMT

Welcome to Part 6 of Android System Verification. It's getting hard to trace back to the previous

Android System Verification Part 6

System Design and Verification — Sat, 16 Jan 2010 03:17:22 GMT

Welcome to Part 6 of Android System Verification. It's getting hard to trace back to the previous

Android System Verification Part 6

System Design and Verification — Sat, 16 Jan 2010 03:17:21 GMT

Welcome to Part 6 of Android System Verification. It's getting hard to trace back to the previous