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

[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?

[Arlet]

No, but when I was working on the cs4954 board, I had everything running comfortably at 100 MHz, including the core. The change helped a bit, but I don't recall exactly what the difference was.

[ElEctric_EyE]

For v1.0h I've decided to add 4 pushbuttons which will fit on the backside of the MicroSD adapter. They will all be pulled high by a 4.7K resistor, when any of them are pushed. I will edit the constraint file to show the switch signals.

[Arlet]

If you have some space, I'd also recommend adding a few test points, like these, with a resistor + LED attached to each test point. That way you can provide a simple debug/status indicator through the LEDs, and attach a scope probe at the same time.

[ElEctric_EyE]

Arlet wrote:

If you have some space, I'd also recommend adding a few test points...

I have avoided LEDs in this project, and anything else that may add inductance or any other possibility of noise. This v1.0g design takes successive hi-speed signals from previous boards, potentially at 108MHz. What' I've been doing for pin testing, is to cut about 4" length of .015" diameter WireWrap wire and wrap it around the scope probe and then test desired pins. Clearance is tight and requires a steady hand, but this works.

Now, if this were a BGA design, I can see how bringing out some pins as you've suggested, may help in troubleshooting...

EDIT: Corrected top MHz.

[Arlet]

You don't have any low speed signals that you can hijack for this purpose ? Something going to serial flash, or something like that.

[ElEctric_EyE]

Why would you want to do this? or maybe which signals would you want to look at in particular? I could surely put in some holes to accomodate the test points, however there are only 3 holes left in v1.0h design.

[Arlet]

ElEctric_EyE wrote:

Why would you want to do this? or maybe which signals would you want to look at in particular? I could surely put in some holes to accomodate the test points, however there are only 3 holes left in v1.0h design.

To make it easier to put a scope probe on a signal, and keeping your hands free at the same time. Holding a probe stable on a 0.5 mm pitch pin while fiddling with the knobs, or a second probe isn't very easy. The exact signals depends on thing I'd like to look at. The advantage of the FPGA is that you can bring out any signal (even a duplicate of an existing one) to any of the pins. For instance, if there's a weird problem that only happens once per second, you can try to create a trigger expression, and bring out that trigger signal to a test pin so you can capture it on the scope while probing any of the other signals at the same time.