<awygle>
whitequark: so i'm using `m._statements` to look at the statements in this module, which works fine if they're bare `m.d.sync += ...` stuff but when i add a `with m.If(...)` around it suddenly `m._statements` is `()`?
<awygle>
is there a way to see like, the whole module?
<awygle>
or am i doing something wrong, as i increasingly suspect
<awygle>
ah, `m._ctrl_stack` seems to give me what i want
<_whitenotifier-3>
[nmigen] awygle opened issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvqP
<awygle>
i swear i'm gonna change my irc nick just so the bot doesn't ping me every time
_whitelogger has joined #nmigen
____ has joined #nmigen
<whitequark>
awygle: you need to flush the module, i think
<_whitenotifier-3>
[nmigen] whitequark commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/Jfv3k
<_whitenotifier-3>
[nmigen] whitequark edited a comment on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/Jfv3k
<_whitenotifier-3>
[nmigen] whitequark edited a comment on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/Jfv3k
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jvp1g
<_whitenotifier-3>
[nmigen] FFY00 commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfvsD
<awygle>
whitequark: ah I'll try that
<_whitenotifier-3>
[nmigen] ohsix commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfvG4
rohitksingh has quit [Ping timeout: 260 seconds]
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfvG6
chipmuenk has joined #nmigen
pinknok has joined #nmigen
Vinalon has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
____2 has joined #nmigen
____ has quit [Ping timeout: 264 seconds]
<chipmuenk>
I'm doing a little project together with a student: I would like to use nMigen instead of migen in my filter design tool https://github.com/chipmuenk/pyfda for fixpoint simulation and Verilog export. The student has had some problems with installing Yosys under Windows (I'm looking into that) which brought up the question: Do I really need Yosys for simulation and Verilog export?
<whitequark>
simulation: nope
<whitequark>
verilog export: yes
<whitequark>
I've been working on a "turnkey" method of installing Yosys but it is unfortunately not trivial and there are a few ecosystem components that were not ready
<chipmuenk>
Ah, ok. That means in comparison to migen, the architecture is more modular?
<_whitenotifier-3>
[nmigen] alanvgreen commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfvZp
<whitequark>
I'm not sure if I would say "more modular" exactly, but at the moment, nMigen is a Yosys frontend
<whitequark>
it does not generate Verilog itself because it is *extremely* hard to do that correctly
<whitequark>
and Migen had a large amount of bugs in its Verilog generator that were never really fixed, in particular around signed values, so probably also bugs you care about
<whitequark>
Yosys' Verilog backend is subject to randomized testing, so it is in a much better shape with that regard
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jvp1g
<chipmuenk>
Yes, I'd like to rely on correct behaviour w.r.t. signed values ;-) ... I'll try to get the toolchain up and running, I think there is a problem with the path on the student's computer.
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jvp1g
pinknok has joined #nmigen
<whitequark>
chipmuenk: my idea for turnkey installation is to compile Yosys to web assembly and then ship *that* in a pip package
<whitequark>
it is exceedingly cursed, but it is the best I can do here, I think
<whitequark>
the last time unfortunately I could not get it to work as every WASM compiler crashed on Yosys
<MadHacker>
Now you just need a python webasm interpreter.
<MadHacker>
Or a python-targetting C++ compiler. :D
<MadHacker>
(I'm strangely tempted by that horrifying prospect. I'm a bad man.)
<whitequark>
there is a python wasm interpreter
<whitequark>
well, it's a native extenion, but it is already shipped by some people working on wasm
<whitequark>
hence the attractiveness of this method
<MadHacker>
Isn't that just moving your build issues to the extension?
<MadHacker>
Presumably it has some deps of its own?
<whitequark>
the beauty is that (a) it is someone else's problem, and (b) a lot more people would use that than just Yosys, meaning it would be tested better and work on more platforms
<whitequark>
it shouldn't have any dependencies, just a binary wheel
<whitequark>
it depends on glibc of course
<whitequark>
and on msvcrt
<whitequark>
this *does* cause problems, but nothing that can't be solved
<MadHacker>
So, compile a wasm yosys, ship it as a binary along with nmigen, tell people to pip install <wasminterpreterthing>, profit?
<whitequark>
not quite
<whitequark>
ship it as nmigen-yosys which depends on whichever wasm interpreter i end up using
<whitequark>
and make that an optional dependency of nmigen, used as a fallback if there is no system yosys or if the system yosys has an unsatisfying version
<whitequark>
(maybe the other way around? not sure yet)
<MadHacker>
Aye, by "along with", I was assuming a certain amount of separation, but yep, that's sane.
<_whitenotifier-3>
[nmigen] programmerjake commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfvCt
<whitequark>
awygle: btw the bot shouldn't ping you on notices
<whitequark>
in fact the whole point of notices is that they don't ping you (or other bots)
<whitequark>
it seems like your client is buggy (which unfortunately is true of a few of them)
<_whitenotifier-3>
[nmigen] codecov[bot] commented on pull request #357: make Record inherit from UserValue - https://git.io/JfvCw
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #357: make Record inherit from UserValue - https://git.io/JfvCw
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #357: make Record inherit from UserValue - https://git.io/JfvCw
<_whitenotifier-3>
[nmigen] anuejn commented on issue #355: [RFC] Redesign UserValue to avoid breaking code that inherits from it - https://git.io/JfvC6
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #357: make Record inherit from UserValue - https://git.io/JfvCw
<_whitenotifier-3>
[nmigen] whitequark commented on issue #355: [RFC] Redesign UserValue to avoid breaking code that inherits from it - https://git.io/JfvCQ
<_whitenotifier-3>
[nmigen] anuejn commented on pull request #357: make Record inherit from UserValue - https://git.io/JfvC7
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #357: make Record inherit from UserValue - https://git.io/JfvCd
anuejn_ is now known as anuejn
<_whitenotifier-3>
[nmigen] anuejn commented on issue #355: [RFC] Redesign UserValue to avoid breaking code that inherits from it - https://git.io/JfvWv
<_whitenotifier-3>
[nmigen] anuejn commented on pull request #357: make Record inherit from UserValue - https://git.io/JfvWk
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #357: make Record inherit from UserValue - https://git.io/JfvWn
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfvW8
<ronyrus>
so, If I want to use nMigen and have a visibility into what happens on the FPGA, like with logic analyzer, using UART as transport out, what should I be using?
<ronyrus>
there is a LiteScope, but it's from the Migen ecosystem, is there something in the nMIgen ecosystem?
<ronyrus>
ok, so what would be the next best thing to do?
<whitequark>
which FPGA / board are you using?
<ronyrus>
ECP5
<ronyrus>
eval
<whitequark>
in the past I've brought signals out to pin headers and used an external LA, but this doesn't always work
<whitequark>
the next step would be building your own debug tool, unfortunately
<ronyrus>
one of the problems that I have is I want to sniff the ULPI interface on 60MHZ. LA that I have can't keep up ...
<whitequark>
there will be something like `nmigen-scope`, but not very soon; there are higher priority issues to be handled in close future
<whitequark>
I see
<whitequark>
you might be able to use nmigen with vendor tools and use Lattice's ILA
<whitequark>
I never tried it, but nmigen *does* support Diamond
<whitequark>
never tried the ILA, that is
<ronyrus>
yeah, that might work.
<ronyrus>
thanks
<whitequark>
ah, there is another approach yet
<ronyrus>
I'm listening ... I"m on mac and there is no diamond for mac, so yeah ...
<awygle>
The diamond ila is pretty buggy but not too bad. Porting litescope to nmigen-compat is not terribly difficult I don't think - I basically did it previously before I got too full of myself
<whitequark>
since it is unlikely that an ILA could keep up with 60 MHz * 7 bit anyway, an approach you could take is a ring buffer that is continuously filled with samples and then paused and retrieved on a trigger
<whitequark>
keep up in realtime*
<awygle>
wq, I get pinged any time any message has the word "awygle" in it anywhere, is that not expected behavior?
<whitequark>
which should be something you can build in a few hours without much trouble
<whitequark>
awygle: ok, so, _whitenotifier sends a special kind of message called "notice"
<whitequark>
which should be displayed differently and also not ping you
<whitequark>
which client?
<ronyrus>
wq: some like something ah-hocish, just to record and get out the samples, yeah?
<awygle>
but it's impossible to acquire, because the archives of the conference only go back to 1988 and the paper was presented in 1987
<awygle>
and there seem to be no electronic versions
<awygle>
and obviously physical copies are right out due to plague
<awygle>
frustrating.
<whitequark>
awygle: jfng: so i have this minor conundrum with blackboxes in cxxrtl
<whitequark>
regarding yesterday's discussion, i thought more about it and it became clear to me that cxxrtl should *not* guess what a signature of an undefined blackbox module looks like
<whitequark>
yes, strictly speaking, if you use parametric blackbox cells where port widths depend on parameters, you are stuck examining use sites rather than definition site anyway
<whitequark>
but in that case, you still do need a single definition site to get a single C++ class
<whitequark>
worse yet, if you only examine use sites, you can easily get into a situation where the class write_cxxrtl infers from use sites does not, due to a mistake, match the implementation provided by the simulation harness, leading to awful C++ errors
<whitequark>
this means that cxxrtl should always require a module to be present when translating a cell, and refuse to do so if there isn't one.
<whitequark>
now, the conundrum
<whitequark>
is it even possible to have parametric blackboxes with cxxrtl?
<whitequark>
the idea with cxxrtl is that it turns the blackbox into a class definition, which your simulated PHY inherits from
<whitequark>
so cxxrtl gives you an abstract class `bb_uart_phy` for example, and a free function `bb_uart_phy* cxxrtl_design::create_uart_phy(name, parameters, attributes)`, where you can return a subclass
<whitequark>
and of course you can have a bunch of implementations, like TTY, unix socket, TCP, and so on
<whitequark>
the problem is
<whitequark>
if a wire width depends on a parameter of a blackbox, the class would be something like `bb_uart_phy<DATA_WIDTH=16>`, and a function `create_uart_phy` would be preceded by `template<size_t DATA_WIDTH>`, and now you can no longer provide it externally, I think
<whitequark>
*squints* actually i know how to fix this, hold on
<_whitenotifier-3>
[nmigen] alanvgreen commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jfv8K
<whitequark>
i hate that i know how to make it work
<whitequark>
the way it works is by combining template prototypes (yes, you can have templated functions without inline implementations) and function template specialization
<whitequark>
the generated code would have a reference to create_uart_phy<8> specifically
<whitequark>
and as long as the simulation harness specializes the PHY for every possible datapath width (typically not a problem, you'll only have a few--but worst case, i imagine you could just make a massive table of those) those references will resolve just fine
chipmuenk1 has joined #nmigen
<_whitenotifier-3>
[nmigen] graingert opened pull request #358: use declarative setuptools config - https://git.io/JfvBX
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #358: use declarative setuptools config - https://git.io/JfvRY
<_whitenotifier-3>
[nmigen] graingert edited a comment on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jfvw8
<_whitenotifier-3>
[nmigen] whitequark commented on issue #254: Find solution to translate values to strings for Symbiyosys vcd files - https://git.io/JfvrI
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JfvrG
<_whitenotifier-3>
[nmigen] whitequark closed issue #254: Find solution to translate values to strings for Symbiyosys vcd files - https://git.io/JfvrZ
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #358: use declarative setuptools config - https://git.io/JfvRY
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #358: use declarative setuptools config - https://git.io/JfvRY
<_whitenotifier-3>
[nmigen] whitequark commented on issue #254: Find solution to translate values to strings for Symbiyosys vcd files - https://git.io/JfvrC
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #358: use declarative setuptools config - https://git.io/JfvRY
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #358: use declarative setuptools config - https://git.io/JfvRY
<_whitenotifier-3>
[nmigen] whitequark commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/Jfvrz
<Vinalon>
Is it possible to use an iCE40's SPRAM instead of BRAM for memories which don't need multiple r/w ports?
<ZirconiumX>
Vinalon: you'll have to instantiate it manually
<ZirconiumX>
But yes
<Vinalon>
so would I need to write a similar class to Memory, probably with a ReadWritePort instead of ReadPort/WritePort, and use Instances to define the properties which are probably explained in one of Lattice's TNs somewhere?
<whitequark>
you can just use Instance
<whitequark>
at some point, Yosys will infer SPRAM from the normal Memory cla
<whitequark>
*class
<whitequark>
but not yet
<whitequark>
there are some limitations of its memory inference which make that impossible
<Vinalon>
okay, thanks - I guess I'll look at how the ReadPort and WritePort Instances compare to the BRAM and yosys IL documentation, then
Berni has quit [Remote host closed the connection]
<_whitenotifier-3>
[nmigen] alanvgreen commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfvHR
pinknok has quit [Ping timeout: 272 seconds]
<_whitenotifier-3>
[nmigen] awygle commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvQI
<_whitenotifier-3>
[nmigen] whitequark commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvQO
<_whitenotifier-3>
[nmigen] awygle commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvQC
<_whitenotifier-3>
[nmigen] whitequark commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvQl
<_whitenotifier-3>
[nmigen] awygle commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvQ4
<awygle>
whitequark: how do you feel about "on_entry" and "on_exit" (or i guess "after_entering" and "after_leaving" to use oMigen terminology)? do you feel they're useful, and if so, do you think they belong on states or on transitions?
<_whitenotifier-3>
[nmigen] whitequark commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvQE
<whitequark>
awygle: "something like that" is useful, but i think we shouldn't just blindly introduce them yet
<whitequark>
for one, i believe we should refactor the FSMs to make them first-class first
<awygle>
sure, i feel that way broadly about any enhancements to the state machine stuff
<whitequark>
ok
<whitequark>
long term, i think we should have something like that
<whitequark>
but we really need to think about potential interactions with the rest of the language
<whitequark>
for exmaple, before_entering and before_leaving would create comb loops in oMigen
<whitequark>
and were very very hard to use correctly
<awygle>
mhm. my hypothesis is that if the hooks are attached to transitions instead of states, you don't need the `before` class, but that's yet to be tested
<_whitenotifier-3>
[nmigen] whitequark commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvQK
<whitequark>
it's quite possible there is a better approach
<_whitenotifier-3>
[nmigen] awygle commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvQX
<whitequark>
afaik I looked into the history of oMigen's FSM module and it was implemented in a completely ad-hoc way when various things in MiSoC needed it
<awygle>
so what i'm doing right now is implementing a DDR2 controller as a hierarchical state machine in nmigen
<awygle>
(because i need a DDR2 controller, and i like hierarchical state machines / statecharts)
<awygle>
i'm going to (attempt to) faithfully implement those semantics, and then maybe the two of us can look at how it turned out in this nontrivial project and decide if we like it more broadly
<awygle>
(well more than just us of course)
<_whitenotifier-3>
[nmigen] whitequark commented on issue #356: Export Past, Rose, Fell, etc from nmigen.hdl.ast - https://git.io/JfvQH