Catalytic adds key piece to ESL puzzle
There's a missing element to electronic systemlevel design; how do we get the C/C++ representation in the first place? By adding fixedpoint capabilities to Matlab, startup Catalytic is providing an answer.
A logical conundrum
Before we plunge headfirst into the main topic of this column with gusto and abandon, there's a little logic problem I've been pondering for a couple of weeks now, so I thought I'd share the fun and pass it around.
The idea is that you have a "black box" with three inputs called A, B, and C, and three outputs called !A, !B, and !C, where the latter are the logical inversions of the former. Of course we could easily implement this using three NOT gates (or INV gates if you prefer that nomenclature). The problem is that we are allowed to use only TWO of these simple inverting gates combined with as many AND and OR gates as we can lay our hands on.
I'm assured that there is a possible solution — and sometimes I feel as though it's just within my grasp — but then the phone rings or another crisis rears its ugly head and the little rapscallion slips away again.
And then I thought: "A problem shared is a problem halved," as they say, so now I'm sharing it with you. If you come up with the answer, please feel free to send it winging my way through the Internet, and I'll include your solution in my next column. But we digress.
True ESL is getting closer by the day
For more years than I now care to remember, people have been bandying the term "Electronic System Level" (ESL) design around. The problem is that, with a few notable exceptions, although there's been a lot of excited talk and gesticulation, the actual design tools themselves have been somewhat thin on the ground.
The key to ESL is for designers to move to higher levels of abstraction. For we hardware design engineers who are used to working with RTL, the next big jump is to move to some flavor of C/C++ (we could try to grapple with SystemC, but it would take a braver man than me to do so).
There are many advantages to working with untimed C/C++ representations, including the fact that verifying these representations is fast and efficient (a pure untimed C/C++ representation will simulate 100 to 10,000 times faster than an equivalent RTL representation); and also the fact that such representations facilitate hardware/software codesign and coverification.
But there are also problems. Until recently, the two major issues facing hardware design engineers — with respect to this migration to higher levels of abstraction — were (a) how do we get the C/C++ representation in the first place, and (b) how do we eventually convert these representations into equivalent Verilog or VHDL RTL?
With regards to the latter point, tools such as Catapult C from Mentor Graphics are starting to come online. As I discussed in my "Catapulting C to Success" column from June 2004, the Catapult C engine is jolly efficacious when it comes to synthesizing the C into RTL for use in traditional simulation and synthesis environments.
But we are still left with the other half of the problem, which is how we obtain the original C/C++ representation in the first place.
Catalytic adds key piece to ESL puzzle
Over recent months, I've started to become more and more exposed to digital signal processing (DSP) design flows. The de facto standard for initial exploration and development of DSP algorithms is to use Matlab from The MathWorks. The M language used by Matlab is incredible powerful and concise; for example, a Fast Fourier Transform (FFT) function can be invoked using the statement:

y = fft(x);
The problem arises when you wish to convert the floatingpoint representations of the algorithms into their fixedpoint counterparts so as to actually implement your design in the real world. Matlab does provide some aid toward performing this quantization, but it's somewhat limited. Even worst, the native simulation engine in Matlab — which is optimized for vector computations and floatingpoint mathematical operations — slows down significantly in the case of fixedpoint representations in which each operation is "wrapped" with checks for overflow, underflow, rounding, and so forth.
For example, the simulation that takes 10 minutes with a floatingpoint representation may slow down by orders of magnitude and take a day or more when being performed on the design's fixedpoint counterpart. For this reason, it is common practice to leave the Matlab domain as soon as the initial algorithmic exploration has been performed on the floatingpoint representations (Figure 1).
Figure 1 — Traditional DSP design flows
This involves multiple handtranslations: from Matlab floatingpoint to floatingpoint C, from floatingpoint C to fixedpoint C, and — in the case of an FPGA or ASIC implementation — from fixedpoint C to RTL. Not surprisingly, performing these translations is timeconsuming and prone to error. But the biggest problem with this scenario is that Matlab's sophisticated visualization and analysis facilities, such as plotting and statistics, are not available when they are needed most, which is to evaluate the quality of the floatingpoint to fixedpoint conversion.
The solution is to streamline the flow by moving the fixedpoint conversion back into the Matlab environment as illustrated in Figure 2.
Figure 2 — Streamlined DSP design flow
In order to achieve this, Catalytic Inc. has developed a suite of tools and utilities, including a fixedpoint library, an interactive quantization and analysis tool, and a Matlab simulation accelerator that dramatically increases the speed of fixedpoint simulations.
The fixedpoint library provides bitaccurate fixedpoint functions for use in the Matlab environment. The results from these functions are bitidentical to the operations executed on typical fixedpoint DSP hardware. This library supports signed and unsigned operands, complex and real numbers, and commonlyused saturation and rounding modes.
The interactive quantization and analysis tool offers the ability to browse through hierarchical Matlab source code; to assign fixedpoint values to signals and have those values automatically propagate throughout the design (insofar as such propagation can be meaningfully inferred); and to easily view and modify the fixedpoint characteristics of every variable within a function.
The simulation acceleration engine discussed above dramatically accelerates fixedpoint simulations. For example, a floatingpoint simulation that takes 10 minutes in Matlab will now take only 15 minutes in the fixedpoint domain using Catalytic's simulation accelerator (as opposed to taking more than a day in the fixedpoint domain when using Matlab's native simulation environment).
This new flow allows developers to take full advantage of Matlab's familiar environment and its sophisticated analysis and visualization capabilities in both the floatingpoint and fixedpoint domains. Once the quantization has been proven, developers can migrate the design from its fixedpoint Matlab representation into its fixedpoint C counterpart with a high level of confidence that the fixedpoint implementation is correct. This significantly reduces the overall implementation time associated with a design, thereby reducing costs and engineering resources and improving timetomarket.
Quite apart from anything else, the folks I've met at Catalytic have been jolly nice, so I have no hesitation in awarding them an official "Cool Beans" from me. Until next time, have a good one!
Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in hightech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and coauthor of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.