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

0 Members and 1 Guest are viewing this topic.

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #125 on: June 11, 2021, 04:54:09 pm »
1) In https://github.com/mithro/soft-utmi/blob/master/hdl/third_party/XAPP1064-serdes-macros/Verilog_Source/Macros/serdes_1_to_n_data_ddr_s8_diff.v#L216-L256 and Figure 6, may I know how does this phase detection state machine works ? 
and which portion of the rest of the code belongs to calibration state machine ?

I don't know the details. You probably can figure this out from the source code. Also there's a huge chapter "Phase Detector Calibration Mechanisms" in ug381.

2) For figure 18, what do "USE_DOUBLER=TRUE"  and  "I_INVERT=TRUE"  mean ?  What is the purpose of the dotted line labelled as "Serdes Strobe" ?

USE_DOUBLER and I_INVERT are attributes of the BUFIO2 primitive. You can read about BUFIO2 in ug382.

SERDESSTROBE is an output from the clock buffer which produces a 1-clock-wide strobe for ISERDES which allows ISERDES to distingush where is the boundary between serial words. It feeds to IOCE input of the SERDES

3) For Figure 6, how does the signal "User BITSLIP" work for data reception ?  In the upper block, why is "Master IDELAY" connected to two-inputs "BUFIO2_2CLK"  ?

You can produce a pulse on BITSLIP. This will shift outputs of ISERDES by 1 bit. So, you can keep doing this until you get the perfect alignment.

BUFIO2_2CLK is the same as BUFIO2, only differential - two inputs are non-inverted and inverted clocks.

4) How do I turn on DDR mode for ISERDES primitive ?  and how is this different from IDDR primitive ?

Set the DATA_RATE attribute of the ISERDES primitive to "DDR". You also will need to supply 2 clocks to it CLK0 and CLK1 (for rising and falling edges respectively).

IDDR is a simpler primitive - it doesn't have CLKDIV, IOCE etc.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #126 on: June 12, 2021, 01:11:40 am »
@NorthGuy Thanks for your technical explanation.

I need some time to digest your reply.

By the way, I have found the calibration state machine coding at https://github.com/mithro/soft-utmi/blob/master/hdl/third_party/XAPP1064-serdes-macros/Verilog_Source/Macros/serdes_1_to_n_data_ddr_s8_diff.v#L141-L204

I might need to consult @mithro about the state machines mechanism if I could not fully understand the xilinx documents
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #127 on: June 13, 2021, 04:14:05 am »
Quote
BUFIO2_2CLK is the same as BUFIO2, only differential - two inputs are non-inverted and inverted clocks.

@NorthGuy

For Figure 6, can I replace the BUFIO2_2CLK primitive with just a BUFIO2 primitive ?  If not, why ?
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #128 on: June 13, 2021, 02:54:15 pm »
Quote
BUFIO2_2CLK is the same as BUFIO2, only differential - two inputs are non-inverted and inverted clocks.

@NorthGuy

For Figure 6, can I replace the BUFIO2_2CLK primitive with just a BUFIO2 primitive ?  If not, why ?

I don't know. There must be a mechanism which keeps both the delays the same. I suspect BUFIO2_2CLK is necessary for this purpose. Once you understand how the calibration works, you will know if it is possible to replace it with BUFIO2.
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #129 on: June 16, 2021, 04:54:24 am »
DDR's DQ signals are already in parallel, what is the purpose of using IOSERDES primitives then for series-to-parallel and parallel-to-series bits conversion ?
« Last Edit: June 16, 2021, 04:57:09 am by promach »
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #130 on: June 16, 2021, 07:39:05 am »
Someone told me that I could send a write of 8w bits to the memory controller, and the memory controller issues 8 writes of w bits to the memory, where w is the data width of your memory interface.

This literally means SERDES_RATIO=8   if I interpret the mechanism correctly. 
Please correct me if wrong.

By the way, any idea how this https://github.com/promach/DDR/blob/main/phase_detector.v does phase detection work ?
« Last Edit: June 16, 2021, 08:08:36 am by promach »
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #131 on: June 16, 2021, 02:12:23 pm »
Someone told me that I could send a write of 8w bits to the memory controller, and the memory controller issues 8 writes of w bits to the memory, where w is the data width of your memory interface.

