Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorHow to implement DE0 SDRAM as 2-port RAM
I currently use the tiny bit of memory on the FPGA for a computer vision project but it's way too limited. I have a stand-alone SDRAM controller from Altera (partially pasted below) but I need one more layer above that which implements this controller as a 2-port RAM entity. It seems like overkill to use QSYS with NiosII though, plus I'm not very familiar with it. What's resource will help me implement this controller as a 2-port RAM entity in the simplest way possible?
entity sdr_sdram is
generic(
ASIZE : integer := 23;
DSIZE : integer := 32;
ROWSIZE : integer := 12;
COLSIZE : integer := 9;
BANKSIZE : integer := 2;
ROWSTART : integer := 9;
COLSTART : integer := 0;
BANKSTART : integer := 20
);
port(
CLK : in std_logic; --System Clock
RESET_N : in std_logic; --System Reset
ADDR : in std_logic_vector(ASIZE - 1 downto 0); --Address for controller requests
CMD : in std_logic_vector(2 downto 0); --Controller command
CMDACK : out std_logic; --Controller command acknowledgement
DATAIN : in std_logic_vector(DSIZE - 1 downto 0); --Data input
DATAOUT : out std_logic_vector(DSIZE - 1 downto 0); --Data output
DM : in std_logic_vector(DSIZE / 8 - 1 downto 0); --Data mask input
SA : out std_logic_vector(11 downto 0); --SDRAM address output
BA : out std_logic_vector(1 downto 0); --SDRAM bank address
CS_N : out std_logic_vector(1 downto 0); --SDRAM Chip Selects
CKE : out std_logic; --SDRAM clock enable
RAS_N : out std_logic; --SDRAM Row address Strobe
CAS_N : out std_logic; --SDRAM Column address Strobe
WE_N : out std_logic; --SDRAM write enable
DQ : inout std_logic_vector(DSIZE - 1 downto 0); --SDRAM data bus
DQM : out std_logic_vector(DSIZE / 8 - 1 downto 0) --SDRAM data mask lines
);
end sdr_sdram;
Inst_frame_buffer : entity work.sdram_wrapper_frame_buffer PORT MAP(
rdaddress => rdaddress, -- IN std_logic_vector(18 downto 0);
rdclock => clk_vga, -- IN std_logic;
q => rddata, -- OUT std_logic_vector(11 downto 0)
wrclock => camera_pclk, -- IN std_logic;
wraddress => wraddress, -- IN std_logic_vector(18 downto 0);
data => wrdata, -- IN std_logic_vector(11 downto 0);
wren => wren -- IN std_logic;
);48 Replies
Altera_ForumI've condensed the camera and vga entities so that there is a single, top level file for both.
When creating a new component in QSYS, I'm having trouble guessing which group needs to be selected. Any of the following seem like they could be right: Bridges and Adapters/Memory-Mapped, Bridges and Adapters/DMA, Bridges and Adapters/Streaming, Bridges/Memory-Mapped, Bridges/Streaming, or Qsys Interconnect/Memory-Mapped The camera basically outputs address, data, and write enable while the vga entity basically outputs an address and accepts pixel data. Which "group" best fits these two entities?Inst_ov7670_controller : entity work.ov7670_top PORT MAP( clk => clk_camera, resend => "not"(btn(2)), config_finished => led(9), -- out sioc => ov7670_sioc, -- out siod => ov7670_siod, -- inout reset => ov7670_reset, pwdn => ov7670_pwdn, xclk => ov7670_xclk, pclk => ov7670_pclk, rez_160x120 => rez_160x120, rez_320x240 => rez_320x240, vsync => ov7670_vsync, href => ov7670_href, d => ov7670_data, addr => wraddress(18 downto 0), -- WRITE ADDRESS OUT --> dout => wrdata(11 downto 0), -- WRITE DATA OUT --> we => wren -- WRITE ENABLE OUT --> ); Inst_VGA_controller : entity work.vga_top PORT MAP( CLK25 => clk_vga, rez_160x120 => rez_160x120, rez_320x240 => rez_320x240, Hsync => hsync, --out Vsync => vsync, --out Din => rddata(11 downto 0), -- <-- READ DATA INPUT R => vga_r, G => vga_g, B => vga_b, address => rdaddress(18 downto 0) -- READ ADDRESS OUT --> );- Altera_Forum--- Quote Start --- When creating a new component in QSYS, I'm having trouble guessing which group needs to be selected. --- Quote End --- That is not quite how creating a Qsys component works. You first have to determine *if* the bus interface used by your component is compatible with the Avalon-MM specification, i.e., whether its use of the address, read, write, and data correspond to the Avalon-MM use of those signal names. If it does not, then you have to create bridge logic that maps the transactions. That bridge might incorporate a FIFO (to handle bursts or latency). So my first question is, do you have a simulation for your VGA bus interface and your camera controller? If not, you should really write one :) Cheers, Dave
- Altera_Forum
There are no packets or other data that can be reliably grouped or streamed. There are two different entities requesting to read and write from unpredictable addresses at unpredictable times usually simultaneously. So far I've created the QSYS component for the camera. I think I picked bridges and adapters/Avalon ST. It ended up being a memory master though after I set all of the parameters.. I messed up and made all the exports reside under one conduit name but other than that it might work.. I have a feeling I can't just connect the two masters to the SDRAM controller and trust that it will just 'figure' it out. There is probably some component that needs to handle that.. It would set priority like you mentioned earlier.. Any idea what component that would be? Maybe a frame buffer? I hope not because I want to be able to store and retrieve all sorts of other data using this SDRAM chip and random times..
- Altera_Forum--- Quote Start --- There are no packets or other data that can be reliably grouped or streamed. There are two different entities requesting to read and write from unpredictable addresses at unpredictable times usually simultaneously. --- Quote End --- But you call them camera and VGA interfaces. I would have thought they would work on frames of data. Based on your comments, the interfaces would not be implemented as Avalon-ST streams, but they do sound like they can be implemented as Avalon-MM master interfaces. --- Quote Start --- So far I've created the QSYS component for the camera. I think I picked bridges and adapters/Avalon ST. It ended up being a memory master though after I set all of the parameters.. I messed up and made all the exports reside under one conduit name but other than that it might work.. I have a feeling I can't just connect the two masters to the SDRAM controller and trust that it will just 'figure' it out. --- Quote End --- Yes, you can. So long as the two masters implement the Avalon-MM protocol correctly, then read and writes should work fine. You would use your simulation to determine if the default arbitration shares are appropriate, or whether you need to change them. --- Quote Start --- There is probably some component that needs to handle that.. It would set priority like you mentioned earlier.. Any idea what component that would be? --- Quote End --- Stop making me repeat myself. If you're not going to read the documentation on Qsys, arbitration, and arbitration shares, then I'll just stop responding to this thread. --- Quote Start --- Maybe a frame buffer? I hope not because I want to be able to store and retrieve all sorts of other data using this SDRAM chip and random times.. --- Quote End --- This is what you need a simulation to determine. If data read pre-fetching or write-posting is appropriate in your design, then a buffer between your devices and the SDRAM might be sufficient. This buffering would be most efficient if your data transfers occur in blocks, but you make it sound like that is not the case. Cheers, Dave
- Altera_Forum
I'll read up on arbitration.
What's going on is the camera entity has it's own clock and is just churning out address + data values that represent the pixel locations and pixel colors that it sees. It can't wait, or buffer, or anything. I'll probably have to use a FIFO memory component that uses the FPGA's limited memory. The vga_out entity is doing the same thing at it's own independent clock rate except that it is asking for pixel data for a given address location. Both entities read and write to the same address space for now. They also often request SDRAM access at the same time. I can't just have it wait until a complete frame is written to memory because that will interfere with the display image. What I really need is the closest thing possible to a 2-port RAM. - Altera_Forum--- Quote Start --- What I really need is the closest thing possible to a 2-port RAM. --- Quote End --- So why not use a board with QDR II+ SRAM then? The bottom-line is you have no hope of any sort of success without simulating your design. You need a simulation of how your camera interface works and how your VGA interface works. With those two simulations, you can determine if you can map them as Avalon-MM bridges, or if you can convert them to streaming interfaces. Then you can determined the memory interface requirements, so that you an determined whether you can use SDRAM or you require QDR II+ SRAM. SDRAM is good for bursts, not as good for random accesses, but it can implement large memories and cheap. QDR II+ SRAM is good for random access, but its small and expensive. Cheers, Dave
- Altera_Forum
I see. I can't really run simulations currently because of modelsim's sinlge-HDL restriction. I'll have to find a way around that..
There is an upside of lower cost if SDRAM ends up working out though. These will replace our current products if I ever get that far with it. Getting a clean 640x480 image is only step one in a 30+ step development process. As of writing this, the entire system is QSYS-based. The image has lost all of its noise but now has an interlaced-look to it (see attached image). QSYS did automatically create a FIFO, among other things, automatically which was nice. I now have to take wild guesses as to what is causing that interlaced look.. The camera and VGA entity ended up as "Bridges and Adapters/Streaming" modules which have Avalon Memory Mapped Master interfaces. One category of settings which is very likely to be wrong are the ones in the attached image. Do any of those stand out as definitely wrong to you? I don't know what "bits per symbol" is in this context. I'll have to look into that... UPDATE: It has a combination of pixelation, as if a 20x20 square is treated as one block, and an interlaced effect which gets worse as I slow the clock down from a starting point of 166MHz - Altera_Forum--- Quote Start --- I can't really run simulations currently because of modelsim's sinlge-HDL restriction. I'll have to find a way around that.. --- Quote End --- Modelsim can handle multiple languages. I use Modelsim-SE. Modelsim-Altera Edition appears only to support a single language: https://www.altera.com/products/design-software/model---simulation/modelsim-altera-software.html --- Quote Start --- There is an upside of lower cost if SDRAM ends up working out though. These will replace our current products if I ever get that far with it. --- Quote End --- Sure, but you need to exhaustively test your code to ensure that SDRAM can meet that requirement, and you cannot do that without proper simulation tools. --- Quote Start --- Getting a clean 640x480 image is only step one in a 30+ step development process. --- Quote End --- And without proper simulation, you're stumbling at step 1. --- Quote Start --- As of writing this, the entire system is QSYS-based. --- Quote End --- You have yet to convince me that you are using Qsys correctly. Just mapping your camera and VGA ports to seemingly identically names ports in Qsys does not make them Avalon-MM components. --- Quote Start --- I now have to take wild guesses as to what is causing that interlaced look.. --- Quote End --- No, you don't. You simulate and you understand, there's no need to guess about anything. --- Quote Start --- The camera and VGA entity ended up as "Bridges and Adapters/Streaming" modules which have Avalon Memory Mapped Master interfaces. --- Quote End --- You're just showing your lack of understanding here. That is just a "section" in the IP catalog. It means nothing. I'm going to stop responding to this thread until you post a simulation of your VGA and camera interfaces showing that they implement Avalon-MM master interfaces. Modelsim Altera Starter Edition is free, and you should be able to take your existing single-language code and either convince me the interfaces can be mapped to Avalon-MM interfaces or already adhere to the Avalon-MM requirements. Good luck! Cheers, Dave
- Altera_Forum
I have modelsim 10.1c SE installed and a testbench made but I need a SDRAM simulation model. Any idea what the detailed steps are to get one set up in modelsim?
# This reference design requires a vendor simulation model. # To simulate accesses to SDRAM, you must: # - Download the vendor model # - Install the model in the system_sim directory # - Add the vendor file to the list of files passed to 'vcom' in setup_sim.do # - Instantiate sdram simulation models and wire them to testbench signals # - Be aware that you may have to disable some timing checks in the vendor model # (because this simulation is zero-delay based) - Altera_Forum--- Quote Start --- I have modelsim 10.1c SE installed and a testbench made but I need a SDRAM simulation model. Any idea what the detailed steps are to get one set up in modelsim? --- Quote End --- Its quite possible that Altera has one for you. I'm pretty sure that the newer versions of Qsys have an option to create an example testbench design. I've used it with the DDR controller, and that includes a DDR model. Try and see if that scheme works with SDRAM too. Run the DE0-nano Qsys design and from within Qsys have it generate an example project. I just tried this with 12.1sp1, and the feature to create an example does not exist in that version. I don't have time to try another version right now, so you should go ahead and see if that feature works for an SDRAM model. If it does not, you can download models from ISSI or Micron's web site. The ISSI SDRAM is just a clone of some Micron model, you'll just have to find out which. ISSI probably has a "replacement part for Micron" list somewhere. Cheers, Dave
