Lattice EFB I2C core works in simulation, but not on hardwar

L

littlegamer

Guest
Hello,

Perhaps someone with Lattice experience can answer this for me. I am building a design on a MachXO2 using the EFB for I2C slave communication. I built my own state machine for writing and reading to the wishbone bus. In simulation, it works perfectly. I can read and write to the I2C lines, see what the wishbone bus is doing, data is processed correctly. In simulation. When I synthesize the design and feed it to an actual MachXO2, it doesn't work at all. The I2C core is alive, it responds to addresses by sending ACKs, also when writing data, but when trying to read the exact same address, it feeds me rubbish (like 0x0B or 0x0F), repeatedly writing will cause the device to crash by pulling the SDA or SCL lines hard low.

I'm using the internal oscillator at 8MHz portmapped to the Wishbone bus. I've changed the statemachine to do the same thing specified in the reference designs (as in, discarding the read buffer twice, disabling and re-enabling the interrupt source for TRRDY, waiting for BUSY low etc). Apart from the extra wishbone transactions, simulation results and hardware results remain the same. I have no clue where to look for. Can anyone give me pointers?

Regards,
littlegamer
 
Hi littlegamer,

On 23/10/2013 19:00, littlegamer wrote:
[]
Perhaps someone with Lattice experience can answer this for me. I am
building a design on a MachXO2 using the EFB for I2C slave
communication. I built my own state machine for writing and reading
to the wishbone bus. In simulation, it works perfectly. I can read
and write to the I2C lines, see what the wishbone bus is doing, data
is processed correctly. In simulation. When I synthesize the design
and feed it to an actual MachXO2, it doesn't work at all.

have you run a post-synth simulation? Have you performed static timing
analysis? If not I strongly invite you to do so before going on the bench.

The I2C
core is alive, it responds to addresses by sending ACKs, also when
writing data, but when trying to read the exact same address, it
feeds me rubbish (like 0x0B or 0x0F), repeatedly writing will cause
the device to crash by pulling the SDA or SCL lines hard low.

Be aware that often simulation vs. reality mismatches are due to
'incomplete simulation environment'. Check that all the input to your
logic is properly modeled in your simulation, including timing and most
of all power-up/rst sequence.

HTH,

Al

p.s.: How do you define a 'device crash'? I've seen a car crash
yesterday and I bet that I do not have to explain you what a car crash
is. My suggestion: try to describe your problem according to your
observations, not to your - understandable - frustration for having a
not working hardware.
 

Welcome to EDABoard.com

Sponsor

Back
Top