Redefining firmware

The role of programmable logic is changing, thanks to a system level development environment that targets partially reconfigurable fpgas. The concept of an fpga that can be partially reconfigured while the system is still running has been a design challenge for many years. In fact, the challenge has its own acronym; SWAP (space, weight and power). This acronym reflects accurately the concept of partially reconfigurable logic by encapsulating both the function and the benefits it offers. The idea that an fpga could be used to provide multiple functions in a system, albeit sequentially, makes perfect sense and meets the three criteria of reducing size, weight and power at a system level. Initially, the challenge for fpga vendors was accommodating partial reconfiguration in the logic fabric – which has since been demonstrated. However, the next hurdle has been making use of that feature, something that hasn't been addressed quite so successfully. The problem stems not from the hardware being able to integrate partial reconfiguration, but how to express that at the design level and then implement it. Designing fpgas is inherently achieved using a hardware description language (hdl) such as Verilog or Vhdl. But while an hdl is very good at describing hardware, hardware has little, if no, concept of 'change'. Essentially, hardware is hard wired and fpgas mimic this using configurable interconnects. In that respect, they also have no concept of 'change'. Although partially reconfigurable logic is also 'hardwired', there are times when it is not. For this reason, describing reconfigurable logic in a traditional HDL has been difficult, which means the benefits have been largely out of reach. Runtime reconfiguration The EU funded ANDRES – Analysis and Design of runtime REconfigurable heterogeneous Systems – project, which recently reported results and its expectation for a commercially available solution in 2010, addresses this problem directly at a system level. Taking each part separately, we can address the analysis and design aspects by defining what is meant by a runtime reconfigurable heterogeneous system. Primarily, heterogeneous means different and, in this instance, refers to four domains – software, analogue/mixed signal, static hardware and reconfigurable hardware. Clearly, the last point is also where 'reconfigurable' applies, but the inclusion of 'runtime' is interesting. ANDRES has developed an environment that allows the analysis and design of a system employing runtime reconfigurable logic, in the form of an fpga that can be partially reconfigured while the system is still running. The project has two major industrial partners; DS2 and Thales. Both hope this will deliver on what SWAP has been promising for so long. ANDRES project coordinator Dr Frank Oppenhiemer said: "FPGAs – in our case, the Xilinx Virtex 4, 5 and now 6 – allow partial reconfiguration of the device by designating part of the device to be runtime reconfigurable. It can then accept a partial bitstream to reconfigure just that part of the device." This can be useful when using, for example, encryption algorithms; it may be necessary to provide a large number of encryption algorithms, but it is likely that only one will be used at a time. By implementing the algorithm in reconfigurable logic, it isn't necessary to implement all of the algorithms in hardware all of the time. "Thales sees great potential in the technology, but the problem is that existing tools aren't up to the task," added Dr Oppenheimer. The ANDRES solution overcomes the limitations of existing HDLs by moving to a higher level of abstraction for the design stage, which has the added benefit of allowing all domains to be designed – or modelled – at a high level. The team chose SystemC as the modelling language, partly because it is object oriented. "SystemC offers an object oriented approach; without it, this would be almost impossible. Also, we are targeting heterogeneous designs and an HDL is not very useful when designing software," commented Dr Oppenheimer. Another important attribute of SystemC is that it can be extended using libraries. This enabled the ANDRES team to define a library specifically targeting reconfigurable design, which it calls OSSS+R: "Reconfigurable objects contain different instantiations of dynamic objects," explained Dr Oppenheimer. But, perhaps more importantly, SystemC uses classes – in particular, polymorphic classes. This means that although it is defined by a class, the object content may change, but its interface at the system level remains the same. So, while the description for the interface stays the same, the object may change at runtime, thereby addressing the challenge of designing the partial reconfiguration of hardware in a description language. Holistic approach With the right libraries, an entire system can be modelled in this way – even software. Embedded software development is addressed within ANDRES using HetSC; an extension of SystemC in the form of a methodological library which supports heterogeneous specifications. From such a specification, C++ elements can be extracted and passed to a compiler targeting a specific microprocessor architecture. With the right model, even multicore processors could be targeted, although Dr Oppenheimer expressed that multicore processing is not addressed directly by ANDRES. The ANDRES environment operates at two levels. Dr Oppenheimer explained that, at a high level, the ANDRES environment isn't concerned with implementation beyond defining tasks. At the next layer, the virtual target architecture layer, this becomes more specific, with cycle accurate timing for the hardware domain. Through analysis, the partitioning can be modified and optimised, but it does require the right models in order to do that. By choosing SystemC, the ANDRES team anticipates that industry will help develop and donate those libraries. Crucially, at a lower level, the ANDRES environment also provides for implementation using the FOSSY tool. FOSSY, or Functional Oldenburg System SYnthesiser, transforms SystemC into synthesiseable Vhdl, which is then passed off to vendor specific tools (such as place and route). The concept approaches a 'push button' design flow using a high level of abstraction to create cycle accurate models of hardware, interfaces and communications buses, with provision for estimated timing for software. While Dr Oppenheimer admits that nothing is ever as simple as 'pushbutton', the level of analysis provided by ANDRES, integrated as it is with the design flow, means the approach probably comes closer than any other environment currently available. While high level modelling in general, and SystemC in particular, is still confined largely to niche applications, Dr Oppenheimer believes European companies are now adopting SystemC in a meaningful way. "The motivation for this project was twofold; while it is already possible to model a runtime reconfigurable system, designing it has been difficult. Also, the message coming from the industry is that there is a disconnect between existing simulation and design flows." The analysis and design aspect of the ANDRES environment addresses this directly. "There was a need for a language flexible enough to cover all domains, taking a holistic approach," he concluded.