If we’re being honest, human beings, especially engineers, are lazy. Let’s face it, most inventions ever made were created for the sole purpose of making our lives easier. The same goes for the manner in which we create our designs. In the not so distant past, engineers were drawing designs by hand on huge trace paper, placing them one below the other to form layers. This sounds like hard work to me! The lazy me would have wanted a smart (read: easy) solution to this process. Then along comes the EDA industry, which Aldec has been part of since 1984, making it much easier for us to do our designs.

Some might argue that EDA was born out not out of laziness, but in fact neccessity, due to increasing design complexity. True, it is impossible to imagine how the pencil and paper method could even work today. The point is it didn’t, and we now have automated the process to such an extent all you need do is enter some parameters in a tool wizard.

The takeaway here is that it’s ok to be lazy – sometimes, and perhaps the the world is even a better place because of it. So the next time your spouse calls you lazy, now you can turn to them and say, “That, my friend, is how EDA was born”.

*A note here for the really smart and effificent. I’ll be hosting a live webinar, Accelerate DSP Design Development: Tailored Flows, this Thursday, July 25. You can register for this free online event at *

**DSP Design Development**

If there were a word (that Marketing would allow me to use) that fully describes the effort it takes to translate a DSP algorithm into synthesizable HDL code I would use it here, but there is not. Fortunately, there is an alternative to all this effort, and while it may not remove the pain completely, it will at least relieve it to an extent where it will be manageable.

An engineer designing DSP models in HDL may face the problem of verifying that an algorithm designed in HDL is giving the same results as in MATLAB® or Simulink®. The standard process would involve exporting results from MATLAB and importing them in HDL testbenches and comparing them. This would require some manual work of exporting the data to a file, copying them over, and finally running the HDL testbench – basically going back and forth between MATLAB and the simulator tool. Wouldn’t it be nice to have an automated way of transferring the data from MATLAB to HDL simulator and back while the simulation is running?

Aldec simulators integrate MathWork’s intuitive MATLAB language and a technical computing environment. These simulators simplify hardware design verification by providing robust visualization and analysis tools. They also extend HDL testbenches with MATLAB language parts in order to create complex stimuli, perform UUT data analysis, or visualize simulated data as clearly as possible. Users can execute MATLAB commands, call M-Function, or transfer data to and from the MATLAB workspace, all within a level of HDL hierarchy.

*What if I am using Simulink? *The Simulink interface within Aldec simulators also simplify verification of hardware designs by providing robust visualization and analysis toolsets. The interface allows co-simulation of mathematical and a hardware component of system-level design, and gives flexibility of successive replacement of mathematical models describing the system with their target HDL equivalents. Users can co-simulate functional blocks described by using mathematical formulas and VHDL entities, Verilog modules, and EDIF cells that are used as black-boxes during the verification process performed within the Simulink environment.

In short, if you have a Simulink model with various blocks, you can generate equivalent blocks from HDL models and replace them in Simulink so that you can co-simulate.

**Debbuging**

If you are finding that most of your time is spent debugging, Aldec Riviera-PRO™ has features that can help here too.

*Data Analysis.* The HDL world is more fixed-point logic and DSP has a lot of floating point operations, and simulating HDL equivalent code typically results in seeing a binary value, or in some cases a fixed point representation. Riviera-PRO’s floating point representation of vectors enables easy visualization of such data. There is also an analog view which can be used to see how a vector is changing values visually, instead of looking at a value on the waveform.

*Data Visualization.* Ever been coding a QAM processor or another signal processing design and wanted to look at the results in format easier to comprehend and not on a time-domain based waveform? Such a time domain representation of data with respect to time allows verifying many parameters of a designed digital system, but it may not be efficient for applications such as image processing, digital filter design, embedded system design, and others. Riviera-PRO offers new solution for a graph-based analysis of HDL objects, correlations between them, and a number of practical applications for it.

Human-friendly visualization tools and techniques can be very important for efficient HDL design analysis and debugging. Specifically, the ability to graphically represent data set values and correlations is very essential for efficient debugging. Using the Plot tool in Riviera-PRO, engineers can focus on designing the hardware, not the time-consuming and inefficient testbench extensions required to view the data in a manageable format.

It is in fact smart, and not at all lazy, to learn about the helpful features and shortcuts in tools that can at least relieve some of the pain of lengthy processes. *For more on these shortcuts and how to leverage them, register for the webinar, Accelerate DSP Design Development: Tailored Flows, at *

]]>