Author Topic: DDR3 initialization sequence issue  (Read 62609 times)

0 Members and 2 Guests are viewing this topic.

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #150 on: June 24, 2021, 02:07:22 am »
Quote
My write just does the opposite.  It snaps in a parallel chunk while continuously shifting out, with mask in parallel.

Why is this so difficult for you to just write like I did above?

Let me confirm one thing.  The pure verilog code above serves as serdes block without using any vendor built-in hard primitives ?  And it can run above 303MHz without any timing violations ?
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #151 on: June 24, 2021, 03:49:02 am »
IMHO, the speed depends only on the acquisition. You need to acquire fast DDR signal with a narrow window which gets more and more difficult as the clock speed increases. Once you get the data, there's no problem to dispatch it through FPGA. Therefore, if you want higher speed, you need to concentrate on sampling.

There are few problems with that. One problem is clock. Spartan-6 BUFIO can work up to 540 MHz (-3 grade) while BUFG can only go to 400 MHz. Hence, if you want to go above 400 MHz, you must sample with BUFIO.

Other problem is the signal: SI, including ODT calibration, length matching, timing, clock quality etc. This produces a window where you can sample (google "eye pattern" for visual). You need a window of certain width to be able to sample reliably. As the speed increases, the window shrinks. If your window is not wide enough, it will limit your speed. If you can get to the limit imposed by the clock you archived the goal - cannot go any faster. If you cannot get to the limit imposed by the clock, you need to work on widening your window.
 
The following users thanked this post: promach

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #152 on: June 24, 2021, 04:26:54 am »
Quote
My write just does the opposite.  It snaps in a parallel chunk while continuously shifting out, with mask in parallel.

Why is this so difficult for you to just write like I did above?

Let me confirm one thing.  The pure verilog code above serves as serdes block without using any vendor built-in hard primitives ?  And it can run above 303MHz without any timing violations ?
Yes, remember, that code I showed you is running on the DDR buffer's clock in.  Not the system clock.
It also can run at the >500MHz limit of the Altera Cyclones.  It is just too simple having a 2 bit counter and 2 bit compare.  The problem arises when connecting the RDATA and RDATA_toggle output to your system clock.  Within this bridge, you may need to setup a multicycle setup of 2 and hold of 1, but that shouldn't be necessary as your compiled setup PLL for that channel should be at 0 degree phase with respect to your system controller clock.  When sampling the RDATA and RDATA_toggle on your system controller clock, delay the RDATA_toggle by 2 clocks to guarantee when you capture the RDATA that all the bits are valid when you capture on the delayed toggle.  Since my system tunes the read clock, this shifts the entire bit of code I sent you and you want to ensure the RDATA when transferred over to the system clock's logic is always true.  (Remember, with BL8s, on your system clock, the RDATA_toggle flips once every 4 clocks.  If you are operating with BC4s, now timing will get more tight and my code would need some adaptation.)
« Last Edit: June 24, 2021, 04:28:52 am by BrianHG »
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #153 on: June 24, 2021, 05:27:00 am »
Quote
Yes, remember, that code I showed you is running on the DDR buffer's clock in.  Not the system clock.

This still requires a vendor PLL core to generate a frequency >= 303MHz to act as the DDR (both input and output ?) buffer's clock in.

Quote
The problem arises when connecting the RDATA and RDATA_toggle output to your system clock.  Within this bridge, you may need to setup a multicycle setup of 2 and hold of 1,

What is the purpose of the RDATA_toggle signal ?
Multicycle setup of 2 is because of the 2 preamble bits ?
What about multicycle hold of 1 ?

Quote
If you are operating with BC4s, now timing will get more tight and my code would need some adaptation.)

I do not think the timing will get tighter.  Why do you say such ?
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #154 on: June 24, 2021, 06:24:31 am »
#1: Yes, the PLL needs to generate the DDR_CK frequency.  I don't know about Xilinx, but with Altera, running a DDR buffer at 303MHz means the data come in/out at 606MHz, bu on the internal bus side, the data runs synchronous to 303MHz, but it's 2x wide.

#2:  A multicycle in the .sdc allows you to describe how many clocks of slack is allowed to transition from source to destination before the data must be valid.  As a 'falsepath' means you don't care about the timing.  This allows the compiler's fitter to optimize logic placement which can allow it to focus on parts of the design which must be fast and ignore to paths you choose, IE a global slow reset control, which you can specify it may be allowed to take up to 2/3 or more clocks before it reaches it's end.

