pie_ has quit [Ping timeout: 260 seconds]
m_t has quit [Quit: Leaving]
pie_ has joined ##openfpga
carl0s has joined ##openfpga
nikitakit has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<awygle> nikitakit: hello there! rqou said you're interested in PAR algorithms, is that right?
<nikitakit> hi! nice to meet you
<nikitakit> yes, I'm interested in PAR
<awygle> Cool :-) is there anything in particular you're interested in? Current projects in the channel include crossbar PAR for GreenPak and Coolrunner, and I'm working on a distributed placer for FPGAs
<nikitakit> hmm... so I'm primarily a CS person, so I'm not actually familiar with any of the particular hardware you're talking about
<nikitakit> I guess I was just surprised at how annoying even the proprietary PAR tooling is, which sparked my interest to see what the problem is all about
<azonenberg> nikitakit: are you in the bay area w/ rqou?
<nikitakit> Yea, I'm a grad student at Berkeley
<azonenberg> ah ok
<azonenberg> we've been talking about, maybe december ish, having a meetup of west coast folks working on PAR and related problems
<nikitakit> (and I do have plenty of grad student things going on)
<azonenberg> me, rqou, awygle, maybe you
<nikitakit> I'd be down to join, unless I'm gone for winter break
<azonenberg> we dont have a date set
<azonenberg> there will likely be a smaller brainstorm session w/ me and awygle since we're both seattle based
<azonenberg> then later in the year try to get all of us in one place
<nikitakit> sure
<nikitakit> In terms of particular interests, my impression is that current PAR tools don't reuse a lot of info when being re-run on a slightly modified design
<nikitakit> It seems to me that once you have a design complicated enough to make PAR super hard, it would be a lot more efficient to precompute some info so you can iterate faster anytime you change the source
<azonenberg> Xilinx has a "smartguide" engineering change order function
<azonenberg> but i dont know how well it works
<azonenberg> what i'm more interested in is speeding design closure by parallelizing PAR
<azonenberg> and i don't mean like annealing on 4 or 8 cores
<azonenberg> I mean a rack of dual xeon blades, or a few hundred large EC2 instances
<azonenberg> PAR-ing a full xcku035 in a minute or two
<azonenberg> No exact performance targets, just "scale well to hundreds or thousands of cores"
<nikitakit> any thoughts as to the key idea of the approach? like splitting up the design into subparts to PAR independently, v.s. just trying a lot of full-design stuff in parallel
<azonenberg> I want to explore energy minimization algorithms used in molecular dynamics
<awygle> nikitakit: that's an interesting thought though.
<azonenberg> Those scale well to hundreds of thousands of CPUs
<azonenberg> and they're basically just a mass-spring system like an FPGA placement
<azonenberg> (where spring force = how much you're failing timing)
<azonenberg> big difference is, we have a discrete domain vs a continuous one
<azonenberg> So some adaptation will be required
<azonenberg> General idea is, do approximate global placement then gradually refine the detail placement
<azonenberg> the further down you go, the less communication you'll need
<azonenberg> then routing can be fully parallelized except at boundaries between tiles managed by single CPUs
<azonenberg> Global placement is likely going to be the hardest part if we do this
<azonenberg> as there will be lots of comm overhead early on
<azonenberg> as the placement approaches a final setup, processors will work more and more on their own
<azonenberg> Also, i want to consider the possibility of having feedback from routing back into placement
<azonenberg> but i'm not yet sure how to do that
<awygle> My current approach is an analytical placer based on the Jacobi method (which is essentially isomorphic to what azonenberg is describing)
<awygle> The "chop up to par independently" approach has been tried in several papers but it tends to hurt quality of result as the number of threads increases
<azonenberg> Yeah, it only really would work if you had hierarchial placement
<azonenberg> and floorplanning of major blocks along CPU boundaries
<awygle> This can be reduced by changing which subregions you're using at each step but still, not ideal
<azonenberg> that's way too much manual effort for a general par
<azonenberg> Floorplanning is something you do during optimization
<azonenberg> not for prototyping
<nikitakit> that sounds interesting
<nikitakit> Do you have the hardware/cloud credits to be prototyping this massively parallel stuff?
<azonenberg> Not yet, although I will be able to go moderately far
<nikitakit> as context my research has to do with deep learning, an it's impossible to get anything done if you don't have the hardware
<azonenberg> i have a bunch of quad core stuff right now
<azonenberg> quite a few U
<azonenberg> My new desktop workstation, to be purchased in the next few months, will be dual socket xeons
<azonenberg> probably on the order of 24-32 physical cores and 48-64 threads
<awygle> I have nothing useful in this regard
<nikitakit> ok, that's already a parallelism challenge with 24-32 cores
<nikitakit> do the proprietary tools parallelize well?
<azonenberg> LOL
<azonenberg> ISE maxes out at 4 for routing and 2 for placement
<azonenberg> vivado can, i think, use six or eight
<awygle> Actually that's not fair, I have 24 cores and two gpus
<nikitakit> ok I see
<azonenberg> awygle: Oh, and i'm going to put something like 128 GB of RAM in it
<azonenberg> I have 32 on my current desktop and i OOM it routinely
<awygle> azonenberg: you bastard :-P
<azonenberg> i tried to fire up a windows VM to LTSpice something earlier and couldn't run it
<azonenberg> i don't even have THAT much open
<awygle> I have 16gb of ram
<awygle> In my desktop. My laptop is 8gb and I think ddr3
<nikitakit> lol I only have a 16gb work laptop and a super old 4gb personal one
<azonenberg> I have 16 in my laptop
<azonenberg> (work, ddr3)
<azonenberg> desktop is 32 of DDR3
<awygle> And a NUC with 4
<azonenberg> I currently have one instance of kicad, two instances of vivado, six linux VMs, two libreoffice spreadsheets, two text editors, several dozen shell tabs, and maybe 10-15 multi-hundred-page PDFs open
<azonenberg> that shouldn't be TOO much, no? :p
<Zorix> that is intense
<azonenberg> I use computers for a living, heavily... I am not opposed to plowing a lot of cash into hardware if it helps me work (and play) more efficiently
<awygle> As a brief aside, this hardware distribution leads to me really wanting to be able to use GPUs with this hypothetical placer, while azonenberg doesn't particularly care
<nikitakit> I'm also curious if GPUs would help
<nikitakit> Like, is there enough floating point math needed
<azonenberg> it's mostly pointer math and conditonals etc from what i remember
<nikitakit> because I think just running discrete stuff on GPU won't give that much of a benefit
<azonenberg> and random access memory math
<azonenberg> exactly what GPUs suck at :p
<azonenberg> heavily branching etc
<awygle> There's significant research into using GPUs for this actually
<nikitakit> it should depend on algorithm, though
<awygle> They tend to just run everything as floats and legalize later
<nikitakit> perhaps there's some clever continuous relaxation that can leverage GPUs
<azonenberg> inb4 fpga par accelerator card
<nikitakit> well, with moore's law fading there's a good chance we go back to accelerators-for-everything
<awygle> oh thank god a keyboard
<awygle> i have legitimately thought about an FPGA PAR accelerator
<awygle> it would be interesting for things like Zynqs
digshadow has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
<awygle> thinking a little more about "use last time's placement to inform this time's", a big issue with the current open source toolchain(s) is that abc is the great devourer of net names
<awygle> so i'd expect it might be hard to correlate
<azonenberg> Well
<azonenberg> That requires improving traceability through ABC
<awygle> but if that wasn't an issue then arachne can already spit out the post-place netlist as a BLIF, so it wouldn't be too hard to teach it to use a post-placement netlist as its initial placement
<azonenberg> which is a high priority for debugging
<nikitakit> yes, this would be a good place to start in terms of going in that direction
<awygle> plus you're berkeley-based so you could annoy alanmi in person
<awygle> like rqou keeps threatening to do
<awygle> azonenberg: this paper might speak to routing/placement feedback: https://www.researchgate.net/publication/309273377_GPlace_a_congestion-aware_placement_tool_for_ultrascale_FPGAs
nikitakit has quit [Ping timeout: 260 seconds]
jn__ has quit [Ping timeout: 246 seconds]
digshadow has quit [Ping timeout: 260 seconds]
nikitakit has joined ##openfpga
carl0s has quit [Quit: Leaving]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
jn__ has joined ##openfpga
digshadow has joined ##openfpga
<awygle> class 10,000 much less hassle. glad i've never worked medical
<rqou> eh, i've been in a "class whatever" cleanroom :P
<rqou> ee143 ftw :P :P
<pie_> oh shit someone illustrated the last question https://imgur.com/gallery/Fd7NP
<pie_> mileage may vary
<awygle> azonenberg: do you use a password manager thing?
<azonenberg> i use an encrypted volume with a text file of passwords, plus a good memory, does that count? ;p
<azonenberg> less important stuff lives in my browser's cache
<azonenberg> if my password to some random forum gets out, i can deal with that
<azonenberg> my online banking etc is 16 char alnum random that i just commit to memory
<azonenberg> My login for work used to be, although due to a recent policy change it's now somewhere in the 25-30 char range
<azonenberg> never written that one down
phil_gekni has quit [Ping timeout: 240 seconds]
phil_gekni has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
<awygle> i also memorize my banking stuff, but i use lastpass for unimportant things, and New Firefox Extensions broke it :(
pie_ has quit [Ping timeout: 252 seconds]
Morn_ has quit [Ping timeout: 248 seconds]
wolfspraul has quit [Ping timeout: 246 seconds]
Morn_ has joined ##openfpga
wolfspraul has joined ##openfpga
<azonenberg> Sooo
<azonenberg> For my 10/100baseT bitbang board
<azonenberg> i feel bad leaving three IO banks unused :p
<azonenberg> ideas on what to do w/ them?
<awygle> USB 1.1 PHY
<awygle> or 2.0, since you're chronically ambitious :P
<azonenberg> Lool
<azonenberg> no
<azonenberg> no usb
<azonenberg> i refuse to have anything to do with it :p
<awygle> lol
<azonenberg> That and, usb is a pure digital protocol
<azonenberg> so its not too crazy when you do it with just GPIOs
<awygle> sure
<rqou> 2.0 isn't quite
<awygle> i want to do a 1.1 PHY and then make an FTDI clone on an ice40
<rqou> azonenberg: troll: R-2R composite video ("the yellow connector")
<azonenberg> FTDI is not something worth cloning IMO :p
<azonenberg> its a last resort b/c you cant find any other interfaces that work
<awygle> on a technical level, no. on a ... call it a social level, yes
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rqou> azonenberg: R-2R video is a good way to needlessly consume pins :P
<rqou> also because composite video is a clusterf*ck :P
<azonenberg> i meant something useful and cool
<azonenberg> not wasting pins for no reason
<awygle> do a high-fidelity DS audio DAC
<rqou> azonenberg: extending the troll idea: put a NES in the remainder of the FPGA
<awygle> as an homage
<rqou> parallel cartridge busses also burn pins :P
<azonenberg> i should just throw on a Q-strip
<azonenberg> and be done with it
<awygle> clone your circuit a bunch of times, do an L2 switch
<awygle> low development effort, potentially useful
<azonenberg> I already have a board with four PHYs on it
<azonenberg> that has this same FPGA
<azonenberg> Which is too small to do the kind of fun stuff i wanted
<awygle> duplicate your circuit a few times, try 4 different AC coupling methods
<azonenberg> i have a magjack on there that i've already used with success
<awygle> transformer, series caps, etc
<azonenberg> the point is to be a PoC, not to actually prototype it for serious use
<azonenberg> Also, i intend to make a L2 switch on an xc7a200t, with 2x 10gbit SFP+ optic ports, 8x 1gbit SFP optics, and probably 16 tri-speed copper ports
<azonenberg> But that will be a full 1U appliance on an 8-16 layer board with an 1156-ball FPGA :p
<awygle> loop it back to a hard PHY for on-board BERT
<azonenberg> Hmmm
<azonenberg> Better idea, loop it back to a magjack terminated into 100 ohms
<azonenberg> and loaded up with SMA connectors
<awygle> that would give you something to do with your fancy new scope :P
<awygle> put switchable diode noise generators on both lines so you can test robustness
<azonenberg> no, i can add noise no problem :p
<awygle> meander the transmission lines so you can experiment with phreaking crappy ethernet phys :p
nikitakit has quit [Quit: Page closed]
<azonenberg> :P
<awygle> put cnlohr's 10-T phy on there and see if you can autonegotiate
<azonenberg> Lol
<awygle> run a long trace to nowhere off one of your unused pins and bit-bang an 802.11 phy
<awygle> (all right i'll stop)
<azonenberg> loool
<azonenberg> yeeeah that would be a bit much :p
<awygle> use a 2.4 Gbps transceiver for your carrier
<awygle> simple diode mixer
<awygle> noooo problem
<awygle> ... would that actually work?
jhol has quit [Quit: Coyote finally caught me]
<azonenberg> um
<azonenberg> not a clue
jhol has joined ##openfpga
<azonenberg> you'd want some RC filtering or something to remove higher harmonics from the carrier
<azonenberg> that much is certain
<azonenberg> And i dont have a GTP on this chip
<azonenberg> It would be hilarious to bitbang some ISM-band radio protocol with one, though
<awygle> you only need 2 MHz baseband to do 802.11b at the slowest rate
<azonenberg> well what i was thinking is
<azonenberg> for some simple PSK-like protocol, transmit only
<azonenberg> you could bitbang RF
<azonenberg> and just LPF out the upper harmonics
<azonenberg> then feed to an external amp or something
<awygle> i wonder if you could use a GTP to drive a Class-E amplifier
<azonenberg> say 433 MHz carrier or so
<azonenberg> that should be bitbangable with a GTP if you turn off the 8b10b
<awygle> oh you mean drive it directly at RF
<awygle> hm
<azonenberg> Yes
<azonenberg> you can't modulate amplitude but you can modulate phase/frequency
<azonenberg> 866 Mbps squarewave data is a 433 MHz carrier
<azonenberg> add an RC filter to remove the 2nd and higher harmonics and you have a 433 MHz sinusoid
<awygle> and just insert longer/shorter pulses to modulate phase
<azonenberg> forget all that silly I/Q stuff
<azonenberg> exactly
<azonenberg> sounds like a horrible idea that might work
<azonenberg> lol
* azonenberg imagines taking an fpga devkit and screwing a 50 ohm antenna onto the SMA connector for a GTP
<azonenberg> Nope :p
<awygle> hmmmm
<awygle> if you run at 866 you'd only have one bit of phase control, i.e. "crappy bpsk", i guess
<azonenberg> Easy enough to improve though
<awygle> i feel like there should be a reason this won't work, but... i can't think of one
<azonenberg> Run at 1732
<azonenberg> or 3464, although this might not work on a crappy spartan6
<azonenberg> i think you'd need an artix for that
<awygle> i feel like a kind and loving god cannot allow this to be possible
<azonenberg> also keep in mind your phase shift is normally done at baseband so it's multiple carrier cycles
<azonenberg> its a huge shift, not a few ps
<azonenberg> And a kind and loving god wouldn't allow a lot of things we have to deal with
<azonenberg> like ISE
<azonenberg> :p
<awygle> i mean if you're going to do this anyway, grab a spartan, run at 4.8 Gbps, try for 802.11
<awygle> if you're gonna be a bear, be a grizzly
<awygle> ERR artix, not spartan
<azonenberg> 802.11 i think requires amplitude control
<azonenberg> Which you won't get with a trivial GTP bitbanger
<awygle> 802.11b at 5.5 M and 11M for sure are BPSK and QPSK respectively
<awygle> with some DSS thrown in
<awygle> (okay actually DBPSK and DQPSK but that's unimportant in this context)
<awygle> i am pretty sure 1M and 2M have the same relationship, just slower, but i've never tried to use them for anything serious
<azonenberg> ah so its not until g/n that you start seeing amplitude change?
<awygle> all the other ones are QAM on OFDM, yes
<azonenberg> idk, i know Ethernet PHYs pretty well
<azonenberg> not other stuff
<awygle> a is idential to g just at 5GHz
<awygle> i know a _lot_ about 802.11, sadly
<azonenberg> i've only actually implemented 1000base-X so far
<azonenberg> wrote my own PCS for an artix7 using a raw GTP with no IP wrapper
<awygle> i did some gnuradio 802.11 stuff for a while, but i was younger and dumber so it didn't work very well
* awygle clicks "send me my 2fa code" and then thinks "oh, who's emailing me?"
<awygle> so did you just play with ethernet phys all day? every time you tweeted a diagram i was jealous that i was stuck at work
<azonenberg> Lol no that was like 15 minutes last night
<azonenberg> i just took my leatherman and stripped insulation off a cat5 cable
<azonenberg> hooked it from my laptop to a cisco
<azonenberg> forced to various speeds and grabbed a few shots with my new lecroy scope
<azonenberg> could not have been more than an hour of work
<azonenberg> the PHY design was maybe 2 hours this afternoon
<awygle> yeah, i meant the (presumably kicad) stuff from today
<azonenberg> Yes, that was mostly after work
<azonenberg> although i did a few mins over lunch
<awygle> anyway. nice plotting horrible things with you. i need sleep so i can go back to work tomorrow >_<
<azonenberg> Lol
<azonenberg> Yeah i'm working from home tomorrow
<azonenberg> REing an unholy amount of obfuscated java
<azonenberg> Wish me luck :p
<awygle> career protip: don't get hired into a death march
<azonenberg> (you see why i feel the need to bitbang ethernet to stay sane?)
<awygle> lol you never have to justify weird side projects to me, my long term goal is "get rich so i can spend all my time running down stupid ideas"
<azonenberg> I've joked that the closest i'd ever get to retiring would be turning my garage into an FFRDC
<azonenberg> and working on DARPA-hard problems in my spare time
<rqou> i was half-expecting "turning my garage into a superfund site"
<rqou> but i guess since you're "the EH&S guy", that won't happen
<azonenberg> Lol
<rqou> meanwhile here i don't think "extended family of convicted human traffickers" care very much about "just a little bit" of chemical contamination :P
<azonenberg> Lol
<azonenberg> You have a... unique... living situation though
<azonenberg> i'm looking to buy a house soon
<azonenberg> Which will give me all the more incentive to not trash the place
<rqou> i believe the "unique" part isn't accurate :P
<rqou> "He used its profits to purchase over 1,000 run-down apartment buildings, making him, by 2000, the largest and wealthiest landlord in the city (other than the University of California), with a worth estimated at US$69 million"
<rqou> awygle: i'm curious, did you ever live in a lakireddy apartment when you were a student?
jn__ has quit [Ping timeout: 248 seconds]
jn__ has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
teepee has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
m_w has joined ##openfpga
m_w has quit [Client Quit]
Hootch has joined ##openfpga
digshadow has joined ##openfpga
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 248 seconds]
digshadow has quit [Quit: Leaving.]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 240 seconds]
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
m_t has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
digshadow has joined ##openfpga
qu1j0t3 has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
enriq has joined ##openfpga
xdeller has quit [Quit: Leaving]
<awygle> rqou: I mean, maybe. I didn't exactly do background checks
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
pie_ has joined ##openfpga
<cr1901_modern> azonenberg: Do you have any literature on 4b/5b clock recovery (yes, analog is not a concern :P)
<cr1901_modern> While reading a paper today it came up and I finally learned that's what's used for 100Mb Ethernet
<awygle> cr1901_modern: yeah re your stackoverflow post, seems like it would be trivial to lock to the opposite phase of the TX clock with a pll
<awygle> Possibly difficult to avoid, even
<awygle> I agree the literature is unclear though, typical academic "we can create a phase relationship!" "what relationship?" "who cares about the details?"
<cr1901_modern> awygle: You got to my point before I typed it out :P
<cr1901_modern> awygle: "Possibly difficult to avoid, even" This isn't an analog phase detector, so the VCO wouldn't be outputting a signal 180-degrees out-of-phase
pie__ has joined ##openfpga
<awygle> It's basically a sign change
pie_ has quit [Ping timeout: 255 seconds]
<azonenberg> cr1901_modern: No i do not have any specific literature
<azonenberg> but basically my plan is, look for edges
<azonenberg> dead-reckon 125 Mbps from that edge out
<azonenberg> fine tune when the next edge arrives
<azonenberg> once i have an approximate phase lock then go half a UI in from the edge and call that my sampling point
<awygle> "UART writ large"
<azonenberg> awygle: lol
<azonenberg> honestly it isnt all that different
<awygle> It's actually easier because the data rate is fixed
<azonenberg> except that there's a constant stream of edges and you fine tune on every one rather than just resyncing every start bit
<awygle> And that yeah
<azonenberg> 10m is more like uart
<azonenberg> since the edges stop between packets
<azonenberg> but its manchester with a preamble to sync to
<awygle> I didn't realize 100b had fill characters
<azonenberg> 100m is realtime clock recovery once the link comes up and there's always idles between packets
<azonenberg> same with gig and up
<azonenberg> 10m actually goes to differential idle between packets
<azonenberg> anyway I think what i'm going to do to implement a sort of pseudo-PID with a multi bit phase accumulator
<azonenberg> basically store a fractional phase counter, every time i see an edge too early increment and every time i see an edge too late decrement
<awygle> Yeah that's more or less what I was thinking
<azonenberg> then divide by say 16 to get the actual sampling phase angle
<azonenberg> also i finished schematic last night
<awygle> It's not_constant_ transitions with 8b/10b though is it?
<azonenberg> gonna try and go through the schematic design review over the next few minutes when i start work
<azonenberg> before i start work*
<azonenberg> then layout tonight
<awygle> So there's probably some complexity there
<azonenberg> there's no 8b10b
<azonenberg> 10baseT is Manchester, always a transition in the middle of a bit, sometimes between them
<azonenberg> 100baseT is 4b5b over MLT-3
<azonenberg> Which has a minimum of two transitions per five bits
<awygle> Ah
<awygle> I knew 10, didn't know 100 though
<azonenberg> here's a 100baseT waveform
<azonenberg> By comparison, zoomed out a lot, here's 10baseT showing the differential idle, preamble, start bit, and beginning of the message body http://thanatos.virtual.antikernel.net/unlisted/Screenshot8.png
<azonenberg> you can see how manchester is kind of a form of PSK
<azonenberg> http://thanatos.virtual.antikernel.net/unlisted/Screenshot4.png this is zoomed out 100baseT showing the 3-level waveform and the constant transitions, looks like i caught a few brief spots where it was 3 bits in a row the same but thats it
<azonenberg> This board is gonna be pretty silly looking, lol
<azonenberg> one FPGA, one triple-output LDO
<azonenberg> empty footprint for a SPI flash that i probably wont populate
<azonenberg> Two RJ45s, six SMA connectors
<azonenberg> and a bunch of passives :p
<openfpga-github> [yosys] azonenberg pushed 12 new commits to master: https://git.io/vdOzq
<openfpga-github> yosys/master 64ca0be combinatorylogic: Adding support for string macros and macros with arguments after include
<openfpga-github> yosys/master 2cc0916 Clifford Wolf: Fix ignoring of simulation timings so that invalid module parameters cause syntax errors
<openfpga-github> yosys/master cb1d439 Clifford Wolf: Merge branch 'master' of https://github.com/combinatorylogic/yosys into combinatorylogic-master
pie__ has quit [Ping timeout: 248 seconds]
m_w has joined ##openfpga
pie_ has joined ##openfpga
xdeller has joined ##openfpga
<rqou> aah azonenberg that's what you were doing with "weird" pin headers
<rqou> :P
<rqou> have you seen tmbinc's scope probe hack?
<azonenberg> rqou: lol
<azonenberg> no i havent
<azonenberg> I'm trying to make my own ProBus active differential probe
<azonenberg> I've managed to manufacture an edge launch push-on BNC
<azonenberg> So now i need the round machine pin header
<rqou> in case you were curious
<azonenberg> cool, but that's a tek
<azonenberg> this is a lecroy
<azonenberg> totally different connector
<rqou> huh, i thought that was a tek
<rqou> they all look pretty similar tbh
<azonenberg> no very different
<azonenberg> tek uses a BNC with a bunch of contacts in a ring around it
<rqou> er, that's _one_ tek interface
<azonenberg> ah yeah you're right
<azonenberg> there's another 2x6 using pogo pins or similar
<rqou> yeah :P
<azonenberg> we have one of those (not that scope but that connector line) at work
<rqou> i have the "contacts in a ring" one
<azonenberg> lecroy uses a 2x3 connector as well, plus a single ring
<azonenberg> For simple passive probes, a resistor from ring to ground sets the probe attenuation
<rqou> heh tek does that too
<azonenberg> For active probes, the 2x6 has a copy of the ring contact, ground, +/- 12V power, and I2C for a descriptor EEPROM
<azonenberg> i dont care about the eeprom, i just want to steal 12V power and have a resistor to tell the scope I'm a 20x probe
<azonenberg> this is an insertable pin header that takes round machine pins
<azonenberg> 2x3 on 2mm pitch
<rqou> careful, i wonder if the 12v will energize if there's no eeprom?
<azonenberg> pin diameter is important
<azonenberg> and i think the 12v powers the eeprom :p
<rqou> wtf
<azonenberg> through an LDO or something
<azonenberg> what would power the eeprom otherwise?
<rqou> but that's potentially dangerous if you somehow slip and mis-mate the connector
<azonenberg> my understanding is they have 12V at up to 1A available for all probes combined
<azonenberg> it shouldnt be possible
<azonenberg> the BNC + shell mean it can only go in one way
<rqou> ah true
<azonenberg> if you rotate 90 or 180 deg it wont insert
<azonenberg> and the BNC keeps you from slipping one pin out of alignment
<rqou> the tek ring can potentially have issues though
<rqou> during the mating process
<azonenberg> Yes
<azonenberg> This is the interface i have
<azonenberg> Not my scope but same probe style
<awygle> You described the multi contact ring, I looked up at the scope on my desk, thought "nuh uh", and then you posted a picture of my scope. Efficient.
pie_ has quit [Ping timeout: 258 seconds]
<azonenberg> This is the other tek interface
<rqou> yup, that's exactly the scope i have
<rqou> except mine is the "original" rather than the "C"
<azonenberg> We have a tek DPO at work, i dont know the exact model
<azonenberg> i know we have both tek interfaces among the scopes here
<azonenberg> we seem to mostly be a tek shop as far as scopes go
<rqou> huh, i just noticed that the ethernet adapter on my scope has a "collision" led
<rqou> yes, it really can get collisions
<rqou> azonenberg, how are you planning to handle that? :P :P
sgstair_ has joined ##openfpga
sgstair has quit [Disconnected by services]
sgstair_ is now known as sgstair
<azonenberg> I won't support half duplex
<azonenberg> so... :p
<azonenberg> qu1j0t3: I have a customer board in front of me that has a buffer with 40ps risetime on the output
<azonenberg> sooo
<azonenberg> won't be #1 but will probably be pretty close behind the real TDRs etc
<azonenberg> But it looks like ~500 ps to my scope
<azonenberg> Which is supposed to have a ~1ns rise time :p
<qu1j0t3> i think there are some of that order in the thread
<qu1j0t3> i'm not treating it as a contest, more as scope pr0n. I posted a modest, 19ns risetime off my Duemilanove :)
Hootch has quit [Quit: Leaving]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined ##openfpga
eduardo_ has quit [Remote host closed the connection]
xdeller has quit [Quit: Leaving]
m_t has quit [Quit: Leaving]
pie_ has quit [Ping timeout: 240 seconds]
xdeller has joined ##openfpga
pie_ has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rqou> you know what's weird? the os with fewest stupid errors when building icestorm/yosys/openfpga is actually macOS
waylon531 has quit [Remote host closed the connection]
<rqou> i wonder if this is just the power of apple engineering (/s) or whether i'm just not doing as many strange things
<qu1j0t3> well, it's clang
uelen has joined ##openfpga
<qu1j0t3> the others are clang or gcc?
<rqou> the others are gcc
<rqou> but i've found that being clang isn't automatically better
<rqou> clang's "compiler driver" logic is really dumb
<qu1j0t3> sure, but maybe quieter
<rqou> the issues i've encountered are always random library/ecosystem issues
<rqou> or being unable to figure out how to obtain the source code of libudev
<rqou> (which i have rewritten the code to not require, except azonenberg still hasn't tested it to his satisfaction)
<rqou> which reminds me that it would be really nice if somebody who both has a greenpak devkit and regularly runs a "more systemd-infested" distro would test https://github.com/azonenberg/openfpga/pull/93
<azonenberg> more invested than debian?
<rqou> yeah, i was thinking e.g. fedora
<azonenberg> infested*
<azonenberg> and its not that i havent tested to my satisfaction
<azonenberg> i havent tested whatsoever :p
<rqou> well, i've tested it :P
<azonenberg> Yay for being overloaded during Q4
<rqou> but only on not-as-systemd distros
<rqou> i.e. debian and android
<rqou> yes, it works on (rooted) android
<rqou> making it work without root is an exercise for the reader :P
<rqou> also azonenberg i sent you that PR before Q4, so that's not a good excuse :P :P
ZipCPU|Laptop has joined ##openfpga
<azonenberg> Yeah, but the con talk is :p
<azonenberg> i'll test it as things settle down, thats all i can promise
<azonenberg> my multitude of obligations are slowly dialing down
<rqou> you do realize i sent you that PR back in june, right? :P
<azonenberg> Yeah i know
<azonenberg> things started heating up in june
<azonenberg> :p
<rqou> lol