Clever Thoughts

I’ve just read an article on memristors in the IEEE spectrum and have to say that this is probably the coolest new development in semiconductors I’ve heard of in a long time. The article ends with

I’m convinced that eventually the memristor will change circuit design in the 21st century as radically as the transistor changed it in the 20th. Don’t forget that the transistor was lounging around as a mainly academic curiosity for a decade until 1956, when a killer app—the hearing aid—brought it into the marketplace. My guess is that the real killer app for memristors will be invented by a curious student who is now just deciding what EE courses to take next year.

and I agree with this statement. The concept is exciting enough to almost wish I were back in school ready to take on this challenge, but only almost, I’m pretty happy sitting way up here in the abstraction level where I can assume that HW exists and focus on firmware, drivers, and other “low level” software. Also the fact that I’m completely unable to follow the math in the article, which is the dumbed down version for a general EE audience, suggests that I probably wouldn’t have done very well, though I might have studied harder.

Semiconductors Memristor

For better or worse I’ve started to become familiar with the OSCI TLM 2.0 standard, and have to ask the question “why has OSCI specified a protocol with out formally defining the state machine that implement the protocol?” I suspect the answer is because no one has formally defined the state machines or state transitions.

I’m motivated to ask this question because back in 1999ish at the University of Wisconsin we came to and published the conclusion that you can’t formally reason about the correctness of a cache coherence protocol with out formally defining the state machine that implement the protocol. To further this work a language for specifying state machine in the context of coherence protocols was developed that could generate documentation, PDF, HTML, and executable simulation code. I believe the first publication of this methodology was in:

Specifying and Verifying a Broadcast and a Multicast Snooping Cache Coherence Protocol, Daniel J. Sorin, Manoj Plakal, Anne E. Condon, Mark D. Hill, Milo M. K. Martin and David A. Wood,
IEEE Transactions on Parallel and Distributed Systems, June 2002 (vol 13, number 6).
(Previously available as Dept. of Computer Sciences Technical Report CS-TR-2000-1412, March 2000.)

So given a methodology for clearly specifying complex protocols published in 2000 why isn’t OSCI using it (or something better) in 2008?

ESL Academic Publications, Wisconsin GEMS, Wisconsin Multifacet

I recently returned for a trip to Austin with my family to discover that the check bag containing the car seats for my children had been lost in transit. I had somewhat expected something to happen as I hadn’t seen the bag on the luggage cart full of bags to be loaded onto the plane while our other bags were clearly visible. I was looking because when we went to check-in in Austin they told me to take the car seats to the TSA Oversized Luggage screening area (and berated me for putting car seats in a bag rather than bringing them unwrapped to be put in the complimentary clear plastic bag they provide). The single TSA agent was already talking to three adults and a pile of kids while checking their luggage, two large coolers and two rifle cases. He told me that “since your bag isn’t fire arms I don’t need you to wait” and assured me that there would be plenty of time to get the bag on my flight.

Getting back to the story after waiting for all the bags to show up I talked to the luggage office who not only filled out the lost luggage form but also provide me with relatively new (< 3 months) loaner car seats of the appropriate sizes and offered an apology.

The bag was delivered the next afternoon and exchanged for the loaners. I think its important to recognize this sort of customer service and planning (having the car seats to loan) as it happens far to infrequently.

Travel continental, good customer service

In reading several blogs and newsletters recently I’ve gotten annoyed that people don’t say what they mean. There is talk about how to design better interfaces and how to document them better but this misses the point that without the interface any possible functionality doesn’t exist. Further the authors never get around to simply stating

Design the Interface First.

To unravel this though:
Jakob recently introduced me to Gary’s newsletter. So I started reading the back issues. Two in particular The (not so) Exciting World of Documentation and Accurate Register Specifications caught my attention. In the first Gary talks about the trouble generating accurate documentation for hardware designs and suggest that hardware engineers have firmware engineers review the documentation to ensure that it is comprehensible. He also discusses the difficulty in documenting the interface after the fact. In the second Gary suggests using a register design tool. Jakob then comments on this in his blog stating

“You really need a full expressive language to write a truly executable model of the hardware.”

Now all of this is well and good, and I happen to agree, but why do they go on at such length about their topics instead of just getting to the my point:

Design, document, and declare the interface first, then worry about implementing any functionality that may be triggered by calls to/interactions with that interface. Without the interface the functionality doesn’t exist.

I feel particular passion about this topic because of a situation I’ve run into with a customer with where over a year ago we were told (paraphrased)

We can’t give you the documentation on the interface to, or basic functionality of, our part in time for you to complete a high level functional model 6 months from now; we haven’t designed the interface and the documentation hasn’t been started. However we have the detailed model almost done we can integrate our detailed model with the functional framework in plenty of time.

I didn’t believe this at the time, and the detailed model ended up being about 3 months late before the integration really started working. The interface to the functionality is still being updated and the documentation still isn’t complete. Further as the firmware and unit tests gets written it becomes increasingly clear that the interface was never “designed” as such, rather it was just slapped together with the hope that it was good enough. Cases are still being found where functionality can’t be tested because there is no interface to it.

From this I draw the conclusion: functionality doesn’t exist until it has been tested through a well designed external interface, simply writing the RTL isn’t enough.

[edit]

Jakob points out that he did present this sentiment but not quite as clearly as I would have liked.

Driven by Blogs, ESL rant

Or why did I start a blog?

Mostly I’m starting this blog because I lack a local water cooler at which to comment and rant about various topics.  I’d like to think that I’ve got some grand purpose and have a clearly defined set of topics upon which to muse. However I suspect that things will be pretty random, though I’ll probably to commenting on technology, blogs, the weather, and the excitement of business travel.

Driven by Blogs