5 Replies Latest reply on Sep 10, 2018 5:52 PM by TakahiroK_16

    tCMS timing restriction (refresh interval) implementation in Host MCU

    gapac_3691236

      Dear All,

       

      we have integrated S27KL0641DABHI023 HyperRAM with STM32L4R5ZI  MCU . ( Circuit design is complete & PCB board in fabrication phase )

       

      But while going through datasheet & application note of HyperRAM , I found following note

       

      "The host must also leave the device enough time to perform these operations by keeping the length of the accesses it makes to a safe length .

      The tCMS, CS# LOW maximum time, describes the maximum amount of time the host can access the device and still allow the self-refresh logic to operate.

       

      tCMS ~ 4us. "

       

       

      I am not getting how to fulfill this strange requirement of tCMS as main intention to use hyperram is to read/ write bulk amount of data in external ram .

      Also how to calculate time required for each read write operation in program & break operating to respect tCMS timing . it is practically impossible task as most of the time data which need to be read / write is dynamic so cant predict whether operation time will exceed 4us or not .

       

      Also situation becomes worst when Host MCU is operated with low frequency ( 8 , 16 MHz )

       

      request you to please explain how to interface HyperRAM & program for bulk data read write .

       

      Note : refer attached reference manual of Host MCU , section 19 Octo-SPI interface (OCTOSPI)

       

      Regards,

      Gaurav

        • 1. Re: tCMS timing restriction (refresh interval) implementation in Host MCU
          TakahiroK_16

          Hi Gaurav,

           

          Typical HyperBus controllers support features which automatically splits one lengthy operation to multiple ones. According to the MCU datasheet you attached, the "Communication regulation features" in page 532 seems to be that.

           

          I would show you a calculation example here. I assume that the MCU and the HyperRAM configurations like below. Please see Figure 75 in the MCU datasheet for the HyperBus protocol.

           

          CS#=L to 1st CK: 1 CK cycle

          last CK to CS#=H: 1 CK cycle

          Command cycles: 2 CK cycles

          Latency Count 1: 6 CK cycles (default)

          Latency Count 2: 6 CK cycles (default)

           

          Therefore, total 16 cycles are required excluding data transfer cycles.

           

          In case the HyperBus operates at 8MHz, number of CK cycles allowed during CS#=L is 4us / 125ns = 32.

          You can use 32 -16 = 16 cycles (32 bytes) for data transfer.

           

          Best Regards,

          Takahiro

          1 of 1 people found this helpful
          • 2. Re: tCMS timing restriction (refresh interval) implementation in Host MCU
            gapac_3691236

            Dear Takahiro ,

             

            Thanks for your help .

             

            "Communication regulation features" seems to be perfect setting for this issue .

             

            1. Please confirm , as per your calculation for 8MHz clock , we need to set max 5 count in CSBOUND register it is equal to (2^CSBOUND) . 2^5=32 .

             

            2. After setting proper value in "Communication regulation features" / CSBOUND register , can we use this external Hyperram for saving RTOS TASK Table ? Is it safe ?

             

            3. Is there any application limitation ( other than speed ) while using Hyperram same as internal RAM ?

             

             

            Thanks,

            Gaurav

            • 3. Re: tCMS timing restriction (refresh interval) implementation in Host MCU
              TakahiroK_16

              Hi Gaurav,

               

              Thanks for your reply.

               

              #1: CSBOUND=5 looks correct to me. If possible, please confirm with ST as well.

              #2 & #3: From software perspective, you can use HyperRAM as internal RAM because the HyperBus controller abstracts the hardware differences between them. In addition to the CSBOUND register in MCU side, you may need to set proper value to Configuration Register in HyperRAM. Please refer to the HyperRAM datasheet about it. Especially, in case your MCU has cache, the Wrapped Burst Length must be same as size of one cache line.

               

              Best Regards,

              Takahiro

              • 4. Re: tCMS timing restriction (refresh interval) implementation in Host MCU
                gapac_3691236

                Dear Takahiro ,

                 

                thanks for your reply . I just confirmed with ST FAE & CSBOUND is the setting required for given issue .

                 

                Also while reading Datasheet of Hyperram , under section 3.3 Read Transactions & 3.4 Write Transactions with Initial Latency

                 

                "However, some HyperBus devices may require a minimum time between the end of a prior transaction and the start

                of a new access. This time is referred to as Read-Write-Recovery time (tRWR). The master interface must start driving CS# LOW

                only at a time when the CA1 transfer will complete after tRWR is satisfied."

                 

                1. In above para i am not able to understand what is meaning of "The master interface must start driving CS# LOW only at a time when the CA1 transfer will complete after tRWR is satisfied." ? is it mean master should low CS pin after CA1 transfer & tRWR time ? if yes then how communication can start before that as CS pin will high before CA1 & tRWR ?

                 

                 

                 

                Thanks ,

                Gaurav

                • 5. Re: tCMS timing restriction (refresh interval) implementation in Host MCU
                  TakahiroK_16

                  Hi Gaurav,

                   

                  Thanks for confirming with ST about CSBOUND.

                   

                  Regarding tRWR, the description means that the master interface should keep CS pin HIGH for a certain period of time that makes CA1 transfer occurs after the tRWR. It assumes that the time between CS# LOW to CA1 is fixed so timing adjustment need to be done by CS# HIGH period.

                   

                  In the ST datasheet, TRWR bit in the OCTOSPI_HLCR register seems to control the tRWR directly.

                   

                  Best Regards,

                  Takahiro