K1 Controller Board with Video Capture

[MichaelM]

EEyE:

I was not referring to clock inputs within an FPGA, but rather clock outputs from the FPGA to an external device such as the SyncRAMs. The FPGA has a dedicated, low skew path from a GCLKxxP/GCLKxxN pin to a BUFG buffer within the FPGA. No such device is required or provided for output clocks. Thus, if you are having a hard time routing from a GCLKxxP/GCLKxxN pin to your SyncRAMs, you can choose any convenient pin instead of a GCLKxxP/GCLKxxN pin.

On the other hand, it is very true that a DDR-based external clock driver should be driven from an internal clock net that is buffered by a BUFG driver as you showed in your example.

In most cases, external clocks which are to be used as inputs to the FPGA should connected to GCLKxxP/GCLKxxN pins to ensure that the low skew dedicated connection paths to the clock buffers can be used. In some situations, a clock not connected in this manner will not be usable in certain high performance circuits/applications such as PCI Express, DDR2 SDRAM, etc. However, in many other cases, a mis-connection of an external clock input can be routed to a BUFG driver using normal FPGA routing resources. There may be significant skew between the clock net and any associated data nets, but it may still work.

[ElEctric_EyE]

MichaelM wrote:

EEyE:

I was not referring to clock inputs within an FPGA, but rather clock outputs from the FPGA... No such device is required or provided for output clocks. Thus, if you are having a hard time routing from a GCLKxxP/GCLKxxN pin to your SyncRAMs, you can choose any convenient pin instead of a GCLKxxP/GCLKxxN pin...

I understand now. Thanks!

On the topic of delaying inputs to the FPGA, say from the databus of a RAM during a read cycle, have you had any success? I've tried to use IOBDELAY unsuccessfully in the Verilog and in the .ucf constraints file.
I've given up only because the design seems to work correctly without any delays. I guess the SyncRAM is plenty fast at 4ns.

[MichaelM]

EEyE:
i've not needed to use IOBDELAY. I've studied how they are used for DDR2 interfaces, but have not attempted to use them yet in one of my designs.

[ElEctric_EyE]

Finished adding in all the bypass capactiors.
I've added filled planes on the bottom of the board around the voltage regulators that should increase the performance.
Originally I did it to avoid adding more vias, for the negative side of the bypass cap's, as there alot of lines running on top of the board (not shown).
The white pads will be free of silkscreen so I can solder the voltage regulators and 0805 cap's.

Now I'll do the same underneath the HDMI audio section, touchscreen section and USB to UART section.

[ElEctric_EyE]

ElEctric_EyE wrote:

...Now I'll do the same underneath the HDMI audio section, touchscreen section and USB to UART section.

I meant on top, for shielding.
Almost done!
Starting the .ucf pin constraints file for the FPGA today. This is yet another check that will help ensure all the pins are correctly wired.

[ElEctric_EyE]

The constraints file is finished and posted on the header post. Found a few errors.
Redid some portions of the layout to make it look neater, the pic of the final version 1.0a is also posted on the header post.
Redefined the goals on the header post.
I'm toast. I might read up on the audio codec, it can sample inputs.

[ElEctric_EyE]

Would be a shame to waste that big blank space in there, 4 boards are going to cost me $200US.
That space can comfortably fit an 80-pin QFP. I'm looking into Analog Devices Audio Processors before I finalize this design. Since I have no FPGA pins left, I'm looking for devices I can add to the I2C bus and that can take advantage of other signals already present.
Another possibility might be wireless transceivers?

[ElEctric_EyE]

In the effort to maximize functionality of this board, every inch must be utilized so I continue optimizing...

Instead of 1 switch to reset 3 IC's simultaneously, i.e. 3x USB to UART ICs, a HDMI Receiver IC and a FPGA Program, there was room to add 2 more of these momentary reset switches so now the user can reset each of these IC's individually whenever necessary.
Still doing research on the IC that will fill in the blank space... Probably isn't going to be an Analog part, I'm leaning towards wireless transceivers. The difficult part is finding a transceiver that has a I2C interface. The ones I've seen have a UART interface, some have SPI. Still looking for the one with I2C.

[ElEctric_EyE]

Was reviewing this thread tonnight. I found 1 missing signal in the constraints file. It was for the clock (CLK) signal for the bidirectional 8-bit communication interface, pin 6 on the 96-pin I/O connector. Updated the .ucf file...

ElEctric_EyE wrote:

... The difficult part is finding a transceiver that has a I2C interface. The ones I've seen have a UART interface, some have SPI. Still looking for the one with I2C.

