IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     
IBM PowerPC 750L/CXe/FX/GX Microprocessor Frequently Asked Questions
Related links: PowerPC 740 Microprocessor, PowerPC 750 Microprocessor, PowerPC 750CX and 750CXe Microprocessor, PowerPC 750FL Microprocessor, PowerPC 750FX Microprocessor, PowerPC 750GL Microprocessor, PowerPC 750GX Microprocessor

FAQ

This document addresses topics and questions frequently asked about the PowerPC 740, 750, 750L, CXe, 750FX and 750GX processors. This document supplements the information found in the specific Microprocessor User's Manuals and the associated hardware specifications.

Questions
Click on subject to go to topic specific questions.

  1. General 750 Family Questions
  2. 750L Specific Questions
  3. 750 CX/CXe Specific Questions
  4. 750 FX Specific Questions
  5. 750 GX Specific Questions


1. General 750 Family Questions

  1. How should the processor be configured in order to prevent illegal accesses due to speculative data loads?
  2. Is there a preferred bootstrap circuit for the processor to ensure that the limits described in the datasheet are met?
  3. Does the processor support cache locking and can the L2 be configured as a specific buffer, not just general cache memory?
  4. I don't need to use all of the BAT registers - how should unused BAT registers be programmed?
  5. Are there any other rules for programming BAT registers?
  6. How can I get information or test reports on PPC750L/CXe/FX product reliability?
  7. I am upgrading from a PPC750 to a PPC750CXe - do I need to recompile my code?
  8. I have a simple program that fills the cache with repeated read operations. Observations of bus activity during the execution of this program shows very low bus utilization - what's going on?
  9. Can you recommend a heat sink for these processors?
  10. Can these processors be used in SMP designs?
  11. Can you explain the differences/limitations of pipeline support for these processors?
  12. Do any of the IBM 750XX processors support out of order transactions?
  13. Can you explain how the QACK# signal should be wired for proper operation?
  14. The power dissipation numbers given in the datasheet cover Vdd and OVdd - what about AVdd?


2. 750L Specific Questions

  1. Is the TAU supported in the 750L?
  2. Is parity or ECC protection available on the 750L caches?
  3. What strapping options are available on the 750L?
  4. Can I use a spread spectrum clock chip with the 750L?


3. 750CX/CXe Specific Questions

  1. How many different PVR values were released for PPC750CXe?
  2. What is the latency of a L2 access?
  3. Is parity or ECC protection available on the caches?
  4. Is the PPC750CXe pin compatible with the PPC750L or PPC740L?
  5. We encountered a problem with our system controller interfacing to the 750CXe. Our bus is set to park the 60x bus on the 750CXe when no master requests it. However, sometimes the 750CXe gets an exception and we suspect for some reason it is sampling data from a transaction that is not a CPU transaction. We suspect that the 750CXe samples the parked DBG# as a qualified DBG# and believes it has bus ownership although DBG# was removed in the cycle following TS# of the other master's transaction (but was asserted again following TA#) and the 750CXE did not have a pending outstanding transaction. Is this an undocumented erratum?
  6. Can I use a spread spectrum clock chip with the PPC750CXe? What about the jitter spec?
  7. Is the TAU supported in the 750CXe?
  8. How can I set the max settling time in THRM3 when the cpu speed is 600MHz?
  9. Why did my PPC750CXe come out of reset configured for 32-bit data bus mode?
  10. What strapping options are available on the PPC750CXe?
  11. Does the PPC750CXe have a lead free package option?


4. 750FX Specific Questions

  1. What is the latency of a L2 access?
  2. Is parity or ECC protection available on the caches and can the L2 be locked?
  3. Is the PPC750FX pin compatible with the PPC750L or PPC750CXe?
  4. Can I use a spread spectrum clock chip with the PPC750FX? What about the jitter spec?
  5. Is the TAU supported in the 750FX?
  6. How can I set the max settling time in THRM3 when the cpu speed is 600MHz or higher?
  7. Can the 750FX be used with the MPC8260 acting as a bridge?
  8. What strapping options are used on the PPC750FX?
  9. Does IBM support the use of the 750FX adder card as a migration tool for processors from other vendors?
  10. What should the maximum input current be for the 750FX I/O pins?
  11. What level of RiscWatch should be used with 750FX dd2.xx?
  12. Please explain how the following Parity Errors are reported: L1 Instruction Cache Tag Memory Parity Error, L1 Data Cache Tag Memory Parity Error, L1 Data Cache Array Parity Error and L2 Tag Memory Parity Error.
  13. The description of HID2[IGRE bit] in the Chapter 2 of the 750FX user manual is misleading. Can you give a better description?


