-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Utilizing on-board SRAM #758
Comments
I think indirect boot scenario b should be used according to your description. I try to find out more details about it. |
Hey there,
sure, that is possible. You "just" need an external memory controller attached to the processor's external memory interface. Accessing external static RAM is quite simple and you should have no problems finding a suitable (open-source) controller for that. I think Xilinx ISE (or AMD Vivado?) also provide an SRAM configuration for their MIG IP. Another option could be to use SPI SRAM attached via the SPI controller. It is slower and you cannot execute code from it (maybe you can, when you multiplex XIP) but it might be simpler to integrate as your do not need to touch the actual hardware. But this highly depends on your performance requirements. |
Thanks for your reply. This week, God willing, I will try to use SRAM controller. |
Hi there. I thinks one side of the SRAM controller should be wishbone compatible and the other side should connect to SRAM and control read/write operations. Am I right? |
Sounds good. With a Wishbone port you can connect the controller right to the processor's external bus interface and map the SRAM directly into the core's address space. |
Sorry, how should we determine that bootloader writes instruction/data to external (attached to wishbone interface) SRAM and processor reads instruction/data from it? |
I'm not sure if I understand your question correctly. For the memory controller it does not matter who (bootloader, debugger, application program, ...) reads/writes what (data or instructions). The controller just translates Wishbone accesses into SRAM accesses. |
Ah now I understand. If you disable the processor-internal IMEM ( The default bootloader will always write any new application data starting at address 0x00000000 - so it does care if this is actually written to the internal IMEM or to an external memory. |
Thanks for your reply. Do we need to specify data and address size in this case? |
The bus provides 32-bit for the address and 32-bit for the data. If your SRAM only provides a 8-bit or 16-bit port then you'll need to implement some kind of state machine to transform 32-bit accesses into consecutive 16/8-bit accesses. Note that the bus interface also supports smaller access granularities, i.e. 8-bit and 16-bit accesses.
"Data space" is just a software concept. On the hardware level there is just memory. You can put your data wherever you want - including your SRAM if that is what you want. |
I think this can be closed, right? |
Hi. Yes thank you. |
I have this one on my stack (but haven't tested it yet): https://github.com/chkrr00k/sram-controller/blob/master/sram.vhd It is quite simple and written in VHDL (❤️). 😅 |
You are awesome! |
Hi @stnolting |
I would suggest to keep the code base as clean as possible so you don't run into merge conflicts when there are upstream changes in the Wishbone gateway 😉 So I would just add the memory controller as individual module and connect it via Wishbone to the processor:
|
You're right. Thanks |
Hi @stnolting |
I found it in |
👍 👍 👍 Keep us updated (if you like) with your SRAM progress! 😉 |
yes pls I will probably in the future also need something very similar to this application case. It was really useful to have this information as a starting point. Ty! |
Ok. surely. |
This is my SRAM controller. It starts when both This is the waveform of SRAM controller. As can be seen, I couldn't get it work with NeoRV32 up to now and bootloader texts to choose uploading binary or execute are not shown. The simulation needs uploading data from UART and I should find a way to do that. |
@stnolting, do you have any idea for connecting a virtual UART terminal to my simulated design? |
Hi! Try with this file uart_rx.simple.vhd. And add it in your test bench as follows: architecture tb of tb is
-- your signals/constants
constant baud0_rate_c : natural := 19200;
constant CLOCK_FREQUENCY : natural := 100000000;
constant uart0_baud_val_c : real := real(CLOCK_FREQUENCY) / real(baud0_rate_c);
begin
your_top_under_test_inst: entity work.your_top_under_test
generic map(
--Your generics
)
port map (
--Your ports
uart0_txd_o => uart0_txd,
uart0_rxd_i => uart0_txd
);
-- UART Simulation Receiver ---------------------------------------------------------------
-- -------------------------------------------------------------------------------------------
uart0_checker: entity work.uart_rx_simple
generic map (
name => "uart0",
uart_baud_val_c => uart0_baud_val_c
)
port map (
clk => clk,
uart_txd => uart0_txd
);
-- Your test
end architecture;
If everything is okey you will see through asserts the uart output in the terminal where you are running the simulation. For example if you use VUnit your going to see the output in the terminal using As shown in the following image: I hope you find it helpful! |
Thanks a lot. |
Thanks for sharing your sources and all the details! You should really put them into a repository! I think that many people would find them useful. 👍
Good idea! One more suggestion from my side: if you enable the internal IMEM and DMEM + the bootloader you can use the bus_explorer program to execute XBUS transactions by hand. Together with an oscilloscope / logic analyzer this can help to debug the FPGA-SRAm interface. |
Thanks for your positive attitude @stnolting. |
Here is my SRAM controller. It's a work in progress. |
Looks great! 👍 |
Is your feature request related to a problem? Please describe.
I have a benchmark that uses large matrices (in order of 200KB data). My FPGA is Spartan 6 that has limited resources but it is connected to a 512 KB SRAM. I need to use this SRAM when I load my instructions and data with UART.
Describe the solution you'd like
Is it possible to have imem and dmem as caches on FPGA and SRAM as the next level memory?
The text was updated successfully, but these errors were encountered: