ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting November 2nd
<_whitenotifier-f> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-f> [YoWASP/yosys] whitequark 346f12f - Update dependencies.
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> [] whitequark closed issue #1: Pip made me scared. Is wasmtime 0.20.0 incompatible? -
<_whitenotifier-f> [] whitequark commented on issue #1: Pip made me scared. Is wasmtime 0.20.0 incompatible? -
<_whitenotifier-f> [] whitequark commented on issue #2: What solvers come with yowasp? -
<_whitenotifier-f> [yosys] RobertBaruch opened issue #18: Pip made me scared. Is wasmtime 0.20.0 incompatible? -
<_whitenotifier-f> [yosys] RobertBaruch opened issue #19: What solvers come with yowasp? -
<whitequark> dub_dub_11: which other devices?
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to cxxsim [+3/-0/±4]
<_whitenotifier-f> [nmigen/nmigen] whitequark 74fce87 - [WIP] sim: add cxxsim engine.
jeanthom has joined #nmigen
Asu has joined #nmigen
<d1b2> <dub_dub_11> Well, the one I particularly have in mind is virtex-5 as that's what I have
<whitequark> yes, i think that would be manageable, perhaps even easier than S3E
<d1b2> <dub_dub_11> That is encouraging to hear
<d1b2> <dub_dub_11> I will give it a shot I think
<d1b2> <dub_dub_11> ISE looks like even more of a pain than quartus so using it through nMigen would be very nice indeed
<whitequark> yes indeed
_whitelogger has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
<Degi> Is there a way to change endianness based on 8 bit boundaries?
<whitequark> endianness doesn't really exist on HDL level
<d1b2> <OmniTechnoMancer> you slice your signal into 8 bit chunks and wire them as you please?
<whitequark> yeah
<d1b2> <OmniTechnoMancer> Can even do one endianness for each 16 bit piece and another for the two 16 bit pieces of your 32 bit value, for extra fun
<lkcl> Degi: you probably - might - mean, "how can i load - or store - some data and swap its byte endian-ness based on a dynamic selector"?
<lkcl> here is a convenient function which can do byte-reversal depending on either a static length *or* a dynamic length:
<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
<lkcl> def Signal32(*args, **kwargs): return Signal(*args, width=32, **kwargs)
FFY00 has quit [Ping timeout: 260 seconds]
<whitequark> yeah
<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
<whitequark> Degi: Liskov substitution principle
<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 -
<_whitenotifier-f> [nmigen] whitequark commented on issue #432: Add support for Display in simulation -
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 -
<_whitenotifier-f> [nmigen] nfbraun edited issue #519: Xilinx Zynq: generated bitstreams do not work with (recent?) FPGA manager -
patrickod has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 260 seconds]