DFB1r4 design discussion thread

[Badwolf]

So the red line here is my synthesised 'block' line.

The idea is when this goes low, I'll shut down AS to the board, that should cause DSP_CS to go high sooner, closer mimicking the native timing.

Screenshot 2021-10-29 at 22.38.23.png

Here's the first attempt at applying it to the output:

Screenshot 2021-10-29 at 22.43.03.png

Here we see the difference between real_AS (green) from the 030 and the AS line the board sees (white). This doesn't work, though. There's a delay between this happening and the CS line going high. Perhaps I need to wind back another half clock cycle.

The highlighted green delay between real_AS and AS that the board sees at the start is there to stop that little 'runt' DSACK activation (see earlier). Perhaps this is also a problem and should happen on a different edge, or even be removed with this DTACK fix?

There are a few next steps at least.

BW.

[Badwolf]

Nope, no joy. Adjusting the AS holdoff a little bit (switched clock edges) reduces the real_AS to AS delay, but there's still a long gap between AS asserting an DSP_CS going low. That's very odd. It's more than one cycle lost.

No combination of AS holdoff and the DSP write AS block have made any difference to it working. When I get the timing so it can read the registers, it can't write the bloody things.

I can't see what's wrong with this, bar the odd CS delay mentioned above. The bit highlighted looks completely legitimate to me!

Screenshot 2021-10-29 at 23.25.57.png

I think that's enough for today. Not sure what's left to try.

BW

[Badwolf]

Couple of things tried today.

* I've hard-wired the CPU to the motherboard clock so no CPLD skew delays: absolutely no difference at all.

* I've stopped the CPU switching to 16MHz, by blocking access to the bus control register: exactly the same at 8MHz, but in slow motion!

The two cycle delay on DSP_CS being asserted it still there. Very odd. I think that's got to be my next big line of attack, although I might try slowing down the response to DSACK first and get the one working board back out and do some measuring.

BW

[exxos]

Is it valid timing to set write before as or cs ?

[Badwolf]

Is it valid timing to set write before as or cs ?

Yeah, that's normal. It should be valid when AS goes low. I was worried about it deserting too soon, but that doesn't seem to be the problem.

BW

[Badwolf]

Well I drew enough blanks on this that I got fed up and did some software work this week.

I fell back to probing the GAL outputs and trying to mimic them in the CPLD. Sure enough, they all seem to be triggering when they ought (with the possible exception of the AS1DLY line, which I can't quite wrap my head around, but there are ways around that by slowing things down).

So back to getting the only known working board out and plugging it in (and sure enough it still works). Here's the trace.

dfb1r3_working.png

Now, this is also slower than on stock (like it's running in slow-mo), but the only other obvious difference is that AS goes low some considerable time *after* the clock does (20ns to be exact). My timings since are a lot tighter. I *think* this is caused by the clock line actually running a bit behind the Falcon clock on this board, for whatever reason.

So previously my efforts were all about trying to reduce clock skew and if anything having the CPU clock running slightly ahead of the mobo's clock such that once it's run through the CPLD lines fire at the right time (Stephen's sample, invert and delay technique). That really didn't work, but I wonder if actually intentionally delaying it would make any difference?

Anyway, we're getting very close to the last roll of the dice here. The only other thing I could think to try would be to lift the GAL's DSP_CS pin and try to supply that line myself.

BW

[exxos]

Anyway, we're getting very close to the last roll of the dice here. The only other thing I could think to try would be to lift the GAL's DSP_CS pin and try to supply that line myself.

Was thinking could you do a new GAL to get it to behave better ?

[Steve]

Yes but if he does a new GAL, that complicates making a 'stock' 'compatible' accelerator doesn't it? Of course the GAL could be included but still...

[Badwolf]

Was thinking could you do a new GAL to get it to behave better ?

It does feel like a proper Hail Mary though as I can't find anything at all wrong with what U44's doing. And it works with the first rev3 board!

It looks fine on both the scope and the logic analyser and, unless I've misunderstood the data sheet, the final communication with the DSP should be completely asynchronous anyway without any system clock dependence at all!

I wonder if the DSP itself is in some locked state, not getting properly reset or something?

BW

[Badwolf]

*Twitching*

IMG_4857.jpeg

IMG_4858.jpeg

OK, that might not look like much, and it's not 100% reliable, but that's the most I've got out of *any* card bar this one freak one that works.

This is *intentionally* giving the external CPU a delayed clock. Pretty haphazardly at the moment -- gating it through the negedge of a 50MHz oscillator, but FFS! Who'd have thought running the external CPU *behind* the mainboard was part of the answer? :roll:


EDIT: I made a mistake, it wasn't this. I checked and I'd typo'd in that logic so it certainly *wasn't* do what's above. I'm not actually sure *what* it is yet. Investigating & trying to repeat.


BW