News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

CPC - Clock jitter

Started by Dandare, 01:18, 16 March 19

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dandare


Hi everybody,
I'd like to tell you a little tale that led to CPC clock jitter discovery (edit: may be better called duty-cycle variance?) . (preliminary discovery)

I'm fairly new to the CPC, but in the past months I've come to learn quite a bit about its hardware implementation as I was designing the CPC Dandanator.


One of the first things I read from the very start is that the clock in the CPC is running at 4mhz while, for video output reasons, effective clock speed is slower (due to the automatic wait insertion). In any case, and as opposed to the Sinclair Spectrum where 48k and 128k speeds are different, the CPC timings are consistent across all the models.
So I assumed as much and designed the CPC Dandanator, that works nicely on all the CPC range since it's synched to the internal clock.
So far so good.


Then I developed a bitbang routine to talk to a PC/MAC over USB, running at 57.600 bps. All good here. I did some tests for 115.200 but it was pretty tight according to the CPC timings so I didn't want to publish it.
Some weeks ago, Syx took a look at the 115.200 routine and proposed a couple of nops here and there and everything started working like a charm, so we launched our code with 115.200bps for the 200 USB-Equipped CPC dandanator on the field.


Yesterday, a Spanish forum user (metsämies) pointed that it was working perfectly on a 6128, but not so good on a CPC464... So I did some preliminary investigation and I was able to replicate his problem. I found this funny fact on a 464 when testing the CLK signal on a 100Mhz oscilloscope (so it shouldn't be caused by aliasing) : 4Mhz clock is not really a 4mhz clock.


Let me try and explain it. It is a 4mhz clock but it's not quite, in the sense that there is jitter between cycles (duty cycle variance), meaning that some pulses are shorter than 4mhz and some are longer, giving a mean 4mhz speed, but not a single pulse, or even a small sample, 4mhz clock. (first tests show up to a 2% error).
This shouldn't be a problem when using the CPC on its own (all is referred to the internal clock), using it with slow peripherals (tape for instance) or to highly-tolerant devices, like the monitor.


But when it comes to fast asynchronous digital signals like a serial port at 115.200bps (a bit over 0,1Mhz), that have to be in sync with the sampling from  the Z80 and have some jitter on their own, and considering that Z80 instruction granularity also affects the sampling, we have found a problem. (it's already solved/worked-around in this particular case, by the way)


This is only a preliminary assessment of the problem, but I wanted to start a topic because I'd like to open an statistical study of the CPC clock speed, and correlate it to several variables such as CPC model, revision and GA and CRTC part numbers, crystal reference, room temperature..


At the end of the day we may come to a conclusion that's not only based in a couple of samples and this could broaden our knowledge of the real CPC hardware behaviour.


I'll start putting together a sample collection procedure so we can compare "apples to apples". Once I have this, I'll start the testing within the GUA (Amstrad User Group) in Spain and open it to anyone that is willing to participate.




As a first glance of this behaviour these are two captures of the clock in two different CPCs
- First one is a CPC Version 1 Z70200 MC0001A. You can clearly see the jitter in the clock
- Second one is in a CPC Version 3 Z70375 MC0044D. Much cleaner and steady clock.

tjohnson

Interesting, where are you measuring the clock from?

Dandare

#2
Quote from: tjohnson on 08:18, 16 March 19
Interesting, where are you measuring the clock from?


Pin 6 of the Z80. Clock input of the CPU.
I'm about to measure the 16mhz clock at the input of the GA, after the not gate, to try to determine whether the problem is in the GA or in the clock generator circuit.

Dandare

#3
Thanks to mad3001, we have an excellent oscilloscope capture that suggest the problem is in the falling edge of the clock produced by the 40007 Gate Array.


In this capture,
Magenta is the 16Mhz clock generated by the crystal and Not gate.
Blue is the 4Mhz clock generated by the GA on pin 39 of the 40007.
Yellow is the inverted clock by the ZTX transistor when it enters the Z80 (pin 6).


We can also see the different propagation delays introduced by the GA (a bit south of 10ns) and the ZTX, (around 15ns).





gerald

Quote from: Dandare on 01:18, 16 March 19
Let me try and explain it. It is a 4mhz clock but it's not quite, in the sense that there is jitter between cycles, meaning that some pulses are shorter than 4mhz and some are longer, giving a mean 4mhz speed, but not a single pulse, or even a small sample, 4mhz clock. (first tests show up to a 2% error).
This shouldn't be a problem when using the CPC on its own (all is referred to the internal clock), using it with slow peripherals (tape for instance) or to highly-tolerant devices, like the monitor.
Welcome to thre real world  :D
Every clock has a jitter, like it or not !
Some more than other, but in CPC case this has never been an issue.

Quote from: Dandare on 01:18, 16 March 19
But when it comes to fast asynchronous digital signals like a serial port at 115.200bps (a bit over 0,1Mhz), that have to be in sync with the sampling from  the Z80 and have some jitter on their own, and considering that Z80 instruction granularity also affects the sampling, we have found a problem. (it's already solved/worked-around in this particular case, by the way)
When you transfers data between two asynchronous clock domains you have to manage the synchronisation by yourself.
Expecting two independent clocks to be magically aligned is just expecting someone else doing the magic for you !Counting on that is a defective design.


Quote from: Dandare on 01:18, 16 March 19
This is only a preliminary assessment of the problem, but I wanted to start a topic because I'd like to open an statistical study of the CPC clock speed, and correlate it to several variables such as CPC model, revision and GA and CRTC part numbers, crystal reference, room temperature..


At the end of the day we may come to a conclusion that's not only based in a couple of samples and this could broaden our knowledge of the real CPC hardware behaviour.


I'll start putting together a sample collection procedure so we can compare "apples to apples". Once I have this, I'll start the testing within the GUA (Amstrad User Group) in Spain and open it to anyone that is willing to participate.




As a first glance of this behaviour these are two captures of the clock in two different CPCs
- First one is a CPC Version 1 Z70200 MC0001A. You can clearly see the jitter in the clock
- Second one is in a CPC Version 3 Z70375 MC0044D. Much cleaner and steady clock.
You're missing one side of the problem there : the other side of you asynchronous system.
And you cannot count on it being perfect either.
I think you'll better spend your time by designing a proper communication protocol rather than relying on statistics.

Dandare

#5
Dear Gerald,

I've been on the real world for quite some time now, thanks.

Yes, I do manage the synchronization: this is telco 101, thanks again.

I'm not missing the other part variance. I'm very much aware of it but it's completely independent of what I'm analysing here: "The difference of clock jitter between different GateArray versions or even batches. Need data to come to a conclusion, hence the statistics part.

As for "designing a proper communication protocol" I'm somewhat familiar with that since It's part of what I teach at University and the basis of the company I founded 15 years ago.


The goal of this post is not to solve a specific problem (already solved by the way) but trying to get data for different CPC/Gate Array behaviour for creating a predictable basis. That's part of any researching process.

gerald

Quote from: Dandare on 16:24, 16 March 19
Dear Gerald,

I've been on the real world for quite some time now, thanks.

Yes, I do manage the synchronization: this is telco 101, thanks again.

I'm not missing the other part variance. I'm very much aware of it but it's completely independent of what I'm analysing here: "The difference of clock jitter between different GateArray versions or even batches. Need data to come to a conclusion, hence the statistics part.

As for "designing a proper communication protocol" I'm somewhat familiar with that since It's part of what I teach at University and the basis of the company I founded 15 years ago.


The goal of this post is not to solve a specific problem (already solved by the way) but trying to get data for different CPC/Gate Array behaviour for creating a predictable basis. That's part of any researching process.
For someone familiar with that, I just wonder why you had to find a workaround to a common clock jitter problem ...
But since you know your stuff, just go ahead. and do your stat  ;)

Bryce

Maybe I'm missing the point here, but discovering a clock with jitter is like finding wet water! As for what's causing the jitter, here's a list of things that will cause it:

Temperature, humidity, position on the earth, clocks height above sea level, orientation / angle of the oscillator, someone walking past the device, magnetic fields (including the earths).
If you find a clock without jitter, that would be something worth talking about. I'm sure that every single GA will have varying degrees of jitter, regardless of type/production batch etc.


Clock jitter should not be a factor in asynchronous comms anyway as both systems should be using the same clock with or without jitter.

Bryce.

Dandare

#8
Quote from: Bryce on 17:52, 16 March 19
Maybe I'm missing the point here, but discovering a clock with jitter is like finding wet water! As for what's causing the jitter, here's a list of things that will cause it:

Temperature, humidity, position on the earth, clocks height above sea level, orientation / angle of the oscillator, someone walking past the device, magnetic fields (including the earths).
If you find a clock without jitter, that would be something worth talking about. I'm sure that every single GA will have varying degrees of jitter, regardless of type/production batch etc.


Clock jitter should not be a factor in asynchronous comms anyway as both systems should be using the same clock with or without jitter.

Bryce.


Hi Bryce,

I reckon that the fact that certain GA produce a variable delayed falling edge output in each cycle of the clock as opposed to a steady 16mhz clock generation, while other part numbers do not is a relevant fact if your goal is understanding the GA functioning. And this is when the source 16Mhz clock is steady.
Now, I understand that this may not be of interest to you or other forum members


"I'm sure that every single GA will have varying degrees of jitter, regardless of type/production batch etc" : while this may be true, now it's only an opinion. If we do some researching we could say it as a fact. And opinions and facts are different things.

Again, this has nothing to do with the async communication. the comm just made me take a look at this

Dandare

Quote from: gerald on 17:18, 16 March 19
For someone familiar with that, I just wonder why you had to find a workaround to a common clock jitter problem ...
But since you know your stuff, just go ahead. and do your stat  ;)


Why wonder when you can experience it for yourself?: just go ahead and program a 115.200bps bitbanging serial in routine in the CPC and you'll find out.

Bryce

#10
Quote from: Dandare on 18:03, 16 March 19

Hi Bryce,

I reckon that the fact that certain GA produce a variable delayed falling edge output in each cycle of the clock as opposed to a steady 16mhz clock generation, while other part numbers do not is a relevant fact if your goal is understanding the GA functioning. And this is when the source 16Mhz clock is steady.
Now, I understand that this may not be of interest to you or other forum members


"I'm sure that every single GA will have varying degrees of jitter, regardless of type/production batch etc" : while this may be true, now it's only an opinion. If we do some researching we could say it as a fact. And opinions and facts are different things.

Again, this has nothing to do with the async communication. the comm just made me take a look at this

But that's incorrect, there are no certain types of GA that produce a perfectly timed falling edge, they ALL have jitter, the question is just how much. Even tiny changes in the thickness of the N or P substrate within the chip, the inductance and capacitance of the internal structure of the silicon and bond wires are all variables and will be different in every single chip. Some may hit the exact target you are looking for by accident, but the Gaussian curve rule applies, so many won't.


That's why chips have tolerances and chips designed for extremely high accuracy or frequency are much more expensive because the parameters have to be much more controlled. All you are seeing in the natural variance within an IC that was designed for a system that doesn't go above 16Mhz. The jitter you show above is well within the tolerances.


Going further, every other chip connected to the clock will effect jitter too. If you want to do an experiment, take any 74 series IC (a few of the same type, same batch etc) and feed them with a really accurate clock. Feed them all with a 16Mhz clock and measure the jitter on each output. They will all have jitter to some extent and just warming the chip with your finger is enough to vary the amount of jitter.  And this is NOT an opinion, it will always be stated in the datasheets.


If your goal is to come up with some sort of statement such as "40010 type X are good and 40010 type Y aren't" then you will be looking forever. 500 GA's will give 500 different results.

You should also check out some of the components available such as the LMK03328 from Ti (about €10 per chip). This is a clock generator for high accuracy systems, full of additional hardware and PLLs etc to make it as stable as possible, but they still call it "ultra low jitter" not "jitterless".


Bryce.

Dandare

#11
That's not my goal and again, I don't know why you are assuming that I said "there is no jitter in a clock". I said (or I tried anyway) that the duty cycle is changing from one pulse to the other but, in the small amount of observations so far, orders of magnitude more noticeable in 40007 GAs. Maybe the word jitter is not the most accurate one here, I would assume that if a native says so, but then I play my non-native English speaker card and we are good to go  :)

