• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1454 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L138 PRU

Florian Pitzl
Prodigy 20 points
Other Parts Discussed in Thread: OMAP-L138

Hello,

We are currently evaluating the OMAP-L138 for a new product development. One of our options is, to use the new
PRU subsystem to communicate with a spezial external ASIC. There's no info about the PRU in the OMAP-L138
reference guide, if the PRU could access the PINMUX registers to change the state of the registermapped input/outputs.

Has somebody any experience with this new PRU feature?

  • 0
    TI__Mastermind 29011 points

    The PRU information is given at this wiki site: http://wiki.davincidsp.com/index.php/Programmable_Realtime_Unit_Subsystem.  To answer your question, yes, the PRU can access the PINMUX registers.

  • 0 in reply to Gus Martinez
    Prodigy 20 points

    Hello Gus,

    Thank you for your answer. I'll try it as soon as the ordered evalkit is on my desk...

    Is it possible to give a vague estimation how long it takes to access the PINMUX registers
    with the PRU? The documentation only mentions that accessing locations through the SCR
    takes some time...


    Reguards,
    Florian

  • 0 in reply to Florian Pitzl
    TI__Mastermind 29011 points

    Florian,

    We do not have numbers for the PRU specifically, but we can approximate with numbers that we have for the DSP config port.  The PRU and DSP config port are at a similar "distance" from the SYSCFG module which includes the PINMUX regs (see SPRUGM7 for more info on SYSCFG module and system interconnect block diagram).

    DSP:

    Writes will be about 10-20 DSP clock cycles.

    Reads will be around 30-40 DSP clock cycles.

    The PRU normally runs at half the speed of the DSP, so halve those numbers to get the PRU access latency.

    Note that access by any other master (ARM, DSP, HPI, etc.) to anything in SCR5 (again see SPRUGM7, system interconnect block diagram), will interfere with the PRU access and the access latency may vary.

    Gus

  • 0 in reply to Gus Martinez
    Prodigy 110 points

     

    >>> Writes will be about 10-20 DSP clock cycles.

    >>> Reads will be around 30-40 DSP clock cycles.

    It does not make much sense that a single  Write (SBBO) would stall the PRU. The write should just starts the writing hardware (Bus activity) in the background. Only if a subsequent SBBO or LBBO instruction occurs too early, the memory bus hardware is busy and the processor needs to be stalled (a hazard occurs).

    With Read it's more complex. A perfect processor design would not stall the PRU on a single read (LBBO). A hazard should occur only if the destination register is accessed by a subsequent instruction (or if another SBBO or LBBO).

    I do know that many processors are designed in that way. (Some even use a write FIFO of some stages to better isolate the CPU from the slower memory BUS).

    I'm going to try this out, as soon as I get a development board.(A program for that is already written.)

    In fact this (the possibility overlap Read activity with other processor work) supposedly will make the difference, weather I can use the chip (in fact an AM 1808) in the project I am planning or not. (I need to create as interface that very fast moves data from the the 180 K L3 RAM out of the chip with a propriety serial procedure).

    -Michael

     

     

  • 0 in reply to Michael Schnell
    TI__Mastermind 29011 points

    Michael Schnell said:
    It does not make much sense that a single  Write (SBBO) would stall the PRU. The write should just starts the writing hardware (Bus activity) in the background. Only if a subsequent SBBO or LBBO instruction occurs too early, the memory bus hardware is busy and the processor needs to be stalled (a hazard occurs).

    Thanks for catching this. You are absolutely right.  Writes are fire and forget, so the first write will only take a couple of cycles.  The 10-20 DSP cycle time is the total trip time for the data to land at the destination.

  • 0 in reply to Gus Martinez
    Prodigy 110 points

    Thanks a lot for the confirmation. (Even if it did take long :) )

    In fact, AFAIR, even the simulator suggests the huge stall for the write cycle. An update would be very welcome.

    I suppose the read prefetch handling (stalling the processor only if the value read from RAM into a register is actually used in a subsequent instruction ) is not implemented. unfortunately this might be critical for my future application.

    We in fact delayed the development on a planned product based the AM... processor until the next generation will be released (Cortex with PRUs and enough RAM). But finally knowing this makes my sleep better .

    -Michael