This literally means SERDES_RATIO=8   if I interpret the mechanism correctly. 
Please correct me if wrong.

THe transmission is in bursts. Full burst is 8-bit. You also can do half-burst - 4-bit - but there's no performance gain when you do this.

This means that serdes ratio of 4 is the most convenient. 8 is the best if you don't do half-bursts. Although, nothing precludes you from  using any other ratio.

The ratio dictates the speed of the clock which you use to communicate with SERDES. For example, if your DDR3 clock is 600 MHz, then 4:1 SERDES will dictate 300 MHz clock. 8:1 SERDES will dictate 150 MHz clock.
« Last Edit: June 16, 2021, 02:24:06 pm by NorthGuy »
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
« Last Edit: June 17, 2021, 02:10:43 pm by promach »
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #133 on: June 17, 2021, 04:18:28 pm »
What is the actual purpose of the serdesstrobeb signal which is the B serdes strobe from BUFIO2 ?

SERDESSTROBE is a CE signal to be used as IOCE pin in the ISERDES. ug381 should have a schematics of ISERDES which shows how it's used.

When you produce clock for ISERDES with BUFIO2 (or other clock buffers), they produce SERDESSTROBE for you which you connect along with the clock to the ISERDES.
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #134 on: June 18, 2021, 01:44:04 am »
Let me rephrase my question:

Do I need serdesstrobeb when serdesstrobea is available ?
In other words, is serdesstrobeb == serdesstrobea ?
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #135 on: June 18, 2021, 01:57:20 pm »
1) Do anyone know how this https://github.com/promach/DDR/blob/main/phase_detector.v works internally ?

2) What does it mean by MAX in Figure 9 of XAPP1064 appnote ?

3) Could anyone explain what it means by Early Data Sampling and Late Data Sampling ?

4) As for why is it 5 bits wide for pdcounter , someone told me that the verilog code only supports 32 (which is equivalent to 25) steps, but that is 1/8 of the total possible delay steps (256 delay taps) ?



 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #136 on: June 18, 2021, 03:25:12 pm »
Let me rephrase my question:

Do I need serdesstrobeb when serdesstrobea is available ?
In other words, is serdesstrobeb == serdesstrobea ?

The code on your picture seems to produce two clocks - A and B. Each has associsated SERDESSTROBE - A and B, so they're not the same.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #137 on: June 18, 2021, 04:27:17 pm »
1) Do anyone know how this https://github.com/promach/DDR/blob/main/phase_detector.v works internally ?

I haven't looked code. I can only comment on the general principle.

Master and slave data are delayed with an offset and sampled with the same clock. When there's an edge in data the VALID signal produces a pulse and INCDEC is set to '1' or '0' depending on the master and slave samples being different or the same. The code is supposed to aggregate these readings. If there is a skew (that is INCDEC is either always '1' or '0') most of the time, your code is supposed to correct the delay.

The diagram you posted is supposed to be read from top to bottom - the top two lines produce the same reading for both master and slave thus INCDEC is set to '0'. The delay is then decremented which shifts data relative to the clock - look at the second set of lines. But the master and slave readings are still the same so INCDEC is still '0'. So, they decrement the delay again - look at the third set of lines. Still the same, so they do another decrement - look at the forth (last) set of the lines. This time, master and slave readings are different, so INCDEC is now '1'. Therefore they increment the delay by '1' going back to the third set of lines. This continues indefinitely keeping the data aligned to the clock.

The pdcount simply adds some stability. Instead of doing delay increments/decrements immediately, they accumulate INCDEC values with the pdcount register. If the INCDEC values are mixed (meaning alignment is close to optimum), pdcount varies around "10000". If ones start to prevail (pdcount goes to "11111") and they do the increment. If zeroes start to prevail, pdcount moves to "00000"  and they do the decrement. Of course you can use any number of bits - the more bits you use the more stable and less responsible the calibration becomes.

The drawback is you need data to maintain calibration. If data stops, the calibration stops too. As applied to DDR3, this means that you need to read data periodically, or you lose calibration. That's where calibrated delays in 7-series come handy.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #138 on: June 19, 2021, 10:24:22 am »
@NorthGuy Thanks for the explanation.  Please allow me some time to digest your technical explanation.

