Question about the parallella's architect

[stevenong_2006]

Hi,
My name is Steven Ong. I am a software engineer at the same time am a graduate student. My special interest research area is mutilcore processing. I have the following questions:
- If I want to get the parallella working out from the box, which items should I need to purchase? (a board + *?)
*** I need this information in order to know what to order ***

I'm planning to use the board for my research study. I need to understand some basic architecture:
- Is the parallella a symmetric multiprocessing (SMP) or an asymmetric multiprocessing architect? Could you direct me to the documentation regarding this area?

Thanks in advance for you reply. All the best.
Steven

[Gravis]

[mhonman]

[LamsonNguyen]

[hewsmike]

Indeed. A key related point of logic is that a given local memory location on a node may be written anytime, by anyone. A read by a core from memory elsewhere is a request packet ( return to sender address enclosed ), to be later honored by a write transaction indistinguishable from a write initiated elsewhere ( on or off chip ) and thus possibly 'un-invited', so to speak. So the question arises - if one wants to rely upon write semantics to leverage the speed asymmetry - as to how one denotes a given local core memory location as containing 'valid' data at some instant. Meaning when should that core treat the operand within to be thus processed in some way.

Thus it behooves the developers ( us ) to create protocols which ( in generality ) achieve the following states ( and transitions thereof ) for some given local memory range:

- can be written to ( this core waiting for data to arrive, a single distal write source may latch/mutex and act ).

- is being written to ( data not yet valid for processing, range only to be accessed by write source ).

- has been written to ( can no longer write from a distance, but may locally read as valid and process, even write to .... ).

Or if you like the memory range has a series of ownership states.

Cheers, Mike.