2011-10-10: Keeps Me Honest
In my study of Caml, I'm still reading a chapter on Imperative Aspects. Specifically, I'm in a section called "Modifiable Data Structures".
To become familiar with lex and yacc, I'm still reading a chapter on Lexical Analysis. Specifically, I'm in a section called "From Regular Expressions to Automata".
If this sounds similar to my last status on FNF-to-JHDL translation, you're right. In fact, since 2011-07-24, there have been only 13 days on which I did any of this reading for the translation project! That's one of the things I like about blogging. It keeps me honest. When it's time to blog, I blog, even if it embarrasses me (aversive stimulus). Let this be a positive punishment (i.e. one that decreases the likelihood of me letting up on the project).
To become familiar with lex and yacc, I'm still reading a chapter on Lexical Analysis. Specifically, I'm in a section called "From Regular Expressions to Automata".
If this sounds similar to my last status on FNF-to-JHDL translation, you're right. In fact, since 2011-07-24, there have been only 13 days on which I did any of this reading for the translation project! That's one of the things I like about blogging. It keeps me honest. When it's time to blog, I blog, even if it embarrasses me (aversive stimulus). Let this be a positive punishment (i.e. one that decreases the likelihood of me letting up on the project).
2011-08-28: Mostly Dijkstra, But a Peek at FSS
In my last blog item about the FSS project, I explained why I'm reading Edsger W. Dijkstra's "A Discipline of Programming". Most of my FSS time continues to be consumed by that, but in preparation for a June job interview for an Application Development position at Denim Group, I wrapped my mind around Java a little bit by revisiting FSS proper for a few days. It wasn't enough time to make a lot of progress on the project, but it was nice to take a peek. I look forward to putting Dijkstra behind me so I can jump back into FSS with both feet.
This error message comes from a SPARC-V9 Standard Reference Model memory access.
At this point in the development of FSS, there is no reason for the reference model to perform a byte-wide access; the reference model should perform only word-wide accesses (i.e. instruction fetches). The access is byte-wide because
returns 0. There is no longer a source for that wire (reference model doesn't deal with wires; it is JHDL-independent), so 0 is just a default value.
The reference model should do absolutely nothing until reset. I run some cycles in the DUV before reset just to make a mess of things, but correct behavior is undefined for this phase of simulation, so there is nothing for the reference model to model.
When the reference model does become active, everything it does should be in a separate thread.
In the FullChipTestBench class, I removed the entire block of code around the reference model's byte-wide memory access. This code appeared in the clock method. In fact, I want to avoid doing anything related to the reference model in the clock method. The reference model is to be clock-ignorant.
Rather than describe and justify every change in my notes, I just went on to make several according to the above strategy.
But except for those few days in June (perhaps a week), my FSS time was dominated by Dijkstra, where I have reached Chapter 20. The good news is that the FSS project is now getting the largest share of my Cosmic Horizon time allocation (at the expense of the Verilog-to-JHDL translation project). On the other hand, total Cosmic Horizon time is down since February due to an intensified job search.
...
starting simulation
Byte memory read still needs to be implemented.
[2] Exit 1
java -d64 -cp classes:JHDL.jar:axis2-adb-1.2.jar:derby.jar:
infovis.jar ...
fonzie%
This error message comes from a SPARC-V9 Standard Reference Model memory access.
At this point in the development of FSS, there is no reason for the reference model to perform a byte-wide access; the reference model should perform only word-wide accesses (i.e. instruction fetches). The access is byte-wide because
referenceProcessor2ReferenceMemoryWidth.get( this )
returns 0. There is no longer a source for that wire (reference model doesn't deal with wires; it is JHDL-independent), so 0 is just a default value.
The reference model should do absolutely nothing until reset. I run some cycles in the DUV before reset just to make a mess of things, but correct behavior is undefined for this phase of simulation, so there is nothing for the reference model to model.
When the reference model does become active, everything it does should be in a separate thread.
In the FullChipTestBench class, I removed the entire block of code around the reference model's byte-wide memory access. This code appeared in the clock method. In fact, I want to avoid doing anything related to the reference model in the clock method. The reference model is to be clock-ignorant.
Rather than describe and justify every change in my notes, I just went on to make several according to the above strategy.
But except for those few days in June (perhaps a week), my FSS time was dominated by Dijkstra, where I have reached Chapter 20. The good news is that the FSS project is now getting the largest share of my Cosmic Horizon time allocation (at the expense of the Verilog-to-JHDL translation project). On the other hand, total Cosmic Horizon time is down since February due to an intensified job search.
2011-07-24: Do something about it!
My status with respect to FNF-to-JHDL translation remains as described at the end of my last blog item on the topic. I want you to go to that blog item now, scroll to the bottom and read the paragraph containing the phrase, "do something about it!".
In my study of Caml, I have read chapters on Expressions, Data Structures and Semantics. I'm currently reading one on Imperative Aspects.
To become familiar with lex and yacc, I have read chapters: Introduction and A Simple Syntax-Directed Translator. I'm currently reading one on Lexical Analysis.
In my study of Caml, I have read chapters on Expressions, Data Structures and Semantics. I'm currently reading one on Imperative Aspects.
To become familiar with lex and yacc, I have read chapters: Introduction and A Simple Syntax-Directed Translator. I'm currently reading one on Lexical Analysis.
2011-06-15: Illiteracy in Engineering
Take a look at the Computer & Software Engineering Professionals group on LinkedIn. The following sentence appears in the group description: "Your cordially invited to join a new group for degreed computer engineers and software engineers!" The word "your" does not fit here. I was considering joining Computer & Software Engineering Professionals, so I pointed out the error to the group owner, Jack Ganter.
You're going to love his response.
"... NO I WILL NOT CORRECT the page ..."
Jack Ganter received from SUNY Buffalo a Bachelor of Arts degree in 1993.
Grammar Guru: Top 10 Common Writing Mistakes
You're going to love his response.
"... NO I WILL NOT CORRECT the page ..."
Jack Ganter received from SUNY Buffalo a Bachelor of Arts degree in 1993.
Grammar Guru: Top 10 Common Writing Mistakes
2011-05-19: An Aside
In pursuit of the meaning of "Set of correctness properties" with respect to the SPARC-V9 Standard Reference Model, I continue to read Edsger W. Dijkstra's "A Discipline of Programming", by this time having reached Chapter 13. The FSS project is slowed by three things: its currently small percentage of the Cosmic Horizon time allocation, my intensified job search and the reading of this book. I'm not at all convinced of the relevance of the book to the project. It seems to me that the set of correctness properties is nothing more than "The SPARC Architecture Manual", Version 9, and that the reference model is to be merely a representation of that. I borrowed the Dijkstra book from the University of Texas libraries. I'll stop this silliness when they want the book back, when I find what I'm looking for or when I finish reading the whole book. I keep hoping UT will recall the book.
As I always do to write this blog, I read my notes since the last blog item on the same topic. This time, they constitute an aside. While straightening my desk, I came across various papers I had written or read and wanted to archive them. I wrote some notes to help me find the papers later if necessary, and at the same time wrote about my interest in those papers.
First, there was "Fast Binary Multiplier Design", a lab report I wrote in 1998 during my undergraduate studies at Rochester Institute of Technology. The course was Digital Systems Design for Computer Engineers. The ideas I developed during completion of this lab form the basis for the integer multiplier (MULX) in the Sputnik microprocessor.
A magazine article led to several other papers found on my desk. Keep in mind that I read these papers a few years ago; the same can be said of my logic below. I'm just now documenting that thought process.
Allon Adir, Eli Almog, Laurent Fournier, Eitan Marcus, Michal Rimon, Michael Vinov, Avi Ziv, "Genesys-Pro: Innovations in Test Program Generation for Functional Processor Verification," IEEE Design and Test of Computers, vol. 21, no. 2, pp. 84-93, Mar./Apr. 2004
I wasn't interested in a generic solution. Mine was to be applicable only to SPARC-V9, so I followed reference 6 to:
Aharon, A.; Bar-David, A.; Dorfman, B.; Gofman, E.; Leibowitz, M.; Schwartzburd, V.; , "Verification of the IBM RISC System/6000 by a dynamic biased pseudo-random test program generator," IBM Systems Journal , vol.30, no.4, pp.527-538, 1991
I had decided on the generation of multiple instruction test programs because I wanted to treat the DUV as a black box. That meant that operands would enter the microprocessor from outside (i.e. loaded from memory) and results would emerge from the microprocessor (i.e. stored to memory). This implies a sequence of instructions. Furthermore, my approach is static, since the test programs are assembled first and executed afterwards. There is no relation between the intermediate machine states during execution of the test program and the test generation process, because intermediate machine states are generally not observable in a black box. This led me to references 8 and 10. I ignored reference 8, "A VLSI Design Verification Strategy", because the title suggests an approach not specific to microprocessors. I was left with reference 10:
Bellon, C.; Liothin, A.; Sadier, S.; Saucier, G.; Velazco, R.; Grillot, F.; Issenman, M.; , "Automatic Generation of Microprocessor Test Programs," Design Automation, 1982. 19th Conference on , vol., no., pp. 566- 573, 14-16 June 1982
First, it is natural for the microprocessor to be the master of the execution of its test program. As for the potential for address conflicts, I'll cross that bridge when I come to it. I definitely want to allow the microprocessor to write to memory, again because this is a more natural approach. So I was led to reference [ABR 81]:
J. A. Abraham and K. P. Parker, "Practical microprocessor testing: Open and closed loop approaches," in Proc. IEEE COMPCON, Spring 1981, pp. 308-311.
As I always do to write this blog, I read my notes since the last blog item on the same topic. This time, they constitute an aside. While straightening my desk, I came across various papers I had written or read and wanted to archive them. I wrote some notes to help me find the papers later if necessary, and at the same time wrote about my interest in those papers.
First, there was "Fast Binary Multiplier Design", a lab report I wrote in 1998 during my undergraduate studies at Rochester Institute of Technology. The course was Digital Systems Design for Computer Engineers. The ideas I developed during completion of this lab form the basis for the integer multiplier (MULX) in the Sputnik microprocessor.
A magazine article led to several other papers found on my desk. Keep in mind that I read these papers a few years ago; the same can be said of my logic below. I'm just now documenting that thought process.
Allon Adir, Eli Almog, Laurent Fournier, Eitan Marcus, Michal Rimon, Michael Vinov, Avi Ziv, "Genesys-Pro: Innovations in Test Program Generation for Functional Processor Verification," IEEE Design and Test of Computers, vol. 21, no. 2, pp. 84-93, Mar./Apr. 2004
The first generation of test generators at IBM was developed in the mid-1980s. These generators incorporated a biased, pseudorandom, dynamic generation scheme.6 The need for a generic solution, applicable to any architecture, led to the development of a model-based test generation scheme ...
I wasn't interested in a generic solution. Mine was to be applicable only to SPARC-V9, so I followed reference 6 to:
Aharon, A.; Bar-David, A.; Dorfman, B.; Gofman, E.; Leibowitz, M.; Schwartzburd, V.; , "Verification of the IBM RISC System/6000 by a dynamic biased pseudo-random test program generator," IBM Systems Journal , vol.30, no.4, pp.527-538, 1991
For some designs, such as a floating-point unit, the main part of the verification task can be fulfilled by programs that consist of only one instruction. The generation of such programs is relatively straightforward: The generator (or the user) selects an instruction and the required controls, generates the operands randomly (or provides them), and then invokes a reference model of the design to get the expected results. The generation of multiple instruction test programs is much more complicated ... There are approaches8,10 that present a way to generate multi-instruction test programs ... Such an approach to test generation may be classified as a static one, since the test programs are assembled first and executed afterwards. There is no relation between the intermediate machine states during execution of the test program and the test generation process. In [RISC System/6000] RTPG the test generation is interleaved with the execution of every instruction as soon as it is generated ...
I had decided on the generation of multiple instruction test programs because I wanted to treat the DUV as a black box. That meant that operands would enter the microprocessor from outside (i.e. loaded from memory) and results would emerge from the microprocessor (i.e. stored to memory). This implies a sequence of instructions. Furthermore, my approach is static, since the test programs are assembled first and executed afterwards. There is no relation between the intermediate machine states during execution of the test program and the test generation process, because intermediate machine states are generally not observable in a black box. This led me to references 8 and 10. I ignored reference 8, "A VLSI Design Verification Strategy", because the title suggests an approach not specific to microprocessors. I was left with reference 10:
Bellon, C.; Liothin, A.; Sadier, S.; Saucier, G.; Velazco, R.; Grillot, F.; Issenman, M.; , "Automatic Generation of Microprocessor Test Programs," Design Automation, 1982. 19th Conference on , vol., no., pp. 566- 573, 14-16 June 1982
One can choose a classical test environment, in which the test equipment imposes its timing, sends the inputs in the right order to the tested circuit and observes the outputs ... Contrary to this, the tested microprocessor can be the "master" of the execution of its test program ; i.e., once the memory is loaded with the test program and operands, the microprocessor is restarted and executes the test program in the "normal functioning" mode ... But this approach involves a difficult memory space management problem : test program, test operands and test results must be stored in memory, at the actual address given in the test program ; test addresses can conflict, due to the somewhat scattered values imposed by the test. Such an environment is proposed in [ABR 81] (so-called closed loop environment). We had used such an environment in a previous phase of this study ... Test experiments on faulty microprocessors have proven the efficiency of the behavioral test approach ... We have chosen an intermediate approach, in which the memory management is simplified : the microprocessor reads the memory normally, but can not write in it ...
First, it is natural for the microprocessor to be the master of the execution of its test program. As for the potential for address conflicts, I'll cross that bridge when I come to it. I definitely want to allow the microprocessor to write to memory, again because this is a more natural approach. So I was led to reference [ABR 81]:
J. A. Abraham and K. P. Parker, "Practical microprocessor testing: Open and closed loop approaches," in Proc. IEEE COMPCON, Spring 1981, pp. 308-311.
On Cosmic Horizon's Verilog-to-JHDL translation project (using OpenSPARC T1 as an example of Verilog), we have achieved correct latch synthesis on Icarus Verilog's v0_8-branch. Get this Verilog compiler via anonymous Git cloning.
When Icarus Verilog moved from version 0.8 to version 0.9, the developers broke synthesis. Improvements to synthesis continue to be made on v0_8-branch. Still, there has been no commitment from Steve Williams to bring synthesis forward into the current release. That's why I say v0_8-branch is superior, that's why I promote use of that branch, and that's why I encourage all users of Icarus Verilog synthesis to make their voices heard.
Anyway, why should I care about synthesis? I'm a front-end microprocessor designer, an architecture guy. Why have I contributed to Icarus Verilog synthesis? I've answered these questions before, but I don't do it often enough. I tend to just jump into details of the project in these blog items.
Actually, there are two active Cosmic Horizon projects. The other one is FSS, a SPARC verification environment. You bring us a SPARC microprocessor design and FSS looks for bugs in its SPARC compliance. If your design is written in JHDL, then you're ready for FSS. If it's written in Verilog, then you'll need a Verilog-to-JHDL translator, the subject of this blog item. (In Alan Feldstein's Blog, I generally alternate between the two projects.)
What does Verilog-to-JHDL translation have to do with synthesis and why have these particular tools been chosen? Translating from Verilog to JHDL can be achieved through an intermediate language called Free Netlist Format (FNF), a technology-neutral target. When Icarus Verilog generates FNF, that involves synthesis. It also involves the FNF generator for Icarus (packaged with Confluence). I chose these particular tools because Tom Hawkins and others working with him on Confluence had already employed/developed these tools to form a path from Verilog to JHDL, and I knew of no other pre-existing path. The challenge for me has been to take OpenSPARC T1 down that path. The tool chain needed (and still needs some) work to be able to support that. One of the issues was support for the latches in OpenSPARC T1.
So if you have a SPARC microprocessor design written in Verilog and would benefit from knowing about bugs in its SPARC compliance, then I want to make you a user of Icarus Verilog synthesis.
Now let me tell you how we achieved correct latch synthesis on Icarus Verilog's v0_8-branch, and what I've been working on since.
When Icarus Verilog moved from version 0.8 to version 0.9, the developers broke synthesis. Improvements to synthesis continue to be made on v0_8-branch. Still, there has been no commitment from Steve Williams to bring synthesis forward into the current release. That's why I say v0_8-branch is superior, that's why I promote use of that branch, and that's why I encourage all users of Icarus Verilog synthesis to make their voices heard.
Anyway, why should I care about synthesis? I'm a front-end microprocessor designer, an architecture guy. Why have I contributed to Icarus Verilog synthesis? I've answered these questions before, but I don't do it often enough. I tend to just jump into details of the project in these blog items.
Actually, there are two active Cosmic Horizon projects. The other one is FSS, a SPARC verification environment. You bring us a SPARC microprocessor design and FSS looks for bugs in its SPARC compliance. If your design is written in JHDL, then you're ready for FSS. If it's written in Verilog, then you'll need a Verilog-to-JHDL translator, the subject of this blog item. (In Alan Feldstein's Blog, I generally alternate between the two projects.)
What does Verilog-to-JHDL translation have to do with synthesis and why have these particular tools been chosen? Translating from Verilog to JHDL can be achieved through an intermediate language called Free Netlist Format (FNF), a technology-neutral target. When Icarus Verilog generates FNF, that involves synthesis. It also involves the FNF generator for Icarus (packaged with Confluence). I chose these particular tools because Tom Hawkins and others working with him on Confluence had already employed/developed these tools to form a path from Verilog to JHDL, and I knew of no other pre-existing path. The challenge for me has been to take OpenSPARC T1 down that path. The tool chain needed (and still needs some) work to be able to support that. One of the issues was support for the latches in OpenSPARC T1.
So if you have a SPARC microprocessor design written in Verilog and would benefit from knowing about bugs in its SPARC compliance, then I want to make you a user of Icarus Verilog synthesis.
Now let me tell you how we achieved correct latch synthesis on Icarus Verilog's v0_8-branch, and what I've been working on since.
2011-01-24: Clean Out Your Inbox Week
Take Inbox Action - Clean Out Your
Inbox Week - Day 1
Brief article starting the
international Clean Out Your Inbox Week on why we should strive to
have a perennially empty inbox.
international Clean Out Your Inbox Week on why we should strive to
have a perennially empty inbox.
Category:
Email Productivity
Email Productivity
Today is the start of the 4th
annual international Clean Out Your Inbox Week. Why should you want
a clean inbox?
annual international Clean Out Your Inbox Week. Why should you want
a clean inbox?
E-mail isn't going anywhere. And the number of e-mail messages we
receive will only grow. It is a real challenge to avoid being
distracted by the urge to view or work on new e-mails, rather than
working on truly important matters. Further, leaving messages in
your inbox to remind you to complete tasks is akin to having that
many items strewn over your desk in no organized fashion -- no
wonder people stress out when they open their inboxes first thing
in the morning!
An empty inbox is the result of managing e-mail well. It doesn't
mean that you've worked every message, but it does mean that you
have sorted every message into a folder that allows you to retrieve
it when the time comes. By sorting e-mail to an "action folder" and
setting a reminder for when you plan to return to it, you will go a
long way towards managing your inbox, rather than having it manage
you.
Today's Tip: Make action folders. This could be as simple as two
folders titled Action A and Action B. Every time there is an e-mail
that requires further attention, sort them into folders by the
importance or urgency of action.
Copyright, Marsha D. Egan, CPCU, PCC, CEO of The Egan Group,
Inc.,
http://inboxdetox.com . Marsha is a certified executive coach
and professional speaker, specializing in leadership development
and workplace productivity. You can reach her at marsha@
marshaegan.com
2011-01-13: Set of Correctness Properties
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.
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.
2010-12-06: Will it Go Round in Circles?
On 2010-08-09 I wrote, "I seem to be going in circles!"
It's always interesting to read notes documenting a thought process before a problem is solved. Phil Connors eventually broke the time loop in Groundhog Day. I stopped going in circles too.
It's always interesting to read notes documenting a thought process before a problem is solved. Phil Connors eventually broke the time loop in Groundhog Day. I stopped going in circles too.
