Blitter test programs?

[ijor]

These corruptions tend to fall in specific places which I'm guessing come at the end of the blitter cycle. Perhaps I'm picking up an erroneous write? Is the timing of the blitter write cycle a bit off?

1)
As I said before, Blitter doesn't follow the 68K Bus specifications very strictly. Blitter was designed to work on the ST, not on every 68K compliant platform. Or at the very least, surely that's how it was developed and tested. And there are also minor variations among the different Blitter revisions.

Blitter just works writing to standard RAM on the ST. You need to design your timing taking this in consideration. Forget about the 68K bus protocol for this purpose. Concentrate in the ST internal timing.

2)
Timing analysis ... timing analysis ... timing analysis ...
You have to perform a comprehensive timing analysis. Problem this is going to be tricky here because you are not fully synchronous to the chipset, yet the chipset is writing to synchronous ram. You probably can't do this analysis with Xilinx ise.

Draw a waveform including the main signals, or may be perform a simulation to produce the waveform. Then perform the timing analysis manually for the best and worst case. Considering how you are aligning the clocks, it might be better to first perform a timing analysis for the clock skew. It's crucial to find out which are the best and worst case for the clock skew.

Did I said before that I don't think it's a good idea to work asynchronously with the chipset? Probably not your problem here. But I just can't help and repeat myself :)

[Badwolf]

This is what I mean about the effect of a tiny delay to starting the SDRAM access cycle:

With the original:

Code: Select all

always @(posedge CLK) begin
	ACTIVE <= AS | ( UDS & LDS ); // when I use UDS_IN here, blitter artefacting gets worse. Interesting.
	UDS_IN <= UDS;
	LDS_IN <= LDS;
	RW_IN <= RW;
end

(ACTIVE is the starting pistol for the SDRAM state machine to advance & the signal for it to stop holding the output.)

IMG_8019.jpeg

Hard to see, but there's a couple of issues in the first 'gh' column.


Then if I use the 'sampled' internal versions of UDS/LDS which has the effect of delaying things by 15ns:-

Code: Select all

always @(posedge CLK) begin
	ACTIVE <= AS | ( UDS_IN & LDS_IN );
	UDS_IN <= UDS;
	LDS_IN <= LDS;
	RW_IN <= RW;
end

I get far more errors (but you'll note the 'main' issue column is the same -- suggests something to do with the start or end of the bus arb section to me):

IMG_8018.jpeg

To me this hints a the problem, but I've not been able to take that hint yet. :)

BW

[stephen_usher]

It also seems to be starting to affect the last 01 column, unless that's a bit of mouse cursor left behind.

[stephen_usher]

Just out of interest, in case it's a delay in the chip sampling... What happens if you swap from the positive edge of the clock to the negative edge, changing the timing by 125nS. Probably breaks everything but what harm is there in trying?

[Badwolf]

As I said before, Blitter doesn't follow the 68K Bus specifications very strictly. Blitter was designed to work on the ST, not on every 68K compliant platform. Or at the very least, surely that's how it was developed and tested. And there are also minor variations among the different Blitter revisions.

Blitter just works writing to standard RAM on the ST. You need to design your timing taking this in consideration. Forget about the 68K bus protocol for this purpose. Concentrate in the ST internal timing.

I'll have to try to set up a test case where I can measure the blitter write timings in that case. I've designed the state machine to basically latch at the first opportunity after a DS assertion but I can't seem to make any impact by fiddling with the timing there.

...and it's also right more times than it's not. Which I thought meant I'm chasing an edge case. Hard to probe, hence hoping the timing was public knowledge.

Timing analysis ... timing analysis ... timing analysis ...
You have to perform a comprehensive timing analysis. Problem this is going to be tricky here because you are not fully synchronous to the chipset, yet the chipset is writing to synchronous ram. You probably can't do this analysis with Xilinx ise.

Draw a waveform including the main signals, or may be perform a simulation to produce the waveform. Then perform the timing analysis manually for the best and worst case.

I appreciate for a modern-day HDL-trained electronics engineer, this may be blindingly obvious, but whilst I can draw the qualitative relative offsets of the waveforms I control, I wouldn't know how to establish (or estimate) the sub-clock-freq timing offsets brought about by the equations applied.

OTOH if you just mean given my clock of X and my dependance on sampling of Y then my progress through the state machine (clocked at X) with possibly a Z delay for refreshes what's the min and max of the CMD_WRITE from assertion of *DS -- well that I can probably work out.

But you see -- I'm not even sure what you mean. :)

Considering how you are aligning the clocks, it might be better to first perform a timing analysis for the clock skew. It's crucial to find out which are the best and worst case for the clock skew.

That's a fair point. This is quite a new approach for me and I don't have the 10ns resolution of Stephen's original.

There will be extremes (or glitches) and then resets (beating in effect) every microsecond or so.

I could almost convince myself that's a relevant number, but then I wouldn't expect it to be so repeatable on a screen blit and the SDRAM controller is actually working on an unrelated clock to the blitter.

Did I said before that I don't think it's a good idea to work asynchronously with the chipset? Probably not your problem here. But I just can't help and repeat myself :)

I'm afraid I don't think I can make the SDRAM controller more synchronous other than with a PLL or similar clock-multiplier. Unless I'm missing something? In terms of the design I've tried to associate as much as possible with a clock edge since the previous redesign (hence this is the nouveau controller. :) )

