How is it possible to drive VGA displays at such high pixel clock frequencies?RAM device / timings for small VGA projectFPGA VGA Buffer. How to read and write?How does this circuit attenuate high frequencies?Video Controller DesignVGA controller using FIFO memory, discrete ICs and Arduino Uno/Mega?Why asynchronous counters can not work at high clock frequencies?Character mask VGA displayHow very high frequencies (VHF) are propagated during night over large distances?Why doesn't my VGA implementation using an AVR microcontroller work?Transistor count of a shift register

Is it possible to clone a polymorphic object without manually adding overridden clone method into each derived class in C++?

Logistic regression BIC: what's the right N?

Can I take the the bonus-action attack from Two-Weapon Fighting without taking the Attack action?

Is "cogitate" used appropriately in "I cogitate that success relies on hard work"?

How do I increase the number of TTY consoles?

Smooth vector fields on a surface modulo diffeomorphisms

Do black holes violate the conservation of mass?

Difference between `nmap local-IP-address` and `nmap localhost`

What will happen if my luggage gets delayed?

How to write a chaotic neutral protagonist and prevent my readers from thinking they are evil?

What is better: yes / no radio, or simple checkbox?

Does an unused member variable take up memory?

Too soon for a plot twist?

What would be the most expensive material to an intergalactic society?

Would those living in a "perfect society" not understand satire

I reported the illegal activity of my boss to his boss. My boss found out. Now I am being punished. What should I do?

Use Mercury as quenching liquid for swords?

Help! My Character is too much for her story!

Is there a way to make cleveref distinguish two environments with the same counter?

Is divide-by-zero a security vulnerability?

Are these two graphs isomorphic? Why/Why not?

How to copy the rest of lines of a file to another file

Factor Rings over Finite Fields

Can I negotiate a patent idea for a raise, under French law?



How is it possible to drive VGA displays at such high pixel clock frequencies?


RAM device / timings for small VGA projectFPGA VGA Buffer. How to read and write?How does this circuit attenuate high frequencies?Video Controller DesignVGA controller using FIFO memory, discrete ICs and Arduino Uno/Mega?Why asynchronous counters can not work at high clock frequencies?Character mask VGA displayHow very high frequencies (VHF) are propagated during night over large distances?Why doesn't my VGA implementation using an AVR microcontroller work?Transistor count of a shift register













1












$begingroup$


I'm working on a digital circuit using discrete components to drive a 640x480 VGA display in a 80x30 text mode.



For a 640x480 display, the pixel clock is 25.175MHz, which has a period around 40ns. I don't understand how I'm supposed to be able provide a new pixel to the display this often.



The basic architecture for my circuit is as follows:



  1. Binary counter for horizontal pixels counts up at 25.175MHz to 800 (640 visible pixels + 160 for front porch, sync, back porch).
    At 800, increment vertical line counter (and reset at 525 lines)


  2. Using horizontal and vertical position, derive the x,y coordinate of current character.


  3. Using x,y coordinate of character, index into video memory to retrieve ASCII character.


  4. Use ASCII character to index in character ROM to obtain bit pattern for character


  5. Use parallel to serial shift register to convert 8 pixel line of character to individual bits at pixel clock frequency


If you follow the chain, it goes:
Counter -> RAM -> ROM -> Parallel to Serial Shift Register



Using the fastest components I can find, the propagation delays and access time add up to around
15ns + 20ns + 70ns + 15ns = 120ns, much greater than the 40ns period for 25MHz.



At even higher resolutions and refresh rates, you can have pixel clocks well above 100MHz which will be a 10ns period.



How is it possible to provide new pixels to the display every 10ns when just the access time for RAM/ROM are already well above it, not even considering all the other signals in your system?










share|improve this question









$endgroup$







  • 1




    $begingroup$
    You use dedicated video RAM, and clock that directly into your video signal. You work on figuring out what to display long before you actually display it.
    $endgroup$
    – Hearth
    7 hours ago






  • 1




    $begingroup$
    Go read about Maximite. It just uses an MCU's peripheral hardware and a few resistors to drive a VGA port. Start by examining the PIC32 peripheral he uses. Works fine. (I have a Maximite here.)
    $endgroup$
    – jonk
    7 hours ago











  • $begingroup$
    "The Cheap Video Cookbook" by "Don Lancaster"
    $endgroup$
    – Jasen
    48 mins ago















1












$begingroup$


I'm working on a digital circuit using discrete components to drive a 640x480 VGA display in a 80x30 text mode.



For a 640x480 display, the pixel clock is 25.175MHz, which has a period around 40ns. I don't understand how I'm supposed to be able provide a new pixel to the display this often.



