C6748 ASYNC3 clock source and maximum frequency

Dean Hofstetter said:

However, we now think we are overclocking ASYNC3.  The default ASYNC3_CLKSRC in the spreadsheet is set to PLL1_SYSCLK2.  According to the C6748 Tech Manual, the power up default is PLL0_SYSCLK2.  When we change the spreadsheet to use PLL0_SYSCLK2, we now get an ASYNC3 violation (182.4MHz vs a max of 150MHz).  The C6748 datasheet does indeed have a table (page 91) noting the max frequency for ASYNC3 is 150MHz (at 1.2V).

If you reference page 136 in the Tech Manual, the table shows the ASYNC3 peripherals using PLL1_SYSCLK2 ....  WITH THE SMALL NOTE THAT SAYS IT DEFAULTS TO PLL0_SYSCLK2!

I am not sure what doc is causing the confusion. EMIFA clock is either sourced by PLL0_SYSCLK3 or a dedicated Div4p5 clock out from PLL0. The 'default' EMA_CLKSRC is correctly set to SYSCLK3 (PLL0). When using flash, you would be looking at EMIFA Async mode, max MHz for which is specified by ASYNC1 (not ASYNC3) in the table on Pg 91. 

Dean Hofstetter said:

1.  Do you agree that we are overclocking ASYNC3 with our PLL settings?

If you are running ASYNC1 (PLL0_SYSCLK3 default)  at  182.4 MHz, then you are overclocking the EMIFA module (as max for ASYNC1 is also 148 MHz @1.2V) 

Dean Hofstetter said:

2.  At 182.4MHz, we are overclocking ASYNC3 by 21.6%.  What weird behavior could we see, and did we do any damage to the chip?  We use:  UART1, SPI1, McBSP2, and TIMER64 (not sure about the TIMER).

You will not see any instant weird behavior, overclocking can show up as failures over time. Additionally the timings were closed at 148 MHz, running at higher, even though functional on "a" board, can cause failures in mass production as you vary process, temp, voltage etc.

Dean Hofstetter said:

3.  It appears we can fix the problem by setting ASYNC3_CLKSRC to use PLL1_SYSCLK2.  However that doesn't work for boot time.  Do we have to load one set of PLL settings into AISGEN(using PLL0_SYSCLK2), and then once our code is running change the PLL settings so we use PLL1_SYSCLK2?

Given the above clarifications, let me know if this is still an issue that you are not able to address via AISGEN

Dean Hofstetter said:

4.  Why on God's green Earth is the default in the spreadsheet set to PLL1_SYSCLK2 if the power up default is PLL0_SYSCLK2?

I hope this is clarified from above. Additionally , with articles, utilities on processors wiki, we intent them to used as customer ease of use tools, sometimes they do lag or get out of sync on various aspects compared to something like the datasheet and TRM which goes through periodic updates and upgrades.

Dean Hofstetter said:

5.  Can you make the documentation on page 136 in the tech manual any more confusing?

Specificity on what to improve would be more helpful. 

Regards

Mukul

Mukul, thanks for the quick reply, but I think you need to re-read my original question.  I'm not asking about ASYNC1 or the EMIFA.  My problem is with ASYNC3, which drives UART1, SPI1, McBSP1, etc.

- Dean

Dean

I indeed misread your query, sorry about that. 

Dean Hofstetter said:

The setting above gave us a "clean" sheet with no violations, so we have been using this.  However, we now think we are overclocking ASYNC3.  The default ASYNC3_CLKSRC in the spreadsheet is set to PLL1_SYSCLK2.  According to the C6748 Tech Manual, the power up default is PLL0_SYSCLK2.  When we change the spreadsheet to use PLL0_SYSCLK2, we now get an ASYNC3 violation (182.4MHz vs a max of 150MHz).  The C6748 datasheet does indeed have a table (page 91) noting the max frequency for ASYNC3 is 150MHz (at 1.2V).

If you are clocking the peripherals that belong to ASYNC3 clock domain via PLL0_SYSCLK2 (default) , which happens to  be 182.4 MHz , then you are OK ... you are *not* overclocking these peripherals. The timing closure summarized on pg 91 have more to with "clock sources" so while with PLL0_SYSCLK2 you can go upto 187.5 MHz , if you chose to source ASYNC3 peripherals with PLL1_SYSCLK2 , then max PLL1_SYSCLK2 can go is upto 150 MHz.

