デバッグ GUI ユーザーガイド (英語版・PDF)

デバッグ GUI ユーザーガイド (英語版・PDF)
Debugging Memory IP
12
2014.08.15
emi_dg_011
Subscribe
Send Feedback
The following topics describe the tools and processes for debugging external memory interfaces.
®
The discussion focuses on issues pertaining to the Altera DDR, DDR2, DDR3, QDRII, QDRII+, and
RLDRAM II IP.
In general, memory debugging issues can be categorized as follows:
•
•
•
•
Resource and planning issues
Interface configuration issues
Functional issues
Timing issues
®
Some issues may not be directly related to interface operation; problems can also occur at the Quartus II
Fitter stage, or in timing analysis.
Resource and Planning Issues
Typically, single stand-alone interfaces should not present Quartus II Fitter or timing problems.
You may find that fitter, timing, and hardware operation can sometimes become a challenge, as multiple
interfaces are combined into a single project, or as the device utilization increases. In such cases, interface
configuration is not the issue; rather, the placement and total device resource requirements can create
problems.
Resource Issue Evaluation
External memory interfaces typically require the following resource types, which you must consider when
trying to place logic manually. You might also use additional constraints to force the placement or location
of external memory interface IP:
•
•
•
•
Dedicated IOE DQS group resources and pins
Dedicated DLL resources
Specific PLL resources
Specific global, regional, and dual-regional clock net resources
Dedicated IOE DQS Group Resources and Pins
Fitter issues can occur with even a single interface, if you do not size the interface to fit within the specified
constraints and requirements. A typical requirement includes containing assignments for the interface
within a single bank or possibly side of the chosen device.
© 2014 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words
and logos are trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other
words and logos identified as trademarks or service marks are the property of their respective holders as described at
www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with
Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes
no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly
agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying on any published
information and before placing orders for products or services.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
ISO
9001:2008
Registered
12-2
Dedicated DLL Resources
emi_dg_011
2014.08.15
Such a constraint requires that the chosen device meets the following conditions:
• Sufficient DQS groups and sizes to support the required number of common I/O (CIO) or separate I/O
(SIO) data groups.
• Sufficient remaining pins to support the required number of address, command, and control pins.
Failure to evaluate these fundamental requirements can result in suboptimal interface design, if the chosen
device cannot be modified. The resulting wraparound interfaces or suboptimal pseudo read and write data
groups artificially limit the maximum operating frequency.
Multiple blocks of IP further complicate the issue, if other IP has either no specified location constraints or
incompatible location constraints.
The Quartus II fitter may first place other components in a location required by your memory IP, then error
at a later stage because of an I/O assignment conflict between the unconstrained IP and the constrained
memory IP.
Your design may require that one instance of IP is placed anywhere on one side of the device, and that
another instance of IP is placed at a specific location on the same side.
While the two individual instances may compile in isolation, and the physical number of pins may appear
sufficient for both instances, issues can occur if the instance without placement constraints is placed before
the instance with placement constraints.
In such circumstances, Altera recommends manually placing each individual pin, or at least try using more
granular placement constraints.
For more information about the pin number and DQS group capabilities of your chosen device, refer to
device data sheets or the Quartus II Pin Planner.
Dedicated DLL Resources
Altera devices typically use DLLs to enhance data capture at the FPGA. While multiple external memory
interfaces can usually share DLL resources, fitter issues can occur when there is insufficient planning before
HDL coding.
If DLL sharing is required, Altera gives the following recommendations for each instance of the IP that
shares the DLL resources:
• Must have compatible DLL requirements—same frequency and mode.
• Exports its autogenerated DLL instance out of its own dedicated PHY hierarchy and into the top-level
design file. This procedure allows easy comparison of the generated DLL’s mode, and allows you to
explicitly show the required DLL sharing between two IP blocks in the HDL
Note: The Quartus II fitter does not dynamically merge DLL instances.
Specific PLL Resources
When only a single interface resides on one side or one quadrant of a device, PLL resources are typically not
an issue. However if multiple interfaces or IP are required on a single side or quadrant, consider the specific
PLL used by each IP, and the sharing of any PLL resources.
The Quartus II software automerges PLL resources, but not for any dynamically controlled PLL components.
Use the following PLL resource rules:
• Ensure that the PLL located in the same bank or side of the device is available for your memory controller.
• If multiple PLLs are required for multiple controllers that cannot be shared, ensure that enough PLL
resources are available within each quadrant to support your interface number requirements.
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Specific Global, Regional and Dual-Regional Clock Net Resources
12-3
• Try to limit multiple interfaces to a single quadrant. For example, if two complete same size interfaces
can fit on a single side of the device, constrain one interface entirely in one bank of that side, and the
other controller in the other bank.
For more information about using multiple PHYs or controllers, refer to the design tutorials on the List of
designs using Altera External Memory IP page of the Altera Wiki website.
Related Information
List of designs using Altera External Memory IP
Specific Global, Regional and Dual-Regional Clock Net Resources
Memory PHYs typically have specific clock resource requirements for each PLL clock output.
For example because of characterization data, the PHY may require that the phy_clk is routed on a global
clock net. The remaining clocks may all be routed on a global or a regional clock net. However, they must
all be routed on the same type. Otherwise, the operating frequency of the interface is lowered, because of
the increased uncertainty between two different types of clock nets. The design may still fit, but not meet
timing.
Planning Your Design
It is important to understand your design and to plan its resource usage and layout. Include the following
steps in your design planning:
1. Plan the total number of DQS groups and total number of other pins required in your shared area. Use
the Pin Planner to assist with this activity.
2. Decide which PLLs or clock networks can be shared between IP blocks, then ensure that sufficient
resources are available. For example, if an IP core requires a regional clock network, a PLL located on
the opposite side of the device cannot be used.
3. Calculate the number of total clock networks and types required when trying to combine multiple instances
of IP.
4. You must understand the number of quadrants that the IP uses and if this number can be reduced. For
example, an interface may be autoplaced across an entire side of the device, but may actually be constrained
to fit in a single bank.
By optimizing physical placement, you ensure that the system uses regional clock networks whereever
possible. The use of regional clock networks instead of dual-regional clock networks can help maintain clock
net resources and simplify routing.
Optimizing Design Utilization
As device utilization increases, the Quartus II software may have difficulty placing the core. To optimize
design utilization, follow these steps:
Debugging Memory IP
Send Feedback
Altera Corporation
12-4
Interface Configuration Performance Issues
emi_dg_011
2014.08.15
1. Review any fitter warning messages in multiple IP designs to ensure that clock networks or PLL modes
are not modified to achieve the desired fit.
2. Use the Quartus II Fitter resource section to compare the types of resources used in a successful standalone
IP implementation to those used in an unreliable multiple IP implementation.
3. Use this information to better constrain the project to achieve the same results as the standalone project.
4. Use the Chip Planner (Floorplan and Chip Editor) to compare the placement of the working stand-alone
design to the multiple IP project. Then use LogicLock™ or Design Partitions to better guide the Quartus
II software to the required results.
5. When creating LogicLock regions, ensure that they encompass all required resources. For example, if
constraining the read and write datapath hierarchy, ensure that your LogicLock region includes the IOE
blocks used for your datapath pin out.
Interface Configuration Performance Issues
There are a large number of interface combinations and configurations possible in an Altera design, therefore
it is impractical for Altera to explicitly state the achievable fMAX for every combination.
Altera seeks to provide guidance on typical performance, but this data is subject to memory component
timing characteristics, interface widths, depths directly affecting timing deration requirements, and the
achieved skew and timing numbers for a specific PCB.
FPGA timing issues should generally not be affected by interface loading or layout characteristics. In general,
the Altera performance figures for any given device family and speed-grade combination should usually be
achievable.
To resolve FPGA (PHY and PHY reset) timing issues, refer to the Analyzing Timing of Memory IP chapter.
Achievable interface timing (address and command, half-rate address and command, read and write capture)
is directly affected by any layout issues (skew), loading issues (deration), signal integrity issues (crosstalk
timing deration), and component speed grades (memory timing size and tolerance). Altera performance
figures are typically stated for the default (single rank, unbuffered DIMM) case. Altera provides additional
expected performance data where possible, but the fMAX is not achievable in all configurations. Altera
recommends that you optimize the following items whenever interface timing issues occur:
•
•
•
•
Improve PCB layout tolerances
Use a faster speed grade of memory component
Ensure that the interface is fully and correctly terminated
Reduce the loading (reduce the deration factor)
Related Information
Analyzing Timing of Memory IP
Interface Configuration Bottleneck and Efficiency Issues
Depending on the transaction types, efficiency issues can exist where the achieved data rate is lower than
expected. Ideally, these issues should be assessed and resolved during the simulation stage because they are
sometimes impossible to solve later without rearchitecting the product.
Any interface has a maximum theoretical data rate derived from the clock frequency, however, in practise
this theoretical data rate can never be achieved continuously due to protocol overhead and bus turnaround
times.
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Functional Issue Evaluation
12-5
Simulate your desired configuration to ensure that you have specified a suitable external memory family
and that your chosen controller configuration can achieve your required bandwidth.
Efficiency can be assessed in several different ways, and the primary requirement is an achievable continuous
data rate. The local interface signals combined with the memory interface signals and a command decode
trace should provide adequate visibility of the operation of the IP to understand whether your required data
rate is sufficient and the cause of the efficiency issue.
To show if under ideal conditions the required data rate is possible in the chosen technology, follow these
steps:
1. Use the memory vendors own testbench and your own transaction engine.
2. Use either your own driver, or modify the provided example driver, to replicate the transaction types
typical of your system.
3. Simulate this performance using your chosen memory controller and decide if the achieved performance
is still acceptable.
Observe the following points that may cause efficiency or bottleneck issues at this stage:
• Identify the memory controller rate (full, half, or quarter) and commands, which may take two or four
times longer than necessary
• Determine whether the memory controller is starved for data by observing the appropriate request signals.
• Determine whether the memory controller processor transactions at a rate sufficient to meet throughput
requirements by observing appropriate signals, including the local ready signal.
Altera has several versions and types of memory controller, and where possible you can evaluate different
configurations based on the results of the first tests.
Consider using either a faster interface, or a different memory type to better align your data rate requirements
to the IP available directly from Altera.
Altera also provides stand-alone PHY configurations so that you may develop custom controllers or use
third-party controllers designed specifically for your requirements.
Functional Issue Evaluation
Functional issues occur at all frequencies (using the same conditions) and are not altered by speed grade,
temperature, or PCB changes. You should use functional simulation to evaluate functional issues.
The Altera IP includes the option to autogenerate a testbench specific to your IP configuration, which
provides an easy route to functional verification.
The following issues should be considered when trying to debug functional issues in a simulation environment.
Correct Combination of the Quartus II Software and ModelSim-Altera Device Models
When running any simulations, ensure that you are using the correct combination of the Quartus II software
and device models.
Altera only tests each release of software and IP with the aligned release of device models. Failure to use the
correct RTL and model combination may result in unstable simulation environments.
®
The ModelSim -Altera edition of the ModelSim simulator comes precompiled with the Altera device family
libraries included. You must always install the correct release of ModelSim-Altera to align with your Quartus
II software and IP release.
Debugging Memory IP
Send Feedback
Altera Corporation
12-6
emi_dg_011
2014.08.15
Altera IP Memory Model
If you are using a full version of ModelSim-SE or PE, or any other supported simulation environment, ensure
that you are compiling the current Quartus II supplied libraries. These libraries are located in the <Quartus
II install path>/quartus/eda/sim_lib/ directory.
Altera IP Memory Model
Altera memory IP autogenerates a generic simplified memory model that works in all cases. This simple
read and write model is not designed or intended to verify all entered IP parameters or transaction
requirements.
The Altera-generated memory model may be suitable to evaluate some limited functional issues, but it does
not provide comprehensive functional simulation.
Vendor Memory Model
Contact the memory vendor directly as many additional models are available from the vendors support
system.
When using memory vendor models, ensure that the model is correctly defined for the following
characteristics:
•
•
•
•
•
•
•
Speed grade
Organization
Memory allocation
Maximum memory usage
Number of ranks on a DIMM
Buffering on the DIMM
ECC
Note: Refer to the readme.txt file supplied with the memory vendor model, for more information about
how to define this information for your configuration.
During simulation vendor models output a wealth of information regarding any device violations that may
occur because of incorrectly parameterized IP.
Note: Refer to Transcript Window Messages, for more information.
Insufficient Memory in Your PC
If you are running the ModelSim-Altera simulator, the limitation on memory size may mean that you have
insufficient memory to run your simulation. Or, if you are using a 32-bit operating system, your PC may
have insufficient memory.
Typical simulation tool errors include: "Iteration limit reached" or "Error out of memory".
When using either the Altera generic memory model, or a vendor specific model quite large memory depths
can be required if you do not specify your simulation carefully.
For example, if you simulate an entire 4-GB DIMM interface, the hardware platform that performs that
simulation requires at least this amount of memory just for the simulation contents storage.
Note: Refer to Memory Allocation and Max Memory Usage in the vendor's readme.txt files for more
information.
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Transcript Window Messages
12-7
Transcript Window Messages
When you are debugging a functional issue in simulation, vendor models typically provide much more
detailed checks and feedback regarding the interface and their operational requirements than the Altera
generic model.
In general, you should use a vendor-supplied model whenever one is available. Consider using second-source
vendor models in preference to the Altera generic model.
Many issues can be traced to incorrectly configured IP for the specified memory components. Component
data sheets usually contain settings information for several different speed grades of memory. Be aware data
sheet specify parameters in fixed units of time, frequencies, or clock cycles.
The Altera generic memory model always matches the parameters specified in the IP, as it is generated using
the same engine. Because vendor models are independent of the IP generation process, they offer a more
robust IP parameterization check.
During simulation, review the transcript window messages and do not rely on the Simulation Passed message
at the end of simulation. This message only indicates that the example driver successfully wrote and then
read the correct data for a single test cycle.
Even if the interface functionally passes in simulation, the vendor model may report operational violations
in the transcript window. These reported violations often specifically explain why an interface appears to
pass in simulation, but fails in hardware.
Vendor models typically perform checks to ensure that the following types of parameters are correct:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Burst length
Burst order
tMRD
tMOD
tRFC
tREFPDEN
tRP
tRAS
tRC
tACTPDEN
tWR
tWRPDEN
tRTP
tRDPDEN
tINIT
tXPDLL
tCKE
tRRD
tCCD
tWTR
tXPR
PRECHARGE
CAS length
Drive strength
AL
tDQS
CAS_WL
Debugging Memory IP
Send Feedback
Altera Corporation
12-8
Passing Simulation
•
•
•
•
•
•
emi_dg_011
2014.08.15
Refresh
Initialization
tIH
tIS
tDH
tDS
If a vendor model can verify all these parameters are compatible with your chosen component values and
transactions, it provides a specific insight into hardware interface failures.
Passing Simulation
Passing simulation means that the interface calibrates and successfully completes a single test complete cycle
without asserting pass not fail (pnf).
It does not take into account any warning messages that you may receive during simulation. If you are
debugging an interface issue, review and, if necessary, correct any warning messages from the transcript
window before continuing.
Modifying the Example Driver to Replicate the Failure
Often during debugging, you may discover that the example driver design works successfully, but that your
custom logic is observing data errors.
This information indicates that the issue is either one of the following:
• Related to the way that the local interface transactions are occurring. Altera recommends you probe and
compare using the SignalTap™ II analyzer.
• Related to the types or format of transactions on the external memory interface. Altera recommends you
modify the example design to replicate the issue.
Typical issues on the local interface side include:
• Incorrect local address to memory address translation causing the word order to be different than expected.
Refer to Burst Definition in your memory vendor data sheet.
• Incorrect timing on the local interface. When your design requests a transaction, the local side must be
ready to service that transaction as soon as it is accepted without any pause.
®
• For more information, refer to the Avalon Interface Specification .
The default example driver only performs a limited set of transaction types, consequently potential bus
contention or preamble and postamble issues can often be masked in its default operation. For successful
debugging, isolate the custom logic transaction types that are causing the read and write failures and modify
the example driver to demonstrate the same issue. Then, you can try to replicate the failure in RTL simulation
with the modified driver.
An issue that you can replicate in RTL simulation indicates a potential bug in the IP. You should recheck
the IP parameters. An issue that you can not replicate in RTL simulation indicates a timing issue on the
PCB. You can try to replicate the issue on an Altera development platform to rule out a board issue.
Note: Ensure that all PCB timing, loading, skew, and deration information is correctly defined in the
Quartus II software, as the timing report is inaccurate if this initial data is not correct.
Functional simulation allows you to identify any issues with the configuration of either the Altera memory
controller and or PHY. You can then easily check the operation against both the memory vendor data sheet
and the respective JEDEC specification. After you resolve functional issues, you can start testing hardware.
For more information about simulation, refer to the Simulating Memory IP chapter.
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Timing Issue Characteristics
12-9
Related Information
• Avalon Interface Specification
• Simulating Memory IP
Timing Issue Characteristics
The Altera PHY and controller combinations autogenerate timing constraint files to ensure that the PHY
and external interface are fully constrained and that timing is analyzed during compilation. However, timing
issues can still occur. This topic discusses how to identify and resolve any timing issues that you may
encounter.
Timing issues typically fall into two distinct categories:
• FPGA core timing reported issues
• External memory interface timing issues in a specific mode of operation or on a specific PCB
TimeQuest reports timing issues in two categories: core to core and core to IOE transfers. These timing
issues include the PHY and PHY reset sections in the TimeQuest Report DDR subsection of timing analysis.
External memory interface timing issues are specifically reported in the TimeQuest Report DDR subsection,
excluding the PHY and PHY reset. The Report DDR PHY and PHY reset sections only include the PHY,
and specifically exclude the controller, core, PHY-to-controller and local interface. Quartus II timing issues
should always be evaluated and corrected before proceeding to any hardware testing.
PCB timing issues are usually Quartus II timing issues, which are not reported in the Quartus II software,
if incorrect or insufficient PCB topology and layout information is not supplied. PCB timing issues are
typically characterized by calibration failure, or failures during user mode when the hardware is heated or
cooled. Further PCB timing issues are typically hidden if the interface frequency is lowered.
Evaluating FPGA Timing Issues
Usually, you should not encounter timing issues with Altera-provided IP unless your design exceeds Altera's
published performance range or you are using a device for which the Quartus II software offers only
preliminary timing model support. Nevertheless, timing issues can occur in the following circumstances:
• The .sdc files are incorrectly added to the Quartus II project
• Quartus II analysis and synthesis settings are not correct
• Quartus II Fitter settings are not correct
For all of these issues, refer to the correct user guide for more information about recommended settings and
follow these steps:
1. Ensure that the IP generated .sdc files are listed in the Quartus II TimeQuest Timing Analyzer files to
include in the project window.
2. Ensure that Analysis and Synthesis Settings are set to Optimization Technique Speed .
3. Ensure that Fitter Settings are set to Fitter Effort Standard Fit .
4. Use TimeQuest Report Ignored Constraints, to ensure that .sdc files are successfully applied.
5. Use TimeQuest Report Unconstrained Paths, to ensure that all critical paths are correctly constrained.
More complex timing problems can occur if any of the following conditions are true:
• The design includes multiple PHY or core projects
• Devices where the resources are heavily used
• The design includes wide, distributed, maximum performance interfaces in large die sizes
Debugging Memory IP
Send Feedback
Altera Corporation
12-10
Evaluating External Memory Interface Timing Issues
emi_dg_011
2014.08.15
Any of the above conditions can lead to suboptimal placement results when the PHY or controller are
distributed around the FPGA. To evaluate such issues, simplify the design to just the autogenerated example
top-level file and determine if the core meets timing and you see a working interface. Failure implies that a
more fundamental timing issue exists. If the standalone design passes core timing, evaluate how this placement
and fit is different than your complete design.
Use LogicLock regions, or design partitions to better define the placement of your memory controllers.
When you have your interface standalone placement, repeat for additional interfaces, combine, and finally
add the rest of your design.
Additionally, use fitter seeds and increase the placement and router effort multiplier.
Evaluating External Memory Interface Timing Issues
External memory interface timing issues usually relate to the FPGA input and output characteristics, PCB
timing, and the memory component characteristics.
The FPGA input and output characteristics are usually fixed values, because the IOE structure of the devices
is fixed. Optimal PLL characteristics and clock routing characteristics do have an effect. Assuming the IP is
correctly constrained with autogenerated assignments, and you follow implementation rules, the design
should reach the stated performance figures.
Memory component characteristics are fixed for any given component or DIMM. Consider using faster
components or DIMMs in marginal cases when PCB skew may be suboptimal, or your design includes
multiple ranks when deration may cause read capture or write timing challenges. Using faster memory
components often reduces the memory data output skew and uncertainty easing read capture, and lowering
the memory’s input setup and hold requirement, which eases write timing.
Increased PCB skew reduces margins on address, command, read capture and write timing. If you are
narrowly failing timing on these paths, consider reducing the board skew (if possible), or using faster memory.
Address and command timing typically requires you to manually balance the reported setup and hold values
with the dedicated address and command phase in the IP.
Refer to the respective IP user guide for more information.
Multiple-slot multiple-rank UDIMM interfaces can place considerable loading on the FPGA driver. Typically
a quad rank interface can have thirty-six loads. In multiple-rank configurations, Altera's stated maximum
data rates are not likely to be achievable because of loading deration. Consider using different topologies,
for example registered DIMMs, so that the loading is reduced.
Deration because of increased loading, or suboptimal layout may result in a lower than desired operating
frequency meeting timing. You should close timing in the Quartus II software using your expected loading
and layout rules before committing to PCB fabrication.
Ensure that any design with an Altera PHY is correctly constrained and meets timing in the Quartus II
software. You must address any constraint or timing failures before testing hardware.
For more information about timing constraints, refer to the Analyzing Timing of Memory IP chapter.
Related Information
Analyzing Timing of Memory IP
Verifying Memory IP Using the SignalTap II Logic Analyzer
The SignalTap II logic analyzer shows read and write activity in the system.
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Verifying Memory IP Using the SignalTap II Logic Analyzer
12-11
For more information about using the SignalTap II logic analyzer, refer to the Design Debugging Using the
SignalTap II Embedded Logic Analyzer chapter in volume 3 of the Quartus II Software Handbook
To add the SignalTap II logic analyzer, follow these steps:
1. On the Tools menu click SignalTap II Logic Analyzer .
2. In the Signal Configuration window next to the Clock box, click … (Browse Node Finder).
3. Type the memory interface system clock (typically * phy_clk) in the Named box, for Filter select
SignalTap II: presynthesis and click List.
4. Select the memory interface system clock (<variation_name>_example_top|<variation_name>
:<variation_name>_inst|<variation_name>_controller_phy:<variation_name>_controller_phy_inst|phy_clk|phy_
clk) in Nodes Found and click > to add the signal to Selected Nodes.
5. Click OK.
6. Under Signal Configuration, specify the following settings:
•
•
•
•
•
For Sample depth, select 512
For RAM type, select Auto
For Trigger flow control, select Sequential
For Trigger position, select Center trigger position
ForTrigger conditions , select 1
7. On the Edit menu, click Add Nodes.
8. Search for specific nodes by typing *local* in the Named box, for Filter select SignalTap II: presynthesis
and click List.
9. Select the following nodes in Nodes Found and click > to add to Selected Nodes:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
local_address
local_rdata
local_rdata_valid
local_read_req
local_ready
local_wdata
local_write_req
pnf
pnf_per_byte
test_complete (trigger)
ctl_cal_success
ctl_cal_fail
ctl_wlat
ctl_rlat
Note: Do not add any memory interface signals to the SignalTap II logic analyzer. The load on these
signals increases and adversely affects the timing analysis.
10. Click OK.
11. To reduce the SignalTap II logic size, turn off Trigger Enable on the following bus signals:
•
•
•
•
•
local_address
local_rdata
local_wdata
pnf_per_byte
ctl_wlat
Debugging Memory IP
Send Feedback
Altera Corporation
12-12
emi_dg_011
2014.08.15
Signals to Monitor with the SignalTap II Logic Analyzer
• ctl_rlat
12. Right-click Trigger Conditions for the test_complete signal and select Rising Edge.
13. On the File menu, click Save, to save the SignalTap II . stp file to your project.
Note: If you see the message Do you want to enable SignalTap II file “stp1.stp” for the current project,
click Yes.
14. After you add signals to the SignalTap II logic analyzer, recompile your design by clicking Start
Compilation on the Processing menu.
15. Following compilation, verify that TimeQuest timing analysis passes successfully. In addition to this
FPGA timing analysis, check your PCB or system SDRAM timing. To run timing analysis, run the *_phy_
report_timing.tcl script.
a. On the Tools menu, click Tcl Scripts.
b. Select <variation_name>_phy_report_timing.tcl and click Run.
16. Connect the development board to your computer.
17. On the Tools menu, click SignalTap II Logic Analyzer.
18. Add the correct <project_name>.sof file to the SOF Manager:
a.
b.
c.
d.
Click ... to open the Select Program Files dialog box.
Select <your_project_name>.sof.
Click Open.
To download the file, click the Program Device button.
19. When the example design including SignalTap II successfully downloads to your development board,
click Run Analysis to run once, or click Autorun Analysis to run continuously.
Related Information
Design Debugging Using the SignalTap II Logic Analyzer
Signals to Monitor with the SignalTap II Logic Analyzer
This topic lists the memory controller signals you should consider analyzing for different memory interfaces.
This list is not exhaustive, but is a starting point.
For a description of each signal, refer to Volume 3: Reference Material of the External Memory Interface
Handbook.
Monitor the following signals for UniPHY designs:
•
•
•
•
•
•
•
•
•
•
•
•
avl_addr
avl_rdata
avl_rdata_valid
avl_read_req
avl_ready
avl_wdata
avl_write_req
fail
pass
afi_cal_fail
afi_cal_success
test_complete
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Hardware Debugging Guidelines
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
12-13
be_reg (QDRII only)
pnf_per_bit
rdata_reg
rdata_valid_reg
data_out
data_in
written_data_fifo|data_out
usequencer|state *
usequencer|phy_seq_rdata_valid
usequencer|phy_seq_read_fifo_q
usequencer|phy_read_increment_vfifo *
usequencer|phy_read_latency_counter
uread_datapath|afi_rdata_en
uread_datapath|afi_rdata_valid
uread_datapath|ddio_phy_dq
qvld_wr_address *
qvld_rd_address *
Related Information
Volume 3: Reference Material
Hardware Debugging Guidelines
Before debugging your design, confirm that it follows the Altera recommended design flow. Refer to the
Design Flow chapter in volume 1 of the External Memory Interface Handbook.
Always keep a record of tests, to avoid repeating the same tests later. To start debugging the design, perform
the following initial steps.
Related Information
Design Flow
Create a Simplified Design that Demonstrates the Same Issue
To help debugging create a simple design that replicates the issue.
A simple design should compile quickly and be easy to understand. Altera's external memory interface IP
generates an example top-level file that is ideal for debugging. The example top-level file uses all the same
parameters, pin-outs, and so on.
Measure Power Distribution Network
Measure voltages of the various power supplies on their hardware development platform over a suitable
time base and with a suitable trigger.
Ensure that you use an appropriate probe and grounding scheme. In addition, take the measurements directly
on the pins or vias of the devices in question, and with the hardware operational.
Debugging Memory IP
Send Feedback
Altera Corporation
12-14
emi_dg_011
2014.08.15
Measure Signal Integrity and Setup and Hold Margin
Measure Signal Integrity and Setup and Hold Margin
Measure the signals on the PCB. When measuring any signal, consider the edge rate of the signal, not just
its frequency. Modern FPGA devices have very fast edge rates, therefore you must use a suitable oscilloscope,
probe, and grounding scheme when you measure the signals.
You can take measurements to capture the setup and hold time of key signal classes with respect to their
clock or strobe. Ensure that the measured setup and hold margin is at least better than that reported in the
Quartus II software. A worse margin indicates a timing discrepancy somewhere in the project; however, this
issue may not be the cause of your problem.
Vary Voltage
Vary the voltage of your system, if you suspect a marginality issue.
Increasing the voltage usually causes devices to operate faster and also usually provides increased noise
margin.
Use Freezer Spray and Heat Gun
If you have an intermittent marginal issue, apply cold or heat to the interface to stress the components.
Cooling ICs causes them to run faster, which makes timing easier. Conversely, heating ICs causes them to
run slower, which makes timing more difficult.
If cooling or heating corrects the problem, it is probably a timing issue.
Operate at a Lower Speed
Test the interface at a lower speed. If the interface works at a lower speed, the interface is correctly pinned
out and functional.
If the interface fails at a lower speed, determine if the test is valid. Many high-speed memory components
have a minimal operating frequency, or require subtly different configurations when operating at a lower
speeds.
For example, DDR, DDR2, or DDR3 SDRAM typically requires modification to the following parameters
if you want to operate the interface at lower speeds:
• tMRD
• tWTR
• CAS latency and CAS write latency
Determine Whether the Issue Exists in Previous Versions of Software
Hardware that works before an update to either the Quartus II software or the memory IP indicates that the
development platform is not the issue.
However, the previous generation IP may be less susceptible to a PCB issue, masking the issue.
Determine Whether the Issue Exists in the Current Version of Software
Designs are often tested using previous generations of Altera software or IP.
Projects may not be upgraded for various reasons:
• Multiple engineers are on the same project. To ensure compatibility, a common release of Altera software
is used by all engineers for the duration of the product development. The design may be several releases
behind the current Quartus II software version.
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Try A Different PCB
12-15
• Many companies delay before adopting a new release of software so that they can first monitor Internet
forums to get a feel for how successful other users say the software is.
• Many companies never use the latest version of any software, preferring to wait until the first service
pack is released that fixes the primary issues.
• Some users may only have a license for the older version of the software and can only use that version
until their company makes the financial decision to upgrade.
• The local interface specification from Altera IP to the customer's logic sometimes changes from software
release to software release. If you have already spent resources designing interface logic, you may be
reluctant to repeat this exercise. If a block of code is already signed off, you may be reluctant to modify
it to upgrade to newer IP from Altera..
In all of the above scenarios, you must determine if the issue still exists in the latest version of the Altera
software. Bug fixes and enhancements are added to the Altera IP every release. Depending on the nature of
the bug or enhancement, it may not always be clearly documented in the release notes.
Finally, if the latest version of the software resolves the issue, it may be easier to debug the version of software
that you are using.
Try A Different PCB
If you are using the same Altera IP on several different hardware platforms, determine whether the problem
occurs on all platforms or just on one.
Multiple instances of the same PCB, or multiple instances of the same interface, on physically different
hardware platforms may exhibit different behavior. You can determine if the configuration is fundamentally
not working, or if some form of marginality is involved in the issue.
Issues are often reported on the alpha build of a development platform. These are produced in very limited
numbers and often have received limited bare-board testing, or functional testing. These early boards are
often more unreliable than production quality PCBs.
Additionally, if the IP is from a previous project to help save development resources, determine whether the
specific IP configuration works on a previous platform.
Try Other Configurations
Designs are often quite large, using multiple blocks of IP in many different combinations. Determine whether
any other configurations work correctly on the development platform.
The full project may have multiple external memory controllers in the same device, or may have configurations
where only half the memory width or frequency is required. Find out what does and does not work to help
the debugging of the issue.
Debugging Checklist
The following checklist is a good starting point when debugging an external memory interface.
Table 12-1: CheckItem
Check
Item
Try a different fit.
Check IP parameters at the operating frequency (tMRD, tWTR for example).
Ensure you have constrained your design with proper timing deration and have closed timing.
Debugging Memory IP
Send Feedback
Altera Corporation
12-16
emi_dg_011
2014.08.15
Catagorizing Hardware Issues
Check
Item
Simulate the design. If it fails in simulation, it will fail in hardware.
Analyze timing.
Place and assign RUP and RDN (OCT).
Measure the power distribution network (PDN).
Measure signal integrity.
Measure setup and hold timing.
Measure FPGA voltages.
Vary voltages.
Heat and cool the PCB.
Operate at a lower or higher frequency.
Check board timing and trace Information.
Check LVDS and clock sources, I/O voltages and termination.
Check PLL clock source, specification, and jitter.
Ensure the correct number of PLL phase steps take place during calibration. If the number
stated in the IP does not match the number, you may have manually altered the PLL.
Retarget to a smaller interface width or a single bank.
Catagorizing Hardware Issues
The following topics divide issues into categories. By determining which category (or categories) an issue
belongs in, you may be able to better focus on the cause of the issue.
Hardware issues fall into three categories:
• Signal integrity issues
• Hardware and calibration issues
• Intermittent issues
Signal Integrity Issues
Many design issues, including some at the protocol layer, can be traced back to signal integrity problems.
You should check circuit board construction, power systems, command, and data signaling to determine if
they meet specifications.
If infrequent, random errors exist in the memory subsystem, product reliability suffers. Check the bare
circuit board or PCB design file. Circuit board errors can cause poor signal integrity, signal loss, signal timing
skew, and trace impedance mismatches. Differential traces with unbalanced lengths or signals that are routed
too closely together can cause crosstalk.
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Characteristics of Signal Integrity Issues
12-17
Characteristics of Signal Integrity Issues
Signal integrity problems often appear when the performance of the hardware design is marginal.
The design may not always initialize and calibrate correctly, or may exhibit occasional bit errors in user
mode. Severe signal integrity issues can result in total failure of an interface at certain data rates, and sporadic
component failure because of electrical stress. PCB component variance and signal integrity issues often
show up as failures on one PCB, but not on another identical board. Timing issues can have a similar
characteristic. Multiple calibration windows or significant differences in the calibration results from one
calibration to another can also indicate signal integrity issues.
Evaluating SignaI Integrity Issues
Signal integrity problems can only really be evaluated in two ways:
• direct measurement using suitable test equipment like an oscilloscope and probe
• simulation using a tool like HyperLynx or Allegro PCB SI
Compare signals to the respective electrical specification. You should look for overshoot and undershoot,
non-monotonicity, eye height and width, and crosstalk.
Skew
Ensure that all clocked signals, commands, addresses, and control signals arrive at the memory inputs at the
same time.
Trace length variations cause data valid window variations between the signals, reducing margin. For example,
DDR2-800 at 400 MHz has a data valid window that is smaller than 1,250 ps. Trace length skew or crosstalk
can reduce this data valid window further, making it difficult to design a reliably operating memory interface.
Ensure that the skew figure previously entered into the Altera IP matches that actually achieved on the PCB,
otherwise Quartus II timing analysis of the interface is accurate.
Crosstalk
Crosstalk is best evaluated early in the memory design phase.
Check the clock-to-data strobes, because they are bidirectional. Measure the crosstalk at both ends of the
line. Check the data strobes to clock, because the clocks are unidirectional, these only need checking at the
memory end of the line.
Power System
Some memory interfaces draw current in spikes from their power delivery system as SDRAMs are based on
capacitive memory cells.
Rows are read and refreshed one at a time, which causes dynamic currents that can stress any power
distribution network (PDN). The various power rails should be checked either at or as close as possible to
the SDRAM power pins. Ideally, you should use a real-time oscilloscope set to fast glitch triggering to check
the power rails.
Clock Signals
The clock signal quality is important for any external memory system.
Measurements include frequency, digital core design (DCD), high width, low width, amplitude, jitter, rise,
and fall times.
Read Data Valid Window and Eye Diagram
The memory generates the read signals. Take measurements at the FPGA end of the line.
Debugging Memory IP
Send Feedback
Altera Corporation
12-18
emi_dg_011
2014.08.15
Write Data Valid Window and Eye Diagram
To ease read diagram capture, modify the example driver to mask writes or modify the PHY to include a
signal that you can trigger on when performing reads.
Write Data Valid Window and Eye Diagram
The FPGA generates the write signals. Take measurements at the memory device end of the line.
To ease write diagram capture, modify the example driver to mask reads or modify the PHY export a signal
that is asserted when performing writes.
OCT and ODT Usage
Modern external memory interface designs typically use OCT for the FPGA end of the line, and ODT for
the memory component end of the line. If either the OCT or ODT are incorrectly configured or enabled,
signal integrity problems occur.
If the design uses OCT, RUP or RDN pins must be placed correctly for the OCT to work. If you do not place
these pins, the Quartus II software allocates them automatically with the following warning:
Warning: No exact pin location assignment(s) for 2 pins of 110 total pins
Info: Pin termination_blk0~_rup_pad not assigned to an exact location on the device
Info: Pin termination_blk0~_rdn_pad not assigned to an exact location on the device
If you see these warnings, the RUP and RDN pins may have been allocated to a pin that does not have the
required external resistor present on the board. This allocation renders the OCT circuit faulty, resulting in
unreliable UniPHY calibration and or interface behavior. The pins with the required external resistor must
be specified in the Quartus II software.
For the FPGA, ensure that you perform the following:
• Specify the RUP and RDN pins in either the projects HDL port list, or in the assignment editor (termination_blk0~_rup_pad/ termination_blk0~_rdn_pad).
• Connect the RUP and RDN pins to the correct resistors and pull-up and pull-down voltage in the schematic
or PCB.
• Contain the RUP and RDN pins within a bank of the device that is operating at the same VCCIO voltage
as the interface that is terminated.
• Check that only the expected number of RUP and RDN pins exists in the project pin-out file. Look for
Info: Created on-chip termination messages at the fitter stage for any calibration blocks not expected
in your design.
• Review the Fitter Pin-Out file for RUP and RDN pins to ensure that they are on the correct pins, and that
only the correct number of calibration blocks exists in your design.
• Check in the fitter report that the input, output, and bidirectional signals with calibrated OCT all have
the termination control block applicable to the associated RUP and RDN pins.
For the memory components, ensure that you perform the following:
• Connect the required resistor to the correct pin on each and every component, and ensure that it is pulled
to the correct voltage.
• Place the required resistor close to the memory component.
• Correctly configure the IP to enable the desired termination at initialization time.
• Check that the speed grade of memory component supports the selected ODT setting.
• Check that the second source part that may have been fitted to the PCB, supports the same ODT settings
as the original
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Hardware and Calibration Issue Characteristics
12-19
Hardware and Calibration Issue Characteristics
Hardware and calibration issues have the following definitions:
• Calibration issues result in calibration failure, which usually causes the ctl_cal_fail signal to be asserted.
• Hardware issues result in read and write failures, which usually causes the pass not fail (pnf) signal to be
asserted.
Note: Ensure that functional, timing, and signal integrity issues are not the direct cause of your hardware
issue, as functional, timing or signal integrity issues are usually the cause of any hardware issue.
Evaluating Hardware and Calibration Issues
Use the following methods to evaluate hardware and calibration issues:
• Evaluate hardware issues using the SignalTap II logic analyzer to monitor the local side read and write
interface with the pass or fail or error signals as triggers
• Evaluate calibration issues using the SignalTap II logic analyzer to monitor the various calibration,
configuration with the pass or fail or error signals as triggers, but also use the debug toolkit and system
consoles when available
• For more information about debug toolkit and the type of signals for debugging external memory
interfaces, refer to the External Memory Interface Debug Toolkit chapter in volume 3 of the External
Memory Interface Handbook.
Consider adding core noise to your design to aggravate margin timing and signal integrity issues. Steadily
increasing the stress on the external memory interface is an ideal way to assess and understand the cause of
any previously intermittent failures that you may observe in your system. Using the SignalTap II probe tool
can provide insights into the source or cause of operational failure in the system.
Steadily increasing stress on the external memory interface allows you to assess and understand the impact
that such factors have on the amount of timing margin and resynchronization window. Take measurements
with and without the additional stress factor to allow evaluation of the overall effect.
Steadily increase the stress on the interface in the following order:
1. Increase the interface utilization by modifying the example driver to focus on the types of transactions
that exhibit the issue.
2. Increase the SNN or aggressiveness of the data pattern by modifying the example driver to output in
synchronization PRBS data patterns, or hammer patterns.
3. Increase the stress on the PDN by adding more and more core noise to your system. Try sweeping the
fundamental frequency of the core noise to help identify resonances in your power system.
Related Information
UniPHY External Memory Interface Debug Toolkit
Write Timing Margin
Determine the write timing margin by phase sweeping the write clock from the PLL.
Use sources and probes to dynamically control the PLL phase offset control, to increase and decrease the
write clock phase adjustment so that the write window size may be ascertained.
Remember that when sweeping PLL clock phases, the following two factors may cause operational failure:
• The available write margin.
Debugging Memory IP
Send Feedback
Altera Corporation
12-20
Read Timing Margin
emi_dg_011
2014.08.15
• The PLL phase in a multi-clock system.
The following code achieves this adjustment. You should use sources and probes to modify the respective
output of the PLL. Ensure that the example driver is writing and reading from the memory while observing
the pnf_per_byte signals to see when write failures occur:
/////////////////
wire [7:0] Probe_sig;
wire [5:0] Source_sig;
PhaseCount PhaseCounter (
.resetn (1'b1),
.clock (pll_ref_clk),
.step (Source_sig[5]),
.updown (Source_sig[4]),
.offset (Probe_sig)
);
CheckoutPandS freq_PandS (
.probe (Probe_sig),
.source (Source_sig)
);
ddr2_dimm_phy_alt_mem_phy_pll_siii pll (
.inclk0 (pll_ref_clk),
.areset (pll_reset),
.c0 (phy_clk_1x), // hR
.c1 (mem_clk_2x), // FR
.c2 (aux_clk), // FR
.c3 (write_clk_2x), // FR
.c4 (resync_clk_2x), // FR
.c5 (measure_clk_1x), // hR
.c6 (ac_clk_1x), // hR
.phasecounterselect (Source_sig[3:0]),
.phasestep (Source_sig[5]),
.phaseupdown (Source_sig[4]),
.scanclk (scan_clk),
.locked (pll_locked_src),
.phasedone (pll_phase_done)
);
Read Timing Margin
Assess the read timing margin by using sources and probes to manually control the DLL phase offset feature.
Open the autogenerated DLL using ALT_DLL and add the additionally required offset control ports. This
action allows control and observation of the following signals:
dll_delayctrlout[5:0], // Phase output control from DLL to DQS pins (Gray Coded)
dll_offset_ctrl_a_addnsub, // Input add or subtract the phase offset value
dll_offset_ctrl_a_offset[5:0], // User Input controlled DLL offset value (Gray Coded)
dll_aload, // User Input DLL load command
dll_dqsupdate, // DLL Output update required signal.
In examples where the applied offset applied results in the maximum or minimum dll_delayctrlout[5:0]
setting without reaching the end of the read capture window, regenerate the DLL in the next available phase
setting, so that the full capture window is assessed.
Modify the example driver to constantly perform reads (mask writes). Observe the pnf_per_byte signals
while the DLL capture phase is manually modified to see when failures begin, which indicates the edge of
the window.
A resynchronization timing failure can indicate failure at that capture phase, and not a capture failure. You
should recalibrate the PHY with the calculated phase offset to ensure that you are using the true read-capture
margin.
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Address and Command Timing Margin
12-21
Address and Command Timing Margin
You set the address and command clock phase directly in the IP. Assuming you enter the correct board trace
model information into the Quartus II software, the timing analysis should be correct.
If you want to evaluate the address and command timing margin, use the same process as in “Write Timing
Margin”, only phase step the address and command PLL output (c6 ac_clk_1x). You can achieve this effect
using the debug toolkit or system console.
Refer to the External Memory Interface Debug Toolkit chapter in volume 3 of the External Memory Interface
Handbook.
Related Information
• Write Timing Margin on page 12-19
• UniPHY External Memory Interface Debug Toolkit
Resynchronization Timing Margin
Observe the size and margins available for resynchronization using the debug toolkit or system console.
Refer to External Memory Interface Debug Toolkit chapter in volume 3 of the External Memory Interface
Handbook.
Additionally for PHY configurations that use a dedicated PLL clock phase (as opposed to a resynchronization
FIFO buffer), use the same process as described in “Write Timing Margin”, to dynamically sweep
resynchronization margin (c4 resynch_clk_2x).
Related Information
• Write Timing Margin on page 12-19
• UniPHY External Memory Interface Debug Toolkit
Postamble Timing Issues and Margin
The postamble timing is set by the PHY during calibration.
You can diagnose postamble issues by viewing the pnf_per_byte signal from the example driver. Postamble
timing issues mean only read data is corrupted during the last beat of any read request.
Intermittent Issue Evaluation
Intermittent issues are typically the hardest type of issue to debug—they appear randomly and are hard to
replicate.
Errors that occur during run-time indicate a data-related issue, which you can identify by the following
actions:
•
•
•
•
Add the SignalTap II logic analyzer and trigger on the post-trigger pnf
Use a stress pattern of data or transactions, to increase the probability of the issue
Heat up or cool down the system
Run the system at a slightly faster frequency
If adding the SignalTap II logic analyzer or modifying the project causes the issue to go away, the issue is
likely to be placement or timing related.
Debugging Memory IP
Send Feedback
Altera Corporation
12-22
emi_dg_011
2014.08.15
EMIF Debug Toolkit Overview and Usage Flow
Errors that occur at start-up indicate that the issue is related to calibration, which you can identify by the
following actions:
• Modify the design to continually calibrate and reset in a loop until the error is observed
• Where possible, evaluate the calibration margin either from the debug toolkit or system console.
Note: Refer to the External Memory Interface Debug Toolkit chapter in volume 3 of the External Memory
Interface Handbook.
• Capture the calibration error stage or error code, and use this information with whatever specifically
occurs at that stage of calibration to assist with your debugging of the issue.
Related Information
UniPHY External Memory Interface Debug Toolkit
EMIF Debug Toolkit Overview and Usage Flow
The EMIF Debug Toolkit is a Tcl-based interface that runs on your PC and communicates via a JTAG
connection to enable you to debug your external memory interface on the circuit board, retrieve calibration
status, and perform margining activities.
The toolkit consists of the following parts:
• DDR2 and DDR3 SDRAM Controllers
• Avalon Memory-Mapped (Avalon-MM) slave interface
• JTAG Avalon master
The EMIF toolkit allows you to display information about your external memory interface and generate
calibration and margining reports. The toolkit can aid in diagnosing the type of failure that may be occurring
in your external memory interface, and help identify areas of reduced margin that might be potential failure
points.
The general toolkit usage flow is as follows:
1. (Optional) Generate your IP core with the CSR port enabled and with the CSR communication interface
type properly set.
2. Recompile the design.
3. Connect your PC's download cable (for example, ByteBlaster II download cable) to the JTAG port on
the development board.
4. Program the device.
5. Specify project settings using the EMIF Debug Toolkit.
6. Generate calibration report and interpret calibration results using the EMIF Debug Toolkit.
Note: For more information about the EMIF Debug Toolkit, refer to the External Memory Interface Debug
Toolkit chapter in volume 3 of the External Memory Interface Handbook.
Related Information
UniPHY External Memory Interface Debug Toolkit
Altera Corporation
Debugging Memory IP
Send Feedback
emi_dg_011
2014.08.15
Document Revision History
12-23
Document Revision History
Date
Version
August 2014
2014.08.15
Maintenance release.
December 2013
2013.12.16
• Removed references to ALTMEMPHY.
• Removed local_wdata_req from step 9 of Verifying Memory IP Using
SignalTap II Logic Analyzer.
November 2012
4.2
Changed chapter number from 11 to 12.
June 2012
4.1
Added Feedback icon.
November 2011
4.0
Added Debug Toolkit section.
June 2011
3.0
Removed leveling information from ALTMEMPHY Calibration Stages and
UniPHY Calibration Stages chapter.
December 2010
2.1
• Added new chapter: UniPHY Calibration Stages.
• Added new chapter: DDR2 and DDR3 SDRAM Controllers with UniPHY
EMIF Toolkit.
July 2010
2.0
Updated for 10.0 release.
January 2010
1.2
Corrected typos.
December 2009
1.1
Added Debug Toolkit for DDR2 and DDR3 SDRAM High-Performance
Controllers chapter and ALTMEMPHY Calibration Stages chapter.
November 2009
1.0
Initial release.
Debugging Memory IP
Send Feedback
Changes
Altera Corporation
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement