<larsc>
sb0: I added a print(sig.huid) to the loop, and they are always in the same order, so I guess it only worked because of some stange side effects.
<larsc>
sb0: what isn't sorted the same way each time is the result of _bins()
<sb0>
ok, thanks for the heads-up... will continue a bit on the video mixer now, and then fix that, unless you beat me to it
Gurty has quit [Ping timeout: 260 seconds]
Gurty has joined #milkymist
sb0 has quit [Quit: Leaving]
lekernel has joined #milkymist
<larsc>
you know the code much better than I do
<larsc>
but I sent you a pull request on github for some other things
<lekernel>
ah
<lekernel>
for some reason github doesn't send me notifications for those
<lekernel>
if (key < 0): ==> if key < 0:
<lekernel>
it's not C :)
<larsc>
right
<Fallenou>
:)
<Fallenou>
hi !
<Fallenou>
does anyone here knows the difference-between/reason-for libgcc1 and libgcc2?
<Fallenou>
it (afaik) seems (obiously) undocumented anywhere
<lekernel>
btw for shifting registers there is << and >>
<lekernel>
they do arithmetic shifts though - your Cat(Replicate(0, n), reg[-n:]) does a logical shift
<GitHub47>
[migen] sbourdeauducq pushed 3 new commits to master: http://git.io/gfoRTg
<GitHub47>
migen/master 72579a6 Lars-Peter Clausen: Add support for negative slice indices...
<Fallenou>
it was not in the "lm32 specific" directory of libgcc anyway
<Fallenou>
ok so I can get a generic one
<Fallenou>
dist/gcc/libgcc2.c
<Fallenou>
ok got it
<Fallenou>
copy pastig those things really is not clean :(
<Fallenou>
but that will do it ...
Gurty has joined #milkymist
<lekernel>
anyone knows how to fix the fpga editor segfault at startup bug?
<lekernel>
s/fix/work around
<lekernel>
with a message
<lekernel>
Wind/U Error (193): X-Resource: DefaultGUIFontSpec (-adobe-courier-medium-r-normal--12-*-*-*-p-*-*-*) does not fully specify a font set for this locale
<lekernel>
but I'm not sure if that's related, the segfault happens several seconds later
<lekernel>
and it prints "Release 14.4 - fpga_editor P.49d (lin64)" after ...
<Fallenou>
can you enable core dumps and get the dump (and then the stack trace) ?
<Fallenou>
maybe by miracle the binary is not stripped :)
<larsc>
hm, I get /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/_fpga_editor: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory
<lekernel>
0x00007fffe265c722 in wuGetTextExtent ()
<lekernel>
from /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libgdi50.so
<lekernel>
motif is already a steaming pile of crap... but wind/u + motif ... omg
<lekernel>
larsc, yeah you need to install openmotif ...
<Fallenou>
maybe I'm terrible wrong here but, isn't it possible to use the 32 bit version, even on a 64 bit system ?
<lekernel>
"These messages are brought to you by a questionable toolkit called Wind/U that is used to port Windows software to operating systems. Most of these messages can be ignored without lasting effect on the quality of your life. The last line, however, is a real problem. As it turns out, the toolkit ports the deficiencies in standard conformance from the Microsoft world to the target system: It cannot handle the standard display coordinates
<lekernel>
of 0.0. "
<larsc>
ok, it took like half a minute to start, but it does not crash
<lekernel>
in part 2 he explains how to add logic elements and nets
jimmythehorn has joined #milkymist
mumptai has quit [Read error: Connection reset by peer]
<Fallenou>
thanks !
<lekernel>
meh, it seems only a limited number of clocks may enter a IOB
<lekernel>
can't find doc about that though
<lekernel>
let's see what xdl says
azonenberg has quit [Remote host closed the connection]
<lekernel>
and the IODELAY CLK is limited to 180MHz, which, if you are using the ISERDES in single ended mode, in turn limits your data rate to 720Mbps to be able to route all clocks
<lekernel>
welcome to fpga slowland
azonenberg has joined #milkymist
<lekernel>
meh, yes, if I read the xdl right there are only 2 local clock distribution networks in a IOB
<lekernel>
and if you use the IOSERDES, you use them all for CLK0 and CLKDIV...
<lekernel>
and if you want to use the variable IODELAY, then you must have CLK=CLKDIV, which limits it to 180MHz
<lekernel>
meanwhile, NVIDIA ships GPUs with 5000+MHz IO...
<Fallenou>
but they don't have useless routing switches and use 28 nm technology
mumptai has joined #milkymist
<Fallenou>
larsc
<Fallenou>
I can see in the linux file you linked :
<lekernel>
couldn't they think of a more confusing behaviour? just lost 2+ hours to this :(
<lekernel>
(what you connect at one *output* of BUFPLL alters what another output does)
<Fallenou>
...
<Fallenou>
isn't it that a part of the design is being optimized out ?
<Fallenou>
like the lock signal
<lekernel>
it may optimize away the BUFPLL, but then it connects the LOCK signal to 0
<lekernel>
in the end, what you see is if you disconnect the output of BUFPLL, what happens to another output changes
<lekernel>
if for whatever reason, they have to remove BUFPLLs with a disconnected output, it would have been much better to connect LOCK to the PLL LOCKED input instead of 0 ...
<Fallenou>
yes it would make more sens
<Fallenou>
sense*
lekernel has quit [Quit: Leaving]
<azonenberg>
lol, wow
<azonenberg>
Also, i think i know that guy
<azonenberg>
(the OP)
<azonenberg>
he went to my school and was talking to me a year or so ago about doing HDMI on an Atlys