Currently, we create a wishbone interface with the default address
width (30 bits) for the bridge. Instead, create an interface that
has the same number of address bits as the CSR bus.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
When creating standalone IP cores such as standalone LiteDRAM without
a CPU, the CSR are presented externally via a wishbone with just enough
address bits to access individual CSRs (14), and no address decoding
otherwise. It is expected that the design using such core will have
its own address decoder gating cyc/stb.
However, such a design might still need to use LiteX code such as
the sdram init code, which relies on the generated csr.h. Thus we
want to be able to control the CSR base address used by that generated
csr.h.
This could be handled instead by having the "host" code provide
modified csr_{read,write}_simple() that include the necessary base
address. However, such an approach would make things complicated
if the design includes multiple such standalone cores with separate
CSR busses (such as LiteDRAM and LiteEth).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
When creating a standalone LiteDRAM core with no CPU, there is
no need to create a wishbone slave to LiteDRAM interface.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This creates a lot of useless churn in the resulting verilog. Instead
use a point to point interconnect in that case.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
When integrate .xci, we don't necessarily want to apply the default timing/loc
constrants generated by Vivado but our custom ones. Setting disable_constraints
to True allow disabling .xdc generated by the IP.
This speeds up the memory test by an order of magnitude, esp. on
cores without a hardware multiplier by getting rid of the
multiplication in the loop.
The LFSR implementation comes from microwatt's simple_random test
project.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
When generating the LitePCIe PHY wrappers from the .xci, Vivado is locking the
PCIe lanes to default locations that do not necessarily match the ones used in
the design.
Processing our constraints earlier makes Vivado use our constraints and not the
ones from the generated wrapper.
Benjamin Herrenschmidt
Dave Marples
enjoy-digital
Kamil Rakoczy
sadullah
Arnaud Durand
Ilia Sergachev
rprinz08
Shawn Hoffman