Yes, I was sufficiently recovered from surgery to write SPARC-V9 Standard Reference Model on 2009-06-23. I'm amazed that I was able to do that much that day. Right after that, I came down with a severe cold that put me right back in bed, so June was nearly a complete loss.

Then on 2009-07-08, I started Japanese 2, an accelerated summer course at Austin Community College. That turned my schedule upside down until 2009-08-13. Why am I studying Japanese? I specialize in SPARC-V9 and have developed significant expertise. Fujitsu Limited is a major player in the world of SPARC-V9. They design their SPARC64 microprocessors in Kawasaki, a suburb of Tokyo.

Adding to the squeeze, when Sun's stock price goes up, I spend more time on OpenSPARC, borrowing from the time allocation for FSS. JAVA is up.

That's enough with the excuses. Let me tell you what progress I have been able to make.

As for fully understanding uninitialized memory accesses, I looked at initialization of the address output by Sputnik. Ideally, this should be randomized before Power-On Reset (POR). I used the FSS waveform viewer to examine the signals of interest and quickly found the root cause of one signal's initial zero value to be a call to method byucc.jhdl.Logic.LogicGates.regce_o to instantiate SPARC's program counter. There is currently no way to instantiate a register in JHDL with a specific initial value, for example one that was randomly generated. So I explored the JHDL source code to find out what would be involved in adding this capability.

I was led to
byucc.jhdl.Xilinx.Virtex.fdce_g

I'm not doing anything with Xilinx, but JHDL's default TechMapper leads me here.

byucc.jhdl.Xilinx.Virtex.fdce_g
is a genericized version of a Xilinx primitive (classes with _g appended to their names). It is a generic-width, asynchronously cleared, enabled D-type flip-flop. The width of the cell is automatically determined from the width of the D wire.

In my opinion, modeling attributes and behaviors that real Virtex devices do not possess, should have no place in the byucc.jhdl.Xilinx.Virtex package. Although it would be relatively simple to give byucc.jhdl.Xilinx.Virtex.fdce_g the ability to instantiate a register with a specific pre-reset value, that would be an example of a feature that does not belong in byucc.jhdl.Xilinx.Virtex. Since an appropriate existing subclass of of byucc.jhdl.Logic.TechMapper is not found, proper software architecture dictates that a new subclass be created, one that supports a random initial value in a register and any other features appropriate for functional verification by simulation.

Unfortunately, this is a huge project. So far, I can live without it. Therefore, its priority is low.

Looking at the other signals of interest, I considered the address for a load or a store. Could I randomize both the computed address and the control input to a mux that selects between instruction or data memory? I found that I was already randomizing the control input to the mux by randomizing the control state memory, which is behavioral.

As for the computed address, randomizing that would be achieved by randomizing the adder inputs. These inputs are influenced by three sources: control inputs (already randomized control state memory), immediate data (from external stimulus; irrelevant to this analysis) and the register file. But the register file uses the same construct as the program counter (i.e. regce_o). Therefore, it cannot be randomized without adding capability to JHDL.

The only unexpected addresses appearing in the FSS memory view (the memory view only shows addresses that have been accessed) are 0000000000000000 through 0000000000000007. I then used the FSS waveform viewer to make sure I understood why at least one of those addresses had been accessed, because it wasn't deliberate.

Through cycle 1 phase 1, address 0 is on the bus. This is followed by the bootstrap loader address at cycle 1 phase 2. Briefly, JHDL initializes regce_o to zero. I'm satisfied that address 0 would be read before POR.

However, I'll still need to investigate why the newly created memory initialization monitor didn't flag the read of uninitialized address 0 as an error. I expect that it will be necessary to disable the monitor before POR, but I want to understand why the error wasn't flagged before I prevent the error.

Then I embarked on what I hope will be a software architecture improvement. FSS adheres to the Model-View-Controller (MVC) architectural pattern. Although I had hastily added the memory initialization monitor to the "model" (i.e. in the part of the test bench closest to the design under verification), I think monitors belong in the "view".