I must confess it has taken me a few weeks after coming up with this idea of parallel computing, even after 99% completion of board design, to wrap my little mind around this design. It is not a simple one. I will tell you all honestly, what gives me confidence is that Arlet has agreed to help develop the HDL for this project. He has shown great skill in the recent past developing sprites with SDRAM timing for v1.1 of the 65Org16 devboard. But this design is totally separate from that one and I'm not calling this project a devboard. Hopefully, some of his hard work will be able to be imported into this design. I believe it will be... My intent here is to concentrate more on the video aspect and change to a more common VGA DB-15 style video output, while maintaining a 3.8"x2.5" board space...

This is the board layout, as it is now. Complete, unless a suggestion is made to improve it in some way. In another thread some people like Garth and Arlet have made important suggestions that I've taken into consideration for the layout of this board. Garth made suggestions regarding the main 96-pin connector GND layout and Arlet suggested a micro-SD card connector and also important suggestions regarding high frequency noise filtering for the videoDAC power supply. Also BigEd encouraged me to continue on a path of mixing video digitally when I started to stray into analog... Thanks all!

Link to CLOSEUP of layout for v1.0g: Original version.
Link to CLOSEUP of layout for v1.0h: Fixed layout errors with U4 MUX. Deleted FPGA control of DACBLANKn. Added FPGA control of SyncRAM ADV/LOADn pin. Also, added 4 momentary push-button switches for debugging/control purposes.




Let me try to explain the concept of the 16-bit design: Each video board has a 2MBx18 synchronous pass-through RAM (16-bits are used for 5-6-5 RGB, 2 parity bits unused...), a 144-pin Spartan 6, a videoDAC, a 3-row 96-pin main connector, and a DB-15 VGA connector for a monitor. The 96-pin main connector allows 16-bit RGB data in, HSYNCin, VSYNCin and PixelClockIn. These signals originate from another video boards' 16-bit RGB data out, HSYNCout, VSYNCout, PixelClockout and are also present on the main connector. The next video board in line can add depth to the video being displayed. Depending on the math, many possibilities exist... It'll be interesting to see how many boards can be successfully cascaded. For now, 4 can fit on another 'in situ' mainboard. We should be able to do preliminary tests in order to verify the design actually works using just 1 standalone video board without the need for a mainboard and controller board.

