6.42
IDT70V261S/L
High-Speed 16K x 16 Dual-Port Static RAM with Interrupt Industrial and Commercial Temperature Ranges
16
written into that semaphore request latch.
The critical case of semaphore timing is when both sides request
a single token by attempting to write a zero into it at the same time. The
semaphore logic is specially designed to resolve this problem. If
simultaneous requests are made, the logic guarantees that only one
side receives the token. If one side is earlier than the other in making
the request, the first side to make the request will receive the token. If
both requests arrive at the same time, the assignment will be arbitrarily
made to one port or the other.
One caution that should be noted when using semaphores is that
semaphores alone do not guarantee that access to a resource is
secure. As with any powerful programming technique, if semaphores
are misused or misinterpreted, a software error can easily happen.
Initialization of the semaphores is not automatic and must be
handled via the initialization program at power-up. Since any sema-
phore request flag which contains a zero must be reset to a one, all
semaphores on both sides should have a one written into them at
initialization from both sides to assure that they will be free when
needed.
Using Semaphores—Some Examples
Perhaps the simplest application of semaphores is their applica-
tion as resource markers for the IDT70V261’s Dual-Port RAM. Say the
16K x 16 RAM was to be divided into two 8K x 16 blocks which were
to be dedicated at any one time to servicing either the left or right port.
Semaphore 0 could be used to indicate the side which would control
the lower section of memory, and Semaphore 1 could be defined as the
indicator for the upper section of memory.
To take a resource, in this example the lower 8K of Dual-Port RAM,
the processor on the left port could write and then read a zero in to
Semaphore 0. If this task were successfully completed (a zero was
read back rather than a one), the left processor would assume control
of the lower 8K. Meanwhile the right processor was attempting to gain
control of the resource after the left processor, it would read back a one
in response to the zero it had attempted to write into Semaphore 0. At
this point, the software could choose to try and gain control of the
second 8K section by writing, then reading a zero into Semaphore 1.
If it succeeded in gaining control, it would lock out the left side.
Once the left side was finished with its task, it would write a one to
Semaphore 0 and may then try to gain access to Semaphore 1. If
Semaphore 1 was still occupied by the right side, the left side could
undo its semaphore request and perform other tasks until it was able
to write, then read a zero into Semaphore 1. If the right processor
performs a similar task with Semaphore 0, this protocol would allow the
two processors to swap 8K blocks of Dual-Port RAM with each other.
The blocks do not have to be any particular size and can even be
variable, depending upon the complexity of the software using the
semaphore flags. All eight semaphores could be used to divide the
Dual-Port RAM or other shared resources into eight parts. Sema-
phores can even be assigned different meanings on different sides
rather than being given a common meaning as was shown in the
example above.
Semaphores are a useful form of arbitration in systems like disk
interfaces where the CPU must be locked out of a section of memory
during a transfer and the I/O device cannot tolerate any wait states.
With the use of semaphores, once the two devices has determined
which memory area was “off-limits” to the CPU, both the CPU and the
I/O devices could access their assigned portions of memory continu-
ously without any wait states.
Semaphores are also useful in applications where no memory
“WAIT” state is available on one or both sides. Once a semaphore
handshake has been performed, both processors can access their
assigned RAM segments at full speed.
Another application is in the area of complex data structures. In this
case, block arbitration is very important. For this application one
processor may be responsible for building and updating a data
structure. The other processor then reads and interprets that data
structure. If the interpreting processor reads an incomplete data
structure, a major error condition may exist. Therefore, some sort of
arbitration must be used between the two different processors. The
building processor arbitrates for the block, locks it and then is able to
go in and update the data structure. When the update is completed, the
data structure block is released. This allows the interpreting processor
to come back and read the complete data structure, thereby guaran-
teeing a consistent data structure.
