<wpwrak> e.g., in labsw, i get what seems to be induction from the load to the wires going to the buttons
<larsc> but it will just be a small bounce, or not?
<wpwrak> in a sufficiently nasty scenario, these current changes could be periodic ...
<larsc> i still don't see how they could confuse the debouncer
<wpwrak> so i'll err on the safe side and add a bit of extra filtering
<larsc> or do you mean that the signal will never be stable?
<wpwrak> the debouncer may see a seemingly stable signal for a while
<wpwrak> at least in theory. it's kinda hard to test this in practice :)
<wpwrak> such things come and go. i already had to go through my whole set of lab power supplies to just make simple upsets happen occasionally. ironically, M1 is about 10x more effective at causing such things.
<larsc> hm, i suppose you could emulate edge triggered behaviour by switching between the trigger level, when the interrupt occurs
<larsc> but you could miss a edge if your irq handler is to slow
<wpwrak> yes, that should work
<larsc> sometimes it feels as if place and route is done by bruteforce
<kristianpaul> why?
<kristianpaul> i mean surelly it is, but did you detected it some how?
<larsc> it takes ages ;)
<kristianpaul> :-)
<wpwrak> larsc: what else would you expect in a proprietary and closed ecosystem where all selective pressure has been carefully eliminated ? ;-)
<lekernel> wpwrak, nothing prevents you from writing a p&r tool
<wpwrak> lekernel: why duplicate your fine work ? :)
<larsc> lekernel: do you know any good articles/papers on p&r?
<lekernel> yes
<lekernel> moment
<larsc> thanks
<lekernel> there's also this super-expensive book http://www.eecg.toronto.edu/~vaughn/book/arch_and_cad.html but it's just elaborating on the paper (I read it)
<lekernel> there's nothing groundbreaking in the book that you can't find out reading the paper and doing a little research
<lekernel> if you still want to read it, it's available in some big libraries
<lekernel> other than that one paper which isn't bad, in general you shouldn't expect much from academic research. if you want the beefy stuff, find papers and articles written by synopsys/cadence/altera/xilinx engineers
<larsc> hehe
<lekernel> US patent 6301693 is very interesting too
<lekernel> you can also check out "Highly Efficient Gradient Computation for Density-Constrained Analytical Placement" from I¬¬¬ (you need to get past the paywall, ask me if it gives you trouble)
<lekernel> but I think that for starters, a "simple" simulated annealing like in VPR would be OK
<larsc> i can access ieee through my university vpn
<lekernel> it seems Altera actually used an unpublished modified VPR to design the Stratix
<lekernel> check out The Stratix Routing and Logic Architecture (David Lewis*, Vaughn Betz*, David Jefferson, Andy Lee, Chris Lane, Paul Leventis*, Sandy Marquardt*, Cameron McClintock, Bruce Pedersen, Giles Powell, Srinivas Reddy, Chris Wysocki, Richard Cliff, and Jonathan Rose*)
<errordeveloper> lekernel: have you had a look at that vrq thing ?
<lekernel> yes, well, it's just a verilog parser
<lekernel> doesn't do any synthesis or p&r
<errordeveloper> ok, that's what I thought
<mwalle> lekernel: im updating the uart core documentation atm. what does THRU mean?
<mwalle> it enables loopback, but what does THRU stand for?
<roh> midi thru?
<roh> midi thru is usually a amplified copy of the 'in' port while 'out' is something 'generated' by a midi device
<roh> means the in goes into the optocoupler and its output to a) a driver (logic gate or so) and the thru output and b) the input of the microcontroller (or whatever)
<roh> the out goes also to a driver and the 'out' port
<mwalle> ah midi terminology :)
<mwalle> roh: thx :)
<roh> yeah. midi is crude ;)
<GitHub120> [linux-milkymist] mwalle force-pushed new-uart from 73ec00d to c1132a2: http://git.io/-D74Cw
<GitHub120> [linux-milkymist/new-uart] lm32: update driver for new uart core - Michael Walle
<lekernel> mwalle, "thru" connects TX to RX
<lekernel> and yes, the term comes from MIDI
<lekernel> are you planning to convert the other cores to level-sensitive as well?
<mwalle> lekernel: dunno, i want to look at the other linux drivers and make them devtree compatible
<lekernel> well, either use level-sensitive or edge-sensitive IRQs in the whole SoC, but not a mix :)
<mwalle> ac97? :b
<lekernel> btw, what is the advantage of having only one IRQ line from the UART to LM32? (as opposed to two like before)
<mwalle> well not really any advantage nor any disadvantage imho, but one irq for uart devices fits better into the linux uart core driver :)
<mwalle> eg. i dont need my own uart core descriptor object just for handling two interrupt numbers
<mwalle> and i need the additional bits within the core anyway for polling
<lekernel> what I don't like is it wastes IM bits and duplicates its functionality in the core, but if it makes writing drivers easier, it's acceptable
<lekernel> though it seems you want to use IM in the LM32 CPU-specific port and the "interrupt mask" core registers in the drivers already...
<mwalle> lekernel: right,