Date: 28 FEB 2001
From: Theerayod Wiangtong
To: Peter Y.K. Cheung
Progress Report (No.8)
Reporting Period: 16-28 FEB 2001
Codesign tools approaching
Introduction
As mentioned earlier in the previous progress report, there are a lot of codesign tools support in design market from both non-profit organisation and commercial research group. However, none of them is fully automated codesign tools. Plenty of problems occur because of heterogeneous design aspect between hardware and software. More work needs to be done to improve any incomplete design features, for example hardware software partitioning scheduling and software code generator.
I selected few design tools to investigate any common looks and differences in order to get some idea how those of design tools can be used for designing. Handel-C (based on C language) is the first priority to study because there is information provided from Wyne Luk who was the member of development team while doing his research at Oxford university. SystemC (based on C++) is quite new for system level design language. Interestingly, well know software companies are members of steering group such as Synopsis, Cadence, Coware, Lucent Technology. Polis and Ptolemy from UCB are quite widely known in embedded system design and almost found in papers related to hardware software codesign. So something about these design tools should be interesting.
Notice that we try to create a new language that easy to deal with for design engineer and push all tedious tasks to computer. In digital design world in the last decade, two dominants hardware description language are including VHDL and Verilog used to simulate and being a source code for several synthesis tools. When FPGAs are introduced, HDL is increasingly significant. There is the rapidly growth in FPGA technology in terms of gate density, faster speed, low cost inclination. These support the high complexity of design circuit and also SRAM based technology which supplies boundless reconfiguration times make FPGA more attractive. We could say that this technology is addressed between ASIC custom and processor because of capability in reconfiguration, in other words reprogramming. Design time in FPGAs is very short when compared with ASIC or custom design and also a high speed when compared with processor. Unsurprisingly, many systems are forced to integrate FPGA in order to get rid of any drawbacks and hardware software; codesign is a very obvious example.
Because of the high complexity of design system today, HDL language which used to describe system in RTL or behavioural level seems to be not practicable to support codesign and a short time-to-market demand. A new language that support system level design that can work for both hardware and software is more feasible. There are various ways to build that language. Probably, it can be achieved from the existing well know language such as VHDL or C/C++ or creating a new language.
Many new system design languages come up and mostly used for particular design such as SDL, Esterel, Lotos. None of them can be used to describe system in relatively wide application domain. For VHDL or Verilog which is hardware description language and supports both sequential programming and concurrent programming, however, it lacks the ability to describe hardware at system level. There are many efforts to add up that capability in HDL but rarely to be accepted from customers. Sometimes, the reasons that software is a main part of system and everyone basically knows programming language, C/C++ becomes the most attractive choice to define the new system level design language. However, some extra features have to be attached to provide more capability such as how to describe design constraints, how to model hardware that works concurrently, how to define clock in order to achieve timing simulation. Handel-C and SystemC are both based on C/C++ language.
What is system design language?
Fundamentally, a system design language is a notation that embodies semantics for describing a system prior to mapping it onto an architecture [2]. There are few important aspects of this design language as follows.
-
It must have a way to describe the behaviour of the components in the system irrespective of whether they will be mapped to software running on microprocessor or mapped to hardware like ASIC or FPGAs.
-
It should support notions of structure and hierarchy that allow the complex system could be separated into small blocks.
-
It must include the ability to incorporate the description of design constraints such as ordering, timing, concurrency, and task scheduling between hardware and software.
Handel-C
Handel-C is a programming language and firstly aims to be a single programming language which can be used for completely generating hardware and software system. This design language is proposed for solving problem of tomorrow’s large scale design and will replace hardware description language that currently used in digital system design.
H
Figure 1. Handel-C design flow
andel-C is based on C language; in other words, it is the subset of C language. However, the extra features to assist hardware design aspect are added including parallelism, communication, sharing, arbitrary width variables and timing. Handel-C allows programmer or designer to create software in the form of parallelism to be able to describe hardware working concurrently. It provides the way to set communication channels used to communicate between parallel blocks. The ability of determining variable width is important for saving space and interfacing with external systems.
The timing model in Handel-C is very simple but effectively useful for timing simulation. The rule of timing is that an assignment statement takes only one single clock cycle to execute. Also the Handel-C is claimed that user can take advantage of parameterisation and customisation possible with FPGA based processor [1].
In design process (see figure 1.), Handel-C compiler is used for parsing design and making .net for simulation. The simulator can be invoked by either compiler command (c:>handelc –s file.c) or simulation command (c:>hsim [option] file.net). The system could be changed by appropriately modifying program in Handel-C language until the results from this system level simulation meet the design specifications. The next design step is to implement in hardware design like FPGA chip. Currently it only supports chips from Xilinx and Altera.
Handel-C allows user to add the necessary hardware interface for example there are commands used to set family and device number of the target FPGA chip. Pins could be located formerly from Handel-C even they could be done in commercial FPGA development tools. The netlist file compatible with predefined FPGA device is then created by using Handel-C compiler command. For example, “c:>handelc –x file.c” is for Xilinx XNF netlist or “c:>handelc –edif file.c” is for Altera netlist input file. The compatible netlist file is employed by other FPGA design tools to place and route circuit and finally implement in the real chip.
Summary
Handel-C is not fully automated design tools for codesign though it firstly aims for being a single codesign programming language. Notice that there is no partitioning or scheduling in design process using Handel-C or software code in predefined processor. Programmer must give a secondary control along with design flow. It seems like Handel-C is used for only hardware flow in system. Nothing mentioned in manual is related to software flow.
Dash (Design Automation for Software and Hardware) compiler is the work carried out from the same group who developed Handel-C. It provides co-simulation and co-synthesis and also works together with Handel-C compiler as seen in [1]. Software parts are compiled using Dash-S and support for different processors. Dash-H is used for hardware compilation. However, partitioning is pushed to be the task of user for making decision rather than automatically done by design tools.
SystemC
In 1999, many software companies in design industry made a major step to establish a new standard design language called SystemC [2] which is based on C++ programming language; that supports OOP (Object Oriented Programming) and dominates software programmers around the world. The OOP is suitable for a large and complex programming because processes are seen as objects and encapsulated. There are only communication channels between objects via defined parameters or functions. So it is quite flexible to add a new aspect through class library to describe hardware designs at the system level.
Generally speaking, SystemC is a C++ class library that can be used to effectively model and simulate both software and hardware in the system level design. C++ compilers from both Borland and Microsoft are able to compile and generate results from the test bench written in SystemC. Surprisingly, it’s open system that let everyone to create model and share together under the same standard rules from SystemC.
Like Handel-C, there are some features created in class library to support hardware design aspects. SystemC provides the essential classes and basic rules for hardware software codesign. The benefit of using SystemC class library is that it lets designer to express such hardware concepts as concurrency, parallelism, ports, wires, new data types and reactivity.
Figure 2. Design flow
(a)Current design flow (b) SystemC design flow
Figure 2(a) is the current design flow that the systems are model and verify in system level first. After that, to implement in a real chip, the system level models are manually converted to HDL language such as VHDL or Verilog. This manually design step is risky to make a mistake so designers have to be very careful. This design flow is not effectively used when system is very complicated. SystemC tries to integrate design flow to be unity as depicted in figure 2(b). Design system could be refined in both high level (abstraction level) and low level (RTL level).
Hardware and software partitioning is done at the high level since it is faster and easier than that in lower level. Then hardware modules are mapped to implement in real architecture. Software modules are divided into sub-task and inter-task communication. However, in software part, it is currently under development.
SystemC simulation is a cycle-based. Processes are executed and signals are updated at clock transition. There is a library that handles all events of signal. Also, SystemC provides functions that let user creates output files used to viewed in standard waveform viewer.
Summary
There are manual and free evaluation software downloaded from internet. The design examples are available when installing SystemC software. The design guide seems like language reference guide. It describes only details about SystemC library classes, how to design system using SystemC language, how to describe processes, ports and signals, data types etc. The completed design flow is not explicitly shown in the manual for example how to compile, simulate or convert to netlist file.
Polis and Ptolemy
Polis and Ptolemy are both the results from research groups at University of California at Berkley. Ptolemy is designed for either working with Polis as simulator or stand-alone simulator. The design step is similar to conventional codesign flow but targets are likely emphasised on embedded system.
Esterel is selected to be a most compatible input design language for Polis. Details of Esterel which is also a high level design language are not yet read. But, basically, Esterel is a synchronous programming language, which is devoted to programming control-dominated software or hardware reactive systems. Contrarily to interactive systems, reactive systems are purely input-driven and they must react at a pace that is dictated by the environment. Process controllers or signal processors are typical reactive systems [3].
The design steps in Polis flow are briefly described as follows.
-
Design entry: System designers write an initial specification of embedded system by using Esterel language. Then, the input files are compiled into SHIFT format which is internal software hardware interface format and used to specify a set of interacting extended finite state machine call CFSM in Polis.
-
Optimization and generate code for simulation: Graphs described in the shift input file format are then optimised. To be used for running the software in the final implementation, a target microprocessor is selected. Estimation tool is run to give an idea of the size and speed of the resulting software after already defined the target microprocessor. C code (.c) and Ptolemy code (.pl) are generated preparing for the next simulation.
-
Simulation in Ptolemy: Ptolemy is run to examine the interconnection, set parameters, verify the design. Notice that hardware software partitioning is done or refined to improve performance during this design step.
-
Generate codes for both hardware and software: For software synthesis, CFSM is translated into S-Graph which is reduced form of the control flow graph. Then S-Graph is used to generate a portable C code that can be input of any available compiler to implement and optimise it in a specific micro-controller instruction set. For hardware, RTL (VHDL) code is created corresponding to S-Graph that interpreted as FSM with one state for each S-Graph node. In addition, VHDL code can be created directly from Shift format using shift2vhdl command from the shell.
-
Real implementation: C code which is software part is compiled to be a specific instruction set for the target microprocessor by using available compiler. For hardware, VHDL can be converted to netlist file and then mapped to real hardware architecture. Finally, the reconfiguration files is downloaded to FPGA chips; e.g. from Xilinx or Altera, and machine code is likewise stored in memory to run the microprocessor.
Summary
The main aspect of Polis that distinguishes it from other design methods, both for hardware and software design, is the use of globally asynchronous, locally synchronous formal model of the design in order to support “neutral” specification of hardware and software components. This model is called Codesign Finite State Machine (CFSM). Polis does not provide any hardware software partitioning yet. It only offers a flexible environment that supports hand-partitioning and where automatic partitioning can be embedded. Partitioning might happen and interact with designer within Ptolemy.
Future tasks
As described above, all of the codesign tools are not fully automated. Some parts of design steps are leave for user to manually finish or make decision. Polis reveals that graphs representation is the most important part to optimise and synthesise circuit. Partitioning and Scheduling are obviously seen that they needs to be developed and then integrated into design tools. Thus the next interesting topics to be investigated will be data flow graph partitioning and scheduling.
References:
-
J.M. Saul, “Hardware/Sofware Codesign for FPGA-based System”, Proceedings of the 32nd, International Conference on System science, 1999.
2. Steven E Schultz, “The new system level design language”, Integrated system design, july 1998.
3. G´erard Berry,” The Esterel v5 Language Primer Version v5 91”, July 27, 2000
-
http://oldwww.comlab.ox.ac.uk/oucl/groups/hwcweb/handel/index.html
-
http://www.esterel.org/home.htm
-
http://www.systemc.org
-
http://www-cad.eecs.berkeley.edu/~polis/
-
http://ptolemy.eecs.berkeley.edu/
-
Matthew Bowen, “Handel-C language reference manual”, Version 2.1, Embedded Solutions Limited.
-
Synopsis, Coware, Frontier Design Inc., “SystemC version 1.1 User’s guide”, 2000
-
Felis Balarin, Messimiliano Chiodo, et al, “Polis User’s Manual Version 0.4”, University of California at Berkley November 10, 1999
-
Ian Page and Geoff Randal, “Using Handel to Accelerate System Development”, Fast Prototyping of IC Designs, IEE Colloquium ,1994 , Page(s): 5/1 -5/5
Share with your friends: |