sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
shenki has left #m-labs [#m-labs]
<sb0> it even tells you how to build that pump
bentley` has quit [Ping timeout: 256 seconds]
<sb0> _florent_, the GTH transceiver user guide still says "When RX buffer bypass is used, RXSLIDE_MODE cannot be set to AUTO or PMA."
<sb0> I wonder if the Xilinx garbage actually breaks down completely when you do that, or if it simply glitches RXUSRCLK when you slide and Xilinx don't want users dealing with glitched clocks in gateware
<sb0> I'm worried that the bruteforce clock aligner might not work so well with a serialization ratio of 40
<sb0> maybe we can do partial transceiver resets to speed it up
<cr1901_modern> sb0: What good are partial transceiver resets for? (I haven't used GTH/X/P)
<sb0> realigning he
<sb0> realigning the divided (word) clock
<sb0> properly designed clock dividers have an input that makes them add or remove one cycle, but xilinx GTs are very far from this
<cr1901_modern> So resetting to a known state is an alternative to "nudge" the clock in the desired direction?
<sb0> resetting to an unknown state. the xilinx divider gives you a random phase every time.
<cr1901_modern> Huh... that sounds counterintuitive. What happens if the new random phase is even more misaligned than before? Reset again?
<sb0> the GT is one of the most imbecilic chip design I've seen in a long time, it's almost FTDI chip level
<sb0> yes, reset until it behaves
<cr1901_modern> Ewww
<cr1901_modern> Btw, you don't seem to have much praise to give to Xilinx ;). Maybe you should switch to Altera :)!
<sb0> from a cursory look at the altera transceiver datasheets, it seems to be similarly messed up. and I don't have high hopes for Intel (x86, ACPI, USB, etc.)
<sb0> IME
<cr1901_modern> Fair enough, I wasn't seriously suggesting switching either. Just amused (and sympathize) that FPGA internal blocks seem to be poorly designed.
<sb0> I heard recently that Intel USB controllers poll the SDRAM via DMA for new transfer requests from the CPU, because this is a perfectly legitimate way to use SDRAM bandwidth
<sb0> a "scan SDRAM now" CSR would have solved the problem, but no
<cr1901_modern> I don't know enough about how this works to comment. (Why woud they poll SDRAM for a transfer request that is presumably sent to a *device* register?)
<cr1901_modern> Oh wait, I think I misread
<cr1901_modern> xfer requests for the USB controller are sent to SDRAM as a temp buffer, and the USB will *scan the SDRAM for xfer requests* without prompting from the CPU?!
rjo has quit [Ping timeout: 258 seconds]
rjo has joined #m-labs
kuldeep has quit [Remote host closed the connection]
kuldeep has joined #m-labs
<sb0> yes
<sb0> or so I heard
bentley` has joined #m-labs
FabM has joined #m-labs
<sb0> is there any vector graphics that does not suck? libreoffice doesn't support resizing page to contents, and inkscape segfaults when attempting the same
<sb0> linux on the desktop, sure!
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
sb0 has quit [Quit: Leaving]
<kyak> ghostscript, maybe :)
hedgeberg is now known as hedgeberg|away
kuldeep has quit [Read error: Connection reset by peer]
kuldeep_ has joined #m-labs
early has quit [Quit: Leaving]
early has joined #m-labs
kuldeep_ has quit [Quit: Leaving]
sb0 has joined #m-labs
kuldeep has joined #m-labs
whitequark has quit [Ping timeout: 245 seconds]
whitequark has joined #m-labs
<cr1901_modern> sb0: Which version? I've inkscape for raster images that are 600MB+ in size, and resize page to contents works fine.
<cr1901_modern> I mean, I agree with it, but just wondering
<whitequark> cr1901_modern: no?
<GitHub> [pythonparser] alanjds opened pull request #13: Accept to parse sources not ending with '\n' (master...accept-eof-source) https://github.com/m-labs/pythonparser/pull/13
<GitHub> [pythonparser] alanjds opened pull request #14: Implementation of .lineno as a property of .loc (master...lineno-property) https://github.com/m-labs/pythonparser/pull/14
<GitHub> [pythonparser] alanjds opened pull request #15: Allow positional __init__ attributes on the AST classes (master...position-construction) https://github.com/m-labs/pythonparser/pull/15
<cr1901_modern> whitequark: Again just wondering. Tbh, I thought --gc-sections was always enabled.
<GitHub> [pythonparser] alanjds opened pull request #16: pythonparser.compat_ast as a tested drop-in replacement of stdlib ast (master...compat_ast) https://github.com/m-labs/pythonparser/pull/16
<whitequark> cr1901_modern: no, because it could cause misbehavior when not all roots are visible to the linker
<whitequark> sections with interrupts, maybe
Gurty has quit [Ping timeout: 240 seconds]
hedgeberg|away is now known as hedgeberg
<cr1901_modern> whitequark: Maybe b/c it references a global variable, but my ISR wasn't eaten by gc-sections
raghu has joined #m-labs
<raghu> bb-m-labs: force build --props=package=artiq-kc705-nist_qc2 artiq-board
<raghu> bb-m-labs: force build --props=package=artiq-kc705-nist_qc2 artiq-board
<bb-m-labs> build forced [ETA 15m43s]
<bb-m-labs> I'll give a shout when the build finishes
<raghu> I guess that extra space in the beginning mattered!
<raghu> Was about to look at the delays between kernels on Windows
raghu has quit [Client Quit]
Gurty has joined #m-labs
<bb-m-labs> build #405 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/405
balrog_ has joined #m-labs
balrog has quit [*.net *.split]
ohsix has quit [*.net *.split]
ohsix has joined #m-labs
balrog_ is now known as balrog