Open Source 68K Accelerator Project(s)

[terriblefire]

When it comes to HDL you should realise that i have implemented an entire Atari ST, BBC Micro and more recently the whole Archimedes core from scratch for the MiST board.... (https://github.com/mist-devel/mist-boar ... Archimedes) I really do know my way around synthed logic.

[terriblefire]

yes, so
RESULT <=(CONDITION THAT REDUCES TO A SINGLE BIT).
in this case CONDITION THAT REDUCES TO A SINGLE BIT is 1
so RESULT = 1;
but we want RESULT = 0 (aka LDS =0 aka /LDS pin is LO).

and yes.. people make the usual mistake you describe .. I try not to (I do both logic stuff like GAL and VHDL and C/C++ coding ... and some ASM 68k).
so my
result <= 1 when True else 0;
was to demonstrate the WRONG case
We want
result <= 0 when True else 1;
aka assert LDS when our test is TRUE, aka set LDS to 0 when our test is TRUE.

I think the root of your confusing is twofold...

Endian. UDS is when A0 = 0 since the MC68000 is big endian the most significant byte comes first.

You have the SIZ bits inverted in your head.

SIZ1 = 0, SIZ0 = 1 is a byte operation.

SO... A0,SIZ1,SIZ0 == 001 is is a byte operation on the UDS. So LDS needs to be 1.

(but it hurt my head to get that too)

[rpineau]

SO... A0,SIZ1,SIZ0 == 001 is is a byte operation on the UDS. So LDS needs to be 1.

This is a 1 byte write to an even address .. so data is on D7-D15 , not D0-D7, so in this case UDS=0, LDS=1
A0,SIZ1,SIZ0 == 101 is a byte write to an odd address, so data is on D0-D7, UDS = 1, LDS = 0

I'm not questioning you qualifications and ability, I'm mostly questioning mine.

That being said, our VHDL code does work on a STE and MegaSTE, interrupt and all ( see viewtopic.php?f=15&t=28277&p=303612#p303252 ).
So I'm trying to figure out why your Verilog code doesn't (and I don't know Verilog and I'm a VHDL beginer).
i agree that that a<= '0' when XX else '1'; get translated to logic equation and doesn't run as a "program" (aka this is not C and thus not sequential but is all happening at once);
When you synthesize, what does the generated code in ISE look like ?
Here is ours (from the generated report, -> equations) :

Code: Select all

FDCPE_LDS: FDCPE port map (LDS_I,LDS,CLK_SYS,'0',NOT ws_count(2)/ws_count(2)_RSTF__$INT);
     LDS <= ((NOT RW AND NOT sys_cycle_count)
      OR (NOT VMA.PIN AND AS_CPU)
      OR (SIZ0 AND NOT SIZ1 AND NOT A0));
     LDS <= LDS_I when LDS_OE = '1' else 'Z';
     LDS_OE <= BGACK_ST;
 

As our code is inside a process there are extra stuff but yours, once synthesis is done should look similar.

[terriblefire]

SO... A0,SIZ1,SIZ0 == 001 is is a byte operation on the UDS. So LDS needs to be 1.

This is a 1 byte write to an even address .. so data is on D7-D15 , not D0-D7, so in this case UDS=0, LDS=1
A0,SIZ1,SIZ0 == 101 is a byte write to an odd address, so data is on D0-D7, UDS = 1, LDS = 0

I'm not questioning you qualifications and ability, I'm mostly questioning mine.

That being said, our VHDL code does work on a STE and MegaSTE, interrupt and all ( see viewtopic.php?f=15&t=28277&p=303612#p303252 ).
So I'm trying to figure out why your Verilog code doesn't (and I don't know Verilog and I'm a VHDL beginer).
i agree that that a<= '0' when XX else '1'; get translated to logic equation and doesn't run as a "program" (aka this is not C and thus not sequential but is all happening at once);
When you synthesize, what does the generated code in ISE look like ?
Here is ours (from the generated report, -> equations) :

Code: Select all

FDCPE_LDS: FDCPE port map (LDS_I,LDS,CLK_SYS,'0',NOT ws_count(2)/ws_count(2)_RSTF__$INT);
     LDS <= ((NOT RW AND NOT sys_cycle_count)
      OR (NOT VMA.PIN AND AS_CPU)
      OR (SIZ0 AND NOT SIZ1 AND NOT A0));
     LDS <= LDS_I when LDS_OE = '1' else 'Z';
     LDS_OE <= BGACK_ST;
 

As our code is inside a process there are extra stuff but yours, once synthesis is done should look similar.

Ok my head hurts now.

D8-D15 are UDS. These are even addresses (believe it or not). Odd addresses are LDS.

So if we write to an even address as a byte that means LDS should not be asserted.

See the timing diagram on page 5-3.

http://www.nxp.com/assets/documents/dat ... 8000UM.pdf

Our logic is correct as it is.

[terriblefire]

I'm virtually certain that's the issue I have is physical. I was a bit rough removing the original 68k, that said it works with a straight 68k

[rpineau]

Ok my head hurts now.

D8-D15 are UDS. These are even addresses (believe it or not). Odd addresses are LDS.

yes yes .. my bad ( looks like I got myself confused a few times around there ).

So if we write to an even address as a byte that means LDS should not be asserted.

Agreed. Any read/write to an even address is UDS = 0, LDS = 1, data on D8-D15

See the timing diagram on page 5-3.

http://www.nxp.com/assets/documents/dat ... 8000UM.pdf

Our logic is correct as it is.

Yes, I'll looking at it.
Byte read (2 part after a word write )
LDS = 1, UDS =0 , data on D8-D15

But the MFP is wired to D0-D7, not D8-D15.
The MFP place the vector for the interrupt on D0-D7. So the CPU assert /LDS and leave /UDS HI to read the vector, like a byte access on an odd address.

So for a byte access on an odd adresse (to read on D0-D7), UDS = 1 and LDS = 0 (look at the write timing diagram 5-7 on page 5.6).

[ijor]

But the MFP is wired to D0-D7, not D8-D15. The MFP place the vector for the interrupt on D0-D7. So the CPU assert /LDS and leave /UDS HI to read the vector, like a byte access on an odd address.

Actually, not. Even when the vector is a just a byte, the CPU asserts both LDS and UDS. But in this case, not asserting UDS on an interrupt ack cycle should be harmless.

But what is more important, the LDS/UDS logic should check the function code and identify CPU access cycles. The address signals have a different meaning depending on the type of cycle. In the specific case of an interrupt ack cycle, the address signals don't represent an actual address. A0 is always 1.

[rpineau]

You're right, during int ack, A[3:1} represent the interrupt level.
And as A0 = 1, our VHDL code assert LDS properly and this in turn assert /DS on the MFP, but it would be more correct to detect IACK and assert both /LDS and /UDS.

[terriblefire]

You're right, during int ack, A[3:1} represent the interrupt level.
And as A0 = 1, our VHDL code assert LDS properly and this in turn assert /DS on the MFP, but it would be more correct to detect IACK and assert both /LDS and /UDS.

On my setup i am seeing at the MFP, IEI = 0, IEO=1, IACK = 0, DS = 0, CS = 1 and the address bus is $FFFFFD, FC= 0b111, IPL= 0b001. But it doesnt assert DTACK.

I can only assume the MFP doesnt have an actual interrupt pending.

[ijor]

On my setup i am seeing at the MFP, IEI = 0, IEO=1, IACK = 0, DS = 0, CS = 1 and the address bus is $FFFFFD, FC= 0b111, IPL= 0b001. But it doesnt assert DTACK.

I can only assume the MFP doesnt have an actual interrupt pending.

That's easy to tell. If MFP doesn't have an interrupt pending IRQ should be DEasserted. You don't provide IRQ state, but I assume it is asserted or otherwise IPL wouldn't be 6.

Can you provide a trace capture of ALL the control signals (we don't need the full address bus)? Include please both clocks (CPU and MFP). It might be an analog issue, which might not be evident at the traces.

[terriblefire]

On my setup i am seeing at the MFP, IEI = 0, IEO=1, IACK = 0, DS = 0, CS = 1 and the address bus is $FFFFFD, FC= 0b111, IPL= 0b001. But it doesnt assert DTACK.

I can only assume the MFP doesnt have an actual interrupt pending.

That's easy to tell. If MFP doesn't have an interrupt pending IRQ should be DEasserted. You don't provide IRQ state, but I assume it is asserted or otherwise IPL wouldn't be 6.

Can you provide a trace capture of ALL the control signals (we don't need the full address bus)? Include please both clocks (CPU and MFP). It might be an analog issue, which might not be evident at the traces.

[terriblefire]

Hmmm the forum lost my post...

[ijor]

Seems like a quoting problem. Your "lost" message has only a quote. Whatever was the reason, it should still be on your brain

Seriously, if I am writing a long post, I keep a local backup just in case until I can see the message was really posted on the forum.

[terriblefire]

Seems like a quoting problem. Your "lost" message has only a quote. Whatever was the reason, it should still be on your brain

Seriously, if I am writing a long post, I keep a local backup just in case until I can see the message was really posted on the forum.

Indeed i was replying during my lunch break and didnt have time to retype then.....

Basically looking for

at the CPU DSACK1/IPL[2:0]/FC[2:0]/AS/RW/BERR/SIZ[1:0]
at the MFP IACK/DTACK/DS/CS

Anything else?

I only have a 4 chan scope here and it isnt mixed mode so getting a matched up analog trace may be tricky.

[ijor]

Basically looking for

at the CPU DSACK1/IPL[2:0]/FC[2:0]/AS/RW/BERR/SIZ[1:0]
at the MFP IACK/DTACK/DS/CS
Anything else?

I would concentrate on the MFP at this time. At the very least trace ALL the MFP control signals, and just in case, probe them at the MFP pins themselves. This includes besides the one you mention, IRQ, RESET and CLK. Adding some CPU control signals as the ones you mention doesn't hurt.

I assume you verified the MFP and the motherboard in general works ok?

[terriblefire]

Basically looking for

at the CPU DSACK1/IPL[2:0]/FC[2:0]/AS/RW/BERR/SIZ[1:0]
at the MFP IACK/DTACK/DS/CS
Anything else?

I would concentrate on the MFP at this time. At the very least trace ALL the MFP control signals, and just in case, probe them at the MFP pins themselves. This includes besides the one you mention, IRQ, RESET and CLK. Adding some CPU control signals as the ones you mention doesn't hurt.

I assume you verified the MFP and the motherboard in general works ok?

Yeah it boots to the desktop with a 68K plugged in but there does exist the chance that i've bust something while removing the CPU and putting a socket in. May be a day or two before I get traces. Its a busy time of year with visitors popping in and I've handed in my notice at work to start a new company. Lots of admin going on.

[terriblefire]

I went though all the signals in a livestream video. Happy to do another one later and let you guys diagnose in real time.

[czietz]

And what are your key findings, for those who don't want to watch 70+ minutes of recorded livestream?

[ijor]

Yeah, sorry terriblefire, but it is not very convenient to watch such a long video. And can't even see the trace properly. Please post the trace if you want us to have a look.

[terriblefire]

Sorry guys it was mostly for my own records i created the video.

I found I3 is held low. I see a ripple on the DTACK at the moment the MFP should be asserting. All other signals *seem* to be as expected. I am really confused why the MFP isnt asserting DTACK. I3 is low and CS is high.

[terriblefire]

Sorry guys it was mostly for my own records i created the video.

I found I3 is held low. I see a ripple on the DTACK at the moment the MFP should be asserting. All other signals *seem* to be as expected. I am really confused why the MFP isnt asserting DTACK. I3 is low and CS is high.

I'm going to recheck this because I looked at the circuit diagram and I3 is tied high.

[ijor]

Sorry guys it was mostly for my own records i created the video.

Ok. Please post some traces when you want some help.

I3 is the Blitter interrupt. Normally unconnected and pulled up on machines without Blitter.

[terriblefire]

The only means i have to post analog traces are in video form.

[ijor]

The only means i have to post analog traces are in video form.

Post digital traces. We need to many channels for doing that with an analog trace anyway.

[czietz]

I assume you already checked that you're not actively driving DTACK high? I.e. is it only an input on your board?