Honored Contributor
Honored ContributorThe master that is *not* providing the clock input will automatically have a clock crossing adapter inserted by QSYS. I tried to inline a picture but the forum won't accept it.
https://drive.google.com/file/d/0b5drao0__dlkv2dzwfhaawo1tdq/edit?usp=sharing You can re-create the example in Qsys very quickly. Do File -> "New system". Delete the clock input block. Add two "Avalon-MM StatixV Hard IP for PCI Express" (avmm) cores. In the wizard only enable BAR0 as 32-bit then finish. Add "On-Chip Memory (RAM or ROM)". Couple up the onchip memory to avmm0 coreclkout, nreset_status and Rxm_BAR0. Now also couple onchip memory to avmm1 Rxm_BAR0. Add the cra ports on respective avmm BAR ports. Export all the refclock, transciever reconfig etc. Change base address of onchip to be 0x4000 on both core's BAR0. The Avalon Memory Mapped Slave is actually actually two networks, command and response. You will see this if you run System -> Show System with QSYS Fabric Components. It's pretty overwhelming to start. There are two "Avalon-ST Handshake Clock Crosser" components inserted towards the end. These handle the clock crossing between the pcie coreclkout domains. One is for commands (avmm1 -> avmm0), the other for responses (avmm0 -> avmm1). The usage of these 'implicit' crossers is adequate on a small system. If you add lots of slave devices the QSYS fabric gets large. For instance 2 masters, 3 slaves requires 6 Handshake Clock Crossers (3 pairs). You get an extra pair for each foreign clock domain master to slave connection. In this case it's better to put all the slaves behind a single explicit "Avalon-MM Clock Crossing Bridge". You then get a single clock crosser pair between the foreign master's clock domain and the bridge. It's easy to create lots of clock crossers and they can be hard to find if you didn't intend to make them. I think the 13.1 QSYS tool is better at showing this.
