lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
dvdk has quit [Remote host closed the connection]
sh4rm4 has quit [Quit: sh4rm4]
sh4rm4 has joined #milkymist
xiangfu has joined #milkymist
antgreen has joined #milkymist
hypermodern_ has joined #milkymist
hypermodern_ has left #milkymist [#milkymist]
lekernel has joined #milkymist
<lekernel>
edid works :)
<lekernel>
now let's try the xrandr-controlled led blinker
<larsc>
nice
<lekernel>
works fine. so the lvds hack isn't too bad :)
<lekernel>
edid is a bit buggy though, so after a few seconds the rescan fails and the computer drops the video signal.. hmm
<larsc>
rescan?
<larsc>
will it requery the edid?
<lekernel>
the video driver sends edid queries every 10 seconds or so, and assumes the monitor was disconnected if it doesn't get a proper edid
<larsc>
ah, yea, that's the default poll interval for kms drivers
<larsc>
normally you'd assume though that the driver only checks hpd
<lekernel>
well, hdmi, unlike vga, requires edid
<larsc>
but there is no need to rescan the edid if the monitor hasn't been disconnected
dvdk has joined #milkymist
<larsc>
btw. I've kind of been able to hack the AbstractActor stuff to do what I want to do. Right now you keep a list of actor classes for which the layout should be infered. A more generic option is to add a flag to the actor class which states if and how the layout should be infered
<larsc>
I think we need to handle 4 different cases. Infer layout from sources, Infer layout from sinks, infer layout from either sinks or sources, infer layout from both sinks and sources
<lekernel>
you could make that "parameter" a static method
<lekernel>
that takes a list of sinks/sources it's connected to, and returns the layout parameters to pass to the constructor
<lekernel>
then you could provide generic functions for simple cases
<larsc>
makes sense
<lekernel>
maybe there should be a way to tell what information that method needs, to resolve dependencies
<larsc>
I think the current algorithem handles that by just trying again and again until all AbstractActors have been instantiated
<larsc>
which is fine for now I guess
hypermodern_ has joined #milkymist
hypermodern_ has left #milkymist [#milkymist]
hypermodern_ has joined #milkymist
hypermodern_ has left #milkymist [#milkymist]
<lekernel>
hmm, the bug only manifests itself with nouveau... the proprietary nvidia driver works fine
<lekernel>
it does way fewer rescans though...
<lekernel>
ah, no. it's just doesn't drop the video signal when the bug appears.
<lekernel>
seems to be electrical problems...
<lekernel>
interestingly enough, disconnecting the logic analyzer makes EDID fail completely
<lekernel>
oh, how I love this sort of bug
<larsc>
or the timing could be slightly off
<lekernel>
have you assembled your board yet?
<larsc>
not fully, still missing a few parts
<lekernel>
could it be glitches (that the logic analyzer would remove due to capacitance)...?
<lekernel>
when the video signal is dropped by the nouveau driver, that's after an i2c address phase that is not acked but should be
<lekernel>
and all the FPGA does at this point is sample sda on the rising edge of scl, and compare the address
<Fallenou>
he is swimming in a pool of fpga internal wires
<lekernel>
do you have fresh news?
<mwalle>
azonenberg: what is FB and ZIA?
<lekernel>
azonenberg, very cool!
<azonenberg>
mwalle: FB = function block
<azonenberg>
ZIA = zero-power input array
<azonenberg>
that's semi-internal terminology used by the toolchain
<azonenberg>
lekernel: it's beautiful how well the silicon matches up with the bitstream
<azonenberg>
i knew what to expect before i even opened the package
<lekernel>
what does the ZIA do?
<Fallenou>
thats' like nice christmas presents :)
<lekernel>
routing?
<azonenberg>
It's a switching matrix that routes every function block's output, and every input pin, back to the inputs of the AND array
<azonenberg>
I'm still trying to understand the exact structure of it
<azonenberg>
i have most of it figured out by bruteforce but i don't yet understand the actual structure, i was hoping the silicon could help clarify that
<lekernel>
how is the config flash routed to the OR/AND arrays and the ZIA?
<azonenberg>
you can even download a bitstream into the SRAM without touching the flash
<lekernel>
so it copies the flash to distributed SRAM, like FPGAs?
<azonenberg>
Yes
<azonenberg>
That was a surprise to me as well
<lekernel>
ah. I thought one plus of CPLDs was they were live at power up
<azonenberg>
The actual configuration cells are probably regular 6T SRAM or D FFs
<azonenberg>
They are, in theory
<lekernel>
is the download-to-SRAM feature documented, or something you found out?
<azonenberg>
It's semi-documented
<azonenberg>
jtag instruction ICS_SRAM_WRITE
<larsc>
mwalle: already signed up :)
<azonenberg>
ISC*
<mwalle>
and at least altera has "real-time programming" (altera buzzword) where the cpld can be flashed while it is still working with the old configuration
<azonenberg>
Same here
<azonenberg>
You can write to the SRAM or the flash independently of the other
<mwalle>
larsc: nice, i guess i wont find time to do the assignments :(
<azonenberg>
i dont know if xc9500* has that feature but cr-ii does
<azonenberg>
cr-ii is a much nicer architecture
<larsc>
mwalle: me neither, just trying to follow the lectures
<mwalle>
larsc: you are not watching the lectures with an android device, do you? :)