Hello guys, I am building a system wich employs the DDR controller generated by MIG 2.0 for a DDR memory + Spartan3E. So far the simulations work fine, and according to the waveforms on UG086. I am using a burst length of 4. My doubt is: for writting, after sending a burst (4 times data), can I continue sending data continuously within the same write command, or should I always terminate the command (with the burst_done signal) and send another write command again in order to write another block in a burst with lenght 4 ? Of course, all of this provided the attention to the auto refresh request. All of your help is welcome.
MIG 2.0 for DDR - Spartan3E
Started by ●February 23, 2009
Reply by ●February 23, 20092009-02-23
On 23 feb, 10:48, Jaime Andr=E9s Aranguren Cardona <jaime.arangu...@gmail.com> wrote:> Hello guys, > > I am building a system wich employs the DDR controller generated by > MIG 2.0 for a DDR memory + Spartan3E. So far the simulations work > fine, and according to the waveforms on UG086. > > I am using a burst length of 4. My doubt is: for writting, after > sending a burst (4 times data), can I continue sending data > continuously within the same write command, or should I always > terminate the command (with the burst_done signal) and send another > write command again in order to write another block in a burst with > lenght 4 ? Of course, all of this provided the attention to the auto > refresh request. > > All of your help is welcome.Hi, The answer was there: "The user must terminate the transfer on a column boundary and must re-initialize the controller for the next row of transactions on a column boundary" Now the question is different: I can get (in simulation) all the signals working, except cntrl0_ddr_dq and cntrl0_ddr_dqs (the most important ones!). I did a loopback between cntrl0_rst_dqs_div_out and cntrl0_rst_dqs_div_in, but both stay all the time in LOW, whereas in the simulation filed delivered by MIG I can see them toggling sometimes to HIGH; the simulation filed delivered by MIG also do a simple loopback. What else can I be missing? What tips should I be aware of to get this running? Kind regards.
Reply by ●February 23, 20092009-02-23
On 23 feb, 13:57, Jaime Andr=E9s Aranguren Cardona <jaime.arangu...@gmail.com> wrote:> On 23 feb, 10:48, Jaime Andr=E9s Aranguren Cardona > > > > > > <jaime.arangu...@gmail.com> wrote: > > Hello guys, > > > I am building a system wich employs the DDR controller generated by > > MIG 2.0 for a DDR memory + Spartan3E. So far the simulations work > > fine, and according to the waveforms on UG086. > > > I am using a burst length of 4. My doubt is: for writting, after > > sending a burst (4 times data), can I continue sending data > > continuously within the same write command, or should I always > > terminate the command (with the burst_done signal) and send another > > write command again in order to write another block in a burst with > > lenght 4 ? Of course, all of this provided the attention to the auto > > refresh request. > > > All of your help is welcome. > > Hi, > > The answer was there: > > "The user must terminate the transfer on a > column boundary and must re-initialize the controller for the > next row of transactions on a column boundary" > > Now the question is different: I can get (in simulation) all the > signals working, except cntrl0_ddr_dq and cntrl0_ddr_dqs (the most > important ones!). I did a loopback between cntrl0_rst_dqs_div_out and > cntrl0_rst_dqs_div_in, but both stay all the time in LOW, whereas in > the simulation filed delivered by MIG I can see them toggling > sometimes to HIGH; the simulation filed delivered by MIG also do a > simple loopback. > > What else can I be missing? What tips should I be aware of to get this > running? > > Kind regards.- Ocultar texto de la cita - > > - Mostrar texto de la cita -Hello guys. Again, I could find it myself: I just had to put the testbench side of the bus in Hi-Z. Now the signals (all of them) show correct activity. Nevertheless, thanks for reading. Regards.
Reply by ●February 23, 20092009-02-23
Jaime Andr�s Aranguren Cardona wrote:> I am building a system wich employs the DDR controller generated by > MIG 2.0 for a DDR memory + Spartan3E. So far the simulations work > fine, and according to the waveforms on UG086.I am also interested in using DDR with the Spartan 3E (such as on the Digilent Spartan 3E board.) Most of my problems should be relatively simple. I don't need the full speed, or even bursts of more than one. I haven't looked at UG086 yet. -- glen
Reply by ●February 26, 20092009-02-26
On 23 Feb., 20:36, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:> Jaime Andr=E9s Aranguren Cardona wrote: > > > I am building a system wich employs the DDR controller generated by > > MIG 2.0 for a DDR memory + Spartan3E. So far the simulations work > > fine, and according to the waveforms on UG086. > > I am also interested in using DDR with the Spartan 3E (such > as on the Digilent Spartan 3E board.) =A0Most of my problems > should be relatively simple. =A0I don't need the full speed, or > even bursts of more than one. =A0I haven't looked at UG086 yet. > > -- glenHi Glen, all guys. The MIG code seems to work, in simulation at least. Well, I know it does come with a simulation testbench and so on, but since later on I will move to a different FPGA (S3A) with the same DDR chip, I decided to start with the S3E kit for tthe HW test but I am fine tuning it myself, which means that I create both a "generic" DDR project, and a S3E kit project in MIG, and I base all of my tests on the "generic" code, and later hand customize it for this kit (clock input, location and timing constraints from kit's UCF, etc...) I am testing against the model provided by micron.com, and it seems to read / write in simulation. My problem now is to correctly generate the col/row/bank addresses. BTW: could you provide some enlightment about how to correctly generate them? For my initial test I just want to continuously and sequentially (from address 0 to 1023, in a linear fashion) write a sequence of numbers (0 to 1023), then read back in the same order and check if I read what I intended to write. My problem now is how to generate the sequential addresses (linea fashion) vs. row/col/bank which is needed for the MIG DDR controller. Any hints will be appreciated. JaaC
Reply by ●February 26, 20092009-02-26
On Feb 26, 6:30=A0am, Jaime Andr=E9s Aranguren Cardona <jaime.arangu...@gmail.com> wrote:> On 23 Feb., 20:36, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > Jaime Andr=E9s Aranguren Cardona wrote: > > > > I am building a system wich employs the DDR controller generated by > > > MIG 2.0 for a DDR memory + Spartan3E. So far the simulations work > > > fine, and according to the waveforms on UG086. > > > I am also interested in using DDR with the Spartan 3E (such > > as on the Digilent Spartan 3E board.) =A0Most of my problems > > should be relatively simple. =A0I don't need the full speed, or > > even bursts of more than one. =A0I haven't looked at UG086 yet. > > > -- glen > > Hi Glen, all guys. > > The MIG code seems to work, in simulation at least. Well, I know it > does come with a simulation testbench and so on, but since later on I > will move to a different FPGA (S3A) with the same DDR chip, I decided > to start with the S3E kit for tthe HW test but I am fine tuning it > myself, which means that I create both a "generic" DDR project, and a > S3E kit project in MIG, and I base all of my tests on the "generic" > code, and later hand customize it for this kit (clock input, location > and timing constraints from kit's UCF, etc...) > > I am testing against the model provided by micron.com, and it seems to > read / write in simulation. My problem now is to correctly generate > the col/row/bank addresses. BTW: could you provide some enlightment > about how to correctly generate them? For my initial test I just want > to continuously and sequentially (from address 0 to 1023, in a linear > fashion) write a sequence of numbers (0 to 1023), then read back in > the same order and check if I read what I intended to write. My > problem now is how to generate the sequential addresses (linea > fashion) vs. row/col/bank which is needed for the MIG DDR controller. > > Any hints will be appreciated. > > JaaCFor Spartan 3 MIG, which is primitive compared to the Virtex 5 MIG, the order of row vs. bank addressing is not important. This is due to the fact that the MIG code only leaves one row of one bank active at any time. The column address should be your low order address bits for linear addressing. This will prevent unnecessary row precharge / activate sequences when performing linear access to memory. Also note that the least significant bits of the column address are incremented inside the memory chip during a burst operation. There is no carry out to the upper address bits, so when starting a burst you should normally begin at a burst boundary to avoid rapping back to previous addresses. Be careful when using the MIG top level interface with "linear" address. It may be using the least significant bits for the bank address (depends on which interface type DDR, DDR2, etc.). Regards, Gabor
Reply by ●February 26, 20092009-02-26
gabor wrote: (snip)> For Spartan 3 MIG, which is primitive compared to the Virtex 5 > MIG, the order of row vs. bank addressing is not important. > This is due to the fact that the MIG code only leaves one > row of one bank active at any time. The column address should > be your low order address bits for linear addressing. This > will prevent unnecessary row precharge / activate sequences > when performing linear access to memory.One that I might try is a video display that also refreshes the RAM. That is an old trick that might still work.> Also note that > the least significant bits of the column address are > incremented inside the memory chip during a burst operation. > There is no carry out to the upper address bits, so when > starting a burst you should normally begin at a burst > boundary to avoid rapping back to previous addresses.I don't expect any burst operations. My first system will be 8080 based, and I don't believe that the 8080 does bursts.> Be careful when using the MIG top level interface with > "linear" address. It may be using the least significant > bits for the bank address (depends on which interface > type DDR, DDR2, etc.).-- glen
Reply by ●March 16, 20092009-03-16
On 26 Feb., 23:02, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:> gabor wrote: > > (snip) > > > For Spartan 3 MIG, which is primitive compared to the Virtex 5 > > MIG, the order of row vs. bank addressing is not important. > > This is due to the fact that the MIG code only leaves one > > row of one bank active at any time. =A0The column address should > > be your low order address bits for linear addressing. =A0This > > will prevent unnecessary row precharge / activate sequences > > when performing linear access to memory. > > One that I might try is a video display that also refreshes > the RAM. =A0That is an old trick that might still work. > > > Also note that > > the least significant bits of the column address are > > incremented inside the memory chip during a burst operation. > > There is no carry out to the upper address bits, so when > > starting a burst you should normally begin at a burst > > boundary to avoid rapping back to previous addresses. > > I don't expect any burst operations. =A0My first system will > be 8080 based, and I don't believe that the 8080 does bursts. > > > Be careful when using the MIG top level interface with > > "linear" address. =A0It may be using the least significant > > bits for the bank address (depends on which interface > > typeDDR, DDR2, etc.). > > -- glenHi guys, Going further with the thread, I want to "report" that it seems to be working, but partially. In simulation everything goes fine, both for writing and reading data. I generate a sequence of numbers, fill the memory with it, and then read all the positions back, comparing with the sequence of numbers written. If an error is found, a counter is incremented. At the end of the read sequence, if everything goes fine, one led should glow, if not (even a single mismatch was found, which means the error counter is different to zero) then 6 leds glow. I am testing my stuff on an S3E Kit. If I just run the test for a very few rows (say 3), then most of the times the test passes, others it does not. If I run for higher number of rows, then at all times it fails. So, it seems to me that I am getting timing problems. Besides, I have to add that I am not using an external 133 MHz clock to SMA connector, I am using the onboard 50Mhz clock instead and a couple DCMs, one for generating a 100 MHz clock and another one to generate the 90 degree phase shifted clock. Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps). Looking into the details of the UCF, I see that this signal, which for the S3E Starter kit is implemented as a loopback, has an assigment to pin P13. I suppose that that is needed because of packaging to IOBs, which is one of the project options for the MIG generated project. Is there a way to make the signal always internal and not look for a physical pin? The only way I have found to meet timing constraints was to remove that constraint in the UCF (the one that assigns rst_dqs_div signal to pin P13), but now another problem arises: when generating the bitstream, it fails because DRC is not passed, saying that the signal rst_dqs_div was assigned to bank3 which uses impedance controlled buffers or has Vref requeriments, which rst_dqs_div does not meet. How can it be got to work reliably? Even the original project generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without modifications, fails to meet the timing constraints for signal rst_dqs_div, which is supposed to be a critical timing signal necessary to get the controller working correctly. All your comments and suggestion are very welcome. Kind regards.
Reply by ●March 17, 20092009-03-17
On 16 Mrz., 17:18, Jaime Andr=E9s Aranguren Cardona <jaime.arangu...@gmail.com> wrote:> On 26 Feb., 23:02, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > > > gabor wrote: > > > (snip) > > > > For Spartan 3 MIG, which is primitive compared to the Virtex 5 > > > MIG, the order of row vs. bank addressing is not important. > > > This is due to the fact that the MIG code only leaves one > > > row of one bank active at any time. =A0The column address should > > > be your low order address bits for linear addressing. =A0This > > > will prevent unnecessary row precharge / activate sequences > > > when performing linear access to memory. > > > One that I might try is a video display that also refreshes > > the RAM. =A0That is an old trick that might still work. > > > > Also note that > > > the least significant bits of the column address are > > > incremented inside the memory chip during a burst operation. > > > There is no carry out to the upper address bits, so when > > > starting a burst you should normally begin at a burst > > > boundary to avoid rapping back to previous addresses. > > > I don't expect any burst operations. =A0My first system will > > be 8080 based, and I don't believe that the 8080 does bursts. > > > > Be careful when using the MIG top level interface with > > > "linear" address. =A0It may be using the least significant > > > bits for the bank address (depends on which interface > > > typeDDR, DDR2, etc.). > > > -- glen > > Hi guys, > > Going further with the thread, I want to "report" that it seems to be > working, but partially. In simulation everything goes fine, both for > writing and reading data. I generate a sequence of numbers, fill the > memory with it, and then read all the positions back, comparing with > the sequence of numbers written. If an error is found, a counter is > incremented. At the end of the read sequence, if everything goes fine, > one led should glow, if not (even a single mismatch was found, which > means the error counter is different to zero) then 6 leds glow. > > I am testing my stuff on an S3E Kit. If I just run the test for a very > few rows (say 3), then most of the times the test passes, others it > does not. If I run for higher number of rows, then at all times it > fails. So, it seems to me that I am getting timing problems. Besides, > I have to add that I am not using an external 133 MHz clock to SMA > connector, I am using the onboard 50Mhz clock instead and a couple > DCMs, one for generating a 100 MHz clock and another one to generate > the 90 degree phase shifted clock. > > Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see > that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps). > Looking into the details of the UCF, I see that this signal, which for > the S3E Starter kit is implemented as a loopback, has an assigment to > pin P13. I suppose that that is needed because of packaging to IOBs, > which is one of the project options for the MIG generated project. Is > there a way to make the signal always internal and not look for a > physical pin? > > The only way I have found to meet timing constraints was to remove > that constraint in the UCF (the one that assigns rst_dqs_div signal to > pin P13), but now another problem arises: when generating the > bitstream, it fails because DRC is not passed, saying that the signal > rst_dqs_div was assigned to bank3 which uses impedance controlled > buffers or has Vref requeriments, which rst_dqs_div does not meet. > > How can it be got to work reliably? Even the original project > generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without > modifications, fails to meet the timing constraints for signal > rst_dqs_div, which is supposed to be a critical timing signal > necessary to get the controller working correctly. > > All your comments and suggestion are very welcome. > > Kind regards.Hi, I bypassed the DRC test for bitstream generation, but results are even worse: now, most of the times it fails.... very seldom passes, even for just 3 rows. Any hint? Kind regards.
Reply by ●March 31, 20092009-03-31
On 17 Mrz., 09:58, Jaime Andr=E9s Aranguren Cardona <jaime.arangu...@gmail.com> wrote:> On 16 Mrz., 17:18, Jaime Andr=E9sArangurenCardona > > > > > > <jaime.arangu...@gmail.com> wrote: > > On 26 Feb., 23:02, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > > gabor wrote: > > > > (snip) > > > > > For Spartan 3 MIG, which is primitive compared to the Virtex 5 > > > > MIG, the order of row vs. bank addressing is not important. > > > > This is due to the fact that the MIG code only leaves one > > > > row of one bank active at any time. =A0The column address should > > > > be your low order address bits for linear addressing. =A0This > > > > will prevent unnecessary row precharge / activate sequences > > > > when performing linear access to memory. > > > > One that I might try is a video display that also refreshes > > > the RAM. =A0That is an old trick that might still work. > > > > > Also note that > > > > the least significant bits of the column address are > > > > incremented inside the memory chip during a burst operation. > > > > There is no carry out to the upper address bits, so when > > > > starting a burst you should normally begin at a burst > > > > boundary to avoid rapping back to previous addresses. > > > > I don't expect any burst operations. =A0My first system will > > > be 8080 based, and I don't believe that the 8080 does bursts. > > > > > Be careful when using the MIG top level interface with > > > > "linear" address. =A0It may be using the least significant > > > > bits for the bank address (depends on which interface > > > > typeDDR, DDR2, etc.). > > > > -- glen > > > Hi guys, > > > Going further with the thread, I want to "report" that it seems to be > > working, but partially. In simulation everything goes fine, both for > > writing and reading data. I generate a sequence of numbers, fill the > > memory with it, and then read all the positions back, comparing with > > the sequence of numbers written. If an error is found, a counter is > > incremented. At the end of the read sequence, if everything goes fine, > > one led should glow, if not (even a single mismatch was found, which > > means the error counter is different to zero) then 6 leds glow. > > > I am testing my stuff on an S3E Kit. If I just run the test for a very > > few rows (say 3), then most of the times the test passes, others it > > does not. If I run for higher number of rows, then at all times it > > fails. So, it seems to me that I am getting timing problems. Besides, > > I have to add that I am not using an external 133 MHz clock to SMA > > connector, I am using the onboard 50Mhz clock instead and a couple > > DCMs, one for generating a 100 MHz clock and another one to generate > > the 90 degree phase shifted clock. > > > Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see > > that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps). > > Looking into the details of the UCF, I see that this signal, which for > > the S3E Starter kit is implemented as a loopback, has an assigment to > > pin P13. I suppose that that is needed because of packaging to IOBs, > > which is one of the project options for the MIG generated project. Is > > there a way to make the signal always internal and not look for a > > physical pin? > > > The only way I have found to meet timing constraints was to remove > > that constraint in the UCF (the one that assigns rst_dqs_div signal to > > pin P13), but now another problem arises: when generating the > > bitstream, it fails because DRC is not passed, saying that the signal > > rst_dqs_div was assigned to bank3 which uses impedance controlled > > buffers or has Vref requeriments, which rst_dqs_div does not meet. > > > How can it be got to work reliably? Even the original project > > generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without > > modifications, fails to meet the timing constraints for signal > > rst_dqs_div, which is supposed to be a critical timing signal > > necessary to get the controller working correctly. > > > All your comments and suggestion are very welcome. > > > Kind regards. > > Hi, > > I bypassed the DRC test for bitstream generation, but results are even > worse: now, most of the times it fails.... very seldom passes, even > for just 3 rows. > > Any hint? > > Kind regards.- Zitierten Text ausblenden - > > - Zitierten Text anzeigen -Hi, I am sorry to say that this is FAR from solved... My "checker" does not work, simply because the cntrl0_data_valid_out signal does not show valid data in a Post-Translate simulation, whereas in the Behavioral Simulation it works perfect. Examining the code in the file (generated from MIG2.3) xxx_data_read_controller_0.vhd one can see this code: -- User data valid output signal from data path. fifo_0_empty <=3D '1' when (fifo0_rd_addr(3 downto 0) =3D fifo_0_wr_addr_3d(3 downto 0)) else '0'; fifo_1_empty <=3D '1' when (fifo1_rd_addr(3 downto 0) =3D fifo_1_wr_addr_3d(3 downto 0)) else '0'; read_valid_data_0_1 <=3D ((not fifo_0_empty) and (not fifo_1_empty)); read_valid_data_1_val <=3D (read_valid_data_0_1); process(clk90) begin if clk90'event and clk90 =3D '1' then if reset90_r =3D '1' then u_data_val <=3D '0'; read_valid_data_r <=3D '0'; read_valid_data_r1 <=3D '0'; else read_valid_data_r <=3D read_valid_data_0_1; read_valid_data_r1 <=3D read_valid_data_r; u_data_val <=3D read_valid_data_r1; end if; end if; end process; There is where the signal is actually generated, the other things are merely structural connections. However, in the synthesis one get the following warnings: WARNING:Xst:2677 - Node <reset90_r> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <read_valid_data_1_r> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <read_valid_data_1_r1> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_0> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_1> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_2> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_3> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_4> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_5> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_6> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_7> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_8> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_9> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_10> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_11> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_12> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_13> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_14> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_0_data_out_r_15> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_0> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_1> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_2> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_3> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_4> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_5> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_6> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_7> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_8> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_9> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_10> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_11> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_12> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_13> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_14> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <fifo_1_data_out_r_15> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_0> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_1> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_2> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_3> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_4> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_5> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_6> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_7> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_8> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_9> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_10> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_11> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_12> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_13> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_14> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_15> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_16> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_17> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_18> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_19> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_20> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_21> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_22> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_23> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_24> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_25> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_26> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_27> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_28> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_29> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_30> of sequential type is unconnected in block <data_read0>. WARNING:Xst:2677 - Node <first_sdr_data_31> of sequential type is unconnected in block <data_read0>. It looks like all what I needed is stripped down from the netlist. Does someone know how to get rid of this, and make the MIG2.3 DDR Controller work???? Thanks!
