REV 3 - REV 5 - The beginning (ST536)

[Badwolf]

I have this at the moment @Badwolf

Code: Select all

assign BUS_FREE = ~&D[31];
FDCP ff_dtack3r( .D(  ram_decode ), .C( CLK100M ), .PRE( BUS_FREE ), .CLR( 1'b0 ), .Q( ram_delay3 ) );
wire ram_access = ram_decode | ram_delay3;

ram_delay3:

• If a single line (D31) is low, output is high.
• Otherwise output reflects ram_decode at the last positive 100MHz edge.

In parallel

• ram_access is low when both ram_decode and ram_delay3 are low.

So if the top bit is low, ram_access will be held until it goes high.
Once it's high you'll get a delay to ram_access of between 0 and 10ns.
If the top bit subsequently goes low during the access, ram_access will be switched high again.

Even though I don't think you want to be basing any decisions on a single pin, I think this would only work if ram_access is expecting a pulse.

BW

[exxos]

Even though I don't think you want to be basing any decisions on a single pin,

I don't.. I want the whole 32bit databus to be high ...

[exxos]

If the top bit subsequently goes low during the access, ram_access will be switched high again.

Even though I don't think you want to be basing any decisions on a single pin, I think this would only work if ram_access is expecting a pulse.

Looking at it again you could be right, it really needs a SR latch.

[Badwolf]

Taking a step back as I don't know the architecture of the 536, but making an educated case:

• Are you sure the ST bus is isolated and not just the 3V3 RAM chips?
• Does the 536 actually pull data lines high? If it doesn't and you've isolated the motherboard, nothing will be pulling them high.
• Is your theory that the ST is still driving the data lines when you want to start a bus cycle because the stock 536 is still in 8MHz mode, but you're all the time in 50?

I think, even if all the above is a 'yes', I'd be tempted to stick to using the the clock (maybe even the 8MHz line?) as there's nothing to say the ST-RAM isn't driving an FFFF anyway.

BW.

[Badwolf]

Even though I don't think you want to be basing any decisions on a single pin,

I don't.. I want the whole 32bit databus to be high ...

Code: Select all

~&D[31:0]

But that assumes there are 32 pull-ups on the 536...

BW

[Badwolf]

But that assumes there are 32 pull-ups on the 536...
BW

Actually, another question: how many data lines are actually routed to the CPLD?!

BW

[exxos]

Actually, another question: how many data lines are actually routed to the CPLD?!

ah only the 16bit ST bus, but thats the upper word of the 030.. But like you say, if something drives the bus high (really it shouldn't be) then it would break the method anyway.

[Badwolf]

Actually, another question: how many data lines are actually routed to the CPLD?!

ah only the 16bit ST bus, but thats the upper word of the 030.. But like you say, if something drives the bus high (really it shouldn't be) then it would break the method anyway.

Honestly, I'd just wait for the next 8MHz edge or something.

BW

[exxos]

I think me and these xilinx chips are going to be falling out very soon :roll:


ST DTACK Yellow
ST AS Blue

Address strobe seems to be even driven high or tri-stated in the code when something is accessing the bus..But it is oscillating like hell and the rise time is extremely slow.. But it does not do this always because the cycle before looks perfect.. I even added a extra 1K pull-up onto it and it made no difference.. In other places the oscillation seem to seriously corrupt AS .. and bizarrely this only seems to happen when the TTRAM is accessed.

IMG_6380.JPG

But more bonkers things going on, address strobe is high and DTACK is clearly pulsing when there is no possible way it could even do that.. unless I am missing something ?! there is no blitter or anything else on this machine I don't see how DTACK Is being driven. The PLD only has DTACK as an input, so I cannot see how the chip can even be driving that as a output unless the compiler is seriously screwing up somehow. I did have a span of the software ringing of a blank page for the design summary, intermittently not seeing the PLD, and after a while it would not even let me copy and paste in the thing.. I think the more you use it the more it starts screwing up.

IMG_6374.JPG

It seems the VDI locking up problem came back when I moved the ROM from the motherboard to the TF536.. and absolutely nothing else has even changed. It otherwise seems to work perfectly fine as long as the TTRAM doesn't get accessed.

[exxos]

This is another bonkers one as well..

ST_AS is not staying high, and yet it is being clocked high continuously via a 100MHz FF... How the hell can it be glitching like that :roll:

IMG_6382.JPG

EDIT:

Dropped to schematics view and that is about as minimalist design can really expect. The highlighted line on the left is basically AS30... Which outputs to AS...

Capture.PNG