EMIF confusion

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

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

0 Likes
11 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi Bob,

   

 

   

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

   

 

   

Regards,

   

 

   

Ralf

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

So best would be to create a technical MyCase

   

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

   

 

   

Bob

0 Likes
Anonymous
Not applicable

@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 ?

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

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

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

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
 

0 Likes
PrMa_264311
Level 3
Level 3
First like received

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

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

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

0 Likes
Anonymous
Not applicable

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

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

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

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

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

0 Likes