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 10th
jeanthom has joined #nmigen
emeb has quit [Quit: Leaving.]
zl2cco has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
<_whitenotifier-b> [nmigen-boards] whitequark closed pull request #94: Add HADBadge (Hackaday Supercon Badge). -
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+1/-0/±0]
<_whitenotifier-b> [nmigen/nmigen-boards] ktemkin 6db14db - Add Hackaday Supercon19Badge.
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [nmigen/nmigen-boards] ktemkin 13b90ac - resources: allow use of ULPI PHYs with active-low RST pins
<_whitenotifier-b> [nmigen-boards] whitequark commented on pull request #95: resources: allow use of ULPI PHYs with active-low RST pins -
<_whitenotifier-b> [nmigen-boards] whitequark closed pull request #95: resources: allow use of ULPI PHYs with active-low RST pins -
samlittlewood has quit [Read error: Connection reset by peer]
samlittlewood has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
zl2cco has quit [Quit: Connection closed for inactivity]
<tannewt> if anyone has time I'm having trouble with my timer peripheral:
<tannewt> the bus waveforms look good but the timer never ticks down because I don't think my writes are working. I think values are supposed to be held in r_data
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
jeanthom has joined #nmigen
hitomi2507 has joined #nmigen
chipmuenk has joined #nmigen
<tannewt> welp, looked some more tonight and couldn't figure it out
<tannewt> (to run the example in that repo do `python -m systemonachip.peripheral.timer`)
<ktemkin> if you're still having issues tomorrow or so, let me know, and I can take a look
jeanthom has quit [Ping timeout: 246 seconds]
Asu has joined #nmigen
<d1b2> <edbordin> cr1901_modern I'm considering just shipping sby as-is on windows for now given the sample of test cases I picked all pass. not ideal that it can currently create runaway processes but it wouldn't be the first thing I've seen doing that on windows... anything I'm not considering here?
* whitequark sighs
<whitequark> fine, i'll fix that crap
jeanthom has joined #nmigen
<whitequark> though i'm sure cr1901 can manage to bind one function with ctypes
<d1b2> <edbordin> whitequark I deliberately did not ping you because I saw you were taking a break!
<d1b2> <edbordin> tbh I can probably manage the ctypes stuff myself
<d1b2> <edbordin> I was just figuring that once it's building nightly it will make its way to users once it's improved upstream anwyay
<d1b2> <edbordin> whitequark seriously though, if you'd rather that I wait until it's improved upstream, it can wait 2 weeks
<whitequark> i'm slightly annoyed that it's been in that state for years
<d1b2> <edbordin> in which case it can wait slightly longer 😛
<jeanthom> hi everyone!
peepsalot has quit [Remote host closed the connection]
peepsalot has joined #nmigen
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
Asu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
<d1b2> <edbordin> whitequark I started tinkering with a ctypes impl
<d1b2> <edbordin> (just in case you still felt the urge to fix shit)
<whitequark> edbordin: cool! ask away if you get stuck on something
<jfng> tannewt: your timer will work if you adjust the alignment of your csr multiplexer:
<d1b2> <edbordin> afaict enumerating all processes with is the only real way, lol. kernel32.CreateToolhelp32Snapshot
<d1b2> <edbordin> with this*
<d1b2> <edbordin> (or other alternative ways of enumerating the same thing)
DaKnig has left #nmigen ["WeeChat 2.9"]
DaKnig has joined #nmigen
cr1901_modern has quit [Ping timeout: 240 seconds]
<jfng> then you will have to write consecutively to 0x4 and 0x5 in order to complete the write operation
<jfng> tannewt: if your CSR bus has a data width of 8 bits and its addresses are aligned on 16 bits (data_width=8, alignment=1), and e.g. you have an 8-bit CSR at address 0x4
<jfng> s/CSR bus/CSR multiplexer
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
peepsalot has quit [Ping timeout: 240 seconds]
peepsalot has joined #nmigen
futarisIRCcloud has joined #nmigen
<Degi> Is there a reason why AsyncFFSynchronizer has 'domain' and FFSynchronizer has 'o_domain'?
<whitequark> no :/
<whitequark> just inconsistent
<Degi> Okay
<Degi> (Should I fix that?)
<whitequark> at least open an issue
<_whitenotifier-b> [nmigen] ECP5-PCIe opened issue #467: Inconsistency between a parameter name for AsyncFFSynchronizer and FFSynchronizer -
<FL4SHK> so I had previously been working on a CPU with a GCC port
<FL4SHK> but I didn't manage to create a Binutils port
<tannewt> jfng: ooooh! let me try it. thank you!
SpaceCoaster_ has quit [Quit: ZNC 1.7.2+deb3 -]
SpaceCoaster has joined #nmigen
<lkcl_> oleee! successful execution of the lixex BIOS using the libre-soc POWER9 prototype core written in nmigen!
<tannewt> 🎉
<tannewt> jfng: that got my timer going but my reads aren't yielding the value unfortunately
<jeanthom> lkcl_, congrats! does it work on an FPGA yet?
<lkcl_> jeanthom: that'll be the next thing to try out. i have a versa-ecp5 here
<jfng> tannewt: nice :) i'm currently at work, but i can take a closer look this evening if you're still blocked by then
<tannewt> jfng: kk. I should likely be working when you are back. I'm streaming in 5.5 hours too
<tannewt> definitely awesome to see the timer going :-)
<lkcl_> tannewt: nice to see you also do unit tests as part of modules, showing "how to use thing X" :)
<tannewt> heh, I just didn't know how to test if I had the registers hooked up right
<lkcl_> yehyeh, totally get it
<tannewt> I've very excited about the "SimulatedBus" clocking the simulation
<tannewt> it means we can write even higher level tests too
<lkcl_> tannewt: precisely because i can't understand what the code does (often even if i actually wrote it), we write these kinds of "howto" unit tests for eeeverything,
<lkcl_> they cascade up the hierarchy and we built up the confidence that each new layer worked reasonably well before moving on to the next
<lkcl_> i am astounded that it has been *industry-standard practice* for 30 years to only do top-level unit tests for processors!
<tannewt> ya, that's a really good practice
<lkcl_> i think it comes from the fact that nmigen is python, and it's "standard practice" to write unit tests for python because it's a dynamic language and you get into serious difficulties if you don't
<tannewt> heh, I write a lot of circuitpython drivers without tests. but testing against hardware is trickier
<whitequark> people write more unit tests in python because it's less of a pain in the ass
<tannewt> (I can't manage to get the `yield self._bus.r_data` to give me anything but zero)
<whitequark> not having unit tests in c++ code causes the same kind of problems but writing c++ unit tests is a pain in the ass so it doesn't happen as much
<whitequark> there's no deep reason
<tannewt> totally
<lkcl_> tannewt: what does the gtkwave look like?
<lkcl_> and is this a wishbone bus?
<tannewt> no, it's just a csr bus
<lkcl_> if so, you want theee... wishbone b4 spec... ah ok.
<tannewt> for muxing the registers together
<lkcl_> ok, because of the wildcard "import *" i have no idea what is being imported from where.
<lkcl_> you'll have to help me to help you, by letting me know which file "CSR bus" is in
<tannewt> peripheral/ sets up the csr mux
<lkcl_> ok thx 1 sec
<tannewt> so the test passes in a csr.Interface which should then be connected to the csr.Multiplexer for the peripheral
<tannewt> (will make peripheral add adapters as needed later)
<lkcl_> ok that's quite small i'm going to recursively-import everything :)
<tannewt> I do see the data in gtkwave but not yielding from my python
<tannewt> ya, 45 channels is not too bad
<tannewt> hence the test :-)
<lkcl_> which variable is it?
<lkcl_> signal sorry
<tannewt> trying to read back csr___r_data
<lkcl_> ok i see. so csr__r_stb goes 1 (for 1 cycle)
<tannewt> but I fixed the `bus` to `self._bus`
<tannewt> yup, then the value is on the bus the next cycle
<lkcl_> and csr__r_data i see gets set to 01 0f 07 ... on the _next_ cycle
<lkcl_> yehyeh
<lkcl_> ah. i know :)
<lkcl_> you're waiting 2 cycles
<lkcl_> so that's *two* cycles.
<lkcl_> and you're reading bus.r_data after *two* cycles - right at the point where the data drops back to zero
<lkcl_> so make it this:
<lkcl_> yield self._bus.r_stb.eq(1)
<lkcl_> yield
<lkcl_> yield self._bus.r_stb.eq(0)
<lkcl_> read_data = yield bus.r_rdata
<lkcl_> yield
<tannewt> this is what I have now
<tannewt> and none of the prints have data
<lkcl_> urr that's taking a long time to load
<tannewt> hrm, irccloud fail
<tannewt> I'm doing the yield where you suggest now
<lkcl_> ermm... ermermerm... i would have expected at least one of those print()s to "work"
emeb has joined #nmigen
<tannewt> me too
<lkcl_> mm ah one thing, you leave w_data "high" on the bus (line 133)
<tannewt> does `.eq` order matter?
<tannewt> when I connect things up
<lkcl_> no it doesn't. it matters on a "per clock"
<lkcl_> there was a bug in nmigen 2+ years ago where it "mattered", but it was a bug
<tannewt> oh, I don't connect r_data in the base peripheral
<lkcl_> ehn? :)
<lkcl_> oh whoops
<tannewt> oh, that made it unhappy
<tannewt> `/home/tannewt/repos/fpga/nmigen-soc/nmigen_soc/csr/ DriverConflict: Signal '(sig csr__r_data)' is driven from multiple fragments: top.peripheral, top.peripheral.csr_multiplexer; hierarchy will be flattened`
<tannewt> k, time for breakfast. I pushed what I have now. thanks for the help lkcl_
<tannewt> then onto real work
<lkcl_> :)
* lkcl_ needs a break too.
cr1901_modern has joined #nmigen
chipmuenk has quit [Ping timeout: 256 seconds]
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
chipmuenk has joined #nmigen
<DaKnig> is it well defined to assign a signed value to unsigned signals?
Asu has quit [Ping timeout: 240 seconds]
Asuu has joined #nmigen
<whitequark> ... we should add this to the cast operator discussion
<whitequark> because i don't think that right now it's actually defined anywhere properly
<whitequark> i mean
<whitequark> it happens to do some specific thing
<whitequark> but i think it's mostly a coincidence
hitomi2507 has quit [Quit: Nettalk6 -]
<DaKnig> it should imo behave like in C
<DaKnig> as in, -1 is short for "all bits set"
<DaKnig> also wq go back to your vacation :)
<whitequark> iirc right now it will always zero-extend
<DaKnig> should i put it in #464?
<tpw_rules> isn't that how python natively works? hex(-1) is -0x1
<whitequark> DaKnig: yes please
<tpw_rules> so no matter what you and it with all the high bits are set
<DaKnig> python has sign and size for signed numbers
<DaKnig> because 2s complement isnt very good with bignum
<DaKnig> bit difference between -0x1 and 0xff / 0xffff / 0xffffffff
<_whitenotifier-b> [nmigen] DaKnig commented on issue #464: [RFC] Shape Conversion Operators Round 2 -
jeanthom has quit [Ping timeout: 260 seconds]
<d1b2> <emeb> question: given a module (with possible lower-level modules) that uses the default sync domain, how do I connect that sync domain to something other than the default sync domain in the higher level when instantiating it?
<whitequark> DomainRenamer
<emeb> thx
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
Asuu has quit [Quit: Konversation terminated!]
chipmuenk has quit [Ping timeout: 244 seconds]
<lkcl_> i really like DomainRenamer
<lkcl_> jeanthom helped me to put something together that uses it, a few days ago
<lkcl_> emeb:;a=blob;f=src/soc/simple/;h=168f389f0d57c4800e99c07f6218683607ac9011;hb=HEAD#l76
<emeb> lkcl_: Oh thanks - was hoping for a good example to study.
<lkcl_> note line 94 is really important
jeanthom has joined #nmigen
<lkcl_> i put that together from the power-on-reset example
<lkcl_> but decided to disable the actual "reset delay" part for now. it does actually work
<lkcl_> strictly speaking i should also have DomainRenamed the "memory" submodule as well
<awygle> i was pretty skeptical of domainrenamer originally but it does work quite nicely
<lkcl_> but obviously not the debug module because (doh) that's what you use to externally control the "reset" of the main core from
<lkcl_> awygle: yeah.
<lkcl_> initially i thought, "argh argh i have to change all code pervasively to add a global clock and reset"
<lkcl_> emeb: oh, i almost forgot. the other important bit is this:
<emeb> lkcl_: cool
<lkcl_> if you're looking to do any kind of "external debug module controls the reset of the core" kind of thing
<emeb> not an issue in the current application, but good to know for future.
<lkcl_> which, back in line 137 core_reset_i is set from the debug module
<lkcl_> if you don't do anything i'm not sure what happens having done the "DomainRenamer" is what i mean
<lkcl_> so if you don't do that "ResetSignal().eq(self.core_reset_i)" thing that i do in
<lkcl_> then you might have to do this back in your equivalent of
<lkcl_> comb += core_sync.clk.eq(ClockSignal())
<lkcl_> comb += core_sync.rst.eq(ResetSignal())
<lkcl_> if you don't, then when you convert to ilang (or verilog) you will find a signal called "core_sync_rst" is in the verilog file and it's floating and *unconnected*
<lkcl_> that "core_sync.rst.eq(ResetSignal())" will grab the global "rst" signal from the *current* module and explicitly connect the new domain (core_sync) reset to it
<lkcl_> if that makes any sense?
jeanthom has quit [Ping timeout: 240 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]