5. 750GX Specific Questions

  1. Is the PPC750GX pin compatible with the PPC750L or PPC750CXe or 750FX?
  2. Is parity or ECC protection available on the caches and can the L2 be locked?


Answers to general questions



1.1 How should the processor be configured in order to prevent illegal accesses due to speculative data loads?

A speculative data load occurs when a conditional branch is predicted incorrectly. One method of correcting this behavior is by setting the HID0 [SPD] bit =1, which disables speculative accesses to nonguarded space. A second option is to enable the G bit (guarded) for only that page/block, since disabling all speculative accesses (using HID0 [SPD]) may decrease performance. Remember that all I/O spaces should be marked as guarded to prevent unwanted interaction with external hardware due to speculative read operations.

1.2 Is there a preferred bootstrap circuit for these processors to ensure that the limits described in the data sheet are met?

No, there is no preferred bootstrap circuit for the PPC750 family of processors. The important thing to remember is that the voltage should be regulated so that it does not exceed the maximum recommended values. The appropriate method of voltage regulation should be determined by the user's final system design.Refer to the specific product datasheet for the appropriate recommended values.

1.3 Does the processor support cache locking and can the L2 be configured for use as a specific buffer, not just as general cache memory?

For the 750 processor family, the L1 caches can be locked by setting the data cache lock bit HID0 [DLOCK] and the instruction cache lock bit HID0 [ILOCK] to 1. Setting L2 cache control register L2CR [L2DO] bit to 1 selects the L2 cache data only mode. This inhibits the caching of any instructions in the L2 and the L2 cache treats all accesses from the L1 instruction cache as cache-inhibited. These accesses bypass the L2 cache with no L2 tag look-up performed. For the 750L and 750CXe, the L2 caches cannot be locked or configured so that part of the L2 can be used as a "private memory" for one specific use.

The 750FX L2 supports cache locking by way, and half of the 512K L2 can be locked by setting the appropriate bits in the L2 control register (L2CR [L2LOCK0] or L2CR [L2LOCK1] ) to 1.

The 750GX supports L2 cache locking with enhanced features. The 750GX has a 1 MB, four-way set associative internal L2 cache. The L2 configuration register has been modified to support the enhanced locking capability while preserving compatibility with the 750FX. The 750GX L2 cache can be configured with any combination of individual ways locked, have half of the ways locked, have all of the ways locked, or have all of the ways unlocked. In addition, the 750GX can be configured for instruction only mode. For more information, please refer to the application note "Differences Between the PowerPC 750GX and the PowerPC 750FX RISC Microprocessors".



1.4 I don't need to use all of the BAT registers - how should unused BAT registers be programmed?

The most recent information suggests that the recommendation for handling unused BAT registers would be to set all bits in each register to zero. This results in the setting of both the User mode valid and Supervisor mode valid bits to the invalid state, and also sets the PP bits to zero, indicating no translation for any access.



1.5 Are there any other rules for programming the BAT registers?

First, make certain that BATs are capable of defining your memory space. BATs are best suited for translating large, aligned, homogeneous areas of storage. RAM, since it holds a variety of things, doesn't always fit these criteria.Different attributes often need to be assigned to instructions in interrupt vectors, regular instructions, data, read-only data, etc.As the PPC750L and 750CXe have only 4 BAT pairs to work with, it can be impossible to properly translate these areas without moving them to aligned areas of memory (and wasting a lot of physical memory).Address spaces needing fine-grained translation control are best suited for translation by PTEs.

That said; make sure that your BATs do not overlap, that is, do not have any region covered by multiple BATs with different memory attributes, sizes, etc.

The value in the BL field determines both the size of the block and the alignment of the block in physical memory. Make sure that you chose the correct starting addresses for your block size, or else the undetermined results you'll get will create all sorts of irritating, hard to diagnose system error conditions. The values loaded in the BEPI and BRPN fields of the BATs must have as many low order zeros as there are ones in the BL field. For example, a lower BAT register set to 0x00300012 combined with an upper BAT register set to 0x00301FFF defines an incorrect configuration as the starting address of the block is set to 0x00300000 and the size of the block is 256MB, yet 0x00300000 is not aligned on a 256MB boundary.



1.6 How can I get information or test reports on PPC750L/CXe/FX product reliability?

IBM Microelectronics Manufacturing produces quarterly reports that show the test results on a per product/process basis. For example, 750CXe would be microprocessors/8SE. You can register to access these reports using this URL: https://www.ibm.com/registration/selfreg



1.7 I am upgrading from a PPC750L to a PPC750CXe or 750FX or 750GX - do I need to recompile my code?

