A Co-Synthesis Environment for Embedding Digital Systems in a Sea-of-Gates IC

Transcription

1 A Co-Synthesis Environment for Embedding Digital Systems in a Sea-of-Gates IC João M P Cardoso INESC / Univ. Algarve jmcardo@ualg.pt Horácio C Neto INESC / IST hcn@inesc.pt INESC, Rua Alves Redol 9, 1000 Lisboa, Portugal Abstract: This paper describes a co-synthesis environment for the implementation of embedded digital systems on a single chip quick turnaround sea-of-gates technology. The target architecture integrates a parameterizable 8 bit RISC microcontroller core with application specific hardware functional units able to accelerate the execution of the timing critical system components. The hardware/software co-synthesis is guided by constraint directives added to the software-based system specification. The system proposed provides a suitable environment and an efficient solution for rapid prototyping and low cost small series production of low to medium complexity embedded digital systems. 1. Introduction Typical digital systems consist of hardware components and/or software components executing on dedicated processors. The best performance can be typically achieved by a dedicated hardware solution, while a faster design and a less expensive solution are commonly achieved by software based solutions. Of course, a better tradeoff between flexibility, performance and cost is achievable if a co-design approach able to tune together the software and hardware components is followed [1][2][3][4][5]. Most hardware/software co-synthesis systems [6][7] target system architectures which consist of a generalpurpose processor, memory and application-specific hardware components (see Figure 1). According to the chosen technology and system complexity, the individual components may be implemented as individual ICs on a board or on a multi-chip module, or they can be integrated in the same integrated circuit. Actual VLSI integration complexities already allow for the integration of complex systems in the same integrated circuit and standard cell products with the capability to integrate complex megacells such as, memory, MPU (MicroProcessor Unit), MCU (MicroController Unit), multipliers and other advanced functions, are already available in the market. However, with NRE (Non Recurring Engineering) costs starting at around 100KECUs, these complex IC products are well beyond the reach of the average customer and are therefore not suitable for low cost and/or low volume applications. PROCESSOR MEMORY ASIC ASIC Figure 1. Commonly targeted system architecture. The environment proposed in this article targets low cost single chip solutions, enabled by the use of a fast turnaround sea-of-gates technology processed using direct-write laser based lithography [8][9], adequate for medium complexity applications where timing and area constraints are important. PROCESSOR CORE WDT Timer units PROGRAM MEMORY I/O PORTS DATA MEMORY INTERFACE FUNCTIONAL UNITS Figure 2. Target system architecture of co-synthesis environment. The targeted system architecture is illustrated in Figure 2. The processor core is instruction set compatible with a commercial microcontroller [10] in order to take advantage of existent and well understood standard development tools. The system specification is therefore software based, with timing constraints directives included in the source code to guide the

2 hardware/software partitioning. The functional units (FUs) using dedicated hardware are generated automatically by the co-synthesis environment when timing constraints are violated or functional parallelization is enforced by the designer. 2. The processor core The processor architecture targeted by the cosynthesis environment has been chosen to be instruction set compatible with a commercial microcontroller [10]. The major issues considered for the architecture selection are enumerated below: Core size not very large (8-bit wide datapath); Simple RISC (Reduced Instruction Set Computer) architecture (with a reduced orthogonal instruction set - 33 instructions 12 bit wide), in order to simplify the parameterization; Good performance and code compactation [11] - all single cycle instructions except for program branches or when the target register is the program counter; Compatibility with existent applications and development tools [11] (simulators, crossassemblers, emulators); A power down mode controlled by a sleep instruction for low power consumption; One level of instruction pipelining (fetch of the next instruction in parallel with the execution of the actual instruction). Direct, indirect and relative addressing modes for data and instructions; An internal Timer and WatchDog Timer (WDT); The processor core, designated by PISCPMS 1 [12], is based on the architecture shown in Figure 3. It has been completely specified in VHDL and mapped to a fast turnaround sea-of-gates technology using a commercial synthesis environment. Some of the characteristics of the implemented core are described below: One instruction cycle (CLKOUT) is equivalent to 3 clock cycles (OSC1). Control pipelining (introducing registers between the control and datapath section) has been added in order to have the actual cycle control signals in the beginning of clock (OSC1). The GOTO and CALL instructions are executed in only one instruction cycle (3 clock cycles of OSC1). 1 Parameterized & Instruction Set Compatible PIC Microcontroller for Sea-of-Gates. All I/O ports can be implemented with and are fully reconfigurable. A maximum of 8x I/O ports is currently allowed. Any register can be configured as an output-only port. The number of register file registers is parameterized (with a current maximum of 80x8bit registers). If more than 32 registers are required a memory mapping scheme as described in [10] is used. Program Memory up to 512 x 12 bits RTCC/ WDTCLK 12 bits Instruction Register MCLR VDD, VSS 5 bits Instruction decoder and Control OSC1 OSC2/CLKOUT Synchronizer RTCC (F1) WatchDog Timer Timer Clock generation Program Counter (F2) 9-bits Stack OPTION TRISB Figure 3. Block diagram of the processor core achitecture. Register File (up to 80x registers) MUX Status (F3) MUX 3. Co-Synthesis Environment 5 bits TRISA Port B (F6) Port A (F5) The co-design system environment proposed is sketched in Figure 4. The system specification is currently defined by an assembler program compatible with existent commercial tools (for ex. MPALC [13] and MPSIM [14]). The system incorporates the PISCPMS core described in the previous section. The processor shares the internal bus with the functional units (see Figure 5). In order to maintain compatibility with existent development tools, the interface between the master processor and the hardware units extends the initial arquitecture, to allow parallel execution of the coprocessors, without requiring new specific instructions. For coordinating simulation and migration of the code segments to hardware, two technology files are ALU W FSR (F4)

