Sign in

username:

password:



Not a member?

Search fpga-cpu



Search tips

Subscribe to fpga-cpu



fpga-cpu by Keywords

Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A

Discussion Groups

Discussion Groups | FPGA-CPU | Re: semaphoric memory

This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).

semaphoric memory - Rob Finch - Apr 5 17:49:00 2005



I got to thinking about cpu instructions and hardware used to manage
semaphores. Then I got to thinking: why not make a memory with
semaphore operations built in instead ? That way regular load and store
instructions could be used.

Whenever there's a load from the semaphore memory, just have it
automatically decrement and return a greater than zero status. Whenever
there's a store just have it increment automatically.




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: semaphoric memory - rtstofer - Apr 5 19:33:00 2005



It's been a long time but I think I remembering reading about an
instruction set that did this very thing. The would fetch the current
value and leave behind a n altered value. It was a single non-
interruptible instruction specifically for semaphones. --- In fpga-cpu@fpga..., "Rob Finch" <robfinch@s...> wrote:
>
> I got to thinking about cpu instructions and hardware used to manage
> semaphores. Then I got to thinking: why not make a memory with
> semaphore operations built in instead ? That way regular load and
store
> instructions could be used.
>
> Whenever there's a load from the semaphore memory, just have it
> automatically decrement and return a greater than zero status.
Whenever
> there's a store just have it increment automatically.





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: semaphoric memory - Jan Gray - Apr 5 20:16:00 2005

I have done something similar in the past, to build a mutex using spin locks
on a shared memory multiprocessor of processor cores that lacked atomic
shared memory operations (not to mention, also lacked RMW memory
instructions). I needed to (try to) update the lock AND determine the
outcome of the update (or the previous state) in one atomic memory
transaction. Therefore I built a simple vector of bits (multiple locks)
and did all modifications using reads: if I read a bit at certain addresses
it CLEARED the bit and returned the original state of the bit. If I read
the same bit at a different address it SET the bit and returned the original
state of the bit...

Jan.




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: semaphoric memory - Kolja Sulimma - Apr 5 20:24:00 2005

Jan Gray wrote:

> Therefore I built a simple vector of bits (multiple locks)
>and did all modifications using reads: if I read a bit at certain addresses
>it CLEARED the bit and returned the original state of the bit. If I read
>the same bit at a different address it SET the bit and returned the original
>state of the bit... There are many cases were you can use address lines as write data lines.
For example I have a design where I memory mapped a JTAG port to a uC in
a way that a read access returns the value of TDO
and the lower to adress lines of the read set the values for TMS and TDI.

Another example is writing 36-bit data into a FIFO over a 32-bit bus.
The missing four bits can be transmitted using the address lines.

Kolja Sulimma





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: semaphoric memory - woodelf - Apr 5 20:57:00 2005

Rob Finch wrote:

>I got to thinking about cpu instructions and hardware used to manage
>semaphores. Then I got to thinking: why not make a memory with
>semaphore operations built in instead ? That way regular load and store
>instructions could be used.
>
>Whenever there's a load from the semaphore memory, just have it
>automatically decrement and return a greater than zero status. Whenever
>there's a store just have it increment automatically. Now if it is busy don't you want to have your task go to sleep as well?
Ben Alias woodelf




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: semaphoric memory - rtstofer - Apr 5 21:01:00 2005



That's a very clever solution. I'll keep it in mind...

--- In fpga-cpu@fpga..., "Jan Gray" <jsgray@a...> wrote:
> I have done something similar in the past, to build a mutex using
spin locks
> on a shared memory multiprocessor of processor cores that lacked
atomic
> shared memory operations (not to mention, also lacked RMW memory
> instructions). I needed to (try to) update the lock AND determine
the
> outcome of the update (or the previous state) in one atomic memory
> transaction. Therefore I built a simple vector of bits (multiple
locks)
> and did all modifications using reads: if I read a bit at certain
addresses
> it CLEARED the bit and returned the original state of the bit. If
I read
> the same bit at a different address it SET the bit and returned
the original
> state of the bit...
>
> Jan.





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )