There is a conflict between the LiteX way of doing things and the POWER
way of handling interrupt tables. LiteX expects to be able to put a ROM
at address 0 and load an application into RAM at a higher address; POWER
is architected to jump to exception handlers at 0x100...0x1000.
As a result of this, we have taken the approach of placing generic exception
handler entry / exit routines into ROM, and reserving a single pointer in
SRAM to determine the C ISR handler location. If no application is loaded,
this pointer is set to the BIOS ROM ISR. When an application loads, before
reenabling interrupts, it needs to set __rom_isr_address to the address of
the application's ISR, otherwise the BIOS ROM ISR will continue to be used.
Tested to operate with the built-in UART in IRQ mode, both in BIOS and in
loaded RAM application.
To be used with LiteDRAM's BIST Generator/Checker, ex:
from litedram.frontend.bist import LiteDRAMBISTGenerator, LiteDRAMBISTChecker
self.submodules.sdram_generator = LiteDRAMBISTGenerator(self.sdram.crossbar.get_port())
self.add_csr("sdram_generator")
self.submodules.sdram_checker = LiteDRAMBISTChecker(self.sdram.crossbar.get_port())
self.add_csr("sdram_checker")
Doing the test with 2 seeds prevents the test to success if previous content in DRAM was
still the expected one (ex after a sdram_cal command that succeded).
A CSR bus data-width of 32 has been validated on very various design and is
now recommended. It provides better performance without impacting resource
usage (even on iCE40).
Forcing megabytes per second for everyone does not make sense.
Showing bytes per second allows to distinguish between low performance and a performance measurement bug.
Anyway previous code claims speeds were in MiB/s, they were not, actually MB/s.
Generated soc.h says for example
but code tester for CONFIG_CPU_VARIANT_MIN not MINIMAL.
Attempted to run instruction unknown to this CPU, most likely cause of hang.
This allows riscv*-gnu-linux toolchains to be used to build LiteX
software. Without this, references to undefined stack guard symbols
get generated and linking fails.
FIXME: timebase-frequency isn't to be used as the raw CPU clock, so
on vexriscv we might want to re-evaluate also setting *that* to the
`CONFIG_CLOCK_FREQUENCY`. Decide whether to keep the SoC's
`bus-frequency` cell, or whether to go with the CPU's `clock-frequency`
only.
enjoy-digital
Raptor Engineering Development Team
bunnie
David Shah
Gabriel Somlo
Stephane Gourichon
Robert Winkler
Michael Betz
Shawn Anastasio
Vamsi Vytla