Industry Insights - All Comments

What a grand article ...

Anonymous — Thu, 09 Feb 2012 21:41:23 GMT

What a grand article.. I especially liked the comment that the color of analog verification is different. Thank you :)

Hi Cedric, I think ...

Anonymous — Tue, 07 Feb 2012 09:03:19 GMT

Hi Cedric,

I think you raise a good point with the SV drawback, its class based domain can not use SVA. One of the biggest misconceptions of SV is that people think that it is "just an extension of Verilog, which we already know". SystemVerilog's class based language domain is not like the module language domain and for any RTL designer to learn that part of the language is really quite difficult for various reasons.

But one point I don't understand is the SV license cost advantage you mention, SV and e costs are exactly the same and there is no difference if you use SV or e.

Another cost factor should be more important, the costs to develop, debug and maintain code. I think everyone who had the chance to work with both languages will tell you that e is more cost efficient in terms of its development, debugability and code maintenance.

Very novel concept w ...

Anonymous — Fri, 06 Jan 2012 06:27:43 GMT

Very novel concept with the help of CPF format and power domain. Most of the post P&R pain points can be brought upfront at the front-end stage thus increasing TAT of the overall flow and chip reliability and manufacturability.

Its a great achievem ...

Anonymous — Thu, 05 Jan 2012 17:10:38 GMT

Its a great achievement to one and all who worked for this project, Presently i am an engineer working on ORCAD9.1 version and recently i tried to use this ORCAD16.5 version, demo version its very nice and lot on changes had been made in this software, i want to learn this software, so please guide me to learn this software.

I would like to cong ...

Anonymous — Mon, 14 Nov 2011 02:56:36 GMT

I would like to congratulate your team in the quality representation of the EDA presentation and the great job they did in there explanation of the direction of the industry, and how each of the steps will benefit by the apps that are now available to yours and others EDA systems. I'm presently working with Oracad 9.1 in design. If you have anything available to us students that will help in the ability to be knowledgeable with these cutting edge tools(such as Auto cad has) with there free student versions that are complete, that is that they are full versions to enable us to be as creative as possible which in turn prepares us for the work place upon graduation. It would benefit us tremendously. I'm presently in a Electronics Engineering Program at USM and could see how it would be so beneficial to our team of students in our strive to reach for the goals of tomorrow today. Thank you, Jack Dvorak

Really appreciated. ...

Anonymous — Fri, 11 Nov 2011 11:33:10 GMT

Really appreciated.

Thank you

Richard, Urban Airsh ...

Anonymous — Tue, 01 Nov 2011 16:48:24 GMT

Richard, Urban Airship is a company that I like to present as an example of what we are up against in EDA and semiconductor when seeking investment.

They're in Portland, Oregon and started from scratch the first week of June, 2009. At the end of July, 2010, they raised $5.4 Million in Series A financing. A year ago, they moved into swank new quarters in the Pearl District. Yesterday, they announced what I believe to be their first acquisition ...

uncrunched.com/.../simplegeo-to-be-acquired-by-urban-airship

And Lip-Bu makes a good point near the very end ... some of us are in 'expensive industries' (a term that I would credit to Helge Seetzen, CEO of TandemLaunch, unless he borrowed it from someone else!) and it's not just electronics, there are other high technology areas like biotech and pharma that are seeing Web 2.0 suck all the oxygen out of the investment room (see tech news sites like TechCrunch or GigaOm).

I definitely agree w ...

Anonymous — Thu, 29 Sep 2011 11:46:08 GMT

I definitely agree with these conclusions. Note that you can use SV assertions in addition to your e verification environment to benefit the advantages of the 2 worlds.

I would add that SV has another :

1/ drawback : assertion can not be used in class, limiting their usage

2/ advantage : license cost

Poor analogy with th ...

Anonymous — Mon, 19 Sep 2011 19:12:38 GMT

Poor analogy with the screw driver & knife. I have found myself similarly use a screw driver to cut things - admittedly not food (yet) - and yes with less efficiency if only I could have found that darn knife.

Ask yourself instead, which is the more powerful tool in general, the screwdriver or the knife ? Or am I throwing a wrench now ?

