Synopsys Processor Designer

The architecture exploration framework applied in this thesis builds on the Synopsys Processor

Designer, a tool platform for embedded processor design available from Synopsys Inc. [96]. The

Synopsys tool-suite revolves around the LISA 2.0 ADL. An earlier version of this tool-suite and the ADL itself has been described in detail in [152]. Amongst others, it allows for automatic gen- eration of efficient ASIP software development tools like instruction set simulator [217], debugger, profiler, assembler, and linker, and it provides capabilities for VHDL and Verilog generation for hardware synthesis [240]. A retargetable C-compiler2 _{[153] is seamlessly integrated into this tool}

chain and uses the same single “golden reference” LISA-model to drive retargeting. A method- ology for system level processor/communication co-exploration for multi-processor systems [270] is integrated into the LISA tool chain, too. It is supposed that such an integrated ADL-driven approach to ASIP design is most efficient, since it avoids model inconsistencies and the need to use various special-purpose description languages.

Architecture Description Language: LISA

A LISA-model can be roughly structured into the processor’s ISA and a description of its resources like memories, register file or pipeline. Resources are modeled by a separate section inside the processor model. All herein declared resources are global to all instructions in the model.

The hardware instructions of the ISA are composed of microarchitectural Operations that model the ISA of the processor in a distributed manner, i.e. Operations represent inherent process steps of certain instructions. If the processor model contains a pipeline, each Operation is assigned to an appropriate pipeline stage. Typically, a hardware instruction can be described via several aspects like assembly syntax, coding and microarchitectural behavior. These aspects are specified inside the Operations of an instruction within appropriate sections. Additionally, Operations contain an Activation-section for the purpose of triggering subsequent Operations. Since multiple instructions can share common parts of the pipeline execution (e.g. instruction fetch), Operations form a rooted tree in which predecessors are shared by its successors.

Figure 4.4 exemplifies a simplified version of the LISA Operations tree for the IRISC architecture (c.f. Appendix A). All instructions share one common part of the Operations tree consisting of

Pre-Fetch (PFE), Fetch (FE) and Decode (DC). In the DC stage of the pipeline, the Operations

tree branches to arithmetic, branch and load/store Operations. Each of these paths branches again at the Execute (EX) stage in correspondence to the appropriate instructions. Finally, in

2

4.1. System Overview 61 FE DC EX WB instruction fetch instruction decode load/store write back memory load shift mul add main arithmetic branch Arith.-Op. fetch Mem.Op. fetch Address. fetch jmp call load store PFE instruction Pre-fetch Operation Activation Root Operation Syntax Coding Behavior Activation

Figure 4.4– Example of operation tree in LISA.

the Writeback (WB) stage, the Operations tree consolidates. To implement new instructions, the tree can only be extended by new Operations in appropriate pipeline stages.

Software Development Tools

Based on the LISA-description of a processor, the Synopsys Processor Designer provides the generation of a software development tool-suite, which covers the entire range from assembly source code processing to simulation plus a Graphical User Interface (GUI) for debugging. Assembler: The generated assembler translates text-files composed of symbolic instruction

names into object code for the present processor prototype. Additionally, the LISA gener- ated assembler features a set of directives for comfortable handling of data initialization and a reasonable separation of programs into sections.

Linker: Since large programs typically consist of multiple, separately assembled modules, LISA offers the generation of a linker to combine these modules into a single executable object file. A linker command file has to be provided by the user that has to keep a detailed model of both, the target memory environment and an assignment table of the module sections to their respective target memory area.

Simulator and GUI: The simulator generated from the LISA-model uses the technique of com- piled simulation. The simulator comes with a generic GUI to visualize the internal states of

62 Chapter 4. Case study: Compiler-Agnostic Architecture Exploration

the simulation process. C-source code and disassembly of the simulated application are dis- played as well as all registers, pipeline registers and memories of the underlying architecture prototype.

Moreover, the Synopsys Processor Designer supports a methodology for MP-SoC communica- tion/processor co-exploration. This methodology allows for seamless integration and evaluation of multiple LISA processor models with SystemC-based communication platform models.

Compiler Designer

The Synopsys Processor Designer provides the semi-automatic generation of an appropriate compiler for a given processor model written in LISA. Here, relevant architecture information (e.g. available registers) is read from the model and is automatically considered during the com- piler generation. However, a major part of information is not retrievable from the processor itself (e.g. calling convention) and has to be specified by the user. Therefore, a GUI is provided that can be applied to complete the required information. The GUI is structured into several dialogs, which guide the user through the process of configuration. Each dialog handles a different aspect of compiler specification: register allocation, layout of data types, available nonterminals, calling

conventions, instruction scheduling and pattern matching. The outcome of the Compiler Designer

is a set of Code Generator Description (CGD) files, which describe the entire backend of a com- piler. CGD is a proprietary file format of Associated Compiler Experts (ACE) from Amsterdam. The company is the vendor of a compiler framework called CoSy [32] that is used as a backend of the compiler designer.

CoSy Compiler Framework CoSy features a modular structure consisting of loosely cou- pled engines that operate on the CoSy Common Medium Intermediate Representation (CCMIR). CoSy comes already with a large set of standard engines, each of which captures a single process- component of compilation, but is additionally open to new implementations of engines. Further- more, CoSy offers numerous configuration options both at the IR and the engine level. For this purpose, CoSy provides the Full Structured Definition Language (fSDL) and the Engine Descrip-

tion Language (EDL). The fSDL serves as an extensible specification language for the elements

of the CCMIR in a distributed fashion, i.e. the CCMIR is a collection of fSDL-defined elements. Every engine contains a fSDL-specification of all elements it wishes to access during its runtime. Based on this view, CoSy creates for each engine the Data Manipulation and Control Package (DMCP). This is a set C-functions and C-data-types that can be used to access the CCMIR inside the engines’ source code.

The EDL is used to describe the order of engine execution during the process of compilation. One of the most important engines of CoSy is the Backend Generator (BEG). BEG consumes CGD files as input and produces automatically a set of algorithms like code-selection, register-allocation and instruction-scheduling that are used by other engines to implement a backend for a given

4.2. Target Application 63