My contract in Boston had been extended again through 2008-09-30, but on 2008-06-23 I learned that, for business reasons, it would end much sooner. It then ended 2008-06-27!

I put a lot of energy into that consulting assignment. It was supposed to last three months, but lasted eight. As a result, Cosmic Horizon slowed. But it did not stop. In this blog item, I will discuss recent progress.

Now that I'm free, things will be picking up dramatically. Of course, if someone hires me, Cosmic Horizon will slow again. After all, I have to eat ...

The Software Requirements Specification now allows me to create a phase-based simulator.

My 2007 United States (and Massachusetts) income tax returns are filed, which include details about Cosmic Horizon. Because it is a sole proprietorship, I don't have to share those details with you.

A phase-based waveform view is now committed to CVS, although I was dissatisfied with the display resolution of the Windows laptop I was using while on the road, even for a 100-cycle simulation run (and 100 cycles isn't enough to see product_valid in the Sputnik microprocessor). An enhancement to the waveform viewer would allow the user to zoom in on a time frame of interest (or something like that). I don't want to work on that right now. Besides, now I'm home with a higher resolution display. And my recent debugging has been focused on the beginning of multiplication (i.e. fewer cycles need to be displayed).

I took a look at the changes that have been made to Sputnik so far since the last chip release. These Sputnik chip releases are internal to Cosmic Horizon. They matter for automated verification to distinguish one set of results in the results database from another set. You will be required to define chip releases for your SPARC designs as well. Anyway, the aforementioned Sputnik changes do not warrant a chip release at this time. I expect that there will be more Sputnik modifications before the next automated verification.

A slow-moving project needs reminders.

To remind me of what I was looking at in the waveform viewer (i.e. JHDL wire names and waveforms), I created a mapping back to the signal names in the original integer multiplier state diagram.

To remind me of the operands I was using to stimulate the integer multiplier, I inspected the SPARC executable.

Then I noticed that I was putting too many bits onto a 3-bit state wire, which I had neglected to widen. That is likely to be the major fault I was looking for. I wrote in my notes that I should "consider improving software architecture so that state bus width is a constant maintained in one place." Here, I was talking about the "software" architecture of the Sputnik microprocessor. Is Sputnik hardware or is it software? That depends on our point of view. Another possible place for improvement is in JHDL itself. There, I could range-check values that I'm putting onto wires. The problem with that approach is that it would tend to slow down simulation at the kernel. Not all Cosmic Horizon JHDL users would see this checking as an improvement. A better way would be to offer the JHDL user the ability to configure for checking or not. I'm writing all this down, but I'm not necessarily working on those improvements now. I prefer to drive toward "FSS Version_0-007 will be able to execute MULX." There hasn't been an FSS release since 2008-05-13.

After fixing the major fault that I described above, I noticed failures after product_valid is indicated by the integer multiplier. At this point, such failures are acceptable. It is likely that I haven't designed that part of Sputnik yet. What I really want to see at this point is correct multiplication.

Above, I stated that I had inspected the SPARC executable to remind me of the operands I was using to stimulate the integer multiplier. A reasonable question then is "What is the correct product?". The operands had been randomly chosen with the only constraint that they both be positive. (One must crawl before he can walk.) But it is highly improbable that operands chosen in this way have a correct product that fits in a 64-bit two's complement integer.

Here's a rather brain-dead idea. I'll use a brute force method (a Java application) on my Sun Fire V210 Server back in Austin so that it can work on the problem of random operand generation while I think of a better idea. It wasn't very reasonable to expect that a VPN/ssh connection would stay up long enough to see a result on standard output, so version 2 creates a file when it's done. That way I could check up on the process from time to time via VPN, but I didn't need to remain connected.

One interesting surprise came when I tried to use the Solaris od command on an output file written using ObjectOutputStream.

Primitive data, excluding serializable fields and externalizable data, is written to the ObjectOutputStream in block-data records. A block data record is composed of a header and data. The block data header consists of a marker and the number of bytes to follow the header. Consecutive primitive data writes are merged into one block-data record.

Details may be found in the Java Object Serialization Specification version 6.0 under "Object Output Classes". I avoided the details by writing another Java application to read the output file (i.e. reading and deserializing data from a sequential-access file).

The writing and reading of the output file was just a test. The brute force method would randomly generate pairs of operands, rejecting any that were not both positive. Furthermore, it would reject any that have a correct product that does not fit in a 64-bit two's complement integer. This program ran from 2008-05-06 until 2008-06-29 without producing a result. (I had to terminate it while debugging a computer network problem after I arrived home.)

In the meantime, I sought a compromise solution. I considered constraining the random generation of the second operand. For the full RTPG, I could improve the distribution by alternating between constraining the first operand and constraining the second. I had a hunch that I would not like this distribution either.

A first order approximation of the probability that any random pair of operands constrained as above will produce an acceptable product follows.



On 2008-05-17, I got the idea to generate each operand bit randomly. The low-order 32 bits can each have a 50% probability of being 1. A probability distribution curve can be devised for the high-order 32 bits such that the probability of being 1 becomes 0 at bit 63. I haven't implemented that yet.

Finally, I'm looking at a tape drive for backup of Cosmic Horizon intellectual property. Just before making the purchase, funding in the form of my consulting assignment in Boston dried up. I'm still thinking about it though.