The point in your last sentence was the word "regardless" where what I'm trying to research is, precisely, the standard deviation of the duty cycle in regards to the GA Part Number. And also the duty cycle range.

"500 GA's will give 500 different results." : That's why we have statistics and means, and standard deviations and, exactly, what I'm trying to analyse.


If they are correlated, it will allow for a regression and then an estimation of this duty cycle variance just by knowing the GA part number. (or the other way around, guessing the GA part number just by sampling the clock).


And then we can be sure whether some fast things can be done safely in all CPCs or not, for instance.
And even if there was no practical purpose for the findings, I think coming to a conclusion about this deviation in regards to the GA PN is worth a few tests.



Bryce

One last comment on your method of measurement: You're only seeing the jitter on the falling edge because you're triggering on the rising edge. If you trigger on the falling edge, the jitter will appear to be on the rising edge. Also, due to the rise and fall being non-linear, the chosen trigger level will effect the amount of jitter displayed.

Bryce.

Gesendet von meinem Motorola DynaTAC 8000x mit Tapatalk


Dandare

#13
Quote from: Bryce on 19:14, 16 March 19
One last comment on your method of measurement: You're only seeing the jitter on the falling edge because you're triggering on the rising edge. If you trigger on the falling edge, the jitter will appear to be on the rising edge. Also, due to the rise and fall being non-linear, the chosen trigger level will effect the amount of jitter displayed.

