<attie>
lkcl: nice! that seems like a good candidate if you ever want to try out the formal verification stuff too.
early` has quit [Quit: Leaving]
early has joined #m-labs
cr1901_modern has quit [Ping timeout: 244 seconds]
cedric has quit [Ping timeout: 250 seconds]
bluebugs has joined #m-labs
bluebugs has quit [Changing host]
bluebugs has joined #m-labs
proteusguy has joined #m-labs
proteusguy has quit [Ping timeout: 245 seconds]
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 268 seconds]
cr1901_modern has joined #m-labs
_whitelogger has joined #m-labs
m4ssi has joined #m-labs
early has quit [Quit: Leaving]
early has joined #m-labs
<lkcl>
attie: oo, what formal verification stuff?
<lkcl>
attie: answer, yes, definitely
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<attie>
lkcl: yosys has a verification thing. I only looked at it briefly, but whitequark has been using it quite a bit and I think I saw that she added some Assume and Assert statements to https://github.com/m-labs/nmigen/blob/master/nmigen/lib/fifo.py
<attie>
so there seems to be some amount of support for it in nmigen now
<attie>
it's on my list of things I want to learn but keep putting off in favor of other things (like finishing my thesis >.<")
<lkcl>
whitequark: i'm finding that a group-object (similar to Record except arbitrary and having an eq function) would be extremely beneficial
<lkcl>
attie: okaay, cool. we discussed formal verification a few weeks ago, so thank you
<lkcl>
ngggh, import * getting in the way agaaaaain. the top imports of a module are what tell you where functions and classes are imported from
<lkcl>
if that's "*" people have *no idea* which module to go to, and have to grep potentially *multiple* source code bases to find them
<lkcl>
attie: it is... and i had to do "grep -r" to find it
<attie>
uh, but it says "from ..formal" right there
<attie>
so you go two levels up... and there's formal.py
<lkcl>
attie: and how would i know that it was *nmigen* that it comes from?
<attie>
because it has only nmigen imports?
<attie>
. is the local module
<lkcl>
in this is example, yes... yet even there, it's mixing ".. import *" with ".. formal import *"
<lkcl>
from ..tools import log2_int is *great*. i now know that tools has a function called "log2_int"
<attie>
I mean, "from x" tells you to look in the package x
<attie>
if x starts with ., it's local
<attie>
otherwise you look for the module x
<attie>
and look in its __init__.py what it gives you
<lkcl>
if there was only the one "import *" it would be "fine" (it's not), the fact that there's 2 means you have to search *two* modules - manually
<attie>
I find * import really useful for DSL stuff
<attie>
I don't want to specify every syntax element of my DSL in an import statement before being able to code in it!
<lkcl>
attie: really, don't do it. it's one of the well-known things about python that causes an awful lot of trouble.
<attie>
can you imagine? from migen import Module, Signal, Value, If, Case, ...
<lkcl>
attie: there's a script around that can do that
<attie>
but that's what * is _for_
<lkcl>
attie: yes, that's exactly what we do.
<lkcl>
from nmigen import Module, Signal, Cat, Value, Record
<attie>
that sounds like hell on earth, but I guess you're welcome to live there if you like the temperature :)
<lkcl>
attie: if you've not worked with massive python codebases before, you'll not have experienced quite how much hell "import *" really is.
<lkcl>
also, it causes the python interpreter to do vast amounts of unnecessary work.
<attie>
it depends what you use it for
<attie>
like, I don't usually do things like "from math import *"
<lkcl>
there *are* circumstances under which "import *" is appropriate.
<lkcl>
attie: there you go... so why do you avoid "from math import *"?
<attie>
because I don't want all of math, I only need one or two functions of the lot
<attie>
but for migen, I never want only half the language
<lkcl>
"import *" is appropriate if you are changing an API or a layout.
<lkcl>
sounds maybe like you have very large modules.
<attie>
modules as in migen Module?
<attie>
yeah I guess
<lkcl>
we're subdividing the SoC code down into extremely small self-contained modules
<lkcl>
python modules, i mean
<lkcl>
each one small enough to only need a few things.
<attie>
I don't make python modules out of my migen modules, no
<lkcl>
mind you, there's a big difference between migen and nmigen, nmigen has "m.If" and "m.Switch" etc. which helps keep the namespace a lot cleaner.
<lkcl>
attie: yehh i am doing very small nmigen modules so as to be able to do visual inspection.
<lkcl>
(of the graphviz)
<attie>
that sounds...like a very bad idea?
<lkcl>
:)
<lkcl>
plus a hell of a lot of unit tests :)
<attie>
I mean, small modules are good
<lkcl>
attie: 1 sec...
<attie>
but looking at the graphviz is not a good way to tell... much of anything
<lkcl>
on large modules, you're right, it's not
<attie>
do you also look at the callgraph of your C programs to tell if you wrote them right?
<attie>
sometimes looking for a specific element can help in catching where you're going wrong, but if you do it in a targeted manner then the amount of code around it doesn't matter
<lkcl>
yeh, i'm certainly not relying on the graphviz only: i'm using gtkwave, the python code, *and* the graphviz all side-by-side
<lkcl>
on a 3000x1800 resolution LCD :)
<attie>
(I glance at specific wires in my ten thousand line export verilog frequently to check for specific errors, and that works. But module size doesn't affect that.)
<lkcl>
the graphviz has helped me to identify where i've failed to connect certain wires to a module, many many times
<attie>
but you can't grep it
<lkcl>
attie: graphviz side-by-side with the python code :)
<lkcl>
in the development of the pipeline, i found that i regularly lost track of the inputs and outputs
<lkcl>
forgot to assign an input that needed to be passed through to another stage
<lkcl>
could i track that down in the python code?
<lkcl>
not a snowball in hell's chance
<lkcl>
... looked at the graphviz... oh look! that register ends there, when it shouldn't! let's have a look at the corresponding python nmigen module...
<lkcl>
ah yes, there it is! that's where i forgot to make an eq statement...
attie has quit [Ping timeout: 246 seconds]
attie has joined #m-labs
<lkcl>
but... butbutbut... it's only been possible / convenient because of the strict splitting down into small, manageable nmigen modules
<lkcl>
i couldn't do it otherwise: the graphviz would be absolute hell.
<attie>
oops my connection kicked the bucket there for a bit
<lkcl>
it's the actual "add" phase
<lkcl>
whoops :)
* attie
checks logs
<lkcl>
oo, where's the logs for this channel?
<lkcl>
ah in the title... :)
<attie>
link in the topic~
<attie>
yep that
<lkcl>
:)
<lkcl>
cool, it's real-time too
<attie>
[29/03 17:55:12] < attie> | well, I guess if it works for you
<attie>
[29/03 17:55:32] < attie> | I could use a motivation to break things up more sometimes
<attie>
those were lost I think
<lkcl>
the IEEE754 pipeline code i'm developing is so insanely complex i'd be hopelessly lost without the combination of graphviz, gtkwave side-by-side with the python code
<attie>
anyway I don't really have any problem tracking down forgotten .eq()s
<attie>
same as forgotten .submodule
<lkcl>
lol
<attie>
it's quite obvious in gtkwave
<attie>
"why is this signal not changing??" Ctrl-F "ooh I never assigned it"
<lkcl>
i'm new to nmigen, and i used to do gate-level designs
<lkcl>
yehhh that quickly goes to hell in a handbasket for a multi-stage pipeline
<attie>
why?
<attie>
my pipelines are multi-stage too
<attie>
each stage has its own signals
<attie>
generally I start looking at the output that is not what I want, and then work my way up the assigns
<lkcl>
oo, do you have some examples online somewhere?
<attie>
gatherkernel and applykernel used to be one bigger pipeline but I broke it in two later
<lkcl>
yehyeh. so yes, when the inputs and outputs are in the same location (like in the fmul.py example) yes it's pretty straightforward and obvious if you missed one
<lkcl>
once things get abstracted out however, with each stage in its own class...
<attie>
hmm, maybe... I keep thinking of how to make pipelines with backpressure a better thing, but not really hit a good way yet
<lkcl>
that's the style that i followed, and to be honest i'm not really at all happy about it
<lkcl>
except that you can't arbitrarily add a new "thing" to a Record
<lkcl>
ah yeah that would be a good choice
<attie>
that's not my #1 feature, I'm ok defining the layout
<lkcl>
if you could do Record.somenewthing = Signal(5) *after* defining the layout
<attie>
just I want the din/dout or dat_r/dat_w to automatically have the fields
<attie>
not have to fiddle with .raw_bits() all the time
<lkcl>
yehh i'm looking at more advanced use of introspection to hide the manual bits of a pipeline where you need to copy registers from stage to stage
<lkcl>
except instead of doing that with individual signals, it can be done on an entire group
<attie>
and I feel like my code gets worse from using DIR_M_TO_S/DIR_S_TO_M
<attie>
when actually what I have is a payload (multiple signals, all one direction) + stb/ack
<lkcl>
yehh the Record Layout direction stuff i can see was really intended for buses
<lkcl>
for GPIO
<attie>
yeah that's what it's made for, and what I use it for is a bad hack
<lkcl>
like an SPI bus, or SD/MMC, or SDRAM.
hartytp has joined #m-labs
<lkcl>
because there isn't anything else that does what's really needed
<attie>
I've tried a few times to write my own class but never liked the result
<attie>
(and frankly I don't want to rewrite all my code)
<attie>
(I'm going to throw it all away in 3 months anyway)
<attie>
(I hope)
<lkcl>
well, i need a break, can we discuss another time, perhaps when whitequark's also around, as it's something we seriously need.
<lkcl>
:)
<attie>
alright, good talk. see you around!
<lkcl>
you too
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has quit [Ping timeout: 246 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 272 seconds]
bluebugs is now known as cedric
rohitksingh has joined #m-labs
hartytp has quit [Quit: Page closed]
m4ssi has quit [Remote host closed the connection]
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 245 seconds]
X-Scale` is now known as X-Scale
rohitksingh has quit [Ping timeout: 245 seconds]
_whitelogger has joined #m-labs
plonk has joined #m-labs
plonk_ has quit [Read error: Connection reset by peer]
plonk has quit [Ping timeout: 250 seconds]
mumptai has joined #m-labs
plonk has joined #m-labs
zoobab has quit [Remote host closed the connection]
mumptai has quit [Quit: Verlassend]
plonk has quit [Ping timeout: 246 seconds]
plonk has joined #m-labs
plonk has quit [Read error: Connection reset by peer]