In general, software that utilizes only user model resources (GPRs, FPRs, CR, FPSCR, etc) will not require changes, and this is true for most compiler-generated code. Some software changes are required when migrating to a 750L, 750CXe, 750FX or 750GX, but these changes are limited to the PowerPC Supervisor Model (configuration registers, cache control and memory management registers, processor version registers, etc). If you are unfamiliar with this terminology, you are encouraged to read Chapter Two of "The Programming Environments for 32-bit Microprocessors" as well as Chapter Two of the appropriate PowerPC Microprocessor User's Manual.

The PPC applications engineering team has developed an application note that deals with these issues: http://www.ibm.com/chips/techlib/techlib.nsf/techdocs/8ED18DEE10A788D287256BFE007002E6



1.8 I have a simple program that fills the cache with repeated read operations. Observations of bus activity during the execution of this program show very low bus utilization - what's going on?

It's impossible to tell exactly what is going on with the limited amount of information provided, but the PPC750CXe (like the PPC750L) does have a limitation on bus pipeline operations. The processor will drop out of pipeline mode between consecutive burst data reads and between consecutive burst instruction fetches. Cache touch instructions will also cause the processor to stop pipelining. When this happens, the address tenure of the second transaction will not begin until one to three bus clocks after the end of the data tenure of the first transaction. The PPC750FX does not have this limitation on back to back reads - it can pipeline up to two outstanding consecutive burst data reads. The 750GX has further improvements, as additional L1 and L2 cache buffers enable pipelining of up to four data cache miss operations.

1.9 Can you recommend a heat sink for these processors?

No, IBM does not make heat sink recommendations. The support team is not able to provide recommendations for heat sinks as that depend on system design issues that we are not able to control.

There is a great deal of cooling design information in the specific processor datasheets, including package thermal characteristics, thermal model for the PBGA package, and heat sink considerations such as max load values. Additional questions that designers may have such as calculating the degree of cooling required, determining the heat flow through the package, or similar questions about the thermal characteristics of these processors should be directed to the support team, at ppcsupp@us.ibm.com

If you need guidance on heat sink and thermal flow calculations, Aavid/Thermalloy and other manufacturers have very good information such as app notes and models, on their web sites. A simple Internet search will turn up dozens of references. Many of the heat sink vendors also have design services groups who will (for a fee) work with you to determine what heat sink best suits your application.



1.10 Can these processors be used in SMP designs?

750CXe/FX/GX (and other 750 processors) can work in an SMP environment; it just takes extra work in the software and OS kernel, and there will be extra bus traffic. The fundamental problem is that the cache management instructions (in particular dcbf, dcbst, dcbi) only operate on the local CPU's caches by default; they are not broadcast on the 60x bus for other processors to see unless ABE is set. Other SMP-capable PowerPC implementations broadcast these operations so they act on all caches in the system. In addition, the 750 family doesn't broadcast TLB invalidations, and it doesn't snoop instructions on the bus, so it wouldn't pick up these other operations even if they were broadcast.So using these processors in an SMP design would require having the software and OS ensure that each CPU in the system performed each of these tasks every time it needed to be done by one of the CPUs.

Basically, SMP operation can be done, but it will require a lot of software overhead, which may impact overall performance for both the kernel and user application code. As with other performance characteristics, it will depend heavily on the application.We have no quantitative data, but if two MEI processors are used without consideration to how tasks are partitioned between the processors, there will be a penalty due to shared data that will be continuously flushed out of one processor when the other processor needs it, along with the maintenance problems of tlbie and dcb operations. If tasks can be partitioned such that there is very little data sharing, then there will be correspondingly very little overhead for maintaining coherency between the two processors.



1.11 Can you explain the differences/limitations of address pipeline support for these processors?

First, we need to make sure we are all on the same page, so here are some excerpts from the 750CXe user manual section 8.2.2.

The 750CX/CXe protocol provides independent address and data bus capability to support pipelined and split-bus transaction system organizations. Address pipelining allows the address tenure of a new bus transaction to begin before the data tenure of the current transaction has finished. Split-bus transaction capability allows other bus activity to occur (either from the same master or from different masters) between the address and data tenures of a transaction.

The 750CX/CXe can pipeline its own transactions to a depth of one level...

NOTE: The 750CX/CXe drops out of pipeline mode between consecutive burst data reads and between consecutive burst instruction fetches. No other sequences of operations cause this effect. In this case, the address tenure of the second transaction will not begin until one to three bus clocks after the end of the data tenure of the first transaction.

This explains the way that the 603/e and 750/L/CX/CXe bus interface works. The ability to pipeline to a depth of one level means that the cpu can have two outstanding bus operations pending, and the text in the NOTE is intended to describe conditions where this pipelining effect will not occur. To help clarify, here is a table of possible outstanding operations and whether or not they will be pipelined:

