randy@pecnos.UUCP (04/23/87)
I have a question of the VME/68020 gurus out there. This question relates to how CAS and CAS2 are being implemented using the VME bus since they don't directly map to the defined bus control structure for indivisible cycles. As with the 68000 and 68010, the TAS of the 68020 maps into the RMW type of cycle of the VME bus. Likewise the single operand CAS also maps into the RMW. The problem comes when the CAS or CAS2 uses multiple operands and does not map into the RMW cycle. This is because multiple different addresses may be used and so AS- on the VME bus must be toggled, thus defeating the mechanism which keeps the RMW cycles indivisible. One way to solve this is to detect these types of CAS and CAS2 cycles and have the boards bus requester hold BUSY- on the VME bus throughout the processor cycle (i.e. while RMC- of the 68020 is asserted) and release when the cycle is done. This works fine for single ported memories, but... The problem with this is for dual ported memories. These may be either processor boards with dual-ported local memory or a memory board dual-ported to the VME bus and another bus (e.g. VMX). In order to make the access to the memory indivisible, the dual-port arbiter must lock to the selected port not only on VME AS- (like for a RMW cycle) but also lock on VME BUSY-. Again this is something that can be done. The problem comes about when a release-on-request board is used (ROR). Since this type of requester holds BUSY- asserted until another bus master request the bus, a dual-port arbiter would "lock-up" on the VME bus access even though the CAS cycle is over. This lock-up will lock out any accesses from the other port (i.e. the processor or other bus). Bad news! I have also seen another solution to mapping the CAS/CAS2 cycles to the VME bus which uses the reserved pin on connector P2 to drive RMC- from the 68020 onto the bus. This is a great solution except it is not part of the VME spec and standard VME boards know nothing about this extra signal. The bottom line question is: How are VME 68020 boards implementing CAS/CAS2 to dual-ported memory without locking things up for an undetermined amount of time? (Besides not using ROR type bus masters) I have studied several boards and have not seen a satisfactory solution. Thanks for any insight you may have. Randy Banton
gnu@hoptoad.uucp (John Gilmore) (04/26/87)
Randy Banton asks a good question with regard to 68020's running
multiprocessor stuff on the VMEbus. The VMEbus only supports the
68000 style of bus locking (keep address strobe active while jiggling
the data strobes), but this only allows an atomic read and write of a single
address. The 68020 allows bus locks on unaligned addresses and also provides
an 8-byte read-compare-and-swap operation.
Sun faced this when designing their 68020 based VMEbus systems. As I
recall, the answer was the same as proposed by Randy -- the board inhibits
arbitration of the VMEbus while the 68020 RMC (bus lock) signal is active,
preventing any other VMEbus master from interspersing cycles.
This is NOT sufficient to lock accesses in a dual ported memory (e.g.
the on-board memory of a Sun-3, which can be accessed by the CPU directly,
or via the VMEbus). We decided that if you wanted multiple CPUs to talk
to the same memory, it had better be a global VMEbus memory board that none
of the CPUs had preferential (dual port) access to. This sidesteps the
problem at the expense of a small memory board in multi-CPU systems.
(This is from memory; your mileage or Sun CPU boards may vary.)
--
Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu gnu@ingres.berkeley.edu