Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Writing to SDR SDRAM through Synposys designware mem controller

hi,

When I am writing to sdram through synopsys designware memory controller the address is not being

properly latched by the SDRAM. Like, if I give address as 0x0018 it will write to

0x0010(one of the address lines is not properly latched). I checked the data sheet

of the SDRAM (Micron 48LC32M16A2) and the setup time is given as 2.8 ns.But, I am giving

the same clock which I gave to the memory controller. Have anybody used synopsys Designware

memory controller to write to SDRAM. If yes, is it the same clock that we give to

both the memory controller and SDRAM or shall the clock to SDRAM to be delayed by

some time from the clock given to memory controller.

Thanks,

gangi.

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Did you define the timing constraints for Timequest on your memory interface, and does the system meet the timing requirements?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    hi,

    yeah, there are timing constraints and the timing constraints are met for all the signals. Except that the clock to sdram (generated in the design) has no timing constraint as the input clock does not clock data to this port.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I'm not sure I understand your last sentence. You don't need to put any constraints on the clock to the sdram, but you must be sure that all the constraints on the other signals to the memory are defined relative to the pin output that gives the clock to the sdram.

    AFAIK you only need to delay the clock to the SDRAM if the Timequest report tells you that the timing requirements aren't met, and you must adjust the delay until they are.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Actually, we cannot give the timing constraints with respect to the clock going out of design. Here in this case clock to sdram is sent from the design so I gave the constraint with respect to the clock whch is used to run the entire design. So, how can i verify the timing constraints of the sdram if i dont know how much the control signal transitions are delayed from the SDRAM clock. Both the input and SDRAM clock are synchronous and are same but after generation of SDRAM clock in the design to the PAD of the fpga the delay might be such that some of the address lines meet the setup and hold time requirements (i.e., they arrive 3ns before the SDRAM clock ) and some of the address lines arrive after the SDRAM clock. Is this point which I am making valid?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Ok, in that case you can define all your timing constraints relative to the clock input and Timequest should say if they can be met. How did you define your constraints? Did you use this guide (http://www.alteraforum.com/forum/showthread.php?t=1269) ?

    If you think there could be a delay between the clock seen from the RAM and the one seen from the FPGA, you can create a virtual clock in your SDC file, that is derived from the clock input on the FPGA, but with a delay to represent the clock on the RAM. And then do all your constraints relative to that virtual clock.