I use the '_toggle' signal when my data out is ready allowing me to run my system clock at 150.15MHz (half rate mode), where it monitors for a toggle on that line, and when it does, it know a read data came in and latches it.  If I used a single 'data_ready' pulse, IE high for 1 single 303MHz clock cycle, the 150m side, or even 75m (Quarter rate) side would never see that portion of a clock pulse.  On the read clock side, serial delaying the '_toggle' by a clock or 2 allows me to set such a multicycle in the .sdc further removing the stringent timing between the DDR read clock and the rest of the system since the RDATA would have the data change to it's new contents 1 clock before, and hold it's contents steady for 3 clocks after the '_toggle' has toggled.

#3: BC4 read 2 clocks, plus a 1 clock break before the next BC4 or BL8 is permitted.  So, a BC4 after a BC4 has a 3 CK cycle.  BL8s are permitted every 4 clocks, IE a 4 clock cycle.  That's 1 clock shorter timing.  If you are not making a smart ram controller, or no consecutive bursting capabilities, your command spacing will never have these adjacent bursts, so you never need to worry about such tight cycles.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #155 on: June 24, 2021, 08:09:25 am »
Quote
running a DDR buffer at 303MHz means the data come in/out at 606MHz, bu on the internal bus side, the data runs synchronous to 303MHz, but it's 2x wide.

Does it mean the vendor PLL core needs to generate 606MHz ?
Or generate just 303MHz and apply DDR buffer similar to IDDR2 ?


Quote
I use the '_toggle' signal when my data out is ready allowing me to run my system clock at 150.15MHz (half rate mode), where it monitors for a toggle on that line, and when it does, it know a read data came in and latches it.  If I used a single 'data_ready' pulse, IE high for 1 single 303MHz clock cycle, the 150m side, or even 75m (Quarter rate) side would never see that portion of a clock pulse.  On the read clock side, serial delaying the '_toggle' by a clock or 2 allows me to set such a multicycle in the .sdc further removing the stringent timing between the DDR read clock and the rest of the system since the RDATA would have the data change to it's new contents 1 clock before, and hold it's contents steady for 3 clocks after the '_toggle' has toggled.

The code snippet you posted is a bit confusing especially the actual purpose of half-rate mode and quarter-rate mode.  Would you be able to post a full implementation of your own SERDES block on github repository ?

Besides, I also have something on multicycle for sdc constraint file, but your explanation on its purpose is a bit confusing to me.  Would you be able have some simple waveform drawing to illustrate your text explanation ?


Quote
BC4 read 2 clocks, plus a 1 clock break before the next BC4 or BL8 is permitted.  So, a BC4 after a BC4 has a 3 CK cycle.  BL8s are permitted every 4 clocks, IE a 4 clock cycle.  That's 1 clock shorter timing.

I do not see such phenomenon though in the following waveform.  Please correct me if wrong.

 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #156 on: June 24, 2021, 08:40:11 am »
Quote
running a DDR buffer at 303MHz means the data come in/out at 606MHz, bu on the internal bus side, the data runs synchronous to 303MHz, but it's 2x wide.

Does it mean the vendor PLL core needs to generate 606MHz ?
Or generate just 303MHz and apply DDR buffer similar to IDDR2 ?


Quote
I use the '_toggle' signal when my data out is ready allowing me to run my system clock at 150.15MHz (half rate mode), where it monitors for a toggle on that line, and when it does, it know a read data came in and latches it.  If I used a single 'data_ready' pulse, IE high for 1 single 303MHz clock cycle, the 150m side, or even 75m (Quarter rate) side would never see that portion of a clock pulse.  On the read clock side, serial delaying the '_toggle' by a clock or 2 allows me to set such a multicycle in the .sdc further removing the stringent timing between the DDR read clock and the rest of the system since the RDATA would have the data change to it's new contents 1 clock before, and hold it's contents steady for 3 clocks after the '_toggle' has toggled.

The code snippet you posted is a bit confusing especially the actual purpose of half-rate mode and quarter-rate mode.  Would you be able to post a full implementation of your own SERDES block on github repository ?

Besides, I also have something on multicycle for sdc constraint file, but your explanation on its purpose is a bit confusing to me.  Would you be able have some simple waveform drawing to illustrate your text explanation ?


Quote
BC4 read 2 clocks, plus a 1 clock break before the next BC4 or BL8 is permitted.  So, a BC4 after a BC4 has a 3 CK cycle.  BL8s are permitted every 4 clocks, IE a 4 clock cycle.  That's 1 clock shorter timing.

