<mithro>
Ideally with a tool which generates some coupled nice diagrams like they have in that doc?
lkcl has quit [Ping timeout: 264 seconds]
lkcl has joined #nmigen
<EmilJ>
Hi mithro, how would you go about generating useful diagrams from nmigen primitives/classes?
<mithro>
EmilJ: Not quite sure, maybe something with netlistsvg -- or maybe the same code which is used to generate nmigen primitives could be used to generate dot-diagram primitives?
<EmilJ>
I think in order for emitted diagrams to be useful, they must be selectively hierarchical - yosys to dot AFAIK emits strictly hierarchical dots, so each module is blackboxed. Netlistsvg seems to be strictly flat structured, but probably could be modified
<EmilJ>
So it needs to be coupled with some system where the user can select which class gets black-boxed and which is "exploded"
<mithro>
EmilJ: I'm an ideas man, not a solutions man ;-) - I was thinking more like the "Figure 2. 64-bit ripple-block carry look-ahead adder" diagram
<EmilJ>
Well, documenting what primitives do internally seems to be best fit with manually made diagrams
<mithro>
And maybe "Figure 11. carry-skip block." type level
<EmilJ>
I think that automatically generated docs make sense for frequently updated, bigger wholes such as an entire digital system
<mithro>
EmilJ: I would like to write something which uses the logical hierarchy and auto-generation together
<EmilJ>
The carry-skip block is nice, that's the sort of practical "exploded" view
<mithro>
Once you get to more than like >4 bits, you are going to need to abstract stuff into blocks
<mithro>
You probably want to make sure there are Half-Adder, Full-Adder and Ripple-Carry-Adder blocks too
<mithro>
See - "Figure 12. 8-bit Fixed-block-size carry-skip adder."
<vup>
I think interactive diagrams could be really useful, kinda like vivado's diagram view works, where you can open a blackbox and get the internals or close it and just get a box
<lkcl>
EmilJ: what i found with large nmigen designs is that many developers forget the difference between a "python object that happens to contain HDL AST tree-fragments" and "a nmigen AST signal"
<lkcl>
consequently there is this - which looks perfectly reasonable:
<lkcl>
x = Mux(somebool, someval, someotherval)
<mithro>
It's probably one of the things that *feels* like it should be easy to do programmatically, but you end up writing a new language :-)
<lkcl>
y = SomethingElse(x, y1, z1)
<lkcl>
and then that's put into a for-loop...
<lkcl>
the end result, if you try to look at it with *any* graph tool, is a hooorrrible repeat of the exact same HDL fragments :)
<lkcl>
Array-of-Array-of-expressions is the worse offender seen so far
<mithro>
lkcl: I think it would be interesting if that for-loop could be seen by the diagram / verilog in some way -- Yosys has generate statements right?
<lkcl>
mithro: that's interesting, i didn't know that it had. i don't believe nmigen is designed to use them
<mithro>
lkcl: I've often wondered if nmigen could automatically work out the name of that signal as 't[i]' type thing?
<lkcl>
mithro: that's one for whitequark, definitely
<lkcl>
EmilJ: some people, when i have raised this issue, have claimed that yosys *should* be capable of performing the identification of common expressions
<lkcl>
however:
<lkcl>
1) on complex designs particularly involving hierarchical modules it fails spectacularly
<mithro>
lkcl: That repository needs a license file
<lkcl>
2) it doesn't help you with graphviz "show"
<lkcl>
mithro: ah true. thank you
<mithro>
lkcl: I noticed in setup it is GPLv3+ which makes it immediately less interesting to me
<lkcl>
ah - no that's wrong. it's LGPLv3+
<lkcl>
classifiers=[
<lkcl>
"Topic :: Software Development :: Libraries",
<lkcl>
"License :: OSI Approved :: LGPLv3+",
<lkcl>
mithro: sorted, thank you for raising that
<mithro>
I'm like "share and share alike" licenses -- but GPL's interactions with ASICification give a lot of lawyers I trust heartburn
<mithro>
lkcl: Any reason you don't run self hosted gitlab or something?
<mithro>
lkcl: I've had long arguments with Bruce about permission and "share and share alike"
<lkcl>
ah lol. did you discuss Design Rights?
<mithro>
lkcl: My general argument is that permission can always be converted to "share and share alike"
<mithro>
s/permission/permissive/
<lkcl>
libresoc is a Libre project as opposed to an "Open" Project.
<mithro>
IE A libre project can always "steal" from an open project.
<lkcl>
github fails the FSF's hosting guidelines, and we actually a Board Member of the FSF as one of the contributors
<mithro>
So for example, GCC shouldn't be worried about LLVM. Ultimately if LLVM gets better than GCC, GCC could just become LLVM + GPL plugins...
<mithro>
lkcl: I said "self hosted gitlab" not "github" :-)
<lkcl>
ah right. yes, we reviewed it: the memory and resource requirements are completely insane. we're hosted off a 1GB RAM 12GB SSD VM.
<lkcl>
at *idle*, gitlab consumed half the ram, 60% of the CPU, and half the disk space
<lkcl>
as i'm paying (personally) for the VM, i put my foot down :)
<lkcl>
mithro: the pipeline API in nmutil is based on chisel3's io lib btw
<lkcl>
at one point it was... and sort-of still is... possible to chunk fragments defined according to what we call the "Stage API" into FSMs rather than pipelines
<lkcl>
... *without* significant overhaul of the actual algorithms
<mithro>
A dedicated server in the "Quad Core + 48GB RAM + 500GB SSD" range is like ~= $30-$40 EUR a month
<lkcl>
mithro: i'm paying $8 a month for a mythic-beasts VM.
<lkcl>
it's a matter of being responsible and frugal with the NLnet grant money, making it go further.
<mithro>
lkcl: Anyway, with nmutil was any permissive license then I could probably dig around in it and I wouldn't have to reinvent it -- could potentially even fund some work related to it. Ideally it would be licensed the same as nmigen so that if it became useful enough it would just become part of nmigen itself.
<lkcl>
mithro: this comes to the crux of the matter. we're setting up a Foundation where requests of that nature are more than welcome
<mithro>
Setting up a foundation is a great way to end up in meetings and not getting anything done :-)
<lkcl>
lol not this one. it's a derivative of the Commons Conservancy.
<lkcl>
do join #libre-soc, let's keep this one to nmigen? :)
<lkcl>
and yes, things like the Priority Picker, whitequark has asked for us to submit it to nmigen
<lkcl>
the PriorityPicker is based off of the CDC 6600, by Seymour Cray and James Thornton.
<lkcl>
conceptually similar to an Encoder-then-Decoder back-to-back, if you actually do that, nmigen/yosys creates a pmux which is horribly inefficient.
<lkcl>
whereas a 16-in 16-out PriorityPicker creates a suite with only 3 gates of latency
<mithro>
lkcl: Choosing a license compatible with your upstream is generally a good idea, changing licenses of things after the fact is a huge logistical and legal nightmare
<lkcl>
someone doing an FPGA design, here, found some fascinating early FPGA reverse-engineering designs
<lkcl>
where the LUTs (etc.) were basically programmed by a shift register
<lkcl>
as in: the shift register was literally connected directly to the routing between LUTs, in a grid fashion
<d1b2>
<dub_dub_11> isn't a shift register approximately what a scan chain is
<mithro>
Anyone have papers or references about doing computation on non-2 complement encoded numbers? Very interested in computation on numbers encoded with error correction in them.
<d1b2>
<geo> you may well already have read about them if you are interested in that area but john gustafson's unum work is pretty interesting (although i cant claim to understand very much of it). In particular the type 3 unums (posits and valids) might be of interest which are meant to be more hardware friendly. iirc valids use interval arithmetic to encode error. http://www.johngustafson.net/pdfs/BeatingFloatingPoint.pdf this is the paper for posits/valids.
<d1b2>
<geo> i think hes written more about posits than valids at the moment
pepijndevos has quit [Ping timeout: 240 seconds]
pepijndevos has joined #nmigen
emeb has joined #nmigen
m4ssi has quit [Remote host closed the connection]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<EmilJ>
about yosys, it got stuck using one CPU core when run on a single verilog file with many modules. Killed it after an hour or so
<EmilJ>
(generating the netlistsvg thing, I mean)
rattboi has quit [Ping timeout: 256 seconds]
emeb_mac has joined #nmigen
<whitequark>
mithro: re __set_name__ for locals: first of all, we could only use that in nmigen in 5 years. second, it will be rejected by upstream anyway. so no.