אימות רכיב מרובה מעבדים Validation of a Multi-Core Chip

1. PLURALITY אימות רכיב מרובה מעבדיםValidation of a Multi-Core Chip מצגת אפיון פרויקט Characterization Presentation Project period : 2 semesters Starting semester: winter 2010/2011 Performed by : Malik Kittani, Ayman Mouallem Supervisor : Moshe Bensal

2. PLURALITY Project Objectives : • Understand Plurality's HAL Architecture. • Understand Plurality’s Simulator and its capabilities. • Learning, designing and implementing of several testing • methods for single core and then expanding the testing to • multi-core architecture .

3. PLURALITY Overview – why Parallel Processing and Multi-Core Limitations with single core Architecture: Hardware improvements like pipelining, superscalar are not scaling well and require sophisticated compiler technology to exploit performance out of them. With single core, we’ve reached to a lot of limitations : speed up, frequency, efficiency, power.

4. PLURALITY Overview – why Parallel Processing and Multi-Core Old approach Vs. New approach Current Days Previous Years • Power expensive, transistors “free” • - Can put more transistors on a chip than have power to turn on Power is free, but transistors expensive Bottleneck is the memory access bus time 2X CPU Performance every 18 months The need for parallelism , specially in servers and GPU. Serialized instructions and programs The parallel processing technology is now mature and is being exploited commercially.

5. PLURALITY Overview – why Parallel Processing and Multi-Core With Multi-core and Parallel Processing we can see that the speedup ideally can go up linearly as we can see .

6. PLURALITY Plurality – What we are going to test This is a Blocks diagram that describes the basics of Plurality system, the system that we are going to test through this project, with all its components.

7. PLURALITY Overview About PLURALITY : • * The cores • - 16-256 of 32-RISC SPARC Hyper-core processor • - Perform basic arithmetic operations • * Co-Processor • - One helper unit for each 4 cores • - Perform multiplication and division • * Central Synchronization Unit (CSU) - scheduler • Distributes the tasks between the cores with minimal overhead • * Shared memory system • -Allows any number of cores to access data and instruction memory at every clock cycles

8. PLURALITY Plurality Task oriented programming model (TOP): The main objective of this model is to change the programming concept of serialized instructions to multiple tasks that can run more simultaneously. The software designer , with the help of the CSU, can divide the regular program to regular and duplicable tasks program. The division can be described by a task map, with dependencies between the tasks When performing a test, this property is very helpful, we can match a task to a single core, and we can match group of tasks to group of cores and wait to see that all cores performed the task they should do, this way we can test the dependencies between the jobs and how the system co-respond with it.

9. PLURALITY What are we going to test ?! • Current perspective : • This Is a new hardware. Is every component working as it should ?! • Are all the components connected and can pass data between them ? • Is all the memory space addressable ? And can be read and written ?! • Are all the components needed for a single core working correctly ? (register file, program counter, ALU). • Future perspective : • Is the system accomplishes it’s aim ?! • Are all the CPUs synchronized ? Is the synchronizer • working properly ? • Is the whole system working simultaneously as it should • be ? can the 256 cores work together without interfering • with each other ?!

10. PLURALITY Working Environment : C++ C language Plurality’s tools are built for linux environment The operation system that is available for us in the Lab is Windows OS Therefore we need the Cygwin Linux-Like Interface Layer

11. PLURALITY Working Environment : C++ C language Software Emulator—supports rapid software development for Task-Oriented Programming and debugging using the native compiler tool chain. Because it runs on the native platform, the emulator is easier to use during early stages of software development. For Testing, the Emulator is not a big help, because all we can see is the final result, with no further information about inner states of the chip

12. PLURALITY Working Environment : Software Simulator—supports cycle-accurate performance evaluation using Plurality’s cross-development tool chain C++ C language The simulator simulate a real hardware data flow, where we can see the values of the points needed for tests, including : registers, memory, focusing on a specific core data flow. The simulator also give us more options like controlling the number of cores on the chip, number of cores per co-processor and more.

13. PLURALITY Working Environment : C++ C language The conversion from serialized program to the TOP method of plurality is done within the compiler through the “GNU Native Platform Tool Chain” and “Plurality Cross-Development Tool Chain” . Plurality’s simulator supports for now only Eclipse working environment.

14. PLURALITY Working Environment : C++ C language Plurality currently support C and C++ languages, but the support for C++ is unstable yet. Therefore we will use the C language for building the tests.

15. PLURALITY Working Environment : Hardware Evaluation Platform—an FPGA-based hardware implementation which runs at a down-scaled frequency relative to the final silicon implementation. C++ C language The hardware evaluation platform is a true hardware implementation for verification of the design before committing to silicon

16. PLURALITY Working Environment : For the Last stage of the Project (a year from now) we would like to perform our test on a real silicon Hardware implementation. C++ C language The first T.O. shall be presented by plurality on 2011. T.O.

17. PLURALITY Disclaimers and hang Factors : • In case that the cygwin environment does not work appropriately , we’ll need a linux computer, with plurality tools for linux system that are more stable. • Plurality is having some economical problems, so if we face a problem with some feature in testing , we won’t have a support from the company, and we’ll have to pass on this feature without testing it. • in the meanwhile we don’t have an FPGA hardware in the lab, so we will perform the tests only on software using the simulator. • Our perspective is to perform the tests on a silicon Tape Out hardware, which now is still not produced.If plurality don’t give us a tape out until the end of the project, we’ll have to end the project without testing the hardware itself.

18. PLURALITY Tasks Until Midterm Presentation : • Learning the compiling, execution and debugging process using the simulator and the Eclipse (18.11-28.11). • Learning and Programming in Task Oriented Programming (TOP) method(29.11-6.12). • Learning and Implementing cornerstones of chip testing field(07.12-19.12): • Observabilityand Controllability: we will explore what features Plurality have in order to do this. • Building A skeleton and ideas for the tests that we are going to build until the end of the semester(12.12-23.12). • Midterm Presentation (27.12.10).

19. PLURALITY Tasks Until Final Presentation : Implementing the skeleton and the ideas of the tests that was suggested at the midterm presentation. For the second semester : Expanding the tests from single core tests, to a whole system tests, and maybe hardware tests if we receive a hardware .

20. PLURALITY References : HyperCore Software Developer’s Handbook. http://www.plurality.co.il/software/documents/SDH-draft-1.5.pdf John Grason and Andrew W.Nagle(1980), Bell Laboratories, Holmdel, New Jersey, “Digital test generation and design for testability” . Bret Pettichord, 2002, “Design for Testability”. Shou-Wei Chang, Kun-Yuan Hsieh and Jenq Kuen Lee (2009), Department of computer science, National Tsing-Hua University, Taiwan, “pTest : An Adaptive Testing Tool for Concurrent Software on Embedded Multicore Processors”. Sankaran Menon, Intel Corporation (2005), “Have we overcome the Challenges associated with SoC and Multi-core Testing?”. Indradeep Ghosh, Anand Raghunathan, and Niraj K. Jha, Department of Electrical Engineering