a technical newsletter for asic and fpga...
TRANSCRIPT
A Technical Newsletter for ASIC and FPGA Designers
Synplify Pro® Software Gets Extremewith Virtex-4
TheVirtex-4™ family is the newest FPGA from Xilinx. Some of the features available in the Virtex-4 are
embedded PowerPC™ 405 processors, ethernet MAC cores, 11.1Gbps serial transceivers, XtremeDSP™ slices,
pipelined block RAM, FIFOs, expanded SelectIO™ resources, and enhanced clocking resources. The Virtex-4 FPGA
family comprises three platforms optimized for specific design areas:
l Virtex-4 LX: logic applications
l Virtex-4 SX: DSP applications
l Virtex-4 FX: embedded processing and high-speed connectivity applications
The FX platform focuses on embedded designs so the platform contains up to two embedded PowerPC™ 405
processors, two Ethernet MAC cores per PowerPC, and 11.1Gbps serial transceivers. The LX is the general pur-
pose Virtex-4, whereas the SX has a higher XtremeDSP slice to logic ratio than the LX to be able to accommo-
date DSP intensive designs. The features available in the older Virtex™/Virtex-II™ families exist in the Virtex-4 family
allowing for an easier design migration. Synplify Pro software manages the inferable portions of Virtex-4 by sup-
porting the new XtremeDSP and utilizing the optional output registers of the block RAM.
The XtremeDSP forms a variety of functions similar to an ALU complete with its own opcodes (opmodes).
The XtremeDSP is capable of implementing arithmetic operations, barrel shifters, comparators, wide multiplexers,
and gates. All of these functions can be pipelined to achieve a performance of up to 500 MHz (see Figure 1 on
page 3).
In today’s market, your design doesn’t only have to be good, it has to be first to market. And while reducing
time-to-market is key, minimizing risk, managing complexity, and lowering costs is just as important.
That’s where platform ASICs come in. According to market research firm Gartner Dataquest, the
structured/platform ASIC market will experience substantial growth in the next four years. In the company’s
recent report entitled “Platform ASICs Jump-Start Market,” Bryan Lewis, research vice president and chief semi-
conductor analyst, contends that: “ASIC platforms have the potential to jump-start the ASIC industry because
they can now serve an increasing number of customers that had been left behind because of the rapidly rising
design costs of traditional ASICs.” In addition, Gartner Dataquest predicts there will be more than 1,000 struc-
tured/platform ASIC design starts by 2007, representing 25 percent of all ASIC design starts.
The explosive growth in platform ASICs has also caught the attention of an ever-increasing list of third-party
providers. Through the new RapidChip Partner Program, LSI Logic and its partners are creating a diverse, expand-
ing environment of third-party EDA tool companies, intellectual property (IP), and design services providers that
are extending the capabilities of RapidChip® platform ASICs and helping OEMs reduce time-to-market, minimize
design risk, and lower the costs of innovating new products.
Banding Together to Build BetterSolutions
Volume 4, Issue 4
The Synplicity® Product Philosophy . . . 2
Synplify Pro® Software Gets Extreme with Virtex-4 . . . . . . . . . . . . . . . . . . . 1
Debugging of an Internet Packet SchedulerUsing Identify® Software . . . . . . . . . 5
Equivalence Checking Synplify Pro® Synthesis:Accelerating Verification and Ensuring Quality . . . . . . . . . . . . . . . . . . . 6
Banding Together to Build Better Solutions . . . . . . . . . . . . . . . . . . 1
Simplify 90-nm Design with NEC Electronics’ISSP90 Family of Structured ASICs . . . . 10
Tips and Hints . . . . . . . . . . . . . . . 12Synplicity Training Classes . . . . . . . . 13Synplicity Events Calendar . . . . . . . . 13
“Virtex-4” continued on page 3
“Banding Together” continued on page 9
by Steve Elzinga, Sr. Product Application Engineer, and Peter Lin, Sr.Technical Marketing Engineer, Xilinx, Inc.
by Diana Hodges, Communications Manager, LSI Logic
Synplicity is now more than 10 years old. When we started the company, the biggest FPGAs were
around 20K gates. 90% of FPGAs were designed with schematics. We were certain that over the next several
years that the bulk of the expanding market would transition to HDL-based design. We wanted that to happen
as quickly as possible, so we started thinking about the implications for our first product.
Historically, EDA tools haven’t done so well on the “A” (or Automation) part. There always seems to be a
reason to add an additional option/switch/dial to the tool. We find, for example, that common operations for
an ASIC synthesis tool, like buffering high fanout nets, are often accomplished with convoluted scripts written
by the end user. The tools essentially consist of a toolbox of useful operations and a programming language
where the user can build their own automation.
These kinds of tools were completely appropriate when the cost of engineering salaries was far less than the
cost of the silicon they could save. These days are gone.
Returning to our early days… FPGAs forced us to rethink this position. Essentially, FPGAs and now struc-
tured/platform ASICs trade silicon for a simpler, lower risk design flow. Synplicity had to match the philosophy
of the tools to the philosophy of the silicon. We had to exchange the toolbox tool philosophy for automated
flows and customized interfaces to the back-end tools of the FPGA vendors.
By making the tools simple to use (what was going on under the hood was definitely not simple), we thought that we could accelerate the transition to
synthesis-based FPGA design.
We examined the true cost of each option we added to the tool: documentation, testing, training, and the probability that the option would be misused, and
we came to the conclusion that even if the tools didn’t always make the best possible decision, that it was better to automate than to ask the designer for help.
Automated tools are easier to test since they will automatically invoke new features in combination with other options, giving better test coverage. Options
also pile up like barnacles, becoming inappropriate as silicon technologies change and new algorithms are introduced. These barnacles eventually slow tool
development. Another problem with tool options is that they often don’t get enabled or even get enabled in the wrong situations because the function is
obscure.
So, when a Synplicity tool doesn’t get the best result, don’t ask us to add a switch so you can force the result you want. Ask us to really think about it and
find a way to get the good result quickly and automatically!
Summary of the Synplicity Tool Philosophyl It is better for an optimization to be automated and right most of the time than be controlled by an option.
l Options and controls should tell the tool what the desired result is, not how to get it.
l Keep tools fast. Fast runtimes allow a tool to be simpler. Many tool options fundamentally compensate for slow execution.
l Engineers read manuals only as a last resort. Don’t make them do it.
2
The Synplicity® Product Philosophy
Editor’s Note: Technically Speaking is a quarterly feature for Syndicated that will feature an article written by KenMcElvain. Ken will discuss his thoughts on a specific synthesis topic.
Ken McElvain, Founder and CTO of Synplicity, Inc.
Inference of the XtremeDSP slice for a multiply function is done by using the multiply opera-
tor:
VHDL Verilog
prod <= a * b; assign prod = a * b;
By default, Synplify Pro software will put multiply functions into the XtremeDSP. If you do not
want to use the XtremeDSP then you can pass a synthesis directive:
VHDL Verilog: assign prod = a*b /*synthesis
syn_dspstyle = "logic"*/;attribute syn_dspstyle : string;attribute syn_dspstyle of prod : signal is "logic";::
beginprod <= a * b;
To make use of the XtremeDSP for a MACC, the HDL code would be:
VHDL Verilogp_tmp <= p_reg + (a * b); assign p_tmp = p + (a * b);process(clk) is always@(posedge clk) beginbegin if (p_rst) p <= 0;
if rising_edge(clk) then else if (p_ce) p <= p_tmp;if p_rst = '1' then end
p_reg <= (others => '0');elsif p_ce = '1' then
p_reg <= p_tmp;end if;
end if;end process;p <= std_logic_vector(p_reg);
The block RAM in Virtex-4 has been enhanced from the Virtex/Virtex-II block RAM. Some of the enhancements to the Virtex-4 block RAM are:
l Cascadable creating a fast 32Kb x 1 block memory
l Byte-wide write enable
l Can be configured as a FIFO
l Pipelined output registers
Of the new features available, only the output registers will be discussed.
The output registers are inferred by using an intermediate signal for the data out of the RAM ('do' in the above examples). Replace the signal 'do' s
process/always blocks above with a signal of the same type 'do_aux' and then register 'do' to infer the block RAM with the output pipeline registers:
VHDL Verilogprocess (clk) always @(posedge clk)begin begin
if rising_edge(clk) then if (out_en) if out_en = '1' then do <= do_aux;
do <= do_aux; endend if;
end if;end process;
3Synd ica ted i s onl ine at www.synpl ic ity.com/syndicated/
“Virtex-4” continued from page 1
“Virtex-4” continued on page 4
Figure 1: XtremeDSP Architecture
Figure 2: Block RAM Inference
4
“Virtex-4” continued from page 3
With the inference that Synplify Pro software can do for Virtex-4, the above inference
examples can be put together to form a very simple MACC FIR filter as shown in Figure 3.
To make the MACC FIR filter Synplify Pro software will need to be able to infer a
pipelined MACC along with dual port block RAM, both of which the Synplify Pro tool can
do. The outputs of the RAM will feed the inputs of the MACC, the MACC load is fed into
a 4-delay shift register, which will fit nicely into a SRL. The RAM is shown in Figure 4.
The XtremeDSP contains two internal registers on the 'A' and 'B' ports, on the output of the multiplier, and on the output of the adder as shown in Figure 3.
The following HDL uses these registers:
VHDL Verilogprocess(clka) always @(posedge clka)begin begin
if rising_edge(clka) then if (macc_rst) beginif macc_rst = '1' then a_reg <= 0;
a_reg <= (others => '0'); b_reg <= 0;b_reg <= (others => '0'); m_reg <= 0;m_reg <= (others => '0'); p_reg <= 0;p_reg <= (others => '0'); p_out <= 0;p_out <= (others => '0'); end
else else begina_reg <= a_in; a_reg <= a_in;b_reg <= b_in; b_reg <= b_in;m_reg <= a_reg * b_reg; m_reg <= a_reg * b_reg;if macc_load = '1' then p_reg <= p_reg + m_reg; p_reg <= macc_load ? (p_reg + m_reg) : m_reg;else p_out <= p_reg;
p_reg <= m_reg; endend if; endp_out <= std_logic_vector(p_reg);
end if;end if;
end process;
Using the Virtex-4 mapping enhancements in the Synplify Pro solution, a relatively straightforward MACC FIR filter can be created. For a complete code list-
ing of the MACC FIR Filter found in this article, please refer to Xilinx®‚ Answer Record 20045.
NOTICE OF DISCLAIMER: Xilinx is providing this design, code, or information as is. By providing the design, code, or information as one possible implementation of this feature, applica-
tion, or standard, Xilinx makes no representation that this implementation is free from any claims of infringement. Your are responsible for obtaining any rights you may require for your imple-
mentation. Xilinx expressly disclaims any warranty whatsoever with respect to the adequacy of the implementation, including but not limited to any warranties or representations that this imple-
mentation is free from claims of infringement and any implied warranties of merchantability of fitness for a particular purpose.
Figure 3: Single-Multiplier MACC FIR Filter
Figure 4: Dual Port Pipelined Block RAM
Correct operation of circuits that perform complex Internet packet processing functions in hardware is hard to verify. Such circuits must properly
respond to data with random bit errors, packet retransmissions, and traffic with unpredictable delays. For a network device that process data at 2.8
Gigabits/second, more than 10 Terabytes of data can be processed per day. When an error occurs after several days of processing, it can be nearly impossible
to recreate the error because it would take years to simulate all of the data.
Synplicity’s Identify tool was used to debug a packet scheduler implemented in reconfigurable hardware on the Field-programmable Port Extender (FPX)
Platform [EHW’01]. Rather than simulating the system with sample input data, actual live network traffic was used to test the circuit in real-time. Using the
Identify tool, the debugging was performed without degrading the performance of the circuit on the FPX (an FPGA-based network-processing platform) or
changing the behavior of the packet scheduler [RECONFIG’04].
Synplicity’s Identify tool effectively instantiated a full logic analyzer within the logic of an FPGA. Once signals in the packet scheduler were selected, Identify
software automatically added a small amount of extra logic within the FPGA circuit to track the values of signals, trigger on suspect network events, and imple-
ment hardware break points.
The Packet Scheduler
The packet scheduler on the FPX provides Quality of Service (QoS) for traffic passing through a Gigabit/Second network [FPL’03]. When a packet first
enters the circuit, it is processed by a set of layered Internet protocol wrappers to segment and reassemble frames; verify and compute checksums; and, read
and write the headers of the Internet packet. A Ternary Content Addressable Memory (TCAM) classifies the packet based on the source address, destination
address, source port, destination port, and protocol of the arriving packet. The result is a flow identifier (Flow ID) that is used by a queue manager to either
drop the packet or have the packet buffered.
In order to buffer large amounts of traffic, the packet scheduler stores packets in off-chip Synchronous DRAM (SDRAM). When the packet scheduler deter-
mines a packet should be transmitted, data is read from SDRAM, processed by the layered protocol wrappers, and then sent to a Gigabit Ethernet line card. A
second FPGA on another FPX was used to monitor and gather statistics on the traffic that included the flow’s throughput, number of packets transmitted, aver-
age packet length, jitter, and latency. All data processing functions on the FPX are performed on a Xilinx Virtex
2000E device synthesized with Synplicity‘s Synplify Pro® tool.
Troubleshooting with a Logic Analyzer
In the initial implementations, it was found that some packets passing through the scheduler were drop or cor-
rupted. Initially, debugging was performed using a logic analyzer connected to test pins of the FPX platform. A pho-
tograph of the FPX platform connected to the logic analyzer is shown in Figure 1. Because only 32 test pins were
available to the logic analyzer and because conditions for triggering on the logic analyzer were limited, it was hard to
find the cause of the problems.
The same circuit was debugged using Synplicity’s Identify RTL Debugger tools. The standard FPGA design flow
was augmented using the Identify product to allow RTL debugging in hardware. Live, full-speed Internet traffic was
analyzed using the system shown in Figure 2. The laptop was used to run the Identify tool, and the parallel port
interface was used to connect to the JTAG pins of the Virtex FPGA in the FPX hardware platform. Two of the
Identify product’s debugging methods, break point triggering and state machine triggering, where used to debug the
scheduler (see Figure 2).
Breakpoint Triggering
Breakpoint triggers were used to sample data whenever a portion of VHDL code was executed. For the packet
scheduler, breakpoints were set to debug the operation of the control packet processor. Parameters of the sched-
uler are configured by sending control packets to hardware. Although the scheduler could process most types of
control packets, it was found that specific configurations were causing problems. By utilizing breakpoints in the por-
tion of the code which handled control packets, it was possible to debug the control processor. When a breakpoint
was encountered, the internal registers where checked to ensure they reflected the data contained within the con-
trol packet. A portion of the VHDL code along with the breakpoint (shown as a green dot) can be seen in the
screen dump in Figure 3 (see Figure 3 on page 6).
Synd ica ted i s onl ine at www.synpl ic ity.com/syndicated/ 5
“Debugging” continued on page 6
Debugging of an Internet Packet Scheduler Using theIdentify® Software by Christopher K. Zuver and John W. Lockwood,Washington University in St. Louis
Figure 1: FPX network processing platformsmounted in rack mount chassis. In the originalmode of debugging, ribbon cables were usedto transfer signals from the debugging port ofthe FPX to a logic analyzer.
Figure 2: A laptop running Synplicity’s Identifyproduct, connected via the parallel cable to aFPX in the chassis, was used to debug the hard-ware circuit. The JTAG interface providedcommunication between the hardware anddebugger.
State Machine Triggering
State machine triggering was used to capture an event that spanned multiple clock cycles.
The protocol wrappers of the scheduler use a specific protocol to identify the portions of
the IP packets that pass through the system. As shown in the Figure 4, this protocol identi-
fies the Start of Frame (SOF), start of IP packet (SOIP), start of IP Payload (SOP), End of
Frame (EOF), and Data Enable (DataEn). Whenever this protocol was violated, the circuit
produced corrupt traffic. State machine triggering allowed the Identify tool to process a
sequence of triggers to locate the event when the sequence violated the proper behavior of
the wrapper protocol. A state machine was constructed in such a way that each state rep-
resents the natural progression of the protocol for normal traffic. The state machine trig-
gered whenever this progression was violated. It was found that a single packet out of 10.5
billion packets (1 day of Gigabit Ethernet data) caused a problem. By using the Identify tool, it was discovered that the errors were caused by a specific, invalid
input traffic pattern that caused an input buffer to overflow. By triggering the machine when the protocol was violated, it was possible to find and correct the
error conditions. Without the Identify tool, such an error would require weeks of debugging, however the issue was found in addressed in a matter of hours.
References
[EH’01] Evolvable Internet Hardware Platforms, by John W. Lockwood, NASA/DoD Workshop on Evolvable Hardware (EHW'01), Long Beach, CA, July 12-14, 2001, pp. 271-279.
[FPL’03] An Extensible, System-On-Programmable-Chip, Content-Aware Internet Firewall, by John W. Lockwood, Christopher Neely, Christopher Zuver, James Moscola, Sarang Dharmapurikar,
and David Lim; Field Programmable Logic and Applications (FPL), Lisbon, Portugal, pp. 859-868 (Paper 14B), Sep 1-3, 2003
[RECONFIG’04] Reconfigurable Network Group Homepage, http://www.arl.wustl.edu/arl/projects/fpx/reconfig.htm, Nov. 2004
6
“Debugging” continued from page 5
“Equivalence Checking” continued on page 7
Figure 3: Break point triggering is used to trigger samples whenever thecontrol_cam_identifier state is entered without explicitly using state as thetrigger case.
Figure 4: Waveform showing trigger of protocol violation in red. The control signalsop_out_appl (Start of Payload) should only be asserted once betweensof_out_appl (Start of Frame) and eof_out_appl (End of Frame). This led to dis-covery of a buffer overflow condition.
Equivalence Checking Synplify Pro® Synthesis:Accelerating Verification and Ensuring Quality
by Arne Boralv,VTO, and Marcus Tallhamm,VP, Marketing and Business Development, Prover Technology
As FPGA devices become more advanced and widely used, requirements on FPGA implementation tools increase as well. In order to utilize FPGA
resources more efficiently, FPGA synthesis and place and route tools perform more aggressive design optimizations and utilize powerful on-chip acceleration
blocks of the latest FPGAs. In addition, physical synthesis is applied to further boost performance.
These and other technical advancements in FPGA devices and implementation tools enable cheaper systems to be developed, but also produce a challenge
for verification: How do you verify that no bugs were introduced?
Desperate Need for More Efficient Verification Methods
Many FPGA applications are in desperate need of more efficient verification methods with higher verification coverage, as failure to reach functional closure
can result in accidents, product recalls, bad product PR, and jeopardize entire projects. Implementation errors have severe consequences in many applications,
including mission-critical control systems in satellites, cars and trains, military equipment, networking components, etc. FPGA designers in this category need
exhaustive verification methods applied throughout the FPGA implementation flow to guarantee that no bugs are introduced.
Another group of designers in strong need of more efficient verification methods are designers that do functional verification using FPGAs prototypes.
These designers synthesize RTL code targeting an FPGA and then execute the FPGA on a board to verify the logic. The approach is magnitudes faster than
simulation-based verification, but of course relies on the implementation being correct. If the FPGA implementation introduces a logic error, two things can
happen. In the best case, the design team detects the error, finds its cause, and corrects it. In the worst case, the error propagates to the production of the
ASIC or structured ASIC, and results in a costly design re-spin.
Most FPGA designers today either rely on inefficient gate-level simulation for verification, or simply assume that implementation tools do not introduce any
bugs. If the FPGA does not work, a trial-and-error approach is used to identify where in the implementation flow the problem was introduced and how to
work around it. Clearly, a solution for efficient verification of FPGA implementation would accelerate verification, improve quality, and reduce costs. Equivalence
checking addresses exactly this problem.
Equivalence Checking
Equivalence checking has been used for more than 10 years by ASIC designers to verify synthesis,
place and route, and other design transformations. In contrast to simulation-based verification that deliv-
ers very low coverage in days or weeks, equivalence checking can deliver 100% coverage in minutes or
hours as it establishes a formal equivalence proof of the two design revisions (see Figure 1).
In the past, equivalence checkers have not been well-suited for FPGA flows due to a lack of adequate
support for sequential FPGA synthesis optimizations. Equivalence checking was a labor intensive process
that often produced unreliable results.
Equivalence Checking Synplify Pro Synthesis
Today, with Synplify Pro software synthesis verification is possible and efficient due to its tight integration with the Prover eCheck equivalence checker.The
integrated flow efficiently addresses previous obstacles in FPGA synthesis verification:
l Prover eCheck supports all common sequential optimizations performed in the Synplify Pro software in verification mode.
l Setup work is eliminated or dramatically reduced by using the information provided in the Verification Interchange Format (VIF) file generated by the
Synplify Pro solution.
The VIF file forward-annotates design transformations performed as part of synthesis, such as finite state machine re-
encodings, port direction changes, register merges, register duplications, and constant register optimizations (see Figure
2). After synthesis is completed, a single command invocation in the Synplify Pro tool automatically translates the VIF file
to a Prover eCheck set-up script and launches Prover eCheck, ready to verify the netlist produced by synthesis. Since all
inter-tool communication is done using open file formats, advanced users have the option of adapting the flow to their
needs should they need to.
Example Transformation Verified
Prover eCheck considers all transformations given in the VIF file as hints only, and verifies the correctness of each and
every one of them as part of the equivalence check. As an example, consider an RTL construct with a 4-bit state
machine with 9 reachable states that is sequentially encoded, which Synplify Pro software re-encodes into a one-hot encoded state machine. In this case, the
VIF file will forward-annotate a mapping of the 9 sequentially encoded RTL states to the one-hot encoded states in the netlist. Prover eCheck will verify that
the state machine cannot reach any other state than the 9 given ones, and in addition prove that the corresponding states are equivalent.
Summary
Equivalence checking has proven to be the most efficient method for verification of design implementation in the ASIC community. With the increased com-
plexity of FPGA devices and FPGA implementation tools, the need for efficient equivalence checking increases. Prover eCheck offers an efficient verification
flow for the Synplify Pro solution that dramatically reduces or eliminates manual set-up. Any logic errors introduced in synthesis or place and route are effi-
ciently pin-pointed. As a result, FPGA designers can greatly increase their productivity compared to previous trial-and-error methods.
To download an evaluation copy of Prover eCheck, register at: www.prover.com/products/eda/echeckreg.xml.
7Synd ica ted i s onl ine at www.synpl ic ity.com/syndicated/
“Equivalence Checking” continued from page 7
Figure 2: Prover eCheck’s FSM re-encod-ing window
RTL
Netlist
Netlist
Place & Route
Synthesis Equivalencecheck
Equivalencecheck
Figure 1: Equivalence Checking Flow Overview
New Quartus II Software Version 4.2 IncludingPowerPlay Technology
by Robert Kruger, Product Line Manager, and Mouzam Khan,Application Engineer MTS,Altera Corporation
FPGAs and other devices continue to grow in density and move to smaller process technologies, making power management in the design cycle increas-
ingly more important. Version 4.2 of the Quartus® II software includes PowerPlay power analysis and optimization tools to help you properly plan for thermal
power dissipation and FPGA power supply system design.
Altera designed PowerPlay technology to enable accurate analysis and optimization of both dynamic and static power consumption. With the PowerPlay
tools, you can account for increasingly detailed design activity data, environmental factors, and device-specific data in your designs. PowerPlay power analysis fea-
tures include detailed reports that can be used to optimize thermal power dissipation on a block-type or
design-hierarchy basis. Automated Quartus II software PowerPlay optimization features will be introduced in
2005.
Power Analysis from Design Concept through Implementation
The new PowerPlay power analysis tools in Quartus II software version 4.2 give you the ability to estimate
power consumption from early design concept through design implementation, as shown in Figure 1.
PowerPlay Early Power Estimators
You can use the PowerPlay early power estimator spreadsheets to estimate static and dynamic power consumption during the design concept stage. You can
fill out early power estimator spreadsheets manually or populate them directly from the Quartus II software. The new Quartus II PowerPlay power analyzer
feature can refine your power estimations during design implementation.
PowerPlay Power Analyzer
The Quartus II software now includes the PowerPlay power analyzer feature. This feature improves the accuracy of power consumption estimations given by
the PowerPlay early estimator spreadsheets by:
l Taking into account device resource usage and place and route results.
l Taking into account functional and timing simulation input/output stimuli.
l Performing statistical analysis of expected design-node activity rates when simulation vector inputs are not available.
The most important factor in estimating power consumption is the behavior of each signal in the design, based on the toggle rate and static probability. The
toggle rate is the average number of times that a signal changes from 1 to 0 or 0 to 1 per second. The static probability of a signal is the percentage of time that
it will be logic 1 during the period of device operation that is being analyzed. You can specify signal activities with
four different data sources:
l Vectorless estimation for the Stratix II and MAX II device families.
l User-entered default toggle rate assignments.
l User-entered node, entity and clock assignments.
l Simulation results.
You can use different data sources for each signal in the same Quartus II design. Simulation results provide the most accurate way of generating signal activi-
ties, and thus give the most accurate calculation of power consumption for FPGA designs.
Operating conditions can also be specified to calculate the power consumption of Stratix II and MAX II designs. You can input typical or maximum device
power characteristics, environmental conditions, and junction temperature. The PowerPlay power analyzer can automatically compute the junction temperature
based on user-specified ambient temperature and cooling solutions. The Quartus II software version 4.2 includes a prepared list of sample cooling systems and
allows you to enter the thermal resistance of your own cooling system.
The Quartus II PowerPlay power analyzer produces detailed reports that can pinpoint which device structures, and even design hierarchy blocks, are dissipat-
ing the most thermal power. Figure 2 lists the PowerPlay power analyzer reports available.
The PowerPlay power analyzer provides comprehensive reports of the power consumption, as shown in Figure 3 (see page 9). The “Thermal Power
Dissipation by Hierarchy” section provides users with the estimated thermal dynamic power and thermal static power consumption for each hierarchy in an
Figure 1: PowerPlay Power Analysis
Figure 2: PowerPlay Power Analyzer Report
“PowerPlay” continued on page 9
8
Industry leaders like Synplicity Inc.,ARM Limited,Arrow, Daito, Denali Software Inc., GDA Technologies Inc., Innotech, Memec, PLDApplications, Pinpoint
Solutions Inc., RepTechnique, Silicon Infusion,TeraSystems, and more have joined LSI Logic's Partner Program, adding value to the RapidChip technology and
ensuring that their solutions work seamlessly by design to satisfy market needs.
LSI Logic’s RapidChip Partner Program Turns Ideas into Innovations
The RapidChip Partner Program frees chip designers from the burden of resource-intensive implementation tasks, allowing them to concentrate on designing
the differentiating intellectual property that adds value to the end system.
By helping OEMs overcome their biggest obstacles with ready-to-use, fully verified products and services, development times of complex systems-on-a-chip
(SoCs) can be slashed by up to 50 percent. And with traditional ASIC design investments rising precipitously, the RapidChip Partner Program can help them sig-
nificantly lower system costs.
LSI Logic and RapidChip Partners: Working Together to Set the Standard for Platform ASICs
Platform ASICs, like RapidChip, are being heralded as the next big thing in custom semiconductors because they bridge the gap between traditional cell-based
ASICs and FPGAs. The programmability, IP selection, and services available with the RapidChip Partner Program lets engineers achieve their high performance
design goals faster and with less expense, solving both the cost inhibitors of traditional ASICs and the performance limitations of FPGAs.
The launch of the RapidChip Partner Program, combined with a large number of customers that have already adopted the platform, establishes LSI Logic as
the acknowledged market leader. By providing a one-stop shop with the widest selection of ready-to-use IP, tools, and services, RapidChip has become the plat-
form ASIC standard.
For more information, go to www.rapidchip.com/partners.
Altera FPGA design. With this information, you can revise your register trans-
fer level (RTL) code or your Synplify Pro software and Quartus II design con-
straints to lower power consumption.
Push-button Power Optimization
FPGA and CPLD design tools can optimize designs for performance and
area utilization automatically, but still leave power management largely to the
designer. In 2005, push-button PowerPlay power optimization technology will
be included in Quartus II software releases. In these upcoming releases,
PowerPlay power optimization technology will help you optimize power con-
sumption in addition to speed and area constraints in FPGA, CPLD, and struc-
tured ASIC designs, as shown in Figure 4.
The combination of Quartus II PowerPlay power analysis and optimization
technology,Altera's advanced silicon design techniques, and partnerships with
leading power management component suppliers gives Quartus II software
users an edge in delivering high-performance, power-optimized designs on 90-
nm and smaller process technologies.
8
“PowerPlay” continued from page 8
Figure 3:PowerPlay Report File
“Banding Together” continued from page 1
Figure 4: PowerPlay OptimizationDesign Flow
9Synd ica ted i s onl ine at www.synpl ic ity.com/syndicated/
The ongoing migration of custom ICs to smaller, more advanced process geometries has shown that the performance requirements of today’s electronic
products continue to rise.This presents a challenge to the majority of ASIC designers working with advanced process technologies like 90-nm, as market and
economic pressures require them to develop high-performance chips under tight time-to-market and NRE cost constraints. These pressures are in direct con-
flict with the characteristics of 90-nm ASIC implementation. The mask, development time, and NRE costs associated with 90-nm development can be quite high.
With the majority of custom chips developed today only reaching small- to medium-sized production runs (5,000 - 100,000 units), achieving a return on invest-
ment for the development of a 90-nm ASIC has become increasingly difficult.
To bridge the gap between market needs, performance needs, and economic and engineering realities, NEC Electronics has developed the Instant Silicon
Solution Platform™ (ISSP™) of structured ASIC devices. The ISSP90 family is designed to serve the needs of customers requiring performance similar to that of a
90-nm cell0based ASIC. Based on NEC Electronics’ 90-nm UX6 CMOS process technology, highly integrated, low-power ASIC in a significantly shorter develop-
ment time and at a fraction of the cost traditionally associated with cell-based ASICs.
High-Performing, Rapidly Customizable Silicon
NEC Electronics’ ISSP90 structured ASICs use a seven metal-layer interconnection struc-
ture consisting of five fixed layers and two customizable layers. The logic architecture is made
up of complex multi-gates for implementing custom logic or synthesizable IP functions. The
two customizable layers are where designers configure the ISSP90 device to support their
specific application.
Below the two customizable layers, pre-verified design-for-test (DFT) circuits, clocktrees,
and power lines are immersed into three fixed metal layers which also serve as interconnect
to embedded IP cores. An additional fixed metal mask layer on top of the customizable layers
is used to reinforce the power lines. The final fixed mask layer is used to support FCBGA packaging. By using the ISSP90 architecture’s fixed and customizable
layers, designers are essentially building a device that offers performance and density levels very similar to a cell-based ASIC in a fabric that accelerates design
and manufacturing turnaround time.
The ISSP90 devices are ideal for supporting complex systems that designers typically implement when working at 90-nm. The ISSP90 family offers two mas-
terslice types: one optimized for high-density applications, and one optimized for high-speed applications. There are multiple gate, memory, and I/O configura-
tions available. ISSP90 structured ASICs offer designers up to 6.5M usable ASIC gates, 5.7M Mbits of configurable embedded SRAM, and clock speeds of up to
500MHz. The various specifications of the masterslices in the ISSP90 family are described in greater detail in Table 1.
Fast, Economical Design with Low Risk
Most importantly, designers using the ISSP platform can build a high-performance structures ASIC with a much shorter development cycle and at a lower
overall NRE cost than a traditional standard cell-based ASIC. The majority of this design advantage is attributable to the pre-embedded features in the ISSP90
architecture’s lower metal layers. The pre-embedded power grid and clock domains simplify resolution of power and signal integrity issues, and accelerate timing
closure. And since these base layers are pre-configured with a variety of popular testing methodologies, designers do not have to spend time adding DFT cir-
cuits to their design and going through lengthy design iterations. Compared to the 12 to 18 months required to develop and manufacture a typical cell-based
ASIC, designers using an ISSP90 structured ASIC can accelerate their development time and receive engineering samples in four to six months. Specific features
of the ISSP90 architecture that help reduce design time are listed in Table 2.
These features translate into lower development costs than required to design a cell-based
ASIC. Fewer mask steps and easier resolution of signal integrity, power integrity, and timing
closer issues result in fewer engineering hours, lower tooling costs, and lower NRE costs.
While a typical five-million-gate cell-based ASIC design implemented in 90-nm can require an upfront NRE cost of anywhere from $1M to $3M and the purchase
of six to ten EDA tools costing more than $300K, designers using a comparable ISSP90 device can spend less than $200K in NRE and need only two to three
tools costing less than $50K to develop their product.
Additionally, NEC Electronics helps eliminate design risk and increases the likelihood of first-pass silicon by offering a highly optimized design flow that helps
resolve many of the traditional back-end design issues that have threatened the success of high-density cell-based ASIC designs. By partnering with Synplicity®,
NEC Electronics offers designers a physical synthesis design tool,Amplify® ISSP physical synthesis, that is specifically optimized for ISSP90 structured ASICs.
Simplify 90-nm Design with NEC Electronics’ ISSP90Family of Structured ASICs by Steven Kawamoto, NEC Electronics America, Inc.
10
Table 1: Specifications for ISSP90 masterslices
Table 2: Fast design turnaround times
“Simplify 90-nm” continued on page 11
Synplify Pro® Software
Q. What is VIF?
A. VIF stands for “Verification Interface Format”.This is an open ASCII file written out during synthesis by the Synplify Pro solution that provides an interface
to popular 3rd party Formal Verification tools. Currently,VIF is supported in the Synplify Pro product only (version 8.0 and higher) for Xilinx and Altera families.
Verification mode is enabled, by turning on, the verification_mode switch under Synplify Pro software implementation options.
set_option -verification_mode 1
In order to generate the Formal Verification interface file, users must also enable the following switch, also available under Synplify Pro software implementa-
tion options.
set_option -write_vif 1
After synthesizing the design with the above mentioned options turned on, the Synplify Pro tool will create a folder called “verify” under the current imple-
mentation directory.The verify folder will contain a file called <design_name>.vif, which is the interface file for performing formal verification.
The VIF file contains Formal Verification related commands and options including but not limited to:
l Project and file setting
l Modeling commands
l Mapping commands
l Information about sequential optimizations (register merging, replication etc..)
VIF was designed to provide an easy to use, tool-independent interface between synthesis and 3rd party formal verification / logical equivalency checking
tools. Synplicity has been working with tool vendors such as Cadence and Prover to enhance and improve the ability to use formal verification tools and Synplify
Pro. More information about support and limitations can be found by contacting your Formal Verification tool vendor or Synplicity.
Amplify® FPGA Software
Q. What technique can I use to improve physical constraints when using Amplify FPGA?
A. The start and end points of critical paths typically have multiple paths of connectivity--some paths being more critical than others. During the creation of
physical constraints, a user can take advantage of this connectivity to minimize the size of physical regions. After filtering the critical group in the HDL Analyst®
“Tips & Hints” continued on page 12
11Synd ica ted i s onl ine at www.synpl ic ity.com/syndicated/
“Simplify 90-nm” continued from page 10
Amplify ISSP software features embedded knowledge of the ISSP90 architecture. With a detailed understanding of the architecture’s embedded complex
multi-gate, clocktree, and power grid during synthesis, the Amplify ISSP product allows engineers to quickly achieve timing closure and avoid the highly iterative
process that typical characterizes ASIC design. Working off a detailed floorplan, the Amplify ISSP tool maps directly to the ISSP architecture, resulting in a more
optimized implementation and a more predictable result. While a generic physical synthesis tool in a cell-based ASIC design can estimate only about 40 percent
of all the routes in a design, the Amplify ISSP product, with its embedded knowledge of the architecture, can estimate up to 70 percent of all routes. Designers
gain better utilization, faster timing closure, and fewer design iterations, resulting in a shorter time to tapeout.
90-nm for the Masses
The dramatic time and cost savings provided by NEC Electronics’ ISSP90 family of structured ASICs brings the performance advantage of 90-nm custom sili-
con to a much broader group of designers, who will in turn deliver high-performance ASIC solutions to the OEMs building tomorrow’s products. For more
information about design benefits ISSP90 structures ASICs can bring to your 90-nm product development plans, visit NEC Electronics America at
www.necelam.con/issp.
RTL View, select an instance that is mutually exclusive to the most critical path
connecting the critical start and end points. Using the HDL Analyst RTL View
"Isolate Paths" feature, prune all logic not associated with the selected instance.
The remaining RTL is reduced and is a better representation of the real critical
path. Having less RTL to constrain leads to smaller region sizes and typically
faster timing closure.
Identify® RTL Debugger
Q. I’ve instrumented my design for state machine triggering. How can I set
simple watchpoint/breakpoint triggers?
A. State machine triggering in Identify builds specialized debug logic that
allows the user to set triggers on sequences of events in the hardware. In order
to use this debug logic to set simple single cycle triggers, the state machine must
be programmed with the desired behavior. In Identify 2.1, the Debugger contains
a graphical editor for the state machine programming. Launch this dialog by click-
ing the toolbar icon (Figure 3) from any state machine enable IICE™.
This dialog contains a drop-down list of state machine “macros”. Each of these
“macros” automatically configures the state machine to behave as described.
(Figure 4).
To create simple triggers with the state machine, simply use the “st_events” macro.This macro config-
ures the state machine to behave like “events” mode and trigger on the nth event of the trigger condition.
Enable your trigger values in “condition 0” and create the macros as shown in Figure 5.This will trigger
the Debugger on the first occurrence of the trigger condition.
12Copyright © 2004 Synplicity, Inc.All rights reserved. Synplicity, the Synplicity logo, “Simply Better Results,” Syndicated, Synplify, Synplify Pro,Amplify, and Identify are regis-tered trademarks. All other names mentioned herein are trademarks or registered trademarks of their respective companies.
Synplicity, Inc.600 W. California Avenue
Sunnyvale, CA 94086 USAPhone: (US) +1 408 215-6000Fax: (US) +1 408 222-0263
www.synplicity.com
EDS Fair 2005
Jan. 27 - 28, 2005
Pacifico Yokohama, Japan
www.edsfair.com (Japanese)
www.edsfair.com/e/index.html (English)
DesignCon 2005
Jan. 31 - Feb. 3, 2005
Santa Clara Convention Center
Santa Clara, CA USA
www.designcon.com
Elektronik/EP 2005
Feb. 1 - 3, 2005
Stockholm, Sweden
www.stockholmsmassan.se/elektronic-ep/
CMSE (Commercialization of
Military and Space Electronics
Conference & Exhibit)
Feb. 8 - 9, 2005
Los Angeles, CA USA
www.cti-us.com/ucmsemain.htm
DATE 2005 (Design, Automation,
and Test in Europe)
Mar. 7 - 11, 2005
MesseMunich, Germany
www.date-conference.com
This list of Upcoming Events is subject to change.
Please go to the Synplicity web site at
www.synplicity.com/events to view the most current
schedule of events the company will be hosting as well
as attending.
Whether you are a new or experienced user, Synplicity offers a variety of focused product train-
ing courses to help ensure your productivity in your daily job. With the flexibility of attending formal
training classes, purchasing your own copy of the training material, or registering for the on-line, self-paced
courses, you choose the option that best fits into your schedule and learning style.
l Free On-line, Self-paced Courses: Any user who is evaluating or owns Synplicity’s software can
register for our on-line, self-paced courses. These courses come at no additional charge. The material
covers the same topics as the corresponding instructor-lead classes. To receive your free account, go
to www.synplicity.com/training to register.
l Up-to-date Classroom and On-site Training Classes: Synplicity also offers instructor-led
courses taught monthly by Synplicity Corporate Application Engineers that are experts in each of our
products. A description of each course is available on our web page at www.synplicity.com/training. All
training classes are given at Synplicity’s headquarters and feature formal instruction, labs, and plenty of
time to ask questions of your instructor. Classes can also be arranged at your facility.
l Training Material: Designers who wish to take a course at their own pace can purchase the
training material used in the instructor-led classes. The training material includes a course manual and
lab instructions, with lab files available electronically. Orders are usually shipped within two weeks.
Additional Information
To view the current schedule of available classes, get more information on Synplicity’s Training Courses,
or to register, simply go to www.synplicity.com/training. If you have any questions regarding our training
program, please send an e-mail to [email protected].
Free Synplicity® On-line TrainingCourses That Fit Your Needs!
“Tips & Hints” continued from page 11
Figure 3
Figure 4
Figure 5