Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!hellgate.utah.edu!cc.usu.edu!slsw2
From: slsw2@cc.usu.edu
Newsgroups: comp.sys.dec
Subject: Re: Caching Turbo Channel access ??
Message-ID: <1991Jun26.153736.48239@cc.usu.edu>
Date: 26 Jun 91 21:37:36 GMT
References: <1991Jun26.010347.6638@mel.dit.csiro.au> <1991Jun26.024702.169@pa.dec.com> <1991Jun26.180424.27695@pa.dec.com>
Organization: Utah State University
Lines: 14

In article <1991Jun26.180424.27695@pa.dec.com>, santiago@lerad.pa.dec.com (Ed Santiago) writes:
>   TURBOchannel options may perform DMA anywhere in
> system memory.  However, DMA transfers do *not* go through the cache,
> so if a transfer occurs to a page that is currently cached, the cache
> will not know about it and keep presenting stale data to the CPU.

Actually, the TURBOchannel spec doesn't *forbid* DMA from going through the
cache, it's just that current implementations don't. That's what I like about
the TURBOchannel spec: carefully designed to be vague in all the right places
(example: "memory access latency; may be many t3 cycles" on pg. 7; you could
pipe TURBOchannel out an RS-232 port and not violate that...).

Roger Ivie
slsw2@cc.usu.edu