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

Hi Scott,

Yes, I'm fairly certain that changing the CPU clock will affect the EMIFA clock. By default the EMIFA and CPU clock are at a 1:3 ratio. I believe this ratio is variable though. You can find additional details in the Chapter 7 (Device Clocking) of Texas Instrument's Technical Reference Manual for the OMAPL138.

\Greg

Hi Scott,

So there is code in the linux kernel to recompute the EMIFA frequency and attempt to keep it at specified maximum frequency (which, I believe, by default, is limited to 100 MHz). Last time I checked, if you ask for 456 MHz it will update the devices to give you 456/5 or 91.2 MHz. I would measure it to be sure. The code in there is a bit weird, as TI wrote the code assuming only a NAND device would be hooked to the EMIFA. I'm not a huge fan of it at the moment, but haven't had the chance to really fool with it.

We've mentioned this elsewhere, but when you change the CPU frequency, the EMIFA clock will absolutely jump around while the switch takes place. We advise that you change the CPU frequency, then load up the FPGA and the drivers. All of our (known... :^)) customer applications do not require dynamic clock adjustment while using the FPGA. If you do, you are going to need to do some clock gating (or provide dynamic reconfiguration or a global reset function), and at a minimum make sure any DCM's or PLL's have adaptive reset logic or they will surely break lock and hang your logic. We have tried to make our drivers for CL supplied FPGA cores (uart, spi, etc.) play nice with EMIFA clocks not equal to 100 MHz (the drivers should update divisors when needed). Seems to be OK.

Sorry, it's a bit of a menace. There are alternate clock sources you might be able to select for the EMIFA that may remain stable, but that will require messing with the kernel code to configure the clock settings.

BTW: we have several applications running at 456 using the UPP, but we typically provide an external clock source for the actual UPP to FPGA interface logic (from the FPGA).

-Mike

Thanks for that explanation Mike. I asked about this because I was seeing odd behavior in my OMAP/FPGA applications. My FPGA designer was using the uPP xmit clock from the OMAP for a uPP channel back to the OMAP. He also uses the EMIFA 100 MHz clock as the main clock of our FPGA design. The things I noticed were:

• when the OMAP was running at 456 MHz I saw a lot of lost data when streaming data across uPP from the FPGA to the OMAP. According to TI this is because the uPP clock is the OMAP clock/4 or a max of 75 MHz when running at 300 MHz. I just divided down the uPP clock by 2 and those errors went away.

*When running the OMAP at 456 MHz it appeared or FPGA design was sampling analog data slightly slower than when run at 300 MHz. Your explanation above about the EMIFA clock explains to me why that happened. thanks, Scott