13 May
2004
13 May
'04
6:46 a.m.
>>>> "Brad" == Brad Parker
<brad(a)heeltoe.com> writes:
Brad> Paul Koning wrote:
> That should do the job just fine for MSCP (except
that this may be
> too large a job for a PIC). For older disk controllers, this
> approach is likely to be hard because touching CSRs causes actions
> to take place, and often actions are tied to bits, not just to the
> whole CSR. You may be able to emulate that in software, but it's
> likely to be tricky because your CPLD will have to be more than
> just a register file.
Brad> well, yes, cpld need to notice when a register is written from
Brad> the unibus and potentially interrupt the cpu.
Brad> there are certainly some interlocking issues to keep the two
Brad> cpu's in sync.
Brad> no reason why the cpld can't do this on bit by bit basis...
It's worse than that in some cases.
For example, if you have mixed read/write and read-only bits, if you
write the CSR and then read it, you want to read the correct read-only
status values. If you try to fake this by having a microprocessor
restore those bits after being interrupted by the CPLD, the read may
get there first.
Similarly, the values you see in one register may change depending on
what's in another register. An example is the drive status, which
reflects the currently selected drive (in a number of disk
controllers). Again, a software emulation may not get there in time.
You might try to cheat by holding off SSYN on the Unibus read until
any pending CSR fixups are done, but then the microcontroller has a
rather tight time limit (20 microseconds or so).
paul