What kind of SDRAM controller have you looked at?

Yes, SDRAM they're cheap, maybe $5 for 16Mx8x4banks. Micron MT46V series. Instead of using Xilinx's core, Opencores has a few SDRAM Cores. Skimming them over, one guy made one for his system that used a T80 Core, VGA Core, UART etc.

The XC3S50 Spartan 3 in 100-pin QFP is the smallest Xilinx FPGA with BlockRAM. Some banks of the FPGA will have to be dedicated to the 2.5V I/O of the SDRAM, and then a bank dedicated to 3.3V to the 65816. The SDRAM I mentioned is available in 66-pin TSSOP. Alot of the pins are NC for the x8bit version, so maybe the XC3S50 will work... will have to try and fit the one of the SDRAM ccontroller cores in there first.

Maybe time to start a new thread about high volume memory. I have no idea how to control any sort of DRAM, but I would like to learn. I do know it is capacitor based and requires row and column refresh timings, I've known this since the C-64 came out, but it was intimidating back then. Also, I would like to see what some of the SDRAM controllers look like when implemented... Although I can't get into another project right now, I think I can start an interesting thread where we all could contribute to and learn from?

Interesting, over 20yrs ago the guys designing the C-64 decided to use DRAM. Andre has articles of CAS/RAS timing, and I believe he actually had the chance to talk to the original C-64 designer, Bill Herd IIRC?

The designer of the C128, yes, that's Bil Herd and I had a great conversation with him.

Using the advice he gave me I was even able to build a SIMM (memory modules with up to IIRC 4MByte each) based RAM disk for my 6502 computer. See
http://www.6502.org/users/andre/csa/ramdisk/index.html and
http://www.6502.org/users/andre/icaphw/design.html

Today technology has changed a lot. For any memory size of a 6502 or even 65816 based system I'd use SRAM now. A quick search at a provider shows that there are even today say 2MByte SRAM chips (not necessarily the cheapest, but 8bit parallel access). It's easy to design, easy to access and easy to build.

For my planned FPGA-based design I am planning to use two 512kx16 SRAM chips to get to 2MByte, but with a fast bandwidth (2x16 bit or even 1x32 bit, not decided yet).

Of course, if you need more memory, it seems like SDRAM is the only option these days. I haven't ventured into that area yet (and I don't plan to for the foreseeable time)

André

I once made my own. It was not very sophisticated, since I only needed long bursts to be efficient, but it ran at 100 MHz on a cheap Spartan-3. Even if you take into account a few cycles overhead per transaction, that's still decent. With some 100 MHz caches, it should be almost as fast as SRAM in typical cases.

Micron has some excellent data sheets, and they also have free Verilog models that can be downloaded to test the controller in simulation.

I'm sure I would never need to bring out all 32 bits of address bus. Programs will never get very big by comparison, but data for things like digital recording or pictures may need a lot of space, and indexing into something that's megabytes long is very inefficient the way the '816 would have to do it. I would like to be able to handle 32-bit integer values all in one operation, partly for data values but also for addresses and indirect addressing and indexing and offsets anywhere in the memory map without paging and banking. It's like everything is in this huge zero page except that you can use the offsets in the equivalent of the 32-bit DP, DB, and PB registers.

I would like to check it out because looking at the ones on opencores.org, a couple have 32-bit databuses, 1 has an 8-bit databus but looks rather complicated...
Did you make your SDRAM controller to be interfaced to your 6502 core?

Here's the source http://ladybug.xs4all.nl/arlet/fpga/source/sdram.v

It was interfaced to a 16-bit wide MT48LC4M16A2 device. I did use it together with my 6502 core, but it wasn't directly interfaced on the bus. Instead, I used a block RAM as an intermediate storage. A state machine would read a big burst from SDRAM, and store it in block RAM, while the other port of the block RAM was mapped in the 6502 memory space. The 6502 used the SDRAM only for reads (another state machine would write the data). As you can see in the sdram.v model, there a separate read and write port for this purpose.

