These provides some info about the SoC (though it's still somewhat
incomplete and needs more work, see comments).
There's also a control register for selecting DRAM vs. BRAM at 0
(and for soft-resetting the SoC but that isn't wired up yet).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The old toplevel.vhdl becomes top-generic.vhdl, which is to be used
by platforms that do not have a litedram option.
Arty has its own top-arty.vhdl which supports litedram and is now
hooked up
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Micropython has been able to fit into 384kB for ages, so lets reduce our
simulated RAM. This is useful for testing if micropython will run on an
ECP5 85k, which has enough BRAM for 384kB but not enough for 512kB.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
This replaces the simple_ram_behavioural and mw_soc_memory modules
with a common wishbone_bram_wrapper.vhdl that interfaces the
pipelined WB with a lower-level RAM module, along with an FPGA
and a sim variants of the latter.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This adds an output buffer to help with timing and allows the BRAMs
to actually pipeline.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Vivado by default tries to flatten the module hierarchy to improve
placement and timing. However this makes debugging timing issues
really hard as the net names in the timing report can be pretty
bogus.
This adds a generic that can be used to control attributes to stop
vivado from flattening the main core components. The resulting design
will have worst timing overall but it will be easier to understand
what the worst timing path are and address them.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This doesn't yet pipeline the block RAM, just generate a valid stall
signal so it's compatible with a pipelined master
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The shared variable used for FIFO memory is not VHDL 2008 compliant.
I can't see why it needs to be a shared variable since reads and writes
update top and bottom synchronously, meaning they don't need same cycle
access to the FIFO memory.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
We can now pass both the input clock and target clock frequency
via generics. Add support for both 50Mhz and 100Mhz target freqs
for both cases.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The memory wishbone doesn't clear ACK and move the state machine on
until STB is de-asserted. This seems like it isn't compliant with
the spec and results in a maximum throughput of 1 transfer every
3 cycles.
Fixing this improves the situation to one transfer every 2 cycles.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
(And rename it to mw_soc_memory).
This makes soc.vhdl simpler and provides the same interface as
the simulated memory, which will help when sharing soc.vhdl
with sim later
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This will be useful when we start needing different toplevels for
different boards.
We keep the reset and clock generators in the toplevel as they will
eventually be taken over by litedram when we integrate it, and they
are more likely to change on different system types.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This adds support for the Digilane Cmod A7-35.
I had to use the MMCM because the clock (12 MHz) is below the PLL
minimum of 19 MHz.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
The old reset code was overly complicated and never worked properly.
Replace it with a simpler sequence that uses a couple of shift registers
to assert resets:
- Wait a number of external clock cycles before removing reset from
the PLL.
- After the PLL locks and the external reset button isn't pressed,
wait a number of PLL clock cycles before removing reset from the SOC.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
Mikey points out that our stack grows down from 512kB and our
heap is below that too, so we can reduce our BRAM requirements,
which allowing some smaller FPGA boards to work. Not sure why
I thought we were using memory between 512kB and 1MB.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
Add a temporary gcc patch to remove hardware divide instructions.
Also add a firmware.hex file built with a gcc with the above patch.
Right now micropython assumes 1MB of BRAM, which limits the FPGAs
we can run on. We should be able to cut it down somewhat.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
Benjamin Herrenschmidt