The main phases in the TCE are illustrated in Figure 2.1 and listed in Table 2.1 The TCE design flow starts from an application described in a high level language (currently the C language). The initial software development phase is intended to be separate from the actual co-design flow of TCE. That is, the program is expected to be implemented and tested natively (on a workstation PC) before ``porting'' it to the TTA/TCE platform. The porting includes ensuring that TTA/TCE runs the program correctly, and optimizing the hardware together with the software by modifying the resources and architecture of the processor to fit the application at hand - a process called hardware/software co-design.
Once the user has implemented the software based on requirements, he designs a TTA processor with a graphical tool, or selects an existing TTA, and compiles and simulates the SW. Both compiler are simulator are retargetable so they need an architectre definition as input in addition to SW source codes. The instruction set simulator (Proxim or ttasim) produces statistics about cycle counts and utilization of function unit, to assist in iteration of the SW of TTA HW until results are satiscatory.
The LLVM compiler framework [llv08] is used to compile the application to 'bitcode', the intermediate representation of LLVM. The resulting bitcode is then compiled and scheduled to a particular TTA processor by TCE. Traditional compiler optimizations are done in LLVM before bitcode generation, so it is possible to utilize the same bitcode file when exploring different TTA processors for running an application.
Once the performance requirement is met, the user maps the architectural resources i.e. function units and register files, to their respective RTL implementations which are stored in Hardware Databases (HDB). The distinction between architectural models and component implementations makes it possible to have several implementations, each e.g. targeted for different FPGA families or ASIC technologies, stored in HDBs. Ideally, changing the target platform might only require changes to the implementation mapping without any changes to the architecture.
After the implementation mapping, the Processor Generator (ProGe) can produce synthesizable HDL, which instantiates all FUS and creates the interconnection network and control unit, which is responsible of fetching, decoding and issuing instructions. ProGe tool also includes a platform integrator feature which can interface the TTA with memory components of an FPGA board and create synthesis settings. Moreover, the platform integrator can ``package'' the TTA (and optionally also the SW) into an easily re-usable format. In practice, this means generating IP-XACT documents which describe the details in XML. Synthesing and simulating the HDL are done with 3rd party tools, such as Altera's Quartus and Mentor Graphics' Modelsim.
Finally, Program Image Generator (PIG) is utilized to convert the compiled SW format into actual binaries. PIG supports various different output formats ranging from plain binary format to FPGA vendor specific embedded RAM formats.
More details about the tools and design phases are given in Chapters 4.1 - 6. The TCE tour tutorial in section 3.1 provides a hands-on introduction to the design flow.
|ProDe||Define FUs, registers, intercconects of TTA core||GUI||.adf|
|Proxim||Simulate TTA cores (architectural level)||GUI||report|
|ttasim||Simulate TTA cores (architectural level)||CLI||report|
|OSEd||Operation Set Abstraction Layer database editor||GUI||operation db|
|HDBEditor||HW implementation database editor||GUI||HDB|
|ProGe / generateprocessor||Generate HDL||CLI (+GUI)||VHDL or Verilog|
|PIG / generatebits||Generate program image||CLI||e.g. .mif|
|Platform integrator||Interface with memories, generate IP-XACT||CLI||e.g. .xml, project files|
|3rd party Synthesis||Convert VHDL to netlist and program FPGA||G/C||e.g. .sof|
|3rd party Simulation||Simulate VHDL||G/C||report, .wave|
Pekka Jääskeläinen 2016-11-24