REV 3 - REV 5 - The beginning (ST536)

[Badwolf]

I know I might be sitting the obvious but you do remember the ram runs at 100mhz?

Yep, not touched it.

The CPU's not still at 25, is it?

BW

[exxos]

The CPU's not still at 25, is it?

Yep... keep having problems with it resetting at 50mhz... But I dont think CPU speed makes any odds anyway.

[Badwolf]

The CPU's not still at 25, is it?

Yep... keep having problems with it resetting at 50mhz... But I dont think CPU speed makes any odds anyway.

Will the CPU be ready to read the data in time?

For argument's sake, say the DATA is presented at cycle 4. That will only be cycle 2 if it's running at half speed.

BW.

[exxos]

Will the CPU be ready to read the data in time?

For argument's sake, say the DATA is presented at cycle 4. That will only be cycle 2 if it's running at half speed.

Have no idea, it only works at all with 350ns delay on it.. I seem to have broken it even more, so falling back to yesterday's code (when I got ROM working) to try again.. Though I think I need a more friendly SDRAM controller.. but I don't have endless time to throw at this anyway :(

EDIT:

It's gone really odd, it loads up STOS, then just before the editor window the screen goes white and it just dies, locks up.. No idea what's caused that to go wonky as it'd been working fine all day.

[exxos]

I've got 50Mhz working again... Its odd as it sometimes hangs for ages before resetting .. but seems to work fine..

I've stripped out all the SDRAM stuff... If anyone knows of any plug and play modules in verilog then let me know...

[exxos]

Last night I tried various DTACK delays for TTRAM. There has to be a bus conflict with the address bus somehow, as its got random address and bus errors...

Numbers are in ns but x10 (EG 3 = 30ns).

Code: Select all

//12 bus error - address error 
//11 
//10 bus error - random errors
//9 random errors
//8 random errors
//7 random errors
//6 bus error
//5 massive errors
//4
//3 massive errors

[Badwolf]

Is your DTACK delay logic *only* applying for ST-RAM and ROM? It's imperative it doesn't interfere with AltRAM timings.

SDRAM is *not* like DRAM. It doesn't hold the data until you stop asserting CAS. The data appears two (or three, it's configurable, but at this speed it's likely two) clock cycles after CAS is asserted and then it's gone again.

The TF330 requests the same address on two concurrent clock cycles (CAS stays low for two cycles) to give you some leeway in latching the address *two clock cycles later*.

If you delay that latching, you will get gibberish. The lines will be undriven and you might get away with it some of the time, if they're slow to recover high, but fundamentally you *cannot* slow down the cycles by inserting wait states in the 030 during an SDRAM access. It's synchronous so you *have* to hit the timings.

The problems I had a lot of early on was that I'd modify the code, it'd hit the timings on some lines, but not others (I don't know, perhaps the memory address 8 line was 12ns slow, for example). It's possible something like that is happening, but if you're adding delay between when CAS gets asserted and when the CPU latches the data, it *will* fail.

Scope on CAS and STERM?

BW

[terriblefire]

Is your DTACK delay logic *only* applying for ST-RAM and ROM? It's imperative it doesn't interfere with AltRAM timings.

SDRAM is *not* like DRAM. It doesn't hold the data until you stop asserting CAS. The data appears two (or three, it's configurable, but at this speed it's likely two) clock cycles after CAS is asserted and then it's gone again.

The TF330 requests the same address on two concurrent clock cycles (CAS stays low for two cycles) to give you some leeway in latching the address *two clock cycles later*.

If you delay that latching, you will get gibberish. The lines will be undriven and you might get away with it some of the time, if they're slow to recover high, but fundamentally you *cannot* slow down the cycles by inserting wait states in the 030 during an SDRAM access. It's synchronous so you *have* to hit the timings.

The problems I had a lot of early on was that I'd modify the code, it'd hit the timings on some lines, but not others (I don't know, perhaps the memory address 8 line was 12ns slow, for example). It's possible something like that is happening, but if you're adding delay between when CAS gets asserted and when the CPU latches the data, it *will* fail.

Scope on CAS and STERM?

BW

On the TF536 DTACK/DSACK is not used for SDRAM. We use STERM and you have to use that.

[exxos]

On the TF536 DTACK/DSACK is not used for SDRAM. We use STERM and you have to use that.

Isn't that for 32bit only ? I have been trying 16bit reads and without DTACK the program just hangs.

[terriblefire]

On the TF536 DTACK/DSACK is not used for SDRAM. We use STERM and you have to use that.

Isn't that for 32bit only ? I have been trying 16bit reads and without DTACK the program just hangs.

It always reads 32bits from sdram. even when you ask for 16bits. SDRAM needs to be sync with the CPU so it uses STERM. The 030 does the byte lane sorting.

If you are involving DSACK in SDRAM reads it simply will never work and if its hanging you have a soldering issue.

EDIT: also dont screw with the SDRAM timings or you will get hangs . The SDRAM code is identical in TF330, TF536, Florica, TF360, TF1260 and TF4060. Its known good.