<guest24923092>
ive been trying out nmigen lately, and i was wondering if there was any way to make it feel less
<guest24923092>
"clunky"
<guest24923092>
like the assignments and whatnot
peepsalot has quit [Ping timeout: 246 seconds]
peepsalot has joined #nmigen
chipmuenk has joined #nmigen
hitomi2502 has joined #nmigen
Asu has joined #nmigen
jeanthom has joined #nmigen
nengel has joined #nmigen
<Lofty>
guest24923092: it's a lot less clunky than it could be
<Lofty>
I'd have to see your code though
<Lofty>
Some things that come to mind are that you can pass a list to m.d.XXX, so you don't have to write all of that for every assignment
proteus-guy has quit [Ping timeout: 264 seconds]
Lofty has quit [Ping timeout: 240 seconds]
<lkcl__>
guest24923092: are you aware, nmigen builds an Abstract Syntax Tree representing the hardware?
<lkcl__>
i have found that once i accepted that concept, things became much easier
<lkcl__>
i also found: what also helped - and still continues to help - is to examine the graphviz output with yosys "read_ilang" and "show top" (or show othersubmodule) every single time
<whitequark>
Sarayan: the wasm toolchain
<lkcl__>
i quickly got a feel for the interconnections where i found that simply looking at the python code *i had written* was unable to give me a clear understanding of the gates and interconnections
<whitequark>
yes, and this is not just about the default case
<whitequark>
Case() statements are always position-dependent, which is the case because you can use wildcards in them
<whitequark>
so if you have multiple statements that can match (and Case(...) without arguments always matches), then the first one in source code order is the one that matches
<jeanthom>
that makes sense for Case with wildcards but isn't that error prone for the default case?
<whitequark>
there is no "default case"
hitomi2502 is now known as hitomi2500
<whitequark>
it's just a complete wildcard, the same as Case("-------")
<whitequark>
that said
<whitequark>
we can certainly add a diagnostic to catch this, something like "unreachable case"
<whitequark>
the main problem here is that every opportunistic diagnostic like this needs a way to suppress it, in case that you did in fact want to express exacty what you wrote
<whitequark>
and i'm not sure how that would work
hitomi2500 has quit [Quit: Nettalk6 - www.ntalk.de]
hitomi2500 has joined #nmigen
<whitequark>
anyway, feel free to open an issue about it
<vup>
adding a `allow_unreachable=True` to `Case` maybe?
<whitequark>
nope
<whitequark>
linter suppressions shouldn't be options that do nothing in the core language
<vup>
ok makes sense, though that makes it a lot harder :)
<whitequark>
they should be either valid syntax that makes it unambiguous what's happening, or a dedicated construct
<whitequark>
yes
<whitequark>
take a look at _check_signed_cond
<jeanthom>
what would be the use cases for "Case" that are unreachable?
<whitequark>
the same as other seemingly absurd constructs: they come up in generic code
<whitequark>
maybe you are e.g. generating these Case() statements from some kind of table you are reading from a file
<whitequark>
for example an instruction decoder or something like that
<whitequark>
then, you don't really care about getting lints, because that external data source presumably has its own checks, and any redundancies are intended
<whitequark>
so if the lint wouldn't be easily disabled, you'd have to redo the analysis nmigen does in your own code, which is annoying
<jeanthom>
yeah reimplementing all the checks outside nMigen would be annoying
<jeanthom>
do we already have ways to disable lints for other things in nMigen?
<whitequark>
sure. see _check_signed_cond
<whitequark>
jeanthom: please open an issue about this so we can at least discuss the possible solution
<whitequark>
if there is a good way to suppress the lint after all, we can add the lint
<_whitenotifier-f>
[nmigen] jeanthom opened issue #404: Unused cases in a switch do not trigger warnings - https://git.io/Jf5R1
<_whitenotifier-f>
[nmigen] jeanthom edited issue #404: Unused cases in a switch do not trigger warnings - https://git.io/Jf5R1
<whitequark>
thanks!
<jeanthom>
you're welcome :)
Asuu has joined #nmigen
Asu has quit [Remote host closed the connection]
futarisIRCcloud has quit [Ping timeout: 256 seconds]
levi has quit [Ping timeout: 256 seconds]
rohitksingh has quit [Ping timeout: 256 seconds]
_florent_ has quit [Ping timeout: 256 seconds]
_florent_ has joined #nmigen
futarisIRCcloud has joined #nmigen
levi has joined #nmigen
rohitksingh has joined #nmigen
ZirconiumX has joined #nmigen
ZirconiumX is now known as Lofty
shizoor has joined #nmigen
<shizoor>
Managed to get nmigen to import a small png or jpeg and display it on screen.
<shizoor>
Or rather pillow does that and numpy makes it an array and so on. Thanks for helping me in here. :)
<agg>
nice!
<agg>
i did a vaguely similar thing ages ago using pillow to draw a font table: you give pillow an OTF, it renders all the letters into a bitmap which it dumps into a bram
<agg>
very cute to just give my code a font file and by magic the fpga gets to draw that font to the screen
<shizoor>
Still bugs to fix, plus I got sidetracked by my mate asking me to do an acid house smiley and making it do raster effects depending on colour. I'm new to this, is "bram" bitmap ram?
<agg>
'block ram', the embedded memory elements in an fpga
<agg>
or, one type of embedded memory in fpgas
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<shizoor>
Tell me more man, can I address that using nmigen on a Lattice ice40? I've founf if I do more than 264x10 pixels, build time goes through the roof. I'm currently declaring an array of unsigned signal.
<shizoor>
found*
<whitequark>
use a Memory
<shizoor>
Thanks!
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
shizoor has quit [Ping timeout: 246 seconds]
hitomi2500 has quit [Quit: Nettalk6 - www.ntalk.de]
<jeanthom>
Is there a way to individually control the direction of "io" pins?
<awygle>
That's what "oe" does
<jeanthom>
awygle, it seems like oe is a global direction switch
<Sarayan>
and that would give me a proxy to the value with read/write?
<whitequark>
that would be pretty much the same thing as doing p_top.p_clk, but for deeply nested signals or signals with weird names it's a lot more convenient
<whitequark>
to answer your question, yes
<Sarayan>
right now having to do signal.curr[0] and signal.next[0] is a little verbose, but not the end of the world
<Sarayan>
the annoying C++-related part is that you can't have references as globals
<Sarayan>
but that's not your fault
<whitequark>
.curr[] and .next[] will be fixed
<whitequark>
in fact that's the next thing on my todo list
<Sarayan>
cool
<whitequark>
you'll be able to do something like
<whitequark>
clk.set(true); / clk.get<bool>()
<Sarayan>
you could make that go down to clk = true; and clk itself if you felt like it
<Sarayan>
with a little enable_if
<whitequark>
i absolutely will not
<Sarayan>
huhuhu
<Sarayan>
that's where wq's line is then :-)
<whitequark>
values are not implicitly castable or assignable to anything and that's by design
<Sarayan>
values sure, but proxies?
<whitequark>
what proxies?
<Sarayan>
I thought the as<> stuff gave you a proxy to the value
<whitequark>
no, it gives you the actual thing
<Sarayan>
so that you can wrap all the C++ sugar you want on top of it without dirtying the inners
<Sarayan>
innards
<whitequark>
that just makes it pointlessly harder to understand
<whitequark>
i'm not a fan of "modern c++" either if you're wondering
<Sarayan>
I'm a fan of, well, half of it
<Sarayan>
to be used with moderation
<Sarayan>
range for, auto on long-named variables, I love
<whitequark>
right, that makes sense
<whitequark>
but like, the fact that cxxrtl uses c++ is already bad enough
<whitequark>
i use it not because it is a good idea but because it is a less bad idea than the alternatives i've seen
<Sarayan>
massaging interfaces on templates with enable_if can make the uses very clean, you just have to be sane
<whitequark>
and then they break and you're left wondering how the fuck is that supposed to work
<whitequark>
the error messages from cxxrtl are already bordering on unusably bad, which is normal by c++ standards
<Sarayan>
the more complex ones I did haven't even broken yet, strangely
<whitequark>
i'm not gonna make them any worse
<Sarayan>
yeah, it's a cost/benefit ratio, a core component used by 4000+ drivers, I try to make the driver code as simple and plain as possible
<whitequark>
sure, i can figure out nearly any c++ error no matter how bad
<whitequark>
others don't, necessarily
<Sarayan>
yeah, error messages are still catastrophic. And cxxrtl has weird erroring
<Sarayan>
is it me, or is pycvd generating ambiguous vcd files?
<Sarayan>
varables are named with increasing numbers, and I'm not sure how you recognize 1 from 11 with just a different lenght value
<Sarayan>
hex numbers, but tthat doesn't change much
<whitequark>
if the first symbol is 0 or 1, it knows the name comes next
<whitequark>
bit vectors start with symbol b, followed by the bits, followed by the space, then the name
<Sarayan>
oh, there's a space if it's not pure 0/1?
<Sarayan>
ok, that works then
<Sarayan>
if it stupid but it works... well in that case it's still stupid
<whitequark>
yes
<anuejn>
is it intendet, that DomainRenamer doesnt affect ClockSignal()?
<anuejn>
ah ofc it is only renamed if the ClockSignal is consumed directy in that module and not passed somewhere else
<anuejn>
that is ... nasty
<vup>
well thats kinda how DomainRenamer works, no? It can't rename something not part of the fragment / the subfragments of the fragment.
<anuejn>
jup, thats what i figured
<anuejn>
but for my usecase it was still unintuitive
<whitequark>
the way domains work are somewhat unintuitive, yeah
<whitequark>
I might be able to fix this in a later refactor, but no promises
<vup>
maybe DomainRenamer is actually a antipattern and one should always pass around the clockdomain string names, that would avoid most of these confusions I think
<whitequark>
nah, that's too much noise
<whitequark>
there's enough noise in the syntax already to add even more
<whitequark>
further, you have the same problem with EnableInserter and ResetInserter and to fix that you'd have to pass enable and reset signals in every module
<whitequark>
what we can do is add signals bound to a specific scope
<whitequark>
something like `m.get_clock_signal()`
chipmuenk has quit [Quit: chipmuenk]
<anuejn>
That sounds nice and like it avoids my problem
<whitequark>
i have no immediate plans for that though, so use a workaround for now (i.e. an intermediate signal(
<whitequark>
any solution with scoped signals would have to come after a fairly large refactor of signal scoping
<Sarayan>
Can time be a uint64_t in picoseconds, or do we need better than that?
<Sarayan>
that's 253 days max
<Sarayan>
and vcd can theoretically do femtoseconds
<Sarayan>
but do we care?
<Sarayan>
128 bits sounds like overkill
<whitequark>
can you explain the context?
<whitequark>
cxxrtl lets you choose the vcd timebase
<Sarayan>
sotring the date from a vcd or anything else related
<Sarayan>
storing
<Sarayan>
in memory, that is
<Sarayan>
possibly, loading multiple vcds with different timebases at the same time
<Sarayan>
so I'd rather use an absolute time instead of a clock,count pair
<whitequark>
oh you mean for your viewer
<Sarayan>
yeah
<whitequark>
make a type for it that for now wraps uint64_t
<whitequark>
then you'll be able to fix it later if it matters