It's one thing to relax the requirement that the SPARC-V9 Standard Reference Model be written as behavioral JHDL. It's another to actually not write it in behavioral JHDL (or any style of JHDL for that matter).

All Sputnik memory access is doubleword, but the reference model ...

The UML presented last time is not the final word on how the pieces will fit together. Getting this sorted out is exactly what I'm working on now and there are aspects of the communication diagram that certainly will change. For example, I don't expect the test bench to tell the reference model to execute an instruction. Rather, the reference model will be much more autonomous, subject to throttle control (i.e. it will have a peek at the instruction fetch scoreboard to know when it should wait).

Since my last blog item about this FSS project, I traveled to California to interview with MIPS Technologies in October. They're not going to call, but you might.

When behavioral modeling in JHDL (which may not be the best option for the SPARC-V9 Standard Reference Model), synchronous cells require a clock method while combinational cells require a propagate method. But I'm not allowed to simultaneously disable the clock and propagate method. Having already removed the clock method in order to make the reference model clock-ignorant, let's take a closer look at the propagate method.

It's normally used to simply compute the output as a function of the inputs. It "must implement any behavior that is combinatorial". Furthermore, "a purely asynchronous circuit need only implement the propagate method" (i.e. it shouldn't also implement the clock method). Technically, the reference model is asynchronous because it is clock-ignorant.

I have observed that the propagate methods are called by
byucc.jhdl.base.PropagateSchedule.propagateAll

That means that the propagate method conflicts with my intended use for the java.lang.Runnable.run method, so I decided to remove the SPARC-V9 Standard Reference Model's dependence on JHDL entirely.

A snapshot of progress on 2010-11-20 shows the following error message after starting simulation: "Byte memory read still needs to be implemented." All Sputnik memory access is doubleword, but the reference model ...

Within a couple of days of seeing that error message, I was on my way to California again, this time for a funeral (and I got violently ill while I was there).

Since then, I have paid some attention to an item about the reference model in the Software Requirements Specification: "Set of correctness properties". Even though I wrote it (or borrowed the idea from elsewhere), I want to make sure I understand what that phrase means to other people, so I'm searching for the origin of the concept. In "Characterizing Correctness Properties of Parallel Programs", E. Allen Emerson and Edmund M. Clarke referenced Edsger W. Dijkstra's "A Discipline of Programming", explaining that "Dijkstra proposes the use of weakest precondition predicate transformers to describe correctness properties." So on 2010-12-03 I borrowed "A Discipline of Programming" from the University of Texas Libraries. Since the book has no index and I can't determine from the table of contents which part I should read, I started at the beginning. I suspect that Dijkstra in 1976 did not originate the concept of correctness properties. And he wrote something disturbing in the preface: "For the absence of a bibliography I offer neither explanation nor apology." Anyway, I'm on Chapter 7 now.

This is not huge progress on development of the SPARC-V9 Standard Reference Model. The truth is that the other project has been getting the larger share of my time in recent months. But the pendulum will swing the other way before long. Honestly, I'm anxious to get back to this with a greater effort. It's interesting stuff.