<lsneff>
wasmer is just a company that writes a webassembly runtime. They don't have any particular sway in the progression of wasm.
emeb_mac has quit [Quit: Leaving.]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
phiren has joined #nmigen
phire has quit [*.net *.split]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
Bertl_oO is now known as Bertl_zZ
<lsneff>
whitequark: query database for a 625 MB file ends up being about 260 MBs.
<lsneff>
not bad, I think
<whitequark>
yep, reasonable
<lsneff>
*625 MB vcd file
emeb_mac has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
<lsneff>
Searching through the db is going to be complex than I thought.
jjeanthom has joined #nmigen
chipmuenk has joined #nmigen
jjeanthom has quit [Ping timeout: 240 seconds]
jjeanthom has joined #nmigen
virtimus has joined #nmigen
virtimus has left #nmigen [#nmigen]
virtimus has joined #nmigen
cesar[m] has quit [Quit: Bridge terminating on SIGTERM]
JJJollyjim has quit [Quit: Bridge terminating on SIGTERM]
nono2357[m] has quit [Quit: Bridge terminating on SIGTERM]
emily has quit [Quit: Bridge terminating on SIGTERM]
jfng has quit [Quit: Bridge terminating on SIGTERM]
samlittlewood has quit [Ping timeout: 246 seconds]
JJJollyjim has joined #nmigen
emily has joined #nmigen
cesar[m] has joined #nmigen
RenaudLifchitz[m has joined #nmigen
jfng has joined #nmigen
Ultrasauce has quit [Quit: Ultrasauce]
virtimus has quit [Remote host closed the connection]
Ultrasauce has joined #nmigen
Bertl_zZ is now known as Bertl
rohitksingh_ has joined #nmigen
rohitksingh_ has joined #nmigen
rohitksingh_ has quit [Client Quit]
<modwizcode>
So I'm trying to convert a project module by module to using nMigen. Is there a way to integrate existing HDL into like wrapper classes or something?
<ktemkin>
yep
<modwizcode>
How might I do that?
<ktemkin>
the instantiation is done with Instance
<ktemkin>
lemme grab a log with an explanation in it
<modwizcode>
Where's Instance?
<modwizcode>
I can't figure out which source file it's in lol
<modwizcode>
okay sounds good
<modwizcode>
oh found the file
<agg>
you can also use platform.add_file to add a verilog file to the build
<modwizcode>
Do I have to do that?
<agg>
if you're using nmigen's build system you'll have to do that to get your external .v files included
<modwizcode>
Right now I have a bit of a problem as it doesn't support the platform I'm using (polarfire) I'm planning on implementing that support though
<whitequark>
oh hi modwizcode!
<agg>
if you're using nmigen to generate verilog of your new code, you could just use that nmigen-generated verilog in your old build system
<modwizcode>
hi whitequark
<whitequark>
what agg just recommended sounds reasonable to me
<modwizcode>
Generating the verilog and pulling it into Libero?
<whitequark>
pretty much
<whitequark>
it should get you started quickly
<modwizcode>
Yeah seems about right
<modwizcode>
I noticed that it seems like migen had like built in stuff for wishbone but nmigen doesn't right?
<ktemkin>
there's some stuff in `nmigen-soc` paralleling the old misoc stuff that'll get you a bit of the way there
<modwizcode>
Also is there an example somewhere of how to properly use the build system and generate code, all the examples I can find seem... slightly dated or don't actually cover the build system.
<modwizcode>
Ah right okay. Forgot about nmigen-soc
<whitequark>
better docs are something that was happening until 2020 interfered
chipmuenk has quit [Quit: chipmuenk]
<modwizcode>
Ah. I'm pedantic for "correctness" when I start new projects so a recommendation down the right path would help.
<whitequark>
if you just want to get some verilog, then it's: `from nmigen.back import verilog; verilog.convert(top, ports=[...])`
chipmuenk1 has joined #nmigen
<whitequark>
where `top` is an Elaboratable and `ports` is a collection of signals you want to become toplevel ports
<modwizcode>
Is it going to be frustrating if I don't convert it with an actual top layer module? I think when I was playing with fifo stuff I noticed it literally instantiates with top, but I was using that "main" thing so I could run simulation too
<modwizcode>
*instantiates it as a module called top
<whitequark>
you can pass a `name="foo"` argument to `convert()`
<modwizcode>
ah thanks
<whitequark>
the main thing is currently not well thought out so don't get stuck on it too much
<whitequark>
it was a quick PoC that never got fleshed out the way it deserved to be
chipmuenk1 is now known as chipmuenk
<modwizcode>
that's what i figured. it gets kinda weird if you forget arguments lol
<modwizcode>
I should submit a patch for that
<modwizcode>
I actually have a more theoretical question too about how resets are handled. So say I want to expose a reset for my module (polarfire FPGAs need a reset since they can't do initial values afaik), so in my module I assign variable to a ResetSignal for that clock domain, and then all those will refer to the same signal, so driving any of them will reset the whole design?
<whitequark>
more or less
<modwizcode>
Do I actually want to expose that signal out of my modules? Signals can have a "reset" value, should I just ignore the "ResetSignal" and specify reset values on my Signals? I think I'm a bit confused here.
<whitequark>
so ResetSignal(domain) is a way to late bind to the reset input of the FFs in that domain (or "sync" if not specified)
<whitequark>
the Signal(reset=) parameter is the actual reset value, or the initial value if the device supports it
<Lofty>
(polarfire FPGAs need a reset since they can't do initial values afaik) <-- they can!
<modwizcode>
I was just parroting what my boss told me, I've not worked with them enough to know the issue.
<modwizcode>
I assume there's some issue though.
<modwizcode>
So for the reset I really don't want to be doing something like "with m.If(ResetSignal()): ...".
<whitequark>
nmigen does that for you on its own
<whitequark>
with m.If(ResetSignal()): m.d.sync += sig.eq(sig.reset)`
<whitequark>
except it happens for every signal in every domain with reset
<modwizcode>
Right, so I should just set initial values using the reset parameter of the Signal itself.
<whitequark>
yes…
<whitequark>
*.
<modwizcode>
Will it expose a reset signal when I generate the module or do I have to create one and put it in the ports parameter?
<whitequark>
this depends on whether you create a clock domain yourself
<whitequark>
if you do not, it will automatically add a clock and a reset and expose them
<whitequark>
(since otherwise you do not have a way to add them to ports)
<Sarayan>
What happens when FFs only have async clear and no async set, signal is stored inverted?
<Lofty>
Sarayan: yep
<Sarayan>
cool
<whitequark>
assuming the toolchain actually handles that case, anyway
<Sarayan>
yosys/nextpnr ftw
<whitequark>
I'm sure some of them silently miscompile instead
<modwizcode>
hey Sarayan did you see my reply to your question in #yosys the other day? Did you work that issue out?
<Sarayan>
maybe not, what was my question already?
<modwizcode>
Idk if it was so much a question but you had an issue with cxxrtl generating really long lines
<Sarayan>
well, it's more the >256 levels of parenthesis, but there's a clang flag for that
<modwizcode>
Yeah but I was more interested in why the line was so long
<modwizcode>
Did you run it through an opt pass by any chance?
<Sarayan>
That you'd have to ask wq, I can put the verilog code somewhere, it's a sv2v of fx68k
<Sarayan>
-O6 -g3
<Sarayan>
iirc
<modwizcode>
I was just wondering if it was run through a yosys opt pass.
<Sarayan>
I think write_cxxrtl -O6 -g3 runs thourgh a lot of yosys passes
<Lofty>
If it went through sv2v it's going to be a bit messy
<modwizcode>
Yeah it shouldn't go through a yosys opt pass by default though
<modwizcode>
but if you didn't run it through one then what I was thinking probably isn't relevant
<Sarayan>
Dunno, just did read, hierarchy and write
<Sarayan>
But write does a lot of stuff
<modwizcode>
Yeah probably not the thing I notice then.
<Sarayan>
including things like memory_collect and flatten, so why not opt?
<modwizcode>
It doesn't I've looked at the code
<Sarayan>
ok :-)
<modwizcode>
and opt is bad for cxxrtl me and wq talked about it the other day
<modwizcode>
Which can cause cxxrtl to generate weird stuff (although in this case it actually is able to figure stuff out generally)
<Sarayan>
nice sign extension
<modwizcode>
It's not a sign extension
<modwizcode>
it's the enable signal to a memory block
<modwizcode>
It actually generates that assignment twice (both times the same signal I think although I didn't care enough to verify proper)
<Sarayan>
b[30:0] = 31 copies of b[31] looks furiously like a sign extension, amusing that it happens with enables
<whitequark>
IIRC I fixed that one
<whitequark>
there is a repeat detector
<modwizcode>
Yeah it looks like CXXRTL figures something out
<modwizcode>
But it still sees a feedback arc
<modwizcode>
what seems even more strange is that those EN signals in the c++ generated don't seem to get assigned to anything.
<whitequark>
you should run `clean` after `opt` to avoid that
<whitequark>
except... `clean` is kind of broken in yosys at the momen
<whitequark>
it does several different things and none of them well
<whitequark>
(there's an issue about it)
<modwizcode>
I forgot clean even existed
<Sarayan>
"it does several different things and none of them well" -- I love and hate that sentence at the same time
<modwizcode>
Huhhhh this generated code is totally screwy this doesn't make sense at all
<modwizcode>
"always @(negedge 1'hx) begin" is nonsense right?
emeb has joined #nmigen
<Sarayan>
"never begin" :-)
<daveshah>
I've seen this before but I can't remember why
<modwizcode>
That's the product of the opt pass written back to verilog on that design with the weird repeat enable
<modwizcode>
it runs all the assign logic for the fifo in that block... which... I don't understand
<modwizcode>
https://paste.debian.net/1179905/ This is the file. This is the SyncFIFO from nMigen written out as verilog combined with a verilog testbench driver that I made to test with cxxrtl
<modwizcode>
written back to verilog.
chipmuenk has quit [Quit: chipmuenk]
<cr1901_modern>
Is "x" "undefined" or "don't care"? "always @(negedge 1'hx) begin" _feels_ like it should "run whenever it feels like, I don't care"
<modwizcode>
I'm pretty sure it's a combination but I think "undefined" is closer
<modwizcode>
The problem is, unless that syntax is some special quirk I'm not recognizing, that code doesn't function the same as the input source, since I can't see it every actually running the process to update the memory.
lime has joined #nmigen
lime has left #nmigen [#nmigen]
<whitequark>
cr1901_modern: the answer is "yes", but in this context it means "never"
<whitequark>
modwizcode: it is possible you are encountering some corner case due to the way opt and write_verilog interact
<modwizcode>
Oh goodie
<modwizcode>
I seem to be good at this
<modwizcode>
Is that worth reporting? What I'm doing seems kind of insane and iirc isn't write_verilog like not specified to work or something?
<whitequark>
what?
<whitequark>
wtf do you mean by "not specified to work"? it's an integral part of nmigen among other things
<modwizcode>
I might be confusing it with the read_verilog pass
<modwizcode>
I'm confusing myself. That note is what I was thinking of but I do run the proc pass and the generated rtlil doesn't seem to have processes.
<whitequark>
yes
<modwizcode>
so it's a bug then right?
<whitequark>
i don't know
<whitequark>
i haven't looked at the code
<whitequark>
have a lot more important things to do
<whitequark>
i'm just saying that you can report it
<modwizcode>
okay
emeb_mac has joined #nmigen
korken89 has joined #nmigen
mogery has joined #nmigen
chipmuenk has joined #nmigen
mogery has quit [Read error: Connection reset by peer]
korken89 has quit [Remote host closed the connection]
aquijoule_ has quit [Remote host closed the connection]