ParityCheck

Firmware architecture in five easy steps By Michael Barr

paritycheck — Fri, 13 Nov 2009 07:28:33 +0000

Firmware architecture in five easy steps

By Michael Barr

(09/21/09, 04:03:00 PM EDT)

Over the past few years, I’ve spent a large amount of my time consulting with and training software development teams that were in the midst of rearchitecture. These teams had already developed the firmware inside successful long-lived products or product families. But to keep moving forward, reduce bugs, and speed new feature development, they needed to take the best of their old code and plug it into a better firmware architecture.

In the process, I’ve collected substantial anecdotal evidence that leads me to conclude that few programmers, technical managers, or teams truly understand what good firmware architecture is, how to achieve it, or even how to recognize it when they see it. That includes the most experienced individual developers on a team. Yet, despite the fact that these teams work in a range of very different industries (including safety-critical medical devices), the rearchitecture process is remarkably similar from my point of view. And there are numerous ways that our clients’ products and engineering teams would have benefited from getting their firmware architecture right from the beginning.

Although learning to create solid firmware architecture and simultaneously rearchitecting legacy software may take a team months of hard work, five key steps are easily identified. So whether you are designing firmware architecture from scratch for a new product or launching a rearchitecture effort of your own, you can use this step-by-step process to help your team get started on the right foot.

Step 1: Identify the requirements
Before we can begin to (re)architect an embedded system or its firmware, we must have clear requirements. Properly written requirements define the WHAT of a product. WHAT does the product do for the user, specifically? For example, if the product is a ventilator, the list of WHAT it does may include a statement such as:

“If power is lost during operation, the ventilator shall resume operation according to its last programmed settings within 250 ms of power up.”

Note that a properly written requirement is silent about HOW this particular part of the overall WHAT is to be achieved. The implementation could be purely electronics or a combination of electronics and firmware; the firmware, if present, might contain an RTOS or it might not. From the point of view of the requirement writer, then, there may as well be a gnome living inside the product that fulfills the requirement.¹ (So long as the gnome is trustworthy and immortal, of course!)

Each requirement statement must also be two other things: unambiguous and testable. An unambiguous statement requires no further explanation. It is as clear and as concise as possible. If the requirement includes a mathematical model of expected system behavior, it is helpful to include the equations.²

Testability is key. If a requirement is written properly, a set of tests can be easily constructed to verify that requirement is met. Decoupling the tests from the particulars of the implementation, in this manner, is of critical importance. Many organizations perform extensive testing of the wrong stuff. Any coupling between the test and the implementation is problematic.

A proper set of requirements is a written list of statements each of which contains the key phrase ” the [product] shall …” and is silent about how it is implemented, unambiguous, and testable. This may seem like a subject unrelated to architecture, but too often it is poor requirements that constrain architecture. Thus good architecture depends in part on good requirements.³

Step 2: Distinguish architecture from design
Over the years, I have found that many engineers (as well as their managers) struggle to separate the various elements or layers of firmware engineering. For example, Netrino is barraged with requests for “design reviews” that turn out to be “code reviews” because the customer is confused about the meaning of “design.” This even happens in organizations that follow a defined software development lifecycle. We need to clear this up.

The architecture of a system is the outermost layer of HOW. Architecture describes persistent features; the architecture is hard to change and must be got right through careful thinking about intended and permissible uses of the product. By analogy, an architect describes a new office building only very broadly. A scale model and drawings show the outer dimensions, foundation, and number of floors. The number of rooms on each floor and their specific uses are not part of the architecture.⁴

Architecture is best documented via a collection of block diagrams, with directional arrows connecting subsystems. The system architecture diagram identifies data flows and shows partitioning at the hardware vs. firmware level. Drilling down, the firmware architecture diagram identifies subsystem-level blocks such as device drivers, RTOS, middleware, and major application components. These architectural diagrams should not have to change even as roadmap features are added to the product—at least for the next few years. Architectural diagrams should also pass the “six-pack test,” which says that even after drinking a six pack of beer, every member of the team should still be able to understand the architecture; it is devoid of confusing details and has as few named components as possible.⁵