I was having lunch w ...

theASICguy — Thu, 01 Sep 2011 20:58:39 GMT

I was having lunch with a former co-worker of mine yesterday and he was telling me that he'd interviewed for a position where he was asked about his knowledge of 10 different interfaces, including many of the ones mentioned above. It seems that you need to be multi-lingual these days to get a job.

Good point Muhammad. ...

Anonymous — Wed, 31 Aug 2011 21:07:37 GMT

Good point Muhammad. The cost of internally-developed VIP is actually quite high. Customers have quoted "man-years" of development time for complex interfaces and that doesn't include the cost of cultivating dedicated protocol experts in the first place. We do see more customers starting to look at these internal costs and being more open to external VIP, especially when they can get production-proven VIP off-the-shelf. That lets them focus on debugging their chips instead of debugging internally-developed VIP.

I agree with inter ...

Anonymous — Tue, 30 Aug 2011 21:34:55 GMT

I agree with interfaces but I have reservation on VIP.

I have been working in the design verification for more than a decade. VIP has very low penetration in the real DV environments due to its cost. Companies are willing to pay their engineers to develop custom solutions but never pay to the VIP vendors.

Vin, Thanks for t ...

Anonymous — Tue, 30 Aug 2011 17:38:02 GMT

Vin,

Thanks for the perspective. The "top 10" will always be a moving target, but I chose Ethernet 40G/100G in the networking space for its potential to further consolidate storage area networks onto the Ethernet backbone. As for other top 10 candidates, Thunderbolt is one we are keeping a close eye on.

Tom

Richard: This is ...

Anonymous — Mon, 29 Aug 2011 16:18:31 GMT

Richard:

This is a good list to start with but I wonder if the Cloud computing interfaces may undergo a change. As the Network and the Server markets merge to meet the cloud requirements we are seeing Interlaken and QPI as emerging interfaces which will complement these.

Vin Ratford

Xilinx

ipfixo

Anonymous — Wed, 03 Aug 2011 14:47:55 GMT

ipfixo

Great that Virtuoso ...

Anonymous — Thu, 28 Jul 2011 18:52:10 GMT

Great that Virtuoso will work from a Mac! Many of us would appreciate more tools run on Mac; actually run _on_ a Mac, not just be accessible from a Mac.

Oh, by the way: they stopped calling it "Macintosh" over ten years ago!

Hi, I think this arg ...

Anonymous — Fri, 22 Jul 2011 06:50:29 GMT

Hi, I think this argument 'against' is very weak, also to some degree testability is part of a good design - why should a good designer make a bad design, it would be a blame. I believe, most designers make a good job in design & verification, and in analog both are closely related, and iterative. So the thinking is 'My blocks are fine, why waste extra-time for doing verification again by someonelse?'. Maybe even with crude non-estabilished 'non-analog' techniques executed by buggy tools.

Close before tape-out the back-end is in critical path. Doing design & verification together has also the advantage to directly check alternative solutions. There would be little time for this with split teams.

The best would be always to have something that work: starting from architecture, topdown-models & well-known blocks, doing refinements and understanding everything more and more. No matter how you call it.

I like the low key i ...

Anonymous — Thu, 07 Jul 2011 22:30:57 GMT

I like the low key interview style but the background was noisy and distracting and a whiteboard or one or two illustrations would have been handy. You should setup a small studio (8x8 section in your booth) where it would be a little quieter and the person interviewed could sketch one or two simple diagrams to provide context

I thought one of Alt ...

Anonymous — Wed, 06 Jul 2011 22:02:44 GMT

I thought one of Altos's very strong points was independence from other simulation tools and

formats such as PrimeTime/CCS and ETS/ECMS. Because Liberate could generate any library formats easily from the same cell line-up. But, by this acquisition, you can be no longer independent at all. I think we will be forced to find a new independent characterizer very soon.

The cloud represent ...

Anonymous — Thu, 23 Jun 2011 11:26:42 GMT

