andrew@isdg.cs.hull.ac.uk (Andrew Stewart) (01/20/89)
Does anyone have experience of using the MEMWAIT pin on a T8 or a T4 to
stretch the memory cycle? I have a circuit that doesn't appear to work,
despite following the timings laid down in the T800 product description. As
far as I can see, the memory cycle is ending *despite* MEMWAIT being held
low; I'm taking memwait low at the same point in the cycle as MS3 goes low,
and I'm using the internal memory configuration available on AD7. (The
slowest multiplexed DRAM time).
On the logic analyser, I get this (amid lots of other rubbish):
<- ~200ns ->
MS0: ------|________________|-------------
MS2: -----------|___________|-------------
MS3: -------------|_________|-------------
MEMWAIT:-------------|_________|-------------
which looks quite odd.
Anyone got any suggestions?
Andrew Stewart
--------------------
Andrew Stewart, Interactive Systems Design Group, University of Hull, Hull, UK
ARPA: andrew%hu-isd.uucp@ukc.ac.uk OR andrew@cs.hull.ac.ukjdr@gec-rl-hrc.co.uk (jdr) (01/21/89)
> Does anyone have experience of using the MEMWAIT pin on a T8 or a T4 to > stretch the memory cycle? I have a circuit that doesn't appear to work, > despite following the timings laid down in the T800 product description. As > far as I can see, the memory cycle is ending *despite* MEMWAIT being held > low; I'm taking memwait low at the same point in the cycle as MS3 goes low, > and I'm using the internal memory configuration available on AD7. (The > slowest multiplexed DRAM time). MemWait needs to be sampled as *high* in order to extend the memory cycle. The transputer samples MemWait close to the last falling edge of ProcClockOut *before* the end of T4. notMemS3 goes low at exactly this point for the AD7 configuration, and is thus not a sensible strobe to use. Section 8.12 of the T800 engineering data states that whatever strobe you use, "its delay should be such as to take the [MemWait] strobe low an even number of periods Tm after the start of T1, to coincide with a rising edge of ProcClockOut". If this doesn't help, you might like to send me more details of your memory configuration, and I'll see if there are any other comments I can make. My own board has a T800 running at 25 Mhz, with 16 Mbyte of DRAM running with a 200ns cycle time using the AD6 configuration. I assert MemWait using a state machine (clocked by ProcClockOut), which is needed to control a hand-shaking bus interface in part of the transputer's memory map. The state machine is triggered by a correct address and notMemS2 going low, and asserts MemWait within 7ns after a rising edge of ProcClockOut. John// =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Robson | Phone: +44 1 908 9662 (direct dial) | | Research Engineer | Telex: 923429 GECLAB G | | GEC Hirst Research Centre | Fax: +44 1 904 7582 | | East Lane |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=| | Wembley | uucp: uunet!mcvax!ukc!gec-rl-hrc!jdr | | Middlesex HA9 7PP | JANET: jdr@uk.co.gec-rl-hrc | | United Kingdom | ARPA: jdr@gec-rl-hrc.co.uk | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
andrew@isdg.cs.hull.ac.uk (Andrew Stewart) (01/21/89)
>The transputer samples MemWait close to the last falling edge of ProcClockOut >*before* the end of T4. notMemS3 goes low at exactly this point for the AD7 >configuration, and is thus not a sensible strobe to use. Section 8.12 of the >T800 engineering data states that whatever strobe you use, "its delay >should be such as to take the [MemWait] strobe low an even number of >periods Tm after the start of T1, to coincide with a rising edge of >ProcClockOut". As you point out, MEMWAIT is active high, not active low. That was a slip of the memory. I do indeed generate active high on MEMWAIT. I agree about tieing MEMWAIT to MS3, but tieing it to MS4 didn't work, so... Basically, I have MEMWAIT set up so that, during an I/O cycle, it goes high with MS3 and stays high for at least 60ns - if the I/O processor requests a longer delay, MEMWAIT is stretched as far as necessary; the idea was that MEMWAIT could only go low after 60ns + whatever-was-necessary; since MEMWAIT is sampled near falling edges of ProcClockOut, that should introduce at least one wait state in the cycle. But, no dice. So, the timing should look something like this: Tstate: T1 T1 T2 T2 T3 T3 T4 T5 T5 T5 T5 T6 T6 P.C.Out: _|--|__|--|__|--|__|--|__|--|__|--|__|--|_ MS0: -------|__________________________|------- MS3: ----------------|_________________|------- WAIT: ________________|-------XXXXXXX|__________ Notice that MEMWAIT is high during at least one falling edge of P.C.Out, but gets pushed to the right as necessary. The T800 seems to ignore it totally; regardless of how far MEMWAIT stretches, MS0 is always the same length. Any ideas? Andrew -------------------- Andrew Stewart, Interactive Systems Design Group, University of Hull, Hull, UK ARPA: andrew%hu-isd.uucp@ukc.ac.uk OR andrew@cs.hull.ac.uk
w-colinp@microsoft.UUCP (Colin Plumb) (01/21/89)
andrew@isdg.cs.hull.ac.uk (Andrew Stewart) wrote: > Does anyone have experience of using the MEMWAIT pin on a T8 or a T4 to > stretch the memory cycle? I have a circuit that doesn't appear to work, > despite following the timings laid down in the T800 product description. I'm not an expert, but when working in the company of experts, there was quite an explosion when we found out we'd have to change the hardware to work around metastability problems MemWait has if it is changed too close to a clock edge. I never did learn the exact details, but I am sure of those few facts. Beat on Inmos for details. > As far as I can see, the memory cycle is ending *despite* MEMWAIT being held > low; I'm taking memwait low at the same point in the cycle as MS3 goes low, > and I'm using the internal memory configuration available on AD7. (The > slowest multiplexed DRAM time). Try some sort of delay to slow down the assertion of Wait a bit. S3 comes on a clock edge, and MemWait doesn't take to being fed that. > On the logic analyser, I get this (amid lots of other rubbish): > > <- ~200ns -> > > MS0: ------|________________|------------- > MS2: -----------|___________|------------- > MS3: -------------|_________|------------- > MEMWAIT:-------------|_________|------------- > > which looks quite odd. Very odd. Could you perhaps include ProcClockOut for reference? That memory configuration is diagrammed in the data book, and what puzzles me is that S0 and S2 are so far apart, while S2 and S3 are so close. They should be 25 and 50 nanoseconds apart, respectively. And shouldn't be affected by the MemWait pin, since nothing's happened to it yet. Or is this access cycle right after another that also used the MemWait pin? If so, are the patterns highly repeatable? Metastability would be evidenced by erratic patterns. -- -Colin (uunet!microsoft!w-colinp)