Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
Get email delivery of the Cadence blog featured here
In my 2004 book, Co-Verification of Hardware and Software for ARM SoC Design, I wrote about the concept of a co-verification engineer. It's the very last section of the book. Although a lot of people told me they read the book (and some actually learned something from it), nobody ever contacted me and said they were a co-verification engineer, so I'll ask again in a slightly different way in 2008.For many years EDA companies providing verification products (like Cadence) have been trying to expand the market by selling products that target the embedded system software that accompanies the hardware design and verification projects they already serve. Logically, it sounds like a good opportunity for market expansion. Unfortunately, efforts in this area have been difficult for various reasons:
There are probably more reasons like management structure and project time line issues, but the primary obstacle to creating products targeting embedded software might be that there is no concept of a software verification engineer. Software engineers certainly try to produce high quality software using techniques such as code inspections by project peers and other types of testing.
The current situation seems very close to the situation in hardware verification in the mid to late 1990's. Sales people and application engineers tell war stories about Specman being introduced to the market as a verification tool at a time when there wasn't a strong concept of a verification engineer. Most hardware design engineers were also responsible for verification.Their tools consisted primarily of a logic simulator and a waveform viewer. The new thing at the time was code coverage (as a 3rd party PLI program). Explaining the concept of a separate tool and language for verification didn't sink in immediately with engineers who would say things like, "I have a simulator and a waveform viewer, what else could I possibly need?". To succeed with Specman, it was necessary to explain the need for a separate person called a verification engineer with a focus on verification and a different skill set from design. Over time this concept took hold and today not many people question the need for verification specialists.The next phase of verification evolution might be to create equivalent specialists for embedded software verification. Today's software engineers are much like the hardware designer a decade ago. They says things like, "I write tests for my software in C, I have a debugger if things don't work, line coverage to measure quality, and some scripts to run the tests, what else could I possibly need?".The role of the software verification engineer is much more than testing, it involves the same concepts that are applied to hardware verification. These are verification planning, constrained random generation to create multiple test scenarios, checking results, and collecting and measuring functional coverage. The job of the software verification engineer is to find bugs in the software, but to use metrics to show the likelihood of bugs is low.
I'm starting to see some job openings on places like monster.com for software verification engineers. I think many are in safety critical domains like aerospace and automotive.
Does anybody out there consider themselves or know people who call themselves a "software verification engineer"?
Maybe I'm completely off and there is no need for rigorous verification techniques for software. After all, the software industry is far older than the RTL design and verification industry and if there was a need it probably would have been solved by now. Maybe the pain or necessity of such methodologies is just not there for software. If you think this is the case, don't be shy and post a comment with your opinion.
Verification techniques used in hardware industry have all been defined and created in the software industry first (except maybe the random generation provided by Specman). I mean test cases suite, mutational code and even formal proof.
All these techniques i use every day were teached me by a Software Verification Specialist (Nuclear, automative, aeronautic industry) with 20 years experience.