System Trace and EMU pin usage

Ralf,

The trace clock speed on the C6678 is driven from the SYSCLK5 output from the Main PLL as discussed in section 7.5.1.1 of the Data Manual.  The default value for this is a /5 from the Main PLL rate.  It is controlled by the trace software and can be set to other rates.  The SPRU655 document recommends that the trace routing support signals up to 200MHz.  If you are running the Main PLL at 1.25GHz and measuring a 104MHz trace clock, then the SYSCLK5 divider must be set to /12.  As long as your trace routing is properly implemented, operation of trace at 104MHz should be robust.

Unfortunately, the signal integrity problems that occur with longer trace routing such as beyond 3" cannot all be resolved by reducing the clock speed.  Reflections and crosstalk will increase that can cause false clock edges to be seen which corrupts the data.  You may be able to resolve this by making changes to the series terminations but there is no guarantee of success.

The SPRU655 document shows proper diagrams for routing the JTAG and EMU[1:0] signals to multiple devices.  The trace signals EMU[n:2] must only be routed to a single DSP.  If you want to have full trace support at both DSPs, you will need multiple emulation headers.  However, high-speed parallel trace support to a single DSP should meet all of your needs.  You can still obtain low-speed trace information over the JTAG chain if needed for multiple DSPs.

The SPRU655 document does not provide clear recommendations regarding signal buffering.  Based on experiences from many customer designs, I recommend that all JTAG implementations have a separately buffered TCK to each DSP and one for RTCK back to the emulator pod.  Some options are shown in Appendix B of the SPRU655 document.

Tom

Hello Tom,

I already tried to change the SYSCLK5 divider, but it doesn't have any effect on the trace clock signal. Our original setting was /5 (250MHz), which was faster than the allowed 210MHz in the data manual. The source for the external trace clock seems to be something different, doesn't it? But if I change the main PLL multiplier, the the trace clock frequency will also change.

According to the Keyston Hardware Design Guide sprabi2b, the EMU signals can operate at up to 166Mbps. Because system trace uses DDR signaling, shouldn't the clock then be limited to 83MHz?

In a system with multiple devices, if I connect EMU[1:0] to all DSPs and EMU[n:2] to only one DSP which can use system trace, how can I setup system trace so that it doesn't use EMU[0:1]? Do I have an option in CCS, or do I have to configure some registers?

I also found some useful information about signal buffering of the regular JTAG signals:
http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide#Multiple_Devices

Thanks,
Ralf

Ralf,

The information on the WIKI site complements the SPRU655 document.  I agree with the buffered diagram for the a single target as shown in Figure 2 with TCK configuration 1.  However, for multiple DSPs, I still recommend a more conservative implementation than the one in Figure 3.  Many of these designs have reflections from the clock stubs that make the JTAG chain unreliable.  I recommend a separate buffer for each TCK and RTCK load.

My expertise is limited PCB implementation.  I will need to get someone else to help with the trace software configuration.

Tom

Thanks for your advice Tom. We are adding an additional TCK buffer for the second DSP.

I would appreciate, if someone could comment on how to change the trace configuration for the EMU pins. It doesn't make sense to implement something in hardware, if the software doesn't support it.

Ralf

Ralf,

You mentioned that you found trace control. It will bring up a tab for each traceable core in a device. To get that far you needed to select a Trace Receiver that matches the XDS you are using. Are you getting errors from Trace Control when you hit the apply button?

Regardless of the trace type, when you hit the trace control apply button, the trace sw will test the connection and select a clock rate that is compatible with the receiver you selected. Will need some more details to help you.

Which XDS are you using?

What kind of trace do you want to do (Core or System)?

Version of CCS and emupack?

Regards,

Doug

Doug,

System Trace seems to work for our existing system, but I'm not sure if it's stable.
The problem is that the data rate for the EMU signals is higher than the specified 166Mbps and I don't know how to reduce it.

For our new system, we are going to implement the "Multiple Device - Single Trace Configuration" scheme, like illustrated in figure 23 of spru655i. It allows the use of EMU0 and EMU1 for global breakpoints and cross triggers for all devices, but they are not usable for system trace. The manual suggests shifting trace to the higher EMU pins. How can I do this?

Emulator: SD XDS560v2 ETH
CCS: 5.3.0.00083
TI Emulation Pack: 5.0.946.0
TI Keystone1 Emulators: 1.0.6.0

Thanks,
Ralf

Ralf,