1st TRANSACTION 2nd TRANSACTION WILL BE PIPELINED ON 60X BUS
READ READ NO
I FETCH I FETCH NO
READ I FETCH YES
I FETCH READ YES
WRITE READ YES
READ WRITE YES
WRITE I FETCH YES
I FETCH WRITE YES

If your bridge chip/system controller supports address pipelining, you can enable it for improved system performance. This will allow for pipelining to occur when ever possible, and will not cause problems as the processor has control over how many outstanding transactions it can support.

The 750X and 750GX processors do not have this restriction, which is referred to as "miss under miss" in some documentation. Refer to the appropriate User Manuals and differences documents to see how to configure these processors properly.



1.12 Do any of the IBM 750XX processors support out of order transactions?

No. An excerpt from the 750CXe User Manual (section 8.2.2) explains this limitation.

In a pipelined implementation, data bus tenures are kept in strict order with respect to address tenures. However, external hardware can further decouple the address and data buses, allowing the data tenures to occur out of order with respect to the address tenures. This requires some form of system tag to associate the out-of-order data transaction with the proper originating address transaction (not defined for the 750CX/CXe interface). Individual bus requests and data bus grants from each processor can be used by the system to implement tags to support interprocessor, out-of-order transactions.

If your bridge chip/system controller supports out of order processing, do not enable this operation, as it can cause serious data integrity problems.



1.13 Can you explain how the QACK# signal should be wired for proper operation?

For 750xx processors, QACK# must be either continuously low, or go low in response to QREQ# , in order to allow the processor to enter nap mode, to enter sleep mode, or to be soft-stopped by a JTAG debugger such as RISCWatch. In addition to this functionality, the state of QACK# is sometimes sampled at the end of hard reset to determine processor configuation. This varies from processor to processor and is discussed in the Differences Documents, and consolidated in the table below:

PROCESSOR CONFIGURATION MODE SELECTION
750L If QACK# is low at the deassertion of HRESET# , reduced pinout mode is disabled. This is the normal state for the processor. QACK# can be pulled low continuously.
750CX/CXe Reduced pinout mode is not supported on the 750CX/CXe, but there is no parity support on the 60x bus anyway. If QACK# is low at the deassertion of HRESET# , 64-bit data bus mode is selected. QACK# can be pulled low continuously.
750FX Reduced pinout mode is not supported for the 750FX. For dd1.x, if QACK# is low at the deassertion of HRESET# , 64-bit data bus mode is selected. For dd2.x, QACK# has no startup function. In either case, QACK# can be pulled low continuously.
750GX Reduced pinout mode is not supported for the 750GX. QACK# has no startup function. QACK# can be pulled low continuously.


1.14 The power dissipation numbers given in the datasheet cover Vdd and OVdd - what about AVdd?

AVdd power consumptions is 50mW (max) for all 750 family processors.

Answers to 750L specific questions


2.1 Is the TAU supported in the 750L?

Yes, however there are some issues concerning TAU accuracy. Some previous versions of the Datasheet incorrectly specified the accuracy of the Thermal Assist Unit (TAU). See the PowerPC 750-PID8p Microprocessor Errata List, Version 4.4 for details. Additionally, a Design Margin has been issued, which describes a fault in the TAU of certain dd3.2 parts, which prevents these parts from attaining the accuracy specified in the latest Datasheet. See Design Margin, PPC750L dd3.2 TAU False High for more details.

The TAU is an analog device whose accuracy can be affected by various error sources. The cumulative effect of these error sources is given in a table in the latest version of the Datasheet. IBM strongly recommends that at least a single-point calibration be performed on the TAU before use. More information on calibrating and improving the accuracy of the TAU is provided in the IBM Application Note, Calibrating the Thermal Assist Unit in the IBM25PPC750L Processors

You can find the Datasheet, Application note and Errata on our public website. The Design Margin note is considered confidential; if you don't have access to the secure document website and wish to obtain a copy, please send a request to ppcsupp@us.ibm.com .



2.2 Is parity or ECC protection available on the 750L L2 caches?

The 750L does not provide parity for L1 caches and L2 tags. The 750L does support parity on the external L2 cache. L2 parity generation and checking is enabled/disabled by setting/clearing bit 1 of the L2CR. When parity generation and checking is disabled, generated parity is always zero.

2.3 What Strapping options are available on the 750L?

Several pins are used to configure the various processor modes during start-up. When the HRESET# signal is deasserted, these pins are sampled to select the desired mode.

In the 750L, the DRTRY# signal determines whether the processor will run in "no-DRTRY#" mode. In this mode, the BIU can forward incoming data to the load/store unit one bus cycle earlier than normal because the data will not be invalidated by a succeeding DRTRY# assertion.

In the 750L, the TLBISYNC# signal is sampled at start-up to determine whether the processor will run in "32-bit data bus" mode. In this mode, only four bytes of data are transferred on the data bus at any one time, requiring two clock cycles to transfer a double word and an eight-clock burst transaction to transfer a cache line.

The BVSEL and L2VSEL pins are used to inform the processor logic of the system 60x and L2 bus interface voltage levels so the appropriate internal drivers will be used.

Pin # Signal Level PPC750L 60X bus voltage selected
W1 BVSEL floating (internal pull-up) 3.3V
W1 BVSEL tied high 3.3V
W1 BVSEL tied to HRESET# 2.5V
W1 BVSEL tied to GND 1.8V


Pin # Signal Level PPC750L L2 bus voltage selected
A19 L2VSEL floating (internal pull-up) 3.3V
A19 L2VSEL tied high 3.3V
A19 L2VSEL tied to HRESET# 2.5V
A19 L2VSEL tied to GND 1.8V


The 750L PLL is configured by the PLL_CFG [0:3] signals. For a given SYSCLK (bus) frequency, the PLL configuration signals set the internal CPU and VCO frequency of operation. Refer to the System Design Information section of the Datasheet for a complete list of PLL_CFG selections.

2.4 Can I use a spread spectrum clock chip with the 750L?

Yes, providing that certain design criteria is taken into account. Refer to the Spread Spectrum Clock Generator section of the Datasheet for detailed information and design guidelines.

Answers to 750CX/CXe specific questions


3.1 How many different PVR values were released for the PPC750CXe?

There are five values that have been released for embedded customers, one for the PPC750CX (DD2.2), and four for the PPC750CXe (DD2.4 and DD3.1). Normally there is only one PVR value released per hardware revision level, but changes in the manufacturing process resulted in PVR changes in early PQ hardware.

REV LEVEL PVR VALUE
DD2.2 00082202
DD2.4 00082214
DD2.4 00083214
DD3.1 00082311
DD3.1 00083311


3.2 What is the latency of an L2 cache access?

The latency of the L2 cache access is 1 processor clock + 3 L2 Clocks + 1 processor clock. Therefore since the L2 is operating in 1:1 mode, an instruction fetch takes 5 processor clock cycles. Cache line transfers from L2 to L1 are pipelined and take 7 cycles. Individual accesses to the L2 are not pipelined.

3.3 Is parity or ECC protection available on the caches?

Although the 750FX and 750GX provide parity for L1 caches and L2 tags, the 750CXe does not. The 750CXe does have ECC protection on the 256K L2 cache. It is always enabled, and operates in the following manner:

A three cycle finite state machine controls accesses to the L2 cache. To write into the L2 cache the address is presented on the first cycle while correct ECC codes are being generated for the data. On the second cycle the data and ECC codes are written into the L2 SRAMS and the third cycle is not used. For read access to the L2 data cache the address is presented on the first cycle. On the second cycle the SRAMS are accessed. On the third cycle the ECC codes are checked and data corrected for most single bit errors. On the fourth cycle the data is forwarded to the requesting unit. If data is uncorrectable by the ECC code a parity error and machine check is generated.



3.4 Is the PPC750CXe pin compatible with the PPC750L or PPC740L?

No, all three parts have different packages and footprints and are not pin-compatible.

3.5 We encountered a problem with our system controller interfacing to the 750CXe. Our bus arbiter is set to park the 60x bus on the 750CXe when no other master requests it. However, some times the 750CXe gets an exception, and we suspect for some reason it is sampling data from a transaction that is not a CPU.

We suspect that the 750CXe samples the parked DBG# as a qualified DBG#, and believes it has bus ownership, although DBG# was removed the cycle following TS# of the other master's transaction (but was asserted again following TA#) and the 750CXe did not have a pending outstanding transaction. Is this an undocumented erratum?

No, the 750 processor (the 750CXe is derived from the 750) design latches any DBG#. There is no distinction between a parked DBG# with no active processor address tenure and one that is intended to go with a valid processor bus access. The latched DBG# is then continuously qualified by DRTRY#, ARTRY#, and DBB#. When the 750 has both a pending data tenure and a qualified DBG#, the new data tenure begins. In your case, the parked DBG# before the other master's snoop is latched, and the instruction fetch after the snoop then provides the pending data tenure.

This is discussed in section 8.4.1.1 of the 750 User's Manual:

