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.
Florent Kermarrec
Gabriel Somlo
Sean Cross
Arnaud Durand
Greg Davill
Konrad Beckmann
bunnie