Bryce.

Gesendet von meinem Motorola DynaTAC 8000x mit Tapatalk


Yes, I know, thanks. Trigger is in the 16mhz clock, I'm measuring the "length" of the 1 signal.
What you can see is that the 16mhz clock is not causing those differences (apparently, as they would be smaller) but the 4mhz is, and again, only in 40007 GAs.
Anyway I refrased my "jitter" to duty cycle variance, and also tried to explain that in the few observations so far, there is an apparent order of magnitude difference between 40007s and other GA, so maybe it's clearer now.

gerald

Quote from: Dandare on 19:17, 16 March 19

Yes, I know, thanks. Trigger is in the 16mhz clock, I'm measuring the "length" of the 1 signal.
What you can see is that the 16mhz clock is not causing those differences (apparently, as they would be smaller) but the 4mhz is, and again, only in 40007 GAs.
Anyway I refrased my "jitter" to duty cycle variance, and also tried to explain that in the few observations so far, there is an apparent order of magnitude difference between 40007s and other GA, so maybe it's clearer now.
On the 40010 the 4MHz clock is generated from the internal state registers and is then re-sampled by the 16MHz clock (falling edge). So it's expected that you will not see that much jitter between the 4MHz and 16MHz.
Details on page 3 of the attached schematic : http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/gate-array-decapped!/msg170713/#msg170713