I do not see such phenomenon though in the following waveform.  Please correct me if wrong.



#1, In Altera, it's flip-flops at the IO pin use the 303MHz clock, sample on the rise and sample on the fall, with an internal alignment word DFF which shift the falling clocked data to the next stage FF for the normal synchronous rising clock.  I do not care how Altera internally does this shift, all I care is I provide a clock and I get back data sampled on the rising and falling edge on a double wide buss.  Same for the transmit section in the opposite direction.

#2, My code runs directly connected to the output of the DDR buffer and shares it's clock_in clock.  It does receive 1 single wire control 'run' signal from my system CK clock which generates all the DDR3 commands.  Otherwise, it just shifts away and every 4 words, it latches that serial pipe into an 2x4 word parallel chunk.  The 1 rule the 2 bit position counter is that it resets it's position if the DQS coming in isn't in a valid state, self correcting/aligning for the DDR3's beginning of a read command.  The full code will be posted on this forum once I fix my issue with my 16port read/16port write cache system.  I'm almost done as it just seems to miss a few posted read requests out of every few hundred thousand for some reason.  (Too large to find in simulation unless I go to extremes there, see attached image...)

#3, Thanks for the correction.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #157 on: June 24, 2021, 12:26:40 pm »
@BrianHG  Could I say that your phase calibration mechanism is similar to bitslip ?
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #158 on: June 24, 2021, 01:42:43 pm »
No, bit slip is is equivilant to reset of the 2bit counter 'RDQ_POS' which aligns my parallel output snapshot time:

Here is my bit-slip auto real-time self correcting code which corrects itself once valid read data comes in:
Code: [Select]
    if (!(RDQS_CACHE_h[RDQ_SYNC_CHAIN]==0 && RDQS_CACHE_l[RDQ_SYNC_CHAIN]==1)) begin    // No valid read data DQS signal pattern, so keep the RDATA_store & RDQ_POS in reset state.
             RDATA_store <= 0 ;                                                         // Reset due to preamble
             RDQ_POS     <= 1 ;                                                         // Reset due to preamble
    end else if ( RD_WINDOW ) begin                                                     // Only generate a single RDATA_store copy read data strobe when an unbroken
                                                                                        // 4 count DQS clock pattern is continuously running inside the read window.
 
                                                RDQ_POS     <= RDQ_POS + 1'b1 ;
                                if (RDQ_POS==3) RDATA_store <= 1'b1 ;
                                else            RDATA_store <= 1'b0 ;
    end else begin
             RDATA_store <= 0 ;                                                         // No more active read window, force end the read stat.
             RDQ_POS     <= 1 ;                                                         // Make sure a false broken read must run for 4 good clocks at the beginning of the next read window.
             end

if ( RDATA_store ) begin                                                                // When a RDATA_store is received, copy the RDQ_CACHE fifo into the RDATA output and toggle the RDATA_toggle status flag.
    for (int i=0;i<4;i++)   begin
                            RDATA[ ((i)*2+0)*DQ_WIDTH  +: DQ_WIDTH  ] <= RDQ_CACHE_h[i+RDQ_SYNC_CHAIN] ; // Big Endian BL8 burst
                            RDATA[ ((i)*2+1)*DQ_WIDTH  +: DQ_WIDTH  ] <= RDQ_CACHE_l[i+RDQ_SYNC_CHAIN] ;
                            end
                            RDATA_toggle_int    <= !RDATA_toggle_int ;
 
end
The first line 'if' and the 2 after that is my 'auto-bit-slip' correction system.  It works by validating the DQS input which is sampled in parallel with the data as seen on the previous page of code.

When doing a read calibration at powerup, I make phase adjustments to the read clock phase data and this code will either return the proper pattern, or garbage, or nothing at all if the read phase and 'RD_WINDOW ' alignment is wrong.  The RD_WINDOW  begins a clock early and ends a clock late allowing for the fact it was generated by the system clock and it shifts relative to the phase of the read clock as my code moves it around scanning for all the valid read points and selects the center position of all the qualified good reads.

« Last Edit: June 24, 2021, 02:07:23 pm by BrianHG »
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #159 on: June 24, 2021, 03:09:51 pm »
Wait, let's back up a bit.

