CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

[exxos]

This uses 32Mhz as reference machine, and then 38Mhz system.




Tests were faster once 40Mhz was reached, but was to unstable to run proper tests.

[exxos]

I did some testings with adding /DTACK into the switching code (was actually on the STE but relevant here). The problem is with DTACK, is that for ROM access for example, the GLUE doesn't release DTACK until a few nanoseconds before address strobe goes low again on the next cycle, basically around S2. The problem here is, the CPU is running at high speeds, it can reread DTACK from the previous cycle and obviously cause a crash.

So I did a quick test and added DTACK into my speed switching code to see exactly what happens in waiting for DTACK to go high before allowing 32 MHz speeds..

I got 266% on ROM speed (should be 309%)

I added 1K pull up on DTACK, then got around 295% (give or take 5%) .. Still a fraction slow.. but only a few %...

So GLUE is what has DTACK almost low all the time... and main cause of crappy DTACK generation.

There could be something else with slow DTACK release which could account for a few % drop in speed somewhere.. but no idea what. It does seem a little odd that speed seems to vary now, it is like DTACK is not arriving at a constant speed causing around 5-10% variation in ROM access.. So this would be difficult to determine.

But really, in the case of the STFM, ROM decoding is done on the booster board anyway. So this rules out likely issues with DTACK. On the STE however, I use the GLUE logic for the decoding as it is fast enough for 32 MHz. Though it is likely this logic will have to be bypassed in order to create a proper DTACK signal.

But in any case, when thinking towards the 64 MHz, the DTACK issue could be a problem, but the least I have a easy solution for this and it is fixable at least :) it is possible slowdown with this new code, could be compensated by the faster CPU anyway.. In that the CPU will start cycles twice as fast, and compensate the slowdown with using DTACK which delays a clock cycle.

Worst case currently is that a few percent is lost, but overall again should be higher with 64Mhz anyway, so it does not really matter much.

[exxos]

As a update, I did a whole bunch of tests.. Long story short, changing to 500R resistor on DTACK made a whole world of difference..

dt11.png

On the left, is 1K resistor... On the right is 500R resistor.. Not a great deal between the two, but makes a dramatic difference in results..

Basically now, worst case looks like about 1% variation in results. But this is about as good as things get anyway.

I really don't know why DTACK is such a "heavy" signal to pull-up :roll: I did a quick measurement of capacitance and read 250pF.. They may not be accurate due to the pull-up resistance being in the mix also.. But with a lot of gates to pull-up on chips, it probably isn't far off...

I did a close-up also..

dtz.png

I also did a quick simulation..

sct.JPG

res1.JPG

So on my actual scope results I see that around 50% through the cycle (about 150ns) in must reach about 4 V.

On my simulation circuit, I see 4V around 200ns.

Of course there will be a lot of factors and this was only quick test, but it seems that the capacitance is indeed around 250pF. Which does not seem much, but it is clear you can take 200ns to get to 4volts. If we assume 2 volts as a logic one, then the time will be closer to 100ns.

500R on 5V is 5V / 500 = 0.010Amps (10mA) which is a lot really, I quickly checked the MFP datasheet and it quotes 5.3mA.. So likely in reality a 1K resistor should be the lowest value used about starting to strain the DTACK drive transistors.

A possible workaround could be control the 500R resistor by the PLD. In that when address strobe goes high, it connects the 500R resistor to DTACK and allows resistance to be pulled up faster. Then when address strobe goes low, the resistor is isolated so the actual DTACK resistance would be normal like 2.2K. This way DTACK switches to 0V with 2.2K as normal, and is pulled up high with 500R...

[exxos]

Tried the PLL finally.. Wired it for x2, so 8MHz input, 16 MHz output...

Just seem to get varying speed for some reason :roll:

pllmess.png

pll2.png

[exxos]

OK, so small update.. I switched to x10 on my scope probes and it is now stable at 16mhz.. BUT..

What I did not realise before, is on the STE...The 32mhz goes to 16mhz and is in sync perfectly.. but whatever is clocking down the 16mhz to 8mhz has a 16ns delay.. so its not in sync..So the PLL starts out 16ns out of sync... So the PLL 16mhz and ST 16mhz are also 16ns out of sync.

This means the STE screws up on floppy access, which it doesn't do when using the 16mhz ST clock.. but the PLL clock is 32ns "behind" the 8mhz and its to much and it screws up.

I could probably do some work arounds on the on a larger PLD based design, but not on the simple STE booster..But, this shouldn't be a problem on the STFM as the clocks are all perfectly in sync..

So I will try and find some time tomorrow to try the PLL on a STFM booster. The STFM is the one which a problematic 32mhz circuit.. so I am not to bothered about the STE issues with it.

[exxos]

