Wolfgang,
Nothing funny in your attachments...other than no read DQS signals from SDRAM..
I agree... you probably have some assembly issue.
But not getting those read DQS signals will definately cause the 5373 some issues.
Let us know if you get it figured out. I'm sure the forum community would like to know how you debugged the problem.
Good Luck.
-JWW
Nothing funny in your attachments...other than no read DQS signals from SDRAM..
I agree... you probably have some assembly issue.
But not getting those read DQS signals will definately cause the 5373 some issues.
Let us know if you get it figured out. I'm sure the forum community would like to know how you debugged the problem.
Good Luck.
-JWW
Nigel,
Ok... Some of this seems familiar to some debug I did on a different chip/board combo several years ago... But I could use some more information to narrow down where we need to search.
Could you outline how you have the DDR controller hooked up. Even down to what you think might be the simplest concepts... We need to make sure you have everything.
At first glance, it looks like you are missing the first DQS edge coming back from the DDR memories during the read cycle. If the 5208 catches the second edge and thinks it is the first edge, you might see the shift in data pattern. I don't think you are debugging a burst problem yet, as a 32 bit read should always complete as you can't terminate a half cycle.. Meaning you will get 16bits on the rising edge and 16 bits on the falling edge. It just looks as if you are getting the later 16 bits when the controller thinks it is getting the first beat of data and the second DQS edge is latching a floating bus. Unless a burst terminate is issued to DDR memories, they will always continue driving DQS edges till the end of the burst cycle. But the Coldfire device stops looking for them after it gets the right count.. Meaning if you need 2 edges (2x16bits to get your long word) then if you miss the first and get the second and third edges, you might get what you are seeing.
One thing you can play with is a register setting called read_latency. I don't remember the actual "bit field" name off hand, but normally the spec says to set it to a 6 or 7. Try moving this value and see if your behaviour changes. This bit field allows the SDRAM controller to mask out "noisey" DQS lines when the bus is tristated between bus cycles. This keeps the controller from seeing false DQS edges. By making this number larger and smaller you can move when the 5208 starts looking for edges. It is counting in 2x clock cycles. So at 83 Mhz, it is counting 166Mhz cycles or 6ns increments (moving from a setting of 6 to 7 adds 6ns of delay before the 5208 looks for a DQS edge during a read cycle).
Sorry this is a lot of infomation.
Lastly... Drive strength is pretty simple. Use the smallest that gets the job done..
I vary my methodoloy from board to board. If I simulate a low cost PTP (point-to-point) design, then I typically try to use a low drive if one is available on the chip that I'm using. If I'm doing multiple banks (chipselects) of SDRAM, I tend to use a high drive if it is available. Remember low drive typically means slower edge rate and less EMI..
Hope this was of some help.
-JWW
Ok... Some of this seems familiar to some debug I did on a different chip/board combo several years ago... But I could use some more information to narrow down where we need to search.
Could you outline how you have the DDR controller hooked up. Even down to what you think might be the simplest concepts... We need to make sure you have everything.
At first glance, it looks like you are missing the first DQS edge coming back from the DDR memories during the read cycle. If the 5208 catches the second edge and thinks it is the first edge, you might see the shift in data pattern. I don't think you are debugging a burst problem yet, as a 32 bit read should always complete as you can't terminate a half cycle.. Meaning you will get 16bits on the rising edge and 16 bits on the falling edge. It just looks as if you are getting the later 16 bits when the controller thinks it is getting the first beat of data and the second DQS edge is latching a floating bus. Unless a burst terminate is issued to DDR memories, they will always continue driving DQS edges till the end of the burst cycle. But the Coldfire device stops looking for them after it gets the right count.. Meaning if you need 2 edges (2x16bits to get your long word) then if you miss the first and get the second and third edges, you might get what you are seeing.
One thing you can play with is a register setting called read_latency. I don't remember the actual "bit field" name off hand, but normally the spec says to set it to a 6 or 7. Try moving this value and see if your behaviour changes. This bit field allows the SDRAM controller to mask out "noisey" DQS lines when the bus is tristated between bus cycles. This keeps the controller from seeing false DQS edges. By making this number larger and smaller you can move when the 5208 starts looking for edges. It is counting in 2x clock cycles. So at 83 Mhz, it is counting 166Mhz cycles or 6ns increments (moving from a setting of 6 to 7 adds 6ns of delay before the 5208 looks for a DQS edge during a read cycle).
Sorry this is a lot of infomation.
Lastly... Drive strength is pretty simple. Use the smallest that gets the job done..
I vary my methodoloy from board to board. If I simulate a low cost PTP (point-to-point) design, then I typically try to use a low drive if one is available on the chip that I'm using. If I'm doing multiple banks (chipselects) of SDRAM, I tend to use a high drive if it is available. Remember low drive typically means slower edge rate and less EMI..
Hope this was of some help.
-JWW
Nigel,
This has that feeling like I've seen this before somewhere... But I'm still banging my head trying to remember where I've seen this.
But I did come up with a couple of comments.
1. Umm.. Probably should have done the DQS routing the other way...Meaning swamp your DQS signals. But at this time I don't think that is your problem, because the SDRAM controller drives all DQS signals during a write cycle and does byte writes using the DM signals to mask the extra byte lane. During reads, the SDRAM provides 16 bits of data on each edge...regardless... and it is 16 bit word addressed. The SDRAM controller just throws away the extra data during the read. I believe the only real reason you should flip those lines on a future design is because the byte lanes are timed to the DQS path. Meaning the SDRAM launches data on the upper order byte lane relative to UDQS. The lower byte lane relative to LDQS. Coldfire times the read of its upper byte lane to DQS3 and DATA[15:8]. So if you tied the data lines correctly DQ[15:0]=> DATA[15:0] and the DQS lines were flipped, the SDRAM would launch UDQS and the SDRAM controller would latch DATA[7:0] relative to UDQS instead of LDQS. This could affect your timing. But honestly in your system and at these speeds, that shouldn't be an issue. Your data valid window should be huge at 60mhz
But in case you ever do a high speed design, you would want to watch the DQS and byte lane alignment as the SDRAMs can have some skew between each lane.
One quick suggestion... Ignore the datasheet... Try a rd_latency of 5... Let me know if that changes the behaviour. This really feels like a missing DQS problem. Meaning if the DQS is too short or missing the controller gets the wrong count and doesn't terminate the internal bus cycle.. On some architectures, a write cycle can free this problem.
One other quick suggestion.. In your config.. What burst length are you setting the SDRAM controller to? And what burst length are you setting the SDRAM (Mode reg) to?
-JWW
This has that feeling like I've seen this before somewhere... But I'm still banging my head trying to remember where I've seen this.
But I did come up with a couple of comments.
1. Umm.. Probably should have done the DQS routing the other way...Meaning swamp your DQS signals. But at this time I don't think that is your problem, because the SDRAM controller drives all DQS signals during a write cycle and does byte writes using the DM signals to mask the extra byte lane. During reads, the SDRAM provides 16 bits of data on each edge...regardless... and it is 16 bit word addressed. The SDRAM controller just throws away the extra data during the read. I believe the only real reason you should flip those lines on a future design is because the byte lanes are timed to the DQS path. Meaning the SDRAM launches data on the upper order byte lane relative to UDQS. The lower byte lane relative to LDQS. Coldfire times the read of its upper byte lane to DQS3 and DATA[15:8]. So if you tied the data lines correctly DQ[15:0]=> DATA[15:0] and the DQS lines were flipped, the SDRAM would launch UDQS and the SDRAM controller would latch DATA[7:0] relative to UDQS instead of LDQS. This could affect your timing. But honestly in your system and at these speeds, that shouldn't be an issue. Your data valid window should be huge at 60mhz
But in case you ever do a high speed design, you would want to watch the DQS and byte lane alignment as the SDRAMs can have some skew between each lane.
One quick suggestion... Ignore the datasheet...
Try a rd_latency of 5... Let me know if that changes the behaviour. This really feels like a missing DQS problem. Meaning if the DQS is too short or missing the controller gets the wrong count and doesn't terminate the internal bus cycle.. On some architectures, a write cycle can free this problem.One other quick suggestion.. In your config.. What burst length are you setting the SDRAM controller to? And what burst length are you setting the SDRAM (Mode reg) to?
-JWW
