10.3.7. Modifying the Example Driver to Replicate the Failure
When the example design works but your custom design doesn't, the underlying problem may be either of the following:
- Related to the way that the local interface transactions are occurring. You should probe and compare using the Signal Tap II analyzer.
- Related to the types or format of transactions on the external memory interface. You should try modifying the example design to replicate the problem.
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 performs only 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.
For Arria® 10 and Stratix® 10 interfaces, you can enable the Traffic Generator 2.0 in the example design, allowing you to use the EMIF Debug Toolkit to configure different traffic pattern for debug purposes.
A problem that you can replicate in RTL simulation indicates a potential bug in the IP. You should recheck the IP parameters. A problem that you can not replicate in RTL simulation indicates a timing issue on the PCB. You can try to replicate the issue on an Intel development platform to rule out a board issue.
Functional simulation allows you to identify any issues with the configuration of either the memory controller or the PHY. You can then 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.
Did you find the information on this page useful?