The first ARM is the ARM we all know, Advanced RISC Machines (the A originally stood for Acorn but that story is for another day). The second ARM stands for "Architecture Reference Manual". At the Jasper User Group recently, Daryl Stewart of ARM's technology services group (TSG) opened the second day. If you want to know more about TSG, then read DVCon Europe: What You Missed , where Daryl's boss gave the keynote. Daryl pointed out that JUG had two kinds of presentations. The first is hands-on presentations, with engineers talking about tips and techniques that they had discovered about formal verification (FV). The second is about how to get FV into organizations. Everything from how to persuade senior management, to how to show value, to how to train engineers with no FV experience. In the early days Daryl worked on what was then called "early payback" and is now called "shift left". This was a mixture of finding bugs earlier, finding bugs that simulation missed, and generally showing incremental gain for incremental effort. This was the AHAA moment: bug A voidance: formal during RTL bringup, catch bugs early, shift left bug H unting: find bugs and create server-farm friendly regression suites bug A bsence: prove critical properties (experts only) bug A nalysis: find late-cycle and post-silicon bugs and confirm correctness of fixes FV got a big credibility boost during one project that Daryl was not allowed to name. One block was considered to be especially hard and was given to a superstar engineer. The red bars in the graph above are the bugs found by the superstar engineer. So, of course, everyone said that it had been good to give it to him, he was clearly great at writing testbenches. "I wrote properties, not a testbench." This was FV not simulation. However, Daryl had grander goals in mind. The ARM ARM has some pseudo-code in it, among the specifications in English, but it turns out that nobody had ever attempted to execute this code and, in fact, it is full of trivial syntax errors. He and a couple of recent graduates started with a couple of subsystems, defined their specs formally, and then validated them. This lead to a machine readable version of the architecture (written in ASL, which I think stands for ARM Specification Language). There has been a lot of academic research on what you can do if you write a model of the ARM architecture, and this replaced the ad-hoc academic models with a real one. In addition to having a "trustworthy" specification of the ARM system-level architecture, they identified aspects of the architecture that were not properly tested. In addition, they could generate simulators direct from the specification, and verify programs and compilers against the spec. Daryl spent a couple of years working on what he called Pelican, which was the Cortex-M7. The group he worked in had responsibility for the memory system and in the next room was the core team. They used FV, of course. This had two big positive results. First, the memory system finished ahead of the core, which never happens. Second, there were many more errata in the core. They took the machine-readable specification and developed what they call ISA-Formal. By observing the architectural state before an instruction retires and after, they don't need anything else. By definition, they are testing instruction flows that include that instruction. If other instructions are wrong, and leave things set up wrong, then this will fall out, so one instruction is actually testing others. In 40 weeks, 25% of the bugs were found by one junior (six months experience) engineer with one-fourth of the compute time per bug. This shifted management mindset a lot since they don't like having to apologize to customers about major errata. There is a long way to go. We are at the cathedral stage of architecture, not the skyscraper stage. System design today is at the same level of development as architecture in the middle ages, there is experience but no formal theory of design. La Sagrada Familia, the famous cathedral in Barcelona, was partially designed by string and weights upside down: the strings naturally conform to the lines of force that have to carry the weight of the building. The vision is that formal methods become to computer engineers as mathematics is to mechanical engineers. In the Q&A, Daryl was asked what the biggest challenges were: "You make it look too easy." He listed a few. One, engineers who don't want to try new things. Another is keeping upper management on board, ensuring that formal is planned in from the beginning and is not pulled out when deadlines get tight (deadlines always get tight). It is a big plus to get formal people into the planning meetings. The recently announced M23 and M33 had verification leads who had come up through FV and they got some astonishing results, especially in terms of security behavior. The next question was whether FV found more valuable bugs that simulation. Daryl admitted that FV is held to standards that simulation is not. Lots of hard bugs are found with formal and lots of trivial ones are found with simulation/testbench. The most important, in terms of keeping senior management on board, is that "this would have been a Cat A error not caught by simulation and you'd have been on a plane." He was asked about latency, handling requirements that certain operations complete within a certain number of clock-cycles. He said that this isn't an architectural issue, but a micro-architectural issue. Nonetheless, some performance issues are amenable to being expressed as properties, but some are not. "Don't oversell formal," he joked to the Cadence team, "you still want to sell us other tools." Previous: Red Hat's Mr ARM Talks Open Source![]()
![]()
↧