LISA

LISA
Description Language for Hardware and Software

The language LISA is aiming at the formalized description of programmable architectures, their peripherals and interfaces. It was originally developed to close the gap between purely structural oriented languages (VHDL, Verilog) and instruction set languages for cycle-accurate simulation purposes of a wide range of modern programmable architectures (DSPs and microcontrollers). The language syntax provides a high flexibility to describe the instruction set of various processors, such as SIMD, MIMD and VLIW-type architectures. Moreover, processors employing heavy pipelining can be easily modeled. This includes the ability to describe architectures with complex execution schemes as e.g. out-of-order execution of instructions.

The process of generating software development tools and synthesizing the architecture requires information on architecture properties and the instruction set definition as depicted in the following table.

  memory 
model

resource
model
behavior
model
instruction
set model
timing
model
micro-
architecture
model
HLL compiler register allocation instruction scheduling instruction selection - instruction scheduling -
assembler - - - instruction trranslation - -
linker memory allocation - - - - -
simulator simulation of storage - operation simulation decoder/ disassembler operation scheduling -
HDL generator basic structure write conflict resolution - instruction decoder opereation schduling operation grouping

Table 1: LISA processor models


These requirements can be grouped into different architectural models - the entirety of these models constitutes the abstract model of the target architecture. The LISA machine description provides information consisting of the following model components.

  • The memory model lists the registers and memories of the system with their respective bit widths, ranges, and aliasing. The compiler gets information on available registers and memory spaces. The memory configuration is provided to perform object code linking. During simulation, the entirety of storage elements represents the state of the processor which can be displayed in the debugger. The HDL generator derives the basic architecture structure.

  • The resource model describes the available hardware resources and the resource requirements of operations. Resources reproduce properties of hardware structures which can be accessed exclusively by one operation at a time. The instruction scheduling of the compiler depends on this information. Moreover, the HDL code generator uses this information for resource conflict
    resolution.

  • The instruction set model identifies valid combinations of hardware operations and admissible operands. It is expressed by the assembly syntax, instruction word coding, and the specification of legal operands and addressing modes for each instruction. Compilers and assemblers can identify instructions based on this model. The same information is used at the reverse process of decoding and disassembling. The HDL generator derives the instruction decoder
    from this model.

  • The behavioral model abstracts the activities of hardware structures to operations changing the state of the processor for simulation purposes. The abstraction level of this model can range widely between the hardware implementation level and the level of high-level language (HLL) statements.

  • The timing model specifies the activation sequence of hardware operations and units. The instruction latency information lets the compiler find an appropriate schedule and provides timing relations between operations during simulation.

  • The micro-architecture model allows grouping of hardware operations to functional units and contains the exact micro-architecture implementation of structural components such as adders, multipliers, etc. This enables the HDL generator to generate the appropriate HDL code from a more abstract specification.

 

Besides this information provided by the LISA language, which is essential for retargeting the software development tools, one of the key aspects in architecture development is the ability to abstract on multiple levels of accuracy. However, it is of course mandatory that a working set of software development tools can be successfully generated independently of the abstraction level.

Figure 1 : Abstraction of architecture


Abstraction can be applied in two different domains: architecture and time. Both domains are closely correlated with each other since it is unlikely that spacial accuracy is set to the level of micro-architecture implementation whereas temporal accuracy is that of the boundary of high level language statements.

Architecture development usually starts with an untimed specification of the algorithm that is to be mapped onto a programmable architecture. At this point the designer realizes a bit-true version of the processor´s data-path abstracting the granularity of hardware resources and behavior to the level of a pure data-flow model of the target architecture. When the data-flow model meets the requirements of the algorithm, the model is refined and the instruction-set is introduced. For this purpose, hardware granularity and behavior are refined by adding data and program memories to the model as well as an instruction sequencer. This model -- the instruction-set model -- can then be used to explore the instruction-set by profiling the application on the target architecture. Once the instruction-set is fixed, different micro-architecture implementations are examined that implement the instruction-set. For this, structure and behavior are once again refined by adding hardware details such as pipelines, peripherals, caches, I/Os and interrupt controllers. At this level representing an architectural model of the target architecture, the model contains enough structural details to co-simulate or even synthesize hardware structures.


Figure 2 : Abstraction of time


As it is necessary to vary the granularity in which structure and behavior are described, the same applies to abstraction of time. Temporal accuracy in an early stage of the design can be limited to the boundaries of HLL statements which can only represent an estimate of the exact time needed for the execution of a fragment of the application -- this is useful to evaluate e.g. whether real-time constraints can be fulfilled. Time can then be refined to the boundaries of processor instructions which is typically know as cycle-count accuracy. For co-simulation purposes with HDL simulators or even HDL synthesis, time can further be refined to the level of cycles or even phases within instructions.

 

LISA

The Language for Instruction Set Architectures

More Infos


Contact: Anupam Chattopadhyay, Felix Engel, Manuel Hohenauer, David Kammler, Ernst Martin Witte, Gunnar Braun, Andreas Hoffmann, Tim Kogel, Achim Nohl, Andreas Ropers, Oliver Schliebusch, Oliver Wahlen, Andreas Wieferink

News >> News >> News

ICE at the Design, Automation & Test Conference 2014

ICE will be well represented at the Design, Automation & Test Conference 2014. It takes place

Electronic Design Automation Lecture Update

The first lecture of the Electronic Design Automation course with Dr. Hoffmann was moved to April

TETRACOM Kickoff

The kickoff meeting of the TETRACOM project took place at the UMIC Research Center on Monday,

User login

Login

Forgot your password?