Questions on DQS Mode (Read Clocks, etc) for an SRAM Interface

[Altera_Forum]

Hi 

 I’m implementing a DDR2 SRAM interface, which does not seem to have an integrated Altera IP solution like those provided for DDR2 SDRAM or QDR2 SRAM. We’ve tried a few different approaches, which are running into timing problems that puzzle me. Consequently, I’m trying to gain a better understanding of DQS Mode in Stratix 3 FPGAs.   The SRAM receives complementary input clocks (K and K#) and echoes back complementary read clocks (CQ and CQ#) edge aligned with the SRAM DDR2 output data (DQ). In this case DQ is actually a bidirectional data bus.   1) Do I need to explicitly specify the DQ and DQS signals in a DQ group (x18, x36, etc), and if so, how?   2) I see references to the DQS bus network (Stratix III Handbook pp 8-4, 8-5, 8-27, 8-36), which I assume is a specialized routing for the clocks from the DQS/CQ pins (or from the DQS pin phase shift logic). I can see that within an IO cell, this clock path will have minimal delay, but how are the DQS/CQ clocks routed from the DQS pin I/O cell to the clock inputs of the DDIO registers in the DQ I/O blocks?    3) I’ve implemented a design using the ALT_DQ_DQS MegaFunction: Quartus 2 has assigned the phase-shifted CQ clock (let’s call it cq_shift) to a global clock network. TimeQuest is showing a 3.5ns delay in said global clock route, which is causing the design to fail data hold timing at the DQ DDIOs. This suggests that if there is a specialized high-speed DQS clock route being used between IO cells, that it is not being used for CQ (DQS). CQ#, on the other hand, has not been assigned to a global clock. Is there some constraint I need to specify in the Quartus assignments (QSF file) or the SDC file which instructs the fitter to use the CQ clock network, rather than a global clock?   4) If I don’t use an ALT_DQ_DQS MegaFunction, and don’t phase shift the DQS/CQ input clock, can Quartus still be made to route DQS/CQ inputs via the DQS clock network?    5) One reason why cq_shift may have been assigned to a global clock, is that I use it as the write clock to a FIFO. Is there a way I can separate the FIFO clock route from cq_shift, so that the former is global while cq_shift uses the DQS clock network?   6) In a DQS mode design, the ALTDLL and ALT_DQ_DQS MegaFunctions seem to require the phase shift to be explicitly specified. Is there any way to instruct Quartus (via constraints, settings, assignments, etc) to adjust this phase shift to match clock and data path delays?    7) What about input delays between the DQ pins and the DDIO registers in the IO cells? These can be specified – is there any way Quartus can adjust them during Fitting, ideally in conjunction with adjusting DQS phase shift, to endure the clock input to the DDIO registers is centered between data edges?   8) From the Stratix III Handbook, p8-4: “you must assign the write clocks to the dqs/dqsn pins associated to this write dqs/dq group. do not use the cq/cqn pin-pair for write clocks”. How do I determine which pins are DQS and which CQ? Pin Planner does not seem to differentiate, labeling all such pins as DQS (S).   9) Finally, I seem to recall reading that a pair of complementary output clocks (K and K#) can automatically be generated from a single DDIO component, reducing skew. Is this in fact the case? If so, how do I do it?   Thanks, Chris

[Altera_Forum]

It's been some time now since I wrote a low-level DDR interface and Altera's megacore's have changed somewhat. 

 Here is what I would recommend.  With the release of Quartus 10.0, Altera has once again made the datapath for their DDR memory controllers open-source. They've labeled this the Uni-phy. So with the 10.0 tools, I would generate a DDR2 SDRAM controller. Look at the generated code and also look at the generated timing SDC constraints. This should give you an idea of how to put together a datapath for your DDR2 SRAM controller.  Jake

[Altera_Forum]

I did this about a year ago in Stratix 3. I generated 3 megafunction blocks: 

- alt_dq_dqs  - altiobuf_bidir (for the data bidirs)  - altiobuf_in (for dqs and dqsn)  1. The dq_dqs mf block had the DQ_GROUP statements embedded in it (I may have needed to switch between DQ_GROUP 18 and 9 - I'm a tad fuzzy on that recollection).  2. I'm fairly sure it's dedicated routing.  3. CQn should also be on the dedicated routing... in my design, cq/cqn both came through the altiobuf_in cells, then connected to the dqs_input_data_in and dqsn_input_data_in pins of alt_de_dqs. The dqs_bus_out/dqsn_bus_out pins are left unconnected.  I then used an internal clock as a transfer clock, connected ot the dq_ipa_clk pin. I only have some of the info on how I did this, as I'm not at that job anymore, so don't have access to my notebooks.