HAHA! It works, finally I2C has been conquered. You know I've been tackling this I2C thing for more than a year now on and off. I hated serial, but now it doesn't seem so bad (minus the blurry data sheet explanations).
Thanks for your help. Sorry I drag the pace down with this 100 pound .b core on my back. But it will be worth it in the end....

Performing a load_reg when doing a CLC, SEC is incorrect? or it doesn't matter?

That's a bug. If load_reg is set, one of the registers will be overwritten, which is not supposed to happen during CLC/SEC.

Ok, I didn't bother to change it back in order to test it (I figured it would be quicker to ask). I'll update Github.

EDIT: Now I can program the CS4954 on the I2C bus with it's 'static' address of $00, I can reset the 'dynamic' address of the 1st DS1085. This will allow me to solder in the other 2 DS1085's after re-assigning their I2C addresses 1 at a time. Then I will add the TSC2003, touch screen controller for the TFT. I pursue this angle to make this Dev.Board mobile. I think, from an automotive standpoint, on revision 1.2 there will be some other voltage reg's on the board in order to facilitate up to 24VDC input. This could be from an auto DC supply or solar powered...

What really needs to be done first though is to test the CS4954 for VGA compatibility with it's RGB outputs and H/V Sync's. I'll do this test next week.

Hi Arlet

You mentioned (see quote below) that your first cut of your SDRAM controller took a simple approach, and therefore a 10ns memory on a 100MHz core might be comparable to a 14MHz chip running on SRAM. Do you have an update, if you've made any progress(*), or if not, do you have any idea of where you might get to?

Would I be right in thinking that a 50MHz core (that is, a core on spartan-3) with 10ns memory should be able to get close to the same throughput in absolute terms, and therefore better throughput in relative terms?

Cheers
Ed

(*) You mention here tracking which SDRAM row is active. That's a 4096-address range of memory you can get to more rapidly, I think, with the 16Mx16 part in this board.

Hi Ed,

It's a good question, but the answer is complicated and depends on a number of factors. First of all, the current performance of the SDRAM interface is like this (assuming CAS delay of 2):

• A random read that involves a change of row takes 8 wait states.
• A random read to a closed bank takes 6 wait states.
• A random read to an active row takes 4 wait states.
• A random write to an active row usually takes 0 wait states (a write directly following a read takes 1 wait state)

The SDRAM has 4 banks, and for each bank, a row has to be activated before you can do read/write. My current SDRAM controller tries to keep all banks active, so rows are never closed (precharged) unless that's necessary. The rows are 4096 * 16 bit each. The bank number is determined by the address bits [10:9]. The worst case performance is when you alternate access between addresses that are in the same bank, but have different row addresses (bits [23:11]), but you can get fast access to any of the 4*4096 words if you have more reasonable access patterns.

To read from 10 ns SRAM at 100 MHz, you need 1 wait state, maybe 2, depending on whether you need extra pipeline stage in the memory interface. My SDRAM interface has such a pipeline stage, because the AB value from the 6502 is combinatorial, and arrives late. Combined with the state machine in the SDRAM controller, I had trouble meeting the 100 MHz target. Of course, the state machine for the SRAM is simpler, so you may get away without the extra stage. At 50 MHz, you should be able to run with 0 wait states.

To go back to your questions. Suppose we have no cache, and put zero page, stack and code space all in SDRAM, and you do mostly reading from active rows (in normal cases that would be reasonable). That means 4 wait states per cycle, or performance equivalent to a 20 MHz SRAM. Writing would be closer to 100 MHz.

Of course, running everything from SDRAM is the worst you can do. In most programs you'd be able to put (part of) zero page in block RAM, as well as (part of) the stack, and frequently used pieces of code. If the program was too big for that, it would be wise to invest some time in an SDRAM accelerator. This could be a simple read-ahead buffer that translates each read into a small burst read, and caches the results, or it could be a full blown cache using a couple of block RAMs. The read-ahead buffer would be very effective for code execution, and would probably take the performance higher than running at 50 MHz + SRAM.

Thanks very much for the detailed reply! (I had vaguely thought there was such a thing as a bank, so thanks also for clarifying that.)

