<br><br>On Friday, May 7, 2021, Paul Mackerras &lt;<a href="mailto:paulus@ozlabs.org">paulus@ozlabs.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, May 07, 2021 at 12:27:38AM +0100, Luke Kenneth Casson Leighton wrote:<br><br>
&gt; the question i have is: is control_writeback making its decisions from the<br>
&gt; *current* r1 or is it making its decisions from the *future* r1?<br>
<br>
That block is combinatorial, since it&#39;s process(all) and has no if<br>
rising_edge(clk) then ... statement.  So it&#39;s the current r1.</blockquote><div><br></div><div>ok whew.  so i am reading VHDL correctly.  same thing repeated below in different ways, reinforcing the understanding.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you mean you&#39;re seeing valid data two cycles after presenting the<br>
address, that&#39;s how it&#39;s meant to work. </blockquote><div><br></div><div>i believe it possible to remove one of those on real mode LDs.</div><div><br></div><div>now, it may be useful to introduce a pipeline stage elsewhere, it just seems anomalous design.</div><div><br></div><div>i think what i am saying is that cache_ram.vhdl having the ADD_BUF delay inside *cache_ram.vhfl itself* is completely unclear.</div><div><br></div><div>i would expect that rd_data0 to be in *dcache.vhdl*, placed into a data structure that is explicitly marked and documented, &quot;this is part of a read pipeline&quot;</div><div><br></div><div>whereas right now there&#39;s one pipeline path in dcache.vhdl for control signals... oh and a totally separate pipeline which happens to be the exact same length except it&#39;s in cache_ram.vhdl involving rd_data and rd_data0.</div><div><br></div><div>this does not seem sensible from a code maintenance and clarity perspective.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The constraint is really the<br>
TLB and cache tag matching and consequent hit/miss detection and cache<br>
way determination, which takes up essentially the whole of cycle 1.</blockquote><div><br></div><div>ah additional context (sorry) i am tacking the phys path at the moment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Of course, you can always cram more into a cycle if you&#39;re willing to<br>
increase the cycle time, but in fact I want to take Microwatt in the<br>
other direction, towards more pipelining and shorter cycle times,<br>
given that registers are close to free on FPGAs.<br>
<br></blockquote><div><br></div><div>understood.</div><div><br></div><div>l.</div><div><br></div><br><br>-- <br>---<br>crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" target="_blank">https://www.crowdsupply.com/eoma68</a><br><br>