The DBB# signal should be connected between masters if data tenure scheduling is left to the masters. Optionally, the memory system can control data tenure scheduling directly with DBG#. However, it is possible to ignore the DBB# signal in the system if the DBB# input is not used as the final data bus allocation control between data bus masters, and if the memory system can track the start and end of the data tenure. If DBB# is not used to signal the end of a data tenure, DBG# is only asserted to the next bus master the cycle before the cycle that the next bus master may actually begin its data tenure, rather than asserting it earlier (usually during another master's data tenure) and allowing the negation of DBB# to be the final gating signal for a qualified data bus grant.

Since the 750CXe's 60x bus configuration does not support DBB#, it's critical that the bus arbiter not rely on DBB# as part of the equation for a qualified DBG#. The 750CXe implements an internal iDBB#, which is asserted on the bus clock cycle following a qualified DBG# and is negated at least one bus clock cycle after the assertion of the final TA#.

Section 8.4.1 of the 750CXe User's Manual states:

The 750CXe does not support the DBB# signal. The memory system must track the start and end of the data tenure and control data tenure scheduling directly with DBG#. The DBG# signal is only asserted to the next bus master the cycle before the cycle that the next bus master may actually begin its data tenure. The 750CXe always requires one cycle after data tenure completion before recognizing a qualified data bus grant for another data tenure.

The solution in your case is to disable bus parking or reconfigure to park the bus on another master. Additionally, if your bridge or arbiter supports configuration of "speculative DBG", then disable that feature as well. If disabling bus parking is not feasible, then perhaps a bit of bus logic can be designed to block DBG# to the 750CXe processor until a TS# assertion by the processor occurs.



3.6 Can I use a spread spectrum clock chip with the PPC750CXe? What about the jitter spec?

Short-term (cycle to cycle) jitter must not exceed +/- 150ps. If it is exceeded, the PLL might lose lock under some conditions.

But for long-term jitter, the specification is different. The kind of long-term jitter caused by a spread spectrum clock is okay, provided that:

  1. It is down spread from the maximum operational frequency, and
  2. Modulation amplitude is .5% of maximum operational frequency or less, and
  3. Modulation frequency is 30 kHz or less.

The effects of the spread-spectrum clock must be subtracted from the system timing budget, since the change in clock cycle time produces changes in the interval from one clock to the next. The system timing budget should be verified with this additional error term.



3.7 Is the TAU supported in the 750CXe?

The thermal sensor in the Thermal Assist Unit (TAU) of the 750CX/CXe has not yet been characterized to determine the basic uncalibrated accuracy. In these devices, the relationship between the actual junction temperature, and the temperature indicated by THRM1 and THRM2, is not well known. IBM recommends that the TAU in these devices be calibrated before use. Calibration methods are discussed in the IBM Application Note Calibrating the Thermal Assist Unit in the IBM25PPC750L Processors. Although this note was written for the 750L, all of the calibration methods apply to the 750CX/e. You can download this application note at:

http://www.ibm.com/chips/techlib/techlib.nsf/techdocs/730050B2CD2C7C8487256ADD0061F729



3.8 How can I select the max settling time for THRM3 when cpu speed is 600MHz?

The 750CX/CXe User's Manual advises that the SITV field of register THRM3 be configured to allow for a sampling interval of 20 microseconds. This interval is not achievable when operating the processor at higher frequencies (600MHz) so in that case the applications group recommends setting bits 18-30 of THRM3 to 1 to indicate the maximum sampling interval.

3.9 Why did the PPC750CXe come out of reset configured for 32-bit data bus mode?

