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>
Anton Blanchard