On a 40007, it might be that the final DFF does not exist and you see the timing difference between the different path from the state register to the clock output. To confirm this one has to reverse engineer the 40007 die.
If it's the case, if you trig on the AY clock (1MHz) the 4MHz clock edge should match 4 by 4.

Dandare

Quote from: gerald on 19:55, 16 March 19
On the 40010 the 4MHz clock is generated from the internal state registers and is then re-sampled by the 16MHz clock (falling edge). So it's expected that you will not see that much jitter between the 4MHz and 16MHz.
Details on page 3 of the attached schematic : http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/gate-array-decapped!/msg170713/#msg170713

On a 40007, it might be that the final DFF does not exist and you see the timing difference between the different path from the state register to the clock output. To confirm this one has to reverse engineer the 40007 die.
If it's the case, if you trig on the AY clock (1MHz) the 4MHz clock edge should match 4 by 4.


Thanks, I'll take a look.

GUNHED

Well, very interesting. Looks like Amstrad was aware of the problem and made it "smaller" in later PCB revisions. 2% is a lot. Thanks for providing the hard data here.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Bryce

Quote from: Dandare on 19:17, 16 March 19

Yes, I know, thanks. Trigger is in the 16mhz clock, I'm measuring the "length" of the 1 signal.
What you can see is that the 16mhz clock is not causing those differences (apparently, as they would be smaller) but the 4mhz is, and again, only in 40007 GAs.
Anyway I refrased my "jitter" to duty cycle variance, and also tried to explain that in the few observations so far, there is an apparent order of magnitude difference between 40007s and other GA, so maybe it's clearer now.

