Off Topic
        Mostly just a place for documenting some of my random acts of engineering.
                        Every day, learn how to do something
you didn't know how to do yesterday.

Creating an arbitrary/custom distribution for constraints for constrained random testing
So there you are working diligently away doing your ASIC Verification Engineer thing and writing complicated constraints and there are no cases of corners out of your reach and your boss says, "OK smartypants, let's see you make a random distribution like this," and then your boss scribble some arbitrary curve like the one on the left. So what do you do?

I've got a script for that.
Click on the scribble for an explanation or take the shortcut to EDA playground:    

Basic UVM testbench for a Stream Processor Single page high-level view:

This is a from-scratch UVM testbench for testing stream processor type components. I have several projects more suited to custom stream processing and/or parallel processing than general purpose CPU computing, and this testbench is the basis for verifying those hardware components.
This testbench comes with a simple "Hello world" Detector DUT. The DUT calculates the correlation coefficient of substrings v.s. the reference string "Hello world". The testbench uses virtual hierarchical sequences, constrained randomized transactions, a scoreboard that compares out-of-order process completion, and a reference model in C integrated via the DPI. This is a work in progress. The most recent testbenches are on EDAplayground here:
for the single processor unit testbench.

Real-time Bol (Indian vocal percussion) to MIDI converter. Single page high-level view:
Part I: The audio delay box. A small project for a psychoacoustic test of human delay perception.

Systems designed to respond to audio input and generate 'real time' audio output have timing budgets determined by a system with a human in the middle. Research shows that 'real time' means responding in less than 35 msec. Here I test that in a real system I have a home, since the hardware I am developing will run in that environment.

A virtual DSP testbench Single page high-level view:
This small virtual testbench is for testing digital filter designs and other DSP functions.
The VirtualDSPtestbench contains a C-based signal generator whose behavior is selectable from the command line via uvm_set_config_int. One of the functions includes a C-based file read, values from which are brought into a sequence as part of the testbench stimulus. So you can sing into EDA playground and filter it and write it back out to GNUplot or to a wav file. That's why I call it a "virtual" DSP testbench as it's in lieu of having the design in physical hardware. And like a physical bench with test equipment, it's designed so that one can drop in a DSP type DUT with minimal effort and apply a standard array of stimuli to it: impulse, step, square, sinusoid, sinusoid sweep, random, and data streams of your own choosing.
The input stimulus uses signed values, so the design uses signed values as well.

There is a Perl script, since I'm going to need a lot of these multipliers ➞
which turns values like "-0.0014567" into Verilog multiplier components
suitable for use in fixed-point signed arithmetic implementations.
This is just in the beginning stage. The most recent testbench is on EDAplayground here:

Firmware on an embedded DSP56309 for cochlear implant research

This is some assembly language programming of an embedded Motorola DSP56309 I did for the MRC-CBU in Cambridge, UK. The project contains details including an overview of cochlear implants, the experiment in question, and the DSP56309 assembly code itself, with notes. This work supported research eventually published in the Journal of the Association for Research in Otolaryngology (Long, Carlyon, Litovsky and Downs, vol 7, 352-360 [2006]).

Just a layered sequences example Single page high-level view:

Sometimes I do things just to see them work. This is one of those times.

This testbench uses the layered sequence approach to connect a CPU complex (CPU) to a Sensor Control Unit (SCU). Between those two are an interconnect (XBR) and a Peripherial Control Unit (PCU).
The CPU complex speaks AXI to the XBR,
the XBR speaks APB to the PCU,
the PCU speaks RS-232(ish) to the SCU.
Translator sequences replace only the necessary functions in the CPU, XBR, and PCU.

The most recent code is on EDAplayground here:

Fun with the SystemVerilog DPI

This is a testbench for testing testbench components. Really. Verification components need to be verified.
You can make properties and assertions all day long; but if they don't fire, that might mean the design is perfect. But it might also mean that the properties are defective and they are not doing what you expected. You will need to test those properties.
One option is to break the design for each and every one of the assertions you created. If you've ever done that sort of targeted crippling of a design you know how tedious it can be. It can also be quite difficult to orchestrate particular fails by selective breaking. And how do you coordinate that with particular sequences you run?
The testbench shown here contains a sample DPI-C based method for injecting errors in the design solely for the purpose of testing the verification components. Just make a function call to cripple the design in a particular way.
This is a work in progress. The most recent code is on EDAplayground here:


