futarisIRCcloud has quit [Quit: Connection closed for inactivity]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 250 seconds]
m4ssi has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 250 seconds]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 258 seconds]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 272 seconds]
_whitelogger has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 258 seconds]
<sb0>
whitequark: did you change the behavior of out-of-bounds Array access in migen?
<whitequark>
sb0: migen or nmigen?
<GitHub-m-labs>
[artiq] jordens commented on issue #1225: Filing multiple clearly distinct issues in parallel is just fine IMO. There is no technical reason why that would be problematic. But please do follow up. https://github.com/m-labs/artiq/issues/1225#issuecomment-451481983
<GitHub-m-labs>
artiq/master a93fdb8 Sebastien Bourdeauducq: drtio: disable all destinations in gateware at startup...
<whitequark>
sb0: i haven't touched migen at all
<whitequark>
and i have no plans to, it doesn't have comprehensive tests and nmigen is compatible with it anyway
<sb0>
i wonder why vivado treats clocks as related and paths subjected to synchronous timing analysis by default
<sb0>
could be a xilinx way to flag unintended async paths, i.e. when you have one, it screws up the P&R by making it work too hard on paths that will never meet timing but don't have to, and then only reports it when P&R failed timing, or reports that another part of the design failed timing
mauz555 has joined #m-labs
<cr1901_modern>
I can think of a reason: If a second clock is generated from a first clock an on-chip, the tools can analyze whether it's safe to skip the CDC circuitry by analyzing worst-case jitter tolerances and setup/hold time margins
<cr1901_modern>
At the very least, I've relied on this in ISE before :P
<whitequark>
if you generate one clock from another in fabric then they are clearly and explicitly related
<whitequark>
so you don't need such heuristics
<cr1901_modern>
Setup/hold time violations could be possible due to jitter
<cr1901_modern>
at fast speeds
<whitequark>
isn't this what would be caught if you make them related?
<whitequark>
you analyze the path in fabric to see the phase difference
<cr1901_modern>
Oh, I don't understand what you mean by "so you don't need such heuristics"
<cr1901_modern>
ENOSLEP
<cr1901_modern>
Does artiq gateware use multiple clock domains where a dest clk domain is related to src (on-chip generated) _and_ a dest clk domain which is unrelated to src?
<GitHub-m-labs>
[artiq] drewrisinger opened pull request #1226: pyon: fix grammar in module docstring. (master...dr-pr-pyon-1) https://github.com/m-labs/artiq/pull/1226
<GitHub-m-labs>
[artiq] drewrisinger opened pull request #1227: artiq_flash: change docs from old `-m` arg to `-V` (#1224) (master...dr-pr-docs-flash-1) https://github.com/m-labs/artiq/pull/1227
<GitHub-m-labs>
[artiq] drewrisinger commented on issue #1219: I'm unsure how to do such a test. Are there pre-existing unit tests that will test those? I don't have the knowledge of all the dependencies needed to write such a test. https://github.com/m-labs/artiq/issues/1219#issuecomment-451510795
<GitHub-m-labs>
[artiq] drewrisinger opened pull request #1228: Docs: instructions to check if in plugdev group (master...dr-pr-docs-plugdev) https://github.com/m-labs/artiq/pull/1228
m4ssi has quit [Remote host closed the connection]
<GitHub-m-labs>
[artiq] drewrisinger commented on issue #1196: I used 16 MB for asyncio_server and that worked for my data. Think this is highly data-dependent, and I don't have a good handle on when it's worth increasing the limit vs moving to a different non-PYON protocol. The raw data that the numpy array was constructed from was ~2-4 MB of text, so it makes sense that 4 MB was too tight. https://github.com/m-labs/artiq
<adamgreig>
whitequark: am I right in assuming I can't use an nmigen module in a migen design, but can the other way around, i.e. I should port top-down rather than bottom-up?
<whitequark>
correct
<adamgreig>
thanks
<adamgreig>
have there been any thoughts on build and platform replacements? especially around constructing pin mappings etc
<whitequark>
not that part, not yet
<whitequark>
build will likely use edalize
<adamgreig>
is the best bet for platform pins to just have them all as ports on top and then provide a pcf separately?
<whitequark>
this is used for ice40 iirc because arachne was bad at something
<whitequark>
but normally migen uses synthesizable verilog
<adamgreig>
right, ok
<GitHub-m-labs>
[artiq] drewrisinger commented on pull request #1185 a3711a4: This should be caught using argparse's ``choices`` kwarg, so removed entirely. If you don't want that, suggest what error message would be better.... https://github.com/m-labs/artiq/pull/1185#discussion_r245418818
<GitHub-m-labs>
[artiq] drewrisinger commented on pull request #1185 a3711a4: This should be caught using argparse's ``choices`` kwarg, so removed entirely. If you don't want that, suggest what error message would be better.... https://github.com/m-labs/artiq/pull/1185#discussion_r245418818
<GitHub-m-labs>
[artiq] drewrisinger commented on issue #1185: I have made all explicitly asked changes. The docstrings that @sbourdeauducq called out above are recommended by `pydocstyle` because they are publicly available functions and so should be documented. ... https://github.com/m-labs/artiq/pull/1185#issuecomment-451567253
<adamgreig>
whitequark: given some pin name like clk25 in the pcf, how can I assign that to drive the sync clockdomain's clk? it seems like the cd doesn't exist until the fragment is made, at which point it's too late to add to the comb domain?
<whitequark>
ClockSignal().eq(clk25)
<bb-m-labs>
build #2783 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2783 blamelist: Drew Risinger <drewrisinger@users.noreply.github.com>
<adamgreig>
whitequark: should I be able to assign to that? TypeError: Value (clk sync) cannot be used in assignments
<adamgreig>
(that's m.d.comb += ClockSignal().eq(self.clk25) in Top's get_fragment, where Top.clk25 is a Signal() and is in ports passed to rtlil.convert
<whitequark>
adamgreig: oh right there's an open bug