MachXO2 EFB Secondary I2C master simulation transmits 0xFF instead of the queued

[johny_2000]

Hello,

I am trying to simulate the hardened Secondary I2C port of the MachXO2 Embedded Function Block (EFB) in master mode using the original protected Lattice simulation model.

Environment:
Device: LCMXO2-4000HC-4MG132C
IP name: MachXO2 Embedded Function Block (EFB), Secondary I2C (EFB_I2C2)
IP version: Module Version 1.2
IP generator: IPexpress/SCUBA
Diamond version: 3.14.0.75.2
Simulator: Active-HDL 12 x64
Simulation model: machxo2_black_boxes-aldec.vp
Wishbone clock: 24 MHz
I2C frequency: approximately 100 kHz
Target device: PCF8574 at the 7-bit address 0x27

External pull-ups are explicitly modeled on both I2C lines:

Code: [Select]

assign (pull1, strong0) SCL = 1'b1;
assign (pull1, strong0) SDA = 1'b1;
Adding these pull-ups solved the original problem where SDA and SCL remained in the high-impedance (High-Z) state. The first I2C byte is now transmitted correctly.

I implemented the master transaction sequence according to the official Lattice examples:
1. Wait until BUSY = 0.
2. Write 0x4E to I2C_2_TXDR. This is the 8-bit write address corresponding to the 7-bit address 0x27.
3. Write 0x90 to I2C_2_CMDR: START + WRITE.
4. Wait for a new TRRDY indication.
5. Write the payload byte, for example 0x3C, to I2C_2_TXDR.
6. Write 0x10 to I2C_2_CMDR: WRITE.
7. Wait for another new TRRDY indication.
8. Write 0x40 to I2C_2_CMDR: STOP.

Observed behavior:
- The address byte 0x4E appears correctly on SDA.
- The PCF8574 model acknowledges the address.
- The payload byte written to TXDR does not appear on the bus.
- Instead of 0x3C, the EFB model transmits 0xFF.
- The same behavior occurs with other payload values. For example, 0xA5 is also transmitted as 0xFF.
- The status register ends at 0x28.
- The expected STOP condition is not generated.
- The I2C transaction does not complete correctly.

I also followed the recommendation from the MachXO2 hardened I2C documentation to issue an initial STOP by writing 0x40 to I2C_2_CMDR immediately after enabling the Secondary I2C port.

The initial STOP produces the documented short low pulse on SCL, so this command is processed by the model. However, it does not fix the following transaction: the address byte is still transmitted correctly, but the payload byte is transmitted as 0xFF.

The register access order, BUSY/TRRDY polling, command values and initial STOP sequence were compared with the official Lattice hardened-I2C examples.

Could someone please clarify the following?

1. Does the protected MachXO2 EFB simulation model fully support multi-byte Secondary I2C master transactions?
2. Is any additional initialization, delay or internal oscillator configuration required before loading the second TXDR byte?
3. Is there a known limitation or defect in the Active-HDL/ModelSim protected EFB model supplied with Diamond 3.14?
4. Is an updated simulation model or library patch available?

An independent 2026-08-03 run in Questa Lattice OEM Edition 2024.2 (build 2024.05) reproduced the same continuation-byte failure with Diamond 3.14's official `ovi_machxo2.EFB` model. In the ordinary production EFB configuration, the strict bench wrote `I2C2_CR=0x8c`, issued the startup`CMDR=0x40` STOP, then sent `TXDR=0x4e` with `CMDR=0x90` and `TXDR=0xa5`with `CMDR=0x10`.  The PCF8574 model decoded and acknowledged the `0x4e` address, but decoded and acknowledged `0xff` for the expected `0xa5` continuation byte; the bench reported zero protocol errors and the expected diagnostic FAIL (`expected=a5 observed=ff`).  Questa itself reported zero engine errors and warnings, which is not a test PASS.

Code: [Select]

# // Questa Lattice OEM Edition-64
# // Version 2024.2 win64 May 20 2024

# DIAG VARIANT_BEGIN id=11 name=refresh_stop_lattice
# I2C_CR=8c spi_disabled=0 osch_exp=0 osch_wbclk=0

# DIAG WB_WRITE_ACCEPT addr=4b data=40 ack=1
# DIAG PROGRESS ... post-configuration STOP reset pulse observed

# DIAG PROGRESS ... issuing address TXDR=4e CMDR=90
# DIAG WB_WRITE_ACCEPT addr=4e data=4e ack=1
# DIAG WB_WRITE_ACCEPT addr=4b data=90 ack=1

# PCF8574 ADDRESS byte=4e match=1 rw=0 ack=1

# DIAG WB_WRITE_ACCEPT addr=4e data=a5 ack=1
# DIAG WB_WRITE_ACCEPT addr=4b data=10 ack=1

# PCF8574 WRITE byte=ff ack=1 port=ff

# DIAG SUMMARY ... payload_expected=a5 payload_wire=ff
# address_ack/nack=1/0 data_ack/nack=1/0
# protocol_errors=0 post_cfg_stop=1

# DIAG RESULT ... FAIL expected=a5 observed=ff SR=28
# Errors: 0, Warnings: 0

So, regarding the official ovi_machxo2.EFB:
- it correctly transmitted address 0x4E, and the PCF8574 acknowledged it (ACK).
- it received value 0xA5 and the continuation command 0x10 into the TXDR.
- in practice, it drove 0xFF onto the bus instead of 0xA5.
- ihe "Errors: 0, Warnings: 0" status refers to the Questa engine itself.

The diagnostic test naturally resulted in a FAIL, as it detected a mismatch: expected=a5, observed=ff.
The real design uses the hardened EFB Secondary I2C controller. At present, the complete transaction can only be simulated using a behavioral replacement for the I2C portion of the EFB model.

Thank you.

[johny_2000]

As an aside: the code mentioned above works correctly on the actual hardware. The issue affects only the manufacturer's simulation model (`machxo2_black_boxes-aldec.vp`) for the MachXO2 Embedded Function Block (EFB), the Secondary I2C interface (EFB_I2C2). I have submitted a support request to Lattice regarding this matter but have not yet received a response. They might have already written off that generation of MachXO2 and no longer pay it the attention. Lattice Diamond itself is no longer being developed. All resources are being directed toward Lattice Radiant.

[zapta]

Did you try to feed all the source code to an AI and let it answer the question? They are getting better and better.