<whitequark>
but if you modify it after you index into it, you silently get a big
<whitequark>
*bug
<whitequark>
rjo: IMO Array should inherit from collections.abc.MutableSequence, and disallow mutation after being indexed into once
<whitequark>
opinion?
<sb0>
whitequark: pong
<whitequark>
sb0: already figured it out (bit width of <</>> result)
<sb0>
whitequark: so when there is a FSM, what gets flattened eactly?
<whitequark>
sb0: FSM into its parent submodule
<whitequark>
the reason is that e.g. in an UART I have a timer that ticks independently but is reset from the FSM
<whitequark>
so, both UART container module and TX FSM drive that signal
<whitequark>
this is now automatically detected and resolved for all cases, with three selectable levels: silent, warn, error (on conflict)
<whitequark>
default is warn
<whitequark>
/home/whitequark/Projects/Glasgow/software/glasgow/gateware/uart.py:231: DriverConflict: Signal '(sig tx_timer)' is driven from multiple fragments: top.dut, top.dut.tx_fsm; hierarchy will be flattened
<whitequark>
tx_timer = Signal(max=bit_cyc)
<whitequark>
looks like this
<sb0>
because otherwise each FSM would have its own module?
<whitequark>
yes, because compat FSMs are submodules
<whitequark>
it's just the old migen implementation
<sb0>
okay, but with the "new" FSM this isn't the case?
<whitequark>
the new FSM will lower directly to the yosys $fsm cell
<whitequark>
it is not a submodule, although the details are a bit fuzzy
<whitequark>
it works more like an instance
<sb0>
can that be exported to verilog in a nice way?
<whitequark>
should be
<whitequark>
if not I'll just expand it in a pass
<whitequark>
sb0: btw I am implementing arrays now, any wishes?
<whitequark>
other than fixing the hazard with mutation
<sb0>
not really
<sb0>
by mutation you mean changing the array itself? I guess there is no way to prevent mutation in the elements of the array to
<whitequark>
of course there is
<whitequark>
inherit from collections.abc.MutableSequence and forward 4 methods
<whitequark>
to the actual array inside
<whitequark>
then, once you create the first proxy, flip a flag.
<sb0>
but if you have a reference to some object that becomes part of the Array, you can still mutate that object via the reference, right?
<whitequark>
what I wanted to do is to make ArrayProxy lazy
<whitequark>
but not completely lazy
<whitequark>
it would check that __getattr__ or __getitem__ succeeds
<whitequark>
and then remember the path
<whitequark>
now there is only a hazard of substituting an incompatible object by mutating an array element
<sb0>
you need python 3.7 for nmigen?
<whitequark>
it's like one function, but I haven't bothered to change it
<whitequark>
3.6 is definitely doable
<whitequark>
3.5 might be not doable if we decide to go with asyncio in the simulator
<whitequark>
because 3.6 introduces async generators
<sb0>
3.7 should be fine, just checking
<sb0>
python asyncio is slow and a bit messy
<whitequark>
so I've been using asyncio and migen simulator together extensively in glasgow
<whitequark>
it is really useful
<sb0>
what does asyncio bring to the simulator that generators/"yield from" don't?
<sb0>
convenient syntax additions and some error checking?
<whitequark>
no
<whitequark>
error checking is already done in back.pysim
<whitequark>
nmigen pysim should never give you an obscure error with a broken backtrace now.
<whitequark>
actually it will interleave frames of pysim and user generator
<sb0>
oh I mean stupid errors like "x = foo()" instead of "x = yield from foo()"
<whitequark>
ah, no
<whitequark>
you would still use yield and yield from for migen simulator
<whitequark>
but you could *also* use asyncio
<whitequark>
so in glasgow, imagine there is an SPI applet that talks to the SPI core in the device via a FIFO
<whitequark>
when running the applet, it is done by an asyncio wrapper around python-libusb
<whitequark>
but when simulating this together, you do not want to change the applet just for simulation
<whitequark>
so, it is good if in the same function, you can interleave calls to asyncio that put data into the "host" side of FIFO, and calls to migen simulator that pull data from "device" side of FIFO
<whitequark>
verilator module style
<whitequark>
this way, you can run e.g. actual SPI flash applet code against the actual applet gateware, and see it all in gtkwave, with zero sim specific changes
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 246 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
<whitequark>
sb0: what is the intended behavior of a 3-element array proxy being indexed with index 3?
<whitequark>
I am tempted to make it output x's
<_whitenotifier-4>
[m-labs/nmigen] whitequark pushed 3 commits to master [+5/-5/±4] https://git.io/fpNLC