Whether dealing with SoCs or a disaster in space, determining the correct set of steps is vital.
No project team wants a “Houston, we have a problem,” moment. And yet, they happen all too frequently, even though there could be a tool to avoid that heart-in-mouth situation.
The real-life Houston moment, brought dramatically to life in the 1995 movie “Apollo 13,” occurred during what was meant to be the seventh manned mission of the NASA Apollo space program in 1970. It didn’t meet the goal to land on the moon and the mission was aborted after an oxygen tank exploded, but taught NASA invaluable lessons implemented in future projects.
Once it was clear that the craft had limited power, Command Module Pilot Ken Mattingly, an original crew member who was sidelined and didn’t make the mission, stepped into the earthbound NASA simulator to figure out what could be turned off to save power. He began the harrowing and arduous manual task to save critical amps of power here and there.
Mattingly, played convincingly by Gary Sinese in the movie, manipulated the controls and painstakingly went through each sequence in the user manual one at a time to determine what could be turned off. When he didn’t hit the power budget, according to a roomful of NASA PhD-holding analysts, he went back through the sequence. With pencil and paper, he manually reorganized the sequences to minimize power yet again.
Adding to the pressure, the powered-down lunar module left the crew in a cabin with no heat and rising levels of carbon dioxide. Potable water was in short supply as well. Time was running out. Mattingly insisted, “It’s all in the sequence,” in his endeavor to find the right power up sequence. He finally found it.
Sequences play an important role in today’s SoCs where there are thousands of them for initialization, configuration, power-up, power-down, low-power mode and so on. Each consists of a specific order of read/writes to specific bit fields in the address spaces of various IP in the SoC. These specific steps of operation can become quite complex with hundreds if not thousands of individual sequential or hierarchical operations typically documented in a non-parsable form in a datasheet. They must be manually and meticulously transcribed into code.
A register configuration sequence that forms the core of the device driver is needed also as a directed sequence in the verification environment. Similarly, a post-silicon bug may need to be reproduced in the verification environment with the exact same sequence. Failure to match the sequence as intended by the designer can lead to a disastrous situation.
A portable sequence generator can help in many instances. Users enter sequences as a common specification in a parsable form and the tool converts it into code for a variety of domains, including firmware, verification, validation and Automatic Testing Equipment (ATE) saving time, manual effort and expense.
If Mattingly had today’s Design Automation tools at hand, they may have assisted him to determine what steps could be skipped to save power and more quickly identify the sequence offering the lowest power consumption. Undoubtedly, NASA now employs powerful computers and Design Automation tools to enable the Mars Exploration Program (MEP) to study of life on the planet, as well as its climate and natural resources.
Sequences have played an important role in electronics design and only recently has there been a tool that focuses on them.
Excellent article on the need for portable generation sequence and a good analogy to drive home the point 🙂 With rising programming complexity, having such tools are not optional anymore.