3 Assembler program MPALC (assembler) MPSIM (simulator) Code segments with constraints extraction Analysis of execution time assembler VHDL sinthetizable ASM to ROM Converter Number of registers necessary SYNTHESIS Library Functions SYNTHESIS SYNTHESIS Program Memory Data Memory Interface FUs PISCPMS CORE Gate Array Figure 4. Co-Synthesis environment. required: one contains the execution cycle number per instruction, the other contains information about the available gate-array chips (maximum gate complexity and number of pin signals in available packages). The migration to hardware and the core parameterization are automated. The parameterized core blocks are specified using parameterized VHDL descriptions which provide an efficient way for automatic block generation. The code segments which violate the performance constraints are migrated to hardware: the corresponding source code is translated to synthetizable VHDL and the hardware is synthesized by a commercial tool guid ed by scripts generated by the co-synthesis environment. The user specifies the performance constraints as directives added to assembler code (the syntax begins with a ; so that commercial assemblers consider the directives as comments). Six types of directives are currently supported by the system: Time constraints directives: ;CONSTRAINT <time constraint> : <label> <TO> <label>] = <execution time>. <time constraint> : MAXTIME MINTIME Concurrent directive: ;PARALLEL : <label> <TO> <label> : <label> <TO> <label> {: <label> <TO> <label> : <label> <TO> <label>}. Specification of clock period: ;CLOCK CYCLE = <period clock time>. Specification of I/O ports: ;PORT_NUMS = <number of I/O ports (default=2)>. Specification of a resource: ;RESOURCE <label> <TO> <label> : <resource name>. Specification of FUs input/output operands: ;<signal type> # <unit number> # <operand byte> [<variable identifier>] EQU <register number>. <signal type> : IN OUT INOUT Generic directive: <label> EQU <identifier>. The concurrent execution of different processes can be forced by direct specification of the code segments (coroutines) parallelizable (with permitted autonomous execution). The code segments specified migrate to hardware and can execute in parallel. This mechanism permits to structure an application as a sequence of independent activities. For each code segment a mechanism like cobegin-coend is used. The cobegin is equivalent to an operand transfer from the register file to the FU and the coend to an operand transfer from the FU to the core processor. These constructions are simple and easy to program. Example 1 shows examples of directives that specify a maximum execution time for a code segment, a minimum

