If the generic USE_LCD is false, the first SD card controller (mmcblk0
in Linux) is connected to pmod HA; if USE_LCD is true, it is connected
to the SD card slot on the touchscreen/LCD panel.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds connections from the A2 - A5 inputs on the Arty A7 to the
XADC module in the Artix-7 plus a way for software to access the XADC
via its DRP port, and a status register to tell software when
conversion sequences are done.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds an interface for an Arduino-compatible LCD touchscreen. The
screen module plugs directly on to the Arduino/chipKit shield
connector on the Arty A7. Unfortunately, the slightly strange way the
resistive touchscreen is brought out (connected to the D0, D1, RS and
CS pins) combined with the 200 ohm protection resisters on the Arty
board mean that some hardware hacks to the module are necessary. I
rewired mine so that D0 and D1 are on the A4 and A5 pins and the reset
is where D0 was (shield I/O 8).
This interface is suitable for boards with a HX8347 driver chip. The
timing may not be quite suitable for other driver chips.
The interface is a byte which can be read and written at 0xc8050000,
containing an index register, and a 1-8 byte data register at
0xc8050008. Reading at offsets 1 to 7 from those addresses yields the
same value as at offset 0. Writing 64 bits to the data register
writes the bytes at offset 1, 0, 3, 2, 5, 4, 7, 6 in that order to the
driver chip. This allows pixel data to be transferred using 64-bit
writes, ending up in the frame buffer in the expected order (for
16-bit pixels, the driver chip expects MS byte then LS byte). 32-bit
writes do 1, 0, 3, 2, and 16-bit writes do 1, 0.
The touchscreen support so far is a 1-byte register containing bits to
set RS, D0, D1 and CS high or low or make them tri-state. There is
nothing to do analog conversions of the signal levels at this stage.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This snoops writes to the interrupt enable registers of the SD card
interfaces and records whether the command-done interrupt is enabled.
LED 5 is turned on whenever either interface has this interrupt enabled
in order to serve as a disk activity indicator.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This frees up LEDs 4 and 5 by combining their status functions into
LED 0, which is now black when the system is in reset and yellow when
the system clock is not locked. On configuations without litedram,
LED 0 now shows green rather than magenta.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds a second SD card interface. The main complexity is in
providing a wishbone switch/arbiter to multiplex the two DMA
wishbones from the two interfaces to a single wishbone going to
the soc module. There is a new syscon info reg bit to indicate the
presence of the second litesdcard.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Currently, GPIO lines 0 - 8 drive three of the 3-colour LEDs on
output, but on input read the state of the pins labelled IO10 - IO13,
IO26 - IO29 and IO8 on the Arty board. Then GPIO lines 10 - 17 drive
IO10 - IO13 and IO26 - IO29 on output, but on input read the 4 buttons
and 4 switches. To simplify all this and prepare for future changes,
this just detaches IO8, IO13 - IO13 and IO26 - IO29, so now GPIO 0 - 8
read 0 on input, and GPIO 10 - 17 do nothing on output.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The run status LED is off when the core is held in reset (e.g. when
the second core hasn't been started yet).
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The CTRL register has a single bit called RUN. It has some unusual
behaviours:
- It can only be written via SPR number 152, which is privileged
- It can only be read via SPR number 136, which is non-privileged
- Reading in problem state (user mode) returns the RUN bit in bit 0,
but reading in privileged state (hypervisor mode) returns the RUN
bit in bits 0 and 15.
- Reading SPR 152 in problem state causes a HEAI (illegal instruction)
interrupt, but reading in privileged state is a no-op; this is the
same as for an unimplemented SPR.
The RUN bit goes to the PMU and is also plumbed out to drive a LED on
the Arty board.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Commit 0ceace927c ("Xilinx FPGAs: Eliminate Vivado critical
warnings", 2024-03-08) incorrectly removed the constraints for
shield_io36 through to shield_io44 (due to me applying the wrong
version of a patch), resulting in Vivado giving compile errors when
building for the Arty A7. This restores the constraints.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Some signals have changed names: "eth_" has been dropped from the
names of the MII/GMII/RGMII signals.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This resolves various warnings and critical warnings from Vivado.
In particular, the asynchronous loops in the xilinx hardware RNG were
giving a lot of critical warnings, which proved to be difficult to
suppress, so this instead makes all the xilinx platforms use the
'nonrandom.vhdl' implementation, which always returns an error.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The flash chip on my board is an ISSI IS26LP256P chip. The ISSI chip
requires slightly different setup for quad mode from the other brands,
but works fine with the existing SPI flash interface logic here.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Make the shield I/O pins be individual signals rather than a bus in
order to avoid warnings on pins which don't have both a driver and a
receiver.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Instead of connecting core_alt_reset to litedram init_done, it moves to
a syscon register bit. This simplifies top- files and future soc_reset
handling. sdram main.c can unset the alt_reset bit after sdram init.
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
As with the DRAM configuration, the DC-SCM board uses the same PHY as
the Nexys Video and works with it's generated VHDL.
Signed-off-by: Joel Stanley <joel@jms.id.au>
This uses the exact same gateware as the nexys video, since the DRAM
connection is identical to the nexys video down to the pin assignments
on the FPGA. The only minor difference is that the DRAM chip on the
dc-scm is a MT41K256M16TW vs. a ...HA part on the nexys video.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
[joel: rebase and tweaks]
Signed-off-by: Joel Stanley <joel@jms.id.au>
works with:
fusesoc build --target=antmicro-artix-dc-scm microwatt --ram_init_file=../hello_world/hello_world.hex
Signed-off-by: Michael Neuling <mikey@neuling.org>
[joel: Fixes and updates]
Signed-off-by: Joel Stanley <joel@jms.id.au>
Now that we have a 33 bit x 33 bit signed multiplier in execute1,
there is really no need for the 16 bit multiplier. The coremark
results are just as good without it as with it. This removes the
option for the sake of simplicity.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This is necessary for the upcoming Arctic Tern system enablement,
since Arctic Tern uses two DRAM devices and a separate clock line
is routed to each device. LiteX handles this behavior correctly,
therefore we assume other hardware exists that uses a similar
DRAM clock design.
Updates from Mikey to fix some compile issues.
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Orangecrab missed out on:
Make wishbone addresses be in units of doublewords or words
Author: Paul Mackerras <paulus@ozlabs.org>
Date: Wed Sep 15 18:18:09 2021 +1000
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
Reduce litedram NUM_LINES 64->8
This allows us to meet timing. Can probably
be improved in future with better BRAM usage.
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
top-orangecrab0.2 is a copy of top-arty with various changes.
USRMCLK is added for the SPI clock
ethernet is removed
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
At present, code (such as simple_random) which produces serial port
output during the first few milliseconds of operation produces garbled
output. The reason is that the clock has not yet stabilized and is
running slow, resulting in the bit time of the serial characters being
too long.
The ECP5 data sheet says that the phase detector should be operated
between 10 and 400 MHz. The current code operates it at 2MHz.
Consequently, the PLL lock indication doesn't work, i.e. it is always
zero. The current code works around that by inverting it, i.e. taking
the "not locked" indication to mean "locked".
Instead, we now run it at 12MHz, chosen because the common external
clock inputs on ECP5 boards are 12MHz and 48MHz. Normally this would
mean that the available system clock frequencies would be multiples of
12MHz, but this is a little inconvenient as we use 40MHz on the Orange
Crab v0.21 boards. Instead, by using the secondary clock output for
feedback, we can have any divisor of the PLL frequency as the system
clock frequency.
The ECP5 data sheet says the PLL oscillator can run at 400 to 800
MHz. Here we choose 480MHz since that allows us to generate 40MHz and
48MHz easily and is a multiple of 12MHz.
With this, the lock signal works correctly, and the inversion can be
removed.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Paul Mackerras
Boris Shingarov
Michael Neuling