1. The Multi Micro Processor B.D.Theelen@tue.nlA.C.Verschueren@tue.nl Eindhoven University of TechnologySection of Information and Communication Systemswww.ics.ele.tue.nl/~btheelen/projects/mup Ad Verschueren and Bart Theelen

2. Contents • Introduction • System architecture • O.S. in hardware: the ‘Task Control Unit’ • Multi processing • Inter-MμP communication • External event handling • Project status Ad Verschueren and Bart Theelen

3. Introduction: what is it ? MμP = Scalable multi processor architecture implemented on a single chip for real-time (embedded) systems Ad Verschueren and Bart Theelen

4. Features • True (shared memory) multi processing • Scalable: number of processors is not fixed • Customisable: number and types of coprocessors varies • On-chip operating system kernel • Priority based multitasking on multiprocessor • External event handling instead of interrupts • Transparent inter-MμP communication Ad Verschueren and Bart Theelen

5. L2 I$ 1 LPU 2 LPU n LPU L1 I$ L1 I$ L1 I$ Register D$ Arbiter External Memory MultiPort D$ Taskassignments GPU m.1 FPU GPU 2.1 LSU GPU 1 TCU GPU m.y FPU GPU 2.x LSU Event Inputs Inter-MPNetwork System architecture ‘Local Processing Unit’= RISC core Function Switch Control Space ‘Global Processing Unit’= (shared) co-processor ‘Task Control Unit’= O.S. kernel in HW Result Switch Ad Verschueren and Bart Theelen

6. Current idea: T9000 look-alike Function Switch Control Space TCU Core TCU Network Management Link Function Rx Task Admin Link Switch Network Task Scheduler Sorted Task List Resource Admin Link Link Resource Data Timers Arbiter Result Tx Event Detect Result Switch Event Inputs MultiPort D$ LPUs The ‘Task Control Unit’ Executive Ad Verschueren and Bart Theelen

7. Multi processing • LPU’s run multiple tasks in parallel • Instruction set is ‘open ended’ • Only 1/16 of instruction space executed by LPU’s • Remainder split over up to 15 different GPU types • Each GPU type determines actual use of ‘opcode’ bits • Function switch routes on GPU type • Non-blocking, task priority based, fair • Result switch routes on task number • Non-blocking, FCFS Ad Verschueren and Bart Theelen

8. Inter-MμP communication • Each task and communication resource has a local # • ‘Communication resource’ = semaphore, pipe or mailbox • Each MμP has its own ‘network address’ • All elements addressed with network address and local # • Communication is completely transparent • Every task can use every resource on the network • TCU shields network from tasks (no direct access) • To transfer large blocks of data, use a pipe ! Ad Verschueren and Bart Theelen

9. External event handling • Interrupts and software O.S. kernel are absent here ! • TCU checks ‘external event’ inputs for activity • Sends specified number of ‘units’ to specified counting semaphore upon detection of event input activity • Tasks can wait at semaphore for units generated by external events • Semaphore to send units to (or wait at) need not be in the MP where the task resides ! Ad Verschueren and Bart Theelen

10. Research Topics • How to configure a MμP for an application domain? • What limits configuring a MμP? • What performance bottlenecks can be expected? • What performance will a specific MμP configuration have? • How should an efficient hardware OS kernel look like? • How to incorporate (automatic) testability in a highly parametrisable development procedure? • How can compilers cope with the flexibility in a MμP system? • Ultimate goal: Tools for industry, which enable fast synthesis by automatically mapping specific performance requirements of an application domain onto an efficient MμP configuration Ad Verschueren and Bart Theelen

11. Project status • Currently, a project run by students ! • Modular by nature, easy to split the workload • Partial designs of most elements present or coming • Instruction set of LPU and interfaces more or less fixed • Functionality of TCU under investigation • Uses Interactive Design and Simulation System • Mixed level: RTL and algorithmic level blocks • Want to have complete algorithmic level model ASAP • From there to RTL and (automatically) VHDL/Verilog Questions ? Ad Verschueren and Bart Theelen