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

[ElEctric_EyE]

So I was getting some kind of picture in my testing using a simple ramp pattern generator. It was not 100%. Testing Red and Blue seemed ok, but Green was not ramping correctly. And after finding an error in pin assignments in the .ucf file early on, Green is still not ramping correcty. Then I realized this morning when I was touching some pins especially near the videoDAC, I would lose the picture entirely. So I added in the 75 ohm load resistors on the videoDAC outputs. Now nothing at all, except the H/VSync's and pixel clock. That's when I realized yet another design flaw. The complimentary RGB outputs are not grounded as the datasheet specifies. Time for some soldering...

My Tektronix 2440 'Scope is starting to go on the fritz too. Screen freezing up intermittently. This version I can send out to be fixed. But we'll see how much longer I can squeeze usefulness out of it.

EDIT:Got it working! Besides grounding the complementary outputs, I touched up the solder around the videoDAC. Something was very finicky there, this being the 3rd touchup, but now it finally works.

[BigDumbDinosaur]

ElEctric_EyE wrote:

Tools I use: Multi-Axis Vice (for holding board in place)...

I was going to ask: how do you get the vise (I assume you meant "vise", not "vice" ) to stay affixed to the bench? I have one just like it and it will not stay put for more than about a minute—it doesn't hold vacuum for very long.

[BigEd]

Hey, on this side of the pond it's a vice! (But EEye is on your side of the pond...)

[BigDumbDinosaur]

BigEd wrote:

Hey, on this side of the pond it's a vice! (But EEye is on your side of the pond...)

If I see "vice" in print I usually think bad things, e.g., excessive drinking.

[ElEctric_EyE]

BigDumbDinosaur wrote:

I was going to ask: how do you get the vise (I assume you meant "vise", not "vice" ) to stay affixed to the bench? I have one just like it and it will not stay put for more than about a minute—it doesn't hold vacuum for very long.

My "vise" sticks for about 2 minutes. It is a vacuum based vice, probably same as yours, placed on a veneer type table, so it isn't mounted on an absolutely flat suction leak-free surface. But it's good enough for me. As Tradesmen, we learn our tools...

[ElEctric_EyE]

While looking for cheaper prices from Cypress competitors, I actually came across a faster SyncRAM made by a company called GSI technology. And it's $15 cheaper @$139US and has an access time of 5.5ns, 1 ns faster. Looking into a 4Mx18 version. Avnet suggested this part as a replacement when I was searching for the Cypress 4Mx18 part.

Digikey does not seem to stock GSI parts.

EDIT: 5.5ns =181.8MHz. 1900x1080x60Hz = 180MHz according to this site. 1900x1080=2.052M pixels, almost exactly half(2.097M) of a 4Mx18 SyncRAM.

[Arlet]

ElEctric_EyE wrote:

While looking for cheaper prices from Cypress competitors, I actually came across a faster SyncRAM made by a company called GSI technology. And it's $15 cheaper @$139US and has an access time of 5.5ns, 1 ns faster. Looking into a 4Mx18 version. Avnet suggested this part as a replacement when I was searching for the Cypress 4Mx18 part.

Digikey does not seem to stock GSI parts.

EDIT: 5.5ns =181.8MHz. 1900x1080x60Hz = 180MHz according to this site. 1900x1080=2.052M pixels, almost exactly half(2.097M) of a 4Mx18 SyncRAM.

More important than the access time is the max clock frequency, both of the SRAM, and what you can manage to get done with the FPGA and on the board. At these frequencies, it will be challenging. In any case, there's more than just the access time of the SRAM. There's also the output delay of the FPGA pad, the trace delays on the PCB, and the input delay on the FPGA. All together probably good for another 4-5 ns of delay.

[ElEctric_EyE]

Arlet wrote:

More important than the access time is the max clock frequency, both of the SRAM, and what you can manage to get done with the FPGA and on the board. At these frequencies, it will be challenging...

Arlet, I'm glad you posted. I am postulating here, so forgive my lofty goals if they are not attainable...

This 1900x1080 will be the most aggressive of timings. Right now I am confident of 720p timings for a HDMI interface board I mentioned before, maybe 1280x720, using the current 2M SyncRAM. I am trying to plan for the Mainboard as it will need to be finalized soon. Always taking into consideration of at least 1 frame buffer in the SyncRAM... I would very much like to squeeze every last bit of performance from the $130+ 4M SyncRAM IC, if we were to head in this direction. I am a "Cost No Object" type performance oriented hobbyist...

The v1.0h board would require a videoDAC of a higher speed grade than the current 140MHz grade. Aside from this, I'm thinking maybe a CPU core (90+MHz), or maybe multiple RGB ALU's (100MHz+), controlled by the 8-bit parallel interface. Can the internal FPGA FIFO can deal with these rates with a 180MHz pixel clock in your opinion?

EDIT: BTW, the GSi Technology pin for pin Cypress compatible SyncRAM datasheet is easier for me to read and understand than the Cypress parts' datasheet. These parts have interesting behavior, especially when compared to old-school ASyncRAM, as stated in the GSi Tech datasheet:"In Flow Through mode the device may begin driving out new data immediately after
new address are clocked into the RAM, rather than holding new data until the following (second) clock edge. Therefore, in Flow
Through mode the read pipeline is one cycle shorter than in Pipeline mode."

[Arlet]

ElEctric_EyE wrote:

The v1.0h board would require a videoDAC of a higher speed grade than the current 140MHz grade. Aside from this, I'm thinking maybe a CPU core (90+MHz), or maybe multiple RGB ALU's (100MHz+), controlled by the 8-bit parallel interface. Can the internal FPGA FIFO can deal with these rates with a 180MHz pixel clock in your opinion?

The FPGA can certainly run parts at 180 MHz, but it may require some extra pipeline stage in the memory controller. Running the RGB ALUs at 180 MHz should be fairly easy, because they can be pipelined without compromising the results. Running a CPU at 90 MHz and interfacing to 180 MHz is unknown territory for me. I know how to do it with async dual port block RAM in between, but that will come at the cost of increased latency. I believe there are ways to combine synchronous 90 and 180 MHz clocks in the same design, but I've never done it before, and don't know how difficult it is.

[ElEctric_EyE]

This is good then. As long as you are reasonably confident, after all the 4M and 2M SyncRAMs have the same pinout, with the addition of 1 address pin. I've already added this feature and the v1.0h design is ready. Now it is only a matter of $ for the board run. Looking like a few weeks unfortunately, unless business picks up here...

EDIT: BTW, do you think removing Reset from your 6502 core would speed it up appreciably? How about if removing Reset, and/or NMI and/or IRQ? Thinking about it more, I guess we would need to keep Reset for the vector to point to the program start.

[Arlet]

ElEctric_EyE wrote:

EDIT: BTW, do you think removing Reset from your 6502 core would speed it up appreciably? How about if removing Reset, and/or NMI and/or IRQ? Thinking about it more, I guess we would need to keep Reset for the vector to point to the program start.

No, the critical paths all run through the ALU. From memory to ALU is usually a long one. Maybe the ALU could be optimized differently for Spartan-6.

[BigEd]

Arlet, I think you once suggested a specific change to pipeline the zero detect... Now that we have a good test suite and you have a rdy-wobbler, could you implement, test and release that change?
That would be much appreciated!
Cheers
Ed

[Arlet]

BigEd wrote:

Arlet, I think you once suggested a specific change to pipeline the zero detect... Now that we have a good test suite and you have a rdy-wobbler, could you implement, test and release that change?

Done

[BigEd]

Great - thanks!

[ElEctric_EyE]

Awesome, is someone running a speed comparison test?