In `spi_sdcard_goidle()`, insert a `busy_wait()` into the CMD55+ACMD41
loop to avoid exhausting the retry counter before the card has a chance
to be ready (required on the trellisboard, also tested OK on nexys4ddr).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Host address parameter types should match CPU word width, so
use `unsigned long` to be correct on both 32 and 64 bit CPUs.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
This causes a DRC error on the Xilinx tools when the prefetch
lines setting is 1. Don't know why this wasn't caught earlier,
but it just popped up in CI.
Depends upon https://github.com/enjoy-digital/litex/pull/435
After initialising the card, reclock the card, aiming for ~16MHz (divider is rounded up, as slower speed is safer), but a maximum of half of the processor speed.
Tested with the card being clocked to 12.5MHz on de10nano
On 64-bit architectures (e.g., Rocket), 'unsigned long' means
eight (not four) bytes. Use 'unsigned int' wherever a FAT data
structure requires a four-byte field!
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Targets which lack an adjustable clocker will not expose the required
registers. Provide a stub sdclk_set_clk() routine for those situations.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Now we only generate multilane bitfield documentation when the CSR has
fields, and the smallest field is less than 8bit long. As this is when
we start running into space problems with the field names.
In cases when each CSR bit has a name and we use CSR with more than 8
bits, the register diagram quickly becomes crowded and hard to read.
With this patch we split the register into multiple lanes of 8 bits
each.
Specific clkoutn_divide_range can now be provided by specialized XilinxClocking classes.
When provided, the specific range will be used. Floats are also now supported in the
range definition/iteration.
It seems LTO is not yet fully working with all configurations, so it's better
reverting the changes for now.
- cause issues with LM32 available compilers.
- seems to cause issues with min/lite variant of VexRiscv.
- seems to cause issues with some litex-buildenv configurations. (see https://github.com/enjoy-digital/litex/issues/417).
The ModuleDoc-generated documentation for the spi_opi module produced
slightly invalid output due to ambiguities in how rst assigns headers.
As a result, sections from the spi_opi document would appear as full
sections.
This cleans up these errors so that it parses properly under sphinx.
Signed-off-by: Sean Cross <sean@xobs.io>
The ModuleDoc-generated documentation for the i2s module produced
slightly invalid output due to ambiguities in how rst assigns headers.
As a result, sections from the i2s document would appear as full
sections.
This cleans up these errors so that it parses properly under sphinx.
Signed-off-by: Sean Cross <sean@xobs.io>
S7 MMCMs allow fractional divider on clock 0. Add a fallback
to try fractional values on clock 0 if a solution can't be found.
This is necessary for e.g. generating both a 100MHz and 48MHz
clock from a 12MHz source with margin=0
By default the behaviour is unchanged and the SoC will provide a ROM:
./arty.py
Bus Regions: (4)
rom : Origin: 0x00000000, Size: 0x00008000, Mode: R, Cached: True Linker: False
sram : Origin: 0x01000000, Size: 0x00001000, Mode: RW, Cached: True Linker: False
main_ram : Origin: 0x40000000, Size: 0x10000000, Mode: RW, Cached: True Linker: False
csr : Origin: 0x82000000, Size: 0x00010000, Mode: RW, Cached: False Linker: False
The integrated rom can be disabled with:
./arty.py --integrated-rom-size=0
but the SoC builder will check for a user provided rom, and if not provided will complains:
ERROR:SoC:CPU needs rom Region to be defined as Bus or Linker Region.
When a rom is provided, the CPU will use the rom base address as cpu_reset_address.
If the user just wants the CPU to start at a specified address without providing a rom,
the cpu_reset_address parameter can be used:
./arty.py --integrated-rom-size=0 --cpu-reset-address=0x01000000
If the provided reset address is not located in any defined Region, an error will
be produced:
ERROR:SoC:CPU needs reset address 0x00000000 to be in a defined Region.
When no rom is provided, the builder will not build the BIOS.
This allows generating SVD export files during the build as we are already doing for .csv or .json.
Use with Builder:
builder = Builder(soc, csr_svd="csr.svd")
Use with target:
./arty.py --csr-svd=csr.svd
Automatic sourcing was not consistent between build backends (and only really supported by ISE/Vivado)
and had no real additional value vs the complexity needed to support it. Now just assume required vendor
tools are in the PATH.
This also removes distutils dependency.
Through their use of the MMPTR() macro, the "classic"
csr_[read|write]simple() accsessors identify the MMIO
subregister with the 'volatile' qualifier.
Adjust the new, csr_[rd|wr]_uint[8|16|32|64]() accessors
to also utilize the 'volatile' qualifier. Since accesses
are implicit (a[i], where a is an 'unsigned long *'),
change 'a' to be a 'volatile unsigned long *' instead.
No difference was noticed in opcodes generated using the
gcc9 risc-v cross-compiler on x86_64 with standard LiteX
cflags (vexriscv and rocket were tested), but since
reports exist that 'volatile' matters on some combinations
of compilers and targets, add the 'volatile' qualifier just
to be on the safe side.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com
This is a straightforward import of the sdcard initialization and
testing routines from the LiteSDCard demo example, made available
as mainline LiteX bios boot-prompt commands.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Previously, we were accessing the `soc.soc_interrupt_map` property in
order to be able to enumerate the interrupts. This has been subsumed
into a more general `irq` object that manages the interrupts.
Use `soc.irq.locs` instead of `soc.soc_interrupt_map` as the authority
on interrupts for both doc and export.
This fixes#385.
Signed-off-by: Sean Cross <sean@xobs.io>
It was suggested that we should move svd generation into `export`,
alongside the rest of the generators such as csv, json, and h. This
performs this move, while keeping a compatible `generate_svd()` function
inside `soc/doc/`.
Signed-off-by: Sean Cross <sean@xobs.io>
The sphinx toctree was behaving oddly, and so previously we were
ignoring it completely. This patch causes it to be used correctly,
which removes the need for double-including various sections.
Signed-off-by: Sean Cross <sean@xobs.io>
lxsocdoc enables automatic documentation of litex projects, including
automatic generation of SVD files.
This merges the existing lxsocdoc distribution into the `soc/doc` directory.
Signed-off-by: Sean Cross <sean@xobs.io>
Expose a pair of `csr_[read|write]_simple()` subregister accessors, and
restore the way dedicated accessors are generated in "generated/csr.h"
to use hard-coded combinations of shifts and subregister accessor calls.
This restores downstream ability to override CSR handling at the
subregister accessor level.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
With add_memory_region, user needs to provide the memory origin, which should not be needed since
could be retrieved from mem_map and prevent automatic allocation which is already possible for csr
and interrupts.
New add_mem_region method now allows both: defining the memory origin in mem_map (which will then
be used) or let the SoC builder automatically find and allocate a memory region.
Hard IP blocks are fixed in location, so long/deep combinational paths routing to multiple hard IP blocks can lead to timing closure problems.
XADC and MMCM DRPs currently have their DEN pins triggered by the ".re" output of a CSR. This is asynchronously derived from a fairly complicated set of logic that involves a logic path that goes all the way back through the cache and arbitration mechanisms of the wishbone bus. On more complex designs, this is leading to a failure of timing closure for these paths, because the hard IP blocks can be located in disparate portions of the chip which "pulls" the logic cluster in opposite directions in an attempt to absorb the routing delays to these IP blocks, leading to non-optimal placement for everything else and thus timing closure problems.
This pull request proposes that we add a pipeline delay on these critical paths. This delays the commit of the data to the DRP by one cycle, but greatly relieves timing because the pipeline register can be placed close to the cluster of logic that computes addresses, caching, and arbitration, allowing for the routing slack to the hard IP blocks to be absorbed by the path between the pipe register and the hard IP block.
In general, this shouldn't be a problem because the algorithm to program the DRP is to hit the write or read CSR, and then poll the drdy bit until it is asserted (so the process is already pretty slow). The MMCM in particular should have almost no impact, because MMCM updates are infrequent and the subsequent lock time of the MMCM is pretty long. The XADC is potentially more problematic because it can produce data at up to 1MSPS; but if sysclk is around 100MHz, adding 10ns to the read latency is relatively small compared to the theoretical maximum data rate of one every 1,000ns.
Note that the xadc patch requires introducing a bit of logic into the non-DRP path. This is because without explicitly putting an "if" statement around the logic, you fall back to the non-blocking semantics of the verilog operator, which ultimately leads to a pretty hefty combinational path. By having a default "if" that should get optimized out when DRP is not enabled, when the DRP path /is/ enabled the synthesizer knows it can safely push the async signal into a simple mux as opposed to worrying about enforcing the non-blocking operator semantics to get the desired result.
Revert to treating SDRAM_DFII_PIX_[RD|WR]DATA CSRs as arrays
of bytes, but use the new uintX_t array accessors for improved
legibility, and to avoid unnecessary byteswapping.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Implement CSR accessors for all standard integer types and
combinations of subregister alignments (32 or 64 bit) and
sizes (i.e., csr_data_width 8, 16, or 32).
Rename accessors to better reflect the size of the register
being accessed, and correspondingly update the generation
of "csr.h" in "export.py".
Additionally, provide read/write accessors that superimpose arrays
of standard unsigned C types over a CSR register (which may itself
be spread across multiple subregisters).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
A bridged/crossover UART can now just be created by:
- passing uart_name="stream" to SoCCore/SoCSDRAM.
- adding a crossover UART core to the design:
# UART Crossover (over Wishbone Bridge
from litex.soc.cores.uart import UART
self.submodules.uart_xover = UART(tx_fifo_depth=2, rx_fifo_depth=2)
self.add_csr("uart_xover")
self.comb += self.uart.connect(self.uart_xover)
This version of the UART adds a second, compatible UART after
the first. This maintians software compatibility, and allows a
program running on the other side of the litex bridge to act as
a terminal emulator by manually reading and writing the second
UART.
Signed-off-by: Sean Cross <sean@xobs.io>
For the "P" side of the analog channels, actually, connecting
a digital line to them has "no meaning". The docs say that
either you connect an analog pin to a pad, or vivado "ties it off
appropriately". I wish it were the case that tying a pin to 0 or 1
would actually connect it to a power or ground, because it means
that even in unipolar mode you have to burn two pins to break out
the signal of interest *and* the ground reference analog pad
(I thought I could just connect it to "0" and the pin would be
grounded, but that doesn't happen -- it's just ignored if it's
not wired to a pad).
For the pad specifier, is it OK to leave it with an optional
argument of analog_pads=None? I tried assigning to the
self.analog property after instantiation, but this doesn't
seem to work, the default values are preferred. It looks like
if you don't want to do the analog_pads= optional argument
the other way to do it would be to add code on the instiating
module that tampers with the properties of the instance directly,
but I think that's sort of ugly.
Also, I noticed you stripped out the layout specifier for
the analog_pads. I thought it would be nice to provide that
in the file, so the caller doesn't have to infer what the
pad layout is by reading the code...what's the motivation for
removing that?
Similarly to how CSRBank subregisters are aligned to the CPU word
width (see commit f4770219f), ensure SRAM word_bits are also aligned
to the CPU word width.
Additionally, fix the MMPTR() macro to access CSR subregisters as
CPU word (unsigned long) sized slices.
This fixes the functionality of the 'ident' bios command on 64-bit
CPUs (e.g., Rocket).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
The design is backward-compatible in functionality for users
who don't want to use DRP. That is, on power on, the XADC will
scan the supply and temperature and store them in CSRs.
If drp_enable is set, the scanning stops, and the XADC is now
controlled by the DRP bus.
Wher drp_enable is reset, the XADC may return to an auto-sample
mode, but only if the internal registers are configured to do this.
If you return to drp_enable without, for example, turning on
the continuous sequence and setting which channels to check,
the results will be unpredictable (mostly either it'll scan just
once and stop, or it'll not scan all the channels, depending on
the register settings).
At this point, the backward compatibility was confirmed in testing,
the DRP API is still a work in progress as the application this
is being developed for needs to support fun stuff like real time
sampling of signals to a buffer.
Down the road, this block may have to be modified again to support an
output FIFO, so we're not railing the CPU trying to do real time
sampling of ADC data. This will probably be added as a True/False flag
of some sort in the parameter list, because the FIFO will be expensive
as far as BRAM goes to implement and applications that don't need the
FIFO buffer can probably use that BRAM for better things.
This fixes some formatting errors with the timer documentation, such as
the lack of a space between the first and second sentences. It also
fixes some grammar for documentation of various fields.
Signed-off-by: Sean Cross <sean@xobs.io>
The ReStructured Text used was not properly formatted, resulting in
confusing and broken output. This corrects the output and lets it
format correctly when using sphinx.
Signed-off-by: Sean Cross <sean@xobs.io>
If clocks and multipliers are planned well, we can have
a zero-error solution for clocks. Suggest to change < to <= in
margin comparison loop, so that a "perfect" solution is allowed
to converge.
Various development boards' LiteDRAM ports may have native data
widths of either 64 (nexys4ddr), 128 (versa5g), or 256 (trellis)
bits. Add Rocket variants configured with mem_axi ports of matching
data widths, so that a point to point connection between the CPU's
memory port and LiteDRAM can be accomplished without any additional
data width conversion gateware.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Enforce the condition that csr_alignment be either 32 or 64 when
requested explicitly when initializing SoCCore().
Additionally, if a CPU is specified, enforce that csr_alignment be
equal to the native CPU word size (currently either 32 or 64), and
warn the caller if an alignment value *higher* than the CPU native
word size was explicitly requested.
In conclusion, if a CPU is specified, then csr_alignment should be
assumed to equal 8*sizeof(unsigned long).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Since the PLIC is internal to Rocket, access its registers
directly via pointer dereference, rather than through the
LiteX CSR Bus accessors (which assume subregister slicing,
and are therefore inappropriate for registers NOT accessed
over the LiteX CSR Bus).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Since csr_data_width=64 has probably never worked properly, remove
it as one of the possible options (to be fixed and re-added later).
Add csr_data_width=16, which has been tested and does work.
Additionally, ensure csr_data_width <= csr_alignment (we should not
attempt to create (sub)registers larger than the CPU's native word
size or XLen).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
The SPI mode is actually mode3, since the output value is updated on the
falling edge of CLK and the input value is updated on the rising edge.
This also clarifies some of the documentation based on experience with
the core.
Signed-off-by: Sean Cross <sean@xobs.io>
It was necessary to add drp_locked CSR for reading LOCK signal from
MMCM. Additionally, input signal RESET from MMCM was not driven by
any signal to do a proper reset of MMCM module thus it was impossible
to perform entirely correct dynamic clock reconfiguration.
Enable SDRAM to be initialized when csr_data_width > 8 bits.
Currently, csr_data_width up to 32 bits is supported.
Read leveling tested with csr_data_width [8, 16, 32] on the
ecp5-versa5g and trellisboard (using yosys/trellis/nextpnr),
and on the nexys4ddr (using Vivado).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
With high speed link (10gbps XGMII ethernet for example), stream data_width is generally
> 8-bit which make header/data un-aligned on bytes boundaries. The change allows the
Packetizer/Depacketizer to work on stream with a data_width > 8-bit.
Rocket variants can be configured with axi port data widths that
are multiples of the native word size (64 bits in our case). In
the future, we will add variants with mem_axi data width > 64 bit,
to match the native data width of the LiteDRAM controller on
various development boards (e.g., 128 bits on the ecp5versa, and
256 bits on the trellisboard).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Connect Rocket's dedicated port for cached RAM accesses (mem_axi)
directly to the LiteDRAM data port, bypassing the shared LiteX
(Wishbone) bus.
When both Rocket's mem_axi and LiteDRAM's port have the same data
width, use a native point-to-point AXI connection.
Otherwise, convert both ends to Wishbone, and use the Wishbone
data width converter to bridge the gap.
FIXME: In the future, this part should be replaced with a native
AXI data width converter!
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Before;
```
ValueError: Memory region conflict between rom and main_ram
```
After;
```
ValueError: Memory region conflict between rom (<SoCMemRegion 0x10000000 0x10000 cached>) and main_ram (<SoCMemRegion 0x0 0x20000000 cached>)
```
Fixes#296.
The total size of RAM (main_mem) can be expected to vary significantly,
and often exceed the size needed for MMIO allocations by a large margin.
As such, place Rocket's MMIO (io regions) below 0x8000_0000, and start
the RAM (main_mem) at 0x8000_0000, with nothing above it to limit its
future growth.
Also, bump the pre-built Rocket verilog submodule to an updated version,
which also comes with matching changes to the way MMIO and RAM accesses
are mapped and routed to their respective AXI interfaces.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
The shadow_base parameter has always been difficult to apprehend, replace it with
io_regions (uncached regions) defined user or the CPU.
The equivalent of a shadow_base parameter of 0x80000000 in the old API is:
io_regions = {0x80000000: 0x80000000} # origin, length
It's still possible to use shadow_base with retro-compat, but user is encouraged
to update and features will be removed in the future.
Both the SoC and get_csr_header() have independently set defaults
for the value of 'shadow_base'. If the SoC's value was modified,
ensure that get_csr_header() uses the modified value instead of
its own default.
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Doing actions on register read is generally not a good design practice (it's
better to do separate register write to trigger actions) but in some very
specific cases being able to know that register has been read can solve cases
that are difficult to do with the recommended practives and that can justify
doing an exception.
This commit add a we signal to CSR, CSRStatus and this allow the logic to know
when the CSR, CSRStatus is read.
For example a standalone controller with no exposed CSRs (probably not
a very useful configuration but I really don't like python backtraces)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
With the new ModuleDoc class, we can inherit `ModuleDoc` and
automatically get module-level documentation.
This patch also corrects a typo in `timer` that causes an error in
sphinx.
Signed-off-by: Sean Cross <sean@xobs.io>
It is important to be able to document modules other than CSRs.
This patch adds ModuleDoc and AutoDoc, both of which can be used
together to document modules.
ModuleDoc can be used to transform the __doc__ string of a class into a
reference-manual section. Alternately, it can be used to add additional
sections to a module.
AutoDoc is used to gather all submodule ModuleDoc objects in order to
traverse the tree of documentation.
Signed-off-by: Sean Cross <sean@xobs.io>
Mainline Linux expects it to be loaded at the physical address of 0x0.
Change the MAIN_RAM base address to 0x0 and update exception vector
during the booting process.
With this change, we will now generate csr.h and sdram_phy.h, which
will be needed by the initialization code running on the host CPU.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Document the various fields present in the SPI flash bitbang interface.
This adds documentation for the Single and DualQuad modules.
Signed-off-by: Sean Cross <sean@xobs.io>
Add `name` and `description` as optional arguments to the various
EventSource types. These default to `None`, so this should be a
backwards-compatible change.
Use the same trick as CSRs, where we default the `name` to be the
instantiated object name as read from the Migen `get_obj_var_name()`
call.
Signed-off-by: Sean Cross <sean@xobs.io>
Generic module to monitor endpoints activity: tokens/overflows/underflows that
can be plugged on a endpoint. Can be useful for various purpose:
- endpoint bandwidth calculation.
- underflows/overflows detection.
- etc...
LiteX rightfully assumes that most often the target software must
be cross-compiled from an x86 host platform. However, LiteX can be
also built on a 'linux-riscv64' platform (e.g. Fedora's riscv64
port), where the software for riscv64 targets should be compiled
using the native toolchain.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
