Productos de aporte

The designer can with this method choose to explore different architectures at a very

early stage of the development process. As shown in Figure 3.10, alternative concrete

representations can be derived from the specification, translated automatically using a TRS mapper to a Bluespec or CAL representation and then passed to tools downstream in the flow that predict the performance and power consumption of the target hardware. This feedback from downstream tools then allows the user to select the appropriate concrete representation or explore further alternatives. Where an existing design is to be targeted to a new hardware platform, architectural decisions can be revisited at the specification level. !"ent-' Re*+nement an. /0rmal Pr00* 4ruste. 70m80nent 70ncrete :8ec+*+cat+0n ; 4R: 4R: <a88er 70ncrete :8ec+*+cat+0n ;; 4R: 4R: <a88er A>stract :8ec+*+cat+0n

Figure 3.10: Event-B Architectural Exploration

In general, increasing concurrency can increase performance, but will increase power consumption. Reducing the clock speed, however, reduces power consumption at a

greater rate than it is increased by exploiting concurrency [Kumar et al.,2003]. Therefore

architectural solutions which maximise concurrency are often desirable, and is the reason that modern SoCs incorporate increasing numbers of processor cores. It is also the

reason that pipelining [Hennessy and Patterson,2006] is so widely exploited. Pipelining

uses shared registers to communicate between simple, specialised pipeline stages. The simplicity of each stage contributes to keeping power consumption low because the low gate count minimises the amount of transistor switching. Similary, shared registers can provide an efficient mechanism for communication between state machines.

For synchronous design, however, shared register communication can only be used for lo- calised, intra-component communication, because the logic synthesis tools cannot man- age the global track delays between components located in non-adjacent areas of the chip. This issue will be dealt with in detail in the next chapter. Transaction Level

Modelling (TLM) [Ghenassia,2006] and Network on Chip (NoC) technology [Gebhardt

and Stevens,2008] have evolved to meet the requirements for inter-component commu-

nication on SoCs and, in particular, to support component re-use.

To raise architectural exploration and re-use to the specification level it is essential that the issues of inter- and intra-component communication can be addressed at this level, before synthesis. It is therefore important that the specification method supports both component and sub-system design and it is an key goal of the following chapters to show that specification refinement with formal proof can be used, starting with an abstract specification, to develop, systematically, alternative sub-system architectures to meet differing performance and power consumption goals.

Developing SoC Components

This chapter looks at the use of the Event-B method for developing SoC component specifications, and how this relates to the restrictions that hardware process technology places on component size. It first looks at the modelling and refinement of finite state machines in general and then looks at pipelined architectures and the implications that such architectures have for how simultaneous pipeline events are managed. It concludes with a detailed investigation of how latency can be managed in an IP Lookup circular pipeline.

The contribution described in this chapter is the development of a method where an abstract specification of an SoC component can be refined formally to derive a con- crete implementation of the component that has a direct correspondence to its HDL description. Whether the concrete implementation is represented by a single process or by multiple processes communicating with shared variables, the method enables the implementation to be verified formally against its abstract specification.

• A single process may be represented in hardware design by a Finite State Machine. • Multiple processes may be represented by a set of communicating Finite State Ma- chines which communicate with message-passing FIFOs or with shared registers. • A hardware pipeline is a special case of a set of multiple communicating processes. An approach is presented where a concrete representation of a single FSM, amenable to hardware synthesis, is derived systematically from an abstract hardware specifica- tion using Event-B refinement. The approach is then extended to show how an ab- stract hardware specification can be modeled, refined and then decomposed to form a concrete, synthesisable pipelined representation, comprising several communicating processes, that has been proved to implement its abstract specification.

This chapter presents the building blocks of the method which will be elaborated in later chapters.

4.1

Restrictions on SoC Component Size

In a modern, low-power System-on-Chip (Soc) development flow it is already possible

to incorporate several microprocessors (multi-core) in a design [Geer,2005] and in the

near future it is feasible that this number could increase to several hundred (many-

core) [Asanovic et al.,2006]. The trend towards multi-processor design has come about

because the constraints of sub-90 nanometre design mean that it is no longer possible

to simply increase processor clock speeds to achieve higher performance [Geer, 2005].

These design constraints, which restrict the size of all hardware processing components,

not just microprocessors, result from several factors, which are explored in [Sylvester

and Keutzer,2001].

First, increases in clock speed increase power consumption and cause heat dissipation problems. Second, the small feature sizes mean that the benefits of faster device switch- ing can be negated by the delays incurred when connecting these devices. Synchronous design tool-chains rely on the combinational logic settling between clock edges and these global track delays therefore restrict the speed at which a component can be clocked. As components get larger and more complex, a corresponding increase in global track delay length is also incurred, limiting the size of components that can be incorporated into a SoC. Third, the capacity limitations of current verification tools, whether formal or simulation-based, coupled with the large cost of verifying complex hardware logic also limits the size and complexity that can be handled. There is therefore a compelling argument for SoC hardware components to be kept as simple as possible.

The detailed investigation of these physical factors in [Sylvester and Keutzer, 2001]

concludes that SoC component size needs to be restricted to between 100,000 and 200,000

gates, and that a Network on Chip (NoC) protocol [Carloni and Sangiovanni-Vincentelli,

2002] is then used to manage the communication between components.

This chapter focuses on the methods required to refine the different types of hardware component encountered on an SoC, from a high-level specification to a representation that is suitable for high-level or RTL synthesis. Chapter 7 will address the development of sub-systems and inter-component communication.