Altera_Forum
Honored Contributor
Honored ContributorAccessing HPS Pins
Hello,
I know I can route HPS pins to the FPGA side but is it possible to do the opposite, route FPGA side logic to HPS part pins? Thank youForum Discussion
15 Replies
Altera_ForumI just checked 13.0 SP1 and I see it in the UI but it can't be enabled (yet). If you go to the pin multiplexing tab in the HPS component and scroll to the bottom you'll see some columns called "Loan I/O". The idea is that when you enable the loaner I/O you'll pop a pin triplet of signals (in, out, out_en) so that you can control the pin from your FPGA logic. This feature is indended for low speed I/O only since the HPS I/O do not share all the same capabilities as the regular FPGA I/O that you are accustom to.
- Altera_Forum
Thank you for you reply.
Regarding this part about low speed I/O. When you say low speed, you're talking about ~1MHz? - Altera_Forum
More than that but it depends on what is hooked up to it on the board, the board design, constraints, on-chip timing needs, etc.. (the same sort of stuff you worry about with the FPGA I/O).
The biggest limiting factor will be the lack of delay chains and registers in the HPS I/O so any interface tuning will be limited to the fitter moving registers around in the FPGA to adjust the clock and data relationships. What I've been telling people is that unless you use them like PIOs then you better know how to write .sdc constraints :) - Altera_Forum
Thank you.
I have to consider this when I start to think about a custom board. :) - Altera_Forum
Adding a bit of colour to the "slow-speed", I have run into an issue while using the HPS Loan I/O - the altddio component that I needed to use for a 125MHz RGMII interface cannot be implemented across the FPGA-to-HPS interface.
This seems to be more of a tool limitation to me, but it's a showstopper for now. In short, don't expect to be able to use the flops within the I/O block via the loaned I/O. - Altera_Forum
That's correct, you will not have access to the I/O flip flops and many of the other features that the FPGA I/O offer like scalable delays. This is not actually a tool issue, the I/O used by the HPS are physically different than the ones on the FPGA side of the Cyclone/Arria V SoC device.
In 13.1 those I/O paths to/from the FPGA and the HPS I/O are not characterized yet. If you need to close timing on those paths you can contact your FAE to request a patch to add this timing information. - Altera_Forum--- Quote Start --- This is not actually a tool issue, the I/O used by the HPS are physically different than the ones on the FPGA side of the Cyclone/Arria V SoC device. --- Quote End --- I see your point about the I/O not being general-purpose FPGA I/O. But given that the I/O that I am loaning to the fabric are in fact used to implement an RGMII to the HPS MAC, then it's clear that the I/O themselves are capable of implementing a DDR function, and I don't see why I shouldn't be able to, via some constraint magic, be able to configure them and use them as such from the FPGA fabric. This is what I mean by a "tool issue"; the silicon is clearly capable of implementing the function that I need.
- Altera_Forum
I'm not overly familar with the HPS I/O but I suspect because there is no clocking mechanism in the I/O (input/output registers are independent of the HPS I/O except in the case of SDRAM) that it will not be possible to loan those HPS EMAC I/O to the FPGA and be able to implement double data rate interfaces relying on the DDR functionality being included in the I/O itself. My understanding is that HPS I/O loaned out to the FPGA for the most part is pin <--> I/O buffer <--> muxes <--> FPGA fabric. I suspect the double data rate that is implemented for the HPS EMACs is independent of the I/O themselves and as a result FPGA logic borrowing those same I/O will not inherit that functionality. In other words the path between the HPS EMAC and the HPS I/O would be pin <--> I/O buffer <--> muxes <--> registers (where I suspect DDR is implemented) <--> EMAC
If you need that functionality and have not done so I recommend opening a service request so that someone can take a closer look at this. If it's really just a tools issue then that most likely can be resolved but I suspect it's a limitation of the implementation. - Altera_Forum
I agree with your reply, and yes I opened an SR a few days ago; I'll be sure to post the result here.
I was unable to reply privately due to too few posts... The SR number is 11021457 - altddio_out:altddio_out_component can't drive HPS loan I/O - Altera_Forum
The HPS loan I/O issue went from bad to worse for me, as we couldn't even successfully drive out a 1Hz signal. The cause was my exceptional ignorance...
It turns out that the HPS I/O are entirely controlled by software (via an HPS h/w block called the System Monitor). So in order for the pinmuxing configuration to take effect, one must build a custom preloader, as described in http://www.rocketboards.org/foswiki/documentation/preloaderubootcustomization We don't have this working quite yet, since we are running into issues building the preloader, but I'll post any updates here.