The design of a system is the middle layer of HOW. The architecture does not include function or variable names. A firmware design document identifies these fine-grained details, such as the names and responsibilities of tasks within the specific subsystems or device drivers, the brand of RTOS (if one is used), and the details of the interfaces between subsystems. The design documents class, task, function/method, parameter, and variable names that must be agreed upon by all implementers. This is similar to how a design firm hired by the renter of a floor on the office building describes the interior and exterior of the new building in finer detail than the architect. Designers locate and name rooms and give them specific purposes (e.g., cube farm, corner office, or conference room).

An implementation is the lowest layer of HOW. There need be no document, other than the source code or schematics, to describe the implementation details. If the interfaces are defined sufficiently at the design level above, individual engineers are able to begin implementation of the various component parts in parallel. This is similar to the way that a carpenter, plumber, and electrician work in parallel in nearby space, applying their own judgment about the finer details of component placement, after the design has been approved by the lessee.

Of course, there is architecture and there is good architecture. Good architecture makes the most difficult parts of the project easy. These difficult parts vary in importance somewhat from industry to industry, but always center on three big challenges that must be traded off against each other: meeting real-time deadlines, testing, and diversity management. Addressing those issues comprise the final three steps.

Step 3: Manage time
Some of your product’s requirements will mention explicit amounts of time. For example, consider the earlier ventilator requirement about doing something “within 250 ms of power up.” That is a timeliness requirement. “Within 250 ms of power up” is just one deadline for the ventilator implementation team to meet. (And something to be tested under a variety of scenarios.) The architecture should make it easy to meet this deadline, as well as to be certain it will always be met.

Most products feature a mix of non-real-time, soft-real-time, and hard-real-time requirements. Soft deadlines are usually the most challenging to define in an unambiguous manner, test, and implement. For example, in set-top box design it may be acceptable to drop a frame of video once in a while, but never more than two in a row, and never any audio, which arrives in the same digital input stream. The simplest way to handle soft deadlines is to treat them as hard deadlines that must always be met.

With deadlines identified, the first step in architecture is to push as many of the timeliness requirements as possible out of the software and onto the hardware. Figure 1 shows the preferred placement of real-time functionality. As indicated, an FPGA or a dedicated CPU is the ideal place to put real-time functionality (irrespective of the length of the deadline). Only when that is not possible, should an interrupt service routine (ISR) be used instead. And only when an ISR won’t work should a high-priority task be used.

View the full-size image

Keeping the real-time functionality separate from the bulk of the software is valuable for two important reasons. First, because it simplifies the design and implementation of the non-real-time software. With timeliness requirements architected out of the bulk of the software, code written by novice implementers can be used without affecting user safety.⁶

The second advantage of keeping the real-time functionality together is it simplifies the analysis involved in proving all deadlines are always met. If all of the real-time software is segregated into ISRs and high-priority tasks, the amount of work required to perform rate monotonic analysis (RMA) is significantly reduced. Additionally, once the RMA analysis is completed, it need not be revised every time the non-real-time code is tweaked or added to.

Step 4: Design for test
Every embedded system needs to be tested. Generally, it is also valuable or mandatory that testing be performed at several levels. The most common levels of testing are:

System tests verify that the product as a whole meets or exceeds the stated requirements. System tests are generally best developed outside of the engineering department, though they may fit into a test harness developed by engineers.⁷
Integration tests verify that a subset of the subsystems identified in the architecture diagrams interact as expected and produce reasonable outcomes. Integration tests are generally best developed by a testing group or person within software engineering.
Unit tests verify that individual software components identified at the intermediate design level perform as their implementers expect. That is, they test at the level of the public API the component presents to other components. Unit tests are generally best developed by the same people that write the code under test.⁸

Of the three, system tests are most easily developed, as those test the product at its exposed hardware interfaces to the world (e.g., does the dialysis machine perform as required). Of course, a test harness may need to be developed for engineering and/or factory acceptance tests. But this is generally still easier than integration and unit tests, which demand additional visibility inside the device as it operates.

To make the development, use, and maintenance of integration and unit tests easy, it is valuable to architect the firmware in a manner compatible with a software test framework. The single best way to do this is to architect the interactions between all software components at the levels you want to test so they are based on publish-subscribe event passing (a.k.a., message passing).

