I'm always amazed by the number of things I don't know. Of course, I typically don't even know that there's something I don't know until it suddenly leaps up and bites me when (and where) I least expect it.
Sometimes there are things that I haven't really spent a lot of time thinking about, but if someone were to ask me my opinion (which I'm always happy to give, irrespective of whether or not I know what I'm waffling on about) I'd have said something like "well I'd assume it works this way." But later, when I come to chat to the folks who actually do know what they are talking about, I find that I've been climbing up a gum tree without a paddle (I never met a metaphor I didn't like).
Pre-compilation for simulation (that was then)
As a recent example, Axis Systems recently announced that they now support pre-compilation for emulation. This means that they have the ability to pre-compile blocks of HDL code, and then link and load the ensuing object files together at emulation time. Now if you'd asked me about this only a week or so ago, I'd have guessed that anyone with an emulator did this as a matter of course, but as usual things are never as simple as they seem.
I vaguely seem to recall that when I first started to play with software logic simulation at the beginning of the 1980s, one had to compile the entire design at one time. This quickly became a problem as designs increased in size, as they are wont to do. So it wasn't long before that ability to pre-compile individual blocks came along. This allowed us to pre-compile most of the design in advance. Later we needed to compile only the block(s) we were currently working on, and then we could quickly link, load, and simulate all of the blocks together.
At that time, each of the blocks were pretty much treated as "white boxes," which meant that you could monitor activity on any signals internal to the block so long as you knew the names of those signals (and even if you didn't, you could use a wildcard '*' character to look at all of the signals).
However, this was something of a problem in the case of IP blocks like microprocessors (yes, we even had these back in the mists of time), because their owners didn't want everyone to know everything that was happening inside the core. So the next thing that came along was the ability to pre-compile blocks and encrypt them at the same time.
Unfortunately, we were a little too enthusiastic the first time around, because the encrypted blocks immediately became "black boxes" in that you couldn't monitor any of their internal signals. This was something of a pain, because the fact that a microprocessor contains entities like an "Accumulator" and a "Status Register" really isn't too much of a secret, and monitoring these little rascals can be jolly useful when it comes to debugging a design.
Thus, sometime later things became a little better thought out. The result was "gray box" capability, in that it was possible to specify a subset of internal registers and signals that would be visible/monitorable, even in an encrypted pre-compiled block. But we digress ...
Pre-compilation for emulation (this is now)
Based on my experiences with simulation, I would have assumed that all of today's emulators supported the concepts of pre-compilation, encryption, and white-black-gray box visibility in much the same way, so I was somewhat surprised to find that this is not the case.
It seems that pre-compilation of blocks is a non-trivial task when it comes to partitioning them across the hardware devices (processor arrays or FPGAs) in an emulator. Apparently, the problem is compounded by the fact that the majority of today's emulators use a cycle-based algorithm, in which case logic may end up being "mangled together" across block boundaries.
This is obviously something of a pain, because it means that if you make a minor modification to a small block in a 10M-gate design, you are going to have to re-compile the design in its entirety, which could take several hours. (When folks are selling you an emulator, they typically gloss over this compilation time and instead dazzle you with exciting tales of the emulation speeds you are about to experience compared to software simulation).
In addition to these excruciatingly painful compilation times, there are a number of other problems with this scenario. First of all, as much as 75% to 90% of a modern design appears in the form of third-party IP, which you are never going to change anyway. Even worse, some IP vendors (like those of microprocessor cores) are more than a little reluctant to supply you with the source RTL/HDL for their baby. Instead, they force you to link to a physical device or a compiled C/C++ model (where the latter is less accurate than its RTL/HDL equivalent).
In the case of Axis emulators, however, these little rapscallions are based on an event-driven approach, which facilitated the development of the Axis pre-compilation capability. This means that you can pre-compile any blocks you don't intend to change, and also third-party IP vendors can deliver pre-compiled and encrypted versions of their cores in the form of black or gray boxes.
The result is massively increased efficiency in terms of compilation time (because you need only compile the block you just "tweaked") combined with third party IP protection, where the latter now means that you have access to a higher quality pre-compiled RTL/HDL-level model.
When you are in the process of designing something and you make a small change to the design, it's incredibly frustrating to have to sit around for hours waiting for the thing to compile so that you can slam some test vectors through it to see whether or not your modification was efficacious. This is especially true if you have to keep on tweaking things over and over (and over) again. So the fact that the Axis pre-compilation capability can replace a 2-hour compilation with one that takes only a few minutes (or seconds depending on the size of the block that's been modified) has to be worth 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.