The cloud represents a cultural change, but there are ways in which those changes can be mitigated for the engineer, manager and system administrator. Each will have their own set of misgivings, but there are a number of companies stepping up to solve them. I met a number of such companies at DAC in the Synopsys cloud stand, but that was by no means a complete set. What seems to be clear at this stage is that partnership is going to be key. No one vendor offers a complete solution for all so it is going to be up to the larger vendors to form strategic alliances in order to tackle the many reasons why design companies don't want to be on the cloud yet.

Thanks Richard for t ...

Anonymous — Mon, 20 Jun 2011 15:30:53 GMT

Thanks Richard for this article,

Xilinx's David Tokic "platform provider" speech is in line with a presentation I have given last march at e-Drive's Motor, Drives and Automation System conference in San Antonio, TX and titled "FPGA Technology as a Platform for Innovation Integration in Motor Drives apps".

You can access this presentation on my blog pe-fpga.com that's on FPGA Technology in Power Electronics applicatiions :

http://bit.ly/jo5Axu

Best Regards, Marc.

This is indeed inter ...

Anonymous — Sun, 19 Jun 2011 21:54:35 GMT

This is indeed interesting and encouraging that a foundary is taking such an interest in System Level power solutions. Makes sense since Power and Software/Verification developments are making or breaking multi-core projects.

India is beginning to get into ESL what with it's vast talent pool in software. With emerging TLM2.0 standard, India can provide a big boost to this field with services and products.

-Ashvin

Kudos to Richard for ...

Anonymous — Thu, 09 Jun 2011 15:52:33 GMT

Kudos to Richard for accurately capturing the important points of the panel.

I do not believe tha ...

Anonymous — Wed, 25 May 2011 17:03:06 GMT

I do not believe that MEMS is a large enough market. Democracy needs a lot of people, ergo MEMS will need a huge market in order to be democratized. I don't see it happening unless some new applications are brought into play.

Unlike virtual model ...

Anonymous — Sun, 01 May 2011 01:41:06 GMT

Unlike virtual modeling as we think of it today, with SystemC TLM 2.0, teams are able to do more exploration. That was the noble goal of VHDL with its one entity, multiple architecture configuration and user defined signal types for abstraction of connectivity. But it didn't inherently have the ability to move logic into the channel description like TLM 2.0 has.

Does TLM 2 really allow for a lot more exploration if we are mostly implementing with predetermined buses?

That's right ... a n ...

Anonymous — Thu, 14 Apr 2011 17:44:50 GMT

That's right ... a new engineering class is step by step borning ... a mixed of a SW guy with HW and System sensibility ... I just hope its real value will be correctly considered and ... unfortunately ... I see the organization evolution trip still so long probably normal if we consider it is done step by step ;-)...

One comment about wh ...

Anonymous — Tue, 12 Apr 2011 19:30:58 GMT

One comment about why a "cloud" is important to us (customer). The time we can save from a "private cloud" will pay for itself if the software design industry starts there. Whether its a remote session or Web application bringing the graphical design, the savings in resources and time to download, install, update, configure will be a benefit and we are anxious to have today. We want to provide our internal designers the tool to start designing the same day it is requested. It is no more different than trying to get your product out there first.

I agree that this is ...

Anonymous — Fri, 01 Apr 2011 08:11:22 GMT

I agree that this is an important step for Cadence. The connection between design, verification, implementation, test and the IT infrastructure has not been given enough emphasis. As the flows grow in complexity there has been some efforts to provide reference flows and limited 'best practice' guidelines, but inevitably there has to be a lot of glue infrastructure to tie everybody together. Partly that comes from a mixed bag of version control, project management tools and compute infrastructure that makes a custom solution inevitable even before you have considered customer or mixed-vendor flows.

Small companies without the resources to automate a lot of the infrastructure will rely on sensible design management procedures and a low turnover of staff. Larger companies will often have a number of individuals working on aspects of the flow and infrastructure solving a lot of the communication and project management issues in house. As the system grows in complexity there can be significant value tied up in the infrastructure IP which in turn makes it difficult to make disruptive improvements.