Interaction based on a publish-subscribe model allows a lightweight test framework like the one shown in Figure 2 to be inserted alongside the software component(s) under test. Any interface between the test framework and the outside world, such as a serial port, provides an easy way to inject or log events. A test engine on the other side of that communications interface can then be designed to accept test “scripts” as input, log subscribed event occurrences, and off-line check logged events against valid result sequences. Adding timestamps to the event logger and scripting language features like delay(time) and waitfor(event) significantly increases testing capability.

View the full-size image

It is unfortunate that the publish-subscribe component interaction model is at odds with proven methods of analyzing software schedulability (e.g., RMA). The sheer number of possible message arrival orders, queue depths, and other details make the analysis portion of guaranteeing timeliness difficult and fragile against minor implementation changes. This is, in fact, why it is important to separate the code that must meet deadlines from the rest of the software. In this architecture, though, the real-time functionality remains difficult to test other than at the system level.⁹

Step 5: Plan for change
The third key consideration during the firmware architecture phase of the project is the management of feature diversity and product customizations. Many companies use a single source code base to build firmware for a family of related products. For example, consider microwave ovens; though one high-end model may feature a dedicated “popcorn” button, another may lack this. The architecture of any new product’s firmware will also soon be tested and stretched in the direction of foreseeable planned feature additions along the product road map.

To plan for change, you must first understand the types of changes that occur in your specific product. Then architect the firmware so that those sorts of changes are the easiest to make. If the software is architected well, feature diversity can be managed through a single software build with compile-time and/or run-time behavioral switches in the firmware. Similarly, new features can be added easily to a good architecture without breaking the existing product’s functionality.

An architectural approach that handles product family diversity particularly well is one in which groups of related software components are collected into “packages”. Each such package is effectively an internal widget from which larger products can be built. The source code and unit tests for each particular package should be maintained by a team of “package developers” focused primarily on their stability and ease of use.

Teams of “product developers” combine stable releases of packages that contain the features they need, customize each as appropriate (e.g., via compile- or run-time mechanisms, or both) to their particular product, and add product-specific “glue.” Typically, all of the products in a related product family are built upon a common “Foundation” package (think API). For example a Model X microwave might be built from Foundation + Package A + Package B; whereas Model Y might consist of Foundation + A’ + B + C, where package A’ is a compile-time variant of package A and package C contains optional high-level cooking features, such as “Popcorn.”

Using this approach in a large organization, a new product built from a selection of stable bug-free packages can be brought to market quickly–and all products share an easy upgrade path as their core packages are improved. The main challenge in planning for change of this sort is in striking the right balance between packages that are too small and packages that are too large. Like many of the details of firmware architecture, achieving that balance for a number of years is more of an art than a science.

Next steps
I hope the five-step “architecture road map” presented here is useful to you. I plan to drill down into more of the details in articles and columns over the coming months. Meanwhile your constructive feedback is welcome via the discussion forum or e-mail.

Michael Barr is the author of three books and over fifty articles about embedded systems design, as well as a former editor-in-chief of this magazine. Michael is also a popular speaker at the Embedded Systems Conference, a former adjunct professor at the University of Maryland, and the president of Netrino. He has assisted in the design and implementation of products ranging from safety-critical medical devices to satellite TV receivers. You can reach him via e-mail at mbarr@netrino.com or read more of what he has to say at his blog (www.embeddedgurus.net/barr-code).

Endnotes:
1. This sounds silly, but it’s true. If an individual requirement doesn’t pass the “gnome test” then it merits further rewriting.

2. However, we must remember that this is only a WHAT requirement. The HOW implementer may not choose to include that equation in the code and still meet the requirement. For example, a mathematical equation may be converted into a look-up table plus interpolations, which may be executed by either hardware or software (or by a gnome).

3. If you can’t get proper requirements from outside engineering, you may have to expend effort inside engineering translating the customer or marketing requirements you do have into a proper set of requirements for internal use.

4. With the exception of anything involving plumbing, which is almost as hard to change as the supporting columns.

5. Non-drinkers may prefer the phrase “30,000 foot view” which is the same standard.

6. To give an extreme example, marketing can have engineering add the game “Pong” in a low-priority task running on the ventilator without affecting patient safety.

7. The system tests should treat the firmware as a black box. In fact, they would ideally be structured at the “gnome level.”