The basic architecture for my circuit is as follows:



  1. Binary counter for horizontal pixels counts up at 25.175MHz to 800 (640 visible pixels + 160 for front porch, sync, back porch).
    At 800, increment vertical line counter (and reset at 525 lines)


  2. Using horizontal and vertical position, derive the x,y coordinate of current character.


  3. Using x,y coordinate of character, index into video memory to retrieve ASCII character.


  4. Use ASCII character to index in character ROM to obtain bit pattern for character


  5. Use parallel to serial shift register to convert 8 pixel line of character to individual bits at pixel clock frequency


If you follow the chain, it goes:
Counter -> RAM -> ROM -> Parallel to Serial Shift Register



Using the fastest components I can find, the propagation delays and access time add up to around
15ns + 20ns + 70ns + 15ns = 120ns, much greater than the 40ns period for 25MHz.



At even higher resolutions and refresh rates, you can have pixel clocks well above 100MHz which will be a 10ns period.



How is it possible to provide new pixels to the display every 10ns when just the access time for RAM/ROM are already well above it, not even considering all the other signals in your system?










share|improve this question









$endgroup$







  • 1




    $begingroup$
    You use dedicated video RAM, and clock that directly into your video signal. You work on figuring out what to display long before you actually display it.
    $endgroup$
    – Hearth
    7 hours ago






  • 1




    $begingroup$
    Go read about Maximite. It just uses an MCU's peripheral hardware and a few resistors to drive a VGA port. Start by examining the PIC32 peripheral he uses. Works fine. (I have a Maximite here.)
    $endgroup$
    – jonk
    7 hours ago











  • $begingroup$
    "The Cheap Video Cookbook" by "Don Lancaster"
    $endgroup$
    – Jasen
    48 mins ago













1












1








1





$begingroup$


I'm working on a digital circuit using discrete components to drive a 640x480 VGA display in a 80x30 text mode.



For a 640x480 display, the pixel clock is 25.175MHz, which has a period around 40ns. I don't understand how I'm supposed to be able provide a new pixel to the display this often.



The basic architecture for my circuit is as follows:



  1. Binary counter for horizontal pixels counts up at 25.175MHz to 800 (640 visible pixels + 160 for front porch, sync, back porch).
    At 800, increment vertical line counter (and reset at 525 lines)


  2. Using horizontal and vertical position, derive the x,y coordinate of current character.


  3. Using x,y coordinate of character, index into video memory to retrieve ASCII character.


  4. Use ASCII character to index in character ROM to obtain bit pattern for character


  5. Use parallel to serial shift register to convert 8 pixel line of character to individual bits at pixel clock frequency


If you follow the chain, it goes:
Counter -> RAM -> ROM -> Parallel to Serial Shift Register



Using the fastest components I can find, the propagation delays and access time add up to around
15ns + 20ns + 70ns + 15ns = 120ns, much greater than the 40ns period for 25MHz.



At even higher resolutions and refresh rates, you can have pixel clocks well above 100MHz which will be a 10ns period.



How is it possible to provide new pixels to the display every 10ns when just the access time for RAM/ROM are already well above it, not even considering all the other signals in your system?










share|improve this question









$endgroup$




I'm working on a digital circuit using discrete components to drive a 640x480 VGA display in a 80x30 text mode.



For a 640x480 display, the pixel clock is 25.175MHz, which has a period around 40ns. I don't understand how I'm supposed to be able provide a new pixel to the display this often.



The basic architecture for my circuit is as follows:



  1. Binary counter for horizontal pixels counts up at 25.175MHz to 800 (640 visible pixels + 160 for front porch, sync, back porch).
    At 800, increment vertical line counter (and reset at 525 lines)


  2. Using horizontal and vertical position, derive the x,y coordinate of current character.


  3. Using x,y coordinate of character, index into video memory to retrieve ASCII character.


  4. Use ASCII character to index in character ROM to obtain bit pattern for character


  5. Use parallel to serial shift register to convert 8 pixel line of character to individual bits at pixel clock frequency


If you follow the chain, it goes:
Counter -> RAM -> ROM -> Parallel to Serial Shift Register



Using the fastest components I can find, the propagation delays and access time add up to around
15ns + 20ns + 70ns + 15ns = 120ns, much greater than the 40ns period for 25MHz.



At even higher resolutions and refresh rates, you can have pixel clocks well above 100MHz which will be a 10ns period.



How is it possible to provide new pixels to the display every 10ns when just the access time for RAM/ROM are already well above it, not even considering all the other signals in your system?







