Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

I don't see any technical reason why you could not use it, but it is preferable that you do not use the EMA_A_RW pin. Here is why:

The EMA_A_RW pin is connected to the FPGA RDWR_B logic signal and is used during FPGA loading (slave select mode) by the CPU. The kernel configures this pin as a GPIO pin (GP3_9) and not as an EMA_A_RW pin. The ARM fpga_ctrl.c driver uses this pin as GPIO to set the RDWR direction to write during FPGA programming operations.

After the FPGA is loaded, you could use the EMA_A_RW pin but you would need to reconfigure the pin-mux settings in the kernel or modify the fpga_ctrl.c driver to perform the pinmux reconfiguration after a successful load.

The timing we are using right now for CS5 in the u-Boot setup is:

Write Setup - 1 clock (setting = 0, the minimum)
Write strobe - 1 clock (setting = 0, the minimum)
Write hold - 1 clock (setting = 0, the minimum)

Read Setup - 1 clock (setting = 0, the minimum)
Read Strobe - 6 clocks (setting = 5)
Read Hold - 1 clock (setting = 0, the minimum)

We are also using a 100 MHz clock. For writes, you can't get the cycle time any faster.

For reads, using EMA_A_RW could shave 1 additional clock off the setup. The 6 clocks could be tightened, but our experience is that if you have a lot of registers / memories / decode space you are muxing to the output you may want the additional pipeline to propagate the data to the output pins. This is only significant if you are ganging multiple address regions (like our framework supports), but was a hard lesson learned on previous MityDSP platforms (we were 1 or two clocks short on the read cycle in some heavily loaded applications).

If you want to tune an alternate CS space, or use CS5 with your own custom logic, keep in mind you'll need to:

- update either u-boot, the kernel, or hack up a driver to modify the wait-states.
- watch for use of EMA_A_RW during FPGA configuration as mentioned above.

-Mike

Mike,

In our implementation, we already need to pass some reads and writes through to another FPGA on our "carrier board." This has the potential to be a bottleneck already, and I'm trying to design an approach that minimizes any delays. Because of this, I'm already planning on using CS5 with my custom logic, as you suggest, so I'm certain we already will have to use one of the methods you mentioned to customize the setup/strobe/hold timing no matter what. I'm already planning on using the wait1 signal so it can self optimize the timing without having to spend lots of time during integration to tweak things in between HW & SW.

That said, I do have a question regarding your post. If you use EMA_A_RW to load the Xilinx's configuration, then I'm thinking that we don't care what its value is prior to configuration, 'cause it won't have any effect on any logic, right? And after configuration, CS5 won't be activated until we want to intentionally access our "user" portion of the FPGA, at which time, we'll have had the chance to modify the usage assignment of EMA_A_RW pin to what we want. Do you agree?

Regards, Dene

Sure, as long as you don't want to reconfigure the FPGA at runtime, you could modify the usage assignment and forget about it's previous functions.

Good luck!

-Mike

Mike,

FYI I am providing software support for Dene and have reconfigured the pin-mux setting for GP3⁹ from GPIO to EMA_RNW (i.e. PINMUX7[27:24] = 1). However it appears that this signal isn't toggling when I read and write the same address. Does anybody know if any other registers must be configured?

Thank you,
David Kasper

Hi David,

The EMA_RNW signal needs to be configured as a GPIO during an FPGA program cycle (see the fpga_ctrl.c file in the ARM drivers) as it is used for controlling the R/W signal of the configuration data on the FPGA during slave select configuration cycles. If you don't allow this pin to function as a GPIO, the fpga_ctrl module will not be able to configure the FPGA.

Depending on where you are configuring this, it's configuration may be getting stomped. The kernel from CL configures this pin as a GPIO during platform initialization.

If you are re-configuring this pin after the FPGA is loaded, then it should work (though I haven't tried it here). Are you trying to squeeze clocks out of the wait states? Can you use the EMA_CS and the EMA_WE pins?

-Mike

Mike,

I understand the pin muxing requirements during the FPGA loading process versus normal operation. My question is do I need to configure any other registers besides PINMUX7 to enable ENA_RNW functionality.

Thanks,
Dave

Ah. Sorry.

According to the EMIFA Users Guide, the EMA_A_RNW is only shown as being active for SDRAM control mode. (Table 2). It may not function for straight ASYNC RAM mode.

-Mike

Is there a chance you're looking at an older version of the document? The current version at the link you provided doesn't list that signal in table 2, but rather in table 3 "EMIFA Pins Specific to Asynchronous Memory", which should be OK.

Regards, Dene

Yes. The revision I was looking at was indeed old. I don't know why the RNW pin isn't working for you. You might try posting to TI's E2E OMAP-L Support Forum as this is specific to the OMAP-L138 part itself. I will see if I can reproduce the issue here when I get a couple of minutes.

-Mike