11 Replies Latest reply on Mar 2, 2015 6:23 AM by user_246598725

    EMIF confusion

    user_246598725

      Hi,

         

       

         

      I want to connect a 16-bit SRAM to the EMIF of a PSoC 5LP. I'm a bit confused about 8-bit transfers on a 16-bit interface.

         

      EMIF component datasheet states:

         

      "...it should not initiate 8 bit transfers to 16 bit memories"

         

       

         

      However, the 5LP technical reference manual says:

         

      "...the PSoC 5LP cannot initiate 8 bit transfers to 16-bit memories and should not initiate unaligned 16-bit or 32-bit transfers to an external memory, as  the  processor  may  convert  these  into  multiple  8  bit aligned  accesses."

         

       

         

      So, the questions are:

         

      1) in general, does it mean that for each variable where a size of 8-bit would be enough a 16-bit variable must be used when EMIF is invoked? -> so, for example, 8-bit arrays for receive buffers or similar aren't possible?

         

      2) the statement from the TRM says that the processor converts unaligned 16/32-bit transfers to 8-bit aligned ones - this could(!) be read as that the processor is able to do a 8-bit transfer... so, is it possible or not?

         

       

         

      Regards,

         

       

         

      Ralf

        • 1. Re: EMIF confusion
          user_1377889

          In the datasheet is distinguished between access by CPU or access by DMA. Your question looks a bit as if you hyve put them both together.

             

           

             

          Bob

          • 2. Re: EMIF confusion
            user_246598725

            Hi Bob,

               

             

               

            no, I don't think 've mixed them, both excerpts are from the corresponding 'CPU access' descriptions.

               

             

               

            Regards,

               

             

               

            Ralf

            • 3. Re: EMIF confusion
              user_1377889

              So best would be to create a technical MyCase

                 

              Support & Community -> Technical Support -> Create a MyCase.

                 

               

                 

              Bob

              • 4. Re: EMIF confusion
                user_385660486

                @RA1981 It looks like PSOC EMIF does not manage BLE/BHE signals usefull for 8bits access on 16bits SRAM, perhaps the limitation come from there. At least, it will be painfull (uint8 => uint16, __attribute__...) and slow (wait state due to the limited bandwidth of the EMIF) to process data located in the external memory.

                   

                I'm very interested to get the answer of the support team, did you create a "My Case" as suggested by Bob ?

                • 5. Re: EMIF confusion
                  user_246598725

                  Hi PNN,

                     

                   

                     

                  yes, I created a support ticket this morning. I asked about the following things:

                     

                  1) confirmation that 8-bit transfer on 16-bit interface is not possible

                     

                  2) behaviour of the EMIF if a 8-bit transfer is done on 16-bit interface and if it would be possible to extend the EMIF component manually with BLE/BHE signals by custom UDB implementation (e.g. depending on A0 address line)

                     

                  3) possibility to access component internal signals (generally, not EMIF related) -> for example, the BLE/BHE generation would need access to A0 line, but no one wants to route this signal externally to a free port. Since I also have to implement an address decoder logic for memory-mapped IO, it would be very nice if it can be done completely internally.

                     

                   

                     

                  I'll give feedback as soon as Cypress support responds.

                     

                   

                     

                  Regards,

                     

                   

                     

                  Ralf

                  • 6. Re: EMIF confusion
                    user_246598725

                    Current status is as follows:

                       

                    The EMIF really can only handle 16-bit data if configured as 16-bit interface, there's no way to get BLE/BHE signals to access single bytes.

                       

                    However, the answer from technical support sounds as if it would be possible to change the behaviour of the EMIF, but "this would be time consuming". So I assume(!) the EMIF functionality itself is a non-open-sourced function realized in programmable logic (otherwise they'd state that the function changes needs silicon modification).

                       

                     

                       

                    For the access of component internal signals (address signals from EMIF in this case) I asked if it would be possible to access them through the DSI by a 'transparent' working component, e.g. configure the port pin which has to be accessed and the corresponding signal is exposed to the user, so it doesn't have to be routed externally to other free ports. This question hasn't been answered yet from the support team (I assume they've to check the possibilities of the DSI).

                       

                    In general, it would be nice if Cypress would open the DSI documentation, I think it would enable the users to create even more powerful components.

                       

                     

                       

                    Regards,

                       

                     

                       

                    Ralf
                     

                    • 7. Re: EMIF confusion
                      user_71310180

                      I'm looking at doing the exact same thing. The particular SRAM I am looking at is happy with either an 8-bit or 16-bit interface. Could you do that? I can, for example, tie LB low and UB high to force an 8-bit bus. In this case the SRAM becomes byte addressable. The part I am looking to use is the AS6C3216. I'm actually going to use 2 of them to bet 8MB of RAM.

                         

                       

                         

                      Preston

                      • 8. Re: EMIF confusion
                        user_246598725

                        Hi Preston,

                           

                         

                           

                        according to the datasheet it wouldn't be enough to tie the UBE/LBE signals to fixed signals. You've to set the BYTE# input to low. Otherwise you would waste half of the memory per chip.

                           

                         

                           

                        Regards,

                           

                         

                           

                        Ralf

                        • 9. Re: EMIF confusion
                          user_385660486

                          Thanks RA1981 !

                             

                           

                             

                          Difficult to correctly handle 16 bits memory without access to the bus from the PLD. Some competitors provide access to AHB&APB signals,  it is twice the component price, only provide BGA packages (increase PCBA price) but you get 200000 LUT3 gates and can have pin compatible components with up to 1M gates.

                             

                          Using PSOC 5LP, we have to force data alignment and take it into account in source code design. IMO, it is not an issue.

                             

                           

                             

                          Regards,

                             

                          PNN

                          • 10. Re: EMIF confusion
                            user_246598725

                            IMO Cypress should open those 'buried' functions which are implemented as programmable logic, or at least provide all 'external' signals where possible (e.g. address lines in case of the EMIF, along with other signals generated internally).

                               

                             

                               

                            In general, I assume(!) that the DSI would be able to access many 'internal' signals which are useful for creation of even more powerful components, but that needs a well documented DSI description. Currently the only 'description' I know about is the register manual, but this is not enough to understand how the DSI works. Cypress should open it and provide some basic tools to work with the DSI.

                               

                             

                               

                            Regards,

                               

                             

                               

                            Ralf

                            • 11. Re: EMIF confusion
                              user_246598725

                              Hello,

                                 

                               

                                 

                              just an update from Cypress technical support:

                                 

                              1) when using EMIF, the ports are connected through the AHB bus with no option to influence by UDB or similar. So the only way is to feed back the address lines into free ports if address decoding must be done.

                                 

                              2) using a 16-bit RAM needs to access it 16-bit wise, there's no way to do 8-bit accesses.

                                 

                              3) Cypress states that those 'features' would need an redesign on chip level, so I suggested them that they should ask the users here in developers community to collect ideas for a maybe(!) future device extension.

                                 

                               

                                 

                              Regards,

                                 

                               

                                 

                              Ralf