Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Flipflop clock domain crossing

Hi,

I'm still fairly new to hardware design, so please bear with me.

I'm designing a double-scanlinebuffer for my sprite renderer.

While the VGA controller (at 25.175MHz) is displaying the pixel data from scanlinebuffer[0], a faster clock (100MHz) is filling scanlinebuffer[1] with new pixeldata.

At some point, when the vga controller has completed a line, it will switch and display the pixel data from scanlinebuffer[1], and the faster clock will start filling scanlinebuffer[0], and after another line is displayed, this whole process will repeat.

Now, this process has a problem: the scanlinebuffer needs to be cleared when the fast clock begins to fill it. Clearing the scanlinebuffer will take alot of cycles, which is not acceptable.

My idea then was to use a line mask buffer, which has an single bit entry for each pixel: 1 means the pixel has been set in the scanlinebuffer, 0 means the displayed pixel should be the background color. This line mask buffer is also double buffered, and is implemented using 2x 20x32bit flipflops. In this way, I can clear all 20 flipflops in a single clock cycle.

What I am uncertain about, is the fact that this double-linemask buffer will be clocked with the fast clock, while its data will be read by vga clock.

Note though, that because of the double buffering scheme, when the vga clock is reading linemaskbuffer[0], the fast clock will not be changing this buffer, but only linemaskbuffer[1].

The question I have is, will this way cause problems? Are there any dangers I need to be aware of?

And, as a purely theoretical last question, since I am using dual-clock RAM for the scanlinebuffer (read-clk is the vga clock, write-clk is the fast 100MHz clk), would it be possible to make this single-clock RAM, and switch clocks during the double buffer switch?

Thanks in advance

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    I've realised the linemask approach is a little too complex for me.

    Now I am tripple-buffering the scanlinebuffer. One scanline will be displayed, another will be filled, and another one will be cleared.

    This makes things a little easier, although I am still interested in the answer of my previous question.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Why do you need to clear the RAM? It's going to be overwritten anyway so what's the point in clearing it?

    I'm not sure I would use your same approach to tackle your problem but if I were, this is what I would do. The process would be the same for a double or triple buffering scheme.

    1 - Your writer side writes data into the scanline buffer. When it's finished, it stores the number of pixels written and passes a signal to the reader side indicating that the buffer is full. The writer side hangs until it receives a signal back from the reader side indicating that the writer side can move on to the next buffer.

    2 - The reader side waits for the signal from the writer side at which point it sends a signal back to the writer side to let the writer know it can move on to the next buffer. The reader side then reads the filled buffer and uses the stored pixel count from the writer side to know when to stop. When it gets to the end, it waits for the signal from the writer side and the process continues indefinitely.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    The RAM needs to be cleared, since the renderer will only fill a select set of pixels of the scanline, in order of visibility. The pixels that are not cleared, need to be a background color.

    To make the reason for clearing more clear - I want to be able to draw transparent sprites. By drawing these pixels in the correct order this can be achieved, but the pixels that are not filled, need to have a background color.

    Right now I am using a similar process as you describe - although the writer can not stall the process indefinitely, it is the reader that controls when the writer should move to the next line, even if it did not get to fill everything it wanted to.