<kc5tja>
It's almost as if m.domains += xyz *replaces* its collection of domains with xyz, rather than appending/inserting into the collection that's already there.
<kc5tja>
(I'll be turning in for the evening shortly; feel free to leave a response here, and I'll check logs tomorrow. Once again, thanks for your time, whoever you may be! :) )
proteusguy has joined #m-labs
kc5tja has left #m-labs [#m-labs]
Rednaxela has joined #m-labs
<Rednaxela>
Hmm... so starting to try to synthesize a slightly nontrivial design for the first time with the combination of migen+yosys+nextpnr... and I'm getting a multiple drivers issue for one of the fsm state signals... and in the intermediate verilog I see the problem... but having a hard time seeing anything I might have done in the python code to cause migen to generate multiple drivers on a fsm state...
<Rednaxela>
Oh... huh... nevermind... seems the extra driver was way elsewhere in the system... wasn't directly the fsm state that was multiply driven but apparently some multiply driven things did propagate due to yosys rearranging things, causing that to be what errored
m4ssi has joined #m-labs
<_whitenotifier-e>
[m-labs/nmigen] sbourdeauducq pushed 1 commit to master [+0/-0/±1] https://git.io/fhcFG
<GitHub-m-labs>
[artiq] jordens commented on pull request #1244 66b1bfb: Not saying that this is wrong, just trying to understand the rationale: Is the reason that you use 31 here just that it makes both interpreting it as a u32 and upcasting to i64 difficult?... https://github.com/m-labs/artiq/pull/1244#discussion_r247805521
<GitHub-m-labs>
[artiq] hartytp opened pull request #1247: issue template: remind users to update the docs (master...master) https://github.com/m-labs/artiq/pull/1247
<adamgreig>
kc5tja: you need to add sync yourself if you add any other domains too, it's only added automatically if there are no other (non-comb) domains
<GitHub-m-labs>
[artiq] klickverbot commented on pull request #1244 05f6daf: I'm using 31 bits by default just since using 32 bits is unattractive for user code anyway (have to deal with signedness/extend to i64), and this way we have the extra sign bit to play with in a backwards-compatible fashion in the future (re saturating behaviour vs. wrapping, etc.).... https://github.com/m-labs/artiq/pull/1244#discussion_r2478
<_whitenotifier-e>
[nmigen] jordens commented on issue #9: Bikeshed: design for .get_fragment() - https://git.io/fhCu8
<_whitenotifier-e>
[nmigen] whitequark commented on issue #9: Bikeshed: design for .get_fragment() - https://git.io/fhCuK
<_whitenotifier-e>
[nmigen] adamgreig commented on issue #9: Bikeshed: design for .get_fragment() - https://git.io/fhCuy
m4ssi has quit [Quit: Leaving]
<_whitenotifier-e>
[nmigen] jordens commented on issue #9: Bikeshed: design for .get_fragment() - https://git.io/fhCzF
<whitequark>
rjo: sb0: can any of you explain to me the semantics of fwft in migen in detail?
<whitequark>
annoyingly, it's not documented, and I am having trouble documenting it
<whitequark>
it seems to me that non-FWFT mode of SyncFIFO does not match FIFOInterface documentation, or perhaps FIFOInterface is underspecified
whitequark has quit [Quit: Reconnecting]
whitequark has joined #m-labs
<whitequark>
sb0: rjo: specifically, it looks to me like SyncFIFO's non-FWFT mode will signal readable without valid data on dout
rohitksingh has joined #m-labs
<sb0>
whitequark: yes it will, that's how a non-first-word-fall-through FIFO works
<whitequark>
that directly contradicts the docs in FIFOInterface then.
<whitequark>
readable : out
<whitequark>
Output data `dout` valid, FIFO not empty.
kc5tja has joined #m-labs
<kc5tja>
adamgreig: Thank you! I wasn't aware of that requirement. I'll be sure to include that in the updated docs.
mumptai has joined #m-labs
<whitequark>
yeah, the more I look at this, the more I think FWFT is a property of the FIFO *interface*, not implementation
<adamgreig>
whitequark: I found I had to add a bunch of ports manually to prevent weird things being inferred, but it's probably because i'm using nmigen wrong, and specifically might be because I'm passing pads as signals from the top-level object as parameters into my classes which use them in modules, rather than using comb statements at every layer to connect things
<adamgreig>
so each layer needs to say that this pad is an output, and then it works (tm)
<kc5tja>
I'm having a new challenge at the moment. I have two modules which use clock domain pix, and a top-level module which intends to drive pix_clk. What is the proper way to do this?
<adamgreig>
but I guess the solution is to not pass any signals as parameters to classes, and only have classes make their own signals which i connect to with comb statements
<kc5tja>
I've tried the obvious approach where I create a ClockDomain() object for pix, but then attempt to drive it with pix.clk.eq(my_synthesized_clock_here).
<kc5tja>
However, this doesn't seem to work. Verilog still exposes all submodule clocks for pix in the interface for top, and doesn't connect the locally generated clock to the submodules.
<kc5tja>
I'm guessing now that it's wrong to declare the pix ClockDomain() in the top module, and just rely on combinatorial statements to bind my synthesized clock to submodule clock inputs explicitly?
<adamgreig>
was just mucking with something and didn't delete it
<whitequark>
it's still there
<adamgreig>
ugh. there we go
<whitequark>
sure. you should pass `ports=...` to rtlil.convert
<whitequark>
with the complete list of inputs and outputs
<whitequark>
this will become required soon
<adamgreig>
and that's different to calling frag.add_ports(...) on L35 (the frag from top.get_fragment())?
<adamgreig>
it would be nice if the platform or something inside top could do that, since that's what knows about what inputs and outputs it has
<adamgreig>
ok, I guess I was mixing up fragment.add_ports and ports= on convert, will see if that resolves all my issues
<adamgreig>
at the least I can have my platform return a list of all the ports it gave out
<whitequark>
yes, that's the idea
<whitequark>
the platform will do that
<adamgreig>
will the platform also be responsible for calling rtlil.convert()?
<adamgreig>
right now my platform knows all the ports you request()d and returns a pcf file and list of ports to my main(), which just calls frag.add_ports instead of putting it in the rtlil call
<adamgreig>
ok, this makes a lot more sense to me now, thanks
<whitequark>
platform would call rtlil.convert too, yes
<whitequark>
the entire build process
Gurty has joined #m-labs
Gurty has quit [Changing host]
Gurty has joined #m-labs
X-Scale has joined #m-labs
<adamgreig>
whitequark: thanks, rejigged to put ports in the convert call and nowhere else and it all works fine
<adamgreig>
much better
<adamgreig>
and moved building into my platform instead of a makefile so that's nice too
_whitenotifier-c has joined #m-labs
<_whitenotifier-c>
[nmigen] cr1901 opened pull request #25: Support for yosys' $anyconst and $anyseq cells - https://git.io/fhWLD