Gradually determining the names of the interface IP necessary in Qsys for my SOC

MYSTERY NAMES AND DESCRIPTIONS

I imagine that formal names for programs and IP have changed over the years, perhaps when Intel acquired Altera but certainly it could have happened from time to time based on marketing or design scope changes. What I know for certain is that there are inconsistencies in how various items are named that can be confusing to a new user. 

For example, the tool Qsys at some point became Platform Designer, which is the current name in the menu of Quartus. However, many documents refer to this as Qsys and older videos show that the menu item was labeled Qsys in earlier versions. 

More importantly, I find that the names for various interface IP provided as part of Qsys have names that don't align with the descriptions of functionality in the Cyclone documentation nor in the Qsys/Platform Designer documentation. Figuring out what IP provides a function described across the breadth of all the manuals is an unnecessary challenge.

Even the names that show up when a particular IP is included in a demonstration or reference project doesn't fully enlighten. Some of the interconnect IP used for the F2H, H2F and H2F lightweight bridges have descriptions that read JTAG to Avalon Master Bridge, but what does JTAG have to do with these allowing FPGA and HPS cross communication of memory mapped addresses? 

SLOGGING THROUGH VARIOUS TOMES TO BUILD UP MY LIST

The HPS manual as part of Cyclone is 706 pages. The Platform Designer manual is 777 pages. The Quartus II handbook is 1,681 pages long. Nowhere do the names one sees in the IP list of the running Qsys show up across all these pages. 

I am reduce to watching videos, reading web posts and examining various reference/demo designs to learn what names relate to each item. When is the HPS_Only_Master used? When is the Avalon_MM_Master_Agent used? When is the Avalon_MM_Pipelined_Bridge used? 

READY TO START EXPERIMENTS 

At this point it makes sense to try to use some of the IP that I see in reference designs to do simple things that are similar to or the same as what will be needed in my full design. Once I see these work properly I can try alternatives or get more sophisticated. 

SIMPLEST COMMUNICATIONS EXPERIENCE PASSING ADDRESS AND GRABBING WORD

The new areas for me in this version of the project are the bridge communications between the HPS and FPGA sides as well as the memory mapped file locked into physical memory within Linux. The starter experiment is just to see that I can look up an address in Linux and send that successfully to the FPGA side where I can access it. 

This is what I will build and play with next. Once I get that working, I can add the next level which is used of the F2H bridge to read various words from the area whose address I just passed along. The combination gives me confidence in the first of the new areas described above, leaving just the Linux bashing experiments to get the virtual cartridge file opened in a contiguous set of physical pages and memory mapped within Linux.