You mentioned: ”I am not using the DQS strobe as a clock for sampling the DQ.  I'm using the DQS inputs as a 'data_enable' DDR input where the 'preamble' is used as a sync/reset read buffer position.  Remember, when reading data, the DQS is in perfect sync with the read DQ.“ in previous post on June 10

I suppose the quoted sentence above resembles bitslip operation ?
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #160 on: June 24, 2021, 03:47:28 pm »
I use the DQ strobe to set the position of of the bit slip.  IE: Equivalent to the alignment of the bit slip input which always runs.
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #161 on: June 24, 2021, 04:50:25 pm »
wait, let me clarify one more thing again.

Your current code implementation only implements bitslip (single bit shift which is equivalent to nano-second shift),  but not phase calibration (pico-second shift).

Please correct me if wrong.
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #162 on: June 24, 2021, 04:57:57 pm »
Quote
The tunable PLL output clock goes to the 'input clock' for the DQ & DQS DDR input buffers and subsequent read data FIFO's input clock.

The PLL has the following optional inputs:

Phase_select,                (Selects which one of the many outputs of a single PLL which you may wish to adjust the phase)
Phase_step_enable,       (Steps the selected PLL output's phase by 1/16th to 1/64th of the PLL's reference clock output, IE 64 steps will shift the selected output by a perfect 360 degrees.)
Phase_direction,          ( Step left or right.)

Wait, I think you are using vendor PLL core to generate pico-second shift.  Please correct me if wrong.

However, I had issues using dynamic phase shift feature of PLL inside ISE tool because of some underlying physical hardware limitations.

What could I do in this case ?

 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #163 on: June 24, 2021, 05:41:38 pm »
The PLL core tuning allows me ~50ps steps in either direction.
My so called 'bit-slip' is an alignment to the first word coming out of the DDR3 during a read, not a reference sampling timing like the PLL tuning.  If the PLL tuning is in a lemon position, the bit slip cant do anything.

Within the MAX 10's DDR buffers, I can setup the calibration de-skew function which offers 1ps step tuning with a range of +/-25ps.  It is only worth it for problem PCBs where you must correct for bad trace length matching.

My current error free tuning window is 7 x 50ps steps, or a span of 350ps where every data bit in the entire 16bits are valid and correct.  Going 1 step outside introduces garbage data.  Putting in the effort to get the 1ps adjustments working when I have 7 steps at the 50ps step size is a waste of my time.  In fact, the 1ps step with a size of +/-25ps total is so small, is is not useful in my design.

 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #164 on: June 25, 2021, 01:08:38 am »
I am thinking of where exactly in the dq signal input path shall the bitslip (nano-second shift) and IODELAY (pico-second shift) phase shift be implemented ?

The following is the input path for the dq and dqs signal

RAM -> IOBUF (for inout)  -> IDDR2 (input DDR buffer) -> ISERDES
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #165 on: June 25, 2021, 01:35:33 am »
I am thinking of where exactly in the dq signal input path shall the bitslip (nano-second shift) and IODELAY (pico-second shift) phase shift be implemented ?

The following is the input path for the dq and dqs signal

RAM -> IOBUF (for inout)  -> IDDR2 (input DDR buffer) -> ISERDES
Bit-slip is not a nanosecond in my design.  It is a 1/2 DDR3 CK# alignment.  It goes up and down by 1/2 DDR3 clock speed, it's a 2 byte on a 16 bit DDR3 ram chip.  My PLL tuning is what shifts inside each DDR3 CK.

On a ser-des, you would call this a bit slip because usually serdes have 1 bit input, not 16 in parallel like with a DDR3 chip.  So, slipping a bit means 1 bit to the left or right.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #166 on: June 25, 2021, 02:45:07 am »
Bitslip is a thing specific to ISERDES. It shifts (rotates) the data coming out of ISERDES by 360 degrees (or a multiple of 360 degrees) of the original clock, that is by whole number of serial bits (or whole number of bit pairs for DDR).

Bitslip has nothing to do with phase shift (performed to achieve a desired phase relationship between signals) you're discussing.
 
The following users thanked this post: promach

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #167 on: June 25, 2021, 03:12:44 am »
Bitslip is a thing specific to ISERDES. It shifts (rotates) the data coming out of ISERDES by 360 degrees (or a multiple of 360 degrees) of the original clock, that is by whole number of serial bits (or whole number of bit pairs for DDR).