Agreed that sequential accesses such as code reads (and zero page and stack accesses) should benefit from burst accesses and even a small buffer. In fact, it sounds like there's a distinct advantage in arranging that zero page and stack accesses don't interfere with code and data accesses by bank or page conflicts. Memory is not uniform...

If you get a chance to run a benchmark of any sort (C64 BASIC or somesuch) that might be interesting. But we can already see that there are further gains to be made.

The LX9 on this board runs your (our!) core at nearly 100MHz and has 32 x 2kbyte block RAMs. The only non-BGA spartan3 would run at 50MHz and has only 3 block RAMs.

Cheers
Ed

There are several non-BGA Spartan-3 devices with more than that. The biggest one is the XC3S500E with 20 block RAMs. The small read-ahead buffer can be implemented with distributed (LUT) RAM by the way.

Of course, not mentioned in this discussion is other RAM usage. For my video/sprite controller, the SDRAM is also used to fetch sprite data. This has currently the highest priority, and runs every 64 usec, for at least 3 usecs (possibly in one long burst during which the CPU has no access to the SDRAM)

My mistake - I was in fact looking specifically at the non-volatile spartan 3an, because we could use those as a single chip pre-programmed hobby part. Good point about using LUT RAM too.

A few days ago I had successfully programmed the CS4954 with 100kHz I2C which was 'bit-banged' with a 6502 driver provided by Arlet, though I did troubleshoot the port to 16-bit .b core to make it work properly for my .b core.
The CS4954 displayed a multicolored test bar. I would like to increase the I2C communication speed to 400kHz, by changing the pull-up resistors from 4.7K to 1.2K. And also change the software delay and observe the signals on the scope to make sure the variable in software is a good value for 400kHz SCL.

Soon I program the 1st DS1085 programmable oscillator for a different I2C address, so I can solder the 2nd one in, and program it for a different address, then finally fit the last DS1085...

Also, I am very close to adding some modules Arlet has made for interfacing a SDRAM to display video.

There is one thing I must do first, and that is to successfully integrate the .b core, into my current project, utilizing at least some new features of the .b core. I will post progress in the software thread soon.

What is the purpose of these DS1085 devices on the board, by the way ?

Originally on V1.0 of the board, they were meant to free up the limited 2 PLL's of the XC6SLX9 I'm using. As you know, I needed 12MHz for the USB to UART MCP2200, and 27MHz for the pixel clock for the CS4954. Although, later I found out just 1 PLL can be used to generate these 2 frequencies from the main 100MHz oscillator. I've kept them there mainly for flexibility for future add on boards. The DS1085 signals go to the expansion headers as well for this purpose.

Actually, the XC6SLX9 has 2 PLLs and 4 DCMs.

I think the DCMs and PLLs frequencies are primarily 'static', meaning they're fixed after startup. Although the Spartan 6 series I think allows for a changing frequency input for the DCM and?/or? PLL. I've not read alot about it...
But if one wanted to change the frequency of a CPU to lower power consumption, for example, these DS1085's are perfect because they're advertised to cleanly change frequency with no runt pulses and the upper limit is 133MHz.

I got around to seeing if I could see the color bars on a VGA monitor, but no luck. I hacked off a VGA cable from an old monitor out in the garage and soldered the HSYNC, VSYNC, and separate R,G,B wires to some wirewrap wires I had tapped off of the respective pins of the CS4954 on the Devboard. I enabled the RGB DACs outputs with the lower 3 bits of register 5 and saw activity on the 'scope, but nothing on the monitor. I would've expected at least something to show up...

The CS4954 is good for composite, and Svideo, but I think in V1.2 of the Devboard I may just go with a videoDAC to support VGA. One similar to a 48-pin QFP AD7125 and have the pixel format in 16-bit 565 RGB. The FPGA would generate the HSYNC and VSYNC.

I'm presently changing the code of the SDRAMif module as suggested here and trying to piece it all together...

Did you verify that HSYNC and VSYNC are present, and are of reasonable frequency and duty cycle? If it's a CRT monitor you can usually hear the horizontal oscillator start up when a proper SYNC signal is applied. No oscillation means no picture, of course...

-- Jeff

_________________
http://LaughtonElectronics.com