Mode setting is determined by the state of the mode signal (QACK#) at the transition of HRESET# from its active to inactive state (low to high). If QACK# is low when HRESET# transitions from active to inactive, 64-bit mode is selected. If QACK# is high when HRESET# transitions from active to inactive, 32-bit mode is selected. So even if you do not user QACK# and QREQ# in your design, you need to pull down QACK# to ensure proper bus mode selection. Refer to the datasheet for more details on other signals that are sampled at power on and used to configure the processor.

3.10 What Strapping options are available on the 750CXe?

Several pins are used to configure the various processor modes during start-up. When the HRESET# signal is deasserted, these pins are sampled to select the desired mode.

The 750CX/CXe is always configured in "no-DRTRY#" mode because it does not have a DRTRY# pin. Consequently, received data cannot be invalidated on the 750CX/CXe. In this mode, the BIU can forward incoming data to the load/store unit one bus cycle earlier than normal because the data will not be invalidated by a succeeding DRTRY# assertion.

In the 750CXe, the QACK# signal is sampled at start-up to determine whether the processor will run in "32-bit data bus" mode. In this mode, only four bytes of data are transferred on the data bus at any one time, requiring two clock cycles to transfer a double word and an eight-clock burst transaction to transfer a cache line.

The BVSEL pin is used to inform the processor logic of the system 60x bus interface voltage levels so the appropriate internal drivers will be used.

Pin # Signal Level PPC750CXe 60X bus voltage selected
W1 BVSEL floating (internal pull-up) 2.5V
W1 BVSEL tied high 2.5V
W1 BVSEL tied to GND 1.8V

The 750CXe PLL is configured by the PLL_CFG [0:3 ] signals. For a given SYSCLK (bus) frequency, the PLL configuration signals set the internal CPU and VCO frequency of operation. Refer to the System Design Information section of the Datasheet for a complete list of PLL_CFG selections.



3.11 Does the PPC750CXe have a lead free package option?

Yes, the 750CXe dd3.1 version is now available for sampling in a lead free package (IBM25PPC750CXEJQxxx3T). Please contact your IBM Sales Representative for ordering information.

Answers to 750FX specific questions


4.1 What is the latency of an L2 cache access?

The latency of the L2 cache access is 1 processor clock + 3 L2 Clocks + 1 processor clock. Therefore since the L2 is operating in 1:1 mode, an instruction fetch takes 5 processor clock cycles. Cache line transfers from L2 to L1 are pipelined and take 7 cycles. Individual accesses to the L2 are not pipelined.

4.2 Is parity or ECC protection available on the caches and can the L2 be locked?

Yes, the 750FX does provide parity for L1 caches and L2 tags. Parity is always generated, and parity checking can be enabled or disabled, using bit selections in the HID2 register. Refer to the 750FX User's Manual, section 2.1.2.4 for programming details. The 750FX also has ECC protection on the 512K L2 cache. It is always enabled, and operates in the following manner:

A three cycle finite state machine controls accesses to the L2 cache. To write into the L2 cache the address is presented on the first cycle while correct ECC codes are being generated for the data. On the second cycle the data and ECC codes are written into the L2 SRAMS and the third cycle is not used. For read access to the L2 data cache the address is presented on the first cycle. On the second cycle the SRAMS are accessed. On the third cycle the ECC codes are checked and data corrected for most single bit errors. On the fourth cycle the data is forwarded to the requesting unit. If data is uncorrectable by the ECC code a parity error and machine check is generated.

The L2 cache can be locked by way; refer to the 750FX User's Manual Chapter 9 for more information.



4.3 Is the PPC750FX pin compatible with the PPC750L or PPC750CXe?

No, all three parts have different packages and footprints and are not pin-compatible.

4.4 Can I use a spread spectrum clock chip with the 750FX?

Yes, providing that certain design criteria is taken into account. Refer to the Spread Spectrum Clock Generator section of the Datasheet for detailed information and design guidelines.

4.5 Is the TAU supported in the 750FX?

The thermal sensor in the Thermal Assist Unit (TAU) of the 750FX has not yet been characterized to determine the basic uncalibrated accuracy. In these devices, the relationship between the actual junction temperature, and the temperature indicated by THRM1 and THRM2, is not well known. IBM is currently doing the characterization work necessary to bound the performance of the TAU. The results of this work are not expected to eliminate the calibration requirement, but will allow designers to make a more informed choice of calibration methods.

IBM recommends that the TAU in these devices be calibrated before use. Calibration methods are discussed in the IBM Application Note Calibrating the Thermal Assist Unit in the IBM25PPC750L Processors. Although this note was written for the 750L, all of the calibration methods apply to the 750FX. You can download this application note at:

http://www.ibm.com/chips/techlib/techlib.nsf/techdocs/730050B2CD2C7C8487256ADD0061F729

4.6 How can I select the max settling time for THRM3 when CPU speed is >600MHz?

The 750FX User's Manual (Preliminary) advises that the SITV field of register THRM3 be configured to allow for a sampling interval of 20 microseconds. This interval is not achievable when operating the processor at higher frequencies (600MHz) so in that case the applications group recommends setting bits 18-30 of THRM3 to 1 to indicate the maximum sampling interval.



4.7 Can the 750FX be used with the MPC8260 acting as a bridge?

Yes, but there are some design issues to be aware of, so the PowerPC applications team created an application note to help customers who want to use the 750FX in existing designs where a 8260 is configured as a bridge to memory and peripherals. Please contact ppcsupp@us.ibm.com to request a copy of this application note.

4.8 What strapping options are used with the 750FX?

It depends on what version of the part you are using, as the DD1.x parts have different strapping behavior from the DD2.x. The application note PPC750FX Differences Document and the Datasheets have information on strapping options for bus mode and I/O voltage selection. These documents are available now on the IBM website.



4.9 Does IBM support the use of the 750FX adder card as a migration tool for processors from other vendors?

No, The 750FX adder card is intended as a migration and evaluation tool for IBM processors only, and as such we do not guarantee or support the use of these cards with other vendor processors.



4.10 What should the maximum input current be for the 750FX I/O pins?

Approximately 20uA plus around 100uA if the keeper is opposing, which will only be for a few ns. However, if the module has been overstressed in violation its specified conditions, it can develop leakages on many pins. To obtain the latest information, please refer to the sections on DC Electrical Specification and Level protection in the latest 750FX data sheet, available on our website: http://www.ibm.com/chips/techlib/techlib.nsf/products/PowerPC_750FX_Microprocessor



4.11 What level of RiscWatch should be used with 750FX dd2.xx?

The 750FX dd2.xx revision requires RiscWatch 5.0 at a minimum. Current RiscWatch owners can request the latest software updates from ppcsupp@us.ibm.com, and customers who want to learn more about RiscWatch functionality can find information on our website: http://www.ibm.com/chips/techlib/techlib.nsf/products/RISCWatch_Debugger



4.12 Please explain how the following Parity Errors are reported: L1 Instruction Cache Tag Memory Parity Error, L1 Data Cache Tag Memory Parity Error, L1 Data Cache Array Parity Error and L2 Tag Memory Parity Error.

Parity is implemented for the following arrays: I-Cache, I-Tag, D-Cache, D-Tag and L2 Tag. All parity errors will result in a Machine Check interrupt which is not recoverable. For all of the following arrays, parity for a given set of data is a 1 if there is an odd number of 1s in the data (even parity). Parity is computed each time data is written to the arrays, independent of the Parity Checking enable/disable control bits.

The Force Bad Parity control bits (5 bits) are provided as user visible bits in the HID2 control register and control the parity bits written when the arrays are written. This is again independent of the Parity Enable/Disable control bits. The Parity Checking enable/disable control bits are provided to select when parity is to be checked for Reads by array group (L1 I-Cache & Tag, L1 D-Cache & Tag, and L2 Tag). If parity checking is enabled and bad parity is found on a Read for the enabled array, then the MSR ME bit controls the action taken by the processor for the parity error. Parity Checking can be enabled or disabled at any time in the code stream without changing the array enable/disable state and the arrays do not require invalidation.

The MSR ME bit enables the processor to take a Machine Check Interrupt allowing the operating system to determine the failing array. If this bit is not asserted, then the processor will take a Checkstop. The Parity Status bits are set at the time of the detection of bad parity only when the array Parity Enable is set. These bits are by array group (L1 I-Cache & Tag, L2 D-Cache & Tag, and L1 Tag) and are helpful for determining the problem within the machine check interrupt handler.

As a final programming reminder, the HID2 register updates are not serialized in the processor; therefore, it is strongly recommended to include an ISYNC instruction after any write to the HID2 register to insure the changes are complete before proceeding in the code stream.



4.13 The description of HID2[IGRE bit] in the Chapter 2 of the 750FX user manual is misleading. Can you give a better description?

The description in Table 2-6 of 750FX User's Manual, for Register HID2, bit 8, reads:

Isolate guarded requests on the bus. This bit prevents pipelining of guarded requests with any other requests on the bus.
To be more precise, it should read:
Isolate guarded requests on the bus. This bit prevents pipelining of guarded load requests with any other requests on the bus.


Answers to 750GX specific questions


5.1 Is the PPC750GX pin compatible with the PPC750L or PPC750CXe or 750FX?

Not with the 750L and 750CXe, but it is compatible with the 750FX. Refer to the 750GX Differences Document for more information.

5.2 Is parity or ECC protection available on the caches and can the L2 be locked?

Yes, the 750GX does provide parity for L1 caches and L2 tags. Parity is always generated, and parity checking can be enabled or disabled, using bit selections in the HID2 register. The 750GX also has ECC protection on the 1M L2 cache. It is always enabled, and operates in the following manner:

A three cycle finite state machine controls accesses to the L2 cache. To write into the L2 cache the address is presented on the first cycle while correct ECC codes are being generated for the data. On the second cycle the data and ECC codes are written into the L2 SRAMS and the third cycle is not used. For read access to the L2 data cache the address is presented on the first cycle. On the second cycle the SRAMS are accessed. On the third cycle the ECC codes are checked and data corrected for most single bit errors. On the fourth cycle the data is forwarded to the requesting unit. If data is uncorrectable by the ECC code a parity error and machine check is generated.

The L2 cache can be locked by way, just like the 750FX. However, the 750GX L2 has 4 ways and the 750FX L2 has 2 ways, so there are additional L2CR bits to program. Please refer to the 750GX Differences Document for more information.




Revision Date: 07/16/04

IBM Customer Connect
Sign in  

IBM microNews
  Feedback
Questions or comments on the technical library
  Help
Information on search and navigation

    About IBM Privacy Contact