Bitslip has nothing to do with phase shift (performed to achieve a desired phase relationship between signals) you're discussing.
Thanks, I was rights about the bit slip.
Mine can do 180 degrees was an added term, however, being able to detect that the source is 180 degrees out of phase is enough for me as the PLL tuning can go right around.
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #168 on: June 25, 2021, 05:32:29 am »
Someone told me the following regarding the difference in purpose between bitslip (1-bit shift which is equivalent to nano-second shift) and IODELAY (pico-second shift)

Quote
so the vaguely general description is that variations in things like PCB trace length can lead to variable amounts of skew between periodic (K clocks) or strobe (dqs) signals, such that the rising edge of these signals may not match up well with the data to be sampled. So, during DDR calibration you're going to first perform fine-tuned adjustment of the IODELAY taps in order to center the clocks/strobes between transition edges of your data. However, because the IODELAYs can only ...well, delay things...it's possible that the clocks/strobes can end up centered but a cycle out of sync. So the bitslip provides a way to delay the incoming signals on a cycle by cycle basis to account for that.
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #169 on: June 25, 2021, 05:52:30 am »
Now reading bitslip appnote for actual coding implementation leads to some Solution A and Solution B ?
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #170 on: June 25, 2021, 01:38:27 pm »
Someone told me the following regarding the difference in purpose between bitslip (1-bit shift which is equivalent to nano-second shift) and IODELAY (pico-second shift)

Quote
so the vaguely general description is that variations in things like PCB trace length can lead to variable amounts of skew between periodic (K clocks) or strobe (dqs) signals, such that the rising edge of these signals may not match up well with the data to be sampled. So, during DDR calibration you're going to first perform fine-tuned adjustment of the IODELAY taps in order to center the clocks/strobes between transition edges of your data. However, because the IODELAYs can only ...well, delay things...it's possible that the clocks/strobes can end up centered but a cycle out of sync. So the bitslip provides a way to delay the incoming signals on a cycle by cycle basis to account for that.

That's correct.

DDR3 chip has programmable latencies (that is you must program the cycle delay between the READ command and the data). So, your controller should already have a mechanism to account for variable number of cycles between the command and the data. Therefore, you don't need to use bitslip.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #171 on: June 25, 2021, 03:44:08 pm »
There is a catch though.

Remember that I am coding my own serdes, therefore I have to make it very simple for high DDR3 frequency.
Thus, the deserializer will be continuously doing the work without any turn on/off switch.

With this in mind, let's look at Figure 66 below.  Note the two low read-preamble DQS bits.

Let's say for example deserialize at 4:1 those two low bits on dqs happen to be on bit 1 and 2 of those four parallel bits, how to deal with that?

 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #173 on: June 25, 2021, 06:44:14 pm »
With this in mind, let's look at Figure 66 below.  Note the two low read-preamble DQS bits.

These are not two bits. The preamble is at least 900 ps, but may be longer. If your speed is low, say 300 MHz, you may be able to get only the very edge of it and if your timing is off, you may not be able to sample it at all.

The preamble is there just to mark the beginning of the period where DQS input is valid.

Let's say for example deserialize at 4:1 those two low bits on dqs happen to be on bit 1 and 2 of those four parallel bits, how to deal with that?

You don't deal with that. You know where your desirializer must start sampling data relative to the READ command you issued. You start sampling at this point (typically, by setting the CE pin of your deserializer). Your first data sample will be 90% after the first rising edge of DQS.

For sampling you typically use the said DQS edge shifted by 90 degrees, and you make sure you don't react to edges earlier than the preamble starts. Or, if you use BrianHG's method, you sample both DQ and DQS as close to this moment as possible.
 
The following users thanked this post: promach

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #174 on: June 25, 2021, 10:53:00 pm »
I am not using the preamble as an alignment.  I am sampling the DQS pattern in parallel with the data and using the 010101010101... as a data qualification alignment bit.  The preamble is just an invalid state preventing my sampling machine from beginning to load byte 0.  Also, it just so happens when I write data out, the DDR input sees my generated DQS upside down, so this also invalidates my read logic from beginning.

It's right there in my code bove from yesterday.  The first 'if' keeps the system in reset unless the DQS coming is always samples a 0 on the high clock and 1 on the low clock.  (I know this looks upside-down.  My read clock is tuned for 0 degrees from the write output clock and this in the internal-external buffer delay in the FPGA's IOs.  Attempting to tune a 0ps setup and hold for in and out makes it impossible for the compiler to make a workable design with high FMAX as the IOs are just so fast.)


 
The following users thanked this post: promach


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf