Routing HPS I2C thru FPGA Not Working

[Altera_Forum]

Hi 

 I followed Altera's guide AN706 (link below) to route HPS' I2C0 port through the FPGA on the Cyclone V Arrow SoCKit. I included the ALT_IOBUFF buffer as instructed by AN706 guide. But it's not working properly. We can send out I2C commands and we can see slave device sending ACK signal through an I2C analyzer. For some reason, the ACK is not reaching the HPS as we keep getting NACK from our code.   We are using Quartus 13.1 while AN706 mentions Quartus 14.0. Not sure if that's the issue. Has anyone successfully routed the HPS I2C port through the FPGA and got it working? Any suggestions/help would be appreciated.  www.altera.com/literature/an/an706.pdf

[Altera_Forum]

QII 14.0 consist of the final timing model which is recommended for user to close timing while export HPS peripherals to FPGA region. 

Anyway, the timing for i2c is quite slow thus I suppose it should not give much impact to your design. A few thing I can think of here is: 1. Did you update your preloader after changing HPS setting in QSYS? 2. How did you connect your pin out to ALT_IOBUFF? 3. You stated you able to send out I2C commands, did you mean HPS send out or the slave did?  -Luis-

[Altera_Forum]

--- Quote Start ---  Hi  I followed Altera's guide AN706 (link below) to route HPS' I2C0 port through the FPGA on the Cyclone V Arrow SoCKit. I included the ALT_IOBUFF buffer as instructed by AN706 guide. But it's not working properly. We can send out I2C commands and we can see slave device sending ACK signal through an I2C analyzer. For some reason, the ACK is not reaching the HPS as we keep getting NACK from our code.   We are using Quartus 13.1 while AN706 mentions Quartus 14.0. Not sure if that's the issue. Has anyone successfully routed the HPS I2C port through the FPGA and got it working? Any suggestions/help would be appreciated.  www.altera.com/literature/an/an706.pdf (http://www.altera.com/literature/an/an706.pdf)  --- Quote End ---    Hey,  I seem to have the same problem here. Have you found a solution to your problem yet? I also see the ACK from the slave but the TX_ABRT register says there was no ack and stops.

[Altera_Forum]

Hey,  

I seem to have similar problems running the hps_i2c0 as an master: - I see the hps putting out the correct i2c-address on the bus and the slave reacts with an ack - The TX_ABRT register says there was no ack and the communication stops  I use an ALT_IOBUFF to connect the pins from FPGA to hps as seen in the application note posted above.  mbp2014 have you found a solution yet?

[Altera_Forum]

The routing of HPS signals to the FPGA didn't always work. I don't recall which version it was that corrected that. You could look at the Quartus release notes. I'd try again with the latest Quartus version.

[Altera_Forum]

I am currently using Quartus 15.1. 

What I am confused about is, that the outgoing direction seems to work since i get the correct output from the HPS to FPGA.  The only problem is, that the ack is somehow not detected by the HPS.

[Altera_Forum]

Hello there, 

 i have the same problem.  Board: DE0_NANO_SOC Quartus: Version 15.1  I took the GHRD from the CD and added an I2C_2 for FPGA, I also added the IO_BUFFF the the FPGA design. Complied all and created an new .rbf and .dtb . I do have the I2C in Linux under Devices. I took the Code for the gsensor from the example and modified it for my purposes.  When i execute the code i will get an: i2c_designware ffc06000.i2c: controller timed outright after i try to write into the i2c_2 file.   It would be nice to get a tip where to search or what to do.  Best Regards

[Altera_Forum]

Could you post your dts-entry for the I2C? 

 Maybe you want to add a i2c-sda-hold-time...

[Altera_Forum]

--- Quote Start ---  Could you post your dts-entry for the I2C?  Maybe you want to add a i2c-sda-hold-time...  --- Quote End ---    Thanks for the fast response! Here ist the Info from the .dts for all I2C, 0 and 1 are for HPS use and 2 is for FPGA routing 3 inst implemented jet.   hps_0_i2c0: i2c@0xffc04000 {  compatible = "snps,designware-i2c-15.1", "snps,designware-i2c";  reg = <0xffc04000 0x00000100>;  interrupt-parent = <&hps_0_arm_gic_0>;  interrupts = <0 158 4>;  clocks = <&l4_sp_clk>;  emptyfifo_hold_master = <1>; /* embeddedsw.dts.params.emptyfifo_hold_master type NUMBER */  status = "okay"; /* embeddedsw.dts.params.status type STRING */  speed-mode = <0>; /* appended from boardinfo */  i2c-sda-falling-time-ns = <5000>; /* appended from boardinfo */  i2c-scl-falling-time-ns = <5000>; /* appended from boardinfo */  }; //end i2c@0xffc04000 (hps_0_i2c0)    hps_0_i2c1: i2c@0xffc05000 {  compatible = "snps,designware-i2c-15.1", "snps,designware-i2c";  reg = <0xffc05000 0x00000100>;  interrupt-parent = <&hps_0_arm_gic_0>;  interrupts = <0 159 4>;  clocks = <&l4_sp_clk>;  emptyfifo_hold_master = <1>; /* embeddedsw.dts.params.emptyfifo_hold_master type NUMBER */  status = "okay"; /* embeddedsw.dts.params.status type STRING */  }; //end i2c@0xffc05000 (hps_0_i2c1)    hps_0_i2c2: i2c@0xffc06000 {  compatible = "snps,designware-i2c-15.1", "snps,designware-i2c";  reg = <0xffc06000 0x00000100>;  interrupt-parent = <&hps_0_arm_gic_0>;  interrupts = <0 160 4>;  clocks = <&l4_sp_clk>;  emptyfifo_hold_master = <1>; /* embeddedsw.dts.params.emptyfifo_hold_master type NUMBER */  status = "okay"; /* embeddedsw.dts.params.status type STRING */  }; //end i2c@0xffc06000 (hps_0_i2c2)    hps_0_i2c3: i2c@0xffc07000 {  compatible = "snps,designware-i2c-15.1", "snps,designware-i2c";  reg = <0xffc07000 0x00000100>;  interrupt-parent = <&hps_0_arm_gic_0>;  interrupts = <0 161 4>;  clocks = <&l4_sp_clk>;  emptyfifo_hold_master = <1>; /* embeddedsw.dts.params.emptyfifo_hold_master type NUMBER */  status = "disabled"; /* embeddedsw.dts.params.status type STRING */  }; //end i2c@0xffc07000 (hps_0_i2c3)   I measured the 4 signals coming out of the HPS and the SDA and SCL have 3.3V after the Buffer an the two .oe signals have 0V constantly.

[Altera_Forum]

i2c@0xffc04000 { compatible = "snps,designware-i2c-15.0", "snps,designware-i2c"; reg = <0xffc04000 0x100>; interrupt-parent = <0x3>; interrupts = <0x0 0x9e 0x4>; clocks = <0x1e>; emptyfifo_hold_master = <0x1>; status = "okay"; speed-mode = <0x00>; i2c-sda-falling-time-ns = <0x1388>; i2c-scl-falling-time-ns = <0x1388>; };

[Altera_Forum]

I have played around with the sda hold time but no success... it looks like the sda signal gets out of the hps but not in again. 

(I can see the sda output and the ack from the slave but the controller says there was no ack)  https://www.alteraforum.com/forum/attachment.php?attachmentid=12224

[Altera_Forum]

--- Quote Start ---  I have played around with the sda hold time but no success... it looks like the sda signal gets out of the hps but not in again. (I can see the sda output and the ack from the slave but the controller says there was no ack)  https://www.alteraforum.com/forum/attachment.php?attachmentid=12224   --- Quote End ---    Hello nd89,   how do you measure the signals?   Thanks

[Altera_Forum]

I measured them with the signaltap and an oscilloscope... why?

[Altera_Forum]

--- Quote Start ---  I measured them with the signaltap and an oscilloscope... why?  --- Quote End ---    When i try to measure with a signal tap, i cant see anything. It won't even trigger...

[Marco_Intel]

Hopefully you already solved this issue, but anyway some suggestions:

1- You need to enable internal timing arc from HPS to FPGA if you route the EMAC to FPGA I/Os, this is stated also in the CV HPS Handbook (vol 4 : Hps technical reference) where you can see that you need to add the following line into the HPS:

set_global_assignment -name ENABLE_HPS_INTERNAL_TIMING ON 

on Old version of Quartus you did need to enable those through an .ini file as you can find on the examples on rocketboards:

https://rocketboards.org/foswiki/view/Projects/CycloneVSGMIIExampleDesign

https://rocketboards.org/foswiki/Projects/CycloneVRGMIIExampleDesign

2- Seen that you're routing those signal through the FPGA you need to provide timing constraint to the I/O as usual (as if you're using an SGMII/RGMII interface depending on what you're using).

Hope it helps.