DFB1r4 design discussion thread

[exxos]

I only looked at U44 as it had CS on it. But I don't see how all the delays add up, as when AS goes high, the address bus will all be pulled high, so U44 wouldn't have a valid address so CS would go high as well. Depending on the speed of thee GAL that should happen within like 25ns.

The only way I can see U44 taking 100+ ns to set CS high, aside from some other pin on U44 screwing it up, is the adress bus is taking to long to all go high. But then we back to bus pullups again

But can you monitor a couple address line on U44 with CS and AS to at least prove the address isn't "hanging around" for some time keeping CS low for longer than it should ..

[Badwolf]

The only way I can see U44 taking 100+ ns to set CS high, aside from some other pin on U44 screwing it up, is the adress bus is taking to long to all go high. But then we back to bus pullups again

I think you've misunderstood something. There's no 100ns delay.

A 10ns delay on CS compared to stock is enough for it to fail.

BW

[exxos]

You mention 125ns delay here https://www.exxosforum.co.uk/forum/viewt ... 150#p73224

[Badwolf]

You mention 125ns delay here https://www.exxosforum.co.uk/forum/viewt ... 150#p73224

Ah, right. That's a completely different test case.

That's a delay in assertion caused by round-trip logic propagation meaning it misses a clock cycle. It's only a 62ns delay -- compare it to the first trace here (https://www.exxosforum.co.uk/forum/viewt ... 140#p73085), which is the same test on stock.

The delay I've identified as causing trouble is the deassertion of CS (DSP latches on LO-HI CS transition). The experiment I rigged simply deasserts on the next positive clock edge after assertion, but in reality I don't have access to that line.

How to stimulate that behaviour with only the lines I have available is the next task.

I think something like: if AS and DSP then on negedge of XDTACK assert DSACK0 and deassert XAS. Reset on AS goes high.

Which will probably not now fit in the CPLD!

BW

[Badwolf]

I think something like: if AS and DSP then on negedge of XDTACK assert DSACK0 and deassert XAS. Reset on AS goes high.

So close, but no cigar.

With one amendment to the above (which is I only do the short termination on writes), DMA2DSP runs happily for quite some time (I've had it going for 20 minutes without a red line so far), but alas, FRAC.DSP, my go-to hard nut program, only works intermittently. It's gets a quarter, sometimes half through.

This is *almost* ok, now, but there must be something not quite right with the timing still. I'm getting sorely tempted to just do a bloody daughterboard for the GAL and control that chip select myself!

Thinking cap back on.

BW

[Badwolf]

The only way I can see U44 taking 100+ ns to set CS high, aside from some other pin on U44 screwing it up, is the adress bus is taking to long to all go high. But then we back to bus pullups again

I was thinking to try to build some pullup 'hats' for my card over the weekend.

Am I right in thinking it's both (address and data) busses that benefit, or should it just be data?

All the lines currently have 10k on them, so I was thinking to add 3.3k to each line to bring the total down to 2.4k. Reasonable?

Cheers,

BW.

[exxos]

I was thinking to try to build some pullup 'hats' for my card over the weekend.

It's worth trying. Only takes one bit or ringing or noise in one line at the wrong time and all goes to hell. As to if it will help with your problem or not is anyone's guess..

Am I right in thinking it's both (address and data) busses that benefit, or should it just be data?

Do both and have done with it.

All the lines currently have 10k on them, so I was thinking to add 3.3k to each line to bring the total down to 2.4k. Reasonable?

Possibly, though it's something I never tried on a Falcon. Maybe aim for about 3.3K - 4.7K. There becomes a point where things will get worse. On a ST it's around 1K, but that's getting a bit *too* low anyway.

[Badwolf]

Its worth trying. Only takes one bit or ringing or noise in one line at the wrong time and all goes to hell. As to if it will help with your problem or not is anyone's guess..

Yep, but (hopefully!) can't hurt.

It's *so* close to working now. I was getting a fail on the DSP program probably one time in 20 with the current set of hacks, so I'm looking for that final piece of the jigsaw. That said I thought I'd nailed it before and then the next moring it was gone again.

Am I right in thinking it's both (address and data) busses that benefit, or should it just be data?

Do both and have done with it.

Yeah, fair enough. The upper address lines are occupied ATM, so that requires a bit more work is all.

All the lines currently have 10k on them, so I was thinking to add 3.3k to each line to bring the total down to 2.4k. Reasonable?

Possibly, though its something I never tried on a Falcon. Maybe aim for about 3.3K - 4.7K. There becomes a point where things will get worse. On a ST its around 1K, but thats getting a bit *to* low anyway.

Adding 6.8k would give about 4k in total. I'll give that a crack, then.

Cheers,

BW.

[Badwolf]

Haha. Well f**k it!

Just spent the evening fine-tuning some pure DSACK0 simulation logic, as this seemed to be far more stable than responding to the GALs. Finally passed all my tests. Was working great. Super!

Put in a different crystal to test the reset problem...

...aaaand the DSP fails at first test.

There's not even an oscillator dependency in the bloody logic I'm testing!

Anyway, I've ordered some new veroboard to let me go to go to town on the pull-ups & and investigate bypassing the GAL for DSP access.

Enough for now!

BW.

[Badwolf]

So it ain't pretty, but I've added 6k8 pull ups to all the motherboard data lines to bring the whole pull-up resistance down to about 4k.

IMG_4870.jpeg (229.08 KiB) Viewed 2486 times

Also, I found a 5k pull-up on the reset line solved that oscillating reset problem at 50MHz.

The system as a whole is now running very nicely. Touch wood, I haven't seen any memory issues yet.

However it's not helped with the DSP at all. I haven't faced doing the same sticky-out resistor trick on the 22 address lines yet, but I ought to do that for completeness.

The DSP just seems so temperamental. Going back to the 40MHz oscillator didn't restore functionality either. It's very strange indeed.


Steve mentioned the additional DMA clock pull-down -- I'm not sure there's any cross pollination with the tests I'm doing, but it perhaps would be worth looking at anyway.

BW