4 time execution for other segment, that force the two code segments to be concurrent, and that define the core processor clock cycle as 33 ns. Code segments whose execution time depends on the value of any operand (statically unbounded) can not currently be automatically migrated to hardware. However, the user can still design these units manually, or guide interactively the co-synthesis system to a migration of the internal code segments of the non deterministic cycles. In the later case, the resulting solution implements the iteration in hardware but controlled by the software. Example 1. Example of assembler directives ; CONSTRAIN MINTIME : label3 TO label4 = 2 us ; CONSTRAIN MAXTIME : label1 TO label2 = 1 us ; PARALLEL : label1 TO label2 : label3 TO label4 ; CLK_CYCLE = 33 ns This limitation will be solved by allowing these non deterministic code segments to be translated to VHDL and synthetized with an high level synthesis tool to a hardware control-datapath unit. 4. Hardware/Software Interface The processor bus is used as the communication interface between the core and the functional units (see Figure 5). This interface solution allows the addition of functional units, as peripheral components, with low additional cost. The core acts as master of the bus and is responsible for the synchronization with the functional units. The transfer of an operand from the register file to the hardware units, or vice-versa, requires the modification of the 3 bits of the status register. This task is done with 2 instructions (see Example 2 and Example 3). ld_b ld_w ALU W B enable_w B0 W0 B1 FUNCTIONAL UNITS W1 B6 W6 The MOVF instruction, which transfers a register content to the W register (or to the proper register, when we want a zero detector), collocates the identified register content in the bus, and loads the B latch with it. The control unit generates the signal ld_b to perform this task. When the 3 most significant bits of the status register are different than 000, the operand in the bus is loaded to the latch of the corresponding hardware unit. Example 2. Operand transfer from register file to FU: MOVLW MOVWF 3 MOVF operand identifier register number to transfer Example 3. Operand transfer from FU to register file: MOVLW MOVWF 3 MOVWF operand identifier register number to transfer The results of the functional units are communicated to the core using the MOVWF instruction in a similar way. This instruction transfers the register contents of W into a specified register. The value in W is transferred to the bus when the control signal enable_w is activated. According to the descodification of the 3 msbs of the status register, the selected operand (register W or one of the unit registers) is transferred to the bus. The maximum number of input/ouptut operands currently allowed for the FUs is 7, because the identification is done by the 3 most significant bits of the F3 register (status register). Alternative mapping schemes can be implemented, such as register bank interfaces, if required by more complex applications. However these alternatives are not yet automated by the co-design environment. The main characteristics of the proposed interface are thus: The transfer between operands from the core to the FUs is done without changing the basic instruction set. Each transfer of is performed with 3 instructions (3 instruction cycles). I/O port accesses are also done in 3 instruction cycles. The FUs and the software components can execute concurrently; A ma ximum of 7 input/output operands for all the FUs is currently supported by the automated environment. Figure 5. Interface of each unit with the core.

5 5. Cost Metrics The cost metrics will guide the partitioning process. These metrics must include the area dimension of each block (core, program memory, data memory, timers, etc.), package sizes available, maximum area available, and execution time. The co-synthesis environment uses high-level estimates obtained through statistically generated system implentations for the parameterized core, and uses accurate metrics feedbacked from the synthesis tools tools for the hardware units (for the sea-of-gates architecture targeted [9] the area unit considered is the site, which consists of a pair of complementary MOS transistors). The estimates for the program area dimension have been obtained through compilation of randomly generated programs based on normal distribution of the instruction set. The area of the circuits synthesized for each of these programs is shown in Table 1. These results indicate that the ratio sites/bit is approximately equal to 1.3, and decreases with the increase of the number of instructions in the program. Table 1. Metric estimates of program memory: Nº of Instructions 12 bits/instruction Memory area in Gate-Array access time t aces (ns) The total area of the IC can be predicted using the expressions (1, 2 and 3). The interface area (A interface) is related to the input operand registers of each FU, the output operand drivers and the generation of control signals. Each FU area is referred by Aunit. The software area (A SW) consists of the program memory and data memory. The size of the data memory depends on the required number of registers and the program memory depends on the number of instructions of the program. The core area consists of a fixed area (without parameterizable capability), the synchronism mechanism of the timer (to increment the RTCC 2 ), the timers (pre-scalar mechanism for both), the register RTCC, the two default ports (A and B), and the area of the address decoder of the register file. AIC = ACORE + ASW + ( A erface + A ) i unit i i int (1) 2 Real Time Clock/Counter Register.

