[Libre-soc-bugs] [Bug 469] Create D-cache from microwatt dcache.vhdl

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=469

--- Comment #26 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #25)
> (In reply to Cole Poirier from comment #24)
> 
> > > if you look at the original dcache.vhdl you will see that index and addrbits
> > > were "variables", not signals.  this is a sign that needs to be looked out
> > > for.
> > 
> > Hmmm. Very interesting! This is probably going to be the most difficult one
> > for me to do properly. This was within an "if rising_edge(clk) then"
> > statement correct? 
> 
> yes.  it's.. tricky.

Indeed :O

> > Is it the case that only signals are used with sync and
> > variables are used with comb within a sync block?
> 
> kinda although it's just not that straightfoward unfortunately.
> "variables" do not
> exist in nmigen as a concept: there are only Signals.  plus, the "sync"
> domain acts differently from "if rising edge" in VHDL, although they
> are similar.
> 
> basically everything in that "rising edge" block has to happen actually
> at that "tick".
> 
> where in nmigen, the concept of a separate hidden "next state" is created
> by sync and it is UTTERLY SEPARATE AND INACCESSIBLE to the current "tick"
> because it is, quite literally, to become the "future" state.
> 
> i explain this more in comment #16.

That's very interesting and more than a little brain straining. I reviewed the
diff of that commit using gitk (very cool tool by the way), it was very
instructive, though given I still only partially understand the subtle
differences between vhdl 'if rising_edge(clk) then' and nmigen 'sync' domains,
I expect it's likely that you may have to correct me on this again :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.