<kristianpaul>
now i can operate the m1 with no need to move my fingers from keyboard :)
<wpwrak>
added. thanks !
<qi-bot>
[commit] Werner Almesberger: m1/jtag-boot/: added "standby" (by Cristian Paul Penaranda Rojas) (master) http://qi-hw.com/p/wernermisc/cc2b07b
<wpwrak>
some day, i need to offer the full set of targets. e.g., also rescue
<wpwrak>
and retrieve/decode the configuration status
<kristianpaul>
I still not get fully understand the boundary scan, is like reading TPs with logic states?
<kristianpaul>
so you can confirm a exspected series of values?
<wolfspra1l>
yes this boundary scan sounds interesting - I also don't fully understand what it does
<wolfspra1l>
but is it some test we can run on each m1 board to better test the board?
<kristianpaul>
hum !! also icap support for multi bit stream boot from jtag commands
<kristianpaul>
s/boot/load
<wpwrak>
a boundary scan is basically access to all the i/o pins. but it seems you have to control them all at once. so you can't just pick one and change it (apparently) while the rest of the system keeps running
<wolfspra1l>
ok but what is being tested?
<kristianpaul>
ah just i/o..
<wpwrak>
wolfspra1l: seems that boundary scan doesn't support pull-ups (or pull-downs, not sure if the fpga has both)
<kristianpaul>
all at once sounds "dangerous"
<wpwrak>
kristianpaul: jtag is often used for other things as well. that's when things get murky :)
<kristianpaul>
for the porpuse of the test i mean
<wpwrak>
wolfspra1l: basically the communication between the chip and its surroundings
<wpwrak>
of course, you could load a purpose-built bitstream that does whatever you want. loading a bitstream via jtag is one of those extensions that go beyond the traditional boundary scan
<kristianpaul>
but thats mean you need still need to feed surrounding signal, wich of course make sense
<wolfspra1l>
our current test goes through all peripherals
<wolfspra1l>
and specifically tries to send data through every wire and verify that it arrived
<wolfspra1l>
what does the bounday scan add?
<wpwrak>
so the traditional boundary scan may lack flexibility. but we could certainly make use something similar for board testing
<wolfspra1l>
some pins of the fpga are unconnected - what can be tested there?
<wolfspra1l>
the only thing we don't test now is the expansion header
<wpwrak>
wolfspra1l: you could test for shorts and such that wouldn't normally show up. e.g., because one line overrides the other
<wolfspra1l>
hmm
<wolfspra1l>
sounds like very few additional cases could be caught
<wolfspra1l>
if there is a short, whatever test we have now will also fail
<wpwrak>
not all invalid conditions will yield invalid results all of the time :)
<wpwrak>
you may also have pins that you can short only for a certain amount of time, before this causes damage
<wpwrak>
so one test would be to pull all the pins high (except for those where this would upset peripherals). then walk though them, drive one at a time low, then read back the rest. see if any of the others has gone from high to low. (again, except cases where peripherals affect this)
<wpwrak>
repeat for pull-low and drive high, if possible
<wolfspra1l>
testing all peripherals and all i/o whether it works looks a little more targeted to me :-)
<wolfspra1l>
yes I can see how some rare cases can be caught like that, but those cases are not very clear to me now, neither their likelihood, nor whether the existing tests would already catch them
<GitHub198>
[softgpsreceiver/gps-sdr] yafss new api - Cristian Paul Peñaranda Rojas
<wpwrak>
if you do it right, you can even auto-identify what external components are on a chip, without telling your test system about your circuit ;-)
<kristianpaul>
so a pcb layout should be tought very well if you want to take fully advantage of this bscan it seems
<kristianpaul>
or no?
<wpwrak>
that things was more a proof of concept than anything else. so it's kinda messy to use.
<wolfspra1l>
kristianpaul: what do you mean with "take full advantage"
<wolfspra1l>
I still don't get it
<wolfspra1l>
some test is cool because it's cool :-) like a roller coaster ride?
<wpwrak>
bscan/README and bscan/example/README would be the thing to look at. i would expect that similar but more advanced tools exist elsewhere
<wolfspra1l>
if you have to design a pcb to "take full advantage" of a test, that sounds scary :-)
<wolfspra1l>
we are testing all peripherals
<wpwrak>
you don;t really need to design the PCB for it
<wolfspra1l>
the tests are thought out in such a way to catch every conceivable error
<wpwrak>
;-)))
<kristianpaul>
well i guess that for some test you need to inject a signal some how
<wolfspra1l>
like the dram tests write and read all sorts of patterns to rule out problems with the wires etc.
<wolfspra1l>
I would first like to understand which additional (!) error case can be caught with a 'boundary scan'
<wolfspra1l>
not needed now, just saying
<wolfspra1l>
some tests we could add are temperature cycles, but most likely only for design verification, not for each board
<wolfspra1l>
the magic boundary scan can most likely not replace those tests :-)
<kristianpaul>
wpwrak: not going depth this bscan sounds to me for focused on PCB and verify traces etc, thats was i wondering how i can really try to test as much as i can with it ;)
<wpwrak>
things like shorts or other abnormal current paths. e.g., those weird suspected ESD damages (the NOR oscillation) ought to show up on such a test
<wolfspra1l>
kristianpaul: we are verifying traces
<wolfspra1l>
that's why we go through _all_ peripherals, and put a load on each that will demonstrably verify each trace
<wpwrak>
you can of course do a boundary scan without using anything that's labeled boundary scan
<wpwrak>
but a purely functional test that doesn't probe for effects that affect the principal function may not catch all the cases
<kristianpaul>
he, i want sat that for chipscope ;)
<wpwrak>
a boundary scan basically takes everything one level lower. you don' think about chip functions but about pins instead
<kristianpaul>
s/sat/said that
<wpwrak>
a device may appear to function on the outside but it's still defective
<wolfspra1l>
still sounds theoretical
<wolfspra1l>
we are testing every peripheral, every i/o
<wpwrak>
e.g., parasitic effects can drive signals. if you're (un)lucky, they just produce the level your functional test expects
<wolfspra1l>
the purpose is to make sure that each peripheral/device works as expected
<GitHub13>
[softgpsreceiver/gps-sdr] yafss new api - Cristian Paul Peñaranda Rojas
<GitHub13>
[softgpsreceiver/gps-sdr] namuru debug commands now on rtems shell - Cristian Paul Peñaranda Rojas
<wolfspra1l>
once that is the case by definition it's not 'defective' :-)
<wpwrak>
do you also test current consumption in relation to the system state ?
<wolfspra1l>
additional tests are great, but they need to be targeted and catch something the other tests don't catch
<wolfspra1l>
oh sure, Adam is very picky about current consumption as you can imagine
<wpwrak>
so for each configuration state, you have a precise system-wide current consumption ?
<kristianpaul>
each could be a loooong list i think :)
<wpwrak>
e.g., base state = xxx.xxx mA. turn MIDI on = xxx.xxx mA. turn MIDI off but audio codec's oscillator on = xxx.xxx mA. send a 0 on NOR D0 = xxx.xxx mA. send a 1 instead = xxx.xxx mA ? etc.
<wpwrak>
very very very long :)
<kristianpaul>
of course computers are fast those days :)
<wpwrak>
but you need to do such things to find shorts. e.g., if two pins are, by accident, driving the same signal with conflicting values, one may always "win". so if the one is the pin you actually expect to drive this signal, you don't see anything abnormal.
<wpwrak>
except that the system will consume more current
<wpwrak>
and maybe this will reduce the system's lifespan. or have other effects, e.g., on a system condition the functional test didn't include. (i highly doubt the functional tests test every corner case)
<wpwrak>
i'm sure DocScrutinizer has a nice collection of horror stories for what can happen if you short a chip's output to something else :)
<roh>
i also think that measuring current is a good 'catchall' test
<kristianpaul>
sure we agree, but not get mad with a not end number of combinations
<wpwrak>
current measurement can also replace a lot of other tests. e.g., if you have a LED, a current test can tell you if it's open, shorted, or working :)
<wpwrak>
kristianpaul: you basically want to have a model of the device. then generate the test patterns from this.
<kristianpaul>
you can do current test by bscan?
<kristianpaul>
i mean current measurement
<wpwrak>
you need a measurement instrument for this
<wpwrak>
the boundary scan itself doesn't contain any such things
<kristianpaul>
but bscan can help you to open/close some gates and path current to the righ intruments i guess
<DocScrutinizer>
my words since 2008
<wpwrak>
but you can set up your system to a quiescent state where, say, the LED is off, measure system current, then turn on the LED and measure again. if the current doesn't change, something is broken.
<wpwrak>
if it goes up by, say, 10 mA (exact value depends on design), the LED is lit. if it's considerably more, something is shorted.
<wpwrak>
kristianpaul: exactly
<DocScrutinizer>
you can't even "test each peripheral for correct function" as supposed above. There are LOTS of functions that are hard to impossible to test. Think overcurrent signals, IRQs that usually don't fire, RTS/CTS etc pp
<wpwrak>
yup. lots of things that are very hard to trigger :)
<wpwrak>
it's more like driving a car around the block and then declaring it to be in good working order :)
<wpwrak>
it's more a test of the absence of obvious fatal flaws
<roh>
well.. i am not saying that all boards need to be in a 10mA window to be 'good' ... just that something which draws >150mA more than everything else working might be 'fishy'
<DocScrutinizer>
you usually do A|B tests with DUT and reference, and probe and compare as many parameters as possible
<DocScrutinizer>
also drive VDD to and beyond the limits
<DocScrutinizer>
etc pp
<wpwrak>
of course, it's nice as a sanity check. prevent "missed the burning forest but all the trees looked good" kind of mishaps :)
<wpwrak>
roh: an absolute 10 mA window is unrealistic, already due to component tolerances. but a relative 10 mA window, e.g., board X with LED off vs. board X with LED on, that is quite realistic
<wpwrak>
and of course, of you have a board Y that's 10% higher in general than board X, you may have a problem there :)
<DocScrutinizer>
then you design a special test program that intentionally triggers as many of those fringe cases that usually never happen, like FIFO overflows and whatnot
<DocScrutinizer>
setting those 10% margins is pretty simple, after 10 DUT's runs you have a god statistic base what'S ok and what's fishy
<wpwrak>
wolfspra1l: these things don't have to be a nightmare to do. if you automate them properly, they're not any worse than extensive functional tests
<DocScrutinizer>
exactly
<DocScrutinizer>
my words since 2007
<kristianpaul>
wasnt 2008?
<DocScrutinizer>
but OM never been interested in *decent* QA tests in fab :-/
<wpwrak>
my code since 2006 ;-) (well, somewhat)
<wpwrak>
DocScrutinizer: don't test for bugs you're not prepared to handle (-:C
<kristianpaul>
hum??
<roh>
*g*
<kristianpaul>
i dont think we looks for bugs, i wonder who find who first ;)
<wpwrak>
the somewhat difficult business relationship between OM and the factory may also have played into this to some extent
<wpwrak>
not that i would have had high hopes for actually getting such things right, but this situation may have prevented them from even being considered
<wpwrak>
after all, any board that fails is a yield problem. now, who gets the blame ? and whoever gets blamed is still convinced it's the other side's fault, so they'll hold a grudge. and so on.
<wpwrak>
not the ideal climate for being good at detecting defects :)
<wpwrak>
the less you find, the fewer incident on the home front :)
<wpwrak>
the customers are far away. and maybe they don't notice either :)
<roh>
pfff.. blame problems
<wpwrak>
of course, that's generally a problem. good QA will invariably run into situations where any bad news they may have will be extremely unwelcome
<roh>
i have heard from people working inside a big german industrial hw manuf, which do proper testing how that goes
<roh>
these guys even do real clima-chamber tests etc
<roh>
at one time we got switches from their lab with temperature sensor wires still hanging from some holes, taped to the top with gaffa
<wpwrak>
roh: but i bet that wasn't a "the three stooged make a smartphone" kind of setting
<roh>
naah. they build stuff.. as well as switches spec-ed to be used in railway and underground tunnels etc.
<roh>
they even got ip67 proof switches.. nice stuff... tricky connectors ;)
<wpwrak>
rubber seals ?
<roh>
from regular vendors we get sometimes stuff with loose smt caps inside... *sigh* .. how many times we soldered such stuff on before using equipment on a ccc event ;)
<wpwrak>
the tragedy of the lowest bidder :)
<roh>
wpwrak: not only.. pressure-cast aluminium cases with seals and plugs with seals etc. but their ip67 line is afaik still 100mbit.. no gbit connectors avail in pressure proof or so
<wpwrak>
just make little sealed enclosure around it ? like a barrel, rubber seal at the front, a thread on the outside and a nut to hold it all down ?
<roh>
heh.. i bet that will never be ip6x ;
<wpwrak>
dust and water. doesn't sound *that* difficult
<roh>
ip67 is 1meter deep immersion
<wpwrak>
yes. rubber seal :)
<roh>
pressure is your issue. all connectors need to go through fittings. just a 'clamp style seal' doesnt work
<wpwrak>
i would screw it in place. or maybe have a bayonet or such
<wpwrak>
of course, that would be a special-purpose item, even if relatively simple. so it won't be cheap
<wpwrak>
basically the way how you'd connect ethernet in docked space stations - you just leave the door open and run the wire across. maintaining the docked and sealed state is a problem someone else has already solved for you :)
<kristianpaul>
any other way of automate ftp transaction besides using expect ?
<roh>
hm. ncftp?
<wolfspra1l>
kristianpaul: curl
<kristianpaul>
nice curl support telnet as well
<DocScrutinizer>
D-Link those suckers! Thanks to "Error! End time needs to be later than start time" for daily periods I can't define a 1 minute downtime for DSL at 6:30 in the morning :-(
<roh>
DocScrutinizer: get a real modem
<roh>
can recommend these 4E adsl2+ ones from pollin (congster type)
<roh>
no it cannot do anything besides bridging, but it does that very well :)
<roh>
and they are so cheap you can get a pack an have some spares for the next shitty-weather-event
<wolfspra1l>
4 EUR, and 3 EUR if you buy three
<wolfspra1l>
in China you probably buy the entire box for 1 USD
<wolfspra1l>
maybe 1.50 :-)
<roh>
naah.
<roh>
afaik they are some oem variant for congster (german telecom cheap prices brand).. dunno why. maybe because they have no switchmode-psu
<roh>
its a broadcom cpu, minimal flash and ram (thats why openwrt isnt possible). .. bcm63xx series cpu. quite fast
<wolfspra1l>
naah what? you think it's not sourced in China and sells here for 1.50 USD?
<wolfspra1l>
those kind of prices are pretty much only possible if you have companies that can operate on super thin margins, and have high volume, i.e. serve the world
<roh>
wolfspra1l: as far as i understand it that price is 'written off hw' .. only sold because its better than scrapping
<roh>
usually modems of that spec still are 10-20Euro
<roh>
my best guess still is the psu.. its a ac-ac heavy old transformer type. surely not latest EU-power-saving-regulation compliant
<wolfspra1l>
"written off" - hmm. dunno.
<wolfspra1l>
I'm not surprised about the price.
<roh>
pollin is known as 'resterampe' 'grabbelkiste'
<wolfspra1l>
if it's new, it's from China and made for the world, sells as 100 different brands here and there
<wolfspra1l>
if it's a one-off thing, ok, that's different
<roh>
i would be surprised if you can buy the bom even in big numbers for the used chips for these 4E
<wolfspra1l>
why not
<roh>
really fresh soc. its faster than the nanonote afaik
<wolfspra1l>
so?
<wolfspra1l>
we don't know the story behind this product, so it's just speculation
<wolfspra1l>
but in high volume chip prices come down, and become more a factor of die size
<roh>
ah.. no.. sorry.. misplaced it.. its slower.. 250mhz
<wolfspra1l>
the chinese manufacturer probably can pick from a number of silicon vendors to make a 'dsl modem box'
<wolfspra1l>
so if broadcom wants to get a little volume into their system, they need to make a price based on die size + x%
<wolfspra1l>
if their die size is uncompetitive, that's their problem. that's why you typically do another tape-out once you have achieved a 20-30% die size reduction
<wolfspra1l>
then you will make back the tape-out costs over time (depends on volume of course)
<wolfspra1l>
this is all assuming it's a new price, not some one-off
<roh>
i think in that market its not so much choice anymore..
<wolfspra1l>
don't say that :-)
<wolfspra1l>
you don't think some Chinese foundry can clone Broadcom chips?
<roh>
not so many soc i know which can handle the big telecoms here in europe. (its the tcom who makes the spec which the modem then is made to fulfill)
<wolfspra1l>
if the soc is produced at 90nm or higher, it can definitely be cloned
<wolfspra1l>
that brings prices down quickly :-)
<roh>
i think they can clone it. but the german telecom wouldnt buy it. they can get brcm to do their bidding as dictated
<wolfspra1l>
in your dreams
<wolfspra1l>
the reason the price comes down is because Broadcom (in this scenario) understands that it makes no sense to fight mother nature
<wolfspra1l>
so yes, Broadcom can charge die size + 20%
<wolfspra1l>
because it's 'original'
<wolfspra1l>
whereas the no-name foundry would charge die size + 5%
<wolfspra1l>
they rather take those 20% than be 'right' but out of business
<wolfspra1l>
if it's indeed a new price, would be interesting to look at the chips
<wolfspra1l>
at 4 EUR, it's getting tight
<wolfspra1l>
that's minus VAT etc.
<wolfspra1l>
amazing
<roh>
its unused, original packaged
<wolfspra1l>
but I've seen similar amazing things here, like the silicone keyboards we include with m1 that we source for 2.50 USD or so
<wolfspra1l>
2.50 USD!
<wolfspra1l>
I took one apart
<wolfspra1l>
so many parts, so many pieces
<wolfspra1l>
pcb
<wolfspra1l>
cable
<wolfspra1l>
usb connector
<roh>
the recommended price was 99E
<wolfspra1l>
three plastic layers to form connecting pad
<wolfspra1l>
a chip on the pcb, some passive parts
<wolfspra1l>
a led
<wolfspra1l>
silicone
<wolfspra1l>
plastic case, even a 1-page manual
<wolfspra1l>
and it retails for 2.50 USD
<wolfspra1l>
everybody in the supply chain operates on a few cents
<wolfspra1l>
it does say 'out of stock', so our speculation may be pointless
<DocScrutinizer>
roh: I need a router, not a modem
<roh>
eh. i see
<DocScrutinizer>
DIR-615 here. Is this POS openWRT capable?
<roh>
cheapest i know.. 24euro thingie from km-electronic. some tp-link
<roh>
841 or 741 or so.. would need to check again
<roh>
uh.. the dlink.. which revision do you have?
<roh>
hm. small flash but the page says possible. no usb also
<DocScrutinizer>
D3E even
<DocScrutinizer>
yeah, no USB obviously :-D
<roh>
Ralink?
<roh>
hm.. D1 and 4 seem supported.. but i dont see D3.. weird
<DocScrutinizer>
yeah
<wolfspra1l>
roh: do you know much about developments in routers?
<wolfspra1l>
more or less Linux?
<wolfspra1l>
integrated dsl or cable modem? integrated wifi?
<wolfspra1l>
is it becoming harder or easier to install something like openwrt?
<wolfspra1l>
I don't follow routers closely, unfortunately. too little time...
<roh>
wolfspra1l: i prefer to keep those seperated
<wolfspra1l>
so it's just a black-box to you?
<roh>
there isnt really any vendor free complete atm implementation atm
<wolfspra1l>
oh I see. you keep the dsl modem separate.
<roh>
yes.. the wan phy. because its cheap and can be seen as a transparent bridge usually.
<roh>
e.g. we have cable and nat-ed dsl here.. i can just move the 'wan' ethernet cable from one to the other to switch from cable to vdsl
<roh>
stuff breaks and it makes replacements easier/more practical for us
<roh>
wolfspra1l: the most important development from my pov is 'shorter lifespan' as well product-cycle wise as well as cheaper entry hw
<roh>
i think larsc or nbd know details there much better than i am
<roh>
what i would wish for is a more decent amount of ram and flash and better performance.. then i would do more on these small machines
<roh>
also to seperate from the market a bit. one cannot compete with 24E devices if its about supporting sw development
<roh>
people paid insane amount of money for the 'good' old routers with minipci slots and 32mb ram for some time
<roh>
i can be wrong but afail there is no 'mainline supported' platform atm..  atleast not intended by the vendor
<roh>
wolfspra1l: what are you thinking about?
<wolfspra1l>
nah, just following
<wolfspra1l>
I think prices will continue to fal
<wolfspra1l>
fall
<wolfspra1l>
more integration, higher volume, etc.
<wolfspra1l>
but I don't know, so I'm curious. And you gave me some good answers already - thanks!
<roh>
k
<DocScrutinizer>
in the old days that's been called MAU iirc
<DocScrutinizer>
media attachment unit
<DocScrutinizer>
just nowadays it's not yellow cable but TV cable, or DSL
<DocScrutinizer>
wolfspra1l: keep an eye on AVM
<DocScrutinizer>
if there's such a thing like a "standard" here then it's FritzBox
<wpwrak>
(EUR 4 bridge) you could probably make some money by trowing away bridge and power supply and just selling the ethernet cables individually ;-)
<DocScrutinizer>
you can also make money here by copying EAN barcodes and stick them to arbitrary plastc bottles, then insert to return machines and get a coupon about 15ct per bottle
<DocScrutinizer>
less efort than making money on selling crappy ethernet patchcables
<qi-bot>
[commit] Werner Almesberger: m1rc3/norruption/LOG: still trying to reproduce the NOR corruption ... (master) http://qi-hw.com/p/wernermisc/50d66bf
<qi-bot>
[commit] Werner Almesberger: fped/gnuplot.c (gnuplot_arc): implemented drawing of arcs (master) http://qi-hw.com/p/fped/6dfbb51