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

Hi Emmett,

Are you using linux or starterware? On starterware, if you are launching from u-Boot (which configures the EMIFA to have some nominal timings for CS5 space), then all you need to do is perform memory read or writes to 0x66000000 address space. The same applies for linux, but you'll need to write kernel space code and do some iomapping to deal with the virtual address space.

You should be able to test accesses using u-Boot, if you like with commands like:

md.w 0x66000000

If you need 32 bit registers, code them to decode to back to back 16 bit word access with the LS bytes on the lower address and the MS bytes on the upper address and then you should be able to use code such as:


int* paddr = (int*)0x66000100;
int reg_val = *paddr;


This will generate 2 read transactions (in order) and give you an effective 32 bit address.

DMA's should work without any special modifications. You might want to alter the EMIFA wait state settings based on your FPGA design, but if you honor the EMIFA_Iface timings, then the default ones (set by the stock u-Boot) should work.

-Mike

Hi Mike,

In the case of 32 bit transfers as described above -
Can you tell me which 16-bit value is transferred first?

I need to make VHDL to pass all 32 bits on the same clock edge to other 32-bit IP in my FPGA design.
In other words:
For a write, latch the 1st 16-bit value, then simultaneously pass the latched 1st 16-bit value concatenated with the 2nd 16-bit value.
For a read, simultaneously read the 1st 16-bit value while latching the 2nd 16-bit value, then read the latched the 2nd 16-bit value.

Thanks,
Emmett

Hi Emmet,

The processor will write or read the first (lower address) 16 bits first, followed by the upper 16 bits when configured in little endian mode.

We've been coding this way for a long time (since the TMS320C671x) and I thought that there was some language in the MegaModule User's Guide about the ordering of the DMA transactions, but I can't find it at the moment. So I can tell you that we use this form of code all the time, and it appears to work, but I can't cite the specification (though we've definitely measured/observed the behavior using chipscope, etc., on the L138). Because I can't pin it down for you, and if you are concerned about that, you'll need to have your software guys bust the 32-bit write into forced 16 bit writes to enforce the order. However, I can tell you we've been working with the assertion that the megamodule won't alter the read order on an aligned 32 bit request and so far (probably 10 independent jobs using 32 bit registers for pushing int32's or floats) have not seen any problems. Your Mileage May Vary. You might take it up with TI on their E2E, they might be able to confirm / pin it down for you. Wish I could help further.

Here is the example if you have a 32 bit register mapped to 0x66000010

signal foo : std_logic_vector(15 downto 0);
signal reg_foo : std_logic_vector(31 downto 0);

-- write decode to lower "16 bit word" @ 0x66000010
    foo(15 downto 0) <= i_DBus;

-- write decode to upper "16 bit word" @ 0x66000012
    reg_foo(31 downto 16) <= i_DBus;
    reg_foo(15 downto 0)  <= foo;