<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">The pixel clock is 75 MHz and the cpu
      clock is 25 MHz.  One video fetch brings in 32 pixels and lasts
      about 10 cpu clocks (32/3).  So during the display scan line about
      10% of the cpu clocks are lost.<br>
      <br>
      If the FPGA has enough internal BRAM to hold the display surface
      (~ 100 kB) then that memory area can be designed to have two-port
      access, i.e. the video can access that area independent of the
      cpu.<br>
      The penalty is added code complexity (but not much).  FWIW, this
      option is possible on Pipistrello since it has enough free BRAMs
      to do this.<br>
      <br>
      Magnus<br>
      <br>
      <br>
      On 5/18/2015 11:35 AM, Davide Della Casa wrote:<br>
    </div>
    <blockquote
cite="mid:CALNNn2P7YHbVGLekKRj6RiE+gPiFKGJPs5EQGfoDDRejpQJ9+Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Hi,</div>
        <div><br>
        </div>
        I'm reading on how Oberon of FPGA manages video generation - the
        chosen way is to have SRAM in common between CPU and video
        system.
        <div><br>
        </div>
        <div>So (reading the docs) the "stallx" line is used to
          arbitrate: "The signal (wire) dspreq stalls the processor
          (stallX) and decides whether the
          memory address (SRAdr) should be taken from the processor
          (adr) or the display controller
          (vidadr)".</div>
        <div><br>
        </div>
        <div>Now I'm wondering what percentage of time does the CPU
          stall because of this? Is the CPU only effectively free to
          work during the "invisible lines" and "beam reset" times? Or
          is there significant time available while "racing the beam"?</div>
        <div><br>
        </div>
        <div>Also I'm curious to know whether alternate solutions could
          potentially be in the cards to avoid the contention</div>
        <div><br>
        </div>
        <div>a) dual port SRAM (too expensive / too many pins needed?)</div>
        <div>
          <div>b) SRAM used in two "blocks" - one dedicated to screen
            and other so contention is reduced (too many pins needed?) -
            potentially with a way for the CPU to know if the "video"
            block is available.</div>
        </div>
        <div>c) ...?</div>
        <div><br>
        </div>
        <div>(I'd think that such considerations could be worthy of
          inclusion in the docs by the way)</div>
        <div><br>
        </div>
        <div>Any links welcome about other typical arrangements of
          interest that are found in fpga projects "in the wild" in
          respect to video management...</div>
        <div><br>
        </div>
        <div>Cheers,</div>
        <div>Davide Della Casa</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">--
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>