I need a SDRAM controller

Hi everybody!

I did a controller to SRAM, so, I need controller a SDRAM, like it=B4s more difficult, (refresh). I=B4m looking for som code free in vhdl. I have seen one code with double port of xilinx but I have got actel.

a big ansker: do you recomend a core about this?, I have a friend that he have bought a core (edif) and he can=B4t enter more things in the FPGA, becouse de edif are in the top, and he can=B4t touch the core. I know that it=B4s sounds bad, but I prefer have the source in vhdl to can modify.

anybody know o have done a similar controller?

thanks

Reply to
merche
Loading thread data ...

Hi, Check out the

formatting link
web site and search for sdram_ctrl

Rajkumar...

Reply to
Rajkumar

thanks a lot, i=B4m look the controller that these page. Other thing, why for a dual port to SDRAM? i suppose it=B4s faster.

Reply to
merche

thanks a lot, i=B4m looking the controller on these page and it=B4s seem easy to understand. Other thing, why for a dual port to SDRAM controller? i suppose it=B4s faster.

Reply to
merche

thanks a lot, i=B4m looking the controller on these page and it seems use an Altera_mf Library, so i don=B4t know what to do for Actel. Other thing, why for a dual port to SDRAM controller? i suppose it=B4s faster.

Reply to
merche

I thought there was an SDRAM controller on opencores as well, but if there is I don't see it. Searching for 'sdram_ctrl' as you suggested comes up empty.

'Memory Controller IP core' seems to be that and more. According to the blurb, it supports SDRAM, SSRAM, FLASH, ROM and many other devices...but I'm guessing that it supports those at the cost of logic resources unless there is a way to parameterize it for the devices that you actually want so you don't end up with SSRAM, FLASH and ROM controllers if you don't happen to need them.

There are DDR SDRAM controller out there but those aren't the same thing. I guess if one wants a simple SDRAM controller, one will have to continue the search someplace else.

Kevin Jennings

Reply to
KJ

Multiple port memories come down to scheduling issues. On occasions you may need multiple modules to access the same memory at the same time. If you only have a single port, one of the modules will have to stall until the memory is available. If these modules are frequently in contention, your performance goes right out the window. Thus a memory that has multiple ports. Multiple ports allow simultanious access to the memory. Less contention. Better performance.

Reply to
Dwayne Dilbeck

About the following code :

[1] Verilog, not VHDL. But treat it as a reference design. [2] DRAM controllers are not especially daunting. Yes ... the data sheets are large, but the actual functions that need to occur (initialization, write block, read blocks, and refresh cycles) are pretty limited, and well documented. [3] What is a challenge is getting the parts (more an issue with the later DDR devices, and yet speedier interfaces) to run at higher speeds. I have not used ACTEL, but Xilinx has IOB FFs that are the secret to running at high clock rates. [4] This design is largely uncommented, and undocumented. But it is free, and like I said can be used as a design reference. [5] When you are debugging .... if you have an easy way to write/read blocks and verify data, then use it, ie an embedded processor. Otherwise, try to build a test block around your block, which initiates a write block, then verifies with a read block, and then allows you to view (??) the read back data. If this were a Xilinx design, chipscope is a good candidate to view read back data. Otherwise, you may need to add a uart to your code, and some logic to dump read back data to RS232 port.
--
Regards,
John Retta
 Click to see the full signature
Reply to
John Retta

Here is a Xilinx example.

Your system contains :

- CPU (microblaze)

- a DMA controller,

- the sdram controller

- a peripheral, and you'd like to copy data from this peripheral to SDRAM using DMA.

Case 1: You use opb_sdram, and everything is connected to the OPB bus.

This bus can only have one transaction going on at the same time, of course.

Say the CPU executes an instruction at address 0x1000. It makes a read request to the sdram controller to get the instruction. Until this request is finished, and the CPU gets the instruction it wanted, OPB bus can not be used for other things. Since SDRAM has latency, this means you lose cycles on the OPB bus.

If, for instance, the DMA controller needs to transfer data from the peripheral to SDRAM, it will have to wait.

Case 2: Yo use mch_opb_sdram. Everything is still connected to the opb bus, but the CPU has a cache and will use XCL to talk to the SDRAM controller. Therefore the CPU talks directly to the SDRAM controller when it needs to read/write SDRAM, and only uses OPB when it needs to talk to the peripheral or the DMA controller.

Say the CPU executes an instruction at address 0x1000. It makes a read request to the sdram controller (via XCL) to get the instruction. The SDRAM controller makes a burst and transfers address

0x1000-0x100F to the CPU cache (even though the CPU didn't ask, once you talk to a SDRAM you might as well do a burst, it doesn't take much extra time). Therefore while the CPU executes the next 4 instructions it takes them from the cache and the OPB bus is free. If the CPU wants to talk to a peripheral or BRAM via OPB bus this does not conflict with instruction fetching. Also, the OPB bus was not used until now, so the DMA controller can talk to the peripheral without waiting, read a burst of data, and talk to the sdram controller via opb bus to write this data. Of course the SDRAM controller can only make one SDRAM transaction at the same time, but you save on transaction setup time. Since the SDRAM controller "sees" two incoming transactions (read instructions / DMA write to memory) it will be ready to switch from one to the other, so you save on arbitration time.

So yeah, multichannel is faster, because OPB bus is not clogged by memory accesses from the CPU and can be used for faster peripheral access or DMA.

Reply to
PFC

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.