This change should change anything from the point of view of
`sdram_read_spd` caller, but it makes it so less I2C reads are actually
hapenning.
With `len` we read too many bytes and write them to the `buf`.
In subsequent iterations we overwrite those bytes as all counters are
being updated by the `temp_len`. Nothing terrible, but too many
bytes were being read.
Signed-off-by: Michal Sieron <msieron@antmicro.com>
Simulation with framebuffer:
litex_sim --with-sdram --with-video-framebuffer
Simulation with video terminal:
litex_sim --with-sdram --with-video-terminal
Fix curly braces to be in the same line as the function header.
Fix function formating to be consistent in files.
Fix guards and add comments at the end of them.
Signed-off-by: Maciej Dudek <mdudek@antmicro.com>
SDRAM_WLC_DEBUG is 0 or 1 based on SDRAM_WRITE_LATENCY_CALIBRATION_DEBUG.
This reduces number of #ifdefs
Signed-off-by: Maciej Dudek <mdudek@antmicro.com>
LFSR only returns 1 random bit per lfsr() call,
so we should concatenate 8 consecutive calls to obtain 1 random byte
Signed-off-by: Maciej Dudek <mdudek@antmicro.com>
`cdelay` function is not a proper thing to count time.
It wouldn't count SoC clocks, but CPU clocks.
But even then, there are multiple instructions in `cdelay`:
- NOP
- decrement
- branch with compare
Assuming each instruction takes exactly 1 CPU cycle it is still wrong,
as we wait 3 time longer than requested.
But they don't take exactly 1 CPU cycle.
CPUs have caches, branch predictors, are out-of-order and so on.
So a much better way to count this time would be `busy_wait_us`.
I performed some test using vexriscv and Saleae Logic Analyzer:
vexriscv variant | requested I2C speed | actual (cdelay) | actual (busy_wait_us)
-----------------+---------------------+-----------------+----------------------
minimal | 50 kHz | 4 kHz | 38 kHz
minimal | 200 kHz | 15 kHz | 96 kHz
minimal | 400 kHz | 28 kHz | 137 kHz
-----------------+---------------------+-----------------+----------------------
lite | 50 kHz | 12 kHz | 40 kHz
lite | 200 kHz | 43 kHz | 115 kHz
lite | 400 kHz | 74 kHz | 180 kHz
-----------------+---------------------+-----------------+----------------------
standard | 50 kHz | 12 kHz | 45 kHz
standard | 200 kHz | 48 kHz | 159 kHz
standard | 400 kHz | 84 kHz | 311 kHz
Signed-off-by: Michal Sieron <msieron@antmicro.com>
Instead of enabling pull-up after every sent bit, enable it only after
sending all 8 bits.
This prevents some glitches from happening, where transition between
bits 0 to 0, produces a short spike.
Signed-off-by: Michal Sieron <msieron@antmicro.com>
Change made in 1989d85 was supposed to poll I2C devices using both
writes and reads.
Here is a sequence that was supposed to happen:
- I2C start
- start I2C write
- start I2C read
- I2C stop
Unfortunately, the change worked differently:
- I2C start
- start I2C write
- write byte of (slave_addr << 1 | 1)
- I2C stop
This way, not only did the read not happen, but a potentially harmful
write was happening.
This commit makes it so following sequence takes place:
- I2C start
- start I2C write
- if (I2C write returned NACK)
- start I2C read
- if (I2C read returned ACK)
- read 1 byte and NACK it
- I2C stop
An additional 1 byte read is happening, as some devices may be unable
to process I2C stop after initiating I2C read.
Signed-off-by: Michal Sieron <msieron@antmicro.com>
Michal Sieron
Florent Kermarrec
Victor Suarez Rovere
Dolu1990
inc
Gwenhael Goavec-Merou
Maciej Dudek