When I configure the HPS in QSys (Quartus Prime 16.0), I can determine the Pin muxing in the "Peripheral Pins" section. In the "Peripherals Mux Table" on the bottom, I can see how the various controllers shall be connected to dedicated pins. For example, on my Cyclone V, if I configure I2C0 to use "HPS I/O Set 1" I can see that the I2C0 entries for pins I2C0_SDA and I2C0_SCL get highlighted. I interpret this as: "Pin I2C0_SDA and I2C0_SCL will be connected to I2C0." I guess that I2C0_SDA and I2C0_SCL are placeholders for the actual pins which are PIN_C23 and PIN_D22 for that chip. So more specifically, I interpret this as: "PIN_C23 and PIN_D22 are connected to I2C0."Now, I do not understand why I can (or must) export the hps_io conduit. In my top-level design file, I additionally have to connect the I2C0 to the correct pins but theoretically, I could easily connect I2C0 to different pins so that the whole configuration in QSys would be useless? As this seems so absurd to me, I am sure that I misunderstood something. Could someone please explain to me where my mistake is?
Hi, you are right with regards to the I2C routing (they have dedicated pin location assignment which correlates to actual pins). I may be wrong, but this is how I interpret the need to export the hps_io conduit:
Hi, thanks for your reply but I guess you're wrong when you say that the hps pin location assignments are necessary so that the qsys design can be reused in different Cyclone V SoC packages. It seems to me that the pin location assignments for hps-pins are actually ignored. I have tested the following:
DrTobbe you are correct, except the last part. Drive strength and slew rate assignments should take effect, but you hit the nail on the head why those interfaces need to be exposed. The HPS pins in Arria/Cyclone V are limited compared to the FPGA pins so drive strength and slew rate are probably the only assignments you can set, the rest of the I/O features are simply not present.It's important that you *do not* manually assign the HPS pins because the HPS component in Qsys hands this information off to Quartus already and if you make a conflicting pin location assignment you'll probably get a confusing error message out of Quartus when the compilation fails.