Looking at the board layout above, I will explain the design starting with U12. A 100MHz (200MHz alt.) oscillator goes to 2 global clocks on 2 separate IOBs on the FPGA, it is expected to divide this clock internally for less jitter. It also goes offboard through the main connector. A jumper (J1) can disable this clock and make its output high impedance. This jumper allows for an outside clock to synchronize multiple boards.
U2 is the 6.5ns pass-through synchronous RAM. 16bits of the databus go to the 4th IOB, top of the S6 (U1). All address lines go to the 1st IOB on the left of the S6. The remaining SyncRAM signals connected to FPGA global clocks are: the main CLK, R/W and ChipSelect.
U5 & U6 are basically 2 XCF04S FPGA PROMs connected in parallel, with standard JTAG connections. iMPACT should be able to see both and either can be programmed. Their serial outputs are multiplexed by U4 (a tinylogic '157 2:1 MUX). It's output goes to the FPGA. The MUX control is a jumpered (J2) resistor (R3), in order to be a pull-up or pull-down. This MUX control also receives a signal from offboard allowing for remote control, hence the resistor. The FPGA /Program signal is also routed offboard. There is also a push button(S1) for manual /Program control.
U9 & U10 are 64Mbit SPI serial FLASH. They each have common dedicated SPI lines, meaning only 1 can be selected at any time. This is done from a S6 /CS signal and U9 inverter.
U3 is the videoDAC. 16 signals for 5-6-5 RGB come from IOB3. The video DAC clock and blank signals come from FPGA global clock pins.
The micro-SD adapter has a built in switch when a card is present. This switch signal is present to the S6, letting it know when to use SPI communications. This signal is also output through the main connector (pin34), consider it a "Board Ready" signal. The SPI clk input is common to the one used for the serial FLASHs. If no card is present, MISO, MOSI, and CE (of the SD-Card adapter) are instead used as additional signals for an 8-bit parallel interface to control the video board via remote commands. This interface consists of 8 bi-directional data bus, R/W, Board Select and Board Ready previously mentioned. The Board CLK input signal is also present to a globalclock and orignates from a Controller Board. Specifications will need to be hashed out for commands to/from this interface, but these pins are there for development.



Constraints file:

The Parts List:


Observations: I think we will need very quick parallel 6-bit ALUs that can do add, subtract, logic AND, OR, EOR, no carry needed on a pixel clock to each Red Green Blue databus to the videoDAC. Once the first board does this math/logical operation in as few cycles as possible, it passes the HSYNC,VSYNC, PixelClock, and 16-bit RGB data into the following 'parallel' board. Recognize that the following board does not read this data and put it into it's own RAM. It is the programmers responsibility to program into the videoRAM of each board what each board is meant to output for the total summation effect. But more on the internals later, it still scrambles my mind!. This is Arlet's speciality. But I do intend to continue my learning some Verilog from this project, so be warned of stupid questions!
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
EDIT: 11/7/2013-... In an attempt to categorize parts of this thread, which has become quite long to some members' chagrin but was not my intention, I will post a 'concentrated minutes' for each page. This will consist of 1 or 2 sentences.

Page 1: Discussions regarding the concept. Simultaneously Switching Output (SSO) problem of FPGAs. HDMI output? Layout and main connector almost done. IO communication dicussion.
Page 2: More discussions on IO. Realization of a backplane design in order to solidify signals on each PVB. Use of GCLKs in FPGA.
Page 3: SyncRAM chosen, parts list completed. First board design .g manufacture order placed. Problems realized. Parts ordered to complete 1 PVB. Version .h started.
Page 4: Pic for tools I used for construct. Closeup of 1.0g board front and back. Pic's of soldering attempts. Initial testing of FPGA and 2xPROMs successful. HSYNC & VSYNC signals successful in Verilog (started Implementation thread). Found faster SyncRAM.
Page 5: Loftier goals of 1900x1080... Arlet adds RDY signal to his core. More PVB version .h info.
Page 6: Version 1.0h boards received. No schematics? Info of new GSI SyncRAM's. Arlet receives a V1.0h 'bare' board. A new thread is started (nov 9th - dec 1st) to try to draw lines in hardware. Arlet "races the beam".
Page 7: My first attempt at drawing a line in hardware, confirmed on the board Arlet received. He begins to write his own code: An improved VGA timing generator, a FIFO buffer and more... This page is worth reading.
Page 8: External memory controllers. Some of Arlet's code modified and some pics... Talk of delaying input signals going through IOB's.
Page 9: Experimenting with Verilog syntax. Arlet's board experiences an unknown problem.
Page 10: Questions about the PVB v.10h construction.
Page 11; Arlet fixes the problem with his board. Issue that caused problem remains unsolved but his board works again. More of Arlet's hardware line generator.
Page 12: More hardware lines in Verilog.
Page 13: Block diagram of the 65Org16 system on paper. Starting to learn Verilog by building a SoC on FPGA.
Page 14: Setting up the blockRAMs, initializing BRAMs. wired OR vs. internal tri-states for databuses. Using Arlet's .coe generator for initializing BRAMs.
Page 15: Arlet's makes bin2hex! Bringing up the simple SoC. Finding errors...
Page 16: Michael finds error in the .coe file. Also reverted back to older version 65Org16.b core. Signs of life of cpu writing to video SyncRAM and visible video output. Youtube video.
Page 17: Experimentation with different system speeds writing to SyncRAM only, and different resolutions begin. Porting over software, from old TFT project, to plot character bitmaps. Noise issues, experimentation with FPGA pin DRIVE strength to resolve.
Page 18: Talk of Arlet's 6502 Sandbox board and bypassing, some pics. More talk of bypass cap values. Garth has great links for design engineers and bypass cap's. Trying IOBDELAY again.
Page 19: Arlet has great ideas for video memory mapping in the 65Org16 64Kx16 zero page. I begin to understand his 'indirect indexed y' suggestion for memory map interface to the videoRAM. I begin to try to implement it in a clear screen routine.
Page 20: Some talk of Bruces' implemetation of Bob Bishops' Mandelbrot, blitters. Arlet has another idea to map the videospace into 65Org16 64Kx16 zeropage, but only 1 line using different 6502 (abs,x) addressing. The clearscreen routine works using Arlet's 'indirect indexed y' memory map interface.
Page 21: 65Org16.b Clearcreen software posted. Begin plotting pixels in software. Jumping right into plotting circles using software SQUARE and SQUAREROOT sub-routines. 8bit shares his Bresenham Circle 6502 code, losing these routines.
Page 22: Talk of filled circles. Trying to do filled by decreasing radii in concentric circles, also drawing lines in radar sweep. Both unsuccessful as error is seen. 8bit shares his Bresenham line 6502 software. Added a Random Number Generator for plotting and color lookup table. Added an opcode cycle counter that can be read by the 65Org16.
Page 23: Plotting characters using the cpu and the value read from the cycle counter. Barrel shift problem noted in all versions of the 65Org16 ALU when using LSR. A proper fix to the 65Org16 ALU is on this page.
Page 24: Calibrating the opcode cycle counter. Cycle counting some 65Org16.b circle and character plotting routines. Trying to optimize the software.
Page 25: Initial converting of 8bit's 65C02 Bresenham Circle to 65Org16.b assembly and plotting results. Some more problems with the 65Org16.b core. Daryl helps out. A major problem found in the .b core... Software circle plotting works!
Page 26:



EDIT: 8/8/12 - Added detail.
EDIT: 8/8/12 - Added Constraints file.
EDIT: 8/8/12 - Switched SO & FEN12n in Constraint file, updated layout pic.
EDIT: 8/8/12 - Added detail.
EDIT: 8/8/12 - Added more detail.
EDIT: 8/10/12 - Changed Title from Concept Design & Implementation...
EDIT: 8/13/12 - Added Power Plane pic
EDIT: 8/18/12 - Edited Constraints file
EDIT: 8/18/12 - Corrected .UCF file
EDIT: 8/20/12 - Added CLOSEUP link
EDIT: 8/21/12 - A few of last layout/main connector pinout/constraint optimizations
EDIT: 8/22/12 - Parts list additions
EDIT: 8/24/12 - Clarified info regarding Main Board
EDIT: 8/27/12 - Updated Parts List
EDIT: 8/28/12 - Finished Parts List
EDIT: 8/28/12 - Re-clarified old details in order to update design changes
EDIT: 9/3/12 - Added power connector, updated parts list
EDIT: 9/6/12 - Ordered parts today. Updated prices on Parts List. All IC's are up to date as of this EDIT date. Some discrete components are actually cheaper than listed here.
EDIT: 9/23/12 - Corrected .UCF file. Functional.
EDIT: 9/23/12 - Found mixed pins assignments in .UCF file
EDIT: 10/9/12 - Updated .UCF file and parts for v1.0h
EDIT: 10/10/12 - Added link for closeup of v1.0h layout
EDIT: 10/18/12 - Clarified that this is a 3.3V design in the Title
EDIT: 6/11/13 - Added pic of .h board
EDIT: 8/6/13 - Corrected .UCF file for v1.0h, and v1.0h brief
EDIT: 12/7/14 - Added System Block Diagram

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

Actually, there's no reason to limit the processing to 'as few cycles as possible'. Delaying the video by 1 ms for instance will not be noticeable to the user, allowing a large number of cycles to be used for processing, allowing pretty much arbitrarily deep pipelines. Using pipelining, the ALU operations would be easy to implement.

This is great news then!

I am working on the .ucf file, trying to make it as succinct as possible. After looking over Chapter 3 of UG625, the Constraints Guide, I am including LOC, IOSTANDARD, SLEW, and DRIVE.
Ex. from another project:


EDIT: The above passed without errors, but I see an error. I believe this is correct syntax as all keywords turned blue in the Xilinx text editor:

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

I've added the constraint file defining pin assignments to the head post. From this info now I will double check my pin choices vs. the board layout for errors.

I already see 1 change I will make to the layout, especially since it is not difficult, and switch Pin95 "FEN12n" (Flash Chip Select) with Pin72 "SO" since SO may perform better on a global clock pin, and the FEN12n is a slow signal. These assignments are at the very bottom of the .ucf file.

Hopefully, I won't be making many more changes though.

EDIT: I have made these changes.

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

I don't know if it's worth checking your work against the SSO (Simultaneously Switching Outputs) rules - basically if you drive too many bus signals with too high a drive, you may have trouble. Either you dial down the drive, or move the signals around to different pins.

Exactly Ed, this is why I've spec'd SLEW and DRIVE along with each pin LOC assignments. While any user can make their own .ucf file I wanted to include the basic one with the most reasonable options all-in-one easy to edit ASCII file that anyone can copy & paste.
I can say from experience, that DRIVE can make a difference in a design as when I had changed this setting in a TFT project, it got rid of some noisy signals.

EDIT: As you mention though, I must consider a signal going across all parallel boards. There are possibly just a few of those. I will check into this. Thanks!

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

Thinking about this more, I shouldn't have a problem with this unless all RGBin and RGBout from one board were oscillating as in a screen blinking at a high frequency from black to white. I would think that this would actually be a good stress test for the FPGA in regards to this potential problem you mention. As far as signal DRIVE strength, I will pay very careful attention, as I have on this board, and make all traces as short as possible on the mainboard. I still have yet to design it, but I would expect we shouldn't have to use the larger current drives. Maybe we could even get away with 4mA. I deviated from the standard 12mA on my TFT project and used 8mA drive on all signals. Considering all this though, I would expect the larger current drives to be present at the last board in the chain, the one actually driving the monitor.

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

My intention to have an HDMI output present off of a DB-15 VGA connector will not work. I had forgotten the pinout of the ADV7511W during this boards development. HDMI will require all RGB inputs. This will change the layout minimally. An HDMI output will require a totally separate board which I will consider when designing the mainboard.

EDIT: The layout and main connector pinout are up to date. A few more days of checking...

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

I decided to change the title to "Concept and Design..." vs. the previous "Concept Design and Implementation...". IMO we don't need another 15+page thread with all kinds of information mixed and hard to find for those interested in just certain parts of this project, myself included. I would like to keep this thread pure, as it has been so far, to the hardware level and IC package considerations...

The implementation thread should be a separate thread with all kinds of good info after the boards are made.

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

You would have a problem every time there would be a change from a dark pixel to a light pixel (or the other way around), for instance, a white line on a black background.

This is not a good situation!
The immediate solution would be to use a much larger FPGA, so the percentage of signals switching simultaneously are below 70%?
EDIT: SSO info is in the DS162. Pages 32 -

Well, I'm not abandoning this yet. Some good news on pg. 36 "Setting VCCAUX to 2.5V provides
better SSO characteristics.". Also, setting the DRIVE to 6mA seems to much improve things when VCCO is 3.3v on Table 34, Pg. 42. Since the outputs are only driving 1 more FPGA maybe we can get away with this low current, hopefully even less.

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

I think the limit isn't necessarily a percentage rather than absolute number of pins that are switching, so a bigger FPGA wouldn't help. Using a BGA package helps a lot, but that's not a very practical solution. I think you should just go ahead with the design you have, and then experiment with clock frequencies, slew rates and drive strengths to find out what the limits are.

I'll take that advice, thanks!...

I was thinking about the I/O communications today. Previously I'd envisioned an 8-bit parallel interface with a typical 8-bit data bus, Board R/W, Board Enable, and Board Ready. Within these 11 signals, 3 global clocks are available.

How superior would it be to have 8 separate serial data lines along with 3 global clock lines in control? After every 16 clocks a pixel would be plotted, based on the info shifted out from the 8 data lines into 8 16-bit wide registers at an 'as of yet' unknown frequency. I think 100MHz would be a realistic shift rate for these registers.

This is the simplest example of 16-bit register use for a single pixel using 3 of 8 databus lines:
1 register for 16-bit RGB info (@least 16 clocks)
1 register for X
1 register for Y

5 registers left!
EDIT: 3 registers previously mentioned for WRITEs, another 3 for READs.

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

I think a 8 bit parallel bus is more flexible than 8 x 16 bit shift registers. In the latter case, you always need 8 clocks to send a chunk of data, and that chunk is always the same size. With an 8 bit parallel bus, you can decide how many bytes to send per command.

SPI commands and parameters have variable lengths. They go eight bits at a time, but as for the data bits, just like on an 8-bit port of a 6522, you can assign the functions of those bits in the application, three for this, one for that, two for the other, etc.. Serial ports, interfacing to off-the-shelf serial ICs, make a project manageable whereas you might not live long enough to complete it otherwise. As for speed, SPI goes in serial, fast enough to record video on an SD card in a camera, and of course DVDs are serial too. Serial ATA is even a lot faster.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?