The issue with xls is essentially a save error, we just need to save it with the right drop down menu and upload again.

FYI, the reason you have a choice/mux for ASYNC3 peripherals to be sourced by an alt clock source (PLL1_SYSCLK2) is just to give these peripherals "immunity" from frequency scaling, because you can have a use-case where you are scaling core frequency via PLL0_SYSCLK1 etc, and would need to honor the 1:2 default requirement for PLL0_SYSCLK2 , which will mean all peripheral module frequencies will change (can cause changes in peripheral clock frequencies), so in some cases users find it useful to leverage frequency scaling, but source ASYNC3 peripherals (mostly serial ports I think) via PLL1_SYSCLK2, which typically remains unchanged as you are always maintain constant frequency for DDR2/mDDR (PLL1 is primarily for DDR2/mDDR source etc).

Hope this helps.

Regards

Mukul 

Mukul, I would love your answer to be true, however I'm still not sure.  The C6748 datasheet clearly states the max frequency for ASYNC3 (at 1.2V) is 150MHz.  Furthermore, the clocking spreadsheet shows a violation when ASYNC3 is sourced via PLL0_SYSCLK2 (when PLL_SYSCLK2 = 182.4MHz).  Using your logic, if we had the 456MHz part, and we ran it at 1.3V, we could clock ASYNC3 at 228MHz.  Changing the spreadsheet to use 1.3V only changes the max ASYNC3 to 152MHz, which matches the datasheet.

So, either your explaination is really the right answer ..or..  the C6748 datasheet is wrong for table 5-5 on page 91  .. AND..  the spreadsheet is incorrectly showing a violation.

Can we please have some other TI experts weigh in on this issue?  Brad Griffis are you out there?

- Dean

I will forward it to Mastermind Brad :) for you to get your second opinion 

You will have to trust me on this, you are just misinterpreting the ASYNC3 row in the table in the datasheet (you have an equivalent row in their for PLL1_SYSCLK2 which has the same max), and as I mentioned the table is talking clock source fmax not module fmax. 

ASYNC3 on spreadsheet will show a violation if you sourced the clock via PLL1_SYSCLK2 and exceeded 152 MHz and it will show a violation if those peripherals were fed by PLL0_SYSCLK2 at exceeded 187.5 MHz at 1.2V.

Dean Hofstetter said:

If we load the above PLL settings into AISGEN, it would appear we are overclocking SPI1 at boot, and there is no way to set the ASYNC3_CLKSRC bit inside the CFGCHIP3 register to force it over to PLL1_SYSCLK2.

I believe there is a way to do this.  AIS has a generic command called a "SET" command (also called a "Boot Table" command for some reason), which allows you to write any data to any address.  This command is described in Section 4.10 "Boot Table Command (0x58535907)" of the app note Using the OMAP-L132/L138 Bootloader.  Furthermore, this command can be inserted into the generated AIS output file.  The one limitation here is that you cannot use this feature from the GUI tool.  You instead need to use the command line tool and associated ini file (straight-forward task). 

You can get the command line version of the tool here:

http://sourceforge.net/projects/dvflashutils/files/OMAP-L138/

You then use the utility at OMAP-L138\GNU\AISUtils\HexAIS_OMAP-L138.exe for generating your AIS-formatted output.

You just call it like this:

command_prompt> HexAIS_OMAP-L138.exe my_executable.out

By default it uses the OMAP-L138.ini file sitting right next to it in order to determine PLL settings, etc.  It's in the ini file that you can insert your SET command for configuring ASYNC3 to be sourced from PLL1.  Just make sure you place the SET command before the PLL0/1 configuration in the same file.

They have an example of a SET command already in the file.  It's commented out (semicolons):

;[AIS_Set]
;TYPE = 0x00050403
;ADDRESS = 0x01E2C004
;DATA = 0x00000003
;SLEEP = 0x00000000

Hope that helps!

Nothing like a little confusion for a Friday afternoon.