By the way, what is wrong with the user_desired_extra_read_or_write_cycles signal ?

 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #139 on: June 19, 2021, 01:43:47 pm »
By the way, what is wrong with the user_desired_extra_read_or_write_cycles signal ?

I guess you drive IBUFDS with this signal along with other things. IBUFx/OBUFx/IOBUFx blocks are positioned on the input pad. They are, sort of, bridges between the FPGA internals and outside world. A wire which drives IBUF is outside of the FPGA and cannot drive anything inside the FPGA. This may have something to do with UCF files.

There are lots of people on this forum who still use ISE on daily basis. They may not look at this thread. I suggest you open a separate thread for ISE entanglements.
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #140 on: June 20, 2021, 08:20:37 am »
Quote
The pdcount simply adds some stability. Instead of doing delay increments/decrements immediately, they accumulate INCDEC values with the pdcount register. If the INCDEC values are mixed (meaning alignment is close to optimum), pdcount varies around "10000". If ones start to prevail (pdcount goes to "11111") and they do the increment. If zeroes start to prevail, pdcount moves to "00000"  and they do the decrement. Of course you can use any number of bits - the more bits you use the more stable and less responsible the calibration becomes.

Wait, I suppose DDR protocol is high-speed protocol ?  Why accumulate instead of calibrate immediately ?

What do you exactly mean by INCDEC values are mixed (meaning alignment is close to optimum) ?

Why exactly the more bits you use, the more stable and less responsible the calibration becomes ?
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #141 on: June 20, 2021, 01:33:22 pm »
Wait, I suppose DDR protocol is high-speed protocol ?  Why accumulate instead of calibrate immediately ?

You don't have to. You can calibrate at every step. But this will produce jitter because you'll change the delays every edge. The data from the DDR3 chip have their own jitter too - you do not want to adjust your settings based on this - you only need to adjust if the data if there's a lasting shift in data position.

Temperature-related changes are very slow compared to DDR3 speed.

What do you exactly mean by INCDEC values are mixed (meaning alignment is close to optimum) ?

Mixed means a mix of '0' and '1'. As opposed to all '0' or all '1', which would indicate that something has changed.

Why exactly the more bits you use, the more stable and less responsible the calibration becomes ?

5 bits mean you're going to calibrate if the difference between the count of '0' and '1' is 15. 6 means you need the difference of 31. 7 means 63. Therefore the more bits, the longer you will wait until you get enough difference between '0' and '1'. Longer wait means more stability and less responsiveness.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #142 on: June 22, 2021, 12:17:42 pm »
According to https://www.xilinx.com/support/documentation/application_notes/xapp1064.pdf#page=20 , When the SerDes factor is 5 to 8 or the phase detector function is selected, two ISERDES2s are required and the pin next to the active input (which must be a master or _p pin) is blocked from use as a synchronous input since the necessary logic is already occupied.

There is some underlying hardware limitation which disallows the use of phase detection of IODELAY2 primitive in the case of ISERDES2 primitive for DDR3 memory controller application.

https://github.com/promach/DDR/blob/main/phase_detector.v#L73-L77

