[I2C, hal, SW] Restructured and refactored the functions#535
[I2C, hal, SW] Restructured and refactored the functions#535KinzaQamar wants to merge 4 commits into
Conversation
c431f00 to
a0269e1
Compare
49e9862 to
ab7f1dc
Compare
79c9fa4 to
bb82b9a
Compare
Taking the transfer checking part out from the i2c_read_byte() and i2c_write_byte() functions. It is needed when you want to controller wants to read / write multiple bytes. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
This is suggested in programmer's guide. As a precautionary step, reset the FMT fifo before sending any transfer Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
| if (i == (num_wr_bytes - 1u)) { | ||
| fdata_reg.stop = 1u; | ||
| } | ||
| VOLATILE_WRITE(i2c->fdata, fdata_reg); |
There was a problem hiding this comment.
you should check that the fifo is not full on every iteration, otherwise it would overflow when num_wr_bytes is large.
There was a problem hiding this comment.
This is going to be UVM agent receiving these bytes. It is capable of receiving any number of bytes.
I was thinking about checking FMTFULL before sending a transfer but since we always write 1 to fmtrst (which is going to reset the FMT FIFO), this is not needed. About checking RXFULL, this should be a test specific thing.
There was a problem hiding this comment.
The UVM agent may be fast, but the i2c block itself might not be. If the processor writes data into the FMT FIFO faster than the I^2C hardware can transmit it, then all it takes is a sufficiently large data transfer for data to be lost when the processor eventually writes to an already-full FMT FIFO.
Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

Taking the transfer checking part out from the i2c_read_byte() and i2c_write_byte() functions. It is needed when you want to controller wants to read / write multiple bytes.
Merge #545 first as a dependency on this PR