<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
<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 - www.ntalk.de]
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>
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
<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.