6502.org

In the STA diagram, I don't see valid data on the SyncRAM data bus.

I don't know how to use a Verilog testbench using a model for the SyncRAM, so when the simulation reads from the SyncRAM the A accumulator become 'X's, but they appear to be in the correct timing cycle.

Yes, but why isn't the data bus valid when writing ? By the way, Cypress seems to have a verilog model here. You should be able to take that, and put it in your own top level schematic.

It's getting data from cpuDO, which is the A accumulator (it's undefined because of the previous LDA (SCRLO),Y): I'll try to do this. Is there an easy way to disable the model when not running a sim, or should I just have 2 separate project files?

I don't know what the easiest way is to do this in isim. I use a different simulator. What I do is make a top level main.v for ISE, and make a testbench.v module that includes both main.v and sram.v and other things of interest and hooks them together. When I run a simulation, it picks the testbench as a top level file, and when I do synthesis, it picks the main.v as top level.

Ok, forget the simulations for now. I've been going with what I have observed that works. And that is running the cpu at 1/2 the video pixel clock.

Today I did exhaustive testing and narrowed the margin for what works 100% and what doesn't work, as far as a read-write-read from the external SyncRAM is concerned.

First I'll explain the test, then the multiple hardware changes:
The test I performed was a 5-part test.

1) CPU writes to the SyncRAM to clear the screen. This tests a repeated write only with the smallest software delay.
2) CPU writes a 8x8 character to SyncRAM. This tests a write only, with some software algorithms to slow it down.
3) CPU writes a circle. This tests a write only, with different software algorithm. Also I can see a true square pixel with this.
4) CPU copy/paste the previously plotted character right next to the original. This tests a read-write-read.
5) Draw a line using LineGen, a hardware module running @cpu speed. This tests the lowest write delay from FPGA to SyncRAM.

I'll start with what works for all above tests, cpu always @1/2 pixel clock:
1024x768 @70MHz
1024x1024 @80MHz
1024x1024 @84MHz

Writing still works, but reading fails:
1024x1024 @88MHz

4MHz is a pretty tight margin, and a clue that I am failing to see right now. But I thought I would report before I forgot.

EDIT: Added #5. I had forgotten.

I think it's time to move on to a new design. One that I've been thinking about for a couple weeks now.
With a 4-layer board and a 1mm Xilinx BGA Spartan 6, I am pretty much limited to the 256-pin XC6SLX25 with 186 I/O. 84 more than the version I used here.
This will allow for another SyncRAM. They will be same 2Mx18 size, but I will try the GSI chip since I have 2 of the highest speed grade already, with virtually all of the control pins going to the FPGA.
This way the HVSync module can read uninterrupted from one memory and the cpu can read/write uninterrupted to the other memory. The FPGA will be responsible for flipping the data lines to the videoDAC.

I expect the new board design to take a few months, at least. And doubtful I will be able to fit it onto a 3.8"x2.5" board. Also, no 5V on this board, everything will be 3.3V. And no onboard FLASH or microSD, although there will be buttons for control purposes.

I think you should not get too carried away by the high SyncRAM clock rates, as you still need to account for round trip delays. Getting the max out of the SyncRAMs means writing a fairly complex memory controller. And if you're not going to write one, it's waste of money, as these suckers are expensive.

I wanted a very basic video design I could practice Verilog on. A platform that would not be soon overshadowed by new technology (talking basics here, not GPUs! but fast RAMs) that I could develop over a few years without being irrelevant.
I think the simplicity of this design on this thread demands a heavier knowledge to get the most out of it... Ideas like FPGA dualport scanline buffers and things like that due to the single RAM usage. Also, I was seriously constrained by the lack of FPGA pins in this design.
This newer design would cost abit more, but when you consider I am losing some ICs like the FLASHs and microSD adapter and 1 FPGA PROM, shouldn't be that much more...

Speaking of FPGA PROMs, I would like to investigate your usage of a non Xilinx FLASH to program the FPGA that you used in your 6502 sandbox thread. Xilinx has a 48-pin BGA (XCF08P) for this XC6SLX25. 8MB is needed for programming. And I don't like it because there's too many DNC's (no connections).

EDIT: This new IC has a 4ns cycle time (flow though mode). Since 2 cycles are actually needed for a read or write transaction, it could almost outperform the Cypress IC with 7.5ns access time by almost 2x, for <$20 per part @$66ea. BTW Avnet still has 4 left. They ordered more than I did and so some are left.

Of course I can't really quit this project until I have my rotating cube.

I am off for vacation for a couple days, but here is a pic of a plotted cube on the left, and a copy/pasted cube on the right.
Resolution is 1024x1024 pixel clock @84MHz. Not so square, but that's ok for now.

Also, I managed to program the FPGA PROM much quicker thanks to this tip I had missed before. Setting it to 22 works great. The highest setting of 26 works, but does not auto reset the FPGA.

There is no rotation without a circle for the virtex's to follow.
In my case it has to be a modified circle, i.e. an ellipse. I wish to do this circle/ellipse creation in Verilog.
There is a very smart clue here in this thread on how I would like to approach this.

Or, if I had a table of a circle in blockRAM, how would I go about scaling it for different radii?

Easy. Use a fixed point multiply. Suppose you have a 3.10 format scaling factor (3 bits before the point, 10 bits after it), you multiply by the scaling factor, and then remove the 10 least significant bits. The Spartan FPGAs have 18*18 -> 36 bit multipliers, so you can have 18 bit scale factors and coordinates.

Thanks Arlet, but some code now present on Wikipedia has led me to the same line of thinking as the Line generator I developed which has worked very well. For now I'll forego the math tables I was planning on pursuing.
Although I will need ellipses, starting with a successful Verilog circle algorithm will hopefully lead me in the right direction for the creation of ellipses.
I've never seen the code so clearly stated from the Wiki before the last couple days, or maybe I was in the wrong frame of mind (I doubt it): I'm thinking, after converting to Verilog, that this circle portion will add maybe 10 more states to the LineGen (which will be renamed to PlotGen). This module will act in a similar manner, in that 3 memory locations (blockRAM) will be written for XCenter and YCenter, and as soon as Radius register has been written to the plotting begins.
Ok, I'm off to write some code.

Also this site deserves mention.

Success!
Maybe a register is needed to count the pixels so the cpu can tell me exactly how big of a blockRAM is needed. 2xpixR would just be an approximation.