Cheers, though.

BW

[Badwolf]

Just out of interest, in case it's a delay in the chip sampling... What happens if you swap from the positive edge of the clock to the negative edge, changing the timing by 125nS. Probably breaks everything but what harm is there in trying?

I don't think I have any 8MHz system clock dependency in there. That clock edge is the 66MHz one. But sure, no harm in trying it.
...
No obvious difference, but that's a shift of only 15ns.

It also seems to be starting to affect the last 01 column, unless that's a bit of mouse cursor left behind.

Yes, not sure about that one, but there are a few columns affected. I had assumed the offsets were related to the 63(?) cycle arbitration breaks in blit mode but some do seem stronger than others.

In fact you've given me an idea -- if I blit the screen back to alt-ram each time it builds up a pattern...

IMG_8020.jpeg

Now, THAT is interesting.

BW

[exxos]

Reseat the blitter :P

[Badwolf]

Reseat the blitter :P

:smackbum:

And grr. My debug board insert is enough to crash blitter access before I've even wired up the logic probe.

(figured I'd work on the practical side of things while I've got the board in front of me. Maths feels like a lunchtime activity...)

BW

[ijor]

I'll have to try to set up a test case where I can measure the blitter write timings in that case.

That's not what I meant. Measure write timing can of course be useful. But what I meant is that you should analyze the ST timing. More precisely what timing the ST requires for writing to RAM. This is "your" timing.

If you measure Blitter you would be measuring your specific case, including specific for your motherboard and Blitter version. if you analyze the timing, you should come with estimated requirements that would apply in every case.

I've designed the state machine to basically latch at the first opportunity after a DS assertion but I can't seem to make any impact by fiddling with the timing there.

Latching data right after DS assertion (S4) could be too soon. Again, you are relying on the Blitter behaving like a 68K CPU that drives the data bus at S3. But the Blitter might not. And it might not because ST RAM doesn't require the data so early.

...and it's also right more times than it's not. Which I thought meant I'm chasing an edge case.

That's the typical case of timing issues. Rarely a timing issue produces a total failure. This doesn't proof that your problem is timing, but it makes it likely.

... suggests something to do with the start or end of the bus arb section to me):

It is possible that it is related to the bus arbitration, but not necessarily. Initially I assumed it might had to do with hold time. But now I suspect more that the main issue is what I mentioned above, that you are latching too soon. Blitter's internal timing is slightly different at the last (and first) words.

I appreciate for a modern-day HDL-trained electronics engineer, this may be blindingly obvious, but whilst I can draw the qualitative relative offsets of the waveforms I control, I wouldn't know how to establish (or estimate) the sub-clock-freq timing offsets brought about by the equations applied.

