Quote from: Wolf0 on March 22, 2017, 02:32:06 AM

Quote from: nerdralph on March 22, 2017, 12:43:29 AM

Quote from: Wolf0 on March 21, 2017, 10:22:02 PM

Sometimes loosening the timings is better, and clocking higher - specifically on Eth.

I've seen you mention loosening the CAS timings. I tried bumping up tCL by 1, but still get crashes on the K4G4 at 2100. So is it just loosening tCL that usually does the trick, or something else too?

You have to loosen it on the DRAM, too - you're loosening the tCL on the ASIC, but not the DRAM, throwing them off.

Interesting. So the memory controller (or driver) isn't smart enough to take tCL from SEQ_CAS_TIMING and use same value for MR0 Cas Latency?
edit: I don't even understand how this would work at all. If the controller is expecting the data 22 cycles after the read, but MR0 is programmed for 21, then wouldn't that cause a 100% error rate?

Here's a quote from the datasheet:
During READ bursts, the first valid data‐out element will be available after the CAS latency (CL). The CAS
Latency is defined as CLmrs * tCK + tWCK2CKPIN + tWCK2CK + tWCK2DQO, where CLmrs is the number of
clock cycles programed in MR0, tWCK2CKPIN is the phase offset between WCK and CK at the pins when
phase aligned at phase detector, tWCK2CK is the alignment error between WCK and CK at the GDDR5
SGRAM phase detector, and tWCK2DQO is the WCK to DQ/DBI#/EDC offset as measured at the DRAM
pins