Author Topic: DDR3 initialization sequence issue  (Read 62301 times)

0 Members and 1 Guest are viewing this topic.

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #50 on: May 30, 2021, 08:04:25 am »
That's 132ns is only valid for the 1GB DDR3.  Have you set Micron's model to 1GB, or a different ram size?  I've been using 4GB, so in my sim my controller chooses 270ns for tXPR.

IE: Line-
`define den4096Mb
or
`define den1024Mb

The other thing is your CSn output stays low.  That is a regular NOP operation.  Since you are transitioning from a CKE low to CKE high, you may need to use the 'Self refresh exit' style 'Device DESELECTED' prior to CKE going high.  This means the CSn may need to be high before CKE goes high.

Check table 70, command truth table.

Also see tCKSRX on power-up Figure 48 and Figure 94.  If needs to be 10ns or 5tCK minimum prior to CKE going from low to high.  Your CSn and the rest of the commands are already low up until the point where CKE goes from low to high instead of being high 5tCK clocks early as required by tCKSRX.

Figure 94 has a better view of tCKSRX.

 
The following users thanked this post: promach

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #51 on: May 30, 2021, 08:05:55 am »
tXPR timing violation is solved. I was using timing data for 1GB memory specification when I am simulating for 2GB memory.
Ok, well, I'll leave what I wrote above anyways as it is a good practice to get everything right in case other brands of DDR3 chips are more stringent than Micron's DDR3 model which let this one slip through as it may be allowed only during the first power-up, but not during the middle of operation.

« Last Edit: May 30, 2021, 08:18:10 am by BrianHG »
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #52 on: May 30, 2021, 09:45:49 am »
As for tCKSRX , I do not really understand why need to issue SRE and SRX self-refresh commands during initialization sequence ?

By the way, why am I having the following tMRD violation at cursor 2 location instead of at either cursor 1 or 3 location ?

 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #53 on: May 30, 2021, 04:10:05 pm »
As for tCKSRX , I do not really understand why need to issue SRE and SRX self-refresh commands during initialization sequence ?
The figure is in the power-up sequence as well as enter/exit refresh as well as reset and 'power-down' entry and exit.  So, I choose to personally obey the setup of 5 tCK and never worry about any issues.
Quote
By the way, why am I having the following tMRD violation at cursor 2 location instead of at either cursor 1 or 3 location ?
Look at figure 49.  This is what you have to make the MR#s look like where you must follow tMRD. Not what you have.  Just like the power-up sequence has cycles missing between each MR# commands replaced with the wiggly line, that wiggly line by the tCKSRX in the power-up sequence figure also illustrates some missing pattern which is visible on the power-up / power-down, DLL enable/Disable figures which should be followed.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #54 on: May 30, 2021, 04:38:31 pm »
Quote
The figure is in the power-up sequence as well as enter/exit refresh as well as reset and 'power-down' entry and exit.  So, I choose to personally obey the setup of 5 tCK and never worry about any issues.

1) Is power-up sequence == initialization sequence (Figure 48) ?
2) enter/exit refresh == Figure 94 ?    'power-down' entry and exit == Figure 95 ?    reset == Figure 106 ?


As for tMRD violation, it is solved by issuing NOP commands in between two MRS commands.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #55 on: May 30, 2021, 10:11:34 pm »
Ok, Ok, Ok,,, I can't believe I'm doing this.

Question: In the datasheet, the you have a '#' after the CS#, RAS#, CAS#, WE# and no '#' after the CKE.  What does that '#' mean?
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #56 on: May 31, 2021, 02:24:05 am »
As for Figure 48, tCKSRX is already fulfilled.
As for Figure 94, I have not implemented SRE and SRX commands yet, so not yet applicable to my coding.
As for Figure 95, I do not see tCKSRX timing though ?
As for Figure 106, it is almost similar to Figure 48 which means tCKSRX is also fulfilled.

As for # , it means active when asserted at logic low.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #57 on: May 31, 2021, 03:06:52 am »
Ok, if the # = active low, then to disable those commands, the default power-up state should be high, right?

The main problem issue you had since you just got the DDR3 model working is that when powering up and doing nothing is that you kept these active low controls low.  Why not default them high & only pulse low for the 1 clock when you need to issue a command.  By that logic, you would have save a day or two of work and you output would meet all the datasheet's requirements.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #58 on: June 01, 2021, 06:25:03 am »
Why tRP violation ?
I confirmed with datasheet for DDR3-1600-125, it is just 13.75ns which already is fulfilled by the waveform, note the time between 2 cursors

