<mithro>
Next step is to take those unisim models and make them run in iverilog or verilator
<esden>
Awesome thank you agg and ktemkin :)
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
rattboi has joined #nmigen
jeanthom has joined #nmigen
chipmuenk has joined #nmigen
hitomi2500 has joined #nmigen
Asu has joined #nmigen
hitomi2501 has joined #nmigen
hitomi2500 has quit [Read error: Connection reset by peer]
hitomi2502 has joined #nmigen
hitomi2501 has quit [Read error: Connection reset by peer]
hitomi2503 has joined #nmigen
hitomi2502 has quit [Read error: Connection reset by peer]
hitomi2503 has quit [Read error: Connection reset by peer]
hitomi2503 has joined #nmigen
jock_tanner has joined #nmigen
<lkcl__>
FL4SHK: to cope with that i created something called RecordObject which helps enumerate the fields of the Record and yields them.
<whitequark>
in 0.3 records will work like that natively
<whitequark>
the design where Record was a subclass of Value was a mistake in first place
<whitequark>
I think I decided on that before I went with having Value.cast()
<whitequark>
so it's a case of XY problem in nMigen's design, more or less
<lkcl__>
whitequark: ah great. that's good to hear because we had to add that capability to everything. {anyclass}.ports() is a first class function, present in every module (several hundred)
<whitequark>
that's a different story though
<lkcl__>
if we were not writing unit tests for every single module, we would not need to output ilang files and run simulations on every module, therefore a ports function on every module would be completely unnecessary
<lkcl__>
each ports function of a parent class uses the ports function of its members to accumulate a massive hierarchical collection of ports.
<lkcl__>
it's quite tedious however has become "routine".
<whitequark>
how are you doing simulations with ilang files?
jock_tanner has quit [Remote host closed the connection]
jock_tanner has joined #nmigen
<lkcl__>
whitequark: the ilang files are simply output for inspection purposes. the reason for having them at every level is because the top level ilang is 6 megabytes, and that's for a "simple" core.
<lkcl__>
so we do visual inspection on much smaller graphs
jeanthom has quit [Ping timeout: 260 seconds]
<whitequark>
right
<whitequark>
so there's a longer term plan to use python type declarations to specify ports
<whitequark>
the problem is genericism
hitomi2503 has quit [Quit: Nettalk6 - www.ntalk.de]
jordi_ has quit [Ping timeout: 256 seconds]
jordi_ has joined #nmigen
jock_tanner has quit [Ping timeout: 245 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Read error: Connection reset by peer]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
<esden>
I have another minor example question. Is there some description of how to use get_tristate and handle bidirectional pins?
<vup>
esden: If you have a platform definition with a Resource defined as "oe", you can just `pin = platform.request("...")` it and you get back something with a `pin.o` and a `pin.oe`
<vup>
now for bidirectional pins its the same, just with the direction defined as "io" and in addition to `pin.o` and `pin.oe` you get a `pin.i`
<esden>
So get_tristate is only used internally then?
<vup>
I think so, but not sure
<esden>
vup: no worries, this is pretty helpful as is :)
chipmuenk has quit [Quit: chipmuenk]
Asu has quit [Ping timeout: 246 seconds]
Asuu has joined #nmigen
<whitequark>
esden: yeah, only used internally
d1b2 has joined #nmigen
<d1b2>
<286Tech> Apparently get_tristate is indeed for internal use.
<d1b2>
<esden> yes, that is what @whitequark just told us in IRC 😄 I was just too slow. 😄
<esden>
o/ from IRC :D
<whitequark>
I find it interesting how much trouble people have with tristates
<whitequark>
I should take that into account for the docs
<d1b2>
<edbordin> o/ from discord :D
<d1b2>
<286Tech> It's linked to IRC? Cool!
<d1b2>
<286Tech> Hi peeps \o
<d1b2>
<gimbas> hi, i come from the future
<d1b2>
<Kate Temkin> @esden what happened to the original bot? where it showed each IRC message as though it was from a Discord user?
<d1b2>
<Kate Temkin> now I have to look at weirdly-prefixed messages on either side >.>
<d1b2>
<esden> @Kate Temkin I did not set up the webhook yet
<d1b2>
<Kate Temkin> oh; that's what it does without the webhook
<d1b2>
<Kate Temkin> gotcha
<d1b2>
<Kate Temkin> (my offer to host your bot with the usb-tools one stands)
<FL4SHK>
whitequark: I don't think I got an answer for this, but are there any plans/already implemented stuff for records being instantiated within a layout?
<whitequark>
instantiated?
d1b2 has quit [Remote host closed the connection]
<FL4SHK>
uh, maybe I'm confused
d1b2 has joined #nmigen
<FL4SHK>
I don't *quite* know the terminology yet
<esden>
(test <- ignore)
<d1b2>
<esden> @Kate Temkin ok I think it is sorted out now. (I only did it once so far and forgot about the webhook thing, now it is done, and thank you for the offer 🙂 )
<whitequark>
FL4SHK: what do you want to do?
<FL4SHK>
make one of the members of a Layout be a Record
<whitequark>
no, that's how are you trying to do it. i'm asking what result do you want to achieve?
<FL4SHK>
Instead it seems I must have separate Layouts and Records
Asuu has quit [Remote host closed the connection]
<FL4SHK>
Not having to always have separate Layouts and Records
<d1b2>
<esden> @286Tech I think the correct way to do this, is to have a tristate pin in the platform. (marked as io) Requesting that said pin, and hooking up the correct o, oe, i pins. Just like vup described. 🙂 This means you would add a new resource with add_resource that is connected to one of the pmod connectors. And in the resource you define that the pins are io. Then you can request them afterwards and get the tristate controls.
<whitequark>
FL4SHK: why is that a problem for you?
<FL4SHK>
because sometimes it's more work
<whitequark>
can you show some concrete examples?
<whitequark>
286Tech: what esden says is correct
<FL4SHK>
a concrete example?
<whitequark>
the idea is that you define the directions in the platform file almost all of the time (sometimes you can't know)
<FL4SHK>
Well, I'd like to skip Layouts for most cases
<FL4SHK>
Here's something that comes to mind that might block that
<whitequark>
the purpose of a Record is to let you use the entire thing as a concatenation of signals
<whitequark>
it's basically a packed struct
<FL4SHK>
I see
<whitequark>
if you don't need a packed struct, you don't need a record
<FL4SHK>
that's interesting
<whitequark>
people tend to misuse them heavily for reasons i don't yet entirely understand
<FL4SHK>
familiarity with other languages
<FL4SHK>
I do believe I actually need a record in this case
<FL4SHK>
I've got a FIFO I want to store VgaColors in
<whitequark>
right, hmm
<d1b2>
<286Tech> @esden Can I not iterate with an index over the subsignals of a resource? I'm not a python expert, so maybe I'm doing something silly.
<whitequark>
286Tech: nope, can only use a name
<d1b2>
<286Tech> Ok, so that's why it doesn't work. That's what the migen example does.
<whitequark>
but in this case the code is a bit odd
<d1b2>
<286Tech> I tried to match it as closely as I could between the migen and nmigen versions.
<d1b2>
<esden> @286Tech sorry still trying to parse the code... not sure why you have a tristate thing separately from the signals that are tristate already 🙂
<d1b2>
<esden> I know why you came to that from the code I wrote where I did use tristate directly
<d1b2>
<esden> the point here is that you don't need that any more
<d1b2>
<286Tech> Yeah the whole TristatePins class is pointless now.
<d1b2>
<esden> correct
<d1b2>
<286Tech> I should be able to assign all the Subsignals at once instead of each signal separately.
<whitequark>
FL4SHK: it looks like your use case is something that we should address with the Record redesign
<FL4SHK>
whitequark: sounds good
<FL4SHK>
I seem to have a knack for finding use cases people didn't think of...
<whitequark>
no
<whitequark>
Record is a longstanding pain point
<FL4SHK>
not referring to just this case
<whitequark>
ah
<ktemkin>
FL4SHK: be sure to stick around, then; that's a useful talent
<FL4SHK>
it's a point of frustration for me, usually
<whitequark>
seconded
<FL4SHK>
but nMigen actually handles things well
<whitequark>
well, that's also true
<whitequark>
oh :)
<d1b2>
<286Tech> @whitequark Is there a way to create a Resource that points to multiple pins, so that I don't have to refer to each pin separately? Then I could just iterate over each pin of the resource.
<whitequark>
286Tech: yes, but their direction is controlled all at once
<whitequark>
in this case I think you actually want multiple resources
<FL4SHK>
I have not really hit any pain points with nMigen, which is why I've been thinking of abandoning (or at least holding off on) my custom HDL project
<FL4SHK>
but I might actually steal some ideas from nMigen for it
<d1b2>
<286Tech> @whitequark In my case, each pin has the same direction, so that's actually perfect.
<whitequark>
because then you can do something like `platform.request("led", n) for n in range(16)`
<FL4SHK>
I *love* the DSL style of doing things
<whitequark>
ah
<FL4SHK>
I've just been itching to work on HDL projects for so long
<whitequark>
286Tech: okay, in that case do something like Pins("1 2 3")
<whitequark>
instead of just Pins("1")
<whitequark>
FL4SHK: niiice
<FL4SHK>
I had been holding off until I got my compiler working... but I got way too tired of waiting
<FL4SHK>
I'm primarily a CPU dev when it comes to hobby stuff
<FL4SHK>
but at work I dont' get to do that...
<FL4SHK>
I also don't always get to write HDL code at work
<d1b2>
<286Tech> @whitequark I see. I really have to get used to the way how to set up resources, signals, and pins, and how they interact with each other.
<whitequark>
hmmm I
<whitequark>
*I'm wondering if I should get the manual (or what's written of it at this point, anyway) live earlier
<FL4SHK>
by the way, the nmigen-boards thing is really, really nice
<FL4SHK>
It supports two of my three dev boards
<whitequark>
nice
<FL4SHK>
my old old dev board, the DE0-Nano, wasn't supported
<whitequark>
what is the third?
<d1b2>
<286Tech> Documentation (no matter how good, bad, and/or incomplete) would always be welcome 🙂
<whitequark>
you can port it from migen i think
<FL4SHK>
ah
<FL4SHK>
that dev board I got like, six years ago
<FL4SHK>
I don't know what to do with it
<whitequark>
ahh
<whitequark>
286Tech: the problem is that I started by writing a reference manual
<whitequark>
so it's hard to read for newcomers, and explains mostly things that are obvious, just it goes into every single subtlety
<d1b2>
<286Tech> That actually sounds... good?
<FL4SHK>
reference manuals seem to be more for people who have experience
<whitequark>
yes
<FL4SHK>
but aren't quite caught up to date
<whitequark>
nmigen needs three manuals
<whitequark>
tutorial, reference, and api reference
<whitequark>
well
<whitequark>
something like that, i think i call the second one "guide"
<FL4SHK>
Prima's Official Strategy Guide
<FL4SHK>
not that they make those any more...
<ktemkin>
so it needs a tutorial, a book, and an API reference~
<whitequark>
yes
<d1b2>
<286Tech> The syntax actually makes sense to me. It's just that I don't use nmigen often enough that I forget how to do things again, and every time I almost get it right 😛
<whitequark>
lemme try and bring it online now
<lkcl__>
whitequark: nmigen-boards - veeery interesting. it's what i was planning to create for the pinmux program.
<d1b2>
<286Tech> @esden I just created a pull request for the icebreaker-nmigen-examples repository.
<d1b2>
<286Tech> I can't really test if it works, but the verilog output looks correct to me.
<FL4SHK>
whitequark: got a little issue
<FL4SHK>
how do I go from a Record to a Shape?
<lkcl__>
if you're familiar with opentitan, they well... the lowrisc people were on the same mailing list on which i announced a collaboration with IIT Madras about 3 years ago.
<whitequark>
FL4SHK: Value.cast(rec).shape()
<lkcl__>
unfortunately, their work is hard-coded to RISC-V and uses systemverilog
<lkcl__>
sigh.
<lkcl__>
so, we have to start again (in nmigen this time, not bluespec)
<FL4SHK>
thank
<lkcl__>
so - delighted to see nmigen-boards resources library.
<lkcl__>
the original idea i had however was for things like SPIFlashResources (etc) to be auto-generated classes or to be meta-classes based on text or json files.
<lkcl__>
(just like in opentitan)
<whitequark>
nothing prevents you from generating those things based on some json files
<whitequark>
it's just python functions and classes, after all
<lkcl__>
yehyeh. i love doing that. less code, and you can use the exact same JSON files for generating many more things
<lkcl__>
GPIO linux kernel header files, device-tree source files, Technical Reference Manuals, the works
<lkcl__>
the amount of effort that proprietary companies put into their TRMs... 1200 pages - it's just mental
<lkcl__>
the downside: like 4th Normalised Form databases, the extra level of indirection confuses the hell out of people :)
<whitequark>
the problems with code generators start when they need to be debugged or changed
<whitequark>
for something like nmigen a lot of effort can go into diagnostics, debugging, support and so on
<whitequark>
but ad-hoc json-based board file generators? not so much
<lkcl__>
sigh. yes.
<lkcl__>
it's templates, and it's a mess. there are no good options.
<lkcl__>
you either write a program that writes out the source code
<lkcl__>
or you use a templating language.
<lkcl__>
for IIT Madras i chose the former (and it was a mess)
<lkcl__>
openpiton chose the latter (and it's a mess)
<lkcl__>
i am leaning towards code that reads JSON/text files and creates meta-classes (a dynamic class Factory)
<lkcl__>
ah.
<lkcl__>
i have a question.
<whitequark>
a good code generator makes the intermediate results inspectable
<whitequark>
for example, pysim is an average code generator because it's not very easy to debug pysim-emitted code
<whitequark>
you can dump it into /tmp but that's it
<lkcl__>
you wouldn't _happen_ to have created a class somewhere in nmigen/builds which uses one pin to "gang" (change) the direction of another group of pins, would you?
<whitequark>
one *pin*?
<lkcl__>
yes, usually wen
<whitequark>
are you making something like a bidirectional parallel bus?
<lkcl__>
yes.
<lkcl__>
sdram and so on
<whitequark>
no, not really. nmigen platforms don't contain any logic, directly at least
<whitequark>
you can do what you want with one m.d.comb
<whitequark>
so it doesn't make sense to put it into the boards or something
<lkcl__>
it's been 2 years since i worked on the code: i will have to review it again, i just remembered that there was a reason why one of the pins was special, could control the I/O direction of some others, and that needed to be put into the pinmux.
<lkcl__>
ah never mind i will remember why when the time comes
<lkcl__>
back to... code-generators... yes.
<lkcl__>
it's the combination of two languages that makes it difficult to develop and debug.
<lkcl__>
i had to constantly interrupt the IIT Madras team leader, every day, for an hour at a time often, for us to work out Bluespec issues.
<lkcl__>
there's no way i could have done that myself, and, without their input, there's no way i can now debug that code, because it might produce syntactically invalid output.
<lkcl__>
although i love meta-classes and dynamic class factories, i'm very tempted to include an option to actually generate and output python code (like nmigen-boards/resources/*.py)
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to doc [+16/-2/±6] https://git.io/JJeID
<whitequark>
that was... incredibly easy? i can't believe it worked first time
<lkcl__>
that's really funny. nmigen/build/dsl.py classes - Pins, Resource, Subsignal etc - they're exactly as i envisioned would be needed to do the dynamic pinmux :)
<lkcl__>
whitequark: what was? (i love it when things work first time)
<whitequark>
publishing the doc to github pages
<lkcl__>
cool! no effort :)
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to doc [+16/-2/±6] https://git.io/JJeI5
<whitequark>
feedback on this document is most welcome
<d1b2>
<286Tech> @whitequark Thanks! I will read it tomorrow, and I'll definitely give feedback if necessary.
<d1b2>
<286Tech> Would you mind if anyone tried to expand the tutorial part?
<whitequark>
yes, actually, I have a pretty specific plan for the entirety of the docs in mind and I'd like to follow it to completion
<whitequark>
I will ask for feedback and participation when appropriate, so you'll have a chance to give some input of course
<d1b2>
<286Tech> Allright, cool!
<d1b2>
<286Tech> It's actually pretty in depth from a quick glance
<whitequark>
yep, that's the intent
<lkcl__>
whitequark: sigh. if python had allowed for the over-riding of bool (it was a PEP - rejected) it would have been possible to do "convert nmigen value to python boolean). ah well :)
<whitequark>
no? that makes no sense
<whitequark>
nmigen values represent sets, not set elements
<whitequark>
it is not any more possible to convert nmigen signals to bool than it is to convert them to int
<lkcl__>
it was a while ago - someone suggested adding __bool__ (similar to __add__ __eq__ etc etc)
<whitequark>
and the error would still be there, because nmigen needs both branches of an if to execute
<whitequark>
what *would* help is the ability to override `and`
<whitequark>
but python won't accept it and frankly i tend to agree that they shouldn't