I noticed in the SyncRAM datasheet Pg11 under Single Write Access:
Right now I have /OE hardwired to ground. Is there a potential problem with my setup?

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

If you only have a single RAM device connected to the FPGA it should be okay. When you put multiple devices on the same bus, you need the /OE.

Thanks!

I am almost ready to "throw the switch", or maybe a better euphemism would be "pull the lever", as in a gambler at a slot machine!

Now that the Parts List is complete and with some very limited funds, I will order a few of the cheaper parts, especially the micro-SD adapter so I can measure it and be sure my custom-component, based on the datasheet, is correct in the layout. This is the only small detail holding me up on making boards, besides $$$. Possibly next week, I'll put in the order for 3 boards. It is more likely this will be in 2 weeks though, as the pace of work in my business was slow last week. However, I already own 2 SyncRAMs, 3 DAC's, 5 2.5V & 1.2V VReg's, and 5 VGA sockets, so the heavier financial stuff is out of the way.

After the PVB's are made and assembled, experimentation and development can proceed for awhile, maybe a few months hopefully, before the need for the mainboard which should be cheaper. But it is taking some time to plan and design for. The general layout and design of the controller board and also the main expansion connector precludes the completion of the mainboard. I will need a controller board thread soon...

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

I decided against routing power through the main connector mainly because in order to test the first of the boards, we shouldn't even need to solder in the main connector. So there is a power connector on top. It's the standard male type compatible with today's ATX power supplies. The voltages will have to be rewired to accommodate 3.3V and 5V. The header should be updated soon.
EDIT: This will also greatly simplify the mainboard layout, without the need for splitting up power planes within the mainboard itself.
EDIT: I've used larger vias for all FPGA power connections. Hopefully this will help against anticipated problems related with SSO.

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

Well this is it! The final day of looking at this design for errors. I am satisfied that there is no possibility of any shorts or any mis-wiring. When I wake up tomorrow morning, first order of business is to send in the design for manufacture. Tomorrow I will also order the necessary parts to complete 2 boards. 1 will go to Arlet hopefully next week's end. I decided to expedite this process and just hope I have the SD-card layout correct according to the datasheet, instead of ordering parts then waiting and measuring, which would've taken at least 1 more week. I will probably expand the SMT pads abit just to be sure the adapter fits...

EDIT(9/5/2012): One other note. I added J2 (should be J3!!, to the upper left of U1) which is the HSWAPEN. Left unconnected, the FPGA's outputs will be high-impedance when being configured. This should be useful when programming a board in the chain, while other boards are receiving video data. Before HSWAPEN was grounded which would have made the user I/O output '1's.
EDIT (9/6/2012): Updated the main top down layout pic and also the closeup. These are representative of the design submitted for the manufacture of the version 1.0g boards, which should be considered my first and hopefully last attempt at a single 5-6-5 16-bit parallel RGB video board. Also updated the price list as Avnet was unfortunately out of the higher -3 speed grade S6.

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

Got the parts in yesterday. My wife says FedEx dropped off a box this morning, which must be the boards. Tomorrow I construct! I'll see if everything fits tonight.

EDIT: Arrg! Sorry, I forgot I had ordered the 64mbit FLASH IC's direct from Microchip last week as well... At least I have all the parts before the boards arrive. I will still measure the SD card adapter and measure the values against the 1.0g layout tonight. Hopefully the boards arrive tomorrow.

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

Emailed tracking # says boards will be in by EOD tomorrow (last day of my 'weekend'), which means next week will be more likely for 2 to be assembled. All the pad placement and sizes appear correct from measuring the parts.

Here's my plan for construction/testing since some ideas here are new: I will solder in the FPGA and 2 PROMs, power, and JTAG connectors and J2 (Prom Select) and apply power. If ISE sees all 3, I will try to successfully program each PROM. If ISE reports successful programming, I'll go on to fully populate the boards. Then the next test is to write some simple Verilog code to read contents of the RAM and display them on some resolution, hopefully 1280x1024. I will start a new thread on implementation before next week, on some code I am working on presently.

EDIT: Aiming for 1280x1024@60Hz which according to VESA timings shown by nice folks at tinyvga.com, gives a pixelclock of 108MHz. The access time+delay of the 6.5ns RAM will gives us a frequency of less than 153.8MHz. Even if the total delay of the FPGA design was an optimistic 5ns, this would give us a max pixelclock of ~87MHz. This realistically limits resolution to 1024x768x60Hz=65MHz (a FPGA delay ~8.5ns). Or maybe pushing things, 1280x800x60Hz=83.46MHz. This is such an odd frequency though. I will see what the ISE lightbulb tool can do for a PLL with some given frequency sources.
EDIT: The clocking wizard was able to generate 83.333MHz and 65.0MHz from a 100MHz input... So let's say I am being overly optimistic and we need to settle for 800x600. The PLL can generate the 40MHz, 49.5MHz and 50MHz pixelclocks for 60Hz, 75Hz and 72Hz VSync's from 100MHz.

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

The thing about video is that your RAM accesses will be sequential (for a frame buffer) so you shouldn't need to add much delay in the FPGA beyond your RAM cycle time, if you arrange for data in to be captured in a buffer before sending to further processing. Similarly, your addresses out would need to come fairly directly from flops. As Arlet has said, extra latency shouldn't be a problem so long as you align things like sync pulses with pixel data with an equal number of cycles of delay.
Cheers
Ed

The FPGA delay will be more than 5ns. But the good news is that it won't matter. All you need to worry about is maximum clock rate for the RAM, which is 133 MHz according to the datasheet. The rest is all pipelined. Of course, you can only get that 133 MHz if all you do is stream linear data from SRAM to the VGA output. So, no sprites or other interesting tricks, and no writing to the SRAM at the same time.
That's strange. Looking at the DCM in the Spartan6:
andYou can combine those to make a wide range of frequencies. And if that still doesn't produce the right frequency, you can even cascade them, or combine a DCM with a PLL.

Are there advantages to using this 6.5ns synchronous RAM with the ability to do back to back Write to Read in a single clock cycle? I would like sprites, I'd prefer to lower overall pixel clock speed in order to accommodate at least 1 sprite per board at the highest resolution possible

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

It looks like ISE Coregen (lightbulb tool) took 100MHzx5 then divided by 6 for 83.333MHz.

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

I haven't studied the synchronous RAM in detail, but it appears that it will save a cycle here and there. If you clock the SRAM at 133 MHz, for a 1280x1024x60 Hz output, reading a full line of 1280 pixels will take 9.64 usecs, but it's only required every 15.63 usecs. That means you have 6 usecs per line to read sprite data, or 798 pixels. That's a decent amount, but that reduces the write window to the vertical blanking time.

EDIT: fixed the math

This is what I need to do in order to test the integrity of the 1.0g board design initially, as I must have a QC (Quality Control) experiment to qualify multiple boards before shipping.

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

The boards are in. Observations for the next run, version 1.0h:

K1 needs to be .030" closer to the bottom edge due to a flange. This can be fixed by removing the flange in this version.
K4 will also need to be moved .030" towards the right edge, as the size of the connector interferes with U9 & U10. Not a serious problem. I can solder in the ICs first, then mount K4 after grinding abit of plastic away with my dremel tool. Also, the mounting holes could be made .015" wider to facilitate easier insertion.

Everything else looks close to expectations. Will try to manage some pics after assemblage is completed.

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

Actually, I'll try to setup the camera for some decent pics as I start soldering the parts tomorrow morning on board #1. Starting from scratch on a bare board, pics only. I hope to encourage SMT bare board assembly. It's really not too difficult. There will be many pic posts tomorrow!

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