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
This morning before heading to ESC it dawned on me that the park across the street from my hotel was the Boston Public Garden. Maybe it was the swans on the hotel logo, but the ironic thing is that the only way I knew about this park was by reading the book Make Way for Ducklings to my kids. I previously reported that 4 weeks ago we had a new baby girl. During the week following the birth, as my wife was recovering, I took over teaching our 5 year old Kindergarten (all our kids are home schooled). I found out that one of the usual Kindergarten tasks is to do something called Five in a Row which involves reading the same book to a child five days in a row. The book I was assigned to read was Make Way for Ducklings (Viking Kestrel Picture Books). My 5 year old was quite excited to hear that I was at the park where the ducklings followed the swan boats and ate peanut shells dropped by the passengers. Below is a picture from my visit to the park on the way to ESC.
My talk was the last session of the day, but even with the late time slot the attendees were interested in the idea of Coverage Driven Verification for Embedded Software. This was my forth talk at ESC, but first one at the Boston conference. You can take a look at the slides and the paper. Overall, I think the attendees were intrigued by the concept. The majority of attendees seemed to test software on a physical target board and were familiar with writing tests, downloading them to the board, running them, and collecting the results back on the host. The presentation could have used some more details on how to make the physical connection between the host machine and a target board via the mailbox and a hardware channel such as USB, Ethernet, JTAG, etc.
The session before mine was related to code instrumentation, a topic that is close to ISX, especially with the introduction of the monitoring features in version 8.2. The talk demonstrated a way to create your own structural coverage tool by using the C preprocessor. I think most attendees were a bit shocked to think about replacing every construct in C with a macro that inserts code to log which statements were executed, but the presenter, Ark Khasin, definitely won some points for creativity. I had seen an article on it previously on embedded.com so I wasn't as surprised as others might have been. Even if the solution is not completely practical it is worth a look. Attempting to parse C code yourself does take effort so the solution to use the C compiler you already have makes some sense. There is also a paper on the MacroExpressions website.
For ISX we have relied on extracting as much information about the embedded software to be verified from debugging information found in object files. I'll talk more about the pros and cons of code instrumentation in a future post, but there is probably no one size fits all solution.
Ideally, there is no need to instrument source code to collect code coverage, functional coverage, do performance profiling, and more. In order to provide these features on uninstrumented code it's necessary to not only use a simulator or vitual machine to run the code but it is also necessary to have some detailed knowlege about the processor that is running the software. Tools that provide a simulation engine and models can do a lot of things with uninstrumented code. For example, with VMware you can debug uninstrumented Linux kernel code running in a virtual machine.
From the start ISX was designed not to rely on the details of simulation tools and models. The main reason is that are so many ways to run software and so many combinations of processors and tools that it's impossible to keep up and users typically don't really want to hear that they can improve verification, but step one is to replace the models they are using. It also makes things like doing verification with the software running on an actual target board a bit of a problem. As a result ISX uses generic C code to provide the verification connection to embedded software. Working at the source level means the solution is generic and can be used with any processor model and C compiler.
Working at the source level is very flexible but also presents some challenges in the instrumentation area. It means some C code must be added or modified to get the benefits of verification, and sometimes engineers don't really like to think about modifying the code for verification purposes. After I get back from ESC I'll cover the details of various approaches to code instrumentation.
It's good to see the Embedded Systems Conference is still going strong. I'm always amazed by the diversity of the types of products produced by the engineers that attend.