Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

HPS Configuration in QSys: Why is hps_io exported?

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?

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    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:

    • The same qsys design can be reused in different Cyclone V SoC packages, where the actual pin location may differ from one another

    • How does Quartus knows which pins to assign to, in this case?

    • By exporting the hps_io pins, you then assign the exposed ports at the top level of the verilog instantiation (for example, I call this verilog instantiation name "soc")

    • During full compilation, Quartus looks at the soc module, interprets that pin assignments are needed for the peripherals (I2C) for example, and searches the corresponding pin location that it needs to allocate the peripherals to.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    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:

    • When I delete the pin location assignments of an ordinary FPGA pin, the fitter will give me warnings about missing location assignments.

    • When I delete the pin location assignments of I2C0 pins, the fitter does not complain about locations, it just complains about missing drive strength and slew rate.

    Therefore, my current theory is that I have to export the hps_io pins so that they "exist" in quartus and it will be possible to configure drive strength and slew rate. But I could imagine that these values will be ignored, too?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    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.