digital-logic signal frequency vga propagation






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 7 hours ago









supershirobonsupershirobon

133




133







  • 1




    $begingroup$
    You use dedicated video RAM, and clock that directly into your video signal. You work on figuring out what to display long before you actually display it.
    $endgroup$
    – Hearth
    7 hours ago






  • 1




    $begingroup$
    Go read about Maximite. It just uses an MCU's peripheral hardware and a few resistors to drive a VGA port. Start by examining the PIC32 peripheral he uses. Works fine. (I have a Maximite here.)
    $endgroup$
    – jonk
    7 hours ago











  • $begingroup$
    "The Cheap Video Cookbook" by "Don Lancaster"
    $endgroup$
    – Jasen
    48 mins ago












  • 1




    $begingroup$
    You use dedicated video RAM, and clock that directly into your video signal. You work on figuring out what to display long before you actually display it.
    $endgroup$
    – Hearth
    7 hours ago






  • 1




    $begingroup$
    Go read about Maximite. It just uses an MCU's peripheral hardware and a few resistors to drive a VGA port. Start by examining the PIC32 peripheral he uses. Works fine. (I have a Maximite here.)
    $endgroup$
    – jonk
    7 hours ago











  • $begingroup$
    "The Cheap Video Cookbook" by "Don Lancaster"
    $endgroup$
    – Jasen
    48 mins ago







1




1




$begingroup$
You use dedicated video RAM, and clock that directly into your video signal. You work on figuring out what to display long before you actually display it.
$endgroup$
– Hearth
7 hours ago




$begingroup$
You use dedicated video RAM, and clock that directly into your video signal. You work on figuring out what to display long before you actually display it.
$endgroup$
– Hearth
7 hours ago




1




1




$begingroup$
Go read about Maximite. It just uses an MCU's peripheral hardware and a few resistors to drive a VGA port. Start by examining the PIC32 peripheral he uses. Works fine. (I have a Maximite here.)
$endgroup$
– jonk
7 hours ago





$begingroup$
Go read about Maximite. It just uses an MCU's peripheral hardware and a few resistors to drive a VGA port. Start by examining the PIC32 peripheral he uses. Works fine. (I have a Maximite here.)
$endgroup$
– jonk
7 hours ago













$begingroup$
"The Cheap Video Cookbook" by "Don Lancaster"
$endgroup$
– Jasen
48 mins ago




$begingroup$
"The Cheap Video Cookbook" by "Don Lancaster"
$endgroup$
– Jasen
48 mins ago










3 Answers
3






active

oldest

votes


















4












$begingroup$

There are two main reasons you are finding this challenging.



First, you are using older and more discrete (lower scale integration) parts than would have been used to do this in the era of VGA.



But next, you are using them in an atypical way. Specifically, your approach is not pipelined which means that you are having to add up multiple delays when determining your interval, and thus rate.



In contrast, synchronous digital designs which attempt to achieve speed try to do as little as possible between registers.



While the details would probably differ a little, crudely speaking it would work something like this:



  • You increment or reset the address, then that goes in a register.

  • You latch the address into the synchronous memory

  • You latch the output of the synchronous memory

  • You latch this into the address of the synchronous character generator

  • You latch the output of the character generator into the output register

  • apply the palette lookup...

  • into the synchronous DAC...

When you break a task down like this, you only get one combinatorial delay plus some propagation delay and register setup and hold times needing to fit between clocks.



A design built this way will take many clocks to produce an output - the latency will actually be higher than a purely combinatorial design. But it produces a new correct output on each cycle of a much faster clock.



And hey, it's video, it doesn't really matter if the CRT is drawing a dozen pixels behind the pixel counter - you of course take that into account in the timing of the sync signals so that they are correct compared to when the data actually comes out of the DAC.



In practice, almost all complex digital systems work this way, as it's a great idea - right up until a pipelined CPU hits a dependency on an earlier computational result or a conditional branch... Then things get interesting, as they'd talk about in the next lecture of a digital systems class - but fortunately your VGA situation is a lot simpler, especially if you don't yet worry about tearing effects if the character buffer changes while the screen is being drawn.



As a practical matter if you want to build this, do it in an FPGA. That will pretty much force synchronous memories on you if you use internal ones, or synchronous IO registers if you use external memory. You'll get a lot of nudging towards a proper design, the fabric itself will be faster than your discrete parts, and of course if you make a mistake you only need twiddle your thumbs while it recompiles rather than spend a long day re-wiring.






share|improve this answer











