levi_ has quit [Read error: Connection reset by peer]
levi_ has joined #nmigen
bubble_buster has quit [Ping timeout: 240 seconds]
mithro has quit [Ping timeout: 240 seconds]
bubble_buster has joined #nmigen
mithro has joined #nmigen
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #nmigen
Degi_ is now known as Degi
levi_ is now known as levi
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #nmigen
futarisIRCcloud has joined #nmigen
jeanthom has joined #nmigen
Asu has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
chipmuenk has joined #nmigen
Sarayan has joined #nmigen
<zignig>
whitequark: after much deliberation I find my self missing a few things.
<zignig>
is there a way do dump heirachy post elaborate and before synth ?
<zignig>
I understand that it is a lambda squiggle.
<zignig>
I it would be possible to dump the submodules vs class it would be possible to build cxxrtl constructs,
* zignig
needs to sleep more and type less.
<Lofty>
zignig: may I ask what your use-case is for this?
<zignig>
Lofty: attempting to put a boneless into cxxrtl and bind peripherals to c++ templated objects.
<Lofty>
Well, nmigen dumps RTLIL, and then cxxrtl takes it in
<zignig>
yep and I find a disconnect between named nmigen and cxxrtl cariables.
<zignig>
*v
<Lofty>
That sounds like a bug, but I don't know what optimisation level you're passing to write_cxxrtl
<zignig>
indeed , the degub_info() means that you can get a space delimimted heir. from cxxrtl , but I can squeeze it out of nmigen elaboratable.
<zignig>
*can
<zignig>
'*can't
* zignig
's fingers are failing.
<zignig>
Lofty: what are you buildinf at the moment?
<Lofty>
...?
<Lofty>
I've been working on synth_intel_alm a bit
<zignig>
with nmigen ?
<zignig>
I have been trying to reflect nmigen_boards , but I keep on getting distracted...
<Lofty>
In terms of nmigen stuff...not all that much
<Lofty>
I might revisit my chess program
<Lofty>
Having accidentally nuked the source code of it while moving from WSL1 to WSL2
<zignig>
oops :)
<zignig>
what board do you have?
* zignig
thinks that cxxrtl can provide for the boardless.
<Lofty>
DE-10 Nano
<Lofty>
Which uses the Cyclone V
<zignig>
cool
futarisIRCcloud has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
<whitequark>
zignig: use back.cxxrtl.convert_fragment
<whitequark>
that gives you two return values, the C++ code and the map from signals to hierarchical names
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
pbsds43 has joined #nmigen
pbsds has joined #nmigen
pbsds43 has quit [Remote host closed the connection]
<whitequark>
kbeckmann: what's "pergola"?
<whitequark>
nvm found it
<whitequark>
kbeckmann: hey, nice board, and I like your code too
<kbeckmann>
thanks :)
<whitequark>
are you building those for other people? i rly want to play with the dvi-d stuff now
<kbeckmann>
i'm currently a bit stuck because of some bad design decisions, so will make a second rev to clear those up. note to self: sharing the flash between the MCU and the ECP5 was not a great idea.
<kbeckmann>
yeah that is the idea. i want to finish the board and ideally make a small production run of it.
<whitequark>
(i have enough devboards that can do this but a versa is too complex and expensive to do stuff like that on a whim)
<whitequark>
cool
<kbeckmann>
yeah the bom is like 20 usd or so, which was the point of it. cheap and not too many things on it.
<whitequark>
btw you don't need __main__ stuff in __init__.py
<kbeckmann>
i have parts for a few more boards. i can solder one up and ship to you if you like.
<whitequark>
and i think you can't actually use it
<whitequark>
to answer that question
<whitequark>
yep, that would be great, assuming you won't drop the firmware support for that rev or if it won't need reflashes
<whitequark>
(not sure what's the situation with the errata)
<kbeckmann>
sure that will not be a problem. and if you need to reflash it, it has both SWD pins and a usb rom bootloader.
<kbeckmann>
there is not a lot of code out there written in nmigen. i have mostly been looking at Luna and the code itself.
<whitequark>
that should be platform.default_clk_frequency
<whitequark>
precisely because that construct is so unwieldy otherwise
<whitequark>
yeah
<whitequark>
kbeckmann: have there been any frustrations you encountered while writing that code?
<whitequark>
anything that can be improved in nmigen?
<kbeckmann>
yeah.. but when i have realized how to use it it is kinda obvious
<kbeckmann>
connectors is something i didn't get at all because i couldn't figure out how to use them
<whitequark>
oh, yeah
<whitequark>
they're just a way to rename pins
<kbeckmann>
but it seems you can just pass conn=... in a Resource
<kbeckmann>
here some example would be really helpful
<whitequark>
yep
<kbeckmann>
and again, obvious when you know the answer :)
<kbeckmann>
one thing that i am not sure if it is a good or bad thing, is that it's not possible to drive individual bits in a signal from different clock domains. i guess this is per design as it prevents dangerous mistakes?
<whitequark>
so that's actually a surprisingly complicated issue
<kbeckmann>
i can imagine...
<whitequark>
not in the sense of code
<whitequark>
but in the sense of design
<whitequark>
right now, it would not be hard to let you do that in nmigen, it's just one condition
<whitequark>
but it would cause a number of problems
<kbeckmann>
it seems like an odd use case but i can still see why one wants to do it. in my case i just split up my wide signal.
<whitequark>
but an even worse problem is that if you *export* a module from nmigen, or import a module from another HDL, you'll then need to describe ports at bit granularity
<kbeckmann>
ohh right.
<whitequark>
oh wait
<whitequark>
also the yosys verilog backend struggles a lot with such signals
<whitequark>
I'm curious, where did you encounter this?
<kbeckmann>
oh..
<whitequark>
maybe we can provide a palatable workaround
<kbeckmann>
it was when i was trying to generate multiple rgb color values in a slower clockdomain and doing a gearbox by writing strange code :)
<whitequark>
right, ok
<whitequark>
then I guess my recommendation boils down to "don't do that"
<kbeckmann>
yep :)
<kbeckmann>
i am not very experienced with HDL at all, so i'm partly learning hdl in general, while learning nmigen. so i will keep making strange mistakes for sure.
<whitequark>
experienced designers have also expressed the desire for being able to drive a signal from multiple domains
<whitequark>
so it's not (just?) a beginner mistake
<kbeckmann>
i see. maybe they have a very specific usecase in mind.
<kbeckmann>
and i'm just doing things wrong :)
<whitequark>
it's for CDC i think
<kbeckmann>
right
<whitequark>
so... pretty similar to what you want
<whitequark>
it's just so hard to support properly that accepting the limitation might be better in long run
<whitequark>
fun fact
<whitequark>
in verilog it is legal to write `always @(posedge clocks[0])`
<whitequark>
and the amount of code in cxxrtl necessary to handle that correctly is staggering
<kbeckmann>
oh...
<whitequark>
this feature is like the inverse of the one we were discussing
<kbeckmann>
trying to understand why one wants to bundle up multiple clocks in the same signal/wire
<kbeckmann>
oh yeah another minor frustration. simulations. i struggled a bit to get the phase right when having multiple clocks. usually i want the simulation to begin with a low clock so you can see the initial state and what happens after the first clock edge.
<kbeckmann>
trying to remember if this was a real problem or not. but i remember having issues with it.
<whitequark>
quite possibly real, simulations are a bit of a weak point currently
<whitequark>
btw, how do i run the simulation?
<whitequark>
can't seem to figure it out from your code