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

Hello Dene,

The base module was designed to be plugged into our framework (using the EMIF_Iface.vhd). It does do things like interrupt routing, reading of the DNA signature, and providing DCM reset logic. All of these functions are only required once in the FPGA, if at all.

If you are rewriting the EMIF interface logic, you'll probably want to pull out the pieces you want from here (the DNA and DCM logic) and put it elsewhere in your code and not use the base_module.vhd file directly.

The interrupt routing (i.e, driving the INT0 and INT1 logical pins to the OMAP-L138) could be implemented anyway you like based on your design. If you need to gang up more than 2 interrupts, then you'll need to architect a method/register to let your software guys know what interrupt source is generating the condition. You could steal from our framework if you like, but if the EMIF timings / interface is different, then the code that is there will likely need modification anyway.

The interrupts INT0 and INT1 are dedicated to the FPGA on the OMAP. How they are used is up to you. The framework provided by the base module is only necessary if you are using cores / drivers provided by CL, which you are not.

Hope this answers your questions.

-Mike

I figure there's a chance that we may want to use some of the cores/drivers in the future. Therefore, my design approach has been to reuse the existing framework components, such as EMFI_iface, MityDSP_L138_top, etc., modifying them as necessary to split off some address space, send out a few additional versions of L138 interface signals, and manage the timing for my needs. In addition, a new module will be added that interfaces to the logic, etc., on our "carrier board."
I'm pretty certain my overall approach and mods are good, but I'm lacking some information at the system level. If you could, please answer the questions in the first post; otherwise I'm kind of stuck. If you see some specific problems, by all means let me know.

Regards, Dene

Q - "Are any of the features or functions designed such that they shouldn't be duplicated in a second version of the module?"

Don't duplicate the DNA function.
Don't duplicate the IRQ function unless you have other interrupt lines to control (see below) beyond INT0 and INT1.
Don't duplicate the DCM reset function.

Q - "I'm less certain of the IRQ logic. It seems that only one instance is necessary, unless all available Interrupt sources are already assigned by Critical Link to other logic. Do you have an existing or proposed interrupt assignment list?"

The FPGA interrupt lines to the OMAP-L138 are mapped through the base-module outputs o_irq_output. There are two dedicated lines. These should be mapped to INT0 and INT1 in the UCF file (INT0 is GP6_12 on the OMAP and INT1 is GP6_13). You may choose to use other GPIO interrupt lines (e.g., unused pins from the uPP/VPIF/HPI interface pins, etc.) if you like in addition to INT0 and INT1. INT0 and INT1 are dedicated for interrupt purposes only.

The interrupt assignments (i_irq_map input vector) that get mapped to the o_irq_output signals in the base_module.vhd are assigned when you build the top level and assign an interrupt level to a core (using our framework). There is no existing assignment until you build a project and add cores. You can assign them anyway you like. The core framework (see GPIO.vhd and core_version.vhd) provides a mechanism for the software to determine what level (INT0 vs INT1) and vector (0 through 15) is used for each core in our framework via register reads.

In addition, there is also an NMI interrupt line that is currently not used by any of our framework / code.

I'm not sure if this answers your questions. If it does not, perhaps you could rephrase them?

-Mike

Mike,

Thanks, that's exactly what I was looking for. No further questions at this point.

Regards, Dene