6 Table 2. IC area estimates Area estimate (number of sites) Description A data 248 per each 8 bit register Area related to general registers 517 per each 8 bit I/O port Area related to I/O ports A prog 13 per instruction (overhead) Area of program memory with random logic A CORE Area of PISCPMS with the 7 special registers (includes PORTA and PORTB) A FIXED Fixed core area. A SYNC 294 Area of syncronism machine of Timer. A OPTION+WDT+Timer 777 Area of Watchdog Timer and Timer. A RTCC 578 Area of register F1. A REG_DEC 163 Area of register file decoder. A unit Area related to each FU A interface nº inputs* nº outputs*90 Area related to FU registers, FU drivers to internal bus and dexmultiplexing control signals. Each operand is 8 bit width. ASW = Aprog + Adata (2) A = A + A + A + CORE FIXED SYNC OPTION+ WDT+ Timer + A + A + A + A RTCC PORTA PORTB REG_ DEC (3) The estimates used for the individual areas are represented in Table Examples The processor core has been implemented in a sea-ofgates integrated circuit with a test program of 135 instructions and 13 registers. This circuit occupies 4030 equivalent gates. Logic simulations illustrated a maximum clock frequency near 35MHz. The critical path of the processor core has been identified, which consists of the increment of the program counter, followed by addressing program memory. A re - scheduling of these is under development in order to increase the maximum allowable clock frequency. The results presented in Table 3 are relative to a multiplication routine included in the implemented chip test program (with 14 instructions plus 1 CALL) which calculates the multiplication of two 8 bit wide operands with a 16 bit re sult. Table 3 also presents the execution time of the implemented routine in a commercial PIC 3 microcontroller. In case the constraint directive for this application specifies that the multiplication must be performed in less than 2 µs, the co-synthesis system automatically migrates the routine to hardware (multiplier). The resulting solution consists of a multiplier unit (area = 1879 sites and execution time = 74 ns). When integrated with the processor core, it will use 11 code instructions for communication between the unit and the core and the total execution time is 1.1 µs. Table 3. Results for multiplication routine: Nº of instruction cycles Execution time PISCPMS@30MHz µs µs 7. Conclusions and Future Work The proposed software/hardware co-synthesis environment provides an efficient approach for rapid prototyping of embedded digital systems by combining, in a one-chip solution, a generic microcontroller core with application specific hardware units. This approach targets single chip system implementation on a quick turnaround sea-of-gates technology and is therefore a very good solution for rapid prototyping and low cost small series production of low to medium complexity embedded digital systems. The communication interface is not critical for the final performance, but alternative interface schemes are being considered. The use of high level hardware synthesis algorithms able to extract the non deterministic code segments, which currently are not 3 PIC is a trademark of Microchip Inc.

7 allowed to be migrated into hardware, is under investigation. The extension of the design system to allow the specification of the software components in C, such that the C compiler exports the constraints directives to the flow graph assembler level where the hardware/software partition is currently performed is planned as a future development. [12] João M. P. Cardoso, Co -Síntese de Sistemas Embebidos em Agregados de Células Lógicas, Master Thesis, IST, 1996 (in preparation). [13] MPCALC ASSEMBLER USER S GUIDE, Microchip Technology Inc., 1994, p [14] MPSIM USER S GUIDE, Microchip Technology Inc., 1993, p References [1] Daniel D. Gajski et al., Specification And Design Of Embedded Systems, Prentice-Hall Englewood Cliffs, [2] Giovanni De Micheli, Computer-Aided Hardware-Software Codesign, IEEE Micro, August 1994, pp [3] Giovanni De Micheli, Hardware-Software Co - design: Application Domains and Design Technologies, in Hardware-Software Co- Design, Kluwer Academic Publishers, January [4] Harry Hsieh, Luciano Lavagno, and Alberto Sangiovanni-Vincentelli, Embedded System Codesign: Synthesis and Verification, in Hardware-Software Co-Design, Kluwer Academic Publishers, January [5] Daniel D. Gajski, and Frank Vahid, Specification And Design Of Embedded Hardware-Software Systems, IEEE Design & Test of Computers, Spring 1995, pp [6] Rolf Ernst, J. Henkel, e T. Benner, Hardware- Software Cosynthesis for Microcontrollers, IEEE Design & Test of Computers, Vol. 10, No. 4, December 1993, pp [7] R. K. Gupta, Cosynthesis of Hardware and Software for Digital Embedded Systems, PhD Thesis, Stanford University, Palo Alto, Calif., 1993 [8] Horácio C. Neto, Fast Prototyping of Microelectronic Systems, IV EBMicro, Escola Brasileira de Microelectrónica, Advanced Research Tutorials, Recife, January 1995 [9] QuickChips Partners, QuickChips, A System Supporting ASIC Design and Providing Rapid Turnaround Prototyping, Esprit Project 6043, Technical Appendix VI, September 1995 [10] MICROCHIP DATA BOOK, Microchip Technology Inc., 1993 [11] EMBEDDED CONTROL HANDBOOK, Microchip Technology Inc., 1993.