In addition to this desire, I was wanting to add a large serial FLASH to this project maybe for sprite pattern storage or something cool like that. So I did some research on I2C flash and came upon a link I would like to share.
I2C bus is too slow for these higher end devices. I2C is usually 100Khz or 400kHz (hi-speed). New/large (64Mbit) SPI FLASH bus is 75 MHz. On the other hand there are I2C EEPROMs, the largest I found was 2Kx16 (unacceptable). I'm starting to realize a serial system needs both SPI and I2C to take advantage of both worlds of ICs presently out there. Taking another look at the project.

[GARTHWILSON]

ElEctric_EyE wrote:

On the other hand there are I2C EEPROMs, the largest I found was 2Kx16 (unacceptable). I'm starting to realize a serial system needs both SPI and I2C to take advantage of both worlds of ICs presently out there.

I knew they went up to at least 128Kx8 in I2C and 1MHz (the 24c1024), but I just found Mouser has a 256Kx8 1MHz I2C one, 1.8V to 5.5V, in SO-8, at http://www.mouser.com/ProductDetail/STM ... fKv7un8%3d . It would be nice to have them much denser (many megabytes, or more), but I'm sure the reason they're not made in I2C is that it would take too long to read and write a large quantity of memory.

[ElEctric_EyE]

Thanks for checking that out Garth, I appreciate it!

But I was thinking today the amount of money that this (these) board(s) is going to cost and the fact that I am not maximizing the 21sqin board space means that I am wasting money.
That together with a few other facts: 1) I can't control more than 1 PVB. 2) I can't use the higher performance SPI FLASH. 3) I can't utilize the wireless transceivers. All because of FPGA pin limitation, I ran out of pins quickl!... I was just trying to race to finish with this thing because last time I designed a board, it took me 4 painstaking months and I already had the PCB footprint nailed down for the 256-pin 1mm XC6SLX45 Spartan 6....

I think what I really need to do is take one step back and do 2 things with this design, in order to accomplish everything I wanted to put into this design but presently can't, i.e. wireless transceivers, massive SPI FLASH, etc.. For this I'll need to maximize the board dimensions and go back to 6"x3.5", and start designing around the XC6SLX150 1mm 484-pin Spartan 6.

If I'm going to go "all in" with BGA experimentation, I might as well go large and do it correctly, including possibly purchasing a re-flow oven instead of using my custom hot plate.

[ElEctric_EyE]

Checking prices for the 484-pin XC6SLX150T-3FG484C @$181US vs. a 676-pin for $228US. on avnet in the -3 speed grade, commercial, non lead-free (for better soldering). Man that's alot of money!

[ElEctric_EyE]

Checking spacing for the 676-pin beast on the 6"x3.5" board. Some trimming and IC reorganization... Looks good so far. I'll work on the VCCINT power pin plane since it requires a separate dedicated power plane within the 3.3v power plane. Also, I'll assign the ground pins.
Interesting observation: More User I/O pins, same number of P/N_GCLK pins as the 256-pin Spartan 6.

[ElEctric_EyE]

ElEctric_EyE wrote:

Checking prices for the 484-pin XC6SLX150T-3FG484C @$181US vs. a 676-pin for $228US. on avnet in the -3 speed grade, commercial, non lead-free (for better soldering). Man that's alot of money!

After reviewing the Spartan 6 family, I don't need to spend that much to get what I need. I don't need all the bells and whistles the LX150 has to offer. I just noticed it was a T version, which I don't need either...
Currently, I'm aiming for a XC6SLX45-3FG676C. LX45 is the smallest of the Spartan 6 family with a 676-pin count and 1mm ball spacing. The device is 27x27mm. Currently it is $84 on avnet.express. Much better! This gives me confidence to proceed with this design, although they have none in stock with a 6 week factory lead time with minimum order of 1. No problem! I order one tonight and probably I'll be done in 6 weeks. Hell of a way to bring in the New Year.

Will I use all 676 pins? Absolutely not, but a greater percentage will be able to be routed out from all sides of the wider square on this 26x26 ball FPGA.

Just FYI, a note on Xilinx FPGA blockRAMs: I've been working with the LX9 series of Spartan 6, the 144-pin QFP version, on the 1080p PVB's for the past year. I've just about max'd out the available blockRAM usage @96%. Those boards have 1Kx16 zero page, 1Kx16 stack page, 4Kx16 ROM for the 65Org16, and another 32Kx16 storage for X,Y coordinate storage. So that's about 38Kx16 available blockRAM on that series of LX9.
The LX45 series blockRAM has approximately 152Kx16, 4x that of the LX9 series blockRAM. It's about 4x the price too ($20 to $80 as mentioned).

[ElEctric_EyE]

A fresh start
Alot of (n) - (no connects) on the LX45. Lucky for me this design does not require alot of connections north of pin A1.
I put some yellow paint to help me out... This is going to be difficult routing on a 6"x3.5" board.