Concept & Design of 3.3V Parallel 16-bit VGA Boards

[ElEctric_EyE]

Arlet wrote:

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.

It might be more flexible and be faster in most cases. But maybe this idea would be something to consider when one has to send alot of information. I was thinking the R/W line can be used to select between 2 banks of 8 16-bit registers. When the Board Select line goes active it means data was sent and after 16 clocks, the cpu can do what it needs to do with either bank of 8 registers depending on a sample of R/W. These shift registers could maybe operate at a multiple of the pixel clock frequency.

EDIT: I have rethought the power situation. Instead of 5V being supplied as the main voltage, 3.3V will be needed for the main, 5V for the video. This gets rid of 1 VREG and potential stress on that part, and should help out with the SSO issue. I will add a pic of the power plane today as well.

[Arlet]

GARTHWILSON wrote:

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.

Yes, but in this case the proposal is to have an 8 channel "serial" bus. Sending 8 bits at a time corresponds to 64 bits total, which isn't very efficient if the data isn't an exact multiple of 64 bits.

I'm also wondering if there won't be any problems synchronizing the data on a different clock. At 100+ MHz speeds, the data and clock will be out of phase by a significant amount. This can be compensated, but it would be easier to send the clock along with the data.

[ElEctric_EyE]

I was hoping to have a pixel clock below 100MHz. This way the CPU and pixel clocks could be one in the same. This clock would have to originate from the controller board, so the onboard oscillator would have to be jumper disabled. This oscillator is there mainly for testing purposes during standalone operation. I probably will want to bring it back down to 100MHz.

Having the shift registers (if one decides to go this route) probably could only run at a multiple of 2. The controller board would have to multiply the cpu/pixel clock frequency internally by 2 and the video board itself would also have to multiply this common cpu/pixel frequency internally by 2 for the common shift-in/shift-out frequencies. Maybe a block diagram would help...

This shift register idea is just an idea. It may turn out parallel would be best after all. Nonetheless, the signals are there for both ideas to be tested through HDL implementations.

[ElEctric_EyE]

I was getting tunnel vision... The signals are there, we can do what we want with the I/O.

What I realized today if I want this board made soon, is that I have to concentrate on the mainboard layout. The way the interconnections are made will actually dictate which pins are which on the main connector. Right now I see spaghetti! I have much work to do.

EDIT: I have started on this endeavour on a new thread.

[Arlet]

To get some more flexibility with the clock, it's probably a good idea to route one of the pins to a global clock input pin on the FPGA.

[ElEctric_EyE]

I would have to sacrifice 1 GCLK signal from the RAM. There are 2 possibilities looking at the truth table on Pg12 of the Cy7C1463 data sheet. Currently, I have /CEN and ADV/LD each going to GCLKs. I imagine CEN would be best to sacrifice and tie this line low.

[Arlet]

I think you can also remove one of the MAINCLK1/MAINCLK2 inputs. Each of those can be attached to a global clock net, so there's no need to have two identical inputs.

[ElEctric_EyE]

I've included 2 MainClk inputs, because if one were to use 1 input for a PLL for instance, then that input is used. You cannot branch off of that input.

[Arlet]

ElEctric_EyE wrote:

I've included 2 MainClk inputs, because if one were to use 1 input for a PLL for instance, then that input is used. You cannot branch off of that input.

For the org16 eval board, I only used a single 100 MHz GCLK, and fed that into a DCM to make a 24 MHz USB clock. That 24 MHz clock was then fed into a PLL to make the 54 MHz video clock. In addition, the original 100 MHz clock was used by a second DCM to create the SDRAM clock (phase shifted/inverted), as well as provide the CPU clock through a BUFG.

[ElEctric_EyE]

Interesting. I had generated the 12MHz for MCP2200 USBtoUART and 27MHz for CS4954 video using a PLL from 1 100MHz GCLK. When I tried to tap that same GCLK, using schematic entry, to create a 40MHz CPU clock, it gave me an error. So I used a second 100MHz tap. Must be a limitation of schematic entry.

[Arlet]

This PDF describes the Spartan 6 clock distribution resources:
http://www.xilinx.com/support/documenta ... /ug382.pdf

[ElEctric_EyE]

That is a 118-pg User's Guide. I am familiar with it. I'll get more familiar with it regarding GCLKs, unless you have something specific to point out, in order to save me time?

Regarding S6, I have:
ds160
ds162
ug380
ug381
ug382
ug383
ug384
ug385
ug386
ug388
ug389
ug393
wp360
wp368
wp370
xapp879

[Arlet]

Chapter 1, pages 11-26 look like they provide a decent overview of all the clock connections. It looks like there's plenty of flexibility. It could be that the schematic entry requires explicit use of some of the clock buffers to get the necessary routes assigned.

[ElEctric_EyE]

Excellent, thanks! Re-EDIT: I will look into this further as I notice the terms ISERDES/OSERDES. I noticed them before when skimming, but now I pay particular attention as they refer to serial-to-parallel and parallel-to-serial clocking on a higher order than even a GCLK.

I think we can keep the 2 MainClk inputs, unless you think it's a good idea to keep the SyncRAM's /CEN. The datasheet mentioned /CEN can be used to stretch access which is the only reason I kept it connected to a GCLK. If this were an asynchronous RAM, I would've grounded it from the start.

EDIT: But then there wouldn't be a ClkEn on an AsyncRAM...

[ElEctric_EyE]

Putting ISERDES/OSERDES aside for now...

I am busy reorganizing the signals on the main connector according to the mainboard layout which I've got some info about in this thread. The data I have in the header of this thread will change very soon to reflect the update. Simply put, pins 1-32 will be inputs. Pins 65-96 will be outputs. Pins 33-64 will be slower control signals. I'm posting now because I can say I am able to successfully reorganize the RGB I/O signals as I need to, in order to complete this PVB design very soon.

EDIT: New layout is complete. Constraints file and Main Connector pinouts are updated. Now back to Mainboard layout...
EDIT: Now all Main Connector Pins have been assigned, all former NC (no connects) are now GNDs. Main connector pinout and Layout updated.
EDIT: A few more optimizations have been made to the layout/main connector pinout/constraint file and posted to the header. Today, I'm completing a parts list while double checking pin to pin connections. If I find no errors, I am tempted to order the first 3 boards tomorrow, along with a few more parts in order to complete 2 boards. Will post a parts list soon to the header. 8/21/12