Right, working now :) I used the 16mhz input and x2 PLL for 32mhz output (to "bypass" the 16ns 8mhz skew issue)

Turns out the ST clocks are in sync on the falling edges of the clocks, and the PLL is syncing on the rising edges...


ST CLOCK 16 & 32

1632st.png

PLL 32 & ST 16

1632.png

So I fiddled with the GAL code to invert the 32mhz input and now everything is happy again :)

Oddly I have some "bug" now which has resulted in a few % extra in speed :lol:

bug.jpg

EDIT:

Oddly now and then it crashed, so I took the scope probes off the ST 16MHz line and all was fine, but the speed went back to normal again.. put the scope probe back and higher speeds again.. odd..

EDIT2:
OK, seems the PLL latches onto 32.89mhz sometimes, other times 32.25mhz... now I want to try x3 on the PLL but not going to be easy to re-wire it as I intended to basse on 8mhz not 32mhz :roll:

[exxos]

1.jpg

Add a little fun earlier.. I took my RSO which I design for the CT60 while ago.. The clock multiplier is way too high for this test, so just a matter of lifting up a pin on the chip to half the output frequency from 100mhz to 50mhz kinda thing. Pin was tiny and ended up snapping off, but thankfully this pin needed to be floating anyway so it didn't matter :lol:

I tried various methods of getting more speed, but I did not break the speed barrier of what I got before of around 38Mhz. I really did not expect it to go any faster. I was just doublechecking that the CPU was maxing out at this frequency.

I still need to finish off the SEC PCB design yet :( but I got a little sidetracked in testing the PLL out before I added it to the PCB layout.. Hopefully I can find time tomorrow to try out the PLL on the STFM make sure I am happy with it before continuing with the SEC design..

[exxos]

I've gone back to the V2.2 booster for PLL testing.. So far passing though the PLL (driven from 8mhz) results in 16mhz output inverted :roll:

So I can the 8MHz though a inverter before the PLL.. but oddly both 16MHz were still out of sync (180deg out of phase).


(ignore the ringing)

p1.png

So I tried inverting the 16MHz output from the PLL and saw 15ns skew..

p2.png

5ns measured is delay though the GAL, so there is 10ns delay though the PLL it seems..

Sometimes it boots and even loads GB6 but it is just to stable.. I think one of the problems is the PLL needs a very clean input and the 8 MHz from the MMU just doesn't cut it. Even with adding resistors and a few picofarads capacitance here and there I think it is time just to redesign a new PLL board.

Basically to take the 8 MHz through a schmitt trigger buffer to clean up the input to the PLL. I think inverting the 8 MHz is to be a lot worse than inverting the 16MHz... With two buffers on the input and output the delay should still end up being around 5ns.. So basically I need to add something like 20ns delay to bring the clocks back into sync again.

This seems a lot of work which is really what I was trying to avoid in using a PLL in the first place.. But if these things are super sensitive to noise, and the ST motherboard basically being one huge noise generating monster, it is not going to take much for the PLL to become unstable even if it is just for one clock cycle..

The problem here is that this particular PLL seems to just constantly depending on what the frequency is.. To me this totally defeats the object of having a PLL.. The idea is to lock onto the frequency and stay that frequency even if the clock input source is removed.. But this IC does not do this :roll:

Overall I am thinking just replacing the 32MHZ circuit in the STFM may ultimately be easier and more reliable..

Here is the datasheet..

https://www.idt.com/document/dst/570-datasheet

If anyone can find a similar chip which actually locks onto the frequency stays on that frequency when the source clock is removed then it will save me some time.. If it looks like it may work then a build up a small board and test it out. Of course the problem with a lot of these chips is they do not state the propagation delay time... This particular PLL would be ideal I think if it would actually latch onto the frequency stop at that frequency once it has been locked onto. I'm sure older PLL devices did that.. ??

[rpineau]

On the new 68020 V3 board we use a clock distribution chip, the NB3N551.
This might help cleanup the clock and then feed it to your PLL ?

[exxos]

On the new 68020 V3 board we use a clock distribution chip, the NB3N551.
This might help cleanup the clock and then feed it to your PLL ?

Possible, though looking for schmitt inputs to be sure, probably 8 inverters.. 2 on input (act as delay buffer) and 3 on output for inversion + delay.. But I think this is getting over complicated just to generate a x2 or x4 clock source.

So far I just used 32mhz osc and used PLD for buffering and feed that into shifter... like the MEGA ST does.. more work to install though.. Neither solution really seems a good one.

I know the STE booster logic can work with seperate clock.. I will investigate if the STFM can operate the same.. It may be better to spend time on using a 32mhz osc but still 8/32 switching, but not in sync with system clock. It works fine on STE.. So maybe with some tweaking it can work well on the STFM as well. This way machine can run as stock 8mhz, but CPU gets speed boost on async clock.