It isn't really obvious, certainly not in this case that the relation between both clocks is not fully synchronous. But it isn't rocket science either. You just add all the delays that are involved since a signal is launched until it arrives at its destination. Then when you get your best and worst case arrival time, you check if it meets the expected hold and setup requirements.

Considering how you are aligning the clocks, it might be better to first perform a timing analysis for the clock skew. It's crucial to find out which are the best and worst case for the clock skew.

That's a fair point. This is quite a new approach for me and I don't have the 10ns resolution of Stephen's original.

Well, again, I think that's crucial information. And again, measuring is not the right approach, at least not measuring alone, because measuring applies to your specific case. You need something theoretic that would apply to everybody.

Did I said before that I don't think it's a good idea to work asynchronously with the chipset? Probably not your problem here. But I just can't help and repeat myself :)

I'm afraid I don't think I can make the SDRAM controller more synchronous other than with a PLL or similar clock-multiplier. Unless I'm missing something? In terms of the design I've tried to associate as much as possible with a clock edge since the previous redesign (hence this is the nouveau controller. :) )

This was just a passing comment to remind you (and everybody) that even when the 68K itself might be designed for asynchronous interface, the ST chipset is not (and in your case the SDRAM either). Again, it was just a passing comment. It is unlikely that this is your problem, at least for this specific Blitter case. But it does complicates the timing analysis.

[Badwolf]

That's not what I meant. Measure write timing can of course be useful. But what I meant is that you should analyze the ST timing. More precisely what timing the ST requires for writing to RAM. This is "your" timing.

Oh, I see what you mean. Yes, that makes sense: probe the actual DRAM write cycle timings.

... suggests something to do with the start or end of the bus arb section to me):

It is possible that it is related to the bus arbitration, but not necessarily. Initially I assumed it might had to do with hold time. But now I suspect more that the main issue is what I mentioned above, that you are latching too soon. Blitter's internal timing is slightly different at the last (and first) words.

Oh, that's interesting. Thanks. I'll try to look at start, end and middle cases, then.

It isn't really obvious, certainly not in this case that the relation between both clocks is not fully synchronous. But it isn't rocket science either. You just add all the delays that are involved since a signal is launched until it arrives at its destination. Then when you get your best and worst case arrival time, you check if it meets the expected hold and setup requirements.

It's hard to explain what I mean when I still don't know what I don't know. IYSWIM.

I may be able to follow the logical steps between various things happening and the resultant output, but I'd not know how to estimate the logic delay for each of them (I don't know if it's safe to just say '20ns!' for each internal logic step [it's a 10ns chip, but what if the signal has to cross function blocks -- I don't even know how to tell]).

I'm also not sure what I'm measuring from yet. Like you say, my initial assumption that DS meant data would be ready by the time by (slow) state machine got there doesn't look to be valid for the blitter.

Anyway, it seems to me I've got to understand what I'm aiming at before I can work out if I'm hitting it yet.

That's a fair point. This is quite a new approach for me and I don't have the 10ns resolution of Stephen's original.

Well, again, I think that's crucial information. And again, measuring is not the right approach, at least not measuring alone, because measuring applies to your specific case. You need something theoretic that would apply to everybody.

They are, of course, separate things -- there is (currently) no 8MHz clock dependency on the SDRAM controller which is trying to emulate a (slow) SRAM interface -- but yes I was nervious about the jitter associated with this technique, but then consoled myself with it working quite extensively on the early TF boards*, albeit with a 5ns better resolution.

But there's no doubt this is still a little experimental in my mind. If everything were perfect you'd expect the skew to vary from around +8 to -8ns. But across different CPLDs, with different initial clock phases, or as things heat up I could imagine that shifting to being non-symmetrical quite easily.

Still, many thanks for your help, Ijor. I've certainly got some things to work on.

(I wasn't planning to support blitter access to SDRAM, but got on a roll and chucked my hat into the ring -- I knew it'd be a mistake!)

BW


* TF may have implemented a better algorithm in the 536 boards -- they're not open source.