<_whitenotifier-b>
[nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJ6Au
<_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 - https://git.io/JJ6Az
<_whitenotifier-b>
[nmigen-boards] whitequark closed pull request #95: resources: allow use of ULPI PHYs with active-low RST pins - https://git.io/JJgUB
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>
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
<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 - https://git.io/JJiVT
<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: 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
<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/bus.py:231: 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 - www.ntalk.de]
<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
<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_>
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 issuer.py 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 core.py
<lkcl_>
then you might have to do this back in your equivalent of issuer.py:
<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