mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 272 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
<sb0>
rjo: I don't understand it
<sb0>
"The state memory holds all Y1 values (IIR processor outputs) for all profiles of all channels in the lower half (1 << W.profile + W.channel addresses) and the pairs of old and new ADC input values X1, and X0, in the upper half (1 << W.channel addresses)."???
<sb0>
rjo: and that does not answer the question about COEFF_DEPTH
<sb0>
why does it seem to be the middle bit and not the lowest one?
<cr1901_modern>
sb0: (This came up in #timvideos) The difference between ClockSignal("my_cd") and self.clock_domains.cd_my_cd.clk is that the former works everywhere, and the latter only works in the module where you declared the clock domain, correct?
<sb0>
this thing is so complicated and without any unit test, how are we supposed to maintain it?
<lkcl>
oo, scary. python without unit test equals baaad :)
<lkcl>
i'm still in the middle of learning and evaluating migen at the moment
<lkcl>
for the libre-riscv soc (800mhz+ quad-core smp rv64gv-sv riscv)
<lkcl>
and clock domains will definitely be something we'll need
<lkcl>
stability and confidence in migen will be absolutely essential
<cr1901_modern>
I've been using Migen for 3.5 years, and clock domain errors still throw me off sometimes b/c the rules are a bit messy
<lkcl>
so, if the team decides to go ahead with migen, we'll help out ok?
<lkcl>
cr1901_modern: that helps to know about.
<lkcl>
you may be interested to know that in bluespec, clock domain synchronisation is an absolute damn nuisance :)
<lkcl>
the rules are so strict it's almost impossible to get them right
<whitequark>
migen is definitely on the fuzzier side, in kind of its host language, python
<whitequark>
e.g. the width extension rules
<whitequark>
i would have personally preferred it to be more strictly typed, but it's such a significant improvement over trying to write verilog that it's not nearly enough to dissuade me from using migen
<cr1901_modern>
The "automatic renaming of clock domains in submodules" feels like a misfeature sometimes, tbh. You can write self.sync.my_undeclared_cd += [] just fine.
<lkcl>
oh, from the operators, carrying the bitwidth through the python objects?
<sb0>
oh fuck this. i'll just move the overflowing address bits into data and consider it an opaque value.
<cr1901_modern>
Having a bad day?
<whitequark>
lkcl: I would have preferred if truncating or extending a value had a speed bump in it, but I also recognize that this would make some generic code significantly less readable
<whitequark>
and to some extent, more fragile
<mithro>
sb0: So, if I do a "mem.get_port(...., clock_domain="blah")" I get the following error when trying to generate gateware;
<mithro>
sb0: It seems to work if I just do a "port.clock = self.cd_blah.clk" but then simulation breaks with a "AttributeError: 'Signal' object has no attribute 'cd'"
<whitequark>
mithro: you need to do `self.specials += port`
<whitequark>
I hit this just today
<mithro>
Welp, yosys is optimizing my design down to 2 LCs.. something is obviously wrong...
<whitequark>
forgot self.submodules += ?
<mithro>
whitequark: Possibly - but everything seems to be in the output verilog file that I can see -- I think it's constant propagation
<mithro>
whitequark: Seems it was putting the self.clockdomain values in the top level
<cr1901_modern>
?
<mithro>
Now it looks like Yosys isn't inferring blockram for my buffer...
<cr1901_modern>
what does "putting the self.clockdomain values in the top level" mean?
<cr1901_modern>
if you create a clock domain inside a submodule with the same name as a clock domain as a parent module, Migen will treat them as two separate clock domaisn
<lkcl>
yes. so... that would be a runtime assertion
<sb0>
lkcl: what is enforcing the signal bitwidth?
<whitequark>
sb0: forbidding implicit truncation of signals
<lkcl>
sb0: the operators increase the bitwidth based on the input parameters
<whitequark>
well, implicit truncation is primaraily a footgun
<lkcl>
or decrease
<whitequark>
implicit expansion is more defensible
<whitequark>
though still can be a footgun
<lkcl>
whitequark: ok.
<sb0>
arithmetic modulo some power of 2 is pretty common in FPGAs
<lkcl>
i'm implementing rv32 in migen, and there are some very specific arithmetic rules that need to be obeyed.
<whitequark>
sb0: extensively using implicit truncation results in code that is hard to understand if you did not write it
<whitequark>
and even if you did
<sb0>
aren't rv32 operations mod 2**32?
<sb0>
(most of the time)
<whitequark>
because you do not necessarily have visibility into the signals used in any specific expression
<whitequark>
they may come from another module, or you might be generic over this signal
<whitequark>
i have hit bugs caused by implicit expansion a lot of times
<whitequark>
last one was... a few hours ago. wasted like a hour on that one.
<lkcl>
sb0: from what i can gather, yes. so, it would be really helpful to not have implicit expansion/truncation.
<whitequark>
sure, experienced migen developers may condition themselves to code defensively against this, but that doesn't make it a good design choice
<sb0>
lkcl: then if your target signal is 32-bit, what does not work?
<lkcl>
sb0: i haven't got to running unit tests yet, i'm still doing a conversion from verilog
<lkcl>
i ran into the same "<<<" operator issue that whitequark ran into a couple days ago.