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

Characterization Presentationמצגת אפיון פרויקט Project period : 2 semesters

Starting semester: winter 2010/2011

PLURALITY

Performed by : Malik Kittani, Ayman MouallemSupervisor : Moshe Bensal

PLURALITY

Project Objectives :

• Learning, designing and implementing of several testing methods for single core and then expanding the testing to multi-core architecture .

• Understand Plurality’s Simulator and its capabilities.

Understand Plurality's HAL Architecture.

PLURALITY

Limitations with single core Architecture:

Overview – why Parallel Processing and Multi-Core

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.

PLURALITY

Old approach Vs. New approach

Previous Years Current Days

Power expensive, transistors “free”- Can put more transistors on a chip than have power to turn on

Power is free, but transistors expensive

2X CPU Performance every 18 months Bottleneck is the memory access bus time

Serialized instructions and programs The need for parallelism , specially in servers and GPU.

The parallel processing technology is now mature and is being exploited commercially.

Overview – why Parallel Processing and Multi-Core

PLURALITY

With Multi-core and Parallel Processing we can see that the speedup ideally can go up linearly as we can see .

Overview – why Parallel Processing and Multi-Core

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.

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

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.

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 ?!

PLURALITY

Working Environment :

C languageC++

The operation system that is available for us in the Lab is Windows OS

Therefore we need the Cygwin Linux-Like Interface Layer

Plurality’s tools are built for linux environment

PLURALITY

Working Environment :

C languageC++ 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

PLURALITY

Working Environment :

C languageC++ Software Simulator—supports cycle-accurate performance evaluation using Plurality’s cross-development tool chain

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.

PLURALITY

Working Environment :

C languageC++

Plurality’s simulator supports for now only Eclipse working environment.

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

Working Environment :

C languageC++ 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.

PLURALITY

Working Environment :

C languageC++ Hardware Evaluation Platform—an FPGA-based hardware implementation which runs at a down-scaled frequency relative to the final silicon implementation.

The hardware evaluation platform is a true hardware implementation for verification of the design before committing to silicon

PLURALITY

Working Environment :

C languageC++

T.O.

For the Last stage of the Project (a year from now) we would like to perform our test on a real silicon Hardware implementation.

The first T.O. shall be presented by plurality on 2011.

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.

PLURALITY

Tasks Until Midterm Presentation :

1) Learning the compiling, execution and debugging process using the simulator and

the Eclipse (18.11-28.11).

2) Learning and Programming in Task Oriented Programming (TOP) method(29.11-

6.12).

3) Learning and Implementing cornerstones of chip testing field(07.12-19.12) :

Observability and Controllability: we will explore what features Plurality

have in order to do this.

4) Building A skeleton and ideas for the tests that we are going to build until the end

of the semester(12.12-23.12).

5) Midterm Presentation (27.12.10).

PLURALITY

For the second semester :

Implementing the skeleton and the ideas of the tests that was suggested at the

midterm presentation.

Tasks Until Final Presentation :

Expanding the tests from single core tests, to a whole system tests, and maybe

hardware tests if we receive a hardware .

PLURALITY

References :i. HyperCore Software Developer’s Handbook.

http://www.plurality.co.il/software/documents/SDH-draft-1.5.pdf

ii. John Grason and Andrew W.Nagle(1980), Bell Laboratories, Holmdel, New Jersey, “Digital test

generation and design for testability” .

iii. Bret Pettichord, 2002, “Design for Testability”.

iv. 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”.

v. Sankaran Menon, Intel Corporation (2005), “Have we overcome the Challenges associated with

SoC and Multi-core Testing?”.

vi. Indradeep Ghosh, Anand Raghunathan, and Niraj K. Jha, Department of Electrical Engineering