Badwolf wrote: 11 Nov 2022 14:17
I think the FPU is always intended to run faster than the CPU. I experimentally decided it could run on a slower clock, but only down to about half the CPU frequency (makes sense -- if DSACK[x] is asserted too long, CPU confusion could abound).
BUT, perhaps that is
really really marginal and I've made a boo-boo there.
It does seem like the FPU need to run faster than the CPU currently.. Let me retest to make sure..
So 40MHz clock WITH OPTION2 works, without OPTION2 crashes on first test. So assume with OPTION2, the CPU is 16MHz and FPU 40MHz.
Badwolf wrote: 11 Nov 2022 14:19
Given how long it takes to switch 'down' (there's a dropped cycle in there), perhaps it's actually too slow for the FPU?
Maybe we need to delay FPUCS until the switch has definitely happened? There's a signal called 'clock_block' which is intended for this purpose, but I don't recall if it's active high or active low.
I did delay FPUCS, but that was when it started working and I took it out because it was seemingly OPTION2 which made it work.
It is rather puzzling.. If running the CPU slower works, then maybe the FPU is keeping data on the bus for a lot longer than we think? and trips up the next cycle on the CPU when running at higher speed?