Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team
rpineau wrote: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.
SO... A0,SIZ1,SIZ0 == 001 is is a byte operation on the UDS. So LDS needs to be 1.
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;
rpineau wrote: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 wrote:
Ok my head hurts now.
D8-D15 are UDS. These are even addresses (believe it or not). Odd addresses are LDS.
terriblefire wrote:So if we write to an even address as a byte that means LDS should not be asserted.
terriblefire wrote:See the timing diagram on page 5-3.
http://www.nxp.com/assets/documents/dat ... 8000UM.pdf
Our logic is correct as it is.
rpineau wrote: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.
rpineau wrote: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 wrote: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 wrote:terriblefire wrote: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.
ijor wrote: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 wrote: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?
ijor wrote:terriblefire wrote: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 wrote: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 wrote:Sorry guys it was mostly for my own records i created the video.
terriblefire wrote:The only means i have to post analog traces are in video form.
Users browsing this forum: No registered users and 6 guests