I am not sure where the 166Mbps number you are referencing came from. The 1.25 GHz C6678 device’s EMU pins for System Trace are rated for SCLK/5 so 250 Mbps. System Trace data is DDR (data on both edges of the clock), so at SCLK/5 that would be a 125Mhz clock. The XDS560v2 is rated to capture data up to 200Mbps with a 100Mhz clock rate. The trace sw in CCS performs a calibration process where it measures the System Trace clock rate of the C6678 and then chooses a System Trace clock divide-by-factor that will generate a data rate the XDS can reliably collect data at. In your case that should be SCLK/7 or 178.5 Mbps (89.3Mhz System Trace clock rate). So there is no control for you to manually select a clock rate. It’s all automatic.

Are you able to collect data reliably and display it with Trace Analyzer (CCS)?

The capability of moving the trace pins was not comprehended in Trace Control for STM. We are currently working through a major overhaul of the user interface, making it much easier to use. We plan to fix this oversight as part of that project. The software version you are currently using utilizes a configuration file to map the EMU pins to a specific System Trace bit. If the support to move the EMU pins for System Trace in a configuration does not show up in time for your new design, we can provide you with a custom configuration file (I assume you are currently connecting all the C6678 EMU pins that you can to the 60-pin connector).

Keep in mind that with two devices the length of your routing between the device and XDS connector may become more critical and the termination resistors must be reduced per section 19.1 of SPRU655. SPRU655 provides models of the XDS cable and we recommend that you simulate your circuit.

Regards,
Doug

Hello Doug,

thank you for the detailed explanation.

I'm not sure if data acquisition with the trace analyzer is stable. Sometimes I get data errors, but I'm not sure if they are related to the higher clock rate.

As I wrote earlier, the 166Mbps limit comes from the Keystone Hardware Design Guide sprabi2b, section 7.9.1. If the main PLL is configured for 1.25GHz core clock, the system trace clock is running at 104MHz. But if I change the PLL multiplier and reduce the core clock to 1.0GHz, the trace clock will also be reduced to 83MHz, about the same ratio.

If the trace clock divider is calculated automatically, how does the CCS trace software know at which frequency the main PLL is running?

I don't need a solution for moving the EMU pins right now, this system is still in development. Because we can't fulfill the routing requirements for system trace when connecting all EMU pins of two DSPs, the idea is to connect the upper EMU pins only to one DSP, which then could be used for system trace. We are only using a 20-pin connector.

Ralf

Now, I checked the PLLDIV5 register again.

During initialization, I set the divider to 8 (PLLDIV5 = 0x00008007). As soon as I start trace collection in CCS, the PLLDIV5 divider gets set back to 6 again. This would explain the higher trace clock frequency (1250MHz / 6 = 208.3MHz).

The CCS Trace Display shows the following in the status bar:
"Receiver Clock: 87.5 MHz, Trace Data Rate: 208.32940625 MHz"

I think it comes down to the following question: How does the trace software calculate the divider value? Does it always expect a SYSCLK1 frequency of 1.0GHz?

Thanks,
Ralf

Ralf,

I got some bad information from the designer responsible for our XDS560v2 trace receiver. The real max trace clock frequency for the XDS560v2 is 120Mhz, so a Trace Data Rate of 208.3 Mbps is well within the 250 Mbps max rate.

Sorry for the confusion,

Doug

Hello Doug,

thanks for clarification.

Maybe someone should update the documentation, it's a lot of inconsistent information out there:

• SPRU655I => System Trace max. 250 Mbps, Core Trace max. 360 Mbps
• SPRABI2B => EMU signals max. 166 Mbps
• SPRS691C => SYSCLK5 max. 210 MHz
• CCS Trace Display => Receiver Clock: 87.5 MHz, Trace Data Rate: 208.3 Mbps (inconsistent)

Ralf

Ralf,

Yes, SPRABI2B looks incorrect. For 1Ghz devices it should have been expressed as a 166Mhz clock rate or 333Mbps data rate. The max EMU pin data rate is also dependent on the type of trace. Core Trace will have a much higher operating rate than System Trace. SPRS691C may be correct. A 210 Mhz clock rate would yield a 420 Mbps data rate which is much higher then the 250Mbps max data rate the XDS560v2 can support. I will confirm.

Doug

About SPRS691C: The SYSCLK5 clock frequency seems to be divided by 2 before it's used as the trace clock. System trace configures a divider of 6 which results in a SYSCLK5 frequency of 208.3 MHz, but the measured frequency on EMU0 is 104 MHz. A limit of 250Mbps would be too high according to the Data Manual.

Ralf