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

Have you ever looked at code guarded by mutexes and semaphores and
wondered, "what if the guarded code were placed in a RAM block that
ensured exclusive access to itself" ?

Why not put the 'code' block in the 'RAM' block ? Then use a hardware
guard, rather than using mutexes and semaphores.

Faster and more efficient, although it does consume some more
transistors.



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

Rob wrote:
> Why not put the 'code' block in the 'RAM' block ? Then use a hardware
> guard, rather than using mutexes and semaphores.

Interesting idea, but I don't think it's as simple as you imply.

How does this RAM know when to start and end exclusive access? Does
it start exclusivity the first time a location is read from it by a
particular processor? When does it stop?

How does it deal with two threads that run on the same processor? How
will it tell whether an access is from one thread or the other? Will
the processor provide a thread ID to the RAM with each access?

If thread A and B are running on the same CPU, and thread A owns the RAM,
what happens if thread B tries to access it? Does the access suspend until
thread A releases the RAM? If so, won't it cause a deadlock, since the
bus from the CPU to the RAM is busy? Or does the RAM abort the cycle,
telling the CPU to retry?

Even if the two threads are on different CPUs, if there isn't some
special signalling method to tell the CPU that the RAM is no longer busy,
thread B will waste memory bandwidth (which could be needed by thread A)
retrying until thread A eventually yields the RAM. That also wsstes
CPU cycles on the processor running thread B, since it could be
running thread C instead.

Best regards,
Eric


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

That reminds me of an idea intelasys had:
http://www.edn.com/article/CA6334623.html?partner=enews

They essentially block the whole cpu (1 out of many) if it tries to read
from or write to an io port if
this port is not being read/written to by another CPU (they have an
2-dim array of CPU's)
The advantage it has, is that the CPU stops (no power) while blocked.
And as this is a HW feature no more semaphores are needed
(which in their case) eases the code.

I especially like the idea as they can even execute instructions from
that port.

(I wonder how much of this idea is copyrighted)

I'd like to design something similar
thilo
Eric Smith wrote:
>
> Rob wrote:
> > Why not put the 'code' block in the 'RAM' block ? Then use a hardware
> > guard, rather than using mutexes and semaphores.
>
> Interesting idea, but I don't think it's as simple as you imply.
>
> How does this RAM know when to start and end exclusive access? Does
> it start exclusivity the first time a location is read from it by a
> particular processor? When does it stop?
>
> How does it deal with two threads that run on the same processor? How
> will it tell whether an access is from one thread or the other? Will
> the processor provide a thread ID to the RAM with each access?
>
> If thread A and B are running on the same CPU, and thread A owns the RAM,
> what happens if thread B tries to access it? Does the access suspend until
> thread A releases the RAM? If so, won't it cause a deadlock, since the
> bus from the CPU to the RAM is busy? Or does the RAM abort the cycle,
> telling the CPU to retry?
>
> Even if the two threads are on different CPUs, if there isn't some
> special signalling method to tell the CPU that the RAM is no longer busy,
> thread B will waste memory bandwidth (which could be needed by thread A)
> retrying until thread A eventually yields the RAM. That also wsstes
> CPU cycles on the processor running thread B, since it could be
> running thread C instead.
>
> Best regards,
> Eric
>
>


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

That reminds me on the old days of the transputers.

Communikation between two processes or cpus is simple on transputers:

In one process you write

Channel ! len::message

suspends the process(or) until the other is ready

In the other process you write

Channel ? len::message

suspends the process(or) until the other has send a message

This also works between CPUs

no semaphores needed

suspend/resume time 4 to 6 memory cycles

Frithjof



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

--- Thilo Jeremias wrote:
(...)
> I especially like the idea as they can even execute instructions from
> that port.
>
> (I wonder how much of this idea is copyrighted)

The old Z80, as far as I can remember, was fetching code from interrupt
controller when interrupt was generated. It was very similar to fetching code
from I/O port since buss cycle wasn't a regular code fetch cycle.

About semaphores, mutextes and etc and hardware support for them.

First of all programmers does not like the idea to be limited in a count of
such elements. So it should be rather an opcode which does mutex/semaphore in
hardware than a locked memory region.

The simple atomic read-test-for-zero-increment-write instruction helps alot.
The

Read
test for zero/not zero
if not generate interrupt
increment
write

This would help even more, since it would be able to transparently initiate
task switch.

In the real world many wrong things may happen. So the hardware support for
such a "waitable" elements should include a kind of software watchdog.
Something like:

0:
load cpu timer
add argument to it
write result B (where B is a local variable or something realy own for
current thread )
1:
Read A
test for zero/not zero
if not
Read B
check, if cpu timer equals B
if yes, generate interrupt or exception (like deadlock exception)
generate task switch interrupt, which will return to 1
increment A
write A to memory

Many embedded engineers will be glad to see it.
kind regards,
Tomasz Sztejka

___________________________________________________________
What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk



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

--- In f...@yahoogroups.com, Tomasz Sztejka wrote:
> --- Thilo Jeremias wrote:
> (...)
> > I especially like the idea as they can even execute instructions from
> > that port.
> >
> > (I wonder how much of this idea is copyrighted)
>
> The old Z80, as far as I can remember, was fetching code from interrupt
> controller when interrupt was generated. It was very similar to
fetching code
> from I/O port since buss cycle wasn't a regular code fetch cycle.
>
> About semaphores, mutextes and etc and hardware support for them.
>
> First of all programmers does not like the idea to be limited in a
count of
> such elements. So it should be rather an opcode which does
mutex/semaphore in
> hardware than a locked memory region.
>
> The simple atomic read-test-for-zero-increment-write instruction
helps alot.
> The
>
> Read
> test for zero/not zero
> if not generate interrupt
> increment
> write
>
> This would help even more, since it would be able to transparently
initiate
> task switch.
>
> In the real world many wrong things may happen. So the hardware
support for
> such a "waitable" elements should include a kind of software watchdog.
> Something like:
>
> 0:
> load cpu timer
> add argument to it
> write result B (where B is a local variable or something realy own for
> current thread )
> 1:
> Read A
> test for zero/not zero
> if not
> Read B
> check, if cpu timer equals B
> if yes, generate interrupt or exception (like deadlock exception)
> generate task switch interrupt, which will return to 1
> increment A
> write A to memory
>
> Many embedded engineers will be glad to see it.
> kind regards,
> Tomasz Sztejka
>
> ___________________________________________________________
> What kind of emailer are you? Find out today - get a free analysis
of your email personality. Take the quiz at the Yahoo! Mail Championship.
> http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
>

Instructions like 'Replace Add One' have been around for a very long
time. Even the Control Data 160A had the instruction
http://ed-thelen.org/comp-hist/CDC-160-A-prel.html

I'm pretty sure the DEC machines had it as well.

Richard



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