CYCLONE V - HPS and I2C Peripheral Pin

[StefanoMarsi]

Hi Community

I'm testing the I2C interface embedded in CycloneV - HPS.

- However, if I export peripherals signals through the HPS I/O Set everything works pretty well.

- But If I switch to FPGA: exporting signals to FPGA Fabric (integarting them with suitable I/O Tristate buffers) the I2C protocol is completely different, the frequency of I2C signals passes from 100kHx to 6 kHz, and even if SDA seems in a certain way coherent with data, SCL is not. 

Please note the different behavior in the images attached.

Any help will be appreciated!

[JingyangTeh]

Hi Stefano

From the waveform that you shared, we could see that the signals are distorted when it is routed through the FPGA.

Have you tried not passing the i2c signals through the tri-state buffer? 

Could you also try setting the I/O standard to Open Drain as suggested in the CycloneV interface guideline?

Please refer to this link on the i2c guidline placement.

https://www.intel.com/content/www/us/en/docs/programmable/683360/18-0/i2c-interface-design-guidelines.html

Regards

Jingyang, Teh

[StefanoMarsi]

This is exactly what I did!

Please note the implementation in the attached code!

[JingyangTeh]

Hi

Sorry for the late reply. I was OOO last week.

After talking with a senior colleague, this could be a bug from our end.

I will file a ticket to get engineering help.

Could you provide additional below:

Quartus Version you are using?

Is this a devkit or a custom board? If it is a devkit could you provide the part number?

Could you also share with us the project file that you are working on?

Regards

Jingyang, Teh

[StefanoMarsi]

Thank you for your help

- I'm using Quartus 22.1 std
- with intel monitor program 21.1

- The board is a De1-SOC (Teraic) rev. G   P.N. 10-01306101-G0

attached the .qar file  of the project.

Thank you

[JingyangTeh]

Hi

I have filed a ticket to engineering.

Will update here if there are any update.

Thanks for sharing your project with us.

Regards

Jingyang, Teh

[JingyangTeh]

Hi Stefano

Could you try following the example of the i2c buffer from the project below?

https://www.intel.com/content/www/us/en/docs/programmable/683126/21-2/i2c-controller-signal-description.html

It was suggested by the engineering.

It is using bufif1

Regards

Jingyang, Teh

[StefanoMarsi]

Thank you for your kind answer, but unfortunately, the result is the same !

Please note that the i2C waveforms present a certain coherence but the frequency and the duty cycle are completely wrong.

Moreover looking at the RTL representation the main difference is that using the HPS pins there are no input buffers (is it possible?) for the signal and the buffers are located quite near the I2C peripheral, while if I try to drive the pins to the FPGA fabric an input buffer is added and all the buffers are located in the I/O resources.

I included a couple of images to better explain this difference.

Thank you for your support

[StefanoMarsi]

However, looking in detail at the previous images there is another slight difference:

- When the HPS pins are used,  the output port of the I2C peripherals is named I2C_CLK_OE and I2C_DATA_OE
- While when I try to drive them to the FPGA pins  they are named OUT_CLK and OUT_DATA

It seems quite strange the adoption of different port names !  (may be different signals are involved !?)

[JingyangTeh]

Hi

Sorry for the late response.

I still got no further update from engineering at this moment on the next step of action.

Regards

Jingyang, Teh

[StefanoMarsi]

don't worry

In the meantime, I've done some other tests and I've to admit that it is a mess:

In particular, I've tried to drive both peripheral i2c0 and i2c1 to FPGA in the same exact way and their behavior is totally different:

- i2c1 presents the malfunctioning I  mentioned in the previous posts (wrong frequency and duty cycle) when drived to FPGA but it works properly when driven to the devoted pins.

- i2c0 presents a correct frequency and the data shape is OK but it completely ignores the ACK received from the device, (even if present)
ad it limits the entire communication to send the first byte (i.e. the address of the device) then it releases the bus and does not send anything else.

I2c2 and i2c3 is not available via software without a suitable preload.

Is it possible that the problem is in the preload?

[JingyangTeh]

Hi

For the pins routed through the FPGA pins, are there any pull up resistors connected to it?

From the guideline for the I2C pins there should be a pull up resistors for the I2C pins.

https://www.intel.com/content/www/us/en/docs/programmable/683360/18-0/i2c-interface-design-guidelines.html

Regards

Jingyang, Teh

[JingyangTeh]

Hi

Any update on this case?

Did adding a pull up resistor solved the issue?

Regards

Jingyang, Teh

[StefanoMarsi]

I tried both with external Pull-Up resistors (included in the client) and adopting PU in the pads, but the result is the same.
However please note my previous messages concerning the different behavior of the different peripherals i2c0 and i2c1 !

[JingyangTeh]

Hi Stefano

Thanks for your testing.

After discussing we are suspecting either it is the i2c hard IP or the HPS-to-FPGA interface that could be the problem.

Below is the data flow of the signal.

Bolded are the part that we are currently suspecting.

HPS I2C Hard IP >> HPS-to-FPGA interface >> FPGA fabric >> FPGA I/O >> Level Shifter >> I2C slave

Is it possible if you could SignalTap the signals of the i2c signals for the setup you have for i2c0 and i2c1?

i2c1_out_scl

i2c1_out_sda

i2c1_in_scl

i2c1_in_sda

arm_a9_hps_i2c1_out_data

arm_a9_hps_i2c1_sda

arm_a9_hps_i2c1_clk_clk

arm_a9_hps_i2c1_scl_in_clk 

GP0GPIO[0]

GP0GPIO[1]

Regards

Jingyang, Teh

[StefanoMarsi]

Thank you for your suggestion
I made the test you asked but the results are more or less the same I have on the oscilloscope at each level.

[StefanoMarsi]

In addition, regarding interface I2c0, signals does not seem accessible fron Signal Tap (since they do not share FPGA Fabric)
But however in such a case the interface in these conditions works pretty well !

[JingyangTeh]

Hi Stefano

From the signal tap pictures that you send it seems like the problem could due to be originating between the HPS I2C Hard IP and HPS-to-FPGA interface.

This is not fixable by any software patch at the moment if the problem is coming from the HPS I2C Hard IP to the FPGA interface.

HPS I2C Hard IP >> HPS-to-FPGA interface >> FPGA fabric >> FPGA I/O >> Level Shifter >> I2C slave

Are you seeing this behavior on other boards as well?

Regards

Jingyang, Teh

[JingyangTeh]

Hi Stefano

Do you have an update for this?

Any chance that you are seeing this behavior on other boards as well?

Regards

Jingyang, Teh

[StefanoMarsi]

I check on a different board and the results are the same !

[JingyangTeh]

Hi Stefano

Please bear with me while I discuss with the engineering team.

Regards

Jingyang, Teh