FemtoRV is a minimalist RISC-V CPU with design process documented and
available at https://github.com/BrunoLevy/learn-fpga.
This CPU is a very nice way to discover/learn RISC-V and this LiteX support
can be useful to learn how to integrate a custom CPU with LiteX.
With this support, FemtoRV is now directly usable with LiteX Sim:
$litex_sim --cpu-type=femtorv
This should also enable its use on all boards (> 50) available in LiteX-Boards
repository (but hasn't been tested yet), ex:
$python3 -m litex_boards.targets.digilent_arty --cpu-type=femtorv --build
As discussed in #909, in some specific cases, it can be interesting to be able
to keep the CPU in reset while the rest of the SoC is still operating (ex the
peripherals/bridges).
With theses changes, the old behaviour is preserved to do a full SoC Reset (at
the exception that writing a 1 is now mandatory) and a separate field specific
to the CPU reset is added.
The SoC Reset is a pulse (otherwise the system would be stuck in Reset) while
the CPU Reset is based on the register value (so can be pulse or hold).
Before this patch, the loop would finish with lowest_div either set to the first failing value
or 0 even if it succeeded with 0. Fix it so that if all tests pass, it’ll end up being -1 before
the incrementation.
This patch also skips retesting the original value. If the retest failed, lowest_div would be incremented past the original value and could potentially wrap around.
* resolve issue #862 add description to soc.svd
The issue is that with no description provided it simply would
not put out a description tag, which breaks compatibility with
other programs.
Insert a somewhat useful default description including a timestamp
and the words "LiteX SoC".
* I2S fix: sample SYNC on the correct edge
The original Tx path implementation samples SYNC on the falling
edge, out of convenience with the fact that teh data must also
change on the falling edge.
This works OK, until you have a CODEC which has a ~40ns max
delay spec on the SYNC, and also has a slightly asymmetric
SYNC edge (the SYNC signal is also the WCLK or LRCLK depending on
which docs you read). The SYNC by spec is supposed to change
on the falling edge, and this extra delay is enough to cause
the SYNC to introduce occassional bit or frame shifts into
the audio.
This fix samples the SYNC on the rising edge, but still
changes the data on the falling edge, thus allowing for
implementations where SYNC has quite loose timings relative
to everything else (as is the case on the TLV320AIC3200)
developandplay
Florent Kermarrec
Romain Dolbeau
Jędrzej Boczar
Vegard Storheil Eriksen
Robert Szczepanski
bunnie
Hans Baier
Tim Callahan