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>
Additional sdc/qsf commands can be added from the design like:
platform.sdc_additional_commands.append("create_clock ...")
platform.sdc_additional_commands.append("set_false_path ...")
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.
When timing requirements are strict, allow the build process to fail upon
failure to meet timing. This facilitates running the build process from a
loop, repeatedly, until a "lucky" p&r solution is found, e.g.:
while true; do
litex/boards/targets/versa_ecp5.py --gateware-toolchain trellis \
--sys-clk-freq=60e06 --cpu-type rocket --cpu-variant linux \
--with-ethernet --yosys-nowidelut \
--nextpnr-timingstrict
if [ "$?" == "0" ]; then
echo "Success" | mail -s "Build Succeeded" your@email.here
break
fi
done
This augments commit #683e0668, which unconditionally forced p&r to
succeed, regardless of whether timing was met, via '--timing-allow-fail'.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Python does not have native OrderedSet and we need to be able to preserve the order of the sources
for some backends (Verilator for instance), so use list instead of set.
Florent Kermarrec
sadullah
Gabriel Somlo
Sean Cross
Arnaud Durand
Greg Davill
Konrad Beckmann
bunnie
Tim 'mithro' Ansell
Giammarco Zacheo
Miodrag Milanovic
Pawel Czarnecki
Ilia Sergachev
Vamsi K Vytla
fb@frank-buss.de
Jan Kowalewski