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
fengling_ has quit [Quit: WeeChat 1.1.1]
fengling has joined #m-labs
early has quit [Quit: Leaving]
early has joined #m-labs
fengling has quit [Ping timeout: 246 seconds]
fengling has joined #m-labs
tija has joined #m-labs
<GitHub9> [migen] enjoy-digital pushed 1 new commit to master: http://git.io/vtxxT
<GitHub9> migen/master 7afa3d6 Florent Kermarrec: mibuild/xilinx: Xilinx's FPGAs do not necessary share the same primitives: add xilinx_s7_special_overrides and specific XilinxDDROutputS7 implementation...
_whitelogger has joined #m-labs
<GitHub147> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vtpIo
<GitHub147> artiq/master 74f0709 Sebastien Bourdeauducq: test/coredevice: fix timestamp conflict
<cr1901_modern> rjo: "I suspect that the solution here is to reaffirm that migen does not guarantee syntactictally valid verilog." My question is: Should it guarantee valid verilog or not?
<sb0__> cr1901_modern: what is the problem you are having? something involving Cat, slices and bidirectional IO signals I guess?
<cr1901_modern> Of course! :D Workaround that works for my purposes: https://github.com/m-labs/migen/issues/20#issuecomment-112254542
<cr1901_modern> I was just commenting on rjo's comment.
<sb0__> ah
<cr1901_modern> I think we figured out that Migen in fact generates syntactically valid Verilog, but Xilinx's compiler chokes on it anyway
<sb0__> it would be nice if we could get correct verilog in all cases, but verilog is fucked and fixing all those little details requires massive effort
<sb0__> alternatively, we could also throw away all that verilog crap and synthesize the netlist directly from the fhdl representation
<cr1901_modern> I was going to ask if that was the next logical step
<sb0__> I'm not sure if the problem here is in the verilog standard or the xilinx compiler
<sb0__> do simulation tools work with that code?
<cr1901_modern> I can't say that I've checked iverilog.
<cr1901_modern> I'll have an answer for you in 5 minutes tho
<cr1901_modern> iverilog chokes on the code as well
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#275 (master - 74f0709 : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
<cr1901_modern> I think I might've also found a bug in iverilog as well XD. The line numbers that errors are reported on are off by the number of line comments in the file.
tija has quit [Quit: Connection closed for inactivity]
<sb0__> ysionneau: what is the status of the serdes-rtio? ready for merge? anything you are stuck on?
<sb0__> ysionneau: I would pass the SERDES module as an argument to the Input and InOut modules
<sb0__> also it should be InOut, not Inout
<sb0__> er, no
<sb0__> I thought it was InOut in ttl_simple but no
tija has joined #m-labs
cr1901_modern1 has joined #m-labs
<ysionneau> sb0__: the serdes-rtio is behaving correctly in the tests
<ysionneau> in the two directions
<sb0__> ysionneau: there should not be that much code duplication between Output and Inout (including in the SERDES modules)
<ysionneau> but before merging that would need testing with real hardware ... and I guess debugging of the "i/oserdese2" part
<sb0__> also, some minor style issues
<ysionneau> ok
<ysionneau> you want to start with a review so that I fix all this?
<sb0__> I would also structure that differently to enable future support for other FPGA families
cr1901_modern has quit [Ping timeout: 252 seconds]
<ysionneau> oh
<ysionneau> the current split into 1 file per FPGA famiy is not OK?
<ysionneau> family*
<sb0__> create a module ttl_serdes_generic that contains Output, Inout, the fake SERDESes and the test benches
<sb0__> Output and Inout take SERDES modules, not pads
<ysionneau> oh, I see
<sb0__> and then a module ttl_serdes_7series that also define Output and Inout, but those take pads, insert a SERDES module and forward that to ttl_serdes_generic
<ysionneau> so IIUC ttl_serdes_7series defines for instance Ouput , and in this module it instanciates the ttl_serdes_generic's Output module, right?
<sb0__> yes, and adds it as its submodule
<sb0__> also, the Output code should definitely be shared in Inout, and ditto with OSerdese2/IOSerdese2
key2 has joined #m-labs
<sb0__> if that's too complicated, we can drop Output, since this is just a FPGA resource optimization
<ysionneau> Ok
<sb0__> but it would be really nice to have... also you don't have to call output() on those
<sb0__> oh and add monitor/injection support.
<sb0__> for this, do not take the fine timestamp into account
<ysionneau> I didn't have a look at monitor/injector yet
<ysionneau> 11:51 < sb0__> but it would be really nice to have... also you don't have to call output() on those < what do you mean "to call output()"?
<sb0__> ysionneau: you should use the PLL LOCKED status to drive a AsyncResetSynchronizer and connect that to the RTIO domain reset
<sb0__> additionally, the runtime should monitor the PLL LOCKED after a clock switch, and report a clock switching failure if the PLL does not lock in a reasonable time (~100ms)
<sb0__> ysionneau: Inout defaults to input mode, and the kernels have to explicitly put it in output mode
<ysionneau> ok
<ysionneau> ah ok
<ysionneau> got it
<sb0__> add a ~1ms delay before looking at LOCKED, to make sure you are not looking at the lock from the previous clock
<ysionneau> hehe yes
<sb0__> actually, you can probably just wait for 1ms and look at LOCKED just once - forget about the 100ms timeout
<sb0__> from what I remember in the K7 datasheet, the PLLs are supposed to lock fast (under a ms)
<sb0__> maybe 1ms is already a lot...
<ysionneau> PLL max lock time : 100 us for K7
<ysionneau> having lunch out, bbl
<ysionneau> sb0__: about the bug we talked about yesterday, I've put a solution which works in my branch ping_controllers
<ysionneau> if you wanna have a look to say if it's good or not
cr1901_modern1 is now known as cr1901_modern
<ysionneau> (it's in the same commit implementing the controllers ping)
<ysionneau> *afk*
<sb0__> ok, so reset PLL, switch clock, unreset PLL, wait 150us, check LOCKED
<ysionneau> ack
<sb0__> ysionneau: why is that called "asyncio_kill_process_wait_timeout"?
<sb0__> as a workaround, checking periodically returncode is an acceptable hack
<sb0__> but it should be clearly labeled as such
<sb0__> and replace the previous workaround completely
<sb0__> step doesn't have to be a parameter. it's a workaround, not a nice API.
<sb0__> are there cases where returncode would never be set? what if the process startup fails because its executable was not found?
<sb0__> i.e. you attempt to create a process with a executable that does not exist, and then call your wait function on it. what happens?
<cr1901_modern> sb0__: (At your leisure) I'm trying to debug a wishbone design, and using abstract_transactions_wb.py as a base. How does run_simulation know to call the Initiator's do_simulation() fcn?
<cr1901_modern> Does run_simulation look for do_simulation in submodules as well?
<sb0__> Module passes it via get_fragment
<cr1901_modern> I see... I still need to spend time looking at the fragment portion of Migen.
<cr1901_modern> AIUI, fragments are "Modules with bookkeeping that has to be deferred until verilog generation is about to begin".
<sb0__> they are just collection of comb/sync statements, clock domains, etc.
<sb0__> non-hierarchical
<sb0__> makes the verilog output stage simpler as it doesn't need to traverse the module hierarchy, nor deal with some details like clock domain renaming
<cr1901_modern> Right, and it makes it so hierarchical Python is just a nice convenience.
<sb0__> ?
<sb0__> fragments are an internal migen detail.
<sb0__> user code should be based on Module
<cr1901_modern> That's what I meant
<cr1901_modern> Modules allow hierarchy, but internally are converted into fragments w/o hierarchy >>
<sb0__> yes
<sb0__> anything wrong with that?
<cr1901_modern> so therefore the hierarchy is just for "convenience writing source code
<cr1901_modern> (not at all. Just thinking out loud/trying to understand)
<cr1901_modern> I was just having trouble writing a testbench for my wishbone slave, and didn't understand how to use the wishbone Initiator, Target, etc. So I don't have to write my own master just for simulation.
<cr1901_modern> sb0__: I get how to do wishbone simulations now, but just one question: in abstract_transactions.py, is it actually specified whether Tap()'s simulation or my_generator actually prints first for a given simulation cycle?
<sb0__> no
<cr1901_modern> Okay, good to know. In my console, "Write x cycles" is the first line, <TWrite...> is the second.
<cr1901_modern> This is opposite of what the comments say, but if print/sim order is not specified, I'm not worrying about it.
<ysionneau> 12:41 < sb0__> are there cases where returncode would never be set? what if the process startup fails because its executable was not found? < ah, will check that
<sb0__> mithro: new style string formatting please
<mithro> sb0__: I always forget the new formatting method
<mithro> sb0__: old habits die hard :P
key2 has quit [Ping timeout: 246 seconds]
tija has quit [Quit: Connection closed for inactivity]
<mithro> sb0__: The digilent-adept one should be fine right?
<_florent_> sb0__: I can look a that if you want
<sb0__> _florent_: you mean change to "".format() and commit?
<_florent_> ok I do that
<sb0__> raise ValueError("Flashing unsupported with DigilentAdept tools") << should be NotImplementedError
<sb0__> hmm, we should have consistent parameter lists in docstrings across migen and artiq ...
<mithro> _florent_: I have some other fixes to that one anyway
<sb0__> the rest looks ok to me
<sb0__> _florent_: so yeah you can commit them, after those details are fixed
<sb0__> thanks
<mithro> sb0__: You should use whatever formatting for the args that readthedocs can automagically make look all nice :)
<_florent_> mithro: are going to fix and re-send your patches? or can I fix the details and commit?
<mithro> _florent_: I'll resend the fpgalink one
<_florent_> ok
<mithro> _florent_: can you just fix the Adept one?
<_florent_> yes
<sb0__> mithro: right now readthedocs fails to pull the docstrings ...
<mithro> sb0__: I can give fixing that a go over the weekend if I have time
<mithro> when sending an updated patch to the mailing list, should I reply to the first email again or send a new one?
<mithro> also, what serial console tool do people use?
<ysionneau> to speak with misoc? usually flterm
<mithro> _florent_: Well, I get the misoc BIOS on the USB UART!
<ysionneau> which board?
<GitHub126> [migen] enjoy-digital pushed 1 new commit to master: http://git.io/vtjYB
<GitHub126> migen/master 055f7d5 Tim 'mithro' Ansell: mibuild/xilinx: Adding programming with the Digilent Adept tools
<mithro> The Digilent Atlys board that _florent_ is creating a firmware on for me
<ysionneau> nice board!
<_florent_> mithro: the DDR2 is also working?
<mithro> _florent_: How do I test the DDR2?
<ysionneau> memory test OK at boot
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#51 (master - 055f7d5 : Tim 'mithro' Ansell): The build passed.
travis-ci has left #m-labs [#m-labs]
<_florent_> it's fine then
<mithro> _florent_: awesome!
<mithro> the help command at the bios doesn't seem to list all the commands available - I typed memtest and it seem to run something
<mithro> hrm... I just had a memtest run fail
<mithro> Memtest failed: 32/532480 words incorrect
<_florent_> I have the same, I'll have to fix that
<mithro> memtest seems to pass pretty much every time I run it - IE I can't seem to get the error to happen again?
<mithro> o wait, its like once in every 20-30 runs
<_florent_> there is probably a timing issue
<mithro> memtest doesn't appear in the bios command list though...
<mithro> _florent_: when sending an updated patch to the mailing list, should I reply to the first email again or send a new one?
<_florent_> you can reply to the first email
<ysionneau> there are lots of command that don't appear in help
<ysionneau> I guess it's to keep the help small?
<ysionneau> but I guess memtest can be added
<ysionneau> the others are very low level stuff to control the DRAM controller
<mithro> ysionneau: maybe a "see XXX.txt file generated with the bios for full list of commands" or something?
<ysionneau> memtest seems high level enough to be added to the help I think
<ysionneau> sb0__: something against adding memtest to BIOS help()?
<sb0__> no. just make sure it doesn't appear on platforms without sdram
<sb0__> mithro: re. parameter docstrings. with the artiq style it appears like this when rendered by sphinx: http://m-labs.hk/artiq/manual/protocols_reference.html#module-artiq.protocols.sync_struct
<sb0__> looks pretty good to me.
<mithro> sb0__: yeah - that looks great
<mithro> I always think the artiq logo looks like two people playing basketball on ice skates
<mithro> _florent_: updated patch sent
<sb0__> yeah, that's more or less what it is ;)
<ysionneau> 16:16 < sb0__> no. just make sure it doesn't appear on platforms without sdram < yep
<sb0__> assert 0 == _run_impact("""
<sb0__> that looks like C...
<sb0__> why not raise an exception on non-zero return status in _run_impact?
<sb0__> this kind of error reporting by return value is what you normally do only when you don't have exceptions
<mithro> sb0__: I assumed that you didn't want _run_impact to always check the return code (because then you'd be using subprocess.check_output) - so I only check it in the _generate_xsvf function
<sb0__> why shouldn't we check the return status?
<sb0__> _florent_ may know more, but non-zero usually means trouble
<sb0__> and it cases it doesn't, it's easy to catch and suppress the exception
<mithro> sb0__: because tools created by FPGA manufactures are generally pretty retarded and do stupid things? :P
<sb0__> in all fairness, xc3sprog & co are only marginally better
<sb0__> :p
<sb0__> their main advantage is they are free and not massively bloated
<sb0__> anyway, I don't know if there are any cases where impact returns a non-zero status when everything was fine...
<mithro> well, bed time for me - I can fix up the _run_impact issue tomorrow if you want
<mithro> _florent_: oh, btw did I tell you that I'll be in Europe for a couple of weeks in August? I'll be working from the London office for a week then attending the Chaos Comms Camp, DebConf and possibly FrOSCon
<_florent_> ah interesting
<ysionneau> what a program :)
<mithro> If you end up anywhere near those it would be awesome to say Hi! in person and share a beverage.
<_florent_> yes :)
<mithro> ysionneau: I've been trying to keep my long haul trips to 1 per year and Australia is pretty much long haul from everywhere!
<mithro> ysionneau: actually have to visit Waterloo in Canada and San Francisco too, so I'm on a round the world ticket
<mithro> It's fricken cold outside here at the moment!
* mithro tries walking faster.
<ysionneau> sb0__: I've read the doc about asyncio.shield() but I don't understand why it is needed for process.wait()
<sb0__> ysionneau: where do you see asyncio.shield used with process.wait?
<ysionneau> in the launcher
<ysionneau> in ctlmgr
<sb0__> mithro: instead of a RTW ticket i'd recommend a series of booking ploys (hidden city, throwaway, etc.) and (even better) buying from airlines that don't use those fucked yield management techniques
<sb0__> RTW gives you crappy connections because 1) it restricts you to one airline alliance 2) they assume you are going on an adventure and try to sell you those connections that no one wants
<sb0__> with booking tricks, it's about the same price as RTW, with much less layover and sitting in sardine boxes
<sb0__> i've heard of http://www.flystein.com/ recently but i never tried them.
<GitHub194> [migen] enjoy-digital pushed 2 new commits to master: http://git.io/vtjVN
<GitHub194> migen/master 8daf5e3 Tim 'mithro' Ansell: Adding support for programming with FPGALink...
<GitHub194> migen/master 0df9c16 Tim 'mithro' Ansell: mibuild: Adding error checking around xsvf generation
<sb0__> ysionneau: working around another python bug. there should be a comment about this. cancelling process.wait() should not have any ill effects, but it does...
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#52 (master - 0df9c16 : Tim 'mithro' Ansell): The build passed.
travis-ci has left #m-labs [#m-labs]
<ysionneau> sb0__: ah, I just didn't see the self.process_task.cancel()
<ysionneau> I was thinking nothing was going to cancel the task ...
<ysionneau> but obviously you want to be able to stop controllers ... therefore the cancel()
<sb0__> well the task is catching asyncio.CancelledError just below and terminates the process there ...
<ysionneau> yep, got it
<sb0__> you can try removing the shield(), hopefully it's not needed with python 3.4.3
<sb0__> asyncio is one of the most buggy python modules ...
<ysionneau> when you said "and replace the previous workaround completely", you mean I remove completely the current "asyncio_process_wait_timeout"?
<ysionneau> even in the cases where it works (when the process *has* a stdout)
<ysionneau> ?
<sb0__> the purpose of asyncio_process_wait_timeout is to wait for a process to terminate, with a timeout. your function does the same. so there should be one function, not two.
<ysionneau> all right
<sb0__> if there is nothing funny going on with returncode, your function should be fine to use at all times
<sb0__> hmm, though we may want fast process termination in the scheduler...
<sb0__> bah. we can use a short poll interval. that function will go away with python 3.5...
<sb0__> maybe we should file an issue so we remember to remove it
<ysionneau> yep good idea
<ysionneau> I could lower the "step" to 0.1 instead of 0.5
<sb0__> yes
<ysionneau> I remember seeing this in physics or math classes when playing with Fourrier Transforms
<sb0__> they should show this gif in the courses :)
<GitHub113> [misoc] fallen pushed 1 new commit to master: http://git.io/vtj9Y
<GitHub113> misoc/master 10eb075 Yann Sionneau: bios: show memtest command in help
<sb0__> many things are shown in there: sine/cosine, vector projections, harmonics. it's great!
<ysionneau> yes :)
<ysionneau> very visual
<ysionneau> much better to understand than just playing with mathematics equations
<ysionneau> for some people I guess
_florent_ has quit [Quit: Leaving]
<GitHub70> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vqeZu
<GitHub70> artiq/master 2881d5f Sebastien Bourdeauducq: gateware: add RTIO clock generator
<sb0__> ysionneau: can you document the RTIO channel assignments on KC705?
mumptai has joined #m-labs
sb0__ has quit [Quit: Page closed]
<GitHub82> [artiq] whitequark pushed 4 new commits to new-py2llvm: http://git.io/vqewv
<GitHub82> artiq/new-py2llvm 86cdc84 whitequark: Initialize types.TBuiltin's attributes field.
<GitHub82> artiq/new-py2llvm 1702251 whitequark: Add region field to types.
<GitHub82> artiq/new-py2llvm 7ce9bdf whitequark: Move transforms to artiq.compiler.transforms, add artiq.Module.
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#276 (master - 2881d5f : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
<GitHub44> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vqe69
<GitHub44> artiq/new-py2llvm 8a65266 whitequark: Improve builtin call error message.
<GitHub44> artiq/new-py2llvm 73a8f3c whitequark: Fix tests.
sb0 has joined #m-labs
<sb0> ysionneau, that's a problem with the conda upload
<GitHub139> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vqveQ
<GitHub139> artiq/master 0a9f909 Sebastien Bourdeauducq: kc705: fix ttl15
<GitHub25> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vqvmR
<GitHub25> artiq/new-py2llvm 02b41ea whitequark: Add MonomorphismChecker.
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#277 (master - 0a9f909 : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
<GitHub121> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vqv8N
<GitHub121> artiq/new-py2llvm 7c833f0 whitequark: Move transforms.MonomorphismChecker to validators.MonomorphismValidator.
<GitHub189> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vqvX5
<GitHub189> artiq/new-py2llvm 0ae13ac whitequark: Style fixes.
<GitHub172> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vqvHZ
<GitHub172> artiq/new-py2llvm bfabca4 whitequark: Remove regions from types....
ylamarre has joined #m-labs
_whitelogger has joined #m-labs
cr1901_modern1 has joined #m-labs
ylamarre has quit [Quit: ylamarre]
cr1901_modern has quit [Ping timeout: 252 seconds]
mumptai has quit [Remote host closed the connection]