<_whitenotifier-b>
[nmigen] jeanthom edited issue #453: submodules are allowed inside If blocks - https://git.io/JJznm
<_whitenotifier-b>
[nmigen] whitequark commented on issue #453: submodules are allowed inside If blocks - https://git.io/JJgry
<_whitenotifier-b>
[nmigen] jeanthom commented on issue #453: submodules are allowed inside If blocks - https://git.io/JJgot
<_whitenotifier-b>
[nmigen] whitequark commented on issue #453: submodules are allowed inside If blocks - https://git.io/JJgol
_whitelogger has joined #nmigen
* zignig
has had a revelation.
<zignig>
<meta pun>
<zignig>
calling all nmigenauts, can WE all make some unitary CSR devices too fill 10mm^2 of ASIC
<zignig>
does not matter what it is, as long as it can be synthed and has function.
<zignig>
</meta pun>
hitomi2507 has quit [Quit: Nettalk6 - www.ntalk.de]
<d1b2>
<edbordin> can we design a core that is hardwired to only run nmigen?
<lkcl__>
whitequark: ping - got a rather interesting nmigen/verilator discrepancy involving unconnected signals.
<lkcl__>
picked up from just starting running litex (with florian's kind help)
<lkcl__>
we've a signal that i deliberately set to reset=1 in a module
<lkcl__>
then did *not* connect it externally (deliberately) because it's currently unused
<lkcl__>
nmigen sim: no problem. value defaults to 1, logic works
<lkcl__>
the output from nmigen conversion to *verilog* on the other hand exposes this signal as an *external* parameter which is connected to a *floating* (uninitialised) parameter in the parent, which because it is uninitialised it defaults to *zero*
<lkcl__>
actually just looking at the (equivalent) ilang file that's not quite correct: the ilang *does* connect the same signal externally - i'm tracking it now
<lkcl__>
yep - fascinating: the verilog and ilang are effectively identical - the "unused" signal is propagating right the way through to the top level in both cases, however there's no actual evidence that the "reset" assignment (setting it to 1) is present.
<whitequark>
lkcl__: yes. you need to explicitly specify ports=[] to convert() to make that not happen
<lkcl__>
whitequark: ooo ok
<lkcl__>
will give that a shot
<lkcl__>
ahh, "cu_shadown_i = 1" in the outputted verilog: superb! thank you
<lkcl__>
urrr now i don't have any ports at all :)
<lkcl__>
or perhaps the names have changed, will double-check
<lkcl__>
ahh yeh - all the ports have entirely gone, whoops :)
* lkcl__
checking if i can list them explicitly and still not have the submodule end up in... you get the idea
<whitequark>
sorry, I meant you have to specify the actual ports using ports=
<whitequark>
not that you need to specify an empty array specifically
<lkcl__>
:)
<lkcl__>
on the case
<lkcl__>
ha, that did it: thank you. really appreciated. hard to catch, that one.
<lkcl__>
whitequark: interestingly, litex "Display()" was what allowed florian to demonstrate a bug to me. which turned out to be Minerva i-fetch not setting wb.sel. need to communicate that to them somehow
<lkcl__>
it doesn't cause "problems" for the 32-bit to 32-bit wishbone infrastructure, however for the 64-to-32 (libresoc:64, litex:32) integration it definitely caused problems.
lkcl__ is now known as lkcl
zignig has quit [Remote host closed the connection]
proteus-guy has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<jfng>
lkcl__: fixed
<lkcl>
jfng: oh good! you may be interested to know, i expanded minerva fetch.py (and loadstore.py) to be arbitrary data/addr width
<jfng>
hm, i don't see the benefit of doing width conversion inside the cpu core. this can be done externally with bus adapters
<lkcl>
jfng: it's not width conversion, it's just parameterisation.
<lkcl>
so if at some point you ever wanted to expand minerva to 64 bit, for example
<lkcl>
64 bit i-fetch or 64-bit d-fetch
<jfng>
ah right, though not in the near future :)
<lkcl>
:)
<lkcl>
for libre-soc we will need 128-bit i-fetch in the future, and *right now* we need a whopping 256-bit wide d-fetch
<lkcl>
completely mental
<lkcl>
four 64-bit wishbone data buses! that's for "low-end" 3D performance!
<Lofty>
lkcl: My chess move generator produces a 1024-bit bus. It's fun to route.
<lkcl>
Lofty: oh, are you doing an ASIC?
<Lofty>
Even on an FPGA, but I did run it under OpenLANE too
<lkcl>
ohh the efabless thing. nice
<Lofty>
It's the SkyWater PDK toolchain.
<lkcl>
jean-paul from LIP6.fr warns that large data buses like that if routed symmetrically can get cross-talk
<Lofty>
Okay, "1024" is a bit too high, but the actual number is a bit complicated to figure out :P
<lkcl>
you have to put GND channels in place
<Lofty>
Honestly, I'm just putting my faith in the tooling
<lkcl>
you wanna know how many wires go into the LD/ST of libre-soc if we put down the (necessary) 8 LD/ST units?
<lkcl>
it's around 3,000 (!!) all into one small area.
<lkcl>
each LD/ST has around 192 wires, they break into 2 "ports" (again 192 each) to deal with mis-aligned requests
<lkcl>
and there's 8 of them
<sorear>
what's on the other end of those 16 ports that can serve 16 simultaneous memory requests?
<lkcl>
first CPUs people normally do, like 32-bit or 64-bit. this is just mad :)
<sorear>
I mean you could have done a vector unit with a large barrel shifter for alignment and a single 512-bit memory interface like a normal person
<lkcl>
sorear: a "Data Merger" which analyses the "sel" bitmask (like wishbone "sel") and (thank goodness) thunks them down to "only" 128-bit requests.
<lkcl>
sorear: lol
<lkcl>
those 128-bit requests, because they have 16 bits of "sel", the bottom 8 can go to 1 64-bit wishbone and the top 8 can go to another
<lkcl>
so although the vector unit is issuing what appears to be non-mergeable but sequentially-addressed LDs/STs
<lkcl>
at the DataMerger the lower 4 bits (after converting to a 16-bit mask) are analysed and it's there that, if they don't overlap, they can go out on the *same* clock as part of the same 128-bit request
<lkcl>
later, to avoid having to do full address-line compares in bits 5 and above we will "mark" the addresses as "sequential" back at the instruction issue phase.
<lkcl>
basically, the reason why not to do it the "normal" way is because the core is intended to be a multi-issue out-of-order engine
<sorear>
should we take this elsewhere?
<sorear>
not really migen-related at this point
<lkcl>
true - much as like discussing it, if it's ok with you i should return to debugging the integration with litex
emeb has joined #nmigen
proteus-guy has quit [Ping timeout: 256 seconds]
<_whitenotifier-b>
[nmigen] jfng opened issue #455: cxxsim: synchronous assignment inside If statement is not executed - https://git.io/JJgjt
<_whitenotifier-b>
[nmigen] jeanthom commented on issue #453: submodules are allowed inside If blocks - https://git.io/JJgj3
<_whitenotifier-b>
[nmigen] jeanthom closed issue #453: submodules are allowed inside If blocks - https://git.io/JJznm
<_whitenotifier-b>
[nmigen] whitequark commented on issue #455: cxxsim: synchronous assignment inside If statement is not executed - https://git.io/JJgjd
<_whitenotifier-b>
[nmigen] whitequark edited a comment on issue #455: cxxsim: synchronous assignment inside If statement is not executed - https://git.io/JJgjd
<DaKnig>
now gonna debug this. it hanged so I was impatient and gave up. not a good idea
<DaKnig>
yep it looks like it definitely hangs
<DaKnig>
what might be the issue?
<DaKnig>
nmigen never took more than a minute and I didnt add much code , so what happened here? it takes 100% of the CPU so Im assuming its in some kinda loop
<whitequark>
seems like you went overboard with arrays
<DaKnig>
:)
<DaKnig>
I made an array in a loop, as a lookup table, then asked it to index that array with three different signals to get three different values
<DaKnig>
is that not allowed?
<whitequark>
it is
<whitequark>
you might just not like what it expands to
<DaKnig>
TMDS_encode is a python function I wrote that operates on integers, returns integers.
jeanthom has joined #nmigen
<whitequark>
ah yes
<DaKnig>
I tested it, it works as expected.
<whitequark>
that expands to 2**24 branches
<whitequark>
when you use multiple arrays in a single statement, they get expanded to a combinatorial product of the cases
<DaKnig>
wait what
<DaKnig>
TMDS_LUT is 256 entries long
<whitequark>
yes
<DaKnig>
why not just make 3 LUTs out of it
<DaKnig>
or something
<whitequark>
well, that's not how arrays work right now
<DaKnig>
:(
<whitequark>
the nice thing about arrays is that they let you use anything as values, not just numbers
<DaKnig>
would be nice to get VHDL/sys verilog - like arrays
<DaKnig>
whats the problem here?
<DaKnig>
what can I do to make this work?
<DaKnig>
i want to generate a LUT via python code and then use it
<FL4SHK>
I did that
<FL4SHK>
I built a LUT out of Array's
<whitequark>
the problem is that arrays are translated in a way that can handle much more complex use cases than yours, and aren't optimized specifically for LUTs
<whitequark>
there's no reason what you wrote *can't* work well
<DaKnig>
what should I use for LUTs then
<whitequark>
but right now it doesn't
<whitequark>
you have two options
<whitequark>
you can use a Memory
<whitequark>
you can also use intermediate signals
<DaKnig>
Memory is a bit long :(
<DaKnig>
both of those options are not satisfying , but ok
<whitequark>
the backend looks at the controlling expression of the Array and expands it to a Switch/Case with cases for every possible value of the controlling expression
<DaKnig>
@FL4SHK look at my code first :) I think I get how to use em
<whitequark>
it does this recursively for every controlling expression in the statement
<whitequark>
so you first get a 256-case switch for pixel[:8]
<whitequark>
then in every case, a 256-case switch for pixel[8:16]
<whitequark>
etc
<DaKnig>
but thsoe statements should be "parallel"
<DaKnig>
dont depend on eachother
<whitequark>
yes, and there's no code to check for that
<whitequark>
because arrays were never intended to be used as simple LUTs
<awygle>
intermediate r, g, b signals Cat-ed together work just fine btw
<DaKnig>
so you expand the Cat into "all the possible values for all teh possible values of inputs involved in it"?
<whitequark>
basically, yes
<whitequark>
that's why it takes so long
<whitequark>
this works fine when the array values are complex, maybe signals or something, because your design isn't going to have 16 millions of signals
<DaKnig>
nasty
<DaKnig>
it would produce a hge file too :)
<DaKnig>
well ok
<DaKnig>
Cat should think of all the components as "parallel independent components" though
<DaKnig>
no
<DaKnig>
?
<DaKnig>
its not an AND gate or something
<whitequark>
no
<whitequark>
like i said, this is fixable in principle
<whitequark>
it's just not very easy with the current approach used in the backend
<awygle>
"arrays were never meant to be used as simple LUTs" curious about this - what should be used for simple LUTs if not Array?
<whitequark>
awygle: arrays with intermediate signals work fine
<whitequark>
just like memories would, but less verbose
<awygle>
yeah, i know they do, i was just curious about the statement
<whitequark>
awygle: oh, that was badly phrased
<whitequark>
i meant that arrays were never optimized for the case of being a simple LUT
<awygle>
ah
<whitequark>
i think it might be possible to rewrite the legalizer to use intermediate signals on its own
<whitequark>
it's not clear how that would work if you have cases like arrays used to index another array
<whitequark>
right now the legalizer uses a dumb approach that always works, but sometimes produces enormous netlists
<awygle>
you're planning to rewrite the whole approach at some point though right?
<whitequark>
i don't currently have such plans
<awygle>
something about term rewriting
<awygle>
or something
<whitequark>
oh
<whitequark>
that was for a different part of nmigen that also uses term rewriting, like the legalizer does
<whitequark>
well
<whitequark>
okay, no, the similarity is coincidental
<awygle>
ah that's where i saw this, the "pysim no like big memory" bug i was looking at last night
<whitequark>
oh
<whitequark>
oh that's entirely different
<lkcl>
DaKnig: try viewing that in graphviz (yosys "show"). it will be particularly illuminating.
<lkcl>
then run "proc" followed by "opt" and do the same "show" command
<lkcl>
and if you *really* want to melt your computer with 100% CPU, do "proc", "opt", "synth" _then_ "show" :)
<lkcl>
the expansion from high-level to low-level i find absolutely fascinating
SpaceCoaster_ has joined #nmigen
SpaceCoaster has quit [Ping timeout: 240 seconds]
Asuu has joined #nmigen
Asu has quit [Read error: Connection reset by peer]
<cr1901_modern>
Do you put your nmigen variables in .bashrc or .bash_profile?
<DaKnig>
whitequark: so it would take care of cases when the array has different width for A[x0] and A[x1] and you concatenate those?
<lkcl>
cr1901_modern: .bashrc is per-bash shell, .bash_profile is global for *all*
<lkcl>
for when you first log in
<DaKnig>
to me it looks like the problem is with Cat then, where the width of things it takes as input depends on something, and is not fixed
<lkcl>
something like that
<DaKnig>
like Cat(a,b) where the width of a differs depenind on something
<lkcl>
cr1901_modern: what are you trying to do? have the same nmigen variables on every single login / boot?
<lkcl>
or are you developing multiple projects simultaneously that need different variables?
<cr1901_modern>
the former
<DaKnig>
would it work if I cast all the outputs of the array to a constant width? so Cat(a[b].cast(8), a[c].cast(8))?
<lkcl>
ah then really you want to put them into e.g. ~/bin/project1_nmigen_vars
<lkcl>
and ~/bin/project2_nmigen_vars
<lkcl>
then in each xterm (whatever) do "source ~/bin/projectN_nmigen_vars" before starting work on that project
<cr1901_modern>
Yea, avoiding source is explicitly what I'm trying to do :P
<lkcl>
if you use a desktop environment you could put that into a startup script on a desktop
<lkcl>
:)
<lkcl>
yyeah it's "avoidable" by having separate startup scripts (different desktop shortcuts) that fire up separate xterms/whatever
<whitequark>
DaKnig: this has nothing to do with Cat(), the width is always the same
<whitequark>
this is purely a backend issue
<whitequark>
cr1901_modern: i have it in .bashrc
<lkcl>
whitequark: he's got multiple projects that have different nmigen variables and wants a convenient way to switch them
<lkcl>
without using "source {xxxxx}"
<lkcl>
kinda tricky
<cr1901_modern>
I think we aren't on the same page
<lkcl>
oh! right. former. yes, sorry.
<lkcl>
yes, chuck them in ~/.bashrc :)
<whitequark>
lkcl, would you please stop saying what other people want without actually understanding it?
<whitequark>
this has happened a few times already on this channel
<lkcl>
whitequark: i misread. that's all. it happens.
<whitequark>
just don't speak for others who can clearly do it for themselves
<cr1901_modern>
I'm not doing anything fancy, I just want to avoid the need for sourcing. I'm remoting into this system and don't often use Linux
<cr1901_modern>
whitequark: Ack, thanks
<lkcl>
and he picked up on the discrepancy. that allowed me to re-read. no harm done.
<cr1901_modern>
whitequark: To be clear, there's two sets of environment variables: One called NMIGEN_ENV_whatever that sets up everything for you, and another set with each tool name which you can point to the appropriate tool manually (more or less). Is this correct?
<whitequark>
cr1901_modern: there are three
<whitequark>
the two you just described are for the build trees generated by nmigen
<whitequark>
the third one is the overrides used *during* generation
<cr1901_modern>
ack
<cr1901_modern>
>the third one is the overrides used *during* generation
<cr1901_modern>
NMIGEN_verbose?
<whitequark>
yes, that's one of them
<cr1901_modern>
Okay cool... "python3 -m nmigen_boards.arty_a7" works until the programming phase
<cr1901_modern>
(which won't work b/c it's remote :P)
chipmuenk has joined #nmigen
<awygle>
ugh, testing. what if i just dropped this on hardware instead.
<DaKnig>
so uh
<DaKnig>
how do I use intermediate results to avoid the problem with the Arrays?
<DaKnig>
just `m.d.comb+=[temp.eq(Array[something]), output.eq(temp)]`?
<DaKnig>
would this work?
<DaKnig>
whitequark
<awygle>
DaKnig: r = TMDS_LUT[pixel[:8]]; ... also g and b ... ; encoded_pixel = Cat(r, g, b)
<DaKnig>
this would not make temp signals though
<DaKnig>
the =
<DaKnig>
its just moving around the fragments
emeb1 has joined #nmigen
emeb has quit [Quit: Leaving.]
emeb1 has quit [Client Quit]
_whitelogger has joined #nmigen
<DaKnig>
ok I used .eq and signals and it seems to work
chipmuenk has quit [Quit: chipmuenk]
<DaKnig>
lkcl: I just did what you said (without the synth obviously :) ) and it doesnt show anytihng; it looks blank. either it didnt work or my cpu is too slow
<DaKnig>
or maybe it only works on top level?
<DaKnig>
ah it was just huge
<DaKnig>
after proc+opt
jeanthom has quit [Ping timeout: 256 seconds]
<cr1901_modern>
whitequark: Just FYI... I almost got a prototype of paramiko working. Ubuntu has the absolutely _wonderful_ (/s times 50) behavior of not executing .bashrc in a non-interactive shell.
<cr1901_modern>
But it doesn't make sense to run a remote build in an interactive shell- I can't get the return code
<cr1901_modern>
This might work fine on other Linux flavors, but your idea of "having the user provide the env vars on the server" doesn't work on Ubuntu w/ the expected way of putting them into .bashrc
<cr1901_modern>
I guess there could be an env var that points to an alternate file to set your nmigen environment tho
<cr1901_modern>
(Am seeking input)
<cr1901_modern>
^_I_ think "having an alternate file to source nmigen vars on the server in your home directory" is reasonable for headless operation. You can source it in .bashrc as well.
<d1b2>
<emeb> trying to learn migen by porting my SDR tuner/downsampler from verilog. Got the tuner working but next up is the CIC filter which is full of fun genvar stuff. This will be a hoot...
<awygle>
cr1901_modern: does bash_profile get used by noninteractive shells?
<cr1901_modern>
If you pass the "-l" option. But that's a moot point, since my install doesn't _have_ a .bash_profile :)
<cr1901_modern>
(and AFAICT, never did)
<cr1901_modern>
Right, that's because it's called .profile... and wth is going on
<cr1901_modern>
err... something's not right
<cr1901_modern>
Okay, everything's fine... .bashrc is still excluded even if profile is source
<cr1901_modern>
My vivado's too old, but otherwise the script seems to work fine
<d1b2>
<edbordin> If you need to resort to a different file perhaps calling it .env would be a good convention to make use of
<cr1901_modern>
Well I'm not doing anything until I know what wq wants
<d1b2>
<edbordin> Sure, just thought I'd throw the idea in the mix :)