The length (ie: duty cycle) shouldn't have any effect on any other parts of the circuit unless there are some parts triggering on the fall. If all components are triggering on the rise, then duty cycle doesn't matter. A 4Mhz signal of any duty cycle (other than 0) will always have rising edges 250µs apart.

Bryce.

Dandare

#18
This thread is going nowhere. Generic and obvious responses that don't dig into what happens aren't really helping. Duty cycle changes and cycle length changes in every cycle (both significantly), but apparently no one cares, except maybe Amstrad did and so they changed their design in more recent GAs.
I opened it to share the beginning of the research I was planning to do not to start an electronics 101 course.

If someone is interested in the composition of the 4mhz signal by the 40007, please drop me a PM and I'll share my findings when I have them.
This said, I consider this thread closed. "Good bye and thanks for all the fish"  :)

Bryce

When I get a chance, I'll do some measurement on a 40007 464 that I have here as a comparison if that helps. I also have several 40010 CPC's too if you want more data.

Bryce.

LambdaMikel

Quote from: Dandare on 14:16, 18 March 19
This thread is going nowhere. Generic and obvious responses that don't dig into what happens aren't really helping.

Yes, I had similar experiences here. This is wrong audience for this kind of topic. I suggest to take this to a board such as mikrocontroller.net

This here is more for gaming and demos and stuff.


gerald

Quote from: gerald on 19:55, 16 March 19
On a 40007, it might be that the final DFF does not exist and you see the timing difference between the different path from the state register to the clock output. To confirm this one has to reverse engineer the 40007 die.
If it's the case, if you trig on the AY clock (1MHz) the 4MHz clock edge should match 4 by 4.
I've done the measure by myself :
If you trigger on the nCPU signal, which is also the AY 1MHz clock and requires a full states loop, you will not find any noticeable jitter on the 4MHz clock edges. Trace are as thick as on the jitter capture, which confirm the hypothesis and is the direct output of the GA states register combination.
-> The edge are exactly at the same position each state loop (16 16MHz clock cycles).

The attached is capture of the 4 MHz clock cycle to cycle jitter.
Scope trigger on rising edge of 4MHz clock, and show the next rising edge (252ns delay) with infinite persistence.
You can clearly see 4 distinct edges which correspond to 4 distinct delay from the 4 state registers that are used for generating the 4MHz clock
-> clock is not re-sampled by the 16MHz clock.





gerald

Quote from: Dandare on 14:16, 18 March 19
This thread is going nowhere. Generic and obvious responses that don't dig into what happens aren't really helping. Duty cycle changes and cycle length changes in every cycle (both significantly), but apparently no one cares, except maybe Amstrad did and so they changed their design in more recent GAs.
I opened it to share the beginning of the research I was planning to do not to start an electronics 101 course.

If someone is interested in the composition of the 4mhz signal by the 40007, please drop me a PM and I'll share my findings when I have them.
This said, I consider this thread closed. "Good bye and thanks for all the fish"  :)
Before leaving, would you care explaining what was the fix for the problem ?

andycadley

All this measuring seems fascinatingly technical and probably goes deeper than all the bits of electronics I've long since forgotten from my degree days. What I do know, though, is that if the clock was varying by as much as 2% you'd not have a terribly stable display, so something seems amiss somewhere.

Dandare

Thank you all for the diagrams and information.


The ˜2% variation is not in the video generation circuit, but on the Z80 Clock.


Final solution for the initial problem is based on stretching of the RX line by means of buffering it to a latch according to the 4Mhz Clk

Powered by SMFPacks Menu Editor Mod