Years ago, in need of some state machines, I wrote a script to generate them. They are, after all, tedious to type and more tedious to test. I think this is not too different in spirit from what Cliff Cummings did with "fsm_perl" (fsm_perl: A Script to Generate RTL Code for State Machines and Synopsys Synthesis Scripts, 1999). But what I have is more compact and has several verification and visualization side benefits.
Since the essence of an FSM is the set, say M, of 5-tuples (Q, Σ, δ, q0, F ), then if that's what you want, why would you ever be typing stuff like this
    case ...
      IDLE : blah blah blah  
Verilog code of FSMs is not the product, merely a means. There are no side benefits of doing all that work in such labor intensive way. And what happened to maintenance? What about assertions? What about code review and inter-group communication? A state machine generator would come in handy.

A UVM Coercion Engine

This is a set of scripts to produce a UVM based mechanism for run-time random distribution weight changing in order to coerce constrained random stimulus to drive a DUT into corners of the design. The verification problems I am concerned with here are those cases where the interaction of independent and loosely-connected FSMs is rare ... rare and difficult to orchestrate even with constrained random stimulus. The Coercion Engine orchestrates these situations.
Tools such as inFact™ from Mentor Graphics, the path tracing tool from nusym (since bought by Synopsys), and tools that perform automatic constraint extraction and run-time modification (see Coverage-directed test generation through automatic constraint extraction, Onur Guzey, Li-C. Wang) perform similar functions. But this is something you can do at home for free.
It will soon be available, in part, on EDAplayground.

Zipf's law

Many, many years ago I read about Zipf's Law and thought it was something I had to see it for myself. I wrote a word sorting/counting program and put gnuplot to work. I've kept the program alive for those occasions where I think of some other text profiling idea I want to try. Such as Recurrence Quantification Analysis, which I'm in the process of doing now.
Never before has counting words been so much fun. In C and Tcl/Wish.

Genetic Algorithm Single page high-level view:

I first learned about Genetic Algorithms (GAs) in May 1989 when I read Simulated Evolution: wherein bugs learn to hunt bacteria by A. K. Dewdney in Scientific American. I wrote a program similar to the one described. I watched dots change their behavior over time. I was hooked. Since then I've written a large number of GAs, mostly just to see them work. The one in this project is written in C++ with the Qt Applications Development Framework.

A LASER chasing Arduinobot

Long ago, when we walked ten miles to school each day and made our own water, you needed lots of equipment to do any home microprocessor projects. That included things like an EPROM burner and a PCB etching tank. Now those were projects. The world has changed since we carved circuit boards out of stone and refined our own copper ore, so I thought I'd see what all this Arduino talk was about. My conclusion? Well, now I have Arduino things all over the house.

DSP tool [Temporarily unavailable]
Google led me to Steven W Smith's The Scientist and Engineer's Guide to Digital Signal Processing online book often enough that I bought a hard copy. I found myself wanting to try things out while I read the book, but since I didn't have a copy of Mathematica, Matlab, or Maple at the time, I wrote a tool to allow me to build DSP experiments quickly. Here is that tool.

Selectomatic [Temporarily unavailable]
I spend a lot of time saving time. It always pays off. Until there is a PDE (Prescient Development Environment) UberMatic Tool plug-in for Eclipse, I will make do with selectomatic, a tool I wrote as a single point interface for all the little things I've seen fit to automate. My EDA engineer's mantra has always been "anything that can be automated should be automated", and that includes automation itself.

Esterel and me
I'm pleased to have had the opportunity to learn the Esterel language using Esterel Studio. At Esterel Technologies I did much of the preliminary work on the Esterel Studio/Synfora PICO Express automatic coupling. I also wrote two whitepapers during my climb up the Esterel Studio learning curve. The papers are here:
I also assisted with the Esterel Verification Methodology Handbook.
Click on the Esterel Studio logo for more of me on Esterel.


Where to get the right me on
("Dan Downs" isn't exactly a unique name).

Contact: OstensiblyMyID you-know-what-symbol-goes-here gmail and-here .