Mukul, again I would love to take your word for it.  However, I'm going to need at least a couple of TI experts to agree before I'm satisfied.  BY THE WAY, ASYNC3 DOES INDEED SHOW A VIOLATION IN THE SPREADSHEET IF PLL0_SYSCLK2 IS SELECTED AND PLL0_SYSCLK2 = 182.4MHz..  Try it out yourself.  As I stated before, either you are right or the spreadsheet / datasheet is wrong.

Brad, you've begun to answer one of my questions IF we do indeed have an overclocking problem.  Mukul seems to think I'm OK, but you are already trying to give me a solution to a problem I may or may not have.  Please re-read the entire thread to see if I'm overclocking ASYNC3 or not.

Thanks, Dean

Dean,

Mukul is the guy I would talk to internally to get the "real" answer.  I trust that he knows the correct answer here.  I see your confusion with the data sheet and hopefully Mukul can make a tweak to make it more clear.

By the way, I made a bone-headed mistake when I made my last post.  There is no need to actually build HexAIS_OMAP-L138.exe from scratch.  It is shipped pre-built in the download.  I'm going to revise my previous post.  The executable is at OMAP-L138_FlashAndBootUtils_2_36\OMAP-L138\GNU\AISUtils\HexAIS_OMAP-L138.exe.  It should be very easy to copy your setup from the GUI into the OMAP-L138.ini file.  Then just add the AIS_Set command to configure CFGCHIP3 before the PLL0/1 setup and you should be all set.  If you take that path you completely avoid any possibility of running out of spec.  So whether you're running out of spec or not, this approach will be safe AND will provide you immunity from clock frequency changes on PLL0.

Best regards,
Brad

Brad, sounds like Mukul is the guy, so I'll go with his answer.  We are NOT overclocking ASYNC3, and thus need to do nothing.  However, I would like to suggest a few things TI can do to clean up this issue.  Basically, everything in current documentation / spreadsheet leads you to believe you are overclocking ASYNC3.

1.  Change the download of the clocking spreadsheet to default to PLL0_SYSCLK2 for the ASYNC3 clock source.  This will then match the power up default for the C6748.

2.  Fix the clocking spreadsheet so if PLL0_SYSCLK2 is selected as the source for ASYNC3, and PLL0_SYSCLK2 is between 150.1MHz and 187.5MHz, it doesn't generate a violation (Operating Voltage = 1.20V).  The spreadsheet also needs to be fixed for the 1.30V Operating Voltage, as PLL0_SYSCLK2 can max out at 228MHz for that voltage node.

3.  While your cleaning up the spreadsheet, look at the EXTCLKSRC drop down for PLL0.  It has BYPASS and EXT as the options.  However on the "PLL Topology" tab in the spreadsheet, EXTCLKSRC looks like it can come from PLL1_SYSCLK3  ..or..  CLKIN / OSCIN.  Does BYPASS = PLL1_SYSCLK3 or CLKIN / OSCIN?  If you re-label one of the drop downs to be PLL1_SYSCLK3, then it is much easier to follow.

4.  Somehow fix table 5-5 in the C6748 datasheet to make it clear that 187.5MHz is allowed for ASYNC3 if PLL0_SYSCLK2 is used (which is the power on default).  The current table is configured assuming you've already flipped the ASYNC3 source bit in CFGCHIP3.

5.  Somehow clarify table 7-1 in the C6748 Tech Manual.  Grouping ECAPs, UART1/2, TIMER64P2/3, eHRPWMs, McBSPs, McASP0 and SPI1 in the PLL1 section under PLL1_SYSCLK2, when that isn't the power up default, is confusing.  The way it is today, it is easy to look at that table and make a mistake.

Thanks, Dean

Fixed and uploaded a new xls , for 1,2, 3

For #4 submitted a doc update request to remove ASYNC3 from the table (as the info is already covered in PLL0/1_SYSCLK2 rows). Litbug ID: SDOCM00089350

Will need more time for #5.

Regards

Mukul

Hello all,

Where can you download the above mentioned spreadsheet?

Best regards,

David.

http://processors.wiki.ti.com/index.php/Programming_PLL_Controllers_on_OMAP-L1x8/C674x/AM18xx

- Dean

Thank you very much, that link is very helpful as I wasn't sure my values were correct.