- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 youLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for you reply.
Regarding this part about low speed I/O. When you say low speed, you're talking about ~1MHz?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 :)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you.
I have to consider this when I start to think about a custom board. :)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Update: we received notification of a patch to help with timing closure of the HSP loan I/O using Quartus 13.1. While this does not resolve our specific altddio issue, it does generally help with HPS Loan I/O and so I post the link to the solution ID here:
http://www.altera.com/support/kdb/solutions/rd01082014_212.html?gsa_pos=1&wt.oss_r=1&wt.oss=loaner io- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, I've tried to share the HPS MAC Pins with my FPGA, So I can use the TSE MAC instead of the MAC inside the HPS.
Everything seems ok but I am getting this: Error (15874): Output port DATAOUT of DDIO_OUT primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_out4:the_rgmii_out4|altddio_out:altddio_out_component|ddio_out_jhb:auto_generated|ddio_outa[0]" must drive input port I of I/O OBUF primitive or input port DATAIN of DELAY_CHAIN primitive. Error (15874): Output port DATAOUT of DDIO_OUT primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_out4:the_rgmii_out4|altddio_out:altddio_out_component|ddio_out_jhb:auto_generated|ddio_outa[1]" must drive input port I of I/O OBUF primitive or input port DATAIN of DELAY_CHAIN primitive. Error (15874): Output port DATAOUT of DDIO_OUT primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_out4:the_rgmii_out4|altddio_out:altddio_out_component|ddio_out_jhb:auto_generated|ddio_outa[2]" must drive input port I of I/O OBUF primitive or input port DATAIN of DELAY_CHAIN primitive. Error (15874): Output port DATAOUT of DDIO_OUT primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_out4:the_rgmii_out4|altddio_out:altddio_out_component|ddio_out_jhb:auto_generated|ddio_outa[3]" must drive input port I of I/O OBUF primitive or input port DATAIN of DELAY_CHAIN primitive. Error (15874): Output port DATAOUT of DDIO_OUT primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_out1:the_rgmii_out1|altddio_out:altddio_out_component|ddio_out_ghb:auto_generated|ddio_outa[0]" must drive input port I of I/O OBUF primitive or input port DATAIN of DELAY_CHAIN primitive. Error (15871): Input port DATAIN of DDIO_IN primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_in4:the_rgmii_in4|altddio_in:altddio_in_component|ddio_in_jsd:auto_generated|ddio_ina[3]" must come from an I/O IBUF or DELAY_CHAIN primitive Error (15871): Input port DATAIN of DDIO_IN primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_in4:the_rgmii_in4|altddio_in:altddio_in_component|ddio_in_jsd:auto_generated|ddio_ina[2]" must come from an I/O IBUF or DELAY_CHAIN primitive Error (15871): Input port DATAIN of DDIO_IN primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_in4:the_rgmii_in4|altddio_in:altddio_in_component|ddio_in_jsd:auto_generated|ddio_ina[1]" must come from an I/O IBUF or DELAY_CHAIN primitive Error (15871): Input port DATAIN of DDIO_IN primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_in4:the_rgmii_in4|altddio_in:altddio_in_component|ddio_in_jsd:auto_generated|ddio_ina[0]" must come from an I/O IBUF or DELAY_CHAIN primitive Error (15871): Input port DATAIN of DDIO_IN primitive "cpusoc_cpu:u0|cpusoc_cpu_tse_mac_1:tse_mac_1|altera_eth_tse_mac:i_tse_mac|altera_tse_rgmii_module:U_RGMII|altera_tse_rgmii_in1:the_rgmii_in1|altddio_in:altddio_in_component|ddio_in_gsd:auto_generated|ddio_ina[0]" must come from an I/O IBUF or DELAY_CHAIN primitive- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When you use the EMAC HPS I/O pins as loaner I/O don't expect them to have to have many features. As you can see from the output there is no altddio atom in the HPS I/O. Loaner I/O do not have double data rate logic, delay chains, registers, etc... in them. Loaner I/O are intended to be use for low speed connectivity since the I/O is limited in functionality and the delay between two adjacent loaner I/O is much more than what you are accustom to with the regular FPGA I/O.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- When you use the EMAC HPS I/O pins as loaner I/O don't expect them to have to have many features. As you can see from the output there is no altddio atom in the HPS I/O. Loaner I/O do not have double data rate logic, delay chains, registers, etc... in them. Loaner I/O are intended to be use for low speed connectivity since the I/O is limited in functionality and the delay between two adjacent loaner I/O is much more than what you are accustom to with the regular FPGA I/O. --- Quote End --- Thanks BadOmen.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Adding some colour to BadOmen's reply, and to close the loop on my earlier post: Unfortunately, we were told by Altera support that the Cyclone V SoC silicon does not support accessing the DDR (high-speed) I/O function via the loan I/O feature.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page