<_whitenotifier-a>
[nmigen] whitequark commented on issue #184: ASIC support tracking issue - https://git.io/fjNnA
_whitelogger has joined #m-labs
whitequark has joined #m-labs
_whitenotifier has joined #m-labs
<_whitenotifier>
[nmigen] programmerjake commented on issue #183: Signal(reset=x) should be equivalent to Signal(reset=x, max=x+1) - https://git.io/fjNcP
<_whitenotifier>
[nmigen] programmerjake commented on issue #184: ASIC support tracking issue - https://git.io/fjNc1
<_whitenotifier>
[nmigen] whitequark commented on issue #183: Signal(reset=x) should be equivalent to Signal(reset=x, max=x+1) - https://git.io/fjNcM
<_whitenotifier>
[nmigen] programmerjake commented on issue #183: Signal(reset=x) should be equivalent to Signal(reset=x, max=x+1) - https://git.io/fjNch
<_whitenotifier>
[nmigen] programmerjake commented on issue #183: Signal(reset=x) should be equivalent to Signal(reset=x, max=x+1) - https://git.io/fjNCv
<_whitenotifier>
[nmigen] whitequark commented on issue #183: Signal(reset=x) should be equivalent to Signal(reset=x, max=x+1) - https://git.io/fjNCJ
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<whitequark>
I'm not sure I understand what's happening
<whitequark>
it seems like someone is trying to write point-free code in python?
sb0 has quit [Quit: Leaving]
jaeckel has quit [Ping timeout: 245 seconds]
jaeckel has joined #m-labs
<whitequark>
yeah, looking closer, i don't think there's anything super interesting going on, it's just a somewhat obfuscated way to write code
mumptai has joined #m-labs
Ultrasauce has quit [Quit: Ultrasauce]
Ultrasauce has joined #m-labs
sb0 has joined #m-labs
<sb0>
yeah, that was also my impression
<_whitenotifier>
[nmigen] programmerjake commented on issue #183: Signal(n, reset=x) silently drops any bits in x past the n-th bit - https://git.io/fjNlh
<zignig>
woohoo ! , finally got the serial bootloader to bootload ! , line endings in python serial SUCK!
<zignig>
now for some cleanup.
<_whitenotifier>
[nmigen] whitequark commented on issue #183: Signal(n, reset=x) silently drops any bits in x past the n-th bit - https://git.io/fjN8q
<whitequark>
zignig: don't forget to turn off XON/XOFF
<whitequark>
this can mangle your data badly
mumptai has quit [Quit: Verlassend]
<zignig>
did that ;) , it was that the \r as not getting encoded and sent as two char.
<whitequark>
yeah also a problem.
<whitequark>
i should be able to look at directives soon-ish maybe.
<zignig>
but managed to upload and run blinky via the bootloader.. :)-|-< :0-/-< :)-\-< (happydance)
<whitequark>
nice.
<zignig>
whitequark: that would be grand.
<whitequark>
btw... i had this idea about reusing the logic in boneless to stuff the (eg) SPRAM full of bytes
<whitequark>
sort of like a debug port
<whitequark>
so you could in the future maybe connect it directly to UART.
<zignig>
like JTAG , will it be able to set/put memory whilst the processor is running ?
<whitequark>
actually a JTAG core for Boneless is something I also want to do but later.
<zignig>
speaking of which , I have a WARMBOOT that is attached to external address in the boneless.
<zignig>
how would I go about having another signal _also_ driving it ?
<whitequark>
mux?
* zignig
is thinking reduce(_or,[signals...]) but i'm not sure.
<whitequark>
reduce(or) works but has different behavior.
<whitequark>
uh. I forget how WARMBOOT works.
<zignig>
I want to have a wrapper around the uart that issues the warmboot, so if the program crashes , remote recovery is possible.
<whitequark>
so you want the BOOT signal to be triggered by something else?
<whitequark>
what about S0/S1?
<zignig>
need all three , I'll need an FSM because it needs to be sequenced.
* zignig
investigates mux driving
<zignig>
whitequark: thanks :)
<lkcl>
whitewuark: ping. do you remember that add_clock exception that occurred in run_simulation, last week? i encountered another scenario, this time nothing to do with run_simulation. it's a combinatorial block that causes the issue. solution: "if "sync" in sim._domains: sim.add_clock(...)"
<lkcl>
clearly, that's not really a "solution" as it bypasses the API (underscore)
<whitequark>
lkcl: hm, interesting
<lkcl>
versions of nmigen from... 2 months ago (appx?) this was fine
<lkcl>
the problem for us is: we've got auto-generated code that will be comb or sync depending on parameters, in the unit tests.
<lkcl>
yeh.
<whitequark>
so you have a purely combinatorial circuit and it fails sim?
<lkcl>
it doesn't fail sim, the add_clock that was added into run_simulation fails with a key exception
<lkcl>
sim._domains 'key "sync" not found'
<whitequark>
you know you shouldn't use nmigen.compat for new code right?
<lkcl>
because... it's a combinatorial block.
<whitequark>
or are you not using it
<lkcl>
i waited until i found a unit test that wasn't
<lkcl>
that's interesting. the "add_clock" exception is back
<lkcl>
File "/home/lkcl/src/libreriscv/ieee754fpu/src/ieee754/part_mul_add/test/test_multiply.py", line 635, in subtest_file
<lkcl>
sim.add_clock(2e-6)
<lkcl>
File "/home/lkcl/src/libreriscv/nmigen/nmigen/back/pysim.py", line 457, in add_clock
<lkcl>
.format(domain))
<lkcl>
ValueError: Domain 'sync' is not present in simulation
<whitequark>
yes.
<lkcl>
argh.
<whitequark>
that's what it was *supposed* to do.
<whitequark>
now...
<lkcl>
ok that doesn't really help, as we need to be able to run simulations on combinatorial blocks... *and we don't know whether the code generated will be combinatorial or synchronous*
<lkcl>
or... we can, but it'll be a pain in the neck to find out
<lkcl>
what did you have in mind?
<lkcl>
btw the code that jacob wrote (that this applies to) is absolutely awesome - it's a dynamic (runtime) partitionable SIMD multiply engine.
<lkcl>
and we'll be putting in "transparent latches" that actually change the length of the pipeline *at runtime*
<lkcl>
utterly cool :)
<whitequark>
so you could do two things
<whitequark>
one, you could add `except ValueError: pass`.
<whitequark>
other, you could do `f = Fragment.get(module, platform=None)` and then do `"sync" in f.drivers`
<whitequark>
which is a way to do the same thing via the public API as you're doing right now.
<lkcl>
ok. yeah that'd do the trick.
<lkcl>
the first is a hack. the second's pretty clean.
<lkcl>
yeah that does the trick - nice. thanks
<whitequark>
you might have to recurse through submodules for a hierarchical design though
<lkcl>
we've a huge tree, it seems to work fine.
<whitequark>
if you don't have any m.d.sync at toplevel it will falsely report there's no clock
<lkcl>
i'm slightly fearful (for my high-resource laptop) of what happens when we start putting together an actual CPU from all these blocks :)
<lkcl>
ah ok.
<whitequark>
well... this actually is a good enough reason to add first-class support for this.
<whitequark>
hang on.
<lkcl>
hm i'll let one of the other unit tests run, just to check
<_whitenotifier>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fjNBr