ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting August 17th
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #nmigen
emeb_mac has quit [Ping timeout: 264 seconds]
emeb_mac has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
kbeckmann has quit [Ping timeout: 240 seconds]
emeb_mac has quit [Ping timeout: 264 seconds]
emeb_mac has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
anu3jn has quit [Ping timeout: 246 seconds]
jfng has quit [Ping timeout: 246 seconds]
emily has quit [Read error: Connection reset by peer]
nurelin has quit [Remote host closed the connection]
cesar[m] has quit [Remote host closed the connection]
cesar[m] has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
jfng has joined #nmigen
anu3jn has joined #nmigen
emily has joined #nmigen
nurelin has joined #nmigen
hitomi2507 has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
Sarayan has quit [Ping timeout: 272 seconds]
kbeckmann has joined #nmigen
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
anu3jn has quit [Quit: killed]
jfng has quit [Quit: killed]
cesar[m] has quit [Quit: killed]
emily has quit [Quit: killed]
nurelin has quit [Quit: killed]
emily has joined #nmigen
Asu has joined #nmigen
jfng has joined #nmigen
cesar[m] has joined #nmigen
anu3jn has joined #nmigen
nurelin has joined #nmigen
proteus-guy has joined #nmigen
proteus-guy has quit [Remote host closed the connection]
proteus-guy has joined #nmigen
<anuejn> awygle: would yo mind me picking up your work on fixing the {r,w}_level bugs on AsyncFIFO ?
alexhw has quit [Quit: - Chat comfortably. Anywhere.]
<awygle> Not at all. Go for it.
<awygle> I believe the remaining bug is just an overflow probity
<awygle> *problem
<awygle> And then we need test cases
Asuu has joined #nmigen
Asu has quit [Ping timeout: 260 seconds]
phire has quit [Quit: ZNC -]
<anuejn> ok
phire has joined #nmigen
<anuejn> hm... somehow the semantics of AsyncFIFOBuffered w_level are wired
<anuejn> it can only reach depth-1
<anuejn> and is most of the time like off by -1
<anuejn> and i dont really know how to properly fix this
<anuejn> awygle: you can take a look here:
alexhw has joined #nmigen
<anuejn> the problem as i see it is that we would need to do something similiar to for the w_level
<anuejn> but we cant do that right away because there is a cdc hazard and if we do proper cdc with the FFSyncronizer, that adds a lot of latency which leads to very wired semantics
<anuejn> but maybe i am just wrong here?
<Degi> lkcl__ there is a resizer here, maybe something like this?
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 246 seconds]
moony has joined #nmigen
<moony> Still learning how FPGA design/HDL works, so appologies if the answer to this is really simple: what would be the best way to represent a multi-port memory?
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #nmigen
hitomi2507 has quit [Quit: Nettalk6 -]
emeb has joined #nmigen
<DaKnig> inheriting from Records is supported right?
<DaKnig> if so can somebody send me a link with an example of that?
<DaKnig> FL4SHK: you told me to pong you for such questions
<moony> is there a way to omit some signals from the .vcd? They're just temporary values, and they're in some object that there's a ton of, so they clog up things a bit
<ktemkin> moony: write_vcd takes a `traces` kwarg
<ktemkin> I don't remember if it adds to or sets the list of displayed traces
<moony> ktemkin: seems to add to it
<lkcl_> Degi: oo that's a nice general-purpose module.
<lkcl_> hmm hmm i need something which understands "sel" masks though.
<Lofty> Hi moony
<moony> hi
<Lofty> I see you took my advice in emudev
<moony> yes
<moony> much nicer than Verilog/VHDL, so far.
<Lofty> Remember, usability issues are bugs!
<DaKnig> sadly nmigen doesnt solve my main issue with VHDL... which is width of code lines
<DaKnig> maybe its something inherent with HDLs? I dont know.
<d1b2> <TiltMeSenpai> wdym width of code lines
<d1b2> <TiltMeSenpai> like keeping 80/100 character lines?
<DaKnig> yes
<d1b2> <TiltMeSenpai> python's pretty flexible with where you can put line breaks
<DaKnig> it is. but the result is still ugly
<d1b2> <TiltMeSenpai> sure
<d1b2> <TiltMeSenpai> what's contributing to your long lines? using Cat a bunch?
<DaKnig> I dont know. too many indentations maybe. compared to C/normal python where I almost never go over 80 chars per line, for some reason its way harder with nmigen or VHDL
<DaKnig> for me at least
<d1b2> <TiltMeSenpai> do you mind if I take a peek at some of your code? there's patterns that you can follow that sometimes help break up lines more logically
<d1b2> <TiltMeSenpai> it's easy to chain operators in python, sometimes you get carried away and end up with long lines
<DaKnig> lemme find a place to paste the code...
<DaKnig> its not that I am not able to keep it under 80 chars, it just feels like I have to break lines more often and that means I end up with very long code.
<DaKnig> <- here, dont judge the fact it doesnt work, still WIP
<DaKnig> this is my second rewrite that I had to make in order to stay below 80 chars per line (I have to keep below that to have two buffers of text on screen side by side)
<d1b2> <TiltMeSenpai> lol maybe it's because I've been writing python for quite a bit of time, but that doesn't look too bad to me
<d1b2> <TiltMeSenpai> am I missing something or is line 126-ish always false
<d1b2> <TiltMeSenpai> with m.If((ctrl_queue[0].vsync == 1) & (ctrl_queue[0].vsync == 0) ):
<DaKnig> ok you spotted a bug. thanks. one is supposed to be [1].
<DaKnig> I think
<d1b2> <TiltMeSenpai> lol, I was looking at that and like "huh, that's strange." Different eyes often help spot bugs
<d1b2> <TiltMeSenpai> is there a term for how staring at a code base for too long kind of makes you blind to the code's actual details?
<DaKnig> it doesnt look too bad because I had to split many lines, consciously make the decision of where to cut the line all the time, something I dont have to do with software langs as this is rarely a problem for me.
<moony> is there some special way signals can be bundled together, or is a list of signals fine
<DaKnig> Records
<DaKnig> its like C structs
<DaKnig> moony:
<DaKnig> you can have .eq between two records and such
<DaKnig> can even inherit from Record and extend it to your needs
<d1b2> <TiltMeSenpai> can you .eq between 2 different record types?
<d1b2> <TiltMeSenpai> (this probably shouldn't be a normal use case, I'm just curious)
<DaKnig> not sure... doesnt it Cat the record and then call .eq on that?
<ktemkin> TiltMeSenpai: you can, with current record semantics
<d1b2> <TiltMeSenpai> huh, cool
<Degi> Can I somehow make a list of unassociated signals which are driven from different domains?
<Degi> [Signal(16, reset=0xFFFF)] * self.__bytes seems to make nmigen think that they need to be driven from the same domain
<d1b2> <TiltMeSenpai> you can make a python list of signals, but I think if you make it a nmigen object, it'll have some undefined behavior
<Degi> Oh yes [Signal(16, reset=0xFFFF) for i in range(self.__bytes)] works
_florent_ has quit [Ping timeout: 240 seconds]
sorear has quit [Read error: Connection reset by peer]
ianloic has quit [Ping timeout: 244 seconds]
sorear has joined #nmigen
ianloic has joined #nmigen
_florent_ has joined #nmigen
<moony> is there any further docs on Switch/Case? I think i'm misusing them somehow
<moony> specifically, is `m.Case(0b0000, 0b0001, 0b1100, 0b1101)` valid?
<moony> Lofty: as you're often around, ^
emeb_mac has joined #nmigen
<moony> ok, no, it's not that
<moony> weird
<moony> my code stops working if my busses are widened from 16-bit to 32-bit
<moony> `m.d.comb += Cat(self.out_bus, self.carry_out).eq(self.in_bus_a + self.in_bus_b + self.carry_in)` is failing the carry flag test when adding 0x8000 and 0x8000
<moony> oh i see
* moony dumb
<moony> i forgot to widen the bus in the test rig
<Lofty> moony: Try m.Case((0b0000, 0b0001, 0b1100, 0b1101)) - that should work?
<moony> Lofty: it works, I just made a silly mistake
<Lofty> Switch doesn't have much to document, but Case has a lot of fun tricks
<Lofty> For example, you can have python Enums and use those as parameters to Case
<Lofty> Or use a string
<Lofty> Which lets you use the - character for don't-care values
<moony> `m.Case("000-", "110-")` is much shorter, thanks for that note
Asuu has quit [Quit: Konversation terminated!]
emeb has quit [Ping timeout: 246 seconds]
emeb has joined #nmigen
emeb has quit [Quit: Leaving.]
<moony> `m.d.comb += self.reserved_op.eq(1)` If I do this conditionally, do I need to set it to 0 in the Else case for defined behavior? (This is the only place it'll ever be set)
<moony> or is it pulled to 0
<DaKnig> you mean condition this in runtime or compile time?
<moony> runtime
<DaKnig> (m.If vs if)
<DaKnig> ok
<moony> with m.If
<DaKnig> the way it works is like so
<DaKnig> if a signal is driven in the comb domain, it is a good idea to have a default value for it.
<moony> so write 0 first, then overwrite later?
<DaKnig> when no assignments are active (when your comb m.If doesnt activate) it resets to default value.
<DaKnig> combinatoric signals dont have memory.
<DaKnig> just remember that.
<moony> right
<DaKnig> I think you set the default value with `reset=`
<DaKnig> lemme check
<moony> so it's otherwise left undefined if I don't do that. Mk
<DaKnig> here found it
<DaKnig> type in python `help (Signal)`
<DaKnig> go down to the parameter `reset`
<moony> thanks
<moony> being new to python, I wasn't even aware `help()` existed, so thanks for that too
<Lofty> moony: it's not undefined; it's defined to initialise to zero
<moony> Lofty: Yea, I saw that
<moony> after I made the comment
<moony> :P
<DaKnig> Lofty: 0 is just the default value. it would reset to the value in `reset` parameter you pass to the constructor
<Lofty> But yeah, in nMigen last sync assignment wins, but multiple comb assignments result in DriverConflicts
<Lofty> DaKnig: well, okay, yes
<Lofty> I suppose I rarely use reset= and treat it as initialise to zero
<Lofty> But you are correct
<DaKnig> I have counters that count up to some value then stop on that. then they are reset by some external signals. I set them to their highest value with reset=.
<moony> What's the appropriate way to sign extend a signal?
<moony> use a signed() signal? (My signal is unsigned, though, so that'd generate an extra signal for no good reason)
<Lofty> moony: there isn't an official operator, but it's being discussed
<Lofty> You can probably try a Cat
<moony> hm
esden has quit [Read error: Connection reset by peer]
<moony> Lofty: With the cat, do you mean making an all-carry-bit signal to concat onto the signal I wish to extend?
tannewt has quit [Ping timeout: 260 seconds]
tannewt has joined #nmigen
esden has joined #nmigen
<Lofty> To sign extend a signal, use a Repl to get N sign bits, and then Cat it with the original signal
<Lofty> moony: ^
<whitequark> Lofty: wait, DriverConflicts?
<whitequark> oh
<whitequark> ok so both comb and sync assignments have last-write-wins semantics
<whitequark> if they don't that seems like a bug
<whitequark> *if they don't in some specific case
<tannewt> wq, when you have a chance is there a reason clocks and reset aren't passed into elaboratables? Seems like they could be treated like any other signal.