Today I was trying to generate HSYNC and VSYNC signals, but no activity from the FPGA. I saw activity coming from both PROMs when the Program button was pushed, but no activity out of the MUX (U4). Then I realized I have the output (pin4) and select (pin6) lines switched. When I disconnected the jumper which pulls the output (should be select) high or low thru a 4.7K resistor, I still see no activity which sort of bothers me. I can fix this mistake relatively easily, although I think I will purchase an X-Acto knife today before I do this.

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

Got the knife, made the corrections and I see signs of life! The VGA monitor light turns green recognizing the HSYNC and VSYNC signals, and the 25MHz pixelclock is coming out of the FPGA.

Version 1.0h is up to date. I was actually making other modifications to the layout as I was assembling this board. Time for some code on the Implementation thread.

EDIT: I will update the tools pic at the top of this page. I don't wish to intimidate, but also people make mistakes, and there are tools I used to correct mistakes, plus that original pic is pretty bad...

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

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.

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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...

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

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.

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

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.

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."

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

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.

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.

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

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.

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