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

I'm not sure that we've used the UHPI interface in any designs nor am I aware of any customers that have utilized the UHPI.

Are you interested in the MityDSP-L138 with or without the FPGA?

• For the module without the FPGA the UHPI_HINT# (OMAP-L138 Ball R16), UHPI_HRDY (OMAP-L138 Ball R17) and UHPI_DS2# (OMAP-l138 Ball T18) signals are NOT available external to the module.
• For the module with the FPGA all UHPI signals are routed to the FPGA so it's possible that they could be interfaced with but a custom FPGA would need to be written.

Can you share some details about the Host MPU you are looking to interface with and/or details about the required interface rate and signals required?

Thanks,

Alex

Thank you for your reply.

Sorry, I missed BALL R16, R17.

I found that a board with FPGA is necessary.
Is there a way to know the connection information of L138 and the FPGA in the board(board schematic etc)?

You can find the pin-out between the FPGA and the OMAP-L138 processor of the module in the Carrier Board Design Guide (Table 4):

https://www.criticallink.com/wp-content/uploads/2014/01/MityDSP-L138F-Carrier-Board-Design-Guide.pdf

Please let us know if you have any further questions.

Alex

Thank you.

I was able to check the connection information between FPGA and L138.

Could you tell me the pin wiring of ball T17 of L138?
It seems necessary to connect to power supply(1.8V or 3.3V).

Unfortunately during my initial review of the modules with and without FPGA I confused the RESETOUT (T17) pin connection for the FPGA module.

As you have found T17 from the L138 is not connected to an FPGA IO but is connected to a dedicated pin of the FPGA, V2 which is the PROGRAM_B_2 function. As shown in the Xilinx FPGA documentation (https://www.xilinx.com/support/documentation/user_guides/ug385.pdf) this pin is an input only and it's function is a "active-low asynchronous reset to configuration logic".

It currently has a 4.7K pull-up to 1.8V. Presumably when configured as an input on the OMAP-L138 (in the case of the UHPI_HAS# signal) it will always be high (due to the pull-up) at the OMAP-l138 processor and isn't controllable from the FPGA.

Alex