Code: [Select]
[phung@archlinux DDR]$ grep -n IODELAY *.v
phase_detector.v:23://        - State machine changed slightly to enable individual control of INC pins on IODELAY2s
phase_detector.v:67:input    [D-1:0]        busy ;            // BUSY inputs from IODELAY2s
phase_detector.v:73:output            cal_master ;        // Output to cal pins on master IODELAY2s
phase_detector.v:74:output            cal_slave ;        // Output to cal pins on slave IODELAY2s
phase_detector.v:75:output            rst_out ;        // Output to rst pins on master & slave IODELAY2s
phase_detector.v:76:output    [D-1:0]        ce ;              // Outputs to ce pins on IODELAY2s
phase_detector.v:77:output    [D-1:0]        inc ;              // Outputs to inc pins on IODELAY2s
phase_detector.v:140:          if (enable == 1'b1) begin                // Wait for IODELAY to be available
phase_detector.v:156:       4'h2 :     begin                            // Now RST master and slave IODELAYs needed for simulation, not for the silicon
phase_detector.v:168:       4'h4 :     begin                            // Wait for IODELAY to be available
phase_detector.v:193:       4'h8 : begin                            // Wait for all IODELAYs to be available, ie CAL command finished
serdes_1_to_n_clk_ddr_s8_diff.v:70:wire         ddly_m;             // Master output from IODELAY1
serdes_1_to_n_clk_ddr_s8_diff.v:71:wire         ddly_s;             // Slave output from IODELAY1
serdes_1_to_n_clk_ddr_s8_diff.v:95://        IODELAY for the differential inputs.
serdes_1_to_n_clk_ddr_s8_diff.v:97:IODELAY2 #(
serdes_1_to_n_clk_ddr_s8_diff.v:125:IODELAY2 #(
serdes_1_to_n_data_ddr_s8_diff.v:89:wire     [D-1:0]        ddly_m;             // Master output from IODELAY1
serdes_1_to_n_data_ddr_s8_diff.v:90:wire     [D-1:0]        ddly_s;             // Slave output from IODELAY1
serdes_1_to_n_data_ddr_s8_diff.v:145:IODELAY2 #(
serdes_1_to_n_data_ddr_s8_diff.v:172:IODELAY2 #(
[phung@archlinux DDR]$
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #143 on: June 23, 2021, 02:43:59 am »
According to https://www.xilinx.com/support/documentation/application_notes/xapp1064.pdf#page=20 , When the SerDes factor is 5 to 8 or the phase detector function is selected, two ISERDES2s are required and the pin next to the active input (which must be a master or _p pin) is blocked from use as a synchronous input since the necessary logic is already occupied.

It might be impossible to calibrate delays for DDR3. You need to study what they have in details and figure out what can be done. Xilinx won't have any DDR3 examples because they have DDR3 API which uses dedicated blocks. Most people use Xilinx's IP, so it's very few with any experience.

If you find it impossible, then you need to find a different approach (such as BrianHG's method) or a different chip (such as Xilinx 7-series).
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #144 on: June 23, 2021, 12:51:52 pm »
Why phase detector requires TWO ISERDES2 primitives ?




Quote
If you find it impossible, then you need to find a different approach (such as BrianHG's method) or a different chip (such as Xilinx 7-series).

BrianHG's method might not work for frequencies higher than 303MHz.   Please correct me if wrong.

Why use 7-series ?  How would it exactly solve my current issue ?

As for Altera MAX10 DECA development board, it seems that there is no dynamic phase detection/calibration state machine verilog coding available ?

 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #145 on: June 23, 2021, 01:54:50 pm »
BrianHG's method might not work for frequencies higher than 303MHz.   Please correct me if wrong.

Not necessarily. Basically, his method assumes that DQS to CK phase relationship is fixed, so if DQS wonders away (for example because of changes in temperature or voltage) it'll stop working. This makes the window narrower, but there's no way to figure out how big the effect is. May work at higher frequencies as well.

Anyway, Spartan-6 will have a limit of how fast you can go, which may be not too far from 300 MHz. Their hardware memory block is rated at 800 Mb/s - 400 MHz. Their DDR LVDS when clocked with BUFG is also rated at 400 MHz. The datasheet says that you can go to 540 MHz with BUFIO/ISERDES, but only if ratio is 4:1 or above. And this is with -3 speed grade.

Why use 7-series ?  How would it exactly solve my current issue ?

Auto-calibrated delays, memory mode ISERDES, higher speed.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #146 on: June 23, 2021, 04:21:56 pm »
Quote
Why phase detector requires TWO ISERDES2 primitives ?

Someone told me the following:

Quote
The "master" is used for the actual data sampling. The delay is adjusted so the sampling is in the middle of the eye.
The "slave" is used for the continuous delay adjustment. The delay is adjusted to be where the data is expected to change.
Every time there is an edge on the data (= the data bit changed), is is checked if the slave sampled the old or the new value (early or late sampling).
When early or late dominates, the pdcounter will eventually reach one of it's limits, and both ISERDES2 primitives are ordered to increment or decrement the delay by one tap.

The master can't be used for the timing adjustment, because the need for a delay change wouldn't be detected until the data had already been corrupted.

But I am confused as in what it exactly means by "The master can't be used for the timing adjustment, because the need for a delay change wouldn't be detected until the data had already been corrupted." ?

 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3136
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #147 on: June 23, 2021, 09:25:40 pm »
But I am confused as in what it exactly means by "The master can't be used for the timing adjustment, because the need for a delay change wouldn't be detected until the data had already been corrupted." ?

You use the data signal to get your data. If the signal goes out of alignment, the data is lost. Therefore, you need to do the adjustments when the signal only begins to go out of alignment.

Therefore, they use a different signal, which is the copy of the original signal shifted by 90 degrees. If the data starts to shift (either way), this second signal (which has a good deal of shift incorporated into it already) will get out of alignment much sooner. This gives you an opportunity to correct the alignment before the data is corrupted.

I don't know whether the mechanism is suitable for DDR3. DQS is a differential signal, so it uses two pins and hence there are two ISERDES blocks. Therefore the lack of ISERDES blocks per se is not a problem in aligning DQS to CK. But of course there may be routing problems, configuration problems etc. The devil is in the details.
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: DDR3 initialization sequence issue
« Reply #148 on: June 24, 2021, 12:31:17 am »
Quote
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.

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.

@BrianHG Why your phase calibration approach does not require use of SERDES block ?
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: DDR3 initialization sequence issue
« Reply #149 on: June 24, 2021, 01:55:12 am »
Quote
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.

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.

@BrianHG Why your phase calibration approach does not require use of SERDES block ?

Here, my ser/des block:
The serial shift in from the simplest of DDR input buffer:
Code: [Select]
                                            RDQ_CACHE_h[0]    <= RDQ_h;                       // Shift in the input read data
                                            RDQ_CACHE_l[0]    <= RDQ_l;                       // Shift in the input read data
    for (int i=0; i<(3+RDQ_SYNC_CHAIN);i++) RDQ_CACHE_h[i+1]  <= RDQ_CACHE_h[i];              // Shift the input across the cache
    for (int i=0; i<(3+RDQ_SYNC_CHAIN);i++) RDQ_CACHE_l[i+1]  <= RDQ_CACHE_l[i];              // Shift the input across the cache
                                            RDQS_CACHE_h[0]   <= RDQS_ph[0];                  // Shift in the DQS status
                                            RDQS_CACHE_l[0]   <= RDQS_pl[0];                  // Shift in the DQS status
    for (int i=0; i<(3+RDQ_SYNC_CHAIN);i++) RDQS_CACHE_h[i+1] <= RDQS_CACHE_h[i];             // Shift the status across the cache
    for (int i=0; i<(3+RDQ_SYNC_CHAIN);i++) RDQS_CACHE_l[i+1] <= RDQS_CACHE_l[i];             // Shift the status across the cache

Snapping the serial word from the above serial pipe of data:
Code: [Select]
if ( RDATA_store ) begin                                                                // When a RDATA_store is received, copy the RDQ_CACHE fifo into the RDATAt output and toggle the RDQ_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 <= !RDATA_toggle ;
    end

RDATA is the full parallel BL8 word/chunk.
RDATA_store is generated by a 2 bit counter, reset by the pattern coming through the parallel sampling RDQS_CACHE_h/l pipe, and externally enabled by a read command.

    Even an Altera -8 can run this code above 320MHz while a -6 can push the 450MHz limit, IE 900MHz DDR3 even though Altera's DDR3 IO limit is 320/640MHz and for some stupid reasons their CK port is limited a lower to 300/600MHz, IE 300MHz CK# output speed.  (I am not using any of the advanced fine time tuning capabilities available to the Max10 on every DDR buffer pin.  Doing so would make my code incompatible with older CycloneIV devices, or would need re-working for Lattice and Xilinx which should officially support above 400MHz and above as their DDR buffers are as fast as Altera's Arria FPGAs.)  RDATA_toggle is the secret to crossing 1 clock domain boundary into another, especially is that clock shifts around when tuned compared to your master system DDR Clock.

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?
« Last Edit: June 24, 2021, 02:08:48 am by BrianHG »
 
The following users thanked this post: promach


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf