ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #nmigen
futarisIRCcloud has joined #nmigen
guest24923092 has joined #nmigen
<guest24923092> hellllooooooooo
<guest24923092> o crap
<guest24923092> crappy kbd
<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
<jeanthom> whitequark, is it normal that the default Case in a Switch is position dependant?
<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 -]
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 -
<_whitenotifier-f> [nmigen] jeanthom edited issue #404: Unused cases in a switch do not trigger warnings -
<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 -]
<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
<awygle> Global in what sense?
<awygle> Each pin has its own oe signal
<jeanthom> gives me len(self.pads.dq.oe) = 1 and len(self.pads.dq.oe) = 16 for the DQ signals of the DDR3 resource
<jeanthom> ie. self.pads = platform.request("ddr3", 0)
<jeanthom> oops it's actually len(self.pads.dq.oe) = 1 and len(self.pads.dq.o) = 16
<jeanthom> not sure if it's a bug or if it is indeed the expected behavior
<whitequark> yes, that's correct
<whitequark> the direction for all pins in a group is controlled at once
<whitequark> do you need to do it individually for DDR3?
<hell__> afaik DDR3 DQs all change direction at once
<hell__> not sure about DQS though
<jeanthom> whitequark, in LiteDRAM there is a TSHX2DQSA instanciated for each DQS and DQ pin
<jeanthom> I'm not sure if it's necessary though
<whitequark> you can request raw inout signals for those pins
<whitequark> dir={"dq":"-", "dqs":"-"}
<jeanthom> you mean I can simply replace the direction with "-" in the platform file and I'll be good to go?
<awygle> Ah I didn't realize your pins were grouped, sorry
guest24923092 has left #nmigen [#nmigen]
ananan has joined #nmigen
<ananan> Is there a way to do something like
<ananan> with (something)m.sync:
<ananan> stb.eq(counter == 100)
<ananan> or something like that?
<ananan> instead of m.d.sync += stb.eq(counter == 100)
<whitequark> jeanthom: the direction in the platform file should probably stay as it is
<whitequark> but you can request nmigen to give you a raw signal during instantiation (platform.request)
<whitequark> ananan: nope
<awygle> ananan: you can do m.d.sync += [.........]
<awygle> Where the dots can be multiple lines
<Sarayan> wq: the c++ api, very cool
<whitequark> oh?
<Sarayan> Yeah, I can see that my nmigen code is broken much more easily
<Sarayan> no need to change the code too look at arbitrary stored signals
<Sarayan> to
<Sarayan> ell, the nmigen code that is
<Sarayan> w
<whitequark> you mean the debug_items thing?
<whitequark> I was thinking it might be useful to let you do something like
<whitequark> value<1> &v = debug_info["clk"].as<value<1>>();
<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[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
<Sarayan> compiler having an issue with a template:
<Sarayan> when you have a series of case and multiple ones match, is it UB, first one wins, last one wins?
<Lofty> First one wins
<Sarayan> thanks
<whitequark> Sarayan: can you show an example?
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk1 has joined #nmigen
chipmuenk1 is now known as chipmuenk
renze has quit [Quit: Spaceserver reboot?!]
<Sarayan> this case vs. the following one
<whitequark> no I mean regarding VCD
<Sarayan> oh
<Sarayan> one sec
<whitequark> oh
<whitequark> the vcd format is very stupid
<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
<Sarayan> sounds like a good idea
jeanthom has quit [Ping timeout: 240 seconds]
q3k has quit [Ping timeout: 256 seconds]
q3k has joined #nmigen
q3k has quit [Remote host closed the connection]
q3k has joined #nmigen
Asu has joined #nmigen
Asuu has quit [Ping timeout: 256 seconds]
MadHacker has quit [*.net *.split]
vup has quit [*.net *.split]
esden has quit [*.net *.split]
Asu has quit [*.net *.split]
felix_ has quit [*.net *.split]
lkcl__ has quit [*.net *.split]
bubble_buster has quit [*.net *.split]
SpaceCoaster has quit [*.net *.split]
pdp7 has quit [*.net *.split]
Cynthia has quit [*.net *.split]
daveshah has quit [*.net *.split]
ananan has quit [*.net *.split]
anuejn has quit [*.net *.split]
electronic_eel has quit [*.net *.split]
key2 has quit [*.net *.split]
samlittlewood has quit [*.net *.split]
lethalbit has quit [*.net *.split]
tpw_rules has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
nengel has quit [*.net *.split]
mwk has quit [*.net *.split]
miek has quit [*.net *.split]
mithro has quit [*.net *.split]
zignig has quit [*.net *.split]
plaes has quit [*.net *.split]
smkz has quit [*.net *.split]
emily has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
Stary has quit [*.net *.split]
hell__ has quit [*.net *.split]
Lofty has quit [*.net *.split]
Ekho has quit [*.net *.split]
ronyrus has quit [*.net *.split]
phire has quit [*.net *.split]
ktemkin has quit [*.net *.split]
awygle has quit [*.net *.split]
agg has quit [*.net *.split]
rohitksingh has quit [*.net *.split]
guan has quit [*.net *.split]
Sarayan has quit [*.net *.split]
ianloic has quit [*.net *.split]
whitequark has quit [*.net *.split]
loxodes has quit [*.net *.split]
peepsalot has quit [*.net *.split]
Degi has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
alexhw has quit [*.net *.split]
_whitelogger has joined #nmigen
emily has joined #nmigen
Asu has quit [Quit: Konversation terminated!]