The block RAMs offer high capacity and performance but are not suitable for applications that require many different small sized memories at various places on the die.
While a more mature technology, such as 0. The base structures are stockroomed until needed, with all of the customization being done in the upper metal layers. By using this development process the extra cost of purchasing DSM reticles for each new design is avoided, significantly lowering NRE cost.
Some companies that offer hybrid Structured ASIC products, such as AMI Semiconductor, use their own fabs to process the upper metal layers for each customer application.
The custom device can be developed while optimizing both cost and schedule. This quick-turn capability not only supports the critical TTM of single applications but can also be used to support entire product lines by quickly and cost-effectively producing product derivatives.
Some types of embedded IP will utilize layers in the base as well as some or all of the programmable layers, depending on the complexity and performance requirements of the IP. The programmable metal layers, M3 to M5, are a more mature technology and are used to route the custom applications.
Soft, synthesizable, IP will also be routed in these programmable metal layers. Specific data on cost, TTM, performance, capacity, power and quality is provided later in this paper when all three platforms are examined in a side-by-side comparison. Due to the economic recession, companies were particularly sensitive to product cost and TTM requirements. It was during this downward turn in the semiconductor market when the Structured ASIC technology emerged into the market.
In the last six months more than half-a-dozen companies have announced Structured ASIC product lines. Structured ASICs are primarily consumed by markets focused on complex digital designs. These include the Electronic Data Processing EDP , communication, consumer, industrial, medical, military and automotive markets.
Due to the critical nature of all of these issues, when designing SoC applications, this paper reviews them again in the framework of the Structured ASIC.
Cost is probably the number one issue, especially in light of current market conditions. There are two types of cost associated with a SoC product: development cost NRE and manufacturing cost per-unit.
What is surprising is just how fast Structured ASICs become a cost-effective solution, in terms of volume. Clearly, if the application calls for more than a few thousand units per year, FPGA high per-unit cost make it a poor choice for a hardware platform. Also, just as clear, the exorbitant NRE cost of cell-based ASIC, make it a poor choice until volumes exceed k units per year and possibly not even then, depending on the application.
Structured ASIC technology will prove to be the most cost effective solution for most applications requiring a volume between 5k and k units per year. Time-to-Market or TTM is another very important issue that has to be taken into account when starting a new SoC development project. TTM is not only critical in beating competitors to market but it also impacts the overall cost of the project.
The longer it takes getting a product to market the greater the impact to market share. Basically there is zero time from design completion to prototypes. However, if the application is going to have any significant volume, then FPGAs become too expensive. Due to its hybrid nature, a Structured ASIC can go from design completion to prototypes in less than 13 weeks, where a cell-based solution could take six months or longer.
To accomplish this one must first prototype and go into limited production using FPGA technology. Using this methodology the product is ready for the market as soon as the system is completely designed and within 13 weeks of starting limited production runs, the Structured ASIC version of the device will be ready for full production runs.
This methodology flow fits well with beta trials that most companies like to do on new products, prior to committing to full production.
Capacity is another key issue when talking about SoC design. Modern day SoC applications can easily reach into the millions of gates. Size may be the determinate factor when considering which hardware platform to utilize. There are a few suppliers that offer Structured ASIC products that support 5 to 10 million gate designs, however, in order to support cell-based type capacities, expensive leading-edge fab technologies must be used, greatly reducing the cost-effectiveness of the product.
Performance runs along the same line as capacity. Higher performance products are available but only by utilizing expensive leading- edge fab technologies. Too maintain cost-effectiveness, Structured ASIC products must lag state-of-the-art, therefore, real high performance systems will incur cost similar to a cell-based design. However, it is possible to support localized high-performance applications such as gigabit SerDes in current Structured ASIC technology with less expensive process technologies.
Hard, embedded, IP blocks with deterministic timing can be used for such applications and since only a very small portion of the design is running at max speed, the performance can be met in older technologies.
Power is another critical resource in modern SoC applications. This is especially true in the communication and consumer markets where electronic devices keep getting smaller and smaller.
The available power decreases while at the same time the complexity of the device increases. All this means that SoC designs used in such devices must conserve as much power as possible. Lower power equates to smaller less expensive power supplies, savings on board space and fewer cooling components, which all help to reduce overall cost.
Structured ASIC technology makes a good choice for a hardware platform, from a power perspective, for all but the most power stringent systems. Simply due to their field programmable nature, FPGA technology offers the greatest benefit from a design cycle-time, point-of-view. If an error is encountered in the design while testing the silicon, the designer simply needs to re-program the FPGA to execute the ECO. Soft IP is synthesizable and offers the most flexibility.
However, timing closure must be met for every application, increasing the risk of utilizing soft IP for high-performance applications. Firm IP is IP that has been synthesized into gates for the target technology. Firm IP provides less risk than soft IP but not as much flexibility. Hard IP is a block of IP that has been completely routed and timing closure on that block has been met. Sequence of events that occur when running complete selftest on the SoC.
This should be the first step in selftest verification since it helps in ironing out the issues at block level. It is not advisable to directly jump to the complete selftest cases in the beginning of verification.
Running startup offline self-test followed by shutdown self-test. Running startup self-test again after online self-test. To extend this scenario, startup, online and shutdown self-test can be run one after the other with different self-test configurations to find out some hidden issues in the design.
Health check of the SoC after completion of self-test — check self-test result registers and critical status registers, etc. Assertions can be coded for the same which can be activated for all selftest cases. Clock and glitch monitors should be present to monitor all clock domains during self-test execution.
What happens when self-test is aborted with external reset? Measure self-test time and power number for each use-case configuration. The various clock dividers of the SoC must be programmed as per the desired frequency for self-test. Any interrupt, reset event that are generated after self-test must be checked thoroughly in various combinations. This is done to mimic the behavior of LBIST scan flops at netlist level, so that most of the issues are caught before-hand.
All these cases mentioned above must be covered for startup, runtime and shutdown selftest. Any other requirement of the SoC during selftest execution needs to be verified. Road-blocks in execution of the ideal self-test verification plan and the way out There can be a lot of possible scenarios in selftest as described above; and covering each one of them is a challenge in itself — it is limited by simulation runtime and sign-off time provided.
Hence, it is advisable to focus more on customer usecases in case of selftest verification. The selection of customer use-case must be based on the following factors: a Selftest time — Ideally, the configuration should target for minimum selftest time with targeted coverage. On the other hand, running all blocks sequentially will lead to large selftest time which is again not desired for.
The ideal selftest configuration must be a compromise between both these factors. So one must fine-tune the selftest configurations as per customer requirements. It is important to think from SoC level perspective- what all events can occur when selftest is running, what are the expectations of the customer on running selftest, etc.
It is important to identify some limited number of combinations at verification level — out of these combinations, one sequence can be finalized as customer sequence based on further analysis. Smarter techniques must be employed to catch such issues before-hand, instead of solely relying on directed tests. Hence it is advisable to break it in to groups.
This adds to the simulation time woes.
0コメント