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
<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>
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
<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)
<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
<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?
<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
<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.
<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