--- Quote Start ---
Your hint to look at the VTAP location points me in the exact location to see the similar picture of figure 7 on page 18 of your document, for quartus 10.1. Thanks for that.
--- Quote End ---
You're welcome.
--- Quote Start ---
However...sorry for being such a newbie... I'm missing the point your are trying to make in par 3.5.3. on page 17 and the figure on page 18. I try to understand the text, but this is higher science for me.
--- Quote End ---
No need to apologize. The best way to learn is to try to understand why and how things work.
The purpose of the comment at the start of that section:
“Test what you fly, and fly what you test”
Is that you should simulate exactly what you plan on testing in hardware. If you simulate a different IP block, than the you use in hardware (synthesize), then what's the point of your simulation?
Altera recommends using a BFM for simulation, and then expects you to trust them that a completely different component, the JTAG-to-Avalon-MM bridge "Just works" - there is no official simulation support for that component. So when you test your Avalon-MM slave IP using a BFM and then synthesize hardware and use a JTAG-to-Avalon-MM bridge, although your slave IP is common, the master IP is not, so you are
not testing what you fly. Your slave component might have bugs that only show up in the hardware test and not in simulation, because the masters generate different Avalon-MM transactions.
The JTAG-to-Avalon-MM analysis document that the tutorial links to has a deeper analysis of that component, and there are minor errors in its design.
Cheers,
Dave
Honored Contributor
