Asynchronous clocks


#1

Hi, folks. Not really a TinyFPGA-specific question, so I’m putting it in General Discussion.
I’ve currently got a TinyFPGA A1 generating a VGA test pattern using the ‘correct’ pixel clock frequency (25.175MHz). I’m designing a graphics board to go on my homebrew MC68010 computer. The 68k is running at 10MHz. I’ve got a clock multiplier that can take that to 25MHz ‘exactly’. My question is…
Am I better off running my FPGA at 2.5 times the CPU clock frequency (which, by my hasty estimation, means there will be at most 4 different phase differences with the 10MHz clock when the 25MHz clock falls) or will it be OK to clock the FPGA at 25.175MHz (thus giving me an essentially random phase difference)?


#2

Perhaps a little more detail will help others understand what or where this clock async is happening and what data is passing over the async link. (Serial bit stream or parallel words?)
Also what form does the 2.5X clock multiplier take and is the 10MHz clock xtal based?
If the 10MHz is from a crystal osc then it should have low jitter.
If the 2.5X is PLL based, then it too will have very little jitter. (If the control loop is properly designed.)
If this is the case then it is all pretty much running synchronously anyway. Certainly way less of a worry than fully async data passing.
Also you could then pass the slow clock through a pair of regsisters clocked on the fast clock to detect the edge of concern (where the data changes on the slow clock) to ensure you clock into the fast system away from the data change edge.
Hope this makes sense to you. (Getting late here :slight_smile: )


#3

Hi, Glenn.
I haven’t worked out the details yet, but I’m planning to run the FPGA off the pixel clock. CPU access to the VRAM (old-style DRAM with a few extra tricks) would start when the FPGA detects that the CPU’s address strobe (~AS) has fallen. I could pass ~AS through a couple of registers. Ideally, a read cycle would complete in the minimum time (~AS low for at least 195ns). The VRAM’s ~RAS-to-data-available is <=100ns. The FPGA has to output half the VRAM address, then take its ~RAS low, then output the other half of the address, then take ~CAS low.
The 10MHz is coming from a xtal oscillator and the clock multiplier is PLL-based, if I recall correctly ( NB3N502DG?).


#4

Sorry for the slow response. Busy time here.
VRAM is normally designed as a form of Dual-Port RAM. So there are independent Addr & Data buses for the processor and video logic. The expectation is that the VRAM provides the bridge across the async timing gap. So, ideally, I think you would be aiming to use combinational logic only on the CPU side of the VRAM. Then the clocked logic providing the VRAM to dot data on the graphics side.
But if the processor does not directly support DRAM, (and it seems MC68000 does not) then you have a whole lot of logic to provide.
[Sorry, I was a Z80 guy, so DRAM interfaces came free out of the box! (Hence how ZX80 and ZX81 managed to do Video interfaces without almost any extra logic!)]
So, I fear you may have to bite the bullet and draw out your timing diagrams with best and worst-case scenarios of where this async clock could appear. I have not spent much time looking at the timing details of the FPGA, but some of the stuff I have read on here tends to point to it being a little sluggish on input to output delays, so don’t be surprised it you get caught in a tight corner.
Good Luck though!