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
antgreen has quit [Ping timeout: 245 seconds]
<larsc> do you have a capture of the signal?
<lekernel> that's the transfer that causes the nouveau driver to stop
<lekernel> when the video signal is off during the initial scan, the exact same waveform (at least, as captured with this thing) makes the FPGA ack
<larsc> hm, have you checked what the fpga sees?
<larsc> maybe some glitches on scl causes it to see extra edges
<larsc> to you use a filter on scl?
<lekernel> no, I don't - should I?
<lekernel> why should there be glitches anyway?
<larsc> I don't know
<larsc> I'd try to add a short moving avarage filter or something similar to scl
<lekernel> adding a 500ns delay on scl makes it work without the logic analyzer connected - but video signal is still dropped after a while
<lekernel> s/500ns/200ns
<lekernel> no change with an average of 5 samples at 50MHz
<lekernel> this start to get irritating
<lekernel> I guess I'll go ahead with the nvidia driver and fix that crap later
xiangfu has quit [Ping timeout: 255 seconds]
xiangfu has joined #milkymist
antgreen has joined #milkymist
gbraad has joined #milkymist
gbraad has quit [Changing host]
gbraad has joined #milkymist
dvdk has quit [Remote host closed the connection]
xiangfu_ has joined #milkymist
xiangfu has quit [Ping timeout: 245 seconds]
xiangfu_ has quit [Ping timeout: 264 seconds]
gbraad has quit [Ping timeout: 264 seconds]
<Fallenou> yeah :)
<wpwrak> nice :)
<kristian1aul> :)
kristian1aul has quit [Quit: Reconnecting]
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
qwebirc68939 has joined #milkymist
qwebirc68939 has quit [Client Quit]
Martoni has quit [Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307164200]]
proppy has quit [Ping timeout: 255 seconds]
<GitHub70> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/KUUI4g
<GitHub70> migen/master 52d1395 Sebastien Bourdeauducq: bank/description: modify reg/mem in-place
hypermodern has joined #milkymist
<GitHub173> [milkymist-ng] sbourdeauducq pushed 3 new commits to master: http://git.io/EMqCVA
<GitHub173> milkymist-ng/master eaef346 Sebastien Bourdeauducq: Instantiate DVI sampler core for both ports
<GitHub173> milkymist-ng/master 2ae504f Sebastien Bourdeauducq: software/bios: default length 4 for mr command
<GitHub173> milkymist-ng/master e99bafe Sebastien Bourdeauducq: dvisampler: add core, EDID support
Alarm has joined #milkymist
antgreen has quit [Quit: Leaving]
proppy has joined #milkymist
* Fallenou starting to play with virtual memory things in netbsd kernel source code
<Fallenou> it's going to be fun
<larsc> lekernel: is there any existing code which makes use of the plumbing actor, against which I could test my changes?
<larsc> All code in examples/ seems to be single source, single sink
<larsc> hm, the output generated by migen looks different each time, this makes it pretty hard to verify whether the code is the same
<larsc> and the framebuffer testbench is broken
<lekernel> it shouldn't look different... what does?
<larsc> everything
<larsc> the indices on named variables change
<lekernel> that problem came from python iteration orders depending on id's, but I should have fixed it a while ago
<larsc> stuff gets basically reorder
<larsc> what's the new way of doing sim.wr(dut.bank.description[addr].field.storage, d)
<larsc> with the Module API?
<lekernel> ah, yes, there's a bug... it's different on each run again
<lekernel> I'll have a look at this
<lekernel> just define a function called do_simulation(self, sim) and derive from Module
<mwalle> Fallenou: ah youre porting netbsd?
<mwalle> btw anyone at ohm2013 ?
<Fallenou> 22:33 < mwalle> Fallenou: ah youre porting netbsd? < yes :)
<mwalle> Fallenou: nice :)
<Fallenou> hopefully I will get some kernel printing on the uart in like 2 or 3 months
<lekernel> mwalle, are *you* going to ohm?
<mwalle> lekernel: im planning it
<mwalle> to got
<mwalle> got
<mwalle> arg
<mwalle> go
<lekernel> first hacker event?
<mwalle> yep
<Fallenou> :)
<mwalle> btw anyone got a jura impressa (coffee maker)
<mwalle> e50
<lekernel> I stopped going to hacker events after the cccamp 2011 frustration, but I'll give it more thought...
<lekernel> "Budget ticket, For those who can not even afford a Raspberry PI." *ahem*
<mwalle> yeah.. ;)
<lekernel> yea right
<Fallenou> but can afford the flight to amsterdam :p or car/bus/whatever
<lekernel> well this pretty much sums up the hardware culture at those events
<lekernel> and has everything to do with me no longer attending them
<mwalle> btw what happend to wolfsprau?
<lekernel> I'm wondering too...
<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?
<lekernel> I thought CPLD had distributed flash
<lekernel> not large chunks of it
<azonenberg> It appears not
<mwalle> maybe someone is interested in https://www.coursera.org/course/vlsicad
<azonenberg> The 2c32a has config SRAM
<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? :)
<larsc> no, on my laptop
<larsc> btw. there is also https://www.coursera.org/course/mosfet
<lekernel> azonenberg, you
<azonenberg> lekernel: ?
<lekernel> azonenberg, have you checked some microsemi/actel devices?
<lekernel> sorry
<azonenberg> Funny you ask
<azonenberg> I have had zero time to analyze it
<azonenberg> just a few pictures in that directory
<lekernel> :)
<azonenberg> Look at the date ;)
<lekernel> and those have distributed flash?
<azonenberg> Unknown
<azonenberg> I opened it up and took a few photos
<azonenberg> that was all i had time for
<azonenberg> No analysis on that
<Fallenou> azonenberg: how much time does it take to decap a chip and then take a picture ?
<azonenberg> Hmm, maybe an hour? But you can run a lot of chips at once on the hot plate
<lekernel> azonenberg, another thing to consider taking apart is a spartan 3an device
<lekernel> those with integrated flash
<azonenberg> i did a dozen chips of nine part numbers in that run
<lekernel> I think there are separate dies...
<azonenberg> Yes
<azonenberg> It's stacked die SPI
<azonenberg> I havent taken one apart but docs say it's "similar to" Atmel DataFlash
<Fallenou> azonenberg: what do you use for taking the pictures? pice range of it?
<azonenberg> There's an SPI_ACCESS primitive in spartan6 too
<azonenberg> but as far as i know there was never a Spartan-6N series
<azonenberg> Fallenou: The optical microscope is an olympus BHM
<azonenberg> $250 on ebay for the body with objectives and a binocular head, another $250 for a head with the camera port
<azonenberg> sold new for probably ten times that
<Fallenou> hum, the ebay price seems very reasonable
<azonenberg> I got lucky
<lekernel> but unfortunately non-reproducible :(
<azonenberg> they were asking $500 OBO
<Fallenou> how much magnification is needed ?
<azonenberg> i offered 250 with the intention of negotiating
<azonenberg> but they sold it to me right then and there
<Fallenou> :)
<azonenberg> Fallenou: Depends on what you're looking at
<azonenberg> For something modern like spartan6, optical won't be of use for more than the top layer or two
<azonenberg> you need a SEM
<Fallenou> I guess I can forget about SEM
<azonenberg> On the other hand for old MCUs made on like a 500nm process, 400x is fine
<Fallenou> ok
<azonenberg> with 1000x you can do 350nm stuff
<azonenberg> maybe 250 if you're really careful and have high-end optics
<azonenberg> 180 and below pretty much needs SEM if you want to see all the details
<azonenberg> Being a student at a tech school is nice, i get access to all the labs :)
<azonenberg> and the rates are quite reasonable
<azonenberg> the one i took the spartan6 pic on is $65 an hour
<azonenberg> they have a lower end one available for i think 45 or 4o
<azonenberg> 40*
<Fallenou> is this total shit ?
<Fallenou> price seems very low
<azonenberg> Yes
<azonenberg> 500x, lol
<azonenberg> i can magnify anything 500 times
<azonenberg> doesnt mean it'll be anything but a blur :p
<Fallenou> =)
<azonenberg> There are good optics and cheap optics, but no good cheap optics
<azonenberg> AmScope objective
<mwalle> Fallenou: we have that at work, its crap ;)
<azonenberg> Olympus Neo40 objective
<azonenberg> Same camera, same specimen
<Fallenou> mwalle: ok ^^
<azonenberg> different lenses
<Fallenou> azonenberg: wow indeed
<azonenberg> Fallenou: For scale the smallest wires visible in the Olympus image are about 500nm across
<azonenberg> the device is a 250 or 180nm process but this is an upper metal layer
<mwalle> gn8
<Fallenou> gn8!
<GitHub100> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/--7e7g
<GitHub100> migen/master fc88319 Sebastien Bourdeauducq: bank/csrgen/BankArray: create banks in sorted order
<lekernel> larsc, there's another source of non-deterministic names, will nail it down tomorrow
<lekernel> gn8
lekernel has quit [Quit: Leaving]
<Fallenou> wow they have tons of this shitty microscope
<Fallenou> it floods the ebay pages
<Fallenou> they must sell like pancakes
<Fallenou> and then end up directly in the bin
<azonenberg> Lol, yep
<azonenberg> Note that the AmScope that took that blurry picture
<azonenberg> sells new for around $1000
<azonenberg> and looks that bad compared to the olympus
<azonenberg> now imagine what $50 optics will look like ;p
<Fallenou> omg :)
<Fallenou> I guess quality is even more important when you want to see something of the order of a few hundreds nm
<Fallenou> that's pretty damn small
<azonenberg> Lol, yes
<azonenberg> The objective is the most critical part
<azonenberg> you can skimp on eyepieces to some extent
<Fallenou> eyepieces?
<azonenberg> You *do* want to see whatever is under that objective, right?
<azonenberg> you need something to look through ;)
<Fallenou> yes indeed =)
<Fallenou> ok, vocabulary problem
<Fallenou> ok, all netbsd .c / .S file compile fine
<Fallenou> now the final linking part is failing :)
Alarm has quit [Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931]]
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #milkymist
hypermodern has quit [Remote host closed the connection]