Industry Insights - All Comments

I think it is not a ...

Anonymous — Thu, 12 Nov 2009 17:13:54 GMT

I think it is not a question of either/or, but a healthy balance of both. No Engineer should entirely rely on others to debug their work. This type of situation fosters sloppyness in the designer and resentment and distrust by the verifiers. However, due to the multitude of cognitive errors exhibited in human nature that none of us are entirely free from - such as wishful thinking, confirmation bias, cognitive dissonance, tunnel vision, etc , having independent eyes doing secondary verification goes a very long way to addressing these problems. While most designers are fully aware of the need to try to break their designs, to quote Taleb's 'Black Swan' book, it is the things 'out of left field' that designers are not so good at testing for - things that people unfamiliar with their project, (i.e. customers) might do to it. From a practical side, with tight time-schedules, verification is definitely something that can be developed in parallel by a separate team.

This is a nice artic ...

Anonymous — Thu, 12 Nov 2009 09:18:14 GMT

This is a nice article and I fully agree. The problems are probably manpower, time and money to really split analog/MS design into pure design and verification. Often there are only very few specialists available and in analog and RF design and verification are not so easy to separate - if there is not much time.

One important aspect to some degree often overlooked is that having a full verification flow from system planing to block design to final verifications would highly smooth all activities, enabling better communications on interfaces and leading to early and efficient verification. Designers tend to be conservative, so great tools such as the AMS Designer are in so common use than they should, and also really advanced model libs are often not available. So people stick to Matlab, pure analog simulators, and simple spice-like subcircuit models and are this way simply not on the state-of-the-art wrt to design & verification flow. Not to mention the analog vs digital boarder...

All well-known problems but hard to earn money on it.

Hi Richard: Good ...

Anonymous — Mon, 09 Nov 2009 19:47:54 GMT

Hi Richard:

Good to see you blogging DFT - some of us have never forgotten DFT! Especially us DFT engineers - but the lack of coverage in the mainstream trade press, which has always been the case, as far as I'm concerned, is why I started blogging it.

ITC was good - although smaller, like all the other conferences seem to be. Lots of good stuff happening in test!

Cheers,

JMF

I believe Richard Ne ...

Anonymous — Sat, 07 Nov 2009 05:00:26 GMT

I believe Richard Newton's contributions to the EDA infrastructure should also be recognized. In particular, his work on EDIF and on unified data bases and graphical user interfaces had a significant and long-lasting effect on all of EDA.

Jacques -- I agree t ...

Anonymous — Thu, 05 Nov 2009 16:49:23 GMT

Jacques -- I agree that Randy Bryant's work with BDDs should be on the list. Not only are BDDs used in logic synthesis, but they are also the foundation of formal model checking and equivalence checking. Few innovations have had so many applications.

On logic synthesis, ...

Anonymous — Wed, 04 Nov 2009 18:33:08 GMT

On logic synthesis, I would add the seminal work on BDD's by Randy Bryant, this year's Kaufman award winner, which is the foundation of all logic synthesis.

Good points, Jim. A ...

Anonymous — Tue, 03 Nov 2009 21:42:51 GMT

Good points, Jim. A paper on Sketchpad was given at the very first Design Automation Conference in 1964.

I'm an old school gu ...

Anonymous — Tue, 03 Nov 2009 21:37:17 GMT

I'm an old school guy so I would add:

- Claude Shannon's introduction of Boolean algebra to digital circuit design theory

- Sketchpad developed by Ivan Sutherland in 1963

- Introduction of VisiCalc in 1979. We all know that Microsoft Excel is one of the most widely used EDA tools in the world, right? It's right up there with V.I. ;^)

What? not proprieta ...

Anonymous — Tue, 03 Nov 2009 21:07:04 GMT

What? not proprietary CAE software on proprietary hardware from the early 1980s? ;-)

A very well-written ...

Anonymous — Mon, 19 Oct 2009 17:19:31 GMT

A very well-written article. Thanks, Richard!

To address John's co ...

Anonymous — Fri, 09 Oct 2009 20:16:46 GMT

To address John's comment, deterministic implies a model which produces a certain, unique result. Random implies that behavior is probabilistic. For example, the mean and standard deviation of a MOSFET threshold voltage, Vt, can be modeled as a function of size or other parameters of the environment (context), but such a model won’t uniquely describe the Vt of a particular MOSFET in a simulated circuit. The simulation must choose a Vt value in accordance with the frequency of observed Vt values. The root cause of the uncertainty could be that we don’t know the number of dopant atoms in the channel of the transistor. The random component of variability (as opposed to a systematic component, which is described deterministically) can be dominant in many contexts. In such cases, 3D physical models may not capture all relevant interactions (or their stochastic nature), necessitating more accurate empirical approaches based on statistical characterization.

I don't understand w ...

Anonymous — Wed, 07 Oct 2009 22:38:10 GMT

I don't understand why these context dependencies are classified as "random" variability. Can't they be modeled deterministically if the variation is know to depend on context?

It's like interconnect coupling depending on "context" -- you model the coupling explicitly for crosstalk analysis. We don't treat crosstalk effects as "random".

John

Great article. The a ...

Anonymous — Mon, 05 Oct 2009 17:24:48 GMT

Great article. The analogy to home remodeling is a good one. And while the focus of this panel is on development costs, the "materials" costs and tradeoffs should also be considered. What IP should it use? What would the area overhead be for a certain power architecture? What package would be required if the chip were implemented this way? How challenging will timing closure be at this frequency/process? Examining all of these tradeoffs along with the economic impact using something like the InCyte Chip Estimator should go hand-in-hand with estimating the development costs.

Luke- OK, I under ...

Anonymous — Wed, 30 Sep 2009 22:35:11 GMT

Luke-

OK, I understand what you are after now.

It is true that IUS does not currently support export tasks in a modport, as in your code above. However, you can achieve pretty much the same modelling effect using classes with virtual tasks within an SV interface. The amount of code is pretty small and shouldn't be too intimidating for non-OO people.

I can send you a small example of this approach if you'd like if you send me your email address.

-Stuart

Sorry Stuart, I shou ...

Anonymous — Thu, 24 Sep 2009 23:21:09 GMT

Sorry Stuart, I should have been more specific.

I'm trying to export tasks through a modport in an interface.

For example:

interface tlm_interface();

modport tlm_slave

(export task write(bit [7:0] addr, bit [31:0] data),

export task read (bit [7:0] addr, output bit [31:0] data));

modport tlm_master

(import task write(bit [7:0] addr, bit [31:0] data),

import task read (bit [7:0] addr, output bit [31:0] data));

endinterface // tlm

WRT SV Interfaces vs Classes, here's where I'm coming from:

We've got an existing rtl design.

We've got a small design team of hardware engineers who mainly know rtl. Not much OO experience.

We don't use SystemC, 'e' or OVM. As I said, small (very busy) design team with a different skill set.

I need a method to replace individual modules within our RTL design with a TLM model.

Two main reasons for this:

1. Speedup software debug / development. (A lot of low level software is debugged in our RTL simulation).

2. Speedup testbench development.

SV interfaces seem like an easy way to add TLM components to an existing rtl design.

Should be relatively easy to swap TLM and RTL components within the design.

I'll need 4 flavours of SV interfaces:

RTL <-> RTL

TLM <-> RTL

RTL <-> TLM

TLM <-> TLM

Generic interface ports also help with this technique.

Luke