Reference design query

Spartan-6 USB 2.0 Modules
1

Hello,
Great product!
Have a few queries:

  1. In the RAMTest design, the burst length between the user fabric and the MCB is specified as 32. There is also a burst specification between the MCB and the DDR2 (on the LX1) which can be configured during each data transfer to either 4 or 8. However the MCB datasheet (generated by ISE) shows the burst length to be fixed at 4. Please clarify.
  2. In the same design, p0_cmd_bl_0 (the wire between the ddr2_test and mcb sending the burst length) is assigned to BURST_LEN - 1 ( and not BURST_LEN). Why?
  3. In the camera_app (with the FMC daughter board), the clock module is clocks.v which uses DCM and PLL_ADV, which in my understanding are IP cores generated by ISE (hence will have *.xco files). However, in the developers release I couldn’t find them.
    May I ask how are these being generated?
    Thanks again,
2

  1. Not sure what you need clarified. There are two different burst specifications. One is for the interface to the MCB. The other is for the interface to the DDR2. There is no particular reason why they would need to be the same.

  2. Please see the MCB documentation on the burst length input. This is simply how Xilinx chose to define the interface.

  3. We instantiate the PLL_ADV and DCM blocks directly. They do not require coregen modules as they are primitives on the Spartan-6.

3

Hi, Thanks for the reply.
For the first point, my query is: where can the burst length between the MCB and the DDR2 be configured (because it can be set differently during each memory access).

4

In our RAMTester sample, it cannot. Generally, it is an input to the MCB block (burst_len). Refer to the Spartan-6 MCB Documentation for more details.

5

Sorry… I answered the wrong question.

I believe the MCB to DDR2 burst length is set as a parameter to the MCB. I’m not sure the MCB allows you to set this differently per transaction. But this question falls into the realm of Xilinx support, so I would suggest contacting them on this matter.

6

Hello,
1) The reference design RAMTEST works when localparam C1_SKIP_IN_TERM_CAL = 1; and does not work when localparam C1_SKIP_IN_TERM_CAL = 0; also the current consumption goes up by 500mA (2.5W!) when this parameter is set to 0. In the ucf file, the in_term is set to none. Is there some connection here?
Please advise.
Having calibration turned ON for the internal termination makes sense but the design does not work. Why is it so? The soft-calibration module is anyhow enabled, then why does this calibration step increase the power consumption dramatically?

  1. The arb_time_slot settings in the reference design (i.e., ramtest) are modified from those given in example_top (generated by MIG), mainly the priority settings. However since only one port is used (of 6 available), then why is this needed?
  2. May I also ask you to explain a bit more about the following settings:
    localparam C1_INCLK_PERIOD = 20833; // OK System Clock 20833/1000 = 20.83ns -> 48Mhz
    localparam C1_CLKOUT0_DIVIDE = 1; // 624MHz system clock //Is the PLL configured to generated 624MHz from 48MHz input?
    localparam C1_CLKOUT1_DIVIDE = 1; // //is it used?
    localparam C1_CLKOUT2_DIVIDE = 4; // 156MHz Test Bench Clock //are we using it?
    localparam C1_CLKOUT3_DIVIDE = 8; // 78MHz Calibration Clock //is it used by the soft_calib_module?
    localparam C1_CLKFBOUT_MULT = 26; //what is it used for?
    localparam C1_DIVCLK_DIVIDE = 2;     //what is it used for?

localparam C1_INCLK_PERIOD = ((C1_MEMCLK_PERIOD * C1_CLKFBOUT_MULT) / (C1_DIVCLK_DIVIDE * C1_CLKOUT0_DIVIDE * 2)); is not used.

Also, the above have been changed from the default values; I guess since the MIG does not take in the input system clock (which in this case is 48MHz) the PLL has to be configured accordingly. May I ask how these values are derived.

Thanks a lot,
Regards,

7

It might be helpful to thoroughly review the MIG design documentation and their own examples and test benches. Xilinx documentation discusses clocks in great detail.

8

I guess that answers questions 2 and 3.
May I ask you for your advice for question 1?
Regards,

9

Good question. There seems to be inconsistent performance with the Xilinx MIG generator from version to version. We’re still investigating, but you may want to contact your Xilinx FAE as this appears to be a Xilinx issue.

10

Hi,
The following lines in the ucf are commented; but aren’t these constraints important? I am a bit confused because the design does work without them (as they are commented) but they are provided in the example.ucf.

DRAM

#CONFIG MCB_PERFORMANCE= STANDARD;
#NET “memc1_infrastructure_inst/sys_clk_ibufg” TNM_NET = “SYS_CLK1”;
#TIMESPEC “TS_SYS_CLK1” = PERIOD “SYS_CLK1” 20.83 ns HIGH 50 %;
#NET “memc?_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/selfrefresh_mcb_mode” TIG;
#NET “c?_pll_lock” TIG;
#NET “memc?_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/gen_term_calib.mcb_soft_calibration_top_inst/mcb_soft_calibration_inst/CKE_Train” TIG; ##This path exists for DDR2 only

11

Support, Looking forward to your response.
Thanks.

12

Support, Looking forward to your response.
Thanks,

13

We’ve submitted some questions to Xilinx and are awaiting their answer. This really isn’t an “Opal Kelly”-specific issue, but we’re trying to get to the bottom of things. This is an issue that affects the Xilinx Spartan-6 memory controller and configuration.

14

Appreciate the reply and look forward to the “truth” as well :slight_smile:
Thanks again.

15

Hello,
May I ask if we were able to get any response from Xilinx.
Regards,

16

Please open a support ticket with us ([email protected]). Although we follow our community forums, it’s not our primary support mechanism - it’s focus is community discussion.

17

Also, we would encourage you to open your own support ticket with Xilinx. Indeed, this is a Xilinx issue (not an Opal Kelly issue) and should be resolved with their support.