Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20688 Discussions

Accessing HPS Pins

Altera_Forum
Honored Contributor II
2,972 Views

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 you
0 Kudos
15 Replies
Altera_Forum
Honored Contributor II
931 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
931 Views

Thank you for you reply. 

 

Regarding this part about low speed I/O. 

When you say low speed, you're talking about ~1MHz?
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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 :)
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

Thank you. 

 

I have to consider this when I start to think about a custom board. :)
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
931 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
931 Views

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.

0 Kudos
Reply