8. Proponents of test-driven development advocate that tests at this level be written in advance of the functions or classes that they are intended to verify.

9. But isn’t it always true that testing real-time behaviors intrusively is an oxymoron?

Windows XP – Tracking System Performance, Useful log counters

paritycheck — Wed, 04 Nov 2009 19:41:48 +0000

After running perfmon from Start->Run

Memory:Pages/sec

Number of pages read from disk or written to disk when Windows runs out of memory. Swapping information to and from the disk can slow down your system a lot. Consider adding more memory if you see frequency swapping.

PhysicalDisk:Avg. Disk Queue Length

How many read and write requests are waiting for the disk to respond. High numbers indicate that a faster disk drive would speed up performance.

PhysicalDisk:% Disk Time

What percentage of the time the disk was busy. This is another indicator of a slow or overloaded disk.

Processor:% Processor Time

What percentage of the time the processor was busy with all types of processes. This counter can tell you whether delays are caused by an overloaded CPU.

Originally sourced from Windows XP Cookbook, Robbie Allen & Preston Gralla

What is an Open-Collector/Open-Drain Circuit?

paritycheck — Tue, 03 Nov 2009 16:15:48 +0000

Open-collector/open-drain is a circuit technique which allows multiple devices to communicate bi-directionally on a single wire.

Open-collector/open-drain devices sink (flow) current in their low voltage active (logic 0) state, or are high impedance (no current flows) in their high voltage non-active (logic 1) state. These devices usually operate with an external pull-up resistor that holds the signal line high until a device on the wire sinks enough current to pull the line low. Many devices can be attached to the signal wire. If all devices attached to the wire are in their non-active state, the pull-up will hold the wire at a high voltage. If one or more devices are in the active state, the signal wire voltage will be low.

An open-collector/open-drain signal wire can also be bi-directional. Bi-directional means that a device can both output and input a signal on the wire at the same time. In addition to controlling the state of its pin that is connected to the signal wire (active, or non-active), a device can also sense the voltage level of the signal wire. Although the output of a open-collecter/open-drain device may be in the non-active (high) state, the wire attached to the device may be in the active (low) state, due to activity of another device attached to the wire.

The bi-directional nature of an open-collector/open-drain device is what makes this circuit so important in interconnecting many devices on a common line. The I2C Bus and SMBus uses this technique for connecting up to 127 devices.

Open-drain refers to the drain terminal of a MOS FET transistor. Open-collector is the same concept on a bipolar device.

sourced from http://www.mcc-us.com/Open-collectorFAQ.htm

converting ppm to frequency

paritycheck — Sat, 03 Oct 2009 13:42:24 +0000

Oscillators and other frequency control devices specify their frequency variation in units of parts per million (ppm). The equation for this relationship is,

delta_frequency = (f x ppm)/ 10^6

where ppm is the peak variation (expressed as +/-),f is the center frequency (in Hz), and delta_frequency is the peak frequency variation (in Hz).

For example, 100 ppm of 100 MHz represents a variation in frequency(delta_frequency) of 10 kHz. The maximum and minimum frequencies are therefore 100.01 and 99.99 MHz, respectively.

Storage rules for C variables

paritycheck — Wed, 01 Apr 2009 13:59:00 +0000

Local variables (declared within a function) are stored on the stack, provided they have not been declared with the static attribute.
Local, non-static variables are sometimes called “automatic” variables. (There is even a C keyword, auto, but it is almost never used in practice.)
Local variables (declared within a function) that have the static attribute are not stored on the stack; they have fixed addresses in memory.
Variables with file scope (declared outside of any function) are not stored on the stack; they also have fixed addresses in memory. The static attribute is irrelevant here (it merely affects the visibility (scope) of the variable).
Arguments passed to a function by value are stored on the stack. The calling function makes a copy of the data and makes that copy available to the called function.
Arguments passed to a function by reference require special consideration. The data pointed to by the reference has whatever storage the variable in the calling program segment has. The pointer itself (being passed to the function) is on the stack.

What does this mean? ((volatile unsigned char )(0×22))

paritycheck — Sat, 28 Mar 2009 06:08:26 +0000

Using C, I was trying to assign a variable name to a register address so that my code would be readable. An example of how to do this is as follows:

#define DDRA (*(volatile unsigned char *)(0x22))

