CS-476: Lab3.4: Hardware counter

Hi everyone,

I would like additional instructions about the requirements of the implementation of the hardware counter, and more exactly what types of accesses are allowed.

This is because that, by default, the Avalon interconnect will do requests' arbitration, and since we make the requests in one shot, the hardware will always stay in a clean state.
This means that by default, our counter already has bare-minimum multi-master capabilities.

Now, if we want to avoid data races and provide "atomic" access or exclusive access, then we have to implement mutex-like functionality. I suppose this is what we should do, but I would like confirmation.

Regards

Re: Lab3.4: Hardware counter

by René Beuchat - Wednesday, 19 May 2021, 08:48

What is the problem of a variable (variable in a shared area as programmable interface or memory) accessed by 2 master units? Same kind of problem as for shared variables in a multi-tasking system: the atomic access for modification + the cache utilisation.

The idea through this laboratory question is to find a way to increment a counter without reading the value by the processor, modifying it and writing it back. As we could have interleaving between the master's accesses.

Thus the proposition is to do the incrementation by writing a value to add to the one in the unit, in our case a programmable interface. You can take your developped counter or parallel port to do that by simple added an register access in its register map with the value to add to the actual data content. If you are working in 2's complement the value to add can be positive or negative.

I hop it is clear.

Thus a simple write with the value to add can be done in an atomic way, without interleaved Read-modify-write.

If you use (with the NIOSII) the IOxx write access, the cache is not used, otherwise a flush is mandatory.

Best.