ASIC Emulation

A Million Monkeys

Most have heard of the Infinite Monkey Theorem. I used to restate it during code review meetings as “a million monkeys could eventually code anything, but this code looks like it took three monkeys and three days.” The truth is, a lot of products have been poorly coded and although I am a strong believer in coding practices which optimize quality, there is no replacement for thorough verification.

An infinite number of monkeys may eventually write the complete works of Shakespeare but until it has been thoroughly evaluated as such, no one will ever know. The name  J. K. Rowling is familiar with many but does anyone know the team of editors and publishers who corrected the text, assisted in making it more readable and even identified that it was something of value in the first place?

To all you code writers, get out there and thank your verification teams.


Trick or Treat

It is not yet Halloween but its coming. This week I resurrected an old trick for a client and thought I would share it here as a technical/tutorial contribution instead of my usual rhetoric.

A great deal of engineering is capturing a process so that it can be modified and repeated to achieve a desired result. In electronics development, that generally means a series of invocations of various EDA programs of different sorts and from different vendors. Each of these invocations work on what is referred to as “source code” and create some intermediate representation of that code which is then fed into the next EDA invocation in the process and so on.

Along with the source code is generally a tool specific EDA setup file that specifies how the process should be completed. Typical source code might be Verilog, VHDL, C++, System C, System Verilog, etc. The method for capturing the process might be in a scripting language such as tcsh, bash, perl, python, tcl, etc. All of these languages have multiple methods for procedurally configuring the source code or the scripted process to achieve variations on the result from the same source code.

However, in many cases, the setup files for the actual EDA tools do not support variations in their invocation within the same setup file.

In fact, different setup files is often the expected method for achieving variation. So, the scripting language is often called up to choose from a selection of setup files based on the variation that only the script has the ability to understand. By selecting a setup file consistent with the desired configuration, a modification of how the EDA tool interprets the source code is achieved and its contribution to the variation in results is realized.

This often leads to a number of similar and somewhat redundant setup files that need to be maintained. Generally, the difference between two setup files is less than 50% of the content of the file. It could even be just one or two out of hundreds or thousands of lines of setup information.

This leads to a process maintenance nightmare where one desired change in setup that is common to all of the various setup files requires that they all be modified and verified to validate the process.

The trick to simplify the redundant maintenance of setup files is also simple, use one of the methods built into the source code files listed above. This method is the “text preprocessor.”

Specifically, I use the ‘C’ code preprocessor invoked by the command:
cpp -E -P -D<variationMacro1> -D<variationMacro2> … <setupFile> -o <temporarySetupFile>

This allows the use of all of the ‘C’ preprocessor constructs to be used in the setup file. The scripting language can invoke the ‘C’ preprocessor as shown above and then pass the temporarySetupFile to the EDA tool.

The only issue is when ‘C’ preprocessor constructs conflict with the syntax of the tool setup file. There are several ways to get around this but I find that using the ‘sed’ editor before and/or after “cpp” allows for management of ‘cpp’ sensitive characters like ‘#’, ‘/*’, and ‘//’.

For example replacing ‘#’ with ‘##’ in the setup file before ‘cpp’ and then reversing the replacement after preserves the ‘#’ character that might be needed in the setup file. Replacing ‘//’ with ‘%’ or some other special character keeps ‘cpp’ from interpreting what follows ‘//’ in the setup file as a comment. These edits will not work if the original file has ‘##’ or ‘%’ characters that should be preserved but I have found that by understanding the syntax of the setup file and the syntax of ‘cpp’ it is generally not difficult to work around any conflicts by using some innocuous character substitution. And if  ‘cpp’ does not meet your needs have a look at ‘m4’. I have never had to go there but if you do and you can then maybe you can write the next tutorial.

This trick can be used in more processes than just EDA development. It can be used in any textual based setup, source code, template, etc. to create customized variations based on  ‘cpp’ constructs.

So, there is the treat.

Eating an Elephant

Everyone knows how to eat an elephant.

Turns out you can eat a whale, a cow, or a chicken the same way and you don’t even have to know which animal it is.

Consulting is an interesting business, at least mine has been.

Sometimes you get to walk up to a clean whiteboard, capture the project goals and help a company design a whole new product. Maybe that’s rare for others, but I enjoyed that type of work all of my employed career and even a couple of times since beginning consulting.

At times, consulting work presents a problem that is in the middle or end of the development cycle and as a consultant you don’t necessarily get the opportunity to influence, or even fully appreciate the big picture. Often, to be efficient, a consultant must identify only as much of the context of the problem as to allow for the solution that the client has requested. In these scenarios the successful consultant needs to be able to quickly understand the environment and design practices of the client, identify the discrepancies, and propose or implement an improvement. More often than not, the challenge of the task is not the solution, but correctly identifying the accurate and optimum scope of the problem.

Lately, I have been providing assistance in ASIC emulation, also called rapid prototyping. In these cases, the actual product is generally near the end of its development cycle. It is generally a large, complex system with multiple processor cores, interfaces, memory systems, etc. There is generally firmware and hardware involved and an elaborate hardware/firmware/software design flow and integration. The focus on this type of assignment is rapidity. It would be impossible to be cost effective and try to understand the entire scope of the project.  So the consultant must quickly learn the environment, the design flow and only enough of the product details sufficient to assist in the process improvement as assigned.

His best tool is experience, which allows him the ability to quickly recognize and adapt to variations in process. For example, most ASIC design teams use version control. Amd. most currently use SVN, yet they all use SVN differently to achieve similar goals. An experienced consultant knows the goals, recognizes SVN, or its variant, or other RC methods and quickly understands and adapts to the methods and variations used by the client. The same is true for design flow scripting, their suite of EDA tools and even the organization of the clients design resources and systems network.

Consultants don’t always get to eat the whole animal and may not even know what kind of animal it is. He just does his part in taking bites and a good one takes bigger bites.