Cross-referencing a legacy diode or MOSFET to a Good-Ark part is a parameter-window exercise, not a prefix match: the equivalent must fit the voltage, current, thermal, surge and package requirements of the application, and the datasheet is the only evidence that matters. This guide explains how to run a Good-Ark cross reference, which parameters to compare first, and where to confirm the result before the part enters the BOM.
How a cross reference should work
A cross reference works by comparing the original part’s parameter window with the candidate’s datasheet: voltage class, current at the operating temperature, thermal resistance, surge capability, package and the application’s specific requirements — not by matching the part-number prefix or the package name.
The original part number identifies the starting point, but the actual comparison is datasheet to datasheet. Two parts with similar numbers or the same package can sit at different points in the window, and two parts with different numbers can be functionally equivalent for an application. The cross-reference process starts with the original datasheet and the application’s operating point, then filters Good-Ark families by the window and confirms the candidate on its current datasheet. The result is an equivalent for the application, not a universal replacement for every use of the original part number.
Which parameters to compare first
Compare the blocking or working voltage first, then the current at the operating temperature, the thermal path, the surge capability and the package — with the switching or recovery parameters added for any application that switches at frequency.
The voltage window clears the part’s blocking requirement; the current check uses the rating at the application’s case temperature, not the 25 °C headline. The thermal path and the package decide whether the candidate fits the board and the cooling; the surge rating covers the application’s events. For a diode used in a switching converter, the recovery or forward-drop behavior matters; for a MOSFET, the gate charge, RDS(on) and SOA enter the comparison. The parameter order follows the application’s stress: the parameter that would fail the design is the one to compare first. A table of the original and candidate values, with the test conditions, makes the comparison visible and auditable.
Matching legacy part families to Good-Ark series
Legacy part families map to Good-Ark series by function and class: general-purpose axial rectifiers map to the general rectifier series, fast-recovery parts to the FRD series, Schottky parts to the Schottky families, and TVS, MOSFET, SiC and IGBT parts to their corresponding categories — with the exact match confirmed on the datasheet.
The mapping is a navigation aid, not a substitute for the datasheet comparison. A legacy 1N400x-style rectifier points to the general rectifier category; a legacy fast-recovery or Schottky part points to those families; and a TVS, MOSFET or wide-bandgap legacy part points to its category. Within the category, the voltage class and the package narrow the search. The mapping saves time by sending the buyer to the right families, and the datasheet comparison finishes the job. For parts whose function is unclear, the starting questions are the same as the selection ones: what does the circuit do with the part, and what does the application require?
The cross-reference mistakes that send the wrong part to the bench
The common mistakes are matching by prefix or package alone, ignoring the temperature condition on the current rating, comparing different test conditions, and skipping the application’s surge or switching requirement — each is avoided by comparing full windows with their conditions.
A prefix or package match proves nothing about the electrical window. The current rating must be compared at the same case temperature, and the voltage and surge values at the same conditions, or the comparison is meaningless. An application that switches at frequency needs the recovery or gate-charge comparison even when the DC window matches. The final mistake is treating the cross reference as the end of the process: the equivalent should be validated on the bench for the application’s real events, because the datasheet window and the circuit behavior can differ. The cross reference narrows the choice; the bench test confirms it.
How to confirm the equivalent before the BOM
Confirm the equivalent by comparing the full parameter windows with their test conditions, checking the package and the thermal path against the board, and validating the candidate on the bench for the application’s worst events.
The confirmation is a three-step gate: the datasheet comparison, the board fit and the bench validation. The datasheet comparison answers whether the candidate can electrically replace the original; the board fit answers whether the package, the footprint and the thermal path work; and the bench validation answers whether the part survives the application’s real surge, switching or temperature events. The bench test should run at the worst operating point, not the nominal one. A cross reference that passes all three steps is ready for the BOM; one that passes only the datasheet is a hypothesis.
| Comparison step | What to check | Evidence |
|---|---|---|
| Voltage window | Blocking/working voltage with margin | Both datasheets |
| Current and thermal | Rating at operating temperature | Derating curves |
| Surge/switching | Application events | Datasheet + bench test |
| Package | Footprint and thermal path | Board design |
Selection summary
A worked example illustrates the method: a legacy axial rectifier rated for 1 A at a 75 °C case temperature with a 1000 V class and a defined surge is being replaced. The Good-Ark search maps the function to the general rectifier family, then compares the candidate’s current at 75 °C, its blocking class, its surge at the original’s waveform and its package fit. The candidate passes the datasheet comparison and the board fit, but the bench test at the product’s inrush condition is what confirms the surge margin. The example is illustrative, but it shows that the cross reference is finished only when the datasheet, the board and the bench all agree.
The record of the comparison should include the original datasheet revision and the candidate’s revision, because a later revision of either part can change the window and invalidate the cross reference. Re-verifying the record when a revision changes keeps the BOM from silently carrying an equivalent that no longer fits.
For a BOM that spans multiple designs, the cross-reference record should also note which applications the equivalent was validated for, because an equivalent that fits one board’s thermal path and surge duty may not fit another. The application-scoped record keeps the cross reference honest across the product line.
Run a Good-Ark cross reference as a parameter-window comparison: map the legacy part to the right family, compare the voltage, current, thermal, surge and package data with their conditions, and confirm the candidate on the bench.
The equivalent is defined by the application, not by the part-number prefix. Compare the full windows, verify the board fit and validate the candidate for the real events. The part that passes the datasheet, the board and the bench is the one that belongs in the BOM.
For cross-reference requests, send the original datasheet and the application conditions through the sample and quote guide; the engineering team can map the part to the right product family and confirm the equivalent against your parameter window before samples are requested.