This means that if a register or memory location exists at address 0×22, I can use DDRA to read or write to it like so..

DDRA = 0x05

in my C code.

The #define looks really cryptic at first. The way to understand this is by breaking it down into pieces.

First of all,

unsigned char

means we are using a byte-sized memory location. Byte being 8-bits wide.

unsigned char *

means we are declaring a pointer that points to a byte-sized location.

(unsigned char *) (0x22)

means the byte-sized pointer points to address 0×22. The C compiler will refer to address 0×22 when the variable DDRA is used. The assembly code will end up using 0×22 in Load(LD) and Store (STR) insturctions.

(*(unsigned char *)(0x22))

The first asterisk from the left signifies that we want to manipulate the value in address 0×22. * means “the value pointed to by the pointer”.

volatile

volatile forces the compiler to issue a Load or Store anytime DDRA is accessed as the value may change without the compiler knowing it.

Keeping Your Job Onshore by Dan Saks

paritycheck — Wed, 25 Mar 2009 13:59:42 +0000

keeping-your-job-onshore

For ASIC designers whose jobs are being outsourced, 3 steps to Professional Success

Choose to do what you love
Sharpen your communication skills
Expand your professional tool set, and master the tools most crucial to your work

Decoding Ethernet Operational modes

paritycheck — Tue, 24 Mar 2009 05:25:18 +0000

Being new to Ethernet, I easily get confused when it comes to all the different link modes. Here is my cheatsheet:

40 GE KR4 = 1 port composed of 4 lanes, each running at 10 G.
10 GE KR = 1 port composed of 1 lane running at 10 G
10 GE KX4 = 1 port composed of 4 lanes, each running at 3.125 G. Also known as running 4 XAUI lanes)
1 GE KX = 1 port composed of 1 lane running at 1 G.

for(;;) vs while(1) loop

paritycheck — Sat, 21 Mar 2009 11:51:30 +0000

I was taking an extension class and the instructor briefly mentioned that in the main C loop, a for(;;) loop was much more efficient than a while(1) loop. I didn’t pay too much attention to the statement at the time but it was always in the back of my mind. Now, I’ve tried a simple experiment to see if there is a difference. I created two small programs that simply increments one of the Atmel AVR’s internal registers. One version uses the for(;;) construct, the other uses the while(1) construct.

Here is the C code using a while loop

#define DDRA (*(volatile unsigned char *)(0x22))

int main()
{

 DDRA = 0xff;
 
 while(1)
 {
  DDRA = DDRA + 1;
 }

}

Here is the C code using a for loop

#define DDRA (*(volatile unsigned char *)(0x22))

int main()
{

 DDRA = 0xff;
 
 //while(1)
 for(;;)
 {
  DDRA = DDRA + 1;
 }

}

Using AVR Studio, the GCC compiler generates the following assembly code when while(1) is used.


learningC.elf:     file format elf32-avr
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000082  00000000  00000000  00000054  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .debug_aranges 00000020  00000000  00000000  000000d6  2**0
                  CONTENTS, READONLY, DEBUGGING
  2 .debug_pubnames 0000001b  00000000  00000000  000000f6  2**0
                  CONTENTS, READONLY, DEBUGGING
  3 .debug_info   00000044  00000000  00000000  00000111  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_abbrev 00000034  00000000  00000000  00000155  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_line   0000006b  00000000  00000000  00000189  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_frame  00000020  00000000  00000000  000001f4  2**2
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_str    0000006e  00000000  00000000  00000214  2**0
                  CONTENTS, READONLY, DEBUGGING
Disassembly of section .text:
00000000 <__vectors>:
   0: 0c 94 2e 00  jmp 0x5c ; 0x5c <__ctors_end>
   4: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
   8: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
   c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  10: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  14: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  18: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  1c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  20: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  24: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  28: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  2c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  30: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  34: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  38: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  3c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  40: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  44: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  48: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  4c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  50: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  54: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  58: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
0000005c <__ctors_end>:
  5c: 11 24        eor r1, r1
  5e: 1f be        out 0x3f, r1 ; 63
  60: cf ef        ldi r28, 0xFF ; 255
  62: d4 e0        ldi r29, 0x04 ; 4
  64: de bf        out 0x3e, r29 ; 62
  66: cd bf        out 0x3d, r28 ; 61
  68: 0e 94 3a 00  call 0x74 ; 0x74 
  6c: 0c 94 3f 00  jmp 0x7e ; 0x7e <_exit>
