REV 3 - REV 5 - The beginning (ST536)

[exxos]

Code: Select all

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

The above code seems to make it work in fact...


EDIT:

Oddly seems to have gone back to the original speed, though it is not just simply down to the single clock delay as I need 2 clock delays from the CPU (50MHz) to be stable otherwise...

IMG_6373.JPG

[terriblefire]

I mean there is nothing wrong with this but to me its like wearing trousers on inside out...

Code: Select all

 ~&D[31:31];
 

[Badwolf]

I mean there is nothing wrong with this but to me its like wearing trousers on inside out...

Code: Select all

 ~&D[31:31];
 

Yer, I was going to flag it's changed from the immediately preceding message too:

Code: Select all

~&D[31:16];

BW

[exxos]

Code: Select all

~&D[31];

Works as well :hide:

[terriblefire]

I'm a bit confused why the state of data on the data bus indicates bus free though?

[Badwolf]

Idea being that ram_delay3 will hold off ram_access until the bus is all high.. then its allowed to run.. but it then has to remain in that state until the cycle is completed..

Obviously AS30 will set the FF to high when AS30 = 1.. When CPU accesses the bus the FF is allowed to run, and will latch BUS_FREE when its sees all datalines high..

Code: Select all

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

I can't see how this does what you're describing. To me it looks like ram_delay3 is held at 1 whenever the bus is inactive. Fine.

But when the bus *is* active, ram_delay3 would seem to me to reflect whatever BUS_FREE was at the last positive 100MHz clock edge. Which doesn't seem like a latch.

I'd have probably tried something like:

Code: Select all

FDCP ff_dtack3r( .D(  1'b0 ), .C( ~(AS30|BUS_FREE) ), .PRE( AS30 ), .CLR( 1'b0 ), .Q( ram_delay3 ) );

So ram_delay is held high whenever AS30 is high, otherwise it goes low on the falling edge of (AS30|BUS_FREE) and stays there until AS30 goes high and resets it.

Hmm... I suppose, actually, the AS30 dependency in the clock is irrelevant as the clock only matters when AS30 is low already.

So a further simplified version might be:

Code: Select all

FDCP ff_dtack3r( .D(  1'b0 ), .C( ~BUS_FREE ), .PRE( AS30 ), .CLR( 1'b0 ), .Q( ram_delay3 ) );

What do you think?

BW

[Badwolf]

Code: Select all

~&D[31];

Works as well :hide:

As would just

Code: Select all

~D[31];

But I'm 100% confident it's not doing what you want. This would be true about half the time anyway!

BW

[Badwolf]

I'm a bit confused why the state of data on the data bus indicates bus free though?

Wot TF sed.

Surely the absence of AS30 and BGK indicates data bus free -- which is what the 030 does itself.

BW

[exxos]

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;

[exxos]

Surely the absence of AS30 and BGK indicates data bus free -- which is what the 030 does itself.

I think you guys have missed some posts... The problem is the otherwise slow bus isolators on the ST to 030 databus.. it takes about 20ns to "disable" which is corrupting the bus.. (maybe +10ns of the PLD itself, not 100% sure) The CPU thinks it can start a new cycle, which ordinarily it could, but because the bus buffers have not yet disabled, they are essentially latching the previous bus cycle data on the bus..

Previously I added 2 CPU clocks (50mhz) to work around this problem which worked... But of course it inherently dropped the speed of the entire system because of the extra delays..

So then I thought, because nothing is actually accessing the bus and I am expecting nothing to be on the bus, the bus pullups will pull the databus high as nothing is driving it yet, so I am simply waiting for that to happen before I start the next cycle, which is exactly the time the bus buffers have actually isolated the bus.

It gets a little bit more complicated because the ROM itself takes about 20ns to turn off.. But as I am driving the ROM from the ST bus side, the bus isolators can combat that problem as well...