On company hoping to tackle this issue head on is Ellexus, a UK based start up (www.ellexus.com). They have produced a tool which automatically records the relationships between programs, files and scripts in the system. This can be used maintain up-to-date documentation, to audit working practices or to facilitate sharing of infrastructure. It can be used to record a run on a system with can then accompany the scripts and data so that remote engineers can see how their system needs to be configured and troubleshoot problems quickly. The main aim is to reduce the amount of time highly qualified engineers have to spend executing scripts in their head in order to understand a system.

IT support from the EDA vendors is long overdue in their quest for complete EDA solutions. I don't think it will solve all the problems, but combined with new solutions like those from Ellexus and the other emerging infrastructure start ups, we can do a lot to stop companies from reinventing the wheel.

A nice resume - albe ...

Anonymous — Wed, 23 Mar 2011 10:02:12 GMT

A nice resume - albeit rather Cadence-centred; but thank you anyway.

One potential problem with "parasitic aware" design is when the device modellers take it as relieving them of the need to include the parasitic calculations in the explicit device modelling.

The problem here is transparency, and there are two potential negatives.

If approximate parasitic calculations are included in the basic device model the designer can initially optimise semi-analytically; in addition individual designers can check the calculation algorithm for sanity (and some of us do - albeit somewhat randomly).

If on the other hand the substrate resistance model in the parasitic extraction is incorrectly chosen the designer is unlikely to discover the error until samples don't work as expected - and even then it can be extremely difficult to identify the cause. [Sorry to "bang on" about this - but I've just seen another example of just this problem.]

Interesting idea, bu ...

Anonymous — Tue, 15 Mar 2011 12:47:46 GMT

Interesting idea, but it remains to be seen how it rolls out in practice.

The trouble remains that interactions require full spice sims and that's not

easily done on designs at the top level, where there are a lot of devices and

some conflicting simulation requirements. Some blocks are GHz devices and

others take ms to settle, spectre just can't get it done in anything like a reasonable

time at full spice level.

Cheers

Adrian

This is sensible as ...

Anonymous — Mon, 14 Mar 2011 21:08:10 GMT

This is sensible as an intermediate-stage check - but it is still too late in the flow for maximum utility. What is most needed at the first-simulation stage is parasitic-aware models, so that sensible well and substrate parasitics are included at the first stage. At the present time this does not appear to come naturally to foundries; but the EDA companies could help by providing templates that allow designers to define diffusion and well arrangements from the schematic - and which would also generate the well parasitics without requiring the layout. This should also in principle develop to extended LVS checks that the layout conforms closer to designer intentions.

It will not be straightforward to do this well - we only need to look at the development of source-drain models and the resulting arbitrary numbering system of GEOMOD (and that still does not allow designers to define layout ordering even of the Source-Drains in a single DIFF region).

Excellent summary of ...

Anonymous — Fri, 04 Mar 2011 17:24:14 GMT

Excellent summary of a very interesting panel session. On the spec vs. the reference implementation question, yes Janick said the spec is the spec, but Tom and Ambar pointed out that the way the process actually works right now, much of the documentation that is "the spec" comes directly from code comments in the reference design. This is significant. Like most open source projects, the code basically is the spec. This isn't a spec with several competing proprietary implementations that each have varying degrees of spec compliance. This is open source code that you can download and run anywhere.

There is a kind of a ...

Anonymous — Wed, 02 Mar 2011 16:25:25 GMT

There is a kind of a quiet assumption that OVM/UVM provides verification reusability for free which seems to be an important factor on decisions made by relatively inexperienced verification managers. Then comes a huge surprise that the test bench derived from OVM classes cannot be used on the next project (sometimes event on the project derivative). Well, if there is no high level architecture over the OVM then the methodology itself will not guarantee anything especially will not provide reusability and efficiency. For example the Scoreboard might be perfectly un-reusable even though it is an ancestor of the ovm_scoreboard. One can end up with equally un-reusable environment but written in SV/OVM this time. So now we come to the kind of a conclusion that the language is actually of second importance following the verification environment architecture which should always be #1. Anyway I have always found implementation of such architecture much easier and quicker in e than in SV. Simply because e is a verification language designed from scratch to address specific verification needs and equipped with tools which verification engineer needs most on daily basis. As a result we were able to create a new block level self checking and fully functional test bench from scratch around a new RTL in just one day. ONE DAY! 8 MAN HOURS! How? Just by reusing eVCs (config, transforms, scoreboard, bfms, sequences, etc.) previously architected and already proved in many (different!) projects and by extending hook methods. In this case I really don’t mind that SV test bench might be actually quicker in simulation time...

