Generally executive and senior management teams know that they can get significant cost savings, performance increases or preserve in-house IP by implementing a new idea or an existing design in an IC. However, What executive and senior management teams frequently don’t know about IC design can kill the company.  IC Design is not a trivial undertaking. Many things must be carefully considered when embarking on an effort to implement an IC as part of the companies development plan and Seattle Semiconductor can help.

Seattle Semiconductor helps companies analyze whether an IC development effort is right for for a particular business, and if so, exactly which type of IC would be appropriate. Furthermore, Seattle Semiconductor can help set the expectations of cost and schedule before the project or idea gets into the budgetary and planning phase and can help perform the costed-BOM analysis to ensure that the end product meets the required goals, whatever those goals may be.

Detailed Capabilities, Tools and Flow

The team at Seattle Semiconductor has an average of 21 years of experience doing very high performance digital IC designs on very large projects. We understand what it takes to get a project successfully from concept to completion.  Most of the team at Seattle Semiconductor started doing digital IC design in the late 1980’s and very early 1990’s and, to date, we have never taped out a device that required a re-spin due to functional design deficiency.

At Seattle Semiconductor, we understand the effort required for the verification of every device and we set the expectations with our customers that verification is the longest task in IC design.

As for design documentation, many management teams feel that time is wasted on the documentation phase of design projects. To this we must respectfully but heartily disagree. The time spent on documentation of a design up front is more than paid for when the design comes back from the foundry, on-time, on-budget and fully functional.  In our view it’s either pay-me-now or pay-me-later and we’ve seen other design teams skimp on documentation and review, tape out their designs, and then spend years trying to fix flaws that could have been (and should have been!) discovered and corrected in the documentation and design phase.

In our view, documentation is the single most important aspect of any engineering effort. It is orders of magnitude more important in IC design. Documentation defines where you are and where you are going with the project. Some customers come to us with fully defined specifications while others come to us with sketches on the backs of envelopes or on napkins. In either case we work with the customer to finalize the details. These details take the form of the following types of documentation:

• ASIC Requirements Documentation (ARD)
• ASIC Detailed Design Specification (ADD)
• ASIC Design Verification Specification (Verification pre-silicon)
• ASIC Tapeout Checklist
• ASIC Design Validation Specification (Verification post-silicon)
• Programmers Reference Manual (PRM)

Additionally, Seattle Semiconductor maintains and uses a set of documentation templates for all of the documentation required by a given project. Many of our documentation templates include macros that automate the generation of other pieces of the design flow which means that the design and the specification are never out of sync.

Implementation, Tools, and Methodology Overview

Design Entry: For design entry Seattle Semiconductor uses Verilog for all RTL Development and Seattle Semiconductor owns Cadence Incisive (NCSim) Simulator tools for design simulation and verification.

Design Verification: For Design Verification Seattle Semiconductor uses Cadence Incisive (NCSim)Verilog simulator coupled with Cadence Testbuilder high level verification modeling suite to verify customer designs. For customers with existing design infrastructure and verification suites we can, in many cases, use what is already in place. This is particularly useful for projects that are cost reductions or obsolescence proofing efforts as considerable time can often be saved through the re-use of existing infrastructure.

Logic Synthesis:   Seattle Semiconductor currently owns and uses Cadence Synthesis tools for generating gate level netlists of the design. However, realizing that many of our customers may have tools and infrastructure in place that uses other synthesis tools, we are very experienced and quite willing to use other synthesis flows that incorporate Synopsys or Magma tool suites.

Design for Test (DFT) During the synthesis phase we can insert DFT structures such as scan flops to help the manufacturing and defect management process. We can develop or use pre-existing logic BIST processes and we highly recommend that all memory instances in a design have a memory BIST collar associated with them for defect management

Post Synthesis Verification:   All gate level netlists are verified via simulation. To approximate the final physical conditions under which the device will operate, we generate artificial SDF data based on synthesis constraints and run gate level simulations on the post-synthesis netlist using the best and worst case sdf data from synthesis. This gives us an early look at the physical functionality of the device and helps us build our scripts for the time when we run detailed post-layout simulations on the design database.

Physical Design: In the case of standard cell and structured ASICs, Seattle Semiconductor works with the foundry backend teams to perform physical implementation of the customers device.  For FPGA implementations, Seattle Semiconductor uses Xilinx or Altera tools and Synplicity FPGA synthesis tools to handle synthesis, physical mapping and bitstream generation for the FPGA device.

Post Physical Verification: Seattle semiconductor performs backannotated Verilog simulations using SDF files generated by the physical implementation process.  We’ve found through experience that using timing analysis (STA) and Logical Equivalency Checking (LEC) is not enough to ensure device functionality.