« Last Edit: June 01, 2021, 07:00:51 am by promach »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #59 on: June 01, 2021, 07:17:45 am »
tRP is the time between a PRECHARGE and an ACTIVATE.  Where is your PRECHARGE after the write.  Or, if you are using AUTO-PRECHARGE, then you need to assume where the AUTO-PRECHARGE took place and call that the beginning time for the tRP.  Remember, you are ACTIVATING a new row in BANK 0 where you came from a previous row in BANK 0.  You need to PRECHARGE the old bank first.  Without the precharge, you may activate a different BANK where you did, but if you are going this route, make sure your ram controller can keep track of which banks are each individually doing what and when as you will occasionally need different precharges at different places.

Note that in my code, I'm use 100% manual precharge with smart recognition of what banks are doing what to allow random access across banks for flexibility.  If you want raw throughput speed, but no bank management, you may per-engineer your sequence for the optimal command placement to run non-stop through all the banks and close one behind the other knowing that your reads will always be in straight line instead of the optimal read/write scatter capability in my controller which was designed to adapt to X&Y graphics burst and copy/fill commands.  (IE, The raster width address spacing Y coordinates are each on the next adjacent bank.)

Take a look at my attached image.  (See figure 90)

I have an:
ACTIVATEh'0000,B#1        0ns
WRITE BL8                     +14ns
WRITE BL8                     +8ns  (2 consecutive WRITE BL8s)
time to last written byte  +20ns
PRECHARGE B#1            +16ns   this is tWR.  (If you are using AUTO-PRECHARGE, this is where it will be, though your not sending the command, it is happening internally in the DDR3.)
ACTIVATEh'0400,B#1      +14ns  this is tRP, time between AUTO-PRECHARGE to ACTIVATE.


This is completely different than a read.  The PRECHARGE is permitted even before the read data is returned. (See figure 72)  If you go the complex route like my controller, you will need to analyze the next instruction coming in before even the current one is going out to know if the precharge is needed, or there is and access in the same row or different bank to achieve the best possible command sequence minimizing wait states.


Your sim looks like you used the read command timing with AUTO-PRECHARGE to ACTIVATE for a write command.  Also, your write command appears to have way too many cycles.
« Last Edit: June 01, 2021, 07:37:58 am by BrianHG »
 
The following users thanked this post: promach

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #60 on: June 01, 2021, 07:30:27 am »
Look at your Model output, it says the DDR3 did an auto-precharge and when.
Subtract that time from your activate command time and you get 13152ps, or 13.1ns.  That is too short.
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #61 on: June 01, 2021, 07:53:14 am »
Quote
Subtract that time from your activate command time and you get 13152ps, or 13.1ns.  That is too short.

How exactly did you subtract ?  Could you point to locations inside my waveform ?

By the way, I am using PREA command which means the DDR3 memory will precharge ALL banks
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #62 on: June 01, 2021, 08:31:08 am »
It's in your simulation transcript, see: (I'm sure you can do the math...)



Double click on each message and your cursor will go there in the waveform.


I did not see a PREA command in your waveform.  If you send a PREA, you can set it to 1 bank or all banks.


Only precharge the banks you want to precharge.  PREA-ALL is special just for when you want to issue a refresh command next as all banks need to be precharged first before a refresh.  The only other situation you may use a precharge-all is if you do not plan on having different banks active, closing and switching 1 while leaving the other ones open.  A precharge-all releases all banks.

« Last Edit: June 01, 2021, 08:34:39 am by BrianHG »
 
The following users thanked this post: promach

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #63 on: June 01, 2021, 08:47:00 am »
A complete ACT-WRITE_BL8-PRE-ACT.
I'm using manual PRE on my write command, so, my ram controller has to place the PRE command there as seen in the snapshot.

Ok, off to sleep...

Warning, do not use AUTO-PREA with the read & write commands if you intend to manually send the PREA command like I do.  If you are using the AUTO-PREA, you will still need to calculate it's hidden position to be able to tell when you can send an ACT.
« Last Edit: June 01, 2021, 08:53:29 am by BrianHG »
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #64 on: June 01, 2021, 03:49:35 pm »
Quote
If you are using the AUTO-PREA, you will still need to calculate it's hidden position to be able to tell when you can send an ACT.

