Passive Heat Dissipation for C6678

We don't have a standard heat sink for the C6678.  Realistically the cooling solution that you will need will depend heavily on the environment in which the device will be housed and amount of power that the device is consuming.  You should calculate the power requirements with the spreadsheet found on the website and review the information in the Thermal Design Guide for Keystone Devices.  This should give you enough information to start looking at heat sink solutions. 

Josh,

There is no single answer to this question.  The thermal solution must be adapted to your system requirements.  Thermal models are provided on the C6678 web page to support this modeling.  Modeling will be required for a definative answer.  Additionally, the simple ThetaJB and ThetaJC values are contained in the datasheet to support first-order approximations.  You can use the Power Estimation spreadsheet (also on the web page) to estimate the maximum heat dissipation for your application.  You will then need to identify a heat dissipation solution such as a heat sink that will suffice for the airflow available (whether forced or convective).  This is discussed in more detail in the Thermal Design Guide for KeyStone devices on the C6678 web page.

Tom

Hello Josh,

You may consider Graphite Foam for this application.  See:

Koppers KFOAM (http://www.kfoam.com/mainsite/material.htm)

Poco Graphite (http://www.poco.com/tabid/95/Default.aspx)

Both of these are licensees of technology developed at ORNL:

http://www.ornl.gov/adm/partnerships/success_stories/led_foam.shtml

Best Regards,

-bogdan

Hi Tom,

Can you please let me know, how do I calculate the power dissipation from the Power Estimation sheet ?

As there is no direct option, should I consider some % of the consumed power as my max power dissipation ?

Is that correct ?

Can you please put some light on this.

Attached is the current sheet of my application: 7382.66AK2H14BAAWA24.xlsx

Thanks & Regards,

Nanjunda M

Thanks for the info Tom,

One doubt, the statement says, "All power consumed will be converted to heat that must be dissipated". Is this correct ?

I hope there will be some transfer/utilization of the power from the processor at any point of time. I'm I wrong ?

Regards,
Nanjunda M

Hi Mukul,

Thanks for the recommendation.

While considering the utilization we have considered the future upgrades that we may need to do with the same design in our board.

That process may utilize the resource 100% at some point of time. So is it wrong to calculate it that way ?

What would be the normal consideration of utilization for worstcase for the Processor ?

I did go through the wiki. That said, there is a possibility of 100% utilization for an intense code.

Thanks & Regards,

Nanjunda M

Hi Nanjunda

Thanks for the additional clarifications. I understand your intent and thinking, but i just want to highlight that 100% utilization are unrealistic 

Some guidance to clarify that 

1) E.g. DSP , the 100% utilization essentially would mean an IPC of 8 , that is 8 instructions every cycle 100% of the time. That is not realistic even with most optimized algorithms - do remember that 100% utilization on the power estimation tool is not equal to 100% CPU load say in a SYSBIOS CPU load graph - a CPU can be 100% busy polling for a flag or doing bunch of load/stores, but it does not mean that the CPU is executing 8 instructions per cycle every cycle...

2) DDR, memory  bandwidths, while you can use 100% again these are unrealistic, as you always have stalls, cache access, latency overheads, multiple initiators throwing traffic that is not necessarily b2b and keeping the busses utilized all the time. 

DSP, DDR are ususally where you could end up over estimating if you max out Utilization % and supersize your power supply. You will need to use some engineering judgement for what is the best way to guardband.

Usual practice I have seen is that customers will fill % utilization to the best of their knowledge and then potentially guardband it another 20%. 

These power estimation spreadsheet already take into account temperature (which you can set at the max you expect your application to run or be exposed to) and worst case silicon process (as we characterize the data using the worst case process).

You can also see the EVM pwer supply design (although they maybe over designed too, as they are usually developed prior to us having all the silicon char).

So in the end it will need you to make some system design calls, based on best understanding of the intended application and cost target (for power supply sizing)

Hope this helps. 

-----

Wiki snapshot below - I dont interpret it as saying 100% is feasible/practical 

% Utilization

Determining the utilization for the C66x CorePac is not as straightforward, so a brief guide is outlined here. The utilization for other modules is simply the percentage of the time the module spends doing something useful, versus being unused or idle. For these peripherals, the value is just the average over time. For example, if the DDR3 performs reads and writes one-quarter of the time and has no data to move for the other three-quarters of the time (though it continues to perform background tasks like refreshes), this would be considered 25% utilization.

I. The C66x CorePac utilization is not as straightforward, because there are varying degrees of use for the DSP. The spreadsheet estimates the DSP activity with respect to three levels of execution: % Signal Processing (SP) Utilization, % Control Code (CC)Utilization, and % Idle Utilization. The user can only enter  % Signal Processing Utilization and % Control Code Utilization in the power model. If the sum of % Signal Processing Utilization and % Control Code Utilization is less than 100%, then the spreadsheet assumes that the remaining percentage is Idle Utilization. The sum of SP, CC and Idle execution levels cannot exceed 100% so the user should make sure %SP + %CC is always <=100. A sum greater than 100% will result in an error pop-up. The three levels of execution are described in more detail below:

Signal Processing (SP) Utilization is used to represent scenarios with high levels of DSP activity. 100% SP activity corresponds to eight instructions fetched by the DSP and executed in parallel each DSP clock cycle, resulting in all eight functional units being active every cycle. Few DSP algorithms will achieve 100% SP utilization because this requires execution of all eight functional units every cycle with no stalls. Even intense applications do not spend all of the time executing such highly parallel code.

% Control Code (CC) Utilization is used to represent scenarios with low levels of activity. This could embody some type of task-polling loop or background task.The activity for this case represents the execution of approximately two functional units every clock cycle.

% Idle Utilization is used to represent the case in which the DSP is active, but is not doing useful work (NOP execution). This parameter cannot be explicitly entered into the spreadsheet, and is assumed to be the remaining utilization percentage when % Signal Processing Utilization and % Control Code do not sum to 100% (% Idle Utilization = 100% - % Signal Processing Utilization - % Control Code Utilization).

Note: It may not always be feasible to neatly separate or profile CPU code into signal processing or control code. For ease of use, it is recommended that the instructions per cycle (IPC) over all CPU code (i.e. both SP and CC) be used to determine utilization and attribute all of it to signal processing. For example, an average IPC of 2.4 over the entire application code is 2.4/8 = 30% utilization (since the CPU has 8 functional units that can operate in parallel). Enter 30% for SP and leave CC at 0%.

For more information about the DSP architecture, operation, or instruction set, see the C66x CPU and Instruction Set Reference Guide (SPRUGH7).

II. General note: System level issues may also reduce utilization. Although the spreadsheet will accept 100% utilization for all peripherals, this is not possible in reality. As memory and EDMA3 bandwidth is consumed, peripheral activity is throttled back due to these bottlenecks, and, therefore, 100% utilization is not achievable. In applications with a lot of memory and/or EDMA3 usage, individual module utilization numbers should be entered, while keeping this overall limitation in mind.