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 co-design and co-verification.
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:
This level of abstraction allows large systems to be captured using relatively few lines of code. Matlab can simulate these representations which are initially described in the floating-point domain extremely quickly and efficiently, and it provides incredibly sophisticated visualization and analysis facilities.
The problem arises when you wish to convert the floating-point representations of the algorithms into their fixed-point 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 floating-point mathematical operations slows down significantly in the case of fixed-point 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 floating-point representation may slow down by orders of magnitude and take a day or more when being performed on the design's fixed-point 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 floating-point representations (Figure 1).
Figure 1 Traditional DSP design flows
This involves multiple hand-translations: from Matlab floating-point to floating-point C, from floating-point C to fixed-point C, and in the case of an FPGA or ASIC implementation from fixed-point C to RTL. Not surprisingly, performing these translations is time-consuming 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 floating-point to fixed-point conversion.
The solution is to streamline the flow by moving the fixed-point 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 fixed-point library, an interactive quantization and analysis tool, and a Matlab simulation accelerator that dramatically increases the speed of fixed-point simulations.
The fixed-point library provides bit-accurate fixed-point functions for use in the Matlab environment. The results from these functions are bit-identical to the operations executed on typical fixed-point DSP hardware. This library supports signed and unsigned operands, complex and real numbers, and commonly-used saturation and rounding modes.
The interactive quantization and analysis tool offers the ability to browse through hierarchical Matlab source code; to assign fixed-point 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 fixed-point characteristics of every variable within a function.
The simulation acceleration engine discussed above dramatically accelerates fixed-point simulations. For example, a floating-point simulation that takes 10 minutes in Matlab will now take only 15 minutes in the fixed-point domain using Catalytic's simulation accelerator (as opposed to taking more than a day in the fixed-point 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 floating-point and fixed-point domains. Once the quantization has been proven, developers can migrate the design from its fixed-point Matlab representation into its fixed-point C counterpart with a high level of confidence that the fixed-point implementation is correct. This significantly reduces the overall implementation time associated with a design, thereby reducing costs and engineering resources and improving time-to-market.
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 high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author 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.