Could you give some hint on calculating the hidden position ?

I have already checked tWL , tWPRE , tBURST timing parameters, what did I miss ?

 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #65 on: June 01, 2021, 08:08:56 pm »
Time to PRE after a WRITE_BL8 -> AL+CWL+4+tWR   (See figure 90)

Time from that PRE to ACT -> tRP

Remember to round 'each' time up to the nearest CK clock.

4 is for a BL8, it would be a 2 when running a BC4. (See figure 91)
« Last Edit: June 01, 2021, 11:30:12 pm by BrianHG »
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #66 on: June 02, 2021, 02:02:24 am »
Thanks for your advice in previous post.

The following waveform is a bit strange ...
By the way, why would the modelsim logs data=xxxx when there are actual dq bits ?

« Last Edit: June 02, 2021, 02:26:09 am by promach »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #67 on: June 02, 2021, 02:28:58 am »
Thanks for your advice in previous post.

The following waveform is a bit strange ...
By the way, why would the modelsim logs data=xxxx when there are actual dq bits ?
Have you assigned the DQ[x:x] output to equal anything?
Also, what is your MASK[x:x] set to.  It needs to be low to write data into the byte location, otherwise the data will not be written.

High mask = mask out data, IE, no data written for that byte position...
« Last Edit: June 02, 2021, 02:30:35 am by BrianHG »
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #68 on: June 02, 2021, 06:08:37 am »
Thanks for the advice.

Before I proceed further to determine the location for falling transition of dm mask signals, may I know why am I having alternating {3, 0} dq bits ?

« Last Edit: June 02, 2021, 06:10:47 am by promach »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #69 on: June 02, 2021, 08:01:32 am »
The DQM is in perfect synchronous timing as you write data.  Dead perfect, parallel.  It should be on the same DDR transmitter clocks.  The only difference is that you may keep those outputs enabled if you like.

When you have more than 8 bits on a DDR3, you get 2x DQM, 1 for the lower 8 bits and 1 for the upper 8 bits.

The idea is to give the ram controller a method of writing only 8 bits at a time, bytes, so that every time your CPU wants to write a byte instead of a full 16 or 32 or 64 bit word, it does not need to read the ram, modify the contents in the cpu, the write the new word back to the ram.

I think GDDR ram just has bit-for-bit data mask capabilities.  With maybe a second read port.
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #70 on: June 02, 2021, 09:20:04 am »
I was asking about the alternating {3, 0} dq bits which I also see in your modelsim waveform as well.

Let me check my memory controller verilog coding to see what is generating the repeating {3, 0} data pattern

 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #71 on: June 02, 2021, 09:41:16 am »
In my sim, the continuous alternating {3,0} IE 2bits high, 2 bits low is not the DQM, it is the DQS, the strobe which I need to send out so that the ram knows when to latch the data I send on the DQ&DQM.  That strobe is in parallel with the CK clock and also has an DQS# negative differential signal not shown in my screenshot.

The DQM I have beginning disabled at 3, then going low to 0 for 8 words, then back to 3 to disable again shows the center of the valid data capture region.  Zooming in, you will see the perfect 90 degree phase offset my DQ output has compared to the DQS output.  Just like the DDR3 best-case scenario recommendation in the data sheet.


« Last Edit: June 02, 2021, 09:44:26 am by BrianHG »
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #72 on: June 02, 2021, 12:40:06 pm »
Something is so peculiar with the alternating {3, 0} dq bits

The waveform should not have value of 0 for dq signal.

https://github.com/promach/DDR/blob/main/ddr3_memory_controller.v#L827-L828

 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #73 on: June 02, 2021, 01:27:54 pm »
I commend BrianHG's patience, and I think you are abusing it. Why don't you actually go in and read the damn datasheet, instead of asking us to do that for you over and over again? All questions you asked so far in this thread can be easily answered by reading the documentation. For example, compare how write burst is supposed to look like (from the datasheet), to what it looks like in your case, and see if you can spot any difference.

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #74 on: June 02, 2021, 01:53:55 pm »
@asmi  in the previous post, I am trying to find out why when ldq_w and udq_w are carrying value of 2, 4 or 6, dq carry a value of 0 ?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf