A Co-Synthesis Environment for Embedding ... - Semantic Scholar

XI Conference on Design of Integrated Circuits and Systems (DCIS'96), Sitges (Barcelona), November 19 -22, 1996, pp. 411 -416.

A Co-Synthesis Environment for Embedding Digital Systems in a Sea-of-Gates IC João M P Cardoso INESC / Univ. Algarve [email protected]

Horácio C Neto INESC / IST [email protected]

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

ASIC

MEMORY 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

DATA MEMORY INTERFACE

WDT Timer units

PROGRAM MEMORY

FUNCTIONAL UNITS

I/O PORTS

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 s ystem specification is therefore software based, with timing constraints directives included in the source code to guide the

XI Conference on Design of Integrated Circuits and Systems (DCIS'96), Sitges (Barcelona), November 19 -22, 1996, pp. 411 -416.

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:

• All I/O ports can be implemented with 8 bits and are fully reconfigurable. A maximum of 8x8 bits 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 Counter (F2) Program Memory up to 512 x 12 bits

8 bits 9-bits Stack

12 bits

• Core size not very large (8-bit wide datapath);

Register File (up to 80x8 bits registers)

Instruction Register

• 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);

8 bits

MUX 5 bits FSR (F4)

RTCC (F1) Status (F3) Port B (F6) MUX Instruction decoder and Control MCLR

Port A (F5)

ALU

• A power down mode controlled by a sleep instruction for low power consumption;

RTCC/ WDTCLK

• One level of instruction pipelining (fetch of the next instruction in parallel with the execution of the actual instruction).

VDD, VSS

• Direct, indirect and relative addressing modes for data and instructions;

5 bits

Synchronizer WatchDog Timer

W

Timer

TRISA OPTION

OSC1 OSC2/CLKOUT Clock generation

8 bits TRISB

8 bits

• An internal Timer and WatchDog Timer (WDT); The processor core, designated by PISCPMS1[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 Microcontroller for Sea-of-Gates.

S et

Compatible

PIC

Figure 3. Block diagram of the processor core achitecture.

3. Co-Synthesis Environment 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

XI Conference on Design of Integrated Circuits and Systems (DCIS'96), Sitges (Barcelona), November 19 -22, 1996, pp. 411 -416.

Assembler program

MPALC (assembler)

Code segments with constraints extraction

ASM to ROM Converter

MPSIM (simulator)

Analysis of execution time

assembler

Number of registers necessary Library Functions

SYNTHESIS SYNTHESIS

Program Memory

VHDL sinthetizable

SYNTHESIS

Data Memory

Interface FUs

Gate Array

PISCPMS CORE

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 : ]] = .

: MAXTIME | MINTIME

• Concurrent directive: ;PARALLEL : : {{ : : }} .

• Specification of clock period: ;CLOCK CYCLE = .

• Specification of I/O ports: ;PORT _NUMS = .

• Specification of a resource: ;RESOURCE : .

• Specification of FUs input/output operands: ; # # [[ ]] EQU . : IN | OUT | INOUT

• Generic directive: EQU .

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

XI Conference on Design of Integrated Circuits and Systems (DCIS'96), Sitges (Barcelona), November 19 -22, 1996, pp. 411 -416.

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.

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 1. Example of assembler directives Example 3. Operand transfer from FU to register file :

; CONSTRAIN MINTIME : label3 TO label4 = 2 us ; CONSTRAIN MAXTIME : label1 TO label2 = 1 us

MOVLW MOVWF 3 MOVWF

; 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 B

B0

ALU

...

B1

B6

FUNCTIONAL UNITS

ld_W W

W0

...

W1

W6

...

enable_W

Figure 5. Interface of each unit with the core.

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 8 bits 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.

XI Conference on Design of Integrated Circuits and Systems (DCIS'96), Sitges (Barcelona), November 19 -22, 1996, pp. 411 -416.

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)

32 64 128 256 512

704 1176 2016 3938 6581

14 15 17 19 24

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 RTCC2), 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 + ∑ ( Aint erface + Aunit ) i

i

2

Real Time Clock/Counter Register.

i

(1)

XI Conference on Design of Integrated Circuits and Systems (DCIS'96), Sitges (Barcelona), November 19 -22, 1996, pp. 411 -416.

Table 2. IC area estimates

A data

A prog

Area estimate (number of sites)

Description

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

13 per instruction + 432

Area of program memory with random logic

(overhead) A CORE

12 280

Area of PISCPMS with the 7 special registers (includes PORTA and PORTB)

A FIXED

9 434

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 A interface

Area related to each FU ≅ nº inputs* 120 + nº outputs*90

Area related to FU registers, FU drivers to internal bus and dexmultiplexing control signals. Each operand is 8 bit width.

ASW = A prog + Adata

(2)

ACORE = AFIXED + ASYNC + AOPTION +WDT+Timer + + ARTCC + APORTA + APORTB + AREG _ DEC

(3)

The estimates used for the individual areas are represented in Table 2.

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:

6. 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

3

PIC is a trademark of Microchip Inc.

PISCPMS@30MHz PIC16C54 @20MHz

Nº of instruction cycles

Execution time

64 72

6.4 µs 14.4 µ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

XI Conference on Design of Integrated Circuits and Systems (DCIS'96), Sitges (Barcelona), November 19 -22, 1996, pp. 411 -416.

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.

8. References [1]

Daniel D. Gajski et al., Specification And Design Of Embedded Systems, Prentice-Hall Englewood Cliffs, 1994.

[2]

Giovanni De Micheli, “Computer-Aided Hardware-Software Codesign”, IEEE Micro, August 1994, pp. 10-16.

[3]

Giovanni De Micheli, “Hardware-Software Co design: Application Domains and Design Technologies”, in “Hardware-Software CoDesign”, Kluwer Academic Publishers, January 1996.

[4]

Harry Hsieh, Luciano Lavagno, and Alberto Sangiovanni-Vincentelli, “Embedded System Codesign: Synthesis and Verification”, in “Hardware-Software Co-Design”, Kluwer Academic Publishers, January 1996.

[5]

Daniel D. Gajski, and Frank Vahid, “Specification And Design Of Embedded Hardware-Software Systems”, IEEE Design & Test of Computers, Spring 1995, pp. 53-67.

[6]

Rolf Ernst, J. Henkel, e T. Benner, “HardwareSoftware Cosynthesis for Microcontrollers”, IEEE Design & Test of Computers, Vol. 10, No. 4, December 1993, pp. 64-75.

[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 Technology Inc., 1993

BOOK,

Microchip

[11] EMBEDDED CONTROL HANDBOOK, Microchip Techn ology Inc., 1993.

[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. 120. [14] MPSIM USER’S GUIDE, Microchip Technology Inc., 1993, p. 120.