Behavioral modeling ...

Anonymous — Sat, 26 Feb 2011 03:29:18 GMT

Behavioral modeling lets you choose your accuracy/speed trade-off level. You can get the same accuracy as Spice if you want but with a more efficient model - simulating transistors is an unconstrained problem, simulating specific circuits is constrained and mathematically more stable.

Really you should only use Spice to characterize cells, and for any higher level activity you use the behavioral models.

Behavioral models can include assertions to warn you if you abuse them.

Thanks for the artic ...

Anonymous — Thu, 24 Feb 2011 22:36:36 GMT

Thanks for the article. As previous commenter pointed out; performance gain is achieved by increasing the abstraction level, simply by eliminating costly model evaluations. However, this is also a trade-off for accuracy.

Thus, I find perf-accuracy graph misleading. Generally, fastspice simulators perform better than Conservative Behavioral model simulations /w fastspice. This is due to the fact that, fastspice applies circuit partitioning/device matching techniques to speedup the simulation. This advantage is lost when conservative behavioral models are used since simulators do not know how to handle the detailed behavioral model efficiently.

Hi Richard, I think ...

Anonymous — Wed, 23 Feb 2011 07:57:48 GMT

Hi Richard,

I think that behavioral analog models, as you pointed out, are not useful if they are not accurate and can loose their advantages(in terms of performance of simulators and effort to develop them) if they are too much accurate.

Actually if the analog models should represent every aspects of analog circuits they can' t be really advantageous!

I think that the real benefit of analog models is that they can be very accurate in the operating points(areas) of interests of analog circuits and very simple in other operating areas that are not of much interest (while spice models maintains the same accuracy, or better the same computational load).

So in order to gain performance advantages one should model with a high accuracy only the operating points in which one could use that models(for example in full chip simulations each analog circuit has a specific way in which is used).

For reducing the effort to spend for modelling, common strategy for every category of circuit could be developed to model beavior of interests.

For example all regulators could use the same modelling strategies in their operating point ( based on interpolation of data taken from spice sims etc etc ).

The same could apply for charge pumps, input output buffers, pll, dll etc etc.

Giacomo

A few quick thoughts ...

Anonymous — Tue, 22 Feb 2011 17:56:57 GMT

A few quick thoughts: UVM is a single methodology supported by all simulation vendors, whereas VMM was proprietary to Synopsys. UVM will support VIP interoperability and a larger VIP ecosystem. UVM supports more block-to-system scalability. For more info, see www.uvmworld.org/overview.php.

What new things are ...

Anonymous — Tue, 22 Feb 2011 06:36:24 GMT

What new things are brought to the table by UVM that are absent in VMM?

Hi Dave, I agree ...

Anonymous — Sun, 06 Feb 2011 11:22:39 GMT

Hi Dave,

I agree with you, this is a big step, how ever it require collaboration of FPGA Vendors and EDA tools to address this issue,

In addition FPGA vendor will have to speed up the compilation times for large FPGAs.

Moshe Genish

HW Leader PMC-Sierra

Thank you for the th ...

Anonymous — Thu, 03 Feb 2011 19:22:36 GMT

Thank you for the thorough coverage Richard.

As FPGAs take on more applications and increase in complexity, software is important but these devices also need to be verified at the implementation level in market-realistic time frames something I like to call Device Native verification. Using the FPGA as a turbo charger to the simulator enables the verification team to keep pace with the project time line while the device complexity escalates with each new FPGA technology node.

Part of the EDA360 mantra, silicon realization is a broad concept that addresses the requirements and solutions to create a deterministic path to a successful silicon device. Unlike IC design, the FPGA design process lacks the traceability through to silicon. By integrating the FPGA into Incisive, like GateRocket does, the loop is closed between silicon and design and a significant gap to silicon realization for FPGAs is addressed. That is why Hardware-Assisted verification for FPGAs is critical to the successful growth of the FPGA market.