00000070 <__bad_interrupt>:
  70: 0c 94 00 00  jmp 0 ; 0x0 <__vectors>
00000074 :
#define DDRA (*(volatile unsigned char *)(0x22))
int main()
{
 DDRA = 0xff;
  74: 8f ef        ldi r24, 0xFF ; 255
  76: 82 b9        out 0x02, r24 ; 2
 
 while(1)
 {
  DDRA = DDRA + 1;
  78: 82 b1        in r24, 0x02 ; 2
  7a: 8f 5f        subi r24, 0xFF ; 255
  7c: fc cf        rjmp .-8       ; 0x76 
0000007e <_exit>:
  7e: f8 94        cli
00000080 <__stop_program>:
  80: ff cf        rjmp .-2       ; 0x80 <__stop_program>

Using the same tools (AVR Studio and GCC), the compiler generates the following assembly code when for(;;) is used.


learningC.elf:     file format elf32-avr
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000082  00000000  00000000  00000054  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .debug_aranges 00000020  00000000  00000000  000000d6  2**0
                  CONTENTS, READONLY, DEBUGGING
  2 .debug_pubnames 0000001b  00000000  00000000  000000f6  2**0
                  CONTENTS, READONLY, DEBUGGING
  3 .debug_info   00000044  00000000  00000000  00000111  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_abbrev 00000034  00000000  00000000  00000155  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_line   0000006b  00000000  00000000  00000189  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_frame  00000020  00000000  00000000  000001f4  2**2
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_str    0000006e  00000000  00000000  00000214  2**0
                  CONTENTS, READONLY, DEBUGGING
Disassembly of section .text:
00000000 <__vectors>:
   0: 0c 94 2e 00  jmp 0x5c ; 0x5c <__ctors_end>
   4: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
   8: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
   c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  10: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  14: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  18: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  1c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  20: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  24: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  28: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  2c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  30: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  34: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  38: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  3c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  40: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  44: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  48: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  4c: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  50: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  54: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
  58: 0c 94 38 00  jmp 0x70 ; 0x70 <__bad_interrupt>
0000005c <__ctors_end>:
  5c: 11 24        eor r1, r1
  5e: 1f be        out 0x3f, r1 ; 63
  60: cf ef        ldi r28, 0xFF ; 255
  62: d4 e0        ldi r29, 0x04 ; 4
  64: de bf        out 0x3e, r29 ; 62
  66: cd bf        out 0x3d, r28 ; 61
  68: 0e 94 3a 00  call 0x74 ; 0x74 
  6c: 0c 94 3f 00  jmp 0x7e ; 0x7e <_exit>
00000070 <__bad_interrupt>:
  70: 0c 94 00 00  jmp 0 ; 0x0 <__vectors>
00000074 :
#define DDRA (*(volatile unsigned char *)(0x22))
int main()
{
 DDRA = 0xff;
  74: 8f ef        ldi r24, 0xFF ; 255
  76: 82 b9        out 0x02, r24 ; 2
 
 //while(1)
 for(;;)
 {
  DDRA = DDRA + 1;
  78: 82 b1        in r24, 0x02 ; 2
  7a: 8f 5f        subi r24, 0xFF ; 255
  7c: fc cf        rjmp .-8       ; 0x76 
0000007e <_exit>:
  7e: f8 94        cli
00000080 <__stop_program>:
  80: ff cf        rjmp .-2       ; 0x80 <__stop_program>

If you look carefully, the only difference in the .lss files are lines 65 and 66. These lines simply show whether a for or while was used for the loop. To summarize, there is no difference. Ofcourse, C compilers may vary.

Alan Wong’s Restaurant, Oahu, Hawaii

paritycheck — Wed, 25 Feb 2009 06:08:23 +0000

Blogs are interesting. When I first decided to create a blog, I decided that my focus would be strictly on all things related to chip design. That is, anything that I found useful throughout my career that I felt compelled to share with other ASIC designers. I’m realizing that, at times, I want to share more than that. I find blogging a great medium for relaying any useful tidbits that I’ve learned in my life that would help my fellow human being – ranging from the chip designer, the CVS user, or even the casual restaurant diner.

However, it just doesn’t seem right to veer from the original intent of the blog which was to provide useful tips to chip designers. So, to stay somewhat on course, I use the NAND gate rating scheme.

2 NAND gates out of 5 (5 NAND gates being best).

Subject: Alan Wong’s Restaurant

Location: Honolulu, Oahu, Hawaii, United States, North America

Title: dessert was very good, overall mediocre

My wife and I ate at Alan Wong’s on Jan 19, 2009. Here is our experience…

We are Southern California locals that had a tough time finding the place even when using a Garmin Nuvi 265W GPS. We were sort of surprised since we had read reviews that this was a highly rated restaurant that won so many awards located at such a mediocre neighborhood. It turns out the restaurant is on the 3rd floor of a business building. Odd considering that Oahu has so many great views of the ocean and mountains,..why would a restaurant owner locate a supposedly highly rated restaurant in a decrepid neighborhood?

Okay, so we finally find the place and valet parking is required ($3.00) in a teeny tiny parking garage.

We made our reservation two nights ago and we arrived on the dot. The hostess was unkempt,.. her shoe heel straps weren’t even on, hair stringy and messy. (Gee guys, keep your eye on the details).

We were finally seated. I do have to say that once inside, the restaurant looks great. Lighting, seating arrangement,.. the whole look of the room design is superb.

My first complaint is this,… it just seemed like the waiters were not professional at all. Our main waiter was so.. robotic. No smile, no “how are you doing?”, No explanation of the dishes, how they are prepared, what makes them taste so good, etc. The menu itself doesn’t describe the dishes well enough. But, then I realized, it is because the food is so mediocre (more on that later).

I ordered the Ginger Crusted Onaga for $35.00. It comes with Hamakua mushrooms, sesame vinagrette, and (of all things) corn.

I thought to myself. “Gee, corn is so common, why am I going to pay $35.00 for some corn with my seafood. Hmm, unless they found a fancy way to prepare it. Okay, I’ll try it”.

If this chef won awards on corn+seafood, he must be really creative. Finally we placed our order with our robot waiter. Wouldn’t you know it, the menu doesn’t even tell you that you have a choice of mashed potatoes, white rice, or brown rice.

I thought again,..”Mashed potatoes?.. nothing fancy about that, right? Unless, the chef is really creative,.. then maybe….Okay, I’ll try it”

We also ordered the Asparagus appetizer. And waited for the food to come… We were served the Asparagus appetizer,… it came with 5-6 asparagus stems + tops,.. with a sauce that was laid on the center of all of them. It was served by another waiter..not the robot one. She seemed like she knew the info for the dish but was really ditzy.

So ditzy that when she asked whether we wanted pepper on our appetizer and we said “No thanks”.. she still put pepper on our dish.. and a lot of it over 5-6 Asparagus. We just let it go,… didn’t want her to screw something up again,.. and besides we were hungry.

Then, the main dish arrives. Basically, a fish on top of mushrooms and corn. Guess what? Nothing really creative about the corn. It was simply corn. The fish was topped with a ginger and spicing – that was tasty. The mushrooms tasted good, too. But, I just couldn’t understand why mix the Haukama mushrooms, the ginger, the fish,.. (all exotic).. with corn.

Then, the next thing that irks me is that, they served the mashed potatoes, slightly later than the main dish, and it was really hot. It was so hot that I nearly burned my tongue. I had to eat the fish first,in its entirety, so that the potatoes could cool down.

Message to the restaurant,.. “Why don’t you time the delivery of the dishes so they come out together at the right temperature?”.

And, finally, we had dessert. This is the one main thing I really liked about Alan Wong’s. I don’t remember the exact name of the dessert but it was a goat cheese sorbet with a strawberry and hibiscus sauce. This tasted very good.

I think I’ve wrote enough and I hope you find this helpful. To summarize, the dessert was great, the interior design of the restaurant looked top notch. The downsides were the waiters, the main dish, and finding the place. This is why I gave it two gates.

This was originally posted at www.tripadvisor.com. But, they decided not to post it. They filter their reviews and are biased to positive reviews.

Good luck!