Bug in DDR template in Lattice FPGAs ?

DQ and DQS should have different clock-to-output timing. DQS rising edge should be in the middle of DQ output window. So receiver can use DQS rising edge to clock in data contained in DQ valid window.

What DDR is different from normal SDRAM is DDR is source synchronous driving device. DQS is used to clock in data sent by data sender.

Weng

I am NOT talking of DQ with regard to DQS.

I am talking about the bits of the bus DQ and the bits of the bus DQS ! They have different tCO. I already know DDR basics ;o)

What about contacting a local Lattice FAE?

Luc

I'm still not answering your question but posing you another question:

Are the clock-to-out times different by about 1/4 of your DDR clock period?

I know that timing analysis from other vendors tend to illustrate timing from the positive edge of the appropriate clock. If the Lattice implementation uses a 2x clock for the data signals, the DQ "bus" and the DQS "bus" (neither of which are a bus, really - they're coupled into byte lanes) would be clocked on opposite edges of that clock. If the clock-to-out timing is referenced to the rising edge only, the difference would be half the 2x clock period. Is that what you're seeing?

Either a Lattice FAE or timing report numbers published here might give others a better idea of what's happening.

OK, maybe my question was not clear enough, one more try:

Having a look at the data bus DQ I can see the following in the PERFORMANCE ANALYST (that is the STATIC TIMING ANALYSIS):

SOURCE DESTINATION DELAY (ns)

CLK Dq_15 9.971 CLK Dq_14 9.971 CLK Dq_13 9.701 CLK Dq_12 9.701 CLK Dq_11 9.698 CLK Dq_10 9.698 CLK Dq_9 9.974 CLK Dq_8 9.974 CLK Dq_7 10.574 CLK Dq_6 10.070 CLK Dq_5 10.350 CLK Dq_4 10.314 CLK Dq_3 10.070 CLK Dq_2 10.574 CLK Dq_1 10.350 CLK Dq_0 10.314

As you can see there are different tCO for the bits of the bus, the same for DQS, ALTHOUGH using the Lattice datapath template as described in my previous post.

Any ideas?

Rgds André

Andre,

I think what you are missing are the constraints. Have set your Tco, fmax, Setup and Pin Assignment constraints? Use either the preference file (.prf) or the Pre-Map Preference Editor to set your constraints. Also TN1050 can help you out.

rgds,

cristian

Hi Cristian,

yes I have set the constraints for all the other signals which do not come out the DATAPATH template. In the Timing Analysis these signals (for example the address bus for DDR) do have the same tCO.

I have constrained DQ and DQS in the PREFERENCE EDITOR under "In/Out Clock" whereas the other signals are constrained under "Cell Attributes". But the constraints for DQ and DQS do have no effect on the tCO.

Rgds André

Andre,

You should be able to constraint the Tco for the DQ and DQS in the input_setup/clock_to_output preference window. Check the example at $ispLEVER/ispcpld/examples/latticeEC/preferences_attributes/ddr/vhdl/ddr.syn

and let me know.

rgds,

cristian

ALuP> > Andre,

Tco,

preference

constraints.

Clock"

Hi Cristian,

I checked the example, and yet, the tCO is for the bits of DQ identical.

But the example does not use the template from the IP Manager but the particular modules.

ispLEVER5.0 is my hope :o)

Rgds André