<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.
<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 ?
<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...