<cr1901_modern>
Why don't most of the tests added declare inout ports anywhere?
<rqou>
whitequark: does the yosys "deminout" command not work around your arachne issue?
GenTooMan has quit [Quit: Leaving]
rohitksingh_work has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
<rqou>
wait azonenberg your scope was new or otherwise under a service contract still?
<rqou>
azonenberg: btw just out of curiosity, how much do you think it would cost me to get my scope "officially" calibrated?
<rqou>
i have an ancient TDS3054 (no suffix) that has been out of cal for over a decade
digshadow has joined ##openfpga
<azonenberg>
whitequark: it was built in february of last year, i bought it in... september ish?
<azonenberg>
3-year warranty
<azonenberg>
rqou: *
<rqou>
oh, so you actually bought it new
<azonenberg>
This is my lecroy, not the rigol
<azonenberg>
Yeah it was $5K including all of the options and accessories
<rqou>
huh
<rqou>
less than i expected
<azonenberg>
350 MHz 4 channel 4 Gsps
<rqou>
ooh
<azonenberg>
I got a good deal from tequipment.net
<rqou>
i thought it was higher-spec than that
<azonenberg>
they sold me the 350 for the price of the 200
<azonenberg>
Well i'm already planning an upgrade
<rqou>
lecroy usually is high-end i think?
<azonenberg>
The wavesurfer 510 is my wishlist scope for the new lab post move
<azonenberg>
also a lecroy
<rqou>
i didn't even realize they had a 350 mhz scope
<azonenberg>
1 GHz 10 Gsps
<azonenberg>
$12900 for the base model, plus a bit more if you want the logic analyzer or any software packages
<rqou>
currently i'm apparently still "winning" with a 500 mhz 5 gsps scope :P
<rqou>
except the sample memory is shallow AF which absolutely _sucks_ to use
<azonenberg>
how deep is it?
<rqou>
10k samples iirc
<rqou>
this thing is from like 2000
<azonenberg>
my current lecroy is good out to 10M samples
<rqou>
hey, memory was _expensive_ back then
<azonenberg>
The ws 510 is 16M by default and can be upgraded to 32M
<rqou>
but yeah, i'd probably totally accept a trade for a 350 mhz scope with ~million sample depth
<rqou>
because 10k points _sucks_ to use for anything i actually want to use it for
<azonenberg>
Yeah
<azonenberg>
The wavesurfer 3000 series doesnt seem to be sold anymore but the 3000Z series is still available
<rqou>
it was probably pretty decent in 1998 :P
<azonenberg>
i think 3000Z is probably a tiny bom change because some chip went eol or something
<azonenberg>
they look identical in specs, front panel, etc
<azonenberg>
Except memory expanded to 20M points
<rqou>
so when do we get ZoidbergNovenaStarshipRaiderScope? :P :P
<azonenberg>
The 3034Z is list price $6500, tequipment has it for...
* azonenberg
looks
<azonenberg>
they have a non-Z 3034 for $5500
<azonenberg>
And a 3024 (200 MHz) for $3800
<azonenberg>
I got mine for that price
<azonenberg>
then the options brought it up to about 5k
<rqou>
when do we get ZoidbergNovenaStarshipRaiderScope? :P :P
<azonenberg>
rqou: starshipraider will be used as a development platform for a scaled down version of my scope frontend, actually
<azonenberg>
probably competitive with a rigol, 1 Gsps 100 MHz or thereabouts
<rqou>
yeah
<rqou>
iirc novenascope is similar
<azonenberg>
Might have to go a little slower, depends on how much bandwidth i can push to the artix (and whether i go to a kintex on the full version of starshipraider)
<azonenberg>
The *full* scope is going to be a standalone 1U unit
<azonenberg>
probably similar form factor to my switch
<azonenberg>
a brain card, a backplane, and a bunch of daq cards
<azonenberg>
Depending on how fast the FPGAs i get are, i may have to put an fpga on every channel to get enough serdes
<azonenberg>
how fast the ADCs are*
<rqou>
i hope you don't hit all the issues whitequark/m-labs are hitting with their ADCs
<azonenberg>
My target for that is to be performance competitive with the lecroy ws510 (10 Gsps 1 GHz, 8 bit)
<azonenberg>
Except with much higher WFM/s over LAN
<rqou>
(no, I don't know exactly what the issues are)
<azonenberg>
Since instead of doing a software networking stack and 1000baseT, it'll be TCP offload and 40GbE
<rqou>
yeah, specs like that are basically the useful limit of "everyday use" oscilloscopes
<rqou>
unlike e.g. the one i used at BRCM
<azonenberg>
And also much more advanced analytics since they don't do eye measurements or any of the "fun" stuff
<azonenberg>
even the ws510 doesn't do that actually
<azonenberg>
i priced out a higher end $40K ish lecroy as well, 40 Gsps 4 GHz
<azonenberg>
just for lulz
<azonenberg>
That is apparently the range you have to go in to get the high-end capabilities like serial data decode and eye measurement
<rqou>
iirc what the exact specs were, but the scope I used at brcm was too slow for the serdes on all of the newer parts but didn't easily go down enough to capture i2c in a useful way
<rqou>
so it just sat very lonely in the lab :P
<azonenberg>
Sampling scope?
<rqou>
no, but not amazing sample depth combined with not low enough sampling rates
Bike has quit [Quit: Lost terminal]
<azonenberg>
oh lol
<azonenberg>
All of my gear will work just fine down to dc'
<azonenberg>
i dont want to give up low speed performance to get high speed
<azonenberg>
However, it will be 50 ohm input only
<azonenberg>
By design
<azonenberg>
Use a Z0 probe or active probe
<rqou>
eventually i asked them to rummage around and find be a random 250 mhz Keysight
<rqou>
*me
<rqou>
much better :P
<rqou>
hilariously, i also rummaged around after that and found a total phase i2c tool that somebody was hiding :P
<azonenberg>
you realize those are just an ftdi plus some level shifters right?
<azonenberg>
:p
<rqou>
is it?
<azonenberg>
pretty sure yes
<awygle>
Aardvark or Beagle?
<azonenberg>
aardvark
<azonenberg>
The beagle is more complicated
<rqou>
the one that doesn't do usb :P
<awygle>
They've updated since but the original Beagle was just the aardvark but can't master
<rqou>
the "Beagle I2C/SPI Protocol Analyzer"
<awygle>
We used way too many of those at Planetary
<azonenberg>
oh when i hear beagle i think the usb analyzer
<rqou>
in my limited experience the total phase hardware is pretty crap, but the software is nice
<awygle>
Eh they were both pretty crap tbh
<awygle>
I had a big problem sourcing 5mA from the 5V output on the aardvark, which was rated to 20 iirc
eddyb has quit [*.net *.split]
jhol has quit [*.net *.split]
pointfree has quit [*.net *.split]
grummel has quit [*.net *.split]
bibor has quit [*.net *.split]
asy has quit [*.net *.split]
asy has joined ##openfpga
jhol` has joined ##openfpga
<rqou>
i wonder if we can build a USB 3.0 analyzer for <=$1k?
<rqou>
(BOM cost)
bibor has joined ##openfpga
grummel has joined ##openfpga
pointfree has joined ##openfpga
* azonenberg
poke lain
<rqou>
since the total phase thing is priced at a whopping $5k
<awygle>
With what, daisho?
<awygle>
(some bits thereof)
<rqou>
idk with what
<rqou>
i don't know enough about the usb physical layer
<azonenberg>
rqou, awygle: lain and a few other folks are working on making one, not sure how much they want me to say about implementation / architecture
<awygle>
Ah
<azonenberg>
But it's an active wip
<awygle>
Cool yo
<rqou>
why secret?
<azonenberg>
rqou: it's going to be a commercial product presumably
<awygle>
Hax :-P
<rqou>
hrm
<azonenberg>
i imagine the goal woudl be to undercut the total phase stuff
<azonenberg>
But idk by how much
<rqou>
time to undercut their project with _the power of FOSS_ :P :P :P
* awygle
rolls eyes
* awygle
winces due to headache
<openfpga-bot>
[jtaghal-apps] azonenberg pushed 1 new commit to master: https://git.io/vpai0
<openfpga-bot>
jtaghal-apps/master ae8415e Andrew D. Zonenberg: Fixed paths
<awygle>
Is the D for Doctor?
<rqou>
dr zoidberg :P
<azonenberg>
lol no thats my actual middle initial
<azonenberg>
I'm starting to use it more to avoid confusion with my cousin andrew
<rqou>
oh, i have code i forgot to push
openfpga-github has joined ##openfpga
openfpga-github has left ##openfpga [##openfpga]
<openfpga-github>
openfpga/master 2b63f45 Robert Ou: xc2bit: Finally achieved deriving all the useful traits
<openfpga-github>
openfpga/master 310cdd9 Robert Ou: xc2bit: Begin attempting to convert IOBs to use small arrays
<openfpga-github>
openfpga/master 04f0b59 Robert Ou: xc2bit: Start giving up on ever getting proper large array support...
<openfpga-github>
[openfpga] rqou pushed 3 new commits to master: https://git.io/vpaia
<rqou>
apparently rust can hack Copy/Clone to work for large arrays but somehow other traits are just not possible to implement that way?
<rqou>
idk how this part of the compiler works
<azonenberg>
lol
<azonenberg>
sooo i just found a bug in my eye diagram rendering code
<azonenberg>
Apparently if you oversample excessively it crashes
<azonenberg>
root cause is, when the waveform has more than 32768 samples per UI
<azonenberg>
cairo fails to create a bitmap
<azonenberg>
because it can't make a texture >32k pixels on a side
<rqou>
solution: stop using cairo :P
<azonenberg>
I'm going to move to GL for sure
<rqou>
just ask for a Gl/Vk buffer thingy directly
<rqou>
(idk how to actually use these apis)
<azonenberg>
Althoguh realistically
<azonenberg>
GL does have a max texture size too
<rqou>
why do all the tutorials for "how to graphics" _suck_?
<azonenberg>
i need to re-learn GL
<azonenberg>
i learned the fixed function pipeline back in the gl 1.3 days
<azonenberg>
i've barely touched shaders and now you can't render anything without them
<azonenberg>
That being said i do need to rewrite my app in GL for certain
soylentyellow has quit [Ping timeout: 248 seconds]
soylentyellow has joined ##openfpga
FabM has quit [Ping timeout: 248 seconds]
FabM has joined ##openfpga
bitd has joined ##openfpga
<whitequark>
cr1901_modern: they do
<whitequark>
read run-test.sh
<daveshah>
whitequark: thanks for your arachne-pnr PR! It's nice to have a longstanding issue fixed. I'll check it over the weekend and get Clifford to merge it
<daveshah>
At the moment we've kind of ignored the CI and done manual hardware regression tests
<daveshah>
But it's something that should be fixed
<whitequark>
daveshah: so, I'm not 100% happy with it
<daveshah>
There have also been discussions, if we get cseed's approval, to move arachne-pnr to the SymbiFlow namespace and fix the formatting at the same time
<daveshah>
It drives me nuts
<whitequark>
I do believe that what's added and tested works, but it might not quite be enough
<whitequark>
I think a proper fix would involve recording the direction of gates specified by the .names command
<daveshah>
whitequark: yeah, the BLIF file format is crap and that's really the ultimate problem
<whitequark>
this is because a .names q[0] q[1] and a .names q[1] q[0] are not the same when both q[1] and q[0] are inout
<whitequark>
no, it's not that
<whitequark>
arachne-pnr throws away information it has from the blif
<daveshah>
I see
<whitequark>
because for cases where it doesn't have inout it doesn't matter
<whitequark>
migen has crappy support for inout too
<whitequark>
rqou: hmmmm
<daveshah>
whitequark: if I'm looking correctly I3C disappears from blif.cc in your PR??
<whitequark>
daveshah: it's using the Models class now
<whitequark>
which has support for I3C in is_ioX
<whitequark>
hang on
<whitequark>
yes
<whitequark>
that's what's happening
<daveshah>
whitequark: yeah, that's fine
<daveshah>
just looked odd
<daveshah>
FYI, Clifford prefers split PRs so maybe you should put CI/test stuff in another PR
<whitequark>
daveshah: I prefer projects without broken tests
<whitequark>
if you have your shit broken and I fix it, don't complain that I don't do it in exactly the way you want
<whitequark>
tbh
<whitequark>
rqou: hm, deminout does look like what I want, and it's in synth_ice40 pipeline
<whitequark>
but it doesn't actually do anything because it would need to be invoked after splitports
<clifford>
whitequark, it's not "our shit". If it were "my shit", the first thing I'd fix is the horrible indenting and the second is the test.
<clifford>
You want to become maintainer of arachne-pnr? Be my guest! Right now it is unmaintained.
<whitequark>
clifford: maybe
<whitequark>
what's the process for that?
<clifford>
The reason we prefer small isolated PRs is because that makes it easier to review stuff and make sure we don't break anything while trying to just fix the most important issues, because, who kowns, maybe cseed will come back one day and maintain it again.
<clifford>
There is no process. Nobody knows who to reach cseed.
<whitequark>
sigh
<whitequark>
ok
<whitequark>
do you require me to split this PR, or can you just open the individual commits and look at them?
<clifford>
Just fork it and maybe you are unlucky and cseed comes back tomorrow and insists that this is his project and your stuff is just an unofficial fork.
<clifford>
Whatever daveshah is happy reviewing. When david says the PR looks good and is not breaking anything then I will just click on that merge button. :)
<daveshah>
I'm fine this time, at least it is separate commits - the biggest problem is when someone submits a load of stuff in different commits
<whitequark>
cseed has commented on something in the last 17 hours
<daveshah>
yeah, but he's totally disappeared from anything arachne related
<daveshah>
he got a new job and now he's very busy last I heard
<whitequark>
well, I asked cseed to make some statement about the future of arachne-pnr
<daveshah>
thanks!
<daveshah>
just being able to reformat it would be nice
<whitequark>
clifford: assuming he is ok with them I will probably maintain it to some degree, given that I need it for my work
<q3k>
++ for unfucking^Wcleaning up arachne
<whitequark>
there will be no major investment of time since I lack any but it won't be completely unmaintained either
rohitksingh_work has quit [Read error: Connection reset by peer]
<daveshah>
whitequark: that's absolutely fine, having a proper maintainer is the main thing
<daveshah>
I'm happy to continue helping to review stuff if you would like
<whitequark>
I'll definitely need help with that since I do not have an in-depth understanding of its guts
<whitequark>
it doesn't seem that complicated and is fairly well written but still
<whitequark>
clifford: what do you think about doing something like `splitnets i:* o:* %u` before `deminout` in synth_ice40?
<whitequark>
(or maybe `select i:* o:* %u ; splitnets`, I'm not completely sure how that works)
<whitequark>
s/splitnets/splitnets -ports/ above
<clifford>
Yea, "splitnets -ports". Otherwise it's a no-op. :)
<whitequark>
is there any downside there I don't see, or should I just test this and submit a yosys PR?
<clifford>
My first thought: It would work well with -noflatten...
<whitequark>
I admit I do not understand what -noflatten is for
<clifford>
It does not flatten the design
<whitequark>
well yes, I understand that, but why?
<whitequark>
isn't everything flattened in the blif in the end?
<clifford>
So then splitnets would chenge the interface of non-top-modules without fixing the instantiations, breaking the design.
<clifford>
No. BLIF does support hierarchical designs. Arachne does not at the moment.
<clifford>
But other tools that can read BLIF might.
<whitequark>
oh ok, so hypothetically, -noflatten may be used if you wanted to do floorplanning
<clifford>
yes
<whitequark>
ok
<whitequark>
thanks for explanation, I conclude that I'll need to finish unfucking inout support in arachne instead
<whitequark>
grumble, tristate support in both verilog and tooling is awful
<clifford>
I think arachne-pnr should be fixed to work with those inout ports. I added the deminout as a work-around because I did not know how to fix IO buffer instantiation in arachne.
<whitequark>
ahh.
<whitequark>
hm and I *think* I found another bug in tristate handling in yosys
<clifford>
Yes, tristate is awful. Tbh I just instantiate SB_IO in my designs if it is not a simple input or output port.
<clifford>
okay, what is the bug?
<whitequark>
let me make a minimal repro
<clifford>
(I'm also not sure if arachne is currently smart enough to merge FFs into the SB_IO.)
<whitequark>
arachne isn't.
<whitequark>
PIO handling in it is very naive
<whitequark>
merging of FF into SB_IO might actually be better as a yosys pass, maybe?
<whitequark>
since then it would benefit any PNR workflow
<clifford>
Can't be done in Yosys. We need to know which IOs share the same clocks in order to know when to pack FFs into the IO buffers. For that we need placement info.
<whitequark>
oooh right, they come in pairs
<whitequark>
hypothetically speaking, if a constraint file was available to yosys, it could be done in yosys, right?
<whitequark>
I see that it would be a major departure from how things are done, that's true
<clifford>
Afaics yes.
<clifford>
But it would be unlikely that iopadmap is of big help, so it would need to be a architecture-specific yosys pass. So therefore we could as well do it in the architecure-specific tool.
<whitequark>
clifford: is there a way to make warnings in yosys such as "multiple drivers for the net" hard errors?
<whitequark>
why are they warnings in the first place?..
genii has joined ##openfpga
<whitequark>
`check -assert`
<whitequark>
clifford: ok, so `check -assert` works (and I need to thread that in synth_ice40), but "Driver-driver conflict" detected in opt_clean doesn't have any way to turn it into an error
<whitequark>
and it produces nasty blifs that have multiple drivers for $false.
<whitequark>
any opinion on the best way to fix that? do I add -assert to opt_clean?
<clifford>
If you can call "opt_clean -assert", can't you also just as easily call "check -assert"?
<whitequark>
clifford: so, I get this warning when opt_clean runs from within synth -run coarse
<whitequark>
the idea is that I would add -assert to synth, synth_ice40, etc, and have it thread all through
<whitequark>
not unlike -Werror, perhaps
<whitequark>
this seems nicer than just inlining `synth -run coarse` into `synth_ice40` or even worse, `synth_ice40` into migen templates
<whitequark>
clifford: though quite frankly, I fail to see why yosys should ever try to build designs with driver conflicts by default
<whitequark>
when is that ever *not* a bug?
<clifford>
There is a "yosys -w regex" option. It hink what you want is the inverse, turning warnings into errors. As part of the framework, not as individual switches to individual commands.
<clifford>
In Verilog? It's not a bug whenever either of the drivers can drive 'z'.
<whitequark>
I know about -w, but it seems awfully ad-hoc
<whitequark>
also, yes, sorry, I wasn't clear enough
<whitequark>
let me rephrase
<whitequark>
if the warning in opt_clean is ever emitted, that means that one of the drivers is a constant
<whitequark>
that means the other driver may only drive a 'z
<whitequark>
ok, I suppose you could have a situation where one driver is a constant 1'b0 (say) and the other is a long string of cells that eventually always resolves to 1'bz
<whitequark>
this would be technically legal although degenerate
<whitequark>
this brings me to the question, how does anyone ever manage to like Verilog? it seems designed to maximize the number of bugs in your FPGA designs
<clifford>
It's a mix of stockholm syndrome and VHDL being even worse for your overall productivity. :)
<whitequark>
if I implemented opt_clean -assert and friends, would you accept the PR?
<whitequark>
I think both mechanisms are valuable, with different goals in mind
<daveshah>
I don't think Lattice add features to their tools in what I count to be 21 minutes...
<whitequark>
well, I always say that Yosys is awesome ;P
<whitequark>
sure, there's tristate, but after looking at it closely I rather sympathize with not having a good implementation there...
<clifford>
daveshah: more like 12 minutes.. :)
<daveshah>
I was counting from whitequark's "clifford: is there a way to make warnings in yosys such as "multiple drivers for the net" hard errors?"
<clifford>
:)
<daveshah>
whitequark: Tristate aside, Yosys is definitely more compatible with designs than either LSE or Synplify, possible even the two together
<daveshah>
I was trying to synthesis a LiteX + LM32 in icecube last night
<whitequark>
daveshah: what
<whitequark>
you're saying that commercial tools are -worse- at handling synthesis corner cases?
<daveshah>
yes
<whitequark>
...
<daveshah>
LSE failed to elaborate a block RAM correctly and left internal primitives that causes P&R to fail in the EDIF
<daveshah>
LSE is crap at block RAM inference
<daveshah>
Synplify Pro just got stuck
<daveshah>
For the NES core, Synplify pro crashed with a "equivalence check failed" internal error
<daveshah>
and LSE has its usual block RAM issues again, as well as issues with certain formats of constants
<whitequark>
that is amazing.
<whitequark>
in a "kill it all with fire" way
<daveshah>
admittedly Yosys slightly loses out for the 5k because of a lack of DSP and SPRAM inferrence
<daveshah>
but still
<whitequark>
SPRAM inference should be reasonably easy
<clifford>
whitequark, re PR: I'm not sure. I still don't see the benefit of of it compared to simply calling "check" with assert. What would be the downside of "synth_ice40 -assert" simply passing -assert to the "check" command?
<whitequark>
clifford: I would like that too, but as far as I can see it is not enough
<whitequark>
specifically, `synth -run coarse` first calls `opt_clean`, which removes one of the two drivers, and then `check`
<daveshah>
whitequark: the problem is Yosys doesn't support combined read and write ports when inferring block RAM yet. It's fixable but it will need some core changes - and I need to write my test suite for Yosys before that happens...
<whitequark>
clifford: so by the time `check` happens the design only has one driver
<clifford>
Ah, because opt_clean threw the other one away. I see...
<clifford>
The problem is that afaic this is a valid optimization. :)
<whitequark>
clifford: yes, I understand. if it was not, I would say make it a hard error :p
<whitequark>
clifford: what I would like yosys to gain is an equivalent of clang's sanitizers.
<whitequark>
as you probably know, most sanitizers just catch UB, but you can enable trap on unsigned overflow, and that catches bugs.
<clifford>
And it can hit whenever one of the drivers becomes a constant, so you would need to make sure you catch all the instances of opt_clean.
<whitequark>
yeah, there's quite a few opt invocations
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
digshadow has joined ##openfpga
<genii>
IEEE, ANSI and ISO docs always seem to reference a plethora of other docs that are then required to go read
<awygle>
most of which require you to pay more money to more organizations
<sorear>
I mean, most papers also have reference
<sorear>
s…
<awygle>
i don't have a problem with references, i have a problem with paywalls
digshadow has quit [Ping timeout: 248 seconds]
<cr1901_modern>
whitequark: >"Online access provided at no cost via the IEEE GET program"
<cr1901_modern>
Which standard did you ultimately get? I don't see any "IEEE GET program" references
<awygle>
cr1901_modern: that's IEEE 1800-2017
<awygle>
(and others)
<whitequark>
cr1901_modern: all of them.
<cr1901_modern>
IEEE 1800-2017 не найдена в базе | article not found
<whitequark>
use a DOI, duh
<cr1901_modern>
Much better
<genii>
awygle: We spent a lot of money of docs like this trying to find out exactly what requirements were for RED certification for an android tablet we had already been selling in the UK for 2-3 years under regular CE stamp
<awygle>
not at all surprising
<azonenberg>
Speaking of annoying standards
<azonenberg>
Is JESD204 paywalled?
<azonenberg>
I dont need it now but might if i do that oscilloscope proejct one day
digshadow has joined ##openfpga
<whitequark>
azonenberg: I have it
<whitequark>
lmk if you need
<balrog>
it's in google cache
<azonenberg>
yeah but i mean, can you just go download it from jedec or do you have to jump through hoops?
<azonenberg>
lol
<balrog>
but going to it directly they request a login
<balrog>
"Registration and most published standards are free, however, selected standards are only available to non-members for a fee."
<balrog>
(but login is required)
<azonenberg>
i already have a jedec account so if it isnt paywalled i'm good
* azonenberg
goes to check
<azonenberg>
Yeah freely downloadable if you have an account
<azonenberg>
i think they even wanted a login for downloading JESD3C, the .jed rom file format
<azonenberg>
and hey, if they want to know how often the standards are being downloaded or something i'm ok with that
<azonenberg>
as long as i can actually *get* it
<sorear>
My biggest problem with these antics is it blocks archive.org
<azonenberg>
oh? it didnt block google
<azonenberg>
conjecture: the free standards spit out a login form for a normal browser useragent
<azonenberg>
but the full pdf for a crawler
<whitequark>
of course
<whitequark>
a lot of websites do that
<whitequark>
change your useragent and...
<azonenberg>
Yep
<azonenberg>
But what i mean is, that wouldnt block the archive bot either
<whitequark>
the archive bot respects robots.txt and uses its own useragent
<whitequark>
many people really hate archive.org
<whitequark>
fuck them
<azonenberg>
i'm honestly surprised it doesnt try half a dozen useragents and, if they get different content, save all of them
<whitequark>
that's not appropriate behavior for a crawler?
<whitequark>
and if they did people would just block it by IP
<azonenberg>
Yeah, it would have to bounce ips
<azonenberg>
At which point it's an arms race
<whitequark>
that's not a job for a nonprofit run by like 2.5 people
<whitequark>
they ought to make a mirror not in north america first
<whitequark>
gotta have that info when canada is a smoking crater
<balrog>
azonenberg: there was discussion of changing the archive.org behaviour
<openfpga-bot>
[jtaghal] azonenberg pushed 8 new commits to master: https://git.io/vpVAR
<openfpga-bot>
jtaghal/master 5820b06 Andrew D. Zonenberg: ARMDebugPort: removed trailing spaces
<openfpga-bot>
jtaghal/master 784857e Andrew D. Zonenberg: ARMDebugPort: removed trailing spaces
<openfpga-bot>
jtaghal/master 3740e1a Andrew D. Zonenberg: Moved ARMDebugPort out of legacy
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/vpVAz
<openfpga-bot>
jtaghal/master 23fcab9 Andrew D. Zonenberg: ARMDebugAccessPort: converted to modern exception structure
<openfpga-bot>
[jtaghal] azonenberg pushed 3 new commits to master: https://git.io/vpVAp
<openfpga-bot>
jtaghal/master c904505 Andrew D. Zonenberg: ARMAPBDevice: Removed trailing spaces
<openfpga-bot>
jtaghal/master 227b056 Andrew D. Zonenberg: Moved ARMAPBDevice out of legacy
<openfpga-bot>
jtaghal/master 203d81e Andrew D. Zonenberg: Added ARM device classes to build script
<openfpga-bot>
[jtaghal] azonenberg pushed 3 new commits to master: https://git.io/vpVxr
<openfpga-bot>
jtaghal/master 31f5d7f Andrew D. Zonenberg: Added more cleaned-up files to build script
<openfpga-bot>
jtaghal/master a7929ff Andrew D. Zonenberg: ARMDebugPeripheralIDRegister: Removed trailing spaces and unnecessary include declaration
<openfpga-bot>
jtaghal/master 86b663a Andrew D. Zonenberg: Moved ARMDebugPeripheralIDRegister out of legacy
<eduardo__>
Azonenberg: just in case. I got 3 pieces of Agilent 1156A probes 1,5 GHz in a fire sale and they are sitting on my shelf.
<azonenberg>
eduardo__: cool, but i dont have a scope that can really take advantage of them yet :p
<azonenberg>
And rather than using somebody else's EOL'd probes i'd rather either use current generation parts, or build my own
<azonenberg>
in the former case i can get support from the manufacturer, in the latter i can debug/fix it myself
<azonenberg>
For the time being i'm primarily using Z0 probes because they're effective, cheap, and pretty flat
<whitequark>
building your own scope probes...
<whitequark>
typical azonenberg
<openfpga-bot>
[jtaghal] azonenberg pushed 3 new commits to master: https://git.io/vpVpu
<openfpga-bot>
jtaghal/master 13ea342 Andrew D. Zonenberg: ARMCortexA9: converted to logtools
<openfpga-bot>
jtaghal/master 1fbb4e4 Andrew D. Zonenberg: ARMCortexA9: Removed trailing spaces
<openfpga-bot>
jtaghal/master 6847731 Andrew D. Zonenberg: Moved ARMCortexA9 out of legacy
<azonenberg>
whitequark: a resistor, sma connector, and piece of coax
<azonenberg>
hard to get simpler than that
ym has quit [Ping timeout: 240 seconds]
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/vpVp1
<openfpga-bot>
jtaghal/master 0d6755d Andrew D. Zonenberg: Added ARMDebugAccessPort to build
<rqou>
wait azonenberg you have arm jtag support?
<azonenberg>
rqou: It's WIP, i started doing it for zynq a while ago and tabled it
<azonenberg>
now we're dealing with an annoying chip at work and i'm reviving it
<azonenberg>
So i can do lower level poking of registers on a maybe-locked chip etc
<rqou>
we should build a "white magic probe" to compete :P
<azonenberg>
You cannot hook it up to gdb or do anything useful yet
<azonenberg>
its a long ways off
<rqou>
also, able to say which chip?
<azonenberg>
right now i can detect coresight components and kinda-sorta do memory access but there are bugs
<azonenberg>
Automotive with a cortex-R, cant be more specific
<rqou>
oh what
<rqou>
i didn't realize anybody actually used cortex-R
<azonenberg>
Yeah, the existing f/oss tools are light on support for them
<azonenberg>
i'm gonna use the a9 on my bench (working from home today) for initial bringup of the arm debug stuff then work on adding cortex-r support at the office next week
<rqou>
is it even similar at all?
<azonenberg>
The arm debug interface is the same to the point that you're on the AHB bus
<rqou>
e.g. i thought M is completely different?
<azonenberg>
the registers you poke from there on out are different
<azonenberg>
But i'm still working on bringing up the mem-ap
<awygle>
Cortex R feels like it needs a third core
<rqou>
so how is R any more real time than M?
<azonenberg>
Dont know, i havent gotten to the R stuff yet
<azonenberg>
still working on the core ADIv5
<rqou>
also, it has the oldschool IRQ/FIQ mechanism, right?
<azonenberg>
This is what i can do with a zynq right now
<awygle>
Plus some fancy fault detection
<azonenberg>
i have code to read registers and dump status but something doesn't work and i'm not yet sure why
<rqou>
wait wait wait
<rqou>
an automotive company undrrstands what a lock bit is?
<azonenberg>
rqou: lol we dont know if it's locked or if the jtag tools just have borked cortex-r support
<azonenberg>
The behavior is confusing
<rqou>
and is using a non-Japanese cpu? :P
<azonenberg>
Which is where my own code comes in, i can get lower level diagnostics on exactly which operations fail / are blocked
<azonenberg>
But yes people are starting to lock things more often
<azonenberg>
i actually had [redacted medical device vendor] send me a board a few months ago with locked stm32s on it
<azonenberg>
that was a shock as i was used to open swd on all of their products :p
<rqou>
but but but how will people rice their cars now? :P
<azonenberg>
Well, if you replace the 50-pound bag of kitty litter over the back wheels with rice
<azonenberg>
you get just as much traction
<azonenberg>
you can always add a second bag...
<rqou>
lolol
<rqou>
i guess adding ridiculous decorations, "stancing", making it loud AF, failing emissions, etc. all don't actually require modifying the firmware :P :P :P
<awygle>
Replace the whole board
<rqou>
azonenberg: was the stm32 the one that has a hardware race condition in the read protection?
<Ultrasauce>
yes
<azonenberg>
rqou: what about rolling coal?
<rqou>
"hybrid repellant" :P
<azonenberg>
and yes you can also pull the whole mcu and replace it
<rqou>
wait don't you have to carefully calibrate control loops for the car you're running?
<rqou>
i guess ricers probably don't care
<rqou>
but still, azonenberg this isn't running an SH or some other weird Japanese mcu?
<rqou>
or is this not a Japanese company?
<rqou>
azonenberg: btw you should ask IOA to buy you a Tesla so you can hack it with the now-public RCM bug :P
Bike has quit [Ping timeout: 260 seconds]
<sorear>
R is A but with a MPU instead of paging. Not very close to M
<rqou>
M can have an MPU too
<sorear>
So?
<sorear>
R is A but with M’s MPU
<sorear>
That’s all
<rqou>
lol
<rqou>
so the "real time" part is just marketing wank?
<azonenberg>
rqou: Can't go into specifics re company
<azonenberg>
But the applications processor is not a SH
<sorear>
It’s accurate if you’re comparing to A
<rqou>
get IOA to buy you a Tesla? :P
<balrog>
azonenberg: have you run into much in the way of SH or renesas RX or other weird crap like that?
<azonenberg>
I bumped into a SH once years ago
<azonenberg>
But by and large i've mostly worked with ARM, the occasional x86
<azonenberg>
one or two pics, a few mips
<azonenberg>
one powerpc
<balrog>
avr?
<azonenberg>
one really weird taiwanese isa ida didnt support, but that didnt matter because i couldnt find tools to dump it either
<azonenberg>
(in the old simplisafe alarm)
<balrog>
can you disclose what that was?
<azonenberg>
I could if i remembered, which i dont
<sorear>
Andestar!
<azonenberg>
hmm, i dont actually know if i've ever seen an avr
<sorear>
?
<azonenberg>
i know i've seen atsam
<azonenberg>
But those are arm
<azonenberg>
oh and here and there 8051
<rqou>
no H8?
<sorear>
No in-house totally bespoke stuff?
<balrog>
8051, the architecture that won't die
<azonenberg>
balrog: lol yeah
<azonenberg>
i want 8051 to die as much as x86
<rqou>
MMU subleq machine :P
<azonenberg>
rqou: how about a machine that just contains two instructions