Using requirements planning in embedded systems design: Part 3 - Defining system timing requirements

When discussing timing in embedded software, there are typically two types of timing requirements, rate of execution and response time. Rate of execution deals with the event-to-event timing within a software function. It can be the timing between changes in an output, time between samples of an input, or some combination of both.

The important thing is that the timing specification relates to the execution timing of the function only—for example, a software serial input routine that simulates a serial port. The rate of execution is related to the baud rate of the data being received. If the baud rate is 9600 baud, then the routine must be called 9600 times a second to accurately capture each bit as it is received.

Response time, on the other hand, is the time between when a trigger event occurs and the time of the first response to the event within the function. The trigger is, by definition, an event external to the function, so the response-timing requirement is a constraint on the software system that manages and calls the software functions.

Specifically, it determines how quickly the main program must recognize an event and begin executing the appropriate software routine to handle it. Using the same software serial port routine as an example, the initial trigger for the routine is the falling edge of the start bit.

To accurately capture the subsequent flow of data bits, the routine will have to sample near the center of each bit. So, at a maximum, the response time must be less than 1/4 bit time; this will place the sample for the first bit within 1/4 bit time of 50%. If the sample placement must be more accurate, then the response time must be correspondingly faster.

Both the rate of execution and response timing requirements should be specified in the requirements document, even if they are not critical. Listing the requirement at least indicates what timing the designer has chosen to meet in the design. It will also become important later in this chapter when we determine the system timing.

Note, that for some software functions, the specifications may be missing. It could be an omission in the document or the specification may be hidden within the specification of another function.

Either way, it once again falls to the designer to play detective and determine the timing requirements. As an example, consider the control function from our clock example. In the requirements document, there may not be a specific requirement for response time and rate of execution listed for the command decoder function.

However, there should be timing specification for the maximum response time to a button command entered by the user. So, if the timing requirement states that the system response to a button press must be less than 200 msecs from the start of the button press, then 200 milliseconds is the maximum time allotted for:

• The response time, plus execution time for the keyboard debounce function responsible for scanning the keyboard, and determining when a valid button press has occurred.
• Plus, the response time allotted to the control task, for the detection of a command.
• Plus, the execution time allotted for processing of the command and making the appropriate change in the system.
• Plus, the maximum time required to display the change of status on the system display.

If we know the button may take as much as 100 ms to stop bouncing, and the debounce routine will require a minimum of 50 ms to detect the stable button, and the display task scans through all the displays 60 times a second, then we can determine that the command function has a maximum of 34 msec to detect and process the command:

34 msec = 200 msec -100 msec - 50 msec -1/60Hz)     Equation 3-2

So, even though there is no specification for the individual functions in the system, there may be an overall timing specification for the execution of the combination of functions. In fact, this will typically be the case with timing specifications.

Timing requirements are most often for a combination of functions rather than the individual functions determined by the designer. This makes sense, as the writers of the requirements document can only specify the performance for the system as a whole, because they will not know what the specific implementation chosen by the designer will look like in the product definition phase.

So, designers should take care in their review of the requirements document; sometimes the important information may not be in the most convenient format, and it may in fact be buried within other specifications.

Both timing parameters should also have tolerance requirements listed as well. The response time will typically have a single tolerance value, expressed as a plus percentage / minus percentage. And the execution rate will have at least one and possibly two, depending on the nature of the function.

Because the response time is less complicated, let’s start with it first. The response timing tolerance is the amount of uncertainty in the timing of when a functions starts.

Typically, it is specified as a plus/minus percentage on the response time, or it can also be specified as just the maximum response time allowed. If it is listed as a ± value, then the response time has both a minimum (Tresponse?X%) and maximum (Tresponse + X%) specification, and the response time is expected to fall within these timing limits.

If, on the other hand, the only specification is a maximum response time, the more common form, then the minimum is assumed to be 0 and the maximum is the specified maximum response time.

Because the minimum and maximum times are the values important to our design, either form works equally well. The designer need only determine the minimum and maximum and note them in the design document for the appropriate software function.

The reason for two potentially different tolerances on execution rate is that first tolerance will typically specify the maximum variation for a single worst-case event-event timing, while the second specifies the total variation in the execution timing over a group of events.

If only a single tolerance is specified, then it is assumed that it specifies both event-event and the total variation for a group of events. To clarify, consider a serial port transmit function implemented in software. The routine accepts a byte of data to be sent, and then generates a string of ones and zeros on an output to transmit the start, data, parity, and stop bits.

The event-to-event timing tolerance governs the bit-by-bit timing variation in the transitions of the ones and zeros sent. If the port were configured for 9600 baud, then the individual bit timing would be 104_s.

The event-event timing tolerance specifies how much this timing can shift for a single bit period. Some bits may be longer, and others shorter than the optimal 104_s, but as long as they are within the specification, the receiving system should be able to receive the data.

The overall timing tolerance governs the accumulated average variation in bit timing for the complete byte sent by the routine, basically specifying the maximum variation over the course of the entire transmission.

The reason this is important has to do with the idea of stacked tolerances. For example, say each bit time within a serial data transmission is allowed to vary as much as ±10%. This means that the bit transitions may vary from as short as 94_s, to as much as 114_s. This is not a large amount, and for a single bit time, it is typically not critical.

However, if the transmitted bits were all long by 10%, the timing error will accumulate and shift the position of the data bits. Over the course of 6 bits, the shift would be sufficient to move the fourth to fifth bit transition so far out that the receiving system would incorrectly think it is sampling the sixth data bit of data.

If, on the other hand, the overall average error is kept below 4%, then even though the individual bits may vary by 10%, most of the individual bit timing errors will cancel. In this scenario, the accumulated error should be sufficiently small to allow the receiver a marginal probability of receiving the valid data.

If we consider the problem from a practical point of view, it makes sense. There will typically be some variation in the timing of output changes. As long as the variation averages out to zero, or some value sufficiently small to be tolerable, then the overall frequency of the output changes will be relatively unaffected by the individual variation. So, note both values in the design notes for future use by the system in the timing analysis later in this series.

(One other point to note: Check for any exceptions to the timing requirements, specifically any exception tied to a particular action in the function, such as, “The bit timing shall be 9600 baud ±3%, except for the stop bit, which shall be 9600 baud +100/?3.” What this requirement tells the designer is that the individual bits in the data stream must vary less than 3%.

The one exception is the stop bit which can be as short as the other bits, but may be as long as two complete bits, before the next start bit in the data stream. This is a valuable piece of information that will help in the design of both the timing and priority control sections of the design and, again, it should be noted in the design notes for the project.)