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

[ElEctric_EyE]

Arlet wrote:

...I figure VGA needs a high priority, since it is has the real time requirements to keep the output going. An underrun on your pixel output will result in bad video output. For the CPU/line drawing it doesn't really matter if they are delayed a little bit...

Typically, how many pixels are good enough for the pixel output priority?

Arlet wrote:

...Note that in my state machine, there are no write bursts, forcing the WE# to be deasserted after every write. I assume your syncram will also allow write bursts.

It does allow for read or write bursts, but there weren't enough pins left on the FPGA to control it, so it's hardwired disabled so it loads the address each access.

Arlet wrote:

...You could have one read channel and one write channel in the SRAM module, and provide priority indication with your read/write enables (0=no read request, 1 = read request priority 1, 2 = read request priority 2, ...and so on). The SRAM state machine would then switch from read -> write if the write was higher priority, but stay in read mode if it wasn't...

Good idea, I will allow this idea to sink in.

BTW, check out the timing diag on Pg.25 of the SyncRAM datasheet. It looks like the data should be present 1 cycle later than all the other signals.

[Arlet]

The datasheet you linked to only has 19 pages. Edit: I found the diagram on page 12.

You are right about the write. The data should be presented 1 cycle later than the address.

Also, I was right about my guess that you can do back-to-back write cycles. It's not a "burst mode" because you have to change the address yourself, but that's not a big deal. This means you can improve the state machine such that a WRITE can follow another WRITE, instead of going back to IDLE.

As far as the number of pixels, I would just let the VGA output module have the highest priority on the memory bus, but only request a read when it actually needs the data. If you're using a FIFO, you can even have two different priorities, depending on how full the FIFO is. For instance, when the FIFO is not completely full, you can do a read request at the lowest priority, so it will claim any idle cycles. When the FIFO is nearly empty, change the read request to the highest priority to prevent underflow. This "low water mark" should be picked such that even in worst case conditions the FIFO doesn't underrun. The exact value depends on VGA bit rate and how long the SRAM state machine would take to switch modes and fetch the new data (only a handful of cycles).

[ElEctric_EyE]

I have an older data sheet with 3 parts #'s with different data widths. Timings are on Pg.12, but nothing appears to have changed.

Also I don't think there is a need for a delay after a read to a write transition with this IC.

[Arlet]

There's a good reason why the write data is delayed: it matches the access delay of the read. This means you can switch between read and write (and vice versa) without having to introduce dummy cycles for bus turnaround.

[ElEctric_EyE]

The state machine should very straightforward then. I'll tackle it using your structure. Thanks for the help!

[ElEctric_EyE]

Arlet wrote:

...As far as the number of pixels, I would just let the VGA output module have the highest priority on the memory bus, but only request a read when it actually needs the data. If you're using a FIFO, you can even have two different priorities, depending on how full the FIFO is...

I noticed you had bank bits in your controller module for the external video RAM. Did you use page-flipping?

[Arlet]

No, I used this code on an Xilinx eval board, which had two 16 bit SRAMs in parallel, so the bank switches between upper and lower 16 bits of data.

[ElEctric_EyE]

I'm thinking of proceeding using bank switching, that way the priorities of the different modules should be more streamlined, i.e. the active bank being displayed will just have one priority to read from the RAM, the inactive bank not being displayed can have multiple read/write priorities from the LineGen and cpu. First I'll try accessing the inactive bank during the inactive display period. Then maybe later, after this part is mastered try using the dual port FIFO, or would the dual port FIFO negate the use of page flipping?

[Arlet]

You mean you want to implement double buffering ? Display from one bank, and update the other, and then switch at every vsync ? Yes, that would be a nice thing to have. I would just put the logic in the VGA module, though.

[ElEctric_EyE]

Yes double buffering, but I was thinking about adding a done signal to the LineGen module and adding a done bit flag to the 65Org16 'P' register and 2 opcodes to set or clear the flag. That way there would be no rush to finish before each VSYNC.

[Arlet]

I would put the double buffering in the VGA module. All you need is a register that contains the start address of the frame in memory. The CPU can then write to this address during the vertical blank. That way, you can also implement triple buffering, or just have a single buffer, or do hardware scrolling.

[ElEctric_EyE]

Arlet wrote:

... All you need is a register that contains the start address of the frame in memory... or do hardware scrolling.

Oh, very nice!
I need to add a few hi-speed I/O flags to the .d core that will work in conjunction with the new, soon to be made, state machine.

[ElEctric_EyE]

ElEctric_EyE wrote:

I need to add a few hi-speed I/O flags to the .d core that will work in conjunction with the new, soon to be made, state machine.

The .d core cpu now has 4 outputs directly tied to the Processor Status Register bits [11:8]. Each bit output has 2 opcodes to set and clear the control bit. It is a 2-cycle operation. 2 of these bits will be immediately taken up for the most upper address bits on the video RAM for page flippling. So 2 are left for other control purposes.
The .d core also has 4 inputs tied to the Processor Status Register bits [15:12]. As inputs, they can be tested by 2 branch opcodes. Branch on clear, or branch on set per bit... Arlet gave a very helpful suggestion on page 2 of the .d core thread which allowed me to head in the right direction and complete this addition very quickly. The .d core Verilog has been updated, as well as the new opcodes on the new .d core branch on Github.
These additions have not slowed down the cpu speed from 100MHz, in the project, although more runs of smartexplorer were needed.

[ElEctric_EyE]

So before I transition to a state machine, and understanding now how the signals should be sent to the SyncRAM I must know what I am doing wrong with my simple attempt at a Verilog interface. I cannot abandon it until I know what is wrong with it.
I am close. A report soon

[ElEctric_EyE]

I see why it won't work now. It has to do with my attempt at using one output bus that was connected to the cpuDIN and no separate input bus, as I was only trying to write I didn't think I needed it and it was ok when just the cpu was writing.... I will move on the make the state machine now, now that I know what will work.

Speaking of state machines, I have an idea to make one that does all the plotting without the cpu. I got real excited when the LineGen module was able to run @180MHz. Yesterday I put in an order for 2 4ns 2Mx18 SyncRAMs, but they won't be delivered for 8 weeks. These have different pinouts, so I would have to redesign the boards, but this is way in the future.