Understanding datasheets for max clock speeds

[fredericsegard]

I've designed a few PCB variations of my 65C02 SBC. All run at 2MHz safe speed. The reason why I thought I needed the slower speed was for slower I/O, like the AY-3-8910 PSG and TMS9918A VDP.

I've read a bit on the subject of wait states and clock stretching. I can't say I understand fully and completely, but I get the general gist of it. I would like to implement faster speeds for the next iteration of my 65C02 project, or maybe directly go to the 65C816. Alas, still being fairly new to this (a bit more than a year into this hobby), I have a hard time understanding which values to read in the datasheets to determine the max clock speeds of ROM, RAM, VDP, PSG, and other devices. For example, some of my RAM is rated 70ns and others at 45ns. My ROM is at 150ns. What does that mean in terms of MHz? I'm not inclined to simply say 1/x (i.e. 150ns = 6.666MHz), as this would seem to be a gross over-simplification. What value should I read in the datasheet to determine clock speed?

I've come across this design for clock stretching that I've slightly adapted from the Plank project to have a variable clock divider, depending on the state of SLOW1 and SLOW2. CS decoding and the SLOW outputs would be generated with an ATF22V10 EEPLD (or ATF16V8), according to the limitations of the addressed I/O.

Variable clock stretching circuit diagram

On a side note, for those that played around with the above-mentioned VDP and PSG, what clock speeds have you managed to successfully push those chips to?

[akohlbecker]

Hello Frederic,

The way to determine the maximum frequency for a component is to look at all the signals going into this chip and their timings. Let's run through a quick example. Starting from the CPU, western design center gives you timings for the address bus / read-write, which are 10 to 30ns. That means RWB is valid between 10 to 30ns after the falling edge of the clock. You then need to look at the datasheet for all the chips in your glue logic and propagate those signals until your reach your component. Let's say you go through two 74HC00 NAND gates (as a fictious example), each take 0 to 19ns as per TI's datasheet, so that signal will reach the component between 10 and 30+19*2=68ns. Now the component will take some time to react to this. Let's say this is a AT28C256-15 EEPROM and we're talking about the Chip Enable signal. That chip takes between 0 and 150ns to react. So the data on the bus will be there between 10 and 68+150=218ns. And finally, the CPU has a setup time requirement for reads of let's say 10ns. This gives you the shortest period your clock can have, which is 218+10 = 228ns. That's 1000/218 = 4.58MHz in this fictious example. This is only looking at a given signal of a given component. You need to repeat this exercise for all the other signals reaching this component, figuring out where in the cycle they are valid, and what impact it has on that component's output.

I go into this process in much detail in my videos, for example here I'm talking about the ROM timings https://youtu.be/ygr_uZ_kBh0?t=845 and here I go through a timing propagation exercise, to compute the timings of my address decoding circuit https://youtu.be/8iGp9w-0JNQ?t=1342. I saw you in the comments before but just in case you haven't watched these particular episodes or for anyone else reading.

All in all, there is no easy formula to determine the maximum frequency you can run your clock at. It depends on all your components, how you design your circuit, and any change in your circuit can cascade to other parts and change the outcome. And even then, this is only a theoretical minimum based on the extended range of values given by the datasheets. Significant overclocking can be achieved on top of this number.

Hopefully this helps you get started! Let me know if you have any questions.

[akohlbecker]

As an example, this is a timing diagram I recently built for the VIA in a read cycle. It shows when the VIA expects its control signals to be valid, and the time it takes for those signals to propagate based on my design. Then it shows when the VIA reacts to these signals, and when the CPU needs the signals reaching it to be valid as well.

You can then mentally compress this clock cycle and find the limiting path. In this example, I could shorten the cycle quite a bit: the control signals section shows that the minimum half-period of my clock is 79+10ns, so 1000/89/2 = 5.61MHz would be the maximum for this section. The data bus section shows that the minimum half-period would be 20+19ns, so 1000/39/2 = 12.82Mhz for this section. All in all, in this diagram the control signals are the limiting factor, specifically my address decoding which is relatively slow.

[BigDumbDinosaur]

fredericsegard wrote:

2022-05-03 05_45_51-Window.png

That circuit looks suspiciously similar to the one published by Jeff two years ago.

[Dr Jefyll]

fredericsegard wrote:

I've come across this design for clock stretching that I've slightly adapted from the Plank project [...]

The Planck project is the "open hardware extensible 65C02 computer" by forumite jfoucher (Jonathan Foucher).

The hardware page on his web site includes a section explaining Clock Generation, and the clock-stretch circuit gets no attribution -- a trifling oversight perhaps. I'm certainly not the only person capable of coming up with this particular approach. And I am indirectly acknowledged in this forum post, at least.

-- Jeff

[fredericsegard]

Hi Adrien,

akohlbecker wrote:

The way to determine the maximum frequency for a component is to look at all the signals going into this chip and their timings. Let's run through a quick example. Starting from the CPU, western design center gives you timings for the address bus / read-write, which are 10 to 30ns. That means RWB is valid between 10 to 30ns after the falling edge of the clock. You then need to look at the datasheet for all the chips in your glue logic and propagate those signals until your reach your component. Let's say you go through two 74HC00 NAND gates (as a fictitious example), each take 0 to 19ns as per TI's datasheet, so that signal will reach the component between 10 and 30+19*2=68ns. Now the component will take some time to react to this. Let's say this is an AT28C256-15 EEPROM and we're talking about the Chip Enable signal. That chip takes between 0 and 150ns to react. So the data on the bus will be there between 10 and 68+150=218ns. And finally, the CPU has a setup time requirement for reads of let's say 10ns. This gives you the shortest period your clock can have, which is 218+10 = 228ns. That's 1000/218 = 4.58MHz in this fictitious example. This is only looking at a given signal of a given component. You need to repeat this exercise for all the other signals reaching this component, figuring out where in the cycle they are valid, and what impact it has on that component's output.

This makes a lot more sense to me now. By the way, I've watched your videos and I find them fascinating. I'll rewatch them with timing in mind. I'll also most likely switch from 65C02 to 65C816 in the process. If I'm to redesign, might as well "upgrade".

Merci beaucoup!

[fredericsegard]

Hi Jeff,

Dr Jefyll wrote:

The hardware page on his website includes a section explaining Clock Generation, and the clock-stretch circuit gets no attribution -- a trifling oversight perhaps. I'm certainly not the only person capable of coming up with this particular approach. And I am indirectly acknowledged in this forum post, at least.

Are you saying that clock stretching in this fashion is not the best implementation to access slower devices? Is there a better way? Or wait states would be the way to go?

Thanks,

[Dr Jefyll]

fredericsegard wrote:

Are you saying that clock stretching in this fashion is not the best implementation to access slower devices?

No. My post was simply a followup to the one that precedes it.

-- Jeff