According to the SPD specification, we shouldn't send
a stop symbol after the write that sets the address counter.
Signed-off-by: Michal Sieron <msieron@antmicro.com>
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>
Michal Sieron
Florent Kermarrec
Victor Suarez Rovere
Dolu1990
inc
Gwenhael Goavec-Merou
Maciej Dudek