3 Replies Latest reply on Aug 24, 2020 12:32 PM by PradiptaB_11

    QDR II+ CY7C2663KV18-550BZI Memory Test Fail

    ViRa_4650396

      Hi Team,

       

      Query regarding QDR II+ chip data read write failure.    

       

      QDR II+ Interface: Two CY7C2663KV18-550BZI (SRAM# 1 & SRAM#2) are connected with Kintex 7 FPGA part# XC7K325T-1FF900I in our board as shown in datasheet (Figure 2. Application Example)

       

       

      We have two similar boards.

       

      Issue:- QDR II+ Counter data write/read and QDR II+ Pattern (A55AA55A) data write/read fails (random failure) in board 1. While the same test run without fail in board2.

       

      Attached the QDR II+ Counter data write/read testcase fail log in attachment1 and QDR II+ Pattern (A55AA55A) data write/read testcase fail log in attachment2

       

      From the log in attachment1, it is observed that the Counter data write/read fails only at LSB C address.

       

      We are suspecting the failure is due to QDR II+ SRAM# 1 IC CY7C2663KV18-550BZI chip.

       

      Waveform for QDR Data out (channel 2) signals Q[4], Q[9], Q[10], Q[11], Q[16] & Q[17] are probed with respect to Clock K (Ball B6 in channel 4) and Read Port Select RPS# (Ball A8 in channel 3) is attached for reference.

       

      During failure, it is also observed that the RPS# is not asserted. The power supply rail (1.8V) rise time is around 136uS.

       

      IC Top Marking :      CY7C2663KV18

                                      550BZI 1825

       

      Batch Code: 1825

       

      It would be helpful if you provide solution for this.

        • 1. Re: QDR II+ CY7C2663KV18-550BZI Memory Test Fail
          PradiptaB_11

          Hi,

           

          We are evaluating all the information provided by you and will try to debug your issue together.

          Also can you let us know how many devices are failing. Did you solder other device on board 1 and checked for any failures.

          Allow me some time to read through your issue and think of some suitable solution.

           

          Thanks,

          Pradipta.

          • 2. Re: QDR II+ CY7C2663KV18-550BZI Memory Test Fail
            ViRa_4650396

            Hi Pradipta,

               

            Up to now we have faced the failure in one of our board and the failure chip is not replaced yet.

             

            Also we are operating at  300MHZ input clock (K, K#) frequency. The switching parameters are known only for clock frequency 450MHZ & 550MHZ as per Read/Write/Deselect sequence provided in datasheet Figure 6. Waveform for 2.5-Cycle Read Latency.

             

            It would be helpful to analyze further in detail of command/control/data lines, if you share the timing parameters for 300MHZ.

             

            Is there any tool recommended by cypress to calculate the time latency due to PCB trace length match for clock, address, data in, data out, control lines for SRAM 1 & SRAM 2 with respect to FPGA (In our case)

             

            Hope for earlier reply.

             

            With Regards,

            Vigneshwar Raj,

            Data Patterns India Pvt. Ltd.  

             

            • 3. Re: QDR II+ CY7C2663KV18-550BZI Memory Test Fail
              PradiptaB_11

              Hi,

               

              The 450 or 550 MHz frequency is the max frequency for the device and the datasheet parameters are measured at those frequencies. When the device is operated at any frequency below the datasheet parameters will be followed with very little changes to timing parameters. I will check if we have any tests or verification done at 300 MHz frequency and provide the parameters if present with us.

               

              We provide the IBIS model for SI analysis and Verilog model for to test the functionality of the device as per the requirement so you can use these models for your application.

              https://www.cypress.com/part/cy7c2663kv18-550bzi 

               

              Also we would like to clarify that we checked the wave forms you have provided and we see the RPS# is asserted in each of them. So we were not able to see where it is not getting asserted. Also since this is a input pin to the device the host should assert this pin low during read operations. Is the host not able to assert this pin when you observe the failure ?

               

              Regards,

              Pradipta.