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
Bike has quit [Quit: Lost terminal]
<cr1901_modern>
whitequark: Is your library a pyxdg replacement?
<whitequark>
replacement? anyway, I have no idea what pyxdg is
<cr1901_modern>
It's a set of helper functions that abstract away the XDG spec, so you can, for example call a function to get a data structure of all programs in /usr/share/applications, to be displayed in a dynamic menu
<cr1901_modern>
It's also not pleasant to use lol
<GitHub34>
[misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/vnWHi
<GitHub34>
misoc/master bc1450e Tim 'mithro' Ansell: Adding --help option to flterm.
rohitksingh has joined #m-labs
mumptai has joined #m-labs
nicksydney has joined #m-labs
ylamarre has quit [Quit: ylamarre]
rohitksingh has quit [Quit: Leaving.]
<whitequark>
sb0: wow, lm32 is in binutils, and it is utter shit
<whitequark>
half of the functions just abort()
<whitequark>
debug prints abound
mumptai has quit [Quit: Verlassend]
olofk has joined #m-labs
<olofk>
I noticed some rearranging in the misoc repo
<olofk>
and wishbone.py still depends on litescope, which isn't part of misoc anymore
<sb0>
whitequark, this does not surprise me, lm32 is open source
<sb0>
_florent_, ^
<sb0>
olofk, which wishbone.py?
<sb0>
hmm com/uart/software
<mithro>
_florent_ is on holidays in ireland
<cr1901_modern>
Ahhh shit, there goes my other Migen project
<cr1901_modern>
for now anyway
<whitequark>
sb0: or1k is open source also and its support is very good
<whitequark>
honestly it just seems that the people writing lm32 toolchain support are really bad at writing toolchain support code
<sb0>
but it had this horrendous verilog implementation before mor1kx.
<cr1901_modern>
I wonder if they just took the MIPS backend and modified it
<whitequark>
the law of conservation of crap?
<sb0>
yes
<sb0>
olofk, and yeah misoc will get a good shakedown after i'm finished with migen
<olofk>
sb0: Yeah, I solved it for now by installing litescope separately and changing removing misoclib.tools
<sb0>
olofk, are misoc builds completely broken right now if you don't have litescope installed?
<sb0>
I haven't tested it since florent's changes...
<sb0>
cr1901_modern, what other migen project?
<olofk>
sb0: Not sure. I just ran a script with this include from misoclib.com.uart.software.wishbone import UARTWishboneBridgeDriver
<olofk>
And that failed
<olofk>
But it seeems to be installable, and that wishbone.py contained the only reference to litescope
<cr1901_modern>
sb0: Wanted to use Litescope to capture bus activity on an old chip to get timing information and "dump" the internal ROM
<sb0>
whitequark, did you delete your llvm-or1k repository?
<whitequark>
you know, no, binutils is not just bad
<whitequark>
the whole fucking thing is written by complete morons
<whitequark>
after I fix this bug, I refuse to touch binutils ever again, because it is simply not worth any single second more of my time
<whitequark>
"binutils maintainer" would be a good interview question, to turn down with shame anyone who replies "yes"
<cr1901_modern>
Not sure if LLVM has something similar, but libbfd had the right idea. Of course, I suppose it's not relevant anymore since ELF and COFF are the only two relevant object formats left.
<whitequark>
Mach-O
<cr1901_modern>
Oops, yea, that too.
<terpstra>
are you guys going to ORCONF2015?
<whitequark>
hmm, short notice. I'm probably not getting a visa this fast
<terpstra>
i only just heard of it myself
<sb0>
whitequark, what are you touching binutils for?
<whitequark>
PR18759
<sb0>
ah, that's still not over
<whitequark>
hell no
<whitequark>
wait until you see my writeup on that
<cr1901_modern>
Is there any architectural reason to prefer lm32 to mor1kx or vice versa?
<sb0>
lm32 isa is a bit cleaner
<cr1901_modern>
Also has the MMU built thanks to ysionneau (though I think OpenRISC has an MMU spec?)
<ysionneau>
rewritten completely by mwalle
<ysionneau>
so it's more his work now
<ysionneau>
and OpenRISC has more than just MMU spec, they have a working implementation, and they can run full featured Linux, with MMU, SMP etc
<ysionneau>
at least mor1kx
<cr1901_modern>
Sounds like most of the work is done for mor1kx, and lm32 needs to be brought up to speed :P
attie has quit [Read error: Connection reset by peer]
<olofk>
hi terpstra :) You were involved with the sdb spec a few years ago, right? I seem to remember your name from the discussions there
<terpstra>
yes
<terpstra>
i actually am going to need to revise the sdb spec actually. :)
<terpstra>
in a complicated WB bus topology (involving diamonds) devices can end up with more than one address... which is not a problem for slaves
<terpstra>
but those diamond topologies also mean that masters end up with different MSI addresses from the point-of-view of different masters... so you need SDB records that also describe the masters, in order to be able to calculate your own MSI address when configuring a slave to send you interrupts
<terpstra>
s/from the point of view of different masters/from the point of view of different SLAVES/
<sb0>
who makes complicated WB bus topologies?
<terpstra>
we do
<terpstra>
we have over 35 slaves in our SoC
<terpstra>
and something like 9+ masters
<sb0>
does this pass timing?
<terpstra>
sure
<terpstra>
we have adapters which cross WB between clock domains via FIFO and adapters which insert a register stage to help with timing closure
<sb0>
ah, right
<terpstra>
i think the biggest crossbar has 27 slaves and 8 masters
<terpstra>
so actually we must have more than 35 and 9 by now since there are other crossbars nested and interconnected all around
<terpstra>
mathias uses an 8-way lm32 setup for the gsi timing master... each having its own private crossbar, connected in turn to a shared crossbar, connected to the main SoC crossbar, connected to the backplane WB crossbar and white rabbit crossbars and peripheral crossbar ...
<terpstra>
WB bus can get complicated pretty fast :)
<sb0>
8 lm32 cores?
<sb0>
or 4, with I+D?
<terpstra>
8 lm32s
<terpstra>
but the masters are on private crossbars with some private devices
<sb0>
interesting
<sb0>
why do you need that many cpus, and how do you program them?
<terpstra>
he uses them for real-time control of the accelerator
<terpstra>
he loads their programs in via the second port of the dpram used for their program memory
<terpstra>
he doesn't want to use my cpu, b/c it's not deterministic. sniff. sniff.
<sb0>
oh, so you connect only the d-side the wishbone
<sb0>
well, by that standard, wb arbitration isn't deterministic either, is it?
<terpstra>
he says both I+D are connected to the same crossbar
<terpstra>
how do you mean?
<terpstra>
WB arbitration is completely deterministic as long as you only access private resources :)
<sb0>
yeah
<sb0>
but you said there is a shared crossbar
<terpstra>
i know he has problems due to the shared memory region
<terpstra>
yes
<terpstra>
i think he plans to move to a scheme where he uses a small slave that receives the messages for other processors non-blocking instead of a shared memory region
<sb0>
are you bitbanging stuff?
<terpstra>
but, this is not my work
<terpstra>
what stuff?
<sb0>
what the cpus control
<terpstra>
no
<sb0>
why do you need that level of RT?
<terpstra>
they fill commands into some sort of FIFO that packages them up to broadcast over the timing network to trigger real-time actions
<terpstra>
i don't know what his exact requirements are, and he just stepped out of the office
<terpstra>
AFAIK, he just has to be deterministic to within 10us or so
<sb0>
that's a lot of time
<terpstra>
don't ask me to justify someone else's design decisions :)
<GitHub117>
[misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/vnBTc
<cr1901_modern>
"sb0: anyone interested in adding instance support (via iverilog/vpi, like myhdl does) to the new migen simulator?" I am; when I brought it up a few nights (?) ago, you said you needed to rethink the protocol.