Forums » Software Development »
General SW questions on the MityDSP L138F development kit
Added by Greg Wong over 11 years ago
A few general SW questions for the novice user. We are planning to use the MityDSP L138F development kit. Here are some general questions:
1. Can our development SW code run out of FLASH?
2. If not, what is the footprint our development SW code will need in RAM?
3. How much internal RAM does the OMAP contain?
4. How much cache does the device support?
5. Can the UPP core operate independently of the primary processing? (e.g. dedicated DMA handler and buffer)
6. What is contained in the NAND Flash? SW and FPGA images?
7. The documentation shows that the NOR Flash is for the boot loader only. I’m just looking for confirmation.
8. How is the clocking handled on the MityDSP? Can we drive the FPGA with an external clock source to clock data out to the external bus?
9. Do you have a schematic of the clock tree we can examine?
10. Are interrupts supported on the board? How are they connected?
Thanks in advance for your response.
Greg Wong
Replies (1)
RE: General SW questions on the MityDSP L138F development kit - Added by Michael Williamson over 11 years ago
Hi Greg,
At the risk of writing a novel, I recommend you take a peek at the following pages / sites / documents:
- MityDSP-L138F DataSheet
- MityDSP-L138F Architecture Figures
- TI's OMAP-L138 Product Page (has links to the OMAP-L138 DataSheets as well as the Technical Reference Manuals)
Short Answers to your questions:
1. Yes, NAND or NOR (depending on you size requirements), and if you have an MMC card hooked up on your baseboard, from MMC as well.
2. That really depends on if you are running an OS (linux, QNX, Windows Embedded, etc.) and what is required. Typically, the OS drives the space requirements for the ARM applications. A basic busybox linux setup could use as little as a couple of MB, but typically needs a bit more depending on what you need (typically < 64 MBytes for non-graphic intense stuff, can run off NAND). DSP code is generally less than 8 MBs operational.
3. For the details of on-chip RAM (ARM + DSP caches, additional internal SRAM) I would check the OMAP-L138 spec. The module includes options for 128 or 256 MBytes of external DDR memory.
4. I would check the L138 spec here as well for clarification, but I seem to recall the ARM using 32K data and instruction, and the DSP provides a 4-way set associative 256 KB cache / L2 RAM.
5. Yes.
6. If you buy a DevKit, the NAND will include a linux operating system to support booting the DevKit host board and exercising most of the peripherals. The NOR will include the UBL, U-Boot, a stock linux kernel that is used to boot off the NAND root filesystem. If you just buy modules, they are only programmed with the UBL and u-Boot. We don't program modules beyond that because we don't know your end application (e.g., probably don't want linux installed if your target OS will be QNX, etc.).
7. The OMAP-L138 boots from SPI NOR (first sector), so you have to at least reserve the bottom memory for the UBL and u-Boot. But the upper areas of the NOR are available for user applications (e.g., kernels or starterware applications, etc.) See the memory figure in the MityDSP-L138F Architecture Figures wiki page.
8. The OMAP-L138 CLKOUT pin (configured as the EMIFA clk) is connected to the FPGA and should be used for EMIFA based transactions to the FPGA. In addition, several of the clock pins for OMAP-L138 peripherals connected directly to the FPGA are also hooked up (e.g., the VP_CLKIN/VP_CLKOUT pins, the UPP clocks, etc.) in order to support peripheral interfacing between the FPGA and the OMAP-L138 (details about the exact pin configurations are available in the constraints files in the BSP). You can certainly bring clock signals in from the DDR/Edge connector to the FPGA (I would advise using a GCLK pin to bring the signal in) for external coherency to whatever interfaces you are working with. The FPGA is capable of sourcing several clocks to the OMAP-L138 peripherals such as the UPP, and we often use external clocks for ADC sampling and routing to the OMAP-L138 via UPP.
9. The OMAP-L138 spec really has 99 % of the clock tree information. We provide 2 clocks on board: a 24 MHz crystal feeding the OSCIN pin on the OMAP-L138, and a 32.768 KHz clock feeding the RTC_XI clock. All other clocks are derived from the OMAP-L138 clock tree (2 PLLs with several follow on dividers). I don't really have a schematic of that, is this sufficient?
10. Yes, interrupts are supported. Any pin on the OMAP-L138 that can be configured as a GPIO can generate an interrupt condition to either the ARM or the DSP. There are several connected to the FPGA directly (our framework makes use of 2, but you can use others as well) and several brought from the OMAP-L138 directly to the edge connector.
Hope this helps. It might make sense to give Tom Catalino (315-425-4045x201) or Omar Rahim (315-425-4045x208) a call here if you are are considering the MityDSP-L138F for a new design.
-Mike