Thanks again for sharing your work Arlet!

SDRAM's/controllers are beyond my capability to understand and use right now, but I am trying to learn...
Looks like they require a fair amount of 'dedicated' time in order to experiment and utilize these devices, although SDRAM's definately deserve attention. Not only from the standpoint of power consumption per byte, but also maximum memory size / max device pins... Although I do question the 'TRUE' speed of a 133MHz SDRAM compared to a 10ns SRAM with all the variable latencies and such.

Forget that power consumption comment....
I've recently seen spec's on a single 32MBx16 SDRAM device that hits approx 480mA, when all the rows and columns are refreshed simultaneously. Current draw starts at 180mA, IIRC for other modes of refresh.

Still learning...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Status Update - June 14, 2011

After getting the Video and keyboard working, I built the next daughter card.

It has a 65C22 and 65SPI. I have run into trouble with the design. The best I can tell, the buffers built into the 9572 on the main SBC-4P board are causing timing issues when reading and writing to the 65c22 and the 65SPI to a lesser degree. I have tripple checked the logic and wiring and cannot see any way to optimize the design more. I have reduced the system clock to 8MHz and have had better results, but still have intermittent errors.

These timing issues are mostly internal propagation delays (of different values) on the buffered lines. Address and R/W are stable prior to PHI2 going high so I know that's not what's causing the issues.

I also bypassed the buffered PHI2 and R/W signals and that helped some but do not completely fix the problem. I may go ahead and bypass all the buffers and test that. I am afraid that will result in a larger- than-desired loading on the data bus and lower address bus.

I just wish I had more free time to work on this.

Daryl

Hi Daryl,
How are you programming the 9572?
If you're using an older version of ISE, like 9 or 10, an updated version may help...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I'm using 8.1i I was told that newer versions do not support ABEL, which I am familiar with. I don't really want to try to learn verilog or VHDL. I may step up to a 95108 and see if that helps.

thanks!

Daryl

Before bypassing the data bus, I decided to swap the XC9572 with an XC95108. It actually fixed all the problems!

The 95108 must have enough extra resources to allow for lower propagation delays.

Now I will have to work up some test code to run all of the I/O together.

I have both daughter boards stacked and connected and the system is clocked at 8MHz. Once the test code is done, I will up the clock to 10, 12, 14, and 16 Mhz until I find the top end.

There is room for two more daughter boards in the I/O space. I might add two of each to really work it hard.

For those interested, this is one of the final steps I need to take before making kits available.

Daryl

Nice!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Here are the result of the first round of testing. The two daughter cards run stable at 12MHz. I could not find my 14 MHz oscillator. At 16Mhz, it runs the test code (65c22 T1 providing interrupts and the IRQ handler prints a FOX test to the video terminal while the OS is doing a continuous disassembly listing) without error but when viewing/updating IO registers on the 65SPI, I get errors. I need to get a 14 Mhz oscillator to test that speed.

Next, I am going to add my DiskOS and CF adapter to the 65SPI port and
test the max speed for that application.

Finally, I plan to add another IO-1 and Term daughter card to use all four I/O slots and see if I can still run at 12MHz. For that test, I will modify my SBC-3 Ethernet and run the Webserver application while dumping statistics to the two video displays. That should be a great I/O intensive test.

Daryl

I was able to wire in a 14.318MHz Oscillator to the SBC-4P and ran it with minimal trouble using three daughter boards. When I added the CF-SPI adapter and the ENC28J60 Ethernet module, I had intermittent lockups.

I am now back on a 12MHz system clock and the web server application has been up for over an hour without error. I will leave it on overnight to see how it does.

For those interested, it can be accessed by this link for the next 24 hours or so. It may be down intermittently and I will place my AVR web server back online after this 24 hour test.

Edit: <link removed>

Daryl