Archives

You are currently viewing archive for January 2011
Category: General
Posted by: afeldstein

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.

Category:
Email Productivity

Today is the start of the 4th
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


Category: General
Posted by: afeldstein
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.