CYCLONE V - HPS and I2C Peripheral Pin

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

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

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

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

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

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

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 !?)

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

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?

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