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

Hi Brian,

Unfortunately, there is no linux side UPP driver available from TI. We have written one (it's rough) and are using it for the DSP core under DSP/BIOS for a couple of projects. The code for that is available in the more recent BSP release package. Depending on what you are trying to do, a linux side driver may not be that difficult to implement.

I think that TI has avoided writing linux drivers for uPP because the control for it is fairly application specific (e.g., data clock configuration in or out, rate, which ports used, data widths, signed or unsigned, triggering, etc.). We've always wanted the DSP to control the uPP on our projects as it is generally the processor immediately interested in the data (primarily ADC data here).

I wish I could be more help on this one. We've talked about writing a uPP linux side driver, but it hasn't been high on the priority list (BTW, I have the updates for GPIO done, need to get you the code).

-Mike

Hi Mike

You can send me the code by email.

I have downloaded the latest BSP, but haven't had the time to look at it yet.

Best regards
Brian

Hi Mike

We have discussed about the uPP port, and we have decided to try and use it in our project, due to the nice 1Gbit/s DMA transfer to the DSP. This will make our system more complex, because we use the ARM core, the DSP and the FPGA. Our dataflow would then be like this:

- FPGA to DSP via uPP port (DMA). Apprx. 20 MBit/s. FPGA should be master and initiate transmission.
- DSP to ARM core (Linux application) via DSPLink (Apprx. 20MBit/s). DSP interrupts ARM core when data is ready (nothing should be done to the data. The DSP is just a buffer).
- ARM core (Linux application) to an external PC via TCP/IP at 2kHz rate (1280bytes in each packet). TX is initiated when DSP signals data is ready (DSPLink).

The system should not do anything else (except that I also need a data path the other way for calibration, but it will only run occasionally).

Do you think it will be possible to reach these data rates, or does the MityDSP platform have some bandwidth limitations?

I hope we soon can start implementation. There has been a lot of talking about different solutions for the project...

Thanks in advance.

Best regards.
Brian

Brian,

You should not have a problem achieving the rates you mentioned above. We have accomplished similar throughput with other designs doing a similar data shuffle, but had the DSP processing data before sending it to the ARM.

The MityDSP-L138 uses x16 DDR2 running at 150 MHz. That's 600 MB/sec (2.4 Gbits/sec) burst throughput, and the bandwidth for the internal SRAMs is much higher. So you shouldn't be bottlenecked getting the data into the processor.

We have observed well over 20 MBits / second on the ethernet output using TCP, though TCP will tax your ARM CPU for packet preparation (checksum calculation, stack management, etc.).

If by different solutions you mean some other SOM, I would be curious what you end up picking if you head a different direction.

-Mike

Hi Mike

This sounds good. An additional question would be about the pin configuration for the uPP port. In the excel sheet for port pins between FPGA og uC I have noticed that some pins are shared between the uPP and the RMII ports. Also for the second uPP port and the Boot pins. Does this mean that the uPP port will only work as 8bits because the RMII port is used for ethernet connection?

I have looked in the latest board support package (I managed to open it :-)), but I have not found any FPGA module (*.vhdl) for the uPP port. Is it not available? You mentioned you have used the port above.

Best regards
Brian

Hi Brian,

For the OMAP-L138, pin-muxing is just a fact of life. If you would like to use ethernet and uPP, then it might make sense to use the MII interface instead of the RMII interface. Otherwise, there are RMII pins that do conflict with the bits DATA[15:8] of the uPP interface. Depending on what you want to do, that may not limit you from using a 16 bit interface as the XDATA[15:8] pins are not in contention with RMII. If you look at Table 3 of the UPP user guide, it is possible to use the A channel in 16 bit mode by using DATA[7:0] and XDATA[7:0] pins. However, if you need both uPP channels in 16 bit mode then you are out of luck.

We don't really have a VHDL "core" for the uPP. It's a fairly straightforward parallel interface, and it's rather project specific. For our applications, there was no software control necessary for the interface, so we didn't create any register controls for it.

-Mike

Hi Brian,

Sorry about the spam this on this thread morning. We've changed our account activation policy to require manual account approval to avoid this sort of thing in the future.

Please accept our apologies.

-Mike