Dave Orecchio

CEO, GateRocket, Inc.

Interesting article. ...

Anonymous — Wed, 02 Feb 2011 10:12:14 GMT

Interesting article.

Thanks Richard for this article and Geoffrey for your comments.

On a similar question, I once compared this with the differences between Linux and Windows. Nowadays, I would talk more about developping for iOS or for Android. I like the screwdriver and knife though ;-)

They are somehow both nice for what they are good at. Both having pros and cons depending on what you want to do with them.

Anyway.

On the technical points, I more than agree that AOP brings productivity and ease some complex code architecture.

IMHO, this comes with two main drawbacks.

1/ One is mentioned here is about the learning curve. All engineers have been taught the OOP principles so you can train someone to SystemVerilog without introducing new concepts. Having done the exercise several times, I now expect something like half the time to train someone and get him/her efficient in SystemVerilog as opposed to e. But as Geoffrey said, it also depends on the personal background, so this is not a very strong statement.

2/ The second point I want to expose about the AOP is its ability to give more freedom to code writers (as said by Geoffrey with less code and in a more productive way) to add new features to existing objects.

The drawback of this is that you can easily write unmaintainable code.

Verification IP are in general well written and don’t fall in this category.

This is however quite common for big verification environments under the project time to market pressure and where more than 3 or 4 verification engineers are involved in the same verification environment.

It’s so easy to add a new feature right in the middle of the file that is already in your emacs buffer (eclipse for younger people or vi for others ;-) rather than thinking about the best place to do so, that resulted code can be very hard to debug, to document and to maintain.

If you’re not careful, you get the productivity gain only up to the point that you reach real issues or up to the beginning of the next project. Then you need to dig into all the different AOP features that are spread in the different files to understand which ones are really needed for the next project.

On my side, I’m always tempted to lose a bit of short term productivity each time I can think of longer term productivity for reuse. But time pressure is also on me, and the good compromise is never easy to find.

If you compare this to OOP with SystemVerilog, since you have to clearly declare a new inherited class and use virtual methods, the short term productivity is less than with AOP. But for long term project reuse and maintenance of big environments, I’m not so convinced.

Now, an less technical points, a choice between e or SV should also consider deals with different EDA vendors, local expertise in one or the other language, or availability of the different Verification IPs in one or the other language.

Even though it is possible to drive SystemVerilog OVM components from e sequences (or vice versa), I would not recommend maintaining an environment using both languages unless you have real expertise in both in your team.

In fact, I can easily imagine debugging an verification environment in e with SystemC reference models, VIP in e and in SV (eVC and uVC ?), interfaced with a design in Verilog and VHDL, including a CPU running some C firmware and the overall thing encapsulated with thousands lines of Perl to run a single test.

If you can just keep thing simple, try to do so. The next person working on the project will thank you.

Regards,

Francois

Anu -- many Cadence ...

rgoering — Mon, 31 Jan 2011 16:19:13 GMT

Anu -- many Cadence Community blogs discuss formal verification; you can find them by typing the word "formal" into the "community search" bar. Here's one that discusses some user experiences: www.cadence.com/.../cdn-live-how-to-succeed-at-formal-verification.aspx

Could you provide po ...

Anonymous — Mon, 31 Jan 2011 06:17:54 GMT

Could you provide pointers ( as papers or blogs) to the real life examples of the benefits of Formal verification ?

Dennis -- you are co ...

rgoering — Thu, 27 Jan 2011 18:53:09 GMT

Dennis -- you are correct; according to Si2 Synopsys has not renewed its membership in the LPC. Mentor was not listed as one of the participants above.

RIchard, I think ...

Anonymous — Thu, 27 Jan 2011 04:39:44 GMT

RIchard,

I think you will find, if you actually investigate with Si2, that neither Synopsys or Mentor are participants in the Low Power Coalition. Synopsys may have participated briefly in 2010 as a carryover from Virage, but are no longer a member in 2011.

Global collaboration ...

ShivS — Mon, 24 Jan 2011 21:36:18 GMT