$endgroup$




















    1












    $begingroup$


    Using the fastest components I can find, the propagation delays and access time add up to around 15ns + 20ns + 70ns + 15ns = 120ns, much greater than the 40ns period for 25MHz.




    You forget that a graphics adapter would never only draw a single pixel – but at least a full scan line. Thus, this would be a completely pipelineable problem.



    Also, don't forget that there's been five decades of video producing hardware so far. Your problem would usually be solved with a special type of RAM, into which you render
    your letters on one port, and which is sequentially read out to a video signal DAC.
    That hardware is way, way faster than what you're looking at.




    The basic architecture for my circuit is as follows:



    1. Binary counter for horizontal pixels counts up at 25.175MHz to 800 (640 visible pixels + 160 for front porch, sync, back porch). At 800,
      increment vertical line counter (and reset at 525 lines)


    2. Using horizontal and vertical position, derive the x,y coordinate of current character.




    Nope, why would you do that? You'd simply put your row pixel into a contiguous area of memory and linearly put it out to your DAC – if this is about a CPU / MCU implementation, you'd not even let your CPU do that, but a DMA unit, programmed to do nothing but take one value after the other and put it out to e.g. a parallel data port, without any CPU core interaction.




    1. Using x,y coordinate of character, index into video memory to retrieve ASCII character.



    Ah, you want to render on the fly – good choice, but unusual at modern costs of RAM.
    Instead, you'd just render the character into a frame buffer beforehand, or if yor device is extremely slim, directly pipe out (see my DMA explanation above) the character row to the DAC.






    share|improve this answer









    $endgroup$




















      0












      $begingroup$

      So obviously that doesn't work; you need a pipeline.



      1) Store the characters contiguously in memory. Start at the top left.



      2) Fetch a character during the blanking interval. Continue to fetch characters in memory order.



      3) Pipeline each decoded character plus line index into the ROM.



      4) Pipeline the ROM output into a buffer.



      5) Pipeline the buffer into a shift register. Read out pixels continuously at 40ns intervals from this.



      (That implies you need to load a new character into the shift register every 320ns, which might even be doable without pipelining the whole rest of the system.)



      6) During horizontal blanking, either return to the start of the line or advance to the next character (ie start of next line.)



      Bonus feature: since you only need a character every 320ns, you could also read a character+colour pair and do either MSDOS-style or Spectrum-Style colour characters.






      share|improve this answer









      $endgroup$












        Your Answer





        StackExchange.ifUsing("editor", function ()
        return StackExchange.using("mathjaxEditing", function ()
        StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
        StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
        );
        );
        , "mathjax-editing");

        StackExchange.ifUsing("editor", function ()
        return StackExchange.using("schematics", function ()
        StackExchange.schematics.init();
        );
        , "cicuitlab");

        StackExchange.ready(function()
        var channelOptions =
        tags: "".split(" "),
        id: "135"
        ;
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function()
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled)
        StackExchange.using("snippets", function()
        createEditor();
        );

        else
        createEditor();

        );

        function createEditor()
        StackExchange.prepareEditor(
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: false,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: "",
        imageUploader:
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        ,
        onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        );



        );













        draft saved

        draft discarded


















        StackExchange.ready(
        function ()
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f426444%2fhow-is-it-possible-to-drive-vga-displays-at-such-high-pixel-clock-frequencies%23new-answer', 'question_page');

        );

        Post as a guest















        Required, but never shown

























        3 Answers
        3






        active

        oldest

        votes








        3 Answers
        3






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        4












        $begingroup$

        There are two main reasons you are finding this challenging.



        First, you are using older and more discrete (lower scale integration) parts than would have been used to do this in the era of VGA.



        But next, you are using them in an atypical way. Specifically, your approach is not pipelined which means that you are having to add up multiple delays when determining your interval, and thus rate.



        In contrast, synchronous digital designs which attempt to achieve speed try to do as little as possible between registers.



        While the details would probably differ a little, crudely speaking it would work something like this:



        • You increment or reset the address, then that goes in a register.

        • You latch the address into the synchronous memory

        • You latch the output of the synchronous memory

        • You latch this into the address of the synchronous character generator

        • You latch the output of the character generator into the output register

        • apply the palette lookup...

        • into the synchronous DAC...

        When you break a task down like this, you only get one combinatorial delay plus some propagation delay and register setup and hold times needing to fit between clocks.



        A design built this way will take many clocks to produce an output - the latency will actually be higher than a purely combinatorial design. But it produces a new correct output on each cycle of a much faster clock.



        And hey, it's video, it doesn't really matter if the CRT is drawing a dozen pixels behind the pixel counter - you of course take that into account in the timing of the sync signals so that they are correct compared to when the data actually comes out of the DAC.



        In practice, almost all complex digital systems work this way, as it's a great idea - right up until a pipelined CPU hits a dependency on an earlier computational result or a conditional branch... Then things get interesting, as they'd talk about in the next lecture of a digital systems class - but fortunately your VGA situation is a lot simpler, especially if you don't yet worry about tearing effects if the character buffer changes while the screen is being drawn.



        As a practical matter if you want to build this, do it in an FPGA. That will pretty much force synchronous memories on you if you use internal ones, or synchronous IO registers if you use external memory. You'll get a lot of nudging towards a proper design, the fabric itself will be faster than your discrete parts, and of course if you make a mistake you only need twiddle your thumbs while it recompiles rather than spend a long day re-wiring.






        share|improve this answer











        $endgroup$

















          4












          $begingroup$

          There are two main reasons you are finding this challenging.



          First, you are using older and more discrete (lower scale integration) parts than would have been used to do this in the era of VGA.



          But next, you are using them in an atypical way. Specifically, your approach is not pipelined which means that you are having to add up multiple delays when determining your interval, and thus rate.



          In contrast, synchronous digital designs which attempt to achieve speed try to do as little as possible between registers.



          While the details would probably differ a little, crudely speaking it would work something like this:



          • You increment or reset the address, then that goes in a register.

          • You latch the address into the synchronous memory

          • You latch the output of the synchronous memory

          • You latch this into the address of the synchronous character generator

          • You latch the output of the character generator into the output register

          • apply the palette lookup...

          • into the synchronous DAC...

          When you break a task down like this, you only get one combinatorial delay plus some propagation delay and register setup and hold times needing to fit between clocks.



          A design built this way will take many clocks to produce an output - the latency will actually be higher than a purely combinatorial design. But it produces a new correct output on each cycle of a much faster clock.



          And hey, it's video, it doesn't really matter if the CRT is drawing a dozen pixels behind the pixel counter - you of course take that into account in the timing of the sync signals so that they are correct compared to when the data actually comes out of the DAC.



          In practice, almost all complex digital systems work this way, as it's a great idea - right up until a pipelined CPU hits a dependency on an earlier computational result or a conditional branch... Then things get interesting, as they'd talk about in the next lecture of a digital systems class - but fortunately your VGA situation is a lot simpler, especially if you don't yet worry about tearing effects if the character buffer changes while the screen is being drawn.



          As a practical matter if you want to build this, do it in an FPGA. That will pretty much force synchronous memories on you if you use internal ones, or synchronous IO registers if you use external memory. You'll get a lot of nudging towards a proper design, the fabric itself will be faster than your discrete parts, and of course if you make a mistake you only need twiddle your thumbs while it recompiles rather than spend a long day re-wiring.






          share|improve this answer











          $endgroup$















            4












            4








            4





            $begingroup$

            There are two main reasons you are finding this challenging.



            First, you are using older and more discrete (lower scale integration) parts than would have been used to do this in the era of VGA.



            But next, you are using them in an atypical way. Specifically, your approach is not pipelined which means that you are having to add up multiple delays when determining your interval, and thus rate.



            In contrast, synchronous digital designs which attempt to achieve speed try to do as little as possible between registers.



            While the details would probably differ a little, crudely speaking it would work something like this:



            • You increment or reset the address, then that goes in a register.

            • You latch the address into the synchronous memory

            • You latch the output of the synchronous memory

            • You latch this into the address of the synchronous character generator

            • You latch the output of the character generator into the output register

            • apply the palette lookup...

            • into the synchronous DAC...

            When you break a task down like this, you only get one combinatorial delay plus some propagation delay and register setup and hold times needing to fit between clocks.



            A design built this way will take many clocks to produce an output - the latency will actually be higher than a purely combinatorial design. But it produces a new correct output on each cycle of a much faster clock.



            And hey, it's video, it doesn't really matter if the CRT is drawing a dozen pixels behind the pixel counter - you of course take that into account in the timing of the sync signals so that they are correct compared to when the data actually comes out of the DAC.



            In practice, almost all complex digital systems work this way, as it's a great idea - right up until a pipelined CPU hits a dependency on an earlier computational result or a conditional branch... Then things get interesting, as they'd talk about in the next lecture of a digital systems class - but fortunately your VGA situation is a lot simpler, especially if you don't yet worry about tearing effects if the character buffer changes while the screen is being drawn.



            As a practical matter if you want to build this, do it in an FPGA. That will pretty much force synchronous memories on you if you use internal ones, or synchronous IO registers if you use external memory. You'll get a lot of nudging towards a proper design, the fabric itself will be faster than your discrete parts, and of course if you make a mistake you only need twiddle your thumbs while it recompiles rather than spend a long day re-wiring.






            share|improve this answer











            $endgroup$



            There are two main reasons you are finding this challenging.



            First, you are using older and more discrete (lower scale integration) parts than would have been used to do this in the era of VGA.



            But next, you are using them in an atypical way. Specifically, your approach is not pipelined which means that you are having to add up multiple delays when determining your interval, and thus rate.



            In contrast, synchronous digital designs which attempt to achieve speed try to do as little as possible between registers.



            While the details would probably differ a little, crudely speaking it would work something like this:



            • You increment or reset the address, then that goes in a register.

            • You latch the address into the synchronous memory

            • You latch the output of the synchronous memory

            • You latch this into the address of the synchronous character generator

            • You latch the output of the character generator into the output register

            • apply the palette lookup...

            • into the synchronous DAC...

            When you break a task down like this, you only get one combinatorial delay plus some propagation delay and register setup and hold times needing to fit between clocks.



            A design built this way will take many clocks to produce an output - the latency will actually be higher than a purely combinatorial design. But it produces a new correct output on each cycle of a much faster clock.



            And hey, it's video, it doesn't really matter if the CRT is drawing a dozen pixels behind the pixel counter - you of course take that into account in the timing of the sync signals so that they are correct compared to when the data actually comes out of the DAC.



            In practice, almost all complex digital systems work this way, as it's a great idea - right up until a pipelined CPU hits a dependency on an earlier computational result or a conditional branch... Then things get interesting, as they'd talk about in the next lecture of a digital systems class - but fortunately your VGA situation is a lot simpler, especially if you don't yet worry about tearing effects if the character buffer changes while the screen is being drawn.



            As a practical matter if you want to build this, do it in an FPGA. That will pretty much force synchronous memories on you if you use internal ones, or synchronous IO registers if you use external memory. You'll get a lot of nudging towards a proper design, the fabric itself will be faster than your discrete parts, and of course if you make a mistake you only need twiddle your thumbs while it recompiles rather than spend a long day re-wiring.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited 3 hours ago

























            answered 7 hours ago









            Chris StrattonChris Stratton

            22.9k22864




            22.9k22864























                1












                $begingroup$


                Using the fastest components I can find, the propagation delays and access time add up to around 15ns + 20ns + 70ns + 15ns = 120ns, much greater than the 40ns period for 25MHz.




                You forget that a graphics adapter would never only draw a single pixel – but at least a full scan line. Thus, this would be a completely pipelineable problem.



                Also, don't forget that there's been five decades of video producing hardware so far. Your problem would usually be solved with a special type of RAM, into which you render
                your letters on one port, and which is sequentially read out to a video signal DAC.
                That hardware is way, way faster than what you're looking at.




                The basic architecture for my circuit is as follows:



                1. Binary counter for horizontal pixels counts up at 25.175MHz to 800 (640 visible pixels + 160 for front porch, sync, back porch). At 800,
                  increment vertical line counter (and reset at 525 lines)


                2. Using horizontal and vertical position, derive the x,y coordinate of current character.




                Nope, why would you do that? You'd simply put your row pixel into a contiguous area of memory and linearly put it out to your DAC – if this is about a CPU / MCU implementation, you'd not even let your CPU do that, but a DMA unit, programmed to do nothing but take one value after the other and put it out to e.g. a parallel data port, without any CPU core interaction.




                1. Using x,y coordinate of character, index into video memory to retrieve ASCII character.



                Ah, you want to render on the fly – good choice, but unusual at modern costs of RAM.
                Instead, you'd just render the character into a frame buffer beforehand, or if yor device is extremely slim, directly pipe out (see my DMA explanation above) the character row to the DAC.






                share|improve this answer









                $endgroup$

















                  1












                  $begingroup$


                  Using the fastest components I can find, the propagation delays and access time add up to around 15ns + 20ns + 70ns + 15ns = 120ns, much greater than the 40ns period for 25MHz.




                  You forget that a graphics adapter would never only draw a single pixel – but at least a full scan line. Thus, this would be a completely pipelineable problem.



                  Also, don't forget that there's been five decades of video producing hardware so far. Your problem would usually be solved with a special type of RAM, into which you render
                  your letters on one port, and which is sequentially read out to a video signal DAC.
                  That hardware is way, way faster than what you're looking at.




                  The basic architecture for my circuit is as follows:



                  1. Binary counter for horizontal pixels counts up at 25.175MHz to 800 (640 visible pixels + 160 for front porch, sync, back porch). At 800,
                    increment vertical line counter (and reset at 525 lines)


                  2. Using horizontal and vertical position, derive the x,y coordinate of current character.




                  Nope, why would you do that? You'd simply put your row pixel into a contiguous area of memory and linearly put it out to your DAC – if this is about a CPU / MCU implementation, you'd not even let your CPU do that, but a DMA unit, programmed to do nothing but take one value after the other and put it out to e.g. a parallel data port, without any CPU core interaction.




                  1. Using x,y coordinate of character, index into video memory to retrieve ASCII character.



                  Ah, you want to render on the fly – good choice, but unusual at modern costs of RAM.
                  Instead, you'd just render the character into a frame buffer beforehand, or if yor device is extremely slim, directly pipe out (see my DMA explanation above) the character row to the DAC.






                  share|improve this answer









                  $endgroup$















                    1












                    1








                    1





                    $begingroup$


                    Using the fastest components I can find, the propagation delays and access time add up to around 15ns + 20ns + 70ns + 15ns = 120ns, much greater than the 40ns period for 25MHz.




                    You forget that a graphics adapter would never only draw a single pixel – but at least a full scan line. Thus, this would be a completely pipelineable problem.



                    Also, don't forget that there's been five decades of video producing hardware so far. Your problem would usually be solved with a special type of RAM, into which you render
                    your letters on one port, and which is sequentially read out to a video signal DAC.
                    That hardware is way, way faster than what you're looking at.




                    The basic architecture for my circuit is as follows:



                    1. Binary counter for horizontal pixels counts up at 25.175MHz to 800 (640 visible pixels + 160 for front porch, sync, back porch). At 800,
                      increment vertical line counter (and reset at 525 lines)


                    2. Using horizontal and vertical position, derive the x,y coordinate of current character.




                    Nope, why would you do that? You'd simply put your row pixel into a contiguous area of memory and linearly put it out to your DAC – if this is about a CPU / MCU implementation, you'd not even let your CPU do that, but a DMA unit, programmed to do nothing but take one value after the other and put it out to e.g. a parallel data port, without any CPU core interaction.




                    1. Using x,y coordinate of character, index into video memory to retrieve ASCII character.



                    Ah, you want to render on the fly – good choice, but unusual at modern costs of RAM.
                    Instead, you'd just render the character into a frame buffer beforehand, or if yor device is extremely slim, directly pipe out (see my DMA explanation above) the character row to the DAC.






                    share|improve this answer









                    $endgroup$




                    Using the fastest components I can find, the propagation delays and access time add up to around 15ns + 20ns + 70ns + 15ns = 120ns, much greater than the 40ns period for 25MHz.




                    You forget that a graphics adapter would never only draw a single pixel – but at least a full scan line. Thus, this would be a completely pipelineable problem.



                    Also, don't forget that there's been five decades of video producing hardware so far. Your problem would usually be solved with a special type of RAM, into which you render
                    your letters on one port, and which is sequentially read out to a video signal DAC.
                    That hardware is way, way faster than what you're looking at.




                    The basic architecture for my circuit is as follows:



                    1. Binary counter for horizontal pixels counts up at 25.175MHz to 800 (640 visible pixels + 160 for front porch, sync, back porch). At 800,
                      increment vertical line counter (and reset at 525 lines)


                    2. Using horizontal and vertical position, derive the x,y coordinate of current character.




                    Nope, why would you do that? You'd simply put your row pixel into a contiguous area of memory and linearly put it out to your DAC – if this is about a CPU / MCU implementation, you'd not even let your CPU do that, but a DMA unit, programmed to do nothing but take one value after the other and put it out to e.g. a parallel data port, without any CPU core interaction.




                    1. Using x,y coordinate of character, index into video memory to retrieve ASCII character.



                    Ah, you want to render on the fly – good choice, but unusual at modern costs of RAM.
                    Instead, you'd just render the character into a frame buffer beforehand, or if yor device is extremely slim, directly pipe out (see my DMA explanation above) the character row to the DAC.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered 7 hours ago









                    Marcus MüllerMarcus Müller

                    34.7k362101




                    34.7k362101





















                        0












                        $begingroup$

                        So obviously that doesn't work; you need a pipeline.



                        1) Store the characters contiguously in memory. Start at the top left.



                        2) Fetch a character during the blanking interval. Continue to fetch characters in memory order.



                        3) Pipeline each decoded character plus line index into the ROM.



                        4) Pipeline the ROM output into a buffer.



                        5) Pipeline the buffer into a shift register. Read out pixels continuously at 40ns intervals from this.



                        (That implies you need to load a new character into the shift register every 320ns, which might even be doable without pipelining the whole rest of the system.)



                        6) During horizontal blanking, either return to the start of the line or advance to the next character (ie start of next line.)



                        Bonus feature: since you only need a character every 320ns, you could also read a character+colour pair and do either MSDOS-style or Spectrum-Style colour characters.






                        share|improve this answer









                        $endgroup$

















                          0












                          $begingroup$

                          So obviously that doesn't work; you need a pipeline.



                          1) Store the characters contiguously in memory. Start at the top left.



                          2) Fetch a character during the blanking interval. Continue to fetch characters in memory order.



                          3) Pipeline each decoded character plus line index into the ROM.



                          4) Pipeline the ROM output into a buffer.



                          5) Pipeline the buffer into a shift register. Read out pixels continuously at 40ns intervals from this.



                          (That implies you need to load a new character into the shift register every 320ns, which might even be doable without pipelining the whole rest of the system.)



                          6) During horizontal blanking, either return to the start of the line or advance to the next character (ie start of next line.)



                          Bonus feature: since you only need a character every 320ns, you could also read a character+colour pair and do either MSDOS-style or Spectrum-Style colour characters.






                          share|improve this answer









                          $endgroup$















                            0












                            0








                            0





                            $begingroup$

                            So obviously that doesn't work; you need a pipeline.



                            1) Store the characters contiguously in memory. Start at the top left.



                            2) Fetch a character during the blanking interval. Continue to fetch characters in memory order.



                            3) Pipeline each decoded character plus line index into the ROM.



                            4) Pipeline the ROM output into a buffer.



                            5) Pipeline the buffer into a shift register. Read out pixels continuously at 40ns intervals from this.



                            (That implies you need to load a new character into the shift register every 320ns, which might even be doable without pipelining the whole rest of the system.)



                            6) During horizontal blanking, either return to the start of the line or advance to the next character (ie start of next line.)



                            Bonus feature: since you only need a character every 320ns, you could also read a character+colour pair and do either MSDOS-style or Spectrum-Style colour characters.






                            share|improve this answer









                            $endgroup$



                            So obviously that doesn't work; you need a pipeline.



                            1) Store the characters contiguously in memory. Start at the top left.



                            2) Fetch a character during the blanking interval. Continue to fetch characters in memory order.



                            3) Pipeline each decoded character plus line index into the ROM.



                            4) Pipeline the ROM output into a buffer.



                            5) Pipeline the buffer into a shift register. Read out pixels continuously at 40ns intervals from this.



                            (That implies you need to load a new character into the shift register every 320ns, which might even be doable without pipelining the whole rest of the system.)



                            6) During horizontal blanking, either return to the start of the line or advance to the next character (ie start of next line.)



                            Bonus feature: since you only need a character every 320ns, you could also read a character+colour pair and do either MSDOS-style or Spectrum-Style colour characters.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered 7 hours ago









                            pjc50pjc50

                            34.2k34288




                            34.2k34288



























                                draft saved

                                draft discarded
















































                                Thanks for contributing an answer to Electrical Engineering Stack Exchange!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid


                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.

                                Use MathJax to format equations. MathJax reference.


                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function ()
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f426444%2fhow-is-it-possible-to-drive-vga-displays-at-such-high-pixel-clock-frequencies%23new-answer', 'question_page');

                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                Frič See also Navigation menuinternal link

                                Identify plant with long narrow paired leaves and reddish stems Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?What is this plant with long sharp leaves? Is it a weed?What is this 3ft high, stalky plant, with mid sized narrow leaves?What is this young shrub with opposite ovate, crenate leaves and reddish stems?What is this plant with large broad serrated leaves?Identify this upright branching weed with long leaves and reddish stemsPlease help me identify this bulbous plant with long, broad leaves and white flowersWhat is this small annual with narrow gray/green leaves and rust colored daisy-type flowers?What is this chilli plant?Does anyone know what type of chilli plant this is?Help identify this plant

                                fontconfig warning: “/etc/fonts/fonts.conf”, line 100: unknown “element blank” The 2019 Stack Overflow Developer Survey Results Are In“tar: unrecognized option --warning” during 'apt-get install'How to fix Fontconfig errorHow do I figure out which font file is chosen for a system generic font alias?Why are some apt-get-installed fonts being ignored by fc-list, xfontsel, etc?Reload settings in /etc/fonts/conf.dTaking 30 seconds longer to boot after upgrade from jessie to stretchHow to match multiple font names with a single <match> element?Adding a custom font to fontconfigRemoving fonts from fontconfig <match> resultsBroken fonts after upgrading Firefox ESR to latest Firefox