emeb has quit [Quit: Leaving.]
<qu1j0t3> anyone here had experience with counterfeit linear chips?
<qu1j0t3> e.g. Analog Devices. I've been, uh, burned once. Anyone know if cerdips are counterfeited as well as plastic dips?
<qu1j0t3> also: is Hungary a known counterfeit source, or just that.. other place
<qu1j0t3> i assume the Eastern European sellers are mostly waste reprocessors? i've never quite figured out why so many high brand value chips are sold from there
<qu1j0t3> and environs
<qu1j0t3> teach me irc
<prpplague> qu1j0t3: less risk selling counterfit chips than selling fake cigarettes
jcarpenter2 has joined ##openfpga
unixb0y has quit [Ping timeout: 252 seconds]
unixb0y has joined ##openfpga
genii has joined ##openfpga
azonenberg_work has quit [Ping timeout: 264 seconds]
jcarpenter2 has quit [Remote host closed the connection]
jcarpenter2 has joined ##openfpga
azonenberg_work has joined ##openfpga
<whitequark> awygle: poke?
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
* prpplague reports whitequark to HR for harrasment
<prpplague> whitequark: stop poking people
* prpplague glares
* whitequark pokes prpplague
<prpplague> i've been violated!
* prpplague finishes soldering 100 breakout boards
<prpplague> fun fun fun
jevinskie has joined ##openfpga
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
indy has joined ##openfpga
rohitksingh_work has joined ##openfpga
<TD-Linux> oh yeah I should finish testing my RevB
Bike has quit [Quit: Lost terminal]
jcarpenter2 has quit [Quit: Leaving]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
genii has quit [Remote host closed the connection]
<lain> prpplague: thanks for fuelling my nightmares :P
<lain> I think when we start sourcing parts for our ARM laptop (mostly for ourselves / internal use) we'll uhhhh x-ray all components and decap random samples D:
_whitelogger has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<mrpackethead> When someone produces an IP core "for sale" and you buy it.. is it encrypted or how do thye protect their IP?
<lain> usually it is encrypted, but it has to be decrypted as part of the design process so it's like DRM... very easy but very illegal to bypass
GuzTech has joined ##openfpga
<azonenberg_work> It depends on the specifics of the core
<azonenberg_work> Sometimes you get a full source license
<azonenberg_work> Sometimes you get a simulation model, plus a black box standard-cell "dummy" that contains pins for the IP core
<azonenberg_work> and is replaced by the actual hard IP at the fab (you never see it)
<azonenberg_work> (that's for asic)
<azonenberg_work> For fpga, generally either source or encrypted netlist
<azonenberg_work> Sometimes both are available depending on how much you pay
<azonenberg_work> I mean, if you have enough arm will sell you a copy of the cortex-a53 source code that you can modify and turn into your own asic with additional propriretary cpu instructions or whatever
<azonenberg_work> But i'm guessing arm source licneses start at the tens of millions for the lowest end cpus
<azonenberg_work> an a53 source license probably costs you $50M or so
<azonenberg_work> Plus royalties for each chip you make :p
<rqou> really? tens of millions for an arm7tdmi?
<azonenberg_work> i was thinking for like an m3
<azonenberg_work> or something
<azonenberg_work> but that was just a wild guess
<azonenberg_work> i've never actually tried getting one :p
<rqou> i was expecting "only" millions for an m3
<azonenberg_work> either way, more than most companies can afford
<rqou> and even less for an arm7tdmi/arm926ejs
<sorear> they seem to not care very much about m3
<sorear> https://github.com/cryptolu/maps is a functional simulator which was written by non-ARM employees while looking at the M3 Verilog code
<sorear> it says something that that repo wasn't dmca'd in less than five minutes, I'm not quite sure what
<rqou> i know there's no way i would pay tens of millions for an arm7tdmi
<rqou> i'd rather just yolo a picorv32
<sorear> i've also met someone IRL who claims that the ARM1176 has the same status as Night of the Living Dead due to rpi-related snafus; I trust this about 0% though
<sorear> awfully specific thing to be making extremely specious claims about
<Bob_Dole> talking about ASIC-making the other day, I was thinking about this guy, I'm sure you've all seen it before but: https://twitter.com/szeloof
<lain> speaking of arm royalties, they recently released encrypted IP you can use in xilinx fpgas for free, it's a Cortex-M1 and I think an M3 is coming soon
m4ssi has joined ##openfpga
GuzTech has quit [Ping timeout: 252 seconds]
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
<azonenberg_work> ...
<rqou> at least the RSO was paying attention
<azonenberg_work> honestly? if it was me RSOing?
<azonenberg_work> at 0:06 i'd have yelled at him to get the muzzle on target NOW
<azonenberg_work> and if it wasn't where it belonged immediately, off the range before it got any further
<azonenberg_work> actually at 0:03 it looks like he sweeps way off to his right too
<rqou> looks like the RSO was busy with another group
<rqou> huh wow being an RSO is tough
<azonenberg_work> That tells me they need more RSOs :p
<azonenberg_work> At my club, the RSOs tend to watch people they dont recognize like a hawk
<rqou> so no loaded gun selfies?
<azonenberg_work> you'd be out on your ass long before it got to that point
<azonenberg_work> If you're a regular they trust, they keep an eye out in case you slip up but arent super paranoid
<azonenberg_work> If it's somebody new they look extra close
<azonenberg_work> Now that I'm certified as one myself, they're a little less down my neck when I have a new shooter in my lane
<azonenberg_work> But that's because they know me, they know i know what i'm doing, and i normally deal with issues long before they get out of hand
<azonenberg_work> The only time i remember the on-duty RSO overruling me on a safety issue is when i was paying too much attention to muzzle control and missed that the guy's hand was too high up the grip
<azonenberg_work> and he risked being pinched by the slide when it came back
<azonenberg_work> But that's a relatively minor risk vs shooting somebody else there :p
<azonenberg_work> If i'm watching somebody i normally complain if they're more than ~30 degrees off target because it's a bad habit
<azonenberg_work> Even if they're nowhere near any of the other lanes
<azonenberg_work> i want them thinking about it BEFORE it gets to the point i have to grab the barrel and point it in a safe direction
<rqou> but have you ever seen an idiot trying to take a selfie?
<azonenberg_work> No
<azonenberg_work> Like i said, we deal with idiots before they get to that point
<azonenberg_work> Minor muzzle control issues (~30 degrees off axis or so) get a polite correction, anything anywhere close to another shooter a ceasefire followed by a very stern warning
<azonenberg_work> If i saw someone actually sweep another shooter with a loaded weapon they'd be off the range immediately
<rqou> btw thoughts on those "gangsta" selfies with presumably unloaded guns?
<azonenberg_work> I have zero respect for anyone who demonstrates poor weapons handling whether it's loaded or not
<azonenberg_work> That's how people win darwin awards
<rqou> does that include police officers? (btw we really should have a ##openfpga-offtopic to absorb the stuff that ##whitequark hasn't absorbed yet)
<azonenberg_work> Or worse yet, shoot a stranger by accident
<azonenberg_work> The police I know personally are very competent about such things
<azonenberg_work> I cant comment on other departments
<azonenberg_work> If they're anything like the military ranges i've heard stories of, their training does not mess around
<rqou> and yet NYPD/LAPD/etc. keep "accidentally" shooting people
<azonenberg_work> Like i said, i cant comment on other departments
<azonenberg_work> What i do know is that NYPD issues Glocks, which have no manual safety catch and rely on you not pulling the trigger when you don't want to fire it, and as a bit of a crutch
<azonenberg_work> they have a nonstandard excessively high trigger pull
<azonenberg_work> Which does make an unintentional shot slightly harder to fire, but also reduces accuracy since you have to put a lot of force on the trigger
<azonenberg_work> i've heard close to ten pounds
<azonenberg_work> Which could very well lead to significant sideways motion as you fire if you're not experienced with it (and will reduce accuracy even for a skilled shooter)
<azonenberg_work> Not saying that's the cause, but it certainly could contribute in some cases
<azonenberg_work> to an intended shot going in an unintended direction
Laksen has joined ##openfpga
<q3k> azonenberg_work: yeah, i'm not firearms expert, but when I shot a glock the trigger was somewhat heavy
<q3k> azonenberg_work: took a lot of practice to pull it steadily without losing your aim sideways
<q3k> azonenberg_work: well, a lot. after an hour i basically got it :)
_whitelogger has joined ##openfpga
s_frit has quit [Ping timeout: 252 seconds]
florolf has quit [Remote host closed the connection]
florolf has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
scrts has quit [Ping timeout: 252 seconds]
Bike has joined ##openfpga
scrts has joined ##openfpga
rohitksingh has joined ##openfpga
Laksen has quit [Ping timeout: 252 seconds]
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
Aleksandar-K has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
Miyu has joined ##openfpga
genii has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
mumptai has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
GuzTech has joined ##openfpga
<azonenberg_work> q3k: most glocks are not that heavy
<azonenberg_work> NYPD had theirs specifically modified
<azonenberg_work> the theory was to reduce liability of negligent discharges
<azonenberg_work> most folks who know anything about shooting think that's BS
<azonenberg_work> might be a little harder to shoot by accident but if you hit the guy next to your perp and not him, that isnt much use
rohitksingh has joined ##openfpga
GuzTech has quit [Remote host closed the connection]
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has quit [Ping timeout: 268 seconds]
azonenberg_work has joined ##openfpga
<prpplague> how was orconf this year?
<prpplague> the schedule looked fantastic
genii has quit [Read error: Connection reset by peer]
mumptai has quit [Quit: Verlassend]
Aleksandar-K has quit [Quit: Leaving]
genii has joined ##openfpga
scrts has quit [Ping timeout: 268 seconds]
kristianpaul has left ##openfpga [##openfpga]
scrts has joined ##openfpga
uovo has joined ##openfpga
oeuf has quit [Ping timeout: 252 seconds]
uovo has quit [Ping timeout: 246 seconds]
pie_ has joined ##openfpga
<kc8apf> EAR requires a license for exports to designated terrorists. All requests for such licenses are summarily denied.
<whitequark> ear?
<kc8apf> US export restrictions
<kc8apf> less restrictive than ITAR
<whitequark> ah
<zkms> why would they require a licence instead of just like...prohibiting altogether export to designated terrorists
<kc8apf> zkms: bureaucrats love their jobs
<whitequark> wait
<whitequark> TERRORISTS
<kc8apf> or maybe there's the occasional terrorist organization US gov't wants to sell weapons to
<whitequark> not TERRITORIES
<whitequark> wtf
<kc8apf> yes, terrorists
<zkms> another day at the EAR license office; everyone keeps asking me if they can get a license to export articles to designated terrorists, buddy, they won't even let *me* export them
<whitequark> ...
<whitequark> tweet that
<TD-Linux> ah, is this one of those cases where silicon valley innovation can ask for forgiveness later?
<zkms> whitequark: i dont have a source for appropriate context and i dont want someone misunderstanding me lol
<whitequark> oh
<whitequark> right
<shapr> Anyone have an ORConf writeup? I'm especially curious about the clash-lang presentation.
<Bob_Dole> maybe exporting ears of corn as a peace-offering to halt terrorist activity is expected under EAR?
* shapr plays the rimshot sound effect
<kc8apf> TD-Linux: not usually. I mean, it regularly comes down to paying a fine and being restricted from doing those types of exports for a while
<openfpga-github> [Glasgow] whitequark closed issue #64: Implement combined, zero-configuration reset for USB FIFO and applet https://github.com/whitequark/Glasgow/issues/64
<whitequark> awygle: ^^^^^
<openfpga-github> [Glasgow] whitequark commented on issue #64: @kevinmehall Thanks, this worked quite well. Though I didn't anticipate that SET INTERFACE would reset the EP toggles and was really puzzled for a while there. https://github.com/whitequark/Glasgow/issues/64#issuecomment-428356957
<whitequark> you can finally ^C applets and not have junk being read the next time you run it
<whitequark> I really hated that and the only way to fix it would be to open the python console and do some bulk reads...
<travis-ci> whitequark/Glasgow#57 (master - 5ac4c8d : whitequark): The build passed.
<whitequark> it's really something amazing to fix a bug that caused incessant intermittent confusing failures and have everything work perfectly every time now
<felix_> whitequark: did you have a look at the trace i linked you? if it looks sort-of useable, i'd try to get a trace at 24mhz with sigrok-cli on another computer running natively under linux. seems though that the frequency of the signal on the cc line is much higher that the 300khz
Bike has quit [Ping timeout: 256 seconds]
oeuf has joined ##openfpga
mumptai has joined ##openfpga
mumptai has quit [Client Quit]
s_frit has joined ##openfpga
<whitequark> felix_: i haven't been able to install saleae sw for some reason, will try again today
<whitequark> unrelated: anyone here understands sd/mmc?
<whitequark> like there's spi mode, mmc mode, and... sd mode? do sd cards support mmc mode?
<jn__> soon there will be pcie in SD cards
<whitequark> wtf
<whitequark> are you serious
<whitequark> what
<whitequark> why
<pie_> put yo sdcard in yo pcmcia?
<qu1j0t3> rude
<pie_> wait does that mean sd card controller chips will have dma?
<pie_> i never really looked into pci but as far as i have noticed, it usually has dma?
<qu1j0t3> definitely, but it may not mean what you think it means
<pie_> queue inigo montoya
<qu1j0t3> pie_: i mean, i'm not a guru, but afaik DMA means "access to host memory by the controller."
<pie_> to me that means poke my rams. though with some thought maybe it just gets allocated some memory block?
<qu1j0t3> you need to have a controller to be a bus master
<qu1j0t3> (at least in traditional buses, this terminology may be wrong for PCI *shrug*)
m_w has joined ##openfpga
Bike has joined ##openfpga
<rqou> I'm somewhat familiar with SD
<rqou> afaik mmc mode and sd mode are/used to be very similar
<rqou> but mmc was defined up to x8
<rqou> this is before SD added the extra fast differential signalling stuff
<rqou> there may also be some electrical differences somewhere because a multidrop bus was supported somewhere at some point (nobody did this)
<whitequark> rqou: the mmc standard apparently still sort of supports this
<whitequark> so like, sd cards have mmcmode, right?
<whitequark> or is it just "very similar"?
<rqou> no, just "very similar"
<whitequark> wtf
<rqou> they use different command sets
<whitequark> is the sd spec public at all anywhere?
<whitequark> can an mmc controller be abused to do sd?
<ZipCPU> Yes and yes
<rqou> but compatible-ish physical and mechanical specs
<whitequark> ZipCPU: yes to the former too?
<rqou> there's a abridged spec
<whitequark> I've never seen a pdf of the SD spec
<rqou> the drm bits are missing
<whitequark> the MMC spec is published by JEDEC thankfully
<whitequark> oh
<rqou> and there's a EULA
<whitequark> well I don't want them in t... the what
<whitequark> the EULA?
<ZipCPU> You can get the SPEC via Google
<rqou> but it's sufficiently detailed to be able to read and write to a normal card
<whitequark> rqou: hm
<whitequark> is the MMC SPI mode and SD SPI mode the same thing?
<ZipCPU> That would be the SD spec I'm referencing
<rqou> i don't think it's quite enough to _qualify_ a card, but just for hax is ok
<rqou> i believe spi mode is yet another command set
<whitequark> rqou: I'm basically thinking about an SD/MMC/whatever applet for Glasgow
<whitequark> mostly because of eMMC
<whitequark> but hey, why not read normal MMC and SD too
<rqou> oh yeah that's definitely possible
<rqou> the crc and bit packing into lanes is confusing AF
<rqou> but otherwise it's "just" a matter of sending the right commands
<whitequark> rqou: do you think you can point me in the direction of the abridged SD spec
<whitequark> ZipCPU: thanks for the info
<ZipCPU> Yeah ... I built an RTL SPI controller for SD cards some time ago
<whitequark> hm, the SPI mode is easy, I'm interested in actual SD mode, it's much faster
<ZipCPU> I'm not sure SPI is any easier than SD mode, but SDIO (as I think it's called) is much faster
<whitequark> though right now Glasgow can only dump data at 4 MB/s down and 1 MB/s up for some reason
<rqou> whitequark should just be these? https://www.sdcard.org/downloads/pls/
<rqou> downloading doesn't seem to work on mobile
<whitequark> rqou: i swear this used to not be a thing...
<whitequark> a few years ago
<whitequark> many years ago, ok
<rqou> no it's definitely been around for a while
<whitequark> you could do SPI but the entire SD thing was under NDA or something.
<whitequark> hm ok
<whitequark> weird.
<rqou> i was reading it back in the NDS homebrew era to try to debug a "DLDI" (cursed)
<whitequark> I'm not even going to ask what that is
<rqou> iirc I fixed it but never published the fix anywhere
<whitequark> hm
<whitequark> the URLs are predictable so you can technically download them all without ever accepting EULA
<whitequark> I wonder if the courts would agree with me
<rqou> the linux kernel also has a driver that knows how to send all the right commands
<whitequark> rqou: wtf, sd and mmc are basically the same except different
<whitequark> why does this exist
<rqou> good question
<rqou> afaik drm
<rqou> mmc doesn't have that
<whitequark> it does
<whitequark> different kind of drm
<rqou> wat
<whitequark> also not public
<rqou> wtf
<whitequark> seriously
<rqou> wtfwtfwtf
* rqou shoots self
* ZipCPU calls ambulance for rqou
<q3k> >sd and mmc are basically the same except different
<q3k> this is annoyingly accurate
<q3k> god I hate those standards so much
<whitequark> extremely cursed
<q3k> seeing the specs actually makes it more difficult to understand them
<q3k> linux drivers are more readable then the fucking specs
<q3k> everything about SD/MMC is utter trash
<q3k> the wire format
<q3k> the documentation for the wire format
<q3k> the 'standardized' host controller api (forgot what it's called)
<whitequark> the wire format just seems kind of "meh" to me, but the command set is some real atrocity
<q3k> and the documentation for that in turn
<whitequark> SDHC
<Bob_Dole> so uhhh, SD/MMC- is using just the spi interface thing viable for stuff that doesn't need a lot of speed?
<q3k> nope
<zkms> also IME most SD cards i've used have been the worst binned flash ever, just the slowest least enduring stuff there is
<q3k> the SPI is totally separate
<q3k> *SPI mode
<Bob_Dole> goal of just getting storage onto a 65816
<q3k> and the decision tree to figure out whether your card actually supports SPI mode is like a choose your own adventure book
<whitequark> Bob_Dole: I *think* the SD SPI mode and MMC SPI mode are *also* separate things
<q3k> twenty different logos
<zkms> apparently they make SLC "industrial" SD cards and hopefully those aren't the worst-binned shit
<Bob_Dole> Oh god
<q3k> fifty different standards
<whitequark> but I can't confirm it because the docs are awful
<ZipCPU> whitequark: It's SPI both ways, but the messages are subtly different.
<q3k> whitequark: seriously, what the _fuck_ where they smoking when they just numbered the commands
<kc8apf> zkms: they're only slightly better
<whitequark> ZipCPU: right, this is what I assumed after looking at the specs
<rqou> uh, my experience is that SD card flash is ok as long as you blacklist any vendor who doesn't actually own the flash fab
<whitequark> thanks
<whitequark> I hate it
<q3k> whitequark: instead of giving them names/identifiers
<rqou> e.g. samsung sd cards are ok
<kc8apf> very little in the way of health statistics available for SD. Hard to know when a card is starting to fail
<whitequark> q3k: they give them names in the mmc spec
<whitequark> but also still use numbers at random
<whitequark> because fuck you, that's why
<q3k> reading the spec from page 1 is like being dropped into the middle of a B movie
<q3k> what the fuck is CMD1
<q3k> what the fuck is CMD3
<whitequark> oh yes.
<q3k> what does any of this mean
<rqou> oh lol yeah
<q3k> why does this state diagram look like the kaballah
<q3k> god damn JEDEC you had one job
unixb0y has quit [Ping timeout: 246 seconds]
<whitequark> q3k: are you on ##whitequark yet btw
<whitequark> the cursed tech channel
<oeuf> whitequark: is it really about tech?
<oeuf> I thought it was about cats and then went off topic
<whitequark> oeuf: well it is about cursed tech *now* apparently
<whitequark> it was about medicine.
<whitequark> but then twitter happened to it
<rqou> there's still medicine and lewd and cats and stuff
<oeuf> rqou: are whitequark's cats lewd?
<rqou> well, one of them had kittens, so yes?
<whitequark> in a way, our bodies are the most cursed tech of it all
Miyu has quit [Ping timeout: 252 seconds]
<q3k> whitequark: I thought ##openfpga was ##whitequark
unixb0y has joined ##openfpga
<whitequark> q3k: eh it felt like i was going offtopic way too much on here
<whitequark> plus on ##whitequark i don't have a filter at all :p
* zkms gives whitequark a root raised cosine
<whitequark> um,
* ZipCPU suggests a Root Nyquist filter instead of the root-raised cosine, it has lower sidelobes
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sorear> having read ieee 1364-2008, ZipCPU's blog, and the yosys manual (in that order) i'm now thinking about what reasonable practices for organizing projects / package management are
<ZipCPU> sorear: You mean like svn vs git? File layout/structure?
<sorear> file layout, handling dependencies
<sorear> build/test/verification scripts
<ZipCPU> I try to follow a document that was once posted on OpenCores for that purpose
<ZipCPU> I think I've modified it somewhat in practice, but ... I've only documented it for my patreon sponsor's
<sorear> i'm guessing we're not quite at the npm level of "easy to integrate third-party stuff"
<ZipCPU> npm?
<sorear> meaning https://www.npmjs.com/
<ZipCPU> Never tried it. Perhaps I should
<sorear> fusesoc is probably what I want to study next
<ZipCPU> You might want to take a look at AutoFPGA after that
<sorear> thanks for the pointer