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
<GitHub51>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/pdzz
<GitHub51>
misoc/master d8b59c0 Florent Kermarrec: litesata: avoid hack on kc705 platform with new mibuild toolchain management
_florent_ has joined #m-labs
ccube has quit [Remote host closed the connection]
<_florent_>
sb0__: even if I'm only able to create kludges, broke or reinvent things
<_florent_>
I think this is a way to confront our ideas and improve things...
<_florent_>
Would you have done the changes you just did to Mibuild if I didn't added
<_florent_>
some kludges that made you think: "hmm, maybe there is something we can
<_florent_>
improve on that point if this kludge is needed here"? I'm not sure.
<_florent_>
.
<_florent_>
Are the changes I made recently a way to go in the good direction? I think so.
<_florent_>
.
<_florent_>
The way you react when things are not done the way you would have done it
<_florent_>
are also a way to confront our ideas and improve things...
<_florent_>
In most of the cases it's justified
<_florent_>
but I'm not sure the way you did it s sometimes really encouraging and appropriate.
<_florent_>
s/is
<_florent_>
Others people are not you, and most of them won't probably be ever as skilled as you are (Me included)
<_florent_>
but they can probably give you ideas you wouldn't have ever think of...
<_florent_>
So please think about that, thanks.
_florent_ has quit [Quit: Leaving]
early has quit [Ping timeout: 245 seconds]
<rjo>
_florent_: we all appreciate your work very much! afaict nobody doubts that your contributions are very valuable and nobody is trying to criticize your skills or attitude. while the tone here is very direct (as it is frequently) you need to assume first that the critique here is purely technical and not personal. many of us have to force ourselves to not take these comments as personal attacks.
early has joined #m-labs
<rjo>
_florent_: that said, you do get a lot of heat currently for two reasons: you are touching high-impact code and you are making significant changes. heat is to be expected even if there were no bugs/imperfections.
mumptai has quit [Ping timeout: 264 seconds]
mumptai has joined #m-labs
nicksydney has quit [Ping timeout: 244 seconds]
_florent_ has joined #m-labs
<_florent_>
thanks rjo, sure I have no doubt the critique is purely technical and I found this very valuable for people like me
<_florent_>
more focussed on exploring and experimenting things. When I say I create kludges, broke on reinvent things, that's what I think about me :)
<_florent_>
and that's the way I generally work before figuring out thre is a cleaner wayt to do things (or having someone else's feedback)
<_florent_>
Maybe I took it too personnaly this time... but that not important.
<_florent_>
I just wanted the community to be aware that if something has been broken or changed in a way you think are not appropriate or can that be improved, I'll always be proactive and try to fix or improve things :)
<_florent_>
(the parenthesis is closed :)
<_florent_>
I've starting integrating the work I've started for the ethernet on Artiq and saw you are using pep8
<_florent_>
starting/started
<_florent_>
we discuss with sb0__ about converting migen and misoc to pep8
<sb0__>
_florent_, what rjo said.
<sb0__>
also to put blame where it is deserved: the platform factory function was initially my idea. you have shown it was a particularly bad one :)
<_florent_>
for pep8, I will have some time next week to do some non technical stuff (won't be in my office in the beginning of the week)
<_florent_>
So if you want to convert migen/misoc to it, I propose to start it
<_florent_>
(and if you think it's the right time to do it)
<sb0__>
do you mean: you are going to do it, or is it a good time for me to do it as you won't be submitting conflicting patches?
<_florent_>
yes I mean I can do it in the beginning of next week, but wanted to be sure: 1) you wanted to do it 2) it's the right time to avoid conflicting patches
<sb0__>
#1 sure
<_florent_>
OK I'll have a look at it
<sb0__>
#2.... I can try to stay away from it for a while
<sb0__>
or hold pushing commits until it is converted to pep8, and then merge them manually
<sb0__>
thanks for your help!
<_florent_>
OK, I'll have a look at pep8, but will work in a branch. I'll send you the patches for a review before pushing it.
<sb0__>
hmm, the problem is diff won't work for that... you are changing almost every line in every file
<sb0__>
but those changes should be benign enough, I think (and most mistakes would cause syntax errors)... I'd say just go ahead and push it to master
<sb0__>
_florent_, maybe the sdram can also be called "main_ram" in the memory mapping?
<_florent_>
OK, so you are OK if I do specific commits (ex: one to change tabs to spaces, one for blank lines, one for whitespaces, ...)
<sb0__>
that will be fine.
<_florent_>
yes for main_ram this would avoid using sdram mapping in that case
<_florent_>
I'll change that
<sb0__>
_florent_, regarding having a xilinx verilog backend. what about exporting the special_overrides dictionary that is currently inside the get_verilog function in mibuild.xilinx.platform, and then you can reuse it to call fhdl.verilog.convert directly?
<sb0__>
mibuild doesn't tweak the verilog output in any other way than using this special_overrides dictionary
<_florent_>
yes this seems fine, I'll have a look
<sb0__>
ysionneau, rjo, artiq_ppro bitstream builds fine here
<sb0__>
97% occupied slices, but it works
<sb0__>
what do you think of a minimal migen, with any cores more complicated than the FIFOs moved (typically) into misoc?
<sb0__>
keep fhdl, fifos, records, mibuild, clock domain transfer components
<sb0__>
simulators
<_florent_>
has it changed with the changes I made? (because my changes should not have impact in that)
<sb0__>
all the rest goes somewhere else
<_florent_>
in/on
<sb0__>
_florent_, not as far as I can tell
<sb0__>
all bank/bus should definitely go to misoc now, as misoc now supports CPU-less socs...
<_florent_>
yes it's a good idea to have a minimal migen
<_florent_>
bus we should maybe keep some bus definition in migen
<GitHub137>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/pFbF
<rjo>
sb0__, _florent_: yes. i am certainly not opposed to pep8-ing migen/misoc ;) it would be a transition. put a deadline out for all patch submissions, practice the conversion once, then convert everything in one go at the deadline.
<sb0__>
rjo, was *args/**kwargs in platform.finalize from you?
aeris has quit [Ping timeout: 252 seconds]
aeris has joined #m-labs
<GitHub47>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/pxX6
<GitHub47>
migen/master beeaefc Sebastien Bourdeauducq: move pytholite to separate repos
sb0__ has quit [Quit: Leaving]
<rjo>
sb0: lemme check.
<rjo>
sb0: i think i may have done do_finalize() and thus args/kwargs. but i don't use args nor kwargs afaict nor do i remember the rationale.
<rjo>
in general i don't like finalize() and do_finalize() (in Module and in Platform). It smells like the very definition of a hack ;)
<rjo>
i don't have the full mibuild history around so i can't blame anybody.
<rjo>
the onler caller of Platform.finalize() is the toolchain, right? And there are no args/kwargs there afaict.
<rjo>
sb0, florent: re splitting migen. yes. i would also define migen as "language, and fundamental building blocks". that is no algorithmic cores (cordic, etc) or non-trivial bus implementations.
<rjo>
but migen, mibuild, micores, and misoc are so tightly coupled still that i would like to see them bundled.
<rjo>
or "mimods" for better reference to migen.fhdl.std.Module