| 7m skew to phase0 [message #415934] |
Thu, 04 August 2022 07:52  |
anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
|
Senior Member |
|
|
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. "
Is this skew only at the 0o falling edge? I ask because I'm using the 7m for timing when to read/write.
|
|
|
|
| Re: 7m skew to phase0 [message #415956 is a reply to message #415934] |
Thu, 04 August 2022 20:41  |
Charlie
Messages: 255
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: 7m skew to phase0 [message #416031 is a reply to message #415956] |
Sun, 07 August 2022 23:24 |
|
|
Originally posted by: kegs
In article <tchp0p$2um30$1@dont-email.me>,
Charlie <charlieDOTd@verEYEzon.net> 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
|
|
|
|
| Re: 7m skew to phase0 [message #416053 is a reply to message #416031] |
Tue, 09 August 2022 20:37 |
Charlie
Messages: 255
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 8/7/2022 11:24 PM, Kent Dickey wrote:
> In article <tchp0p$2um30$1@dont-email.me>,
> Charlie <charlieDOTd@verEYEzon.net> 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.
Okay, thanks for the clarification.
>
> 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
By 'qualify' do you mean synchronizing the signals?
I use two flip-flops to synchronize an Apple II slot signal such as
phase0 to the card's 'system' clock (which is the Carte Blanche II 'on
board' clock).
For what it is worth, I would try to avoid using DMA if I was designing
a card to work on all slotted Apples. There seems to be a number of
differences in the way the different models need to do DMA. I doubt it
is worth the effort. But then I don't know anything about accelerators.
Charlie
|
|
|
|
| Re: 7m skew to phase0 [message #416055 is a reply to message #416053] |
Tue, 09 August 2022 21:41 |
anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
|
Senior Member |
|
|
> For what it is worth, I would try to avoid using DMA if I was designing
> a card to work on all slotted Apples. There seems to be a number of
> differences in the way the different models need to do DMA. I doubt it
> is worth the effort. But then I don't know anything about accelerators.
>
> Charlie
Is there a way to make a slottable replacement processor that didn't use DMA?
|
|
|
|
| Re: 7m skew to phase0 [message #416058 is a reply to message #416055] |
Tue, 09 August 2022 22:41 |
Charlie
Messages: 255
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 8/9/2022 9:41 PM, Anthony Ortiz wrote:
>> For what it is worth, I would try to avoid using DMA if I was designing
>> a card to work on all slotted Apples. There seems to be a number of
>> differences in the way the different models need to do DMA. I doubt it
>> is worth the effort. But then I don't know anything about accelerators.
>>
>> Charlie
>
> Is there a way to make a slottable replacement processor that didn't use DMA?
Apparently there is.
This link shows several accelerators. Most are not DMA compatible.
https://en.wikipedia.org/wiki/Apple_II_accelerators
I believe the only one that is DMA compatible and uses a slot is a ZipGSX.
Anyway, what I meant is that since you stated that you wanted your card
to be usable on all slotted Apple II models, DMA would make designing it
more difficult.
Charlie
|
|
|
|
| Re: 7m skew to phase0 [message #416059 is a reply to message #416058] |
Tue, 09 August 2022 22:53 |
anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
|
Senior Member |
|
|
> Apparently there is.
> This link shows several accelerators. Most are not DMA compatible.
>
> https://en.wikipedia.org/wiki/Apple_II_accelerators
>
> I believe the only one that is DMA compatible and uses a slot is a ZipGSX..
>
> Anyway, what I meant is that since you stated that you wanted your card
> to be usable on all slotted Apple II models, DMA would make designing it
> more difficult.
>
> Charlie
I think what they mean by 'DMA compatible' is that the cards are compatible with other cards that use DMA. For now, my accelerator isn't DMA compatible either because I have DMA active all the time and don't respect any of the other cards that want to use DMA. To make mine DMA compatible I would have to listen to other cards DMA requests and share the bus with them according to the DMA sharing protocols. I believe that's what they mean by 'DMA compatible', because Transwarp definitely uses DMA but I know they went the distance to share the bus with other DMA cards, thus earning the 'DMA compatible' seal of approval.
This is a partially educated guess on my part though, so someone correct me if I'm wrong here.
|
|
|
|
| Re: 7m skew to phase0 [message #416061 is a reply to message #416059] |
Wed, 10 August 2022 12:41 |
Charlie
Messages: 255
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 8/9/2022 10:53 PM, Anthony Ortiz wrote:
>> Apparently there is.
>> This link shows several accelerators. Most are not DMA compatible.
>>
>> https://en.wikipedia.org/wiki/Apple_II_accelerators
>>
>> I believe the only one that is DMA compatible and uses a slot is a ZipGSX.
>>
>> Anyway, what I meant is that since you stated that you wanted your card
>> to be usable on all slotted Apple II models, DMA would make designing it
>> more difficult.
>>
>> Charlie
>
> I think what they mean by 'DMA compatible' is that the cards are compatible with other cards that use DMA. For now, my accelerator isn't DMA compatible either because I have DMA active all the time and don't respect any of the other cards that want to use DMA. To make mine DMA compatible I would have to listen to other cards DMA requests and share the bus with them according to the DMA sharing protocols. I believe that's what they mean by 'DMA compatible', because Transwarp definitely uses DMA but I know they went the distance to share the bus with other DMA cards, thus earning the 'DMA compatible' seal of approval.
>
> This is a partially educated guess on my part though, so someone correct me if I'm wrong here.
I won't argue the point since I don't really know how they work.
Charlie
|
|
|
|
| Re: 7m skew to phase0 [message #416072 is a reply to message #416053] |
Thu, 11 August 2022 00:16 |
|
|
Originally posted by: kegs
In article <tcuuk4$1h6sc$1@dont-email.me>,
Charlie <charlieDOTd@verEYEzon.net> wrote:
> On 8/7/2022 11:24 PM, Kent Dickey wrote:
>> In article <tchp0p$2um30$1@dont-email.me>,
>> Charlie <charlieDOTd@verEYEzon.net> 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."
[snip]
>> 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
>
> By 'qualify' do you mean synchronizing the signals?
> I use two flip-flops to synchronize an Apple II slot signal such as
> phase0 to the card's 'system' clock (which is the Carte Blanche II 'on
> board' clock).
"Qualify" means using logic gates (for example) to avoid capturing data
in a flip-flop when the data might be changing. Imagine you have a fast
clock, and want to capture data from a slower domain, but which lines up
with one of your edges. Have logic create a qualifier signal that is
0 during this fast clock period, and AND the data with it. Now, we avoid
latching a signal when it could be changing.
Metastability is not well understood by most people since almost every
detailed description of how to avoid metastability that I've read has
had at least a small bug. A common flaw is if you synthesize logic and
don't have a set of timing constraints between clock domains, you may
not be avoiding metastability. Paths can (and do) take "scenic routes"
if you have no constraints. "Synthesis" is not an issue with TTL since
you're hand placing components.
Sometimes you just have to capture data as its changing, and that's
when the 2-3 flip-flops in a row rule come into play. Note you can really
only do one bit like this, to move a counter requires gray coding and more
care.
The thing about metastability is it's rare--if you have a problem, it may
be hard to detect in practical testing.
Kent
|
|
|
|
| Re: 7m skew to phase0 [message #416080 is a reply to message #416072] |
Thu, 11 August 2022 12:21 |
Charlie
Messages: 255
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 8/11/2022 12:16 AM, Kent Dickey wrote:
> In article <tcuuk4$1h6sc$1@dont-email.me>,
> Charlie <charlieDOTd@verEYEzon.net> wrote:
>> On 8/7/2022 11:24 PM, Kent Dickey wrote:
>>> In article <tchp0p$2um30$1@dont-email.me>,
>>> Charlie <charlieDOTd@verEYEzon.net> 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."
> [snip]
>>> 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
>>
>> By 'qualify' do you mean synchronizing the signals?
>> I use two flip-flops to synchronize an Apple II slot signal such as
>> phase0 to the card's 'system' clock (which is the Carte Blanche II 'on
>> board' clock).
>
> "Qualify" means using logic gates (for example) to avoid capturing data
> in a flip-flop when the data might be changing. Imagine you have a fast
> clock, and want to capture data from a slower domain, but which lines up
> with one of your edges. Have logic create a qualifier signal that is
> 0 during this fast clock period, and AND the data with it. Now, we avoid
> latching a signal when it could be changing.
>
> Metastability is not well understood by most people since almost every
> detailed description of how to avoid metastability that I've read has
> had at least a small bug. A common flaw is if you synthesize logic and
> don't have a set of timing constraints between clock domains, you may
> not be avoiding metastability. Paths can (and do) take "scenic routes"
> if you have no constraints. "Synthesis" is not an issue with TTL since
> you're hand placing components.
>
> Sometimes you just have to capture data as its changing, and that's
> when the 2-3 flip-flops in a row rule come into play. Note you can really
> only do one bit like this, to move a counter requires gray coding and more
> care.
>
> The thing about metastability is it's rare--if you have a problem, it may
> be hard to detect in practical testing.
>
> Kent
Thanks for your detailed answer. I've learned some things from it.
Charlie
|
|
|
|
Members
Search
Help
Register
Login
Home
