tannewt has quit [Read error: Connection reset by peer]
esden has quit [Ping timeout: 264 seconds]
tannewt has joined #nmigen
esden has joined #nmigen
cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
Degi has quit [Ping timeout: 264 seconds]
electronic_eel_ has joined #nmigen
electronic_eel has quit [Ping timeout: 264 seconds]
Degi has joined #nmigen
_whitelogger has joined #nmigen
<d1b2>
<dub_dub_11> I've just been having a look at the vendor files for supporting S3A and S6 through ISE, it seems like there are fairly few differences between platforms. Does that mean it would be a relatively manageable task to add further devices if I were to research those differences (and this only hasn't been done because other devices aren't commonly used), or are there some deeper limitations I am missing?
electronic_eel_ has quit [Ping timeout: 264 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
emeb_mac has quit [Quit: Leaving.]
<_whitenotifier-f>
[yowasp.github.io] whitequark closed issue #1: Pip made me scared. Is wasmtime 0.20.0 incompatible? - https://git.io/JTHia
<_whitenotifier-f>
[yowasp.github.io] whitequark commented on issue #1: Pip made me scared. Is wasmtime 0.20.0 incompatible? - https://git.io/JTQr6
<_whitenotifier-f>
[yowasp.github.io] whitequark commented on issue #2: What solvers come with yowasp? - https://git.io/JTQoe
<_whitenotifier-f>
[yosys] RobertBaruch opened issue #18: Pip made me scared. Is wasmtime 0.20.0 incompatible? - https://git.io/JTQoo
<_whitenotifier-f>
[yosys] RobertBaruch opened issue #19: What solvers come with yowasp? - https://git.io/JTQoi
<whitequark>
dub_dub_11: which other devices?
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to cxxsim [+3/-0/±4] https://git.io/JTQX4
<lkcl>
depending on the input length parameter type. int is fixed, Signal you can see at line 23 you can set the length dynamically to 1,2,4 or 8
<lkcl>
then you can do a Mux() on which order you want it
<lkcl>
the Mux will take which endian-ness you want, the original data or that byte-reversed data as parameters 1,2 and 3.
<Degi>
I mean yes it doesn't really exist, but it would make writing code easier. For example one value is made from byte 1 bits 0-5 and byte 2 bits 6-7, if I'd reverse endianness I could do data[8+2:8+2+8] instead if Cat(data[8:8+6], data[16+6:16+8)
<lkcl>
Degi: that's why i wrote that byte_reverse function. hm, so what you must be saying is: you'd like some way to set a context that alters the byte - or bit - order of *all* operations?
<lkcl>
which.... if it's done as a context (with m.ByteOrder(little=True) or with m.BitOrder(big=True))
<lkcl>
would actually be really neat
<Degi>
I think it would be enough to reverse the bit order of a signal, though not sure if its worth the complexity, since I don't need to deal with that so much
<Degi>
That would be good ^^
<lkcl>
it's conceptually similar to how VHDL works.
<lkcl>
the other way would be actually having the declaration be on the Signal itself
<Degi>
Maybe some class derived from Signal, like a ByteSignal
<lkcl>
yeah that's an idea too.
<lkcl>
my biggest concern that it would make a heck of a mess of peoples' expectations, if you know what i mean
<whitequark>
you can't derive from Signal (for good reasons)
<whitequark>
but deriving from ValueCastable (once it is merged) is viable
<lkcl>
they'd start going "urrr which order was that in, and what was this one, moo?" :)
<lkcl>
interesting about not being able to derive from Signal. i did consider at one time creating convenience classes Signal32 (etc, you can see where that goes)
<lkcl>
then realised that if i really wanted to they could be done as functions
<whitequark>
the problem with subclassing Signal is that it would force all internal code in nmigen to assume that Signal's behavior may change
<whitequark>
(or any other Value for that matter)
<lkcl>
that's interestingly unexpected
<whitequark>
well, it's how subclassing works. you keep some behavior as-is, and change some other behavior. but there's (in Python) no limitations as to what you change
<whitequark>
of course, Liskov substitution principle says you can't just change any behavior you like, but few people know or follow it
<whitequark>
on the other hand, monkey-patching classes you don't own is widely understood as a bad idea whose consequences you have to deal with on your own
<whitequark>
since I can't rely on, expect, or enforce LSP, I simply forbid subclassing Value altogether. it results in a more robust design in the end, anyway
<Degi>
LSP?
<d1b2>
<OmniTechnoMancer> helpful lack of non-overridable methods
<d1b2>
<OmniTechnoMancer> Enforcing a subtyping relation
<whitequark>
in short, it says that to preserve soundndess, a subclass must follow the contract of a superclass
<whitequark>
for example, Circle cannot be a subclass of Ellipse, even though many OOP examples are written with that hierarchy
<d1b2>
<OmniTechnoMancer> would depend on the interfaces present?
<d1b2>
<OmniTechnoMancer> I just prefer Traits
FFY00 has joined #nmigen
<_whitenotifier-f>
[nmigen] BracketMaster commented on issue #432: Add support for Display in simulation - https://git.io/JT7Z5
<_whitenotifier-f>
[nmigen] whitequark commented on issue #432: Add support for Display in simulation - https://git.io/JT7nh
emeb_mac has joined #nmigen
<agg>
is it possible to give connector pins custom names, rather than just integers starting from 1?
<agg>
lots of connectors with names for the pins rather than just numbers, even if sometimes those names are just numbers starting from 0
<whitequark>
agg: yep, any names can be provided in a dict
<agg>
oh, cool, nice! totally missed that, thanks
emeb has joined #nmigen
<kbeckmann>
is there a way to force a small AsyncFIFOBuffered to not use BRAM in an ECP5 design? need to run at 250 MHz and it's really on the limit..
<whitequark>
yes
<whitequark>
but it's uh... difficult
<kbeckmann>
ah..
<whitequark>
you need to put a (*logic_block*) attribute on the memory
<whitequark>
and the FIFO interface is not making it easy
<kbeckmann>
ok, thanks, will try a quick hack to see if it solves my problem.
<lkcl>
kbeckmann: 250mhz on an ECP5, that's impressive.
<kbeckmann>
it's for handling serdes data.
<kbeckmann>
you can run stuff at over 400 MHz too, as long as it's small enough :)
samlittlewood has joined #nmigen
samlittlewood has quit [Quit: samlittlewood]
emeb has left #nmigen [#nmigen]
<_whitenotifier-f>
[nmigen] nfbraun opened issue #519: Xilinx Zynq: generated bitstreams do not work with (recent?) FPGA manager - https://git.io/JT7pG
<_whitenotifier-f>
[nmigen] nfbraun edited issue #519: Xilinx Zynq: generated bitstreams do not work with (recent?) FPGA manager - https://git.io/JT7pG