<div dir="ltr"><div>Hi,</div><div><br></div>I&#39;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 &quot;stallx&quot; line is used to arbitrate: &quot;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)&quot;.</div><div><br></div><div>Now I&#39;m wondering what percentage of time does the CPU stall because of this? Is the CPU only effectively free to work during the &quot;invisible lines&quot; and &quot;beam reset&quot; times? Or is there significant time available while &quot;racing the beam&quot;?</div><div><br></div><div>Also I&#39;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 &quot;blocks&quot; - 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 &quot;video&quot; block is available.</div></div><div>c) ...?</div><div><br></div><div>(I&#39;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 &quot;in the wild&quot; in respect to video management...</div><div><br></div><div>Cheers,</div><div>Davide Della Casa</div></div>