From: kegs@provalid.com
In article ,
Charlie wrote:
>On 8/4/2022 7:52 AM, Anthony Ortiz wrote:
>> In the Apple IIe #2 tech notes for DMA, they state the following:
>>
>> "...there will be some skew between edges of the 7 M clock and the
>timing signals from the PAL, such as the edges of 0o or 01. This skew
>means the 7 M clock edge may rise as much as 20 ns before, or 5 ns
>after, the 0o falling edge."
>
>Yeah, that's a pretty ambiguous note.
>
>> Is this skew only at the 0o falling edge? I ask because I'm using the
>7m for timing when to read/write.
>
>It is my understanding that skew means that one clock signal is delayed
>in relation to another. In other words 7M and phase0 had at one time
>been in sync with each other (that is, the rising edge of phase0 happens
>at exactly the same time as a rising edge of 7M) but phase0 became
>delayed because it went through more circuitry than 7M.
>
>People who know more about hardware than me should jump in here if I'm
>wrong.
>
>Anyway, to answer your question, I think that both the rising and
>falling edges of phase0 would be skewed.
>
>Charlie
Clock signals are not meant to capture each other, and it's tricky to
use the "wrong" clock signal to capture data driven by a different clock.
By specifying skew, Apple's reminding people about these basic rules.
I think it's just a hint that you should be careful trying to latch
bus data using 7M instead of ph0. Also, one popular suggestion was to delay
ph0 using 7M to latch it to create a new clock edge for better timing (I
think for hold time reasons)--and this note is basically saying you need to
use the falling edge of 7M to do that since the rising edge of 7M cannot
capture ph0 properly.
It's best if you use ph0 to capture bus data, possibly delayed for hold
time. Directly using 7M is problematic, and you'll need to qualify it
to avoid metastability issues, and to properly qualify it would seem to
take a lot of TTL logic.
Kent
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