Global collaboration is a daily topic among the teams we work with - what's the right model of data distribution, IT infrastructure, workflow to move design data efficiently as it goes from concept to tapeout. The biggest concern we are hearing lately is security - more IP is coming from external sources and design work if being done in overseas locations or with 3rd party contractors, the potential impact and even legal liability for a breach is growing.

The cloud offers some interesting possibilities for fluidly moving design data and IT assets to where it's needed - kind of like Akamai for content delivery + Amazon for compute resource. The reality is that there is still a lot to be done to secure internal systems and until there can be 100% confidence on data security internally, no senior executive is going to think about going to a public cloud.

Whether it's distributed compute models, centralized private clouds or public clouds, the 3 most important security questions are:

How to determine who can see existence/read/edit design content?

How can design content be securely distributed and tracked?

What mechanisms will prevent a breach or allow a suspected breach to be tracked and shut down quickly?

TV INTERNET USERS WI ...

Anonymous — Fri, 21 Jan 2011 13:31:44 GMT

TV INTERNET USERS WILL BE NORMAL INTERNET USERS, NOT COUCH POTATOES. BIGGEST ISSUE FOR END USERS IS LACK OF DEMO CAPABILITY WHEN BUYING A TV AT MAJOR STORES LEADING TO DISAPPOINTMENTS FOR NORMAL INTERNET USERS, IN MY OPINION. MANAGE EXPECTATIONS UP FRONT. THEN PROVIDE ON-TV TRAINING FOR REST OF FAMILY.

AS TO THE BLOG FOCUS ON DRIVER TOOLS FOR HARDWARE-SOFTWARE INTEGRATION , YES, OF COURSE, INNOVATION IS NO EXCUSE FOR LACK OF COMMUNICATION OR LACK OF INTEGRATION TOOLS, BUT LIKE MOST INNOVATION, THE PUSH FOR DEADLINES KILLS FULL CLOSURE, AND CES IS JUST ONE EXAMPLE OF THAT TIMING PROBLEM. SURPRISE HARDWARE FEATURES AND SURPRISE APPS CANNOT BE ROBUST AND EASY TO USE THE FIRST YEAR OF A MAJOR TSUNAMI OF INNOVATION.

I PREDICT CUTTING END USER COST FOR TV+INTERNET SERVICES WILL BE THE DRIVER, NOT NICHE CAPABILITIES.

Qualcomm's Jim Thomp ...

Anonymous — Thu, 20 Jan 2011 11:00:53 GMT

Qualcomm's Jim Thompson comment, " It's not just about reducing geometries, it's about getting costs down as well." is so very apt. Spiralling complexities, prohibitive prices, rare FTSSes etc. all add to the woes. Will the consolidation, which is happening in all facets, help in the ecosystem coming together?

Excellent article!! ...

Anonymous — Tue, 18 Jan 2011 10:37:47 GMT

Excellent article!!

I do agree with all points mentioned by Mr. Richard. I have worked on both 'e' and 'SV' and I strongly support 'e' from productivity , manageability and re-usability point of view.

Not sure about the c ...

Anonymous — Mon, 17 Jan 2011 17:07:20 GMT

Not sure about the comments comparing the easy of replacing e verification components versus SV ones. Either case is straightfoward if the interfaces are compatible. I've been involved in many projects that aimed to replace e by SV - most of the problems and "lack of productivity" were due to the naive insistence in replicating the configurabilty provided by AOP in SV. Many times it would have been better to use pure OOP techniques. As for other productivity issues, it's really because the tools we have are not very powerful as tools, as well as significant oversights in the SV LRM. Take introspection. The reason there's so much extra code required for OVM/UVM compared to e is because the language does not provide the introspection that e does. It's a ridiculous oversight as the tools already have the capability (they have to have otherwise they couldn't operate at all) - yet verifiers have to jump through hoops defining the obvious simply because there's no introspection.

SV is definitely not the answer to problem of verification, but neither is e - they're both just a means to an end. The hard part of verification is not in the coding, it's in writing good verification plans and meaningful coverage goals in the first place. The language and low-level frameworks to connect it all up are the easy part.