[Lab3] Clarification on questions

[Lab3] Clarification on questions

by Leonardo Mussa -
Number of replies: 4

Hello, 


we are not sure we understand the question in "Manipulation 4" of the lab description https://moodlearchive.epfl.ch/2019-2020/pluginfile.php/542641/mod_resource/content/1/Labo_FPGA4U_MultiProcessorNIOSII_1_0doc.pdf

Also the description of the "Multi processor design to realize" is not super clear to us (memory size? how many parallel ports?)

Could you please give us a brief summary of what you expect us to do and what are the key points we should address?

Just to be sure we interpreted the instructions correctly and we didn't overlook anything important


Thanks a lot for your help

In reply to Leonardo Mussa

Re: [Lab3] Clarification on questions

by René Beuchat -

Hello, 

in the manipulation on Multiprocessors, I expect 2 NIOSII processors, version with caches and the description on section 3.

When you use the UART, you can test it with the logic analyser with serial UART decoding.

3 PIOs in  total: 1 for each NIOS, 1 for both.

In 3.4 we want to use the common PIO as a  software counter by software accessible by both processors.

When we do a counter in a variable (represented here as the PIO), if we do something as Cnt++, it is NOT a primitive, as the processor has to execute :

  • Read Cnt in an internal processor register
  • Add 1 to the register
  • Write back to the Cnt

If two processors have to do that a Mutex is mandatory to have exclusive access to this variable.

Here we want to represent the Cnt by the PIO data register and doing the same, but we need to do that "by hand" with IO_RD... and IO_WR... accesses. and Mutex to do exclusive access.

Now the Manipulation 4 needs that you modify your own parallel port with a primitive function to add a value which is provide by a write access to a specific register position (you decide how) that will take the actual register value and add the written data, You can do a hardware specialized unit to act as a counter accessible as a unique cycle primitive.

I hope its clear now.

Best.

RB


In reply to René Beuchat

Re: [Lab3] Clarification on questions

by Jon Märki -

So if I get it right, the idea for the manipulation 3.4 is to make a better hardware counter (That just does the addition on its own) and share it using a mutex, right ? And then we check what happens if we remove the mutex access?

In reply to Jon Märki

Re: [Lab3] Clarification on questions

by Cédric Oliver Portmann -

Did you get an answer on this?

In reply to Cédric Oliver Portmann

Re: [Lab3] Clarification on questions

by Sahand Kashani-Akhavan -

Sorry, just saw this now.

If you use a CPU's adder to implement a counter, but where the data that needs to be incremented is in a PIO, then the CPU must use IORD, then increment the value, the IOWR the value back. This means that if multiple CPUs want to manipulate the counter, then they first need to use mutex to ensure mutual exclusion access to the counter.

What we are asking you to do here is to implement a counter in HW directly such that a CPU's write access to, for example, address 0 of the counter causes the value to increment automatically, and a write to, for example, address 4 of the counter would cause the value to decrement automatically.

With such a counter, the CPUs don't actually need a mutex as only one CPU can access the counter at a given time and the avalon bus will perform arbitration between multiple CPUs if ever they simultaneously try to access it. So if you don't need to read the value back, but just increment/decrement it, then such a hardware primitive is much faster than having a software-based exclusive access policy for a shared variable.