exxos's DFB1 trials

[exxos]

You're using the wrong lowspeed there. Would only work with the top one, but also I don't see the difference between the two you quoted. Presumably one is meant to be with | clock_block and the other with | ~clock_block?

I tried both some reason I copied the same one twice.. will edit the post..

Certainly cannot hurt.

My head is spinning a bit from it all :stars: But I think at least in my case, as soon as CPU runs faster things start to mess up. So for whatever reason the CPU is trying to talk to some part of the FPU access to fast.

My only suggestion will probably be something like after a FPU cycle, artificially add a couple of 16MHz clock delays there before starting the next cycle. Just really guessing that maybe the FPU could be keeping data on the bus for 100ns after /AS goes high... Unlikely..but if it is simple to do then might as well try it to rule it out. Point being that datasheets can never be trusted and we cannot guarantee that these FPUs are even "in specification" to start with. They could all be factory rejects for all I know.

Anyways,If you want me to try any more jeds then shoot them over to me. I'm not at home at weekends so cannot do anything then until Monday. And I am away for two days but back on Thursday.

[Badwolf]

My only suggestion will probably be something like after a FPU cycle, artificially add a couple of 16MHz clock delays there before starting the next cycle. Just really guessing that maybe the FPU could be keeping data on the bus for 100ns after /AS goes high... Unlikely..but if it is simple to do then might as well try it to rule it out. Point being that datasheets can never be trusted and we cannot guarantee that these FPUs are even "in specification" to start with. They could all be factory rejects for all I know.

Anyways,If you want me to try any more jeds then shoot them over to me. I'm not at home at weekends so cannot do anything then until Monday. And I am away for two days but back on Thursday.

No worries. Many thanks to both you and @dml. You for the detective work that's generated new information and a partial success and Doug for the background so we know what we're poking into.

I think I can see a test case I can implement here (OPTION 1 and a 40MHz oscillator for starters) and if that works, I'll have a go with all the firmware tricks I can think of!

BW

[stephen_usher]

A quick question, is the /CS signal for the FPU clocked at the CPU speed or the FPU speed?

If the former then could this mean that the FPU doesn’t have time to respond before the /CS is disasserted?

[Badwolf]

A quick question, is the /CS signal for the FPU clocked at the CPU speed or the FPU speed?

If the former then could this mean that the FPU doesn’t have time to respond before the /CS is disasserted?

It's asynchrnous by default:

Code: Select all

wire fpu = {FC,A[19:16]} != 7'b1110010; // co-processor decode
...
assign FPUCS = fpu;

This isn't technically 100% correct as it disregards the coprocessor index bits, but since there's only one co-processor, I think it's legit.

We've tried adding in a dependency on AS too and later delaying the chip select until a (CPU) clock switch has completed, but no joy yet.

BW

[Badwolf]

Right, I've put a 36MHz Oscillator into my DFB1 and changed the FPUCLK to CLKOSC directly.

Perfect: I get an error.

IMG_5998.jpg

Something to work with. First step, I jumper OPTION2 so now I've got a CPU at 16MHz and an FPU at 36:

IMG_5999.jpg

...but error at same test...

IMG_6001.jpg

Now, previously I would have thought 'dodgy FPU, only stable at 25, not at 36', but now I think it's time to bodge some caps on the bottom.

BW

[exxos]

Right, I've put a 36MHz Oscillator into my DFB1 and changed the FPUCLK to CLKOSC directly.

Now, previously I would have thought 'dodgy FPU, only stable at 25, not at 36', but now I think it's time to bodge some caps on the bottom.

Looks like you are replicating what I see here now then basically. But I don't think the capacitors are the main cause here.

Odd that OPTION2 doesn't work for you.

[Badwolf]

Looks like you are replicating what I see here now then basically. But I don't think the capacitors are the main cause here.

Odd that OPTION2 doesn't work for you.

Yes, I was hoping OPTION2 would do the trick, exactly replicating what you're seeing, then I could do firmware magic, but I'm going to cap it up and see if that can push it back into the green.

BW

[exxos]

Yes, I was hoping OPTION2 would do the trick, exactly replicating what you're seeing, then I could do firmware magic, but I'm going to cap it up and see if that can push it back into the green.

May be purely on the basis that you used a slightly slower oscillator ?

[Badwolf]

Yes, I was hoping OPTION2 would do the trick, exactly replicating what you're seeing, then I could do firmware magic, but I'm going to cap it up and see if that can push it back into the green.

May be purely on the basis that you used a slightly slower oscillator ?

Mine works at 25, so I doubt it that's the oscillator is too slow.

Anyway, two 10uF added with a completely legit technique...

IMG_6004.jpg

Got a little bit further, but still failing:

IMG_6005.jpg

So maybe there's something in this.

BW

[exxos]

So maybe there's something in this.

Possibly yes... Like I said earlier seems to be a lot of noise on the top right VCC pin.. Maybe you could scope that ?

But it could be the capacitors are just simply too far away from the pins to be totally effective.As there needs to be All Power Pins Ideally As Well.

The only possible way would be to hack on some caps ontop of the socket with some small header pins or something and add caps like that to see if it gets the noise down etc.

I did this on the H5 for example..

Capture.PNG