ZombieChicken has quit [Remote host closed the connection]
m_t has quit [Quit: Leaving]
kristianpaul has quit [Ping timeout: 248 seconds]
kristianpaul has joined ##openfpga
genii has quit [Read error: Connection reset by peer]
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
<cyrozap> azonenberg: It's consistent with the IDs for the A5, A7, A8, and A15: http://repo.or.cz/openocd.git/blob/HEAD:/src/target/arm_adi_v5.c#l1072
Bike has quit [Quit: Lost terminal]
ZombieChicken has joined ##openfpga
rohitksingh_work has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
<mithro> awygle: we where not crazy!
<awygle> mithro: at least not about this!
* awygle can't even remember what he was planning to document with this
<mithro> Ha lol
<azonenberg> cyrozap: what about cortex-m?
<cyrozap> azonenberg: Ok, so those aren't consistent, but with enough products a 12-bit identifier is going to lose it's numerological significance eventually :P
<azonenberg> Lol yeah
<pie__> <sorear> cad is a mess for the same reasons fpga toolchains are a mess
<pie__> what is that
kuldeep has quit [Read error: Connection reset by peer]
ironsteel has joined ##openfpga
soylentyellow__ has joined ##openfpga
soylentyellow_ has quit [Ping timeout: 240 seconds]
<rqou> azonenberg: ping?
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
<azonenberg> rqou: ack
<rqou> so, my pcb needs two voltages routed throughout, 1.8v and 3.3v
<rqou> how should i design the planes?
<rqou> (this is a 4 layer board)
<azonenberg> In general, I do S-G [core] P-S
<azonenberg> as my stackup for oshpark 4 layer
<azonenberg> If i have multiple power rails i route them in the single power layer
<rqou> right, that's what i'm doing so far
<azonenberg> using small pours on one of the signal layers to jumper as needed if the graph is nonplanar
<rqou> but what shape should the power planes be in?
<azonenberg> for example, on my ethernet switch line card
<rqou> also, did you see my rough board layout?
<rqou> do you have comments on it?
<azonenberg> (no)
rohitksingh_work has quit [Read error: Connection reset by peer]
<azonenberg> i saw the tweet but didnt look at it in detail
<azonenberg> anyway, basic constraints... high speed signals should be routed adjacent to either a VCCO or ground plane
<azonenberg> They should be adjacent to the same plane the whole path
<azonenberg> Minimize length and maximize width of high current plane areas to reduce resistive losses
<rqou> mind looking a bit? since this is (surprisingly enough) my first *) bga *) 4 layer *) designed for reflow only, not hand-soldering PCB
<azonenberg> So i see the overview render
<azonenberg> but no netlist :p
<azonenberg> What are the 5 pin components
<azonenberg> SMA connectors?
<rqou> yeah, it's just an overview at this point
<rqou> yes
<rqou> those will be moving
<azonenberg> do these have transceivers?
<azonenberg> or what
<rqou> nah, just clock inputs
<azonenberg> ah ok
<rqou> that's why there's also the janky 3-pin header :P
<rqou> for if your signal integrity doesn't matter _that_ much
<azonenberg> no comments at this point
<azonenberg> go through my design checklist though
<azonenberg> Feel free to rotate components if it makes routability easier
<azonenberg> and swap fpga pins
<rqou> yeah i'll definitely be doing that later
<rqou> any comments about the board being huge?
<azonenberg> my initial schematic generally only has bank-level assignments somewhat final
<azonenberg> and i expect to swap within banks
<rqou> all my banks are the same voltage, so whatever
<pie__> azonenberg, hm thats an idea, do routing tools support automatic alternative pin assignments?
<azonenberg> Not that i know of
<azonenberg> as far as board size, if you stick with 1x pmod
<rqou> azonenberg: anyways, one problem i have right now is that 1.8v is only needed in the middle of each part
<azonenberg> not really
<pie__> ^ awygle add to feature list ;D
<rqou> how do i get 1.8v to them without chopping up the 3.3v plane?
<azonenberg> i'd have a hook-shaped plane
<azonenberg> that goes along the edge of the pcb
<azonenberg> then up and under the middle of the 3.3 plane
<azonenberg> which would be kinda E-shaped
<rqou> hook-shape?
<azonenberg> chopping up the plane is fine as long as you dont have signal return paths crossing the chops
<azonenberg> look at the screenshot i linked
<azonenberg> and note that all of my fast diffpairs avoid the plane splits
<rqou> yeah, i have no idea how you're getting voltage _into_ those islands
<azonenberg> note also the use of outer layer planes to connect isolated islands
<azonenberg> (smps in bottom left)
<azonenberg> this is an extreme example for my boards since i have eight phys, four on each side of the board
<azonenberg> that all need the same few voltages
<azonenberg> plus pi-filtered analog rails off those
<rqou> hrm, but you _do_ have signals crossing the breaks in the planes?
<rqou> also wtf why is my gimp broken
<azonenberg> Yes, but slow ones
<azonenberg> like MDIO and JTAG
<azonenberg> not clocks or the SGMII pairs
<azonenberg> if your edge rates are low, going a bit out of your way isnt a problem
<azonenberg> fast edges dont like it and will radiate / have other problems
<azonenberg> I'll probably be using SLEW=slow for all of those crossing signals
<rqou> hrm, so i think i can just avoid having any signals crossing the plane gaps
<azonenberg> thats ideal
<rqou> azonenberg: so how about reaching the middle chip?
<azonenberg> with power? i'd have it come up from the bottom or one side
<azonenberg> whatever is easiest
<azonenberg> i'd have to see a ratsnest
<rqou> hmm, so current plan is a 5V ring around the entire outside of the board
<rqou> just a 50 mil trace
<azonenberg> What is 5V used for?
<rqou> the @bml_khubbard extension to PMOD
<rqou> "just put a 5V down the center in case anybody wants it"
<azonenberg> eeeew
<rqou> well, the PMOD also gets 3.3V
<azonenberg> but you mean 5V on the middle of the pmod header?
<azonenberg> that breaks compat with almost every pmod device out there
<rqou> in a header that is exactly between a pair of PMODs
<rqou> wait, it does?
<azonenberg> oh
<azonenberg> i thought you meant on a pmod pin
<rqou> no, completely separate header
<azonenberg> if its between the pair it only breaks compat with dual pmods, mechanically
<rqou> why?
<rqou> the spacing is still the same
<azonenberg> yeah but it might have protruding components i think
<rqou> what might?
<azonenberg> the pomod
<azonenberg> the pmod*
<azonenberg> i forget what the keepouts are for dual
<rqou> um, that would be really weird
<azonenberg> if you're allowed to reach out over the host between the headers
<azonenberg> anyway
<rqou> that would be _super_ weird
<azonenberg> As a general rule i only put my 5/12V in a small pour near the PSU
<azonenberg> but in this case i guess a ring is fine
<azonenberg> its out of the way
<rqou> because the PMOD headers are pulled in 0.4 inches from the side of the board
<azonenberg> So i assume 3.3 is your main vccio?
<rqou> yes
rohitksingh_work has joined ##openfpga
<rqou> anyways, the pmod mechanical spec is one reason this board is so damn big
<azonenberg> in that case i would default to a 3.3v pour around the entire board
<rqou> yes
<azonenberg> then make cutouts for other rails on an as-needed basis
<rqou> but right inside the 5v ring i would put a 1.8v pour/ring
<azonenberg> whats 1.8 for?
<azonenberg> vccint?
<rqou> that then reaches in to get the vcc_core for each chip
<rqou> yeah
<azonenberg> if you have all of the chips around the perimeter that would work
<azonenberg> i would have done it like veins of a leaf
<azonenberg> up the middle and out
<rqou> that was my other thought
<azonenberg> But again i'd need to see a ratsnest to decide
<rqou> but then it messes up the 3.3v
<rqou> ok, let me get you one
<azonenberg> But do you have hig hspeed signals crossing that one area?
<rqou> kinda?
<rqou> ftdi fifo
<azonenberg> And can you not route them on the FRONT layer, where they're referenced to the solid ground plane?
<azonenberg> this only matters for signals on the BACK layer referenced to the power plane
<pie__> apparently there *are* pcb HDLs
<azonenberg> non-adjacent layers dont matter
<pie__> why make a new one? are they crappy
<azonenberg> pie__: does the fact that nobody uses them answer your question?
<rqou> and yes, there will be (a lot of) pin swapping done on the center chip
<pie__> azonenberg, arguably that argument doesnt always work :P "better isnt always more popular"
<rqou> which is just a ginormous mux
<pie__> and hardware sounds like an industry that would be very loving of its tools :p
<pie__> azonenberg, im not even an EE i wouldnt know x'D im sorry
<azonenberg> rqou: sounds kinda like my coolrunner monster board
<rqou> it's exactly inspired by that
<rqou> but with fewer issues hopefully :P
<azonenberg> Lol
<pie__> rqou, "get off my lawn" :PP
<azonenberg> so the things at about the 3 o'clock position are dip switches?
<azonenberg> for config?
<rqou> yes
<azonenberg> That's a low speed signal so SI is a non-issue with them
<azonenberg> hmm
<azonenberg> and the FTDI is at 9:00?
<rqou> yes
<rqou> along with the ginormous HC49
<azonenberg> And it has no paths to any of the other chips
<rqou> HC49 really sucks :P
<azonenberg> everything goes through the mux?
<rqou> only to the mux
<azonenberg> in that case i'd have an H-shaped 1.8V pour
<azonenberg> (rotated H)
<azonenberg> and have the io from each fpga to the mux simply avoid crossing it on the back layer
<azonenberg> Should be pretty easy
<rqou> and also move the SMAs appropriately?
<azonenberg> Yeah
<rqou> also, why is my board so _huge_?
<azonenberg> a ring of 1.8V would be annoying since you'd have to route the pmod stuff over it
<azonenberg> not that pmods are exactly high speed connectors
<azonenberg> but this wouldnt help
<azonenberg> Because pmods
<azonenberg> my preferred connector for higher density / speed is samtec q-strip
<rqou> yeah, well, these aren't exactly high-speed parts
<azonenberg> a QTH-030 is about the size of a pmod but gives you a ground plane and 60 matched 50-ohm signals
<azonenberg> or 20 diffpairs
<rqou> btw, what's the proper way to fan out a clock tree?
<azonenberg> But its also $10 per connector (not per mating pair) :p
<rqou> i just copied your 49.9 ohm source termination for now
<azonenberg> That works fine for point to point
<rqou> i need point to multi-point though
<azonenberg> for fanout, the easy option is to echo it through an fpga and accept a bit of skeqw
<azonenberg> skew*
<rqou> this seems to be what you did on the coolrunner board :P
<azonenberg> using the fpga as a buffer
<rqou> skew doesn't matter, but the center FPGA has zero remaining IOs
<azonenberg> did i? that must have been me being derpy then
<azonenberg> other option is to drop a few cents on a clock buffer chip
<rqou> i've seen some weird triangles built out of resistors or something
<azonenberg> 50 ohm series termination on a multi-drop bus would be problematic
<azonenberg> but at the speeds on the coolrunner board i probably didnt care :p
<azonenberg> and personally i'd just buffer it
<rqou> so i do care, because unlike you i have both a fast clock and a slow clock
<azonenberg> this is what i do on the ethernet line card
<rqou> 2.048 MHz CLK2 and 40 MHz CLK3
<azonenberg> i have a single 25 MHz osc and eight port buffer
<rqou> can i just use a resistor wye?
<rqou> actually, half-serious: can i just make 4 50-ohm traces that gradually taper into one :P
<azonenberg> i know passive techniques exist but i'm pretty sure you lose amplitude
<rqou> but i don't care that much
<azonenberg> a dumb 2:1 impedance matched splitter loses 3 dB
<rqou> what about tapering in four traces into one?
<azonenberg> i dont know
<azonenberg> i'm not an E&M guru
<azonenberg> i tend to go with simple, conservative designs that i know will work
<rqou> apparently that actually works for RF (at least sometimes)
<azonenberg> rather than trying to minimize cost
<rqou> but then i have to go find a clock buffer chip
<azonenberg> so?
<rqou> unless you mean to just stick in some 74HCxxx thing :P
<azonenberg> no i mean an actual clock buffer
<azonenberg> silabs etc makes plenty of them
<azonenberg> And i tend to build one-off designs where NRE on the PCB/stencil, plus design time and the major IC (FPGA etc) is the big expense
<rqou> yeah, i used one of those at BRCM
<azonenberg> so trying to penny pinch $10 per board on passives or support components isnt worth it
<rqou> it's nice and fancy, but not really necessary
<azonenberg> Other question
<azonenberg> do you actually need phase alignment on these clocks?
<rqou> no
<azonenberg> oscillators are cheap and small... :p
<rqou> lol
<azonenberg> you could just throw down several :p
<azonenberg> say one at top and one at bottom, betwee nthe fpgas
<azonenberg> and have a < 1/10 wavelength trace between them
<rqou> so multiple app notes i've seen say that carefully-shaped t-junctions work
<rqou> i'll probably just use that
<azonenberg> yeah i'm not saying it wont work
<pie__> i might give working on some pcbhdl a shot in the near future, goto -> ##pcbhdl :D
<azonenberg> i'm just saying, a buffer (with everything point to point) is the lowest risk, lowest effort solution
<pie__> exam season over today, im freee
<rqou> anyways, i specifically added a 40 MHz clock so that i can do cool VGA demos too
<rqou> because apparently those are all the rage
<azonenberg> > 2018
<azonenberg> > "VGA" and "cool" in same sentence
<rqou> 40 MHz is supposedly the "proper" dotclock for 800x600x60Hz
<rqou> apparently people go nuts over sprite engines or whatever in FPGAs
<rqou> which is weird to me, because sprite engines are pretty simple
<rqou> heck, i bet you could fit "mode7" logic into a larger max v
<rqou> azonenberg: what do you think?
<azonenberg> whats mode7?
<rqou> weird name for the technique where, given a 2d tile engine that can perform affine transformations of a layer, you alter the transform matrix on each scanline to simulate 3d
<azonenberg> no idea
<pie__> rqou, ugh i saw that the other day
<pie__> rqou, and i cant remember
<azonenberg> my only "GPU" to date was a very simple 2D thing for rendering on a 128x32 oled
<azonenberg> if i ever do a "real" one it will probably implement opengl ES or something in hardware :p
<pie__> no shitty intermediate compilers right
<rqou> azonenberg: basically the general algorithm is: for each screen pixel, use affine transform to get a "background layer" pixel, then perform the usual 2d tile fetching logic and display the resulting pixel
<rqou> so the hardest part is multiplying
kuldeep has joined ##openfpga
<rqou> azonenberg: wat, kicad planes don't auto-avoid each other?
<azonenberg> no, the DRC isnt that advanced yet - would be nice
<azonenberg> it does DRC fail
<azonenberg> but it wont auto avoid
<rqou> apparently it does
<rqou> there's a "zone priority" setting
<rqou> you just have to go on the forums to figure it out :P
<azonenberg> lol
<rqou> i love how kicad is the best piece of crap we've got :P
<rqou> azonenberg: how's this for a first-order approximation? https://photos.app.goo.gl/WtRxLXWpjFAr1WB29
<azonenberg> rqou: not bad
<azonenberg> personally, i dont worry about planes at this point though
<azonenberg> i start by drawing normal min-sized tracks for power
<azonenberg> get a complete netlist
<azonenberg> Then do the copper pours as a near-final step once i have a netlist-complete layout and am optimziing the geometry
<azonenberg> pours take more work to redo than a trace if you move something
<rqou> huh
<rqou> i'm used to doing power first on 2-layer boards
<rqou> combined with the part where i'm not too familiar with 4 layer :P
<rqou> wtf how come a bunch of program suddenly won't start on my machine
<rqou> just linux things
<rqou> azonenberg: how do you place decoupling for QFPs?
<rqou> azonenberg: also, what trace width/space do you use for usb, and what size vias do you use for bga fanout?
<azonenberg> its been a while since i've done usb so i dont have design rules handy
<azonenberg> 245 um trace / 250 space is 100 zdiff on oshpark so you'll want slightly wider traces to get 90 zdiff on the same process
<azonenberg> (usb1/2 is weird and doesnt use 100 zdiff like every other differential iostandard on the planet)
<azonenberg> for decoupling, generally either on the top side right between the pins
<azonenberg> or on the back side
<azonenberg> If on the back what i do is, have one of the power/ground vias go out and the other go in under the chip
<azonenberg> then have the cap kinda straddle the vias
<rqou> er what?
<azonenberg> you can also have them fan out on the top layer in a bit of a V-shape and put the cap on that
<rqou> so i'm trying to put all decoupling on the bottom
<azonenberg> yes, thats what i normally do
<rqou> but i seem to recall people saying that your power trace is supposed to hit the capacitor first
<azonenberg> forget that
<rqou> but that's not really possible in this case?
<azonenberg> thats hogwash
<rqou> so that only applies to 2-layer?
<azonenberg> you want a low impedance path to both the plane and the cap
<rqou> oldschool long power/gnd wires among 74xx chips
<azonenberg> this means, via goes directly to the plane
<azonenberg> trace from via to qfp pin is as short as possible within fanout routability constraints
<azonenberg> trace from via to cap is as short as possible
<azonenberg> ideally you want kind of a []8 shape
<azonenberg> where the cap has one via to the side of each pad
<azonenberg> and the annular ring is tangent to the cap so there's basically no trace
<azonenberg> you can't make the ring overlap the cap pad or you might get solder wicking into the via (oshpark tents vias decently but you dont want to rely on it)
<rqou> so where does the "trace should hit capacitor first" advice come from?
<azonenberg> Probably old school no-plane designs
<azonenberg> and misguided attempts to minimize impedance from cap to the IC
<azonenberg> The goal is to minimize inductance from the cap to the die
<azonenberg> in-package stuff is fixed and unavoidable
<rqou> so for my "iz cheap" 2 layer stuff i usually put a ground plane on the bottom
<azonenberg> Optimal: cap on component side right between pins (but with anything finer pitch than a SOIC this is almost impossible)
<rqou> and then route power as a star on the top
<rqou> is this bad?
<rqou> er, not quite a star
<rqou> usually i route power as a ring, and then tap off of it
<azonenberg> Next best: cap on back side with low inductance mounting to plane
<azonenberg> sorry i meant, next best: cap on back side with via in pad
<azonenberg> followed by optimized vias
<azonenberg> least good is long traces anywhere
<azonenberg> For 2L getting good signal integrity is near impossible, i dont have any strategies to recommend since i just dont do fast stuff on 2L
<azonenberg> star topology power works ok-ish as long as you have good decoupling local to each chip (higher idnuctance than a plane)
<azonenberg> and as long as you have all of your signals referenced to ground
<rqou> i mean, my 2l stuff isn't particularly fast
<azonenberg> you cant use power as a ref plane obvs
<azonenberg> if you dont have a power plane
<rqou> i'm not @bml_khubbard
<azonenberg> lol
<azonenberg> yeah hes nuts
<azonenberg> smart but a little insane
<azonenberg> i forget what pcb tool he uses... diptrace? expresspcb? something totally not meant for fast work
<rqou> so i would describe my 2l style as a "oldschool design with modern influences" style
<rqou> but either way, it's 2l so signal integrity isn't that good no matter what
<azonenberg> yeah
<azonenberg> i value my time enough that it's not worth wasting debugging flaky 2L designs
<azonenberg> if i was mass producing i'd consider cost optimizing
<azonenberg> but for a one-off i prefer to minimize risk
<azonenberg> even if the cost is slightly higher
<rqou> zomgwtf
<rqou> i just noticed all my pmod pinouts are fucked up
<rqou> i hate how inconsistent kicad is with everything
<azonenberg> how so? pin numbering confusion?
<rqou> yeah
<daveshah> pmod has a really odd numbering system
<daveshah> Because it was originally only one row
<azonenberg> yeah i have a connector footprint specifically for pmods
<rqou> azonenberg: now i get why you do pcb layout and schematic simultaneously for fpga designs
<azonenberg> that uses the weird numbering
<azonenberg> rqou: its not simultaneous so much as a phased approach
<azonenberg> start with initial schematic capture to define the first round netlist
<azonenberg> do schematic review
<azonenberg> then adjust the pin assignments as you do layout
<azonenberg> then double check the final pin assignments and review the layout
<azonenberg> so... turbulent waterfall model? :p
<azonenberg> i.e. directional but with some mixing
<azonenberg> there's definitely a "figure out all of the connectors, major subsystems, # of caps, PSU, etc" phase that should happen first
<azonenberg> or you risk doing layout that has to be undone
<azonenberg> but the pin assignments do have to change a lot to optimize for layout
<azonenberg> especially since sch symbols normally have pins in die-pad order
<azonenberg> which may not be the same as package pin order, depending on the package
bitd has joined ##openfpga
<rqou> pmod is officially the worst spec
ZombieChicken has quit [Remote host closed the connection]
rohitksingh_work has quit [Read error: Connection reset by peer]
<gruetzkopf> i really need to do a proper implementation of all the terrible things i did to pcie
<pie__> azonenberg, i take it back this is really all i found on a cursory search https://www.osti.gov/servlets/purl/1078729
bitd has quit [Remote host closed the connection]
m_t has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
pie__ has quit [Ping timeout: 268 seconds]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
elms has quit []
elms has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
scrts has quit [Ping timeout: 248 seconds]
Bike has joined ##openfpga
ironsteel has quit [Quit: Ex-Chat]
scrts has joined ##openfpga
genii has joined ##openfpga
scrts has quit [Ping timeout: 264 seconds]
scrts has joined ##openfpga
pie__ has joined ##openfpga
pie__ has quit [Ping timeout: 240 seconds]
soylentyellow_ has joined ##openfpga
soylentyellow__ has quit [Ping timeout: 256 seconds]
pie__ has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
<awygle> pie__: altium supports that
<awygle> ugh how does _everyone_ somehow learn that "trace hit cap first" thing?
<awygle> rqou: if you're being cheap/lazy and don't want a clock buffer, the next best thing is source-series termination with fly-by routing
<awygle> your board looks next to impossible to route fly-by though
scrts has joined ##openfpga
<awygle> a real impedance-matched power divider is a pain in the ass to get right, if you're planning to go that route i wouldn't even bother and just do Terrible T Junctions and accept slow edge rates
<awygle> (like... potentially very slow)
<awygle> pie__: lmao
scrts has quit [Ping timeout: 264 seconds]
<awygle> rqou: as for the hugeness, i recommend rotating your DIPs, crunching in slightly in all dimensions, fitting in 100mmx100mm, and going with seeed or dirtypcbs or one of those. although apparently if you go with JLCPCB/EasyEDA you don't even have to bother shrinking it to get decent prices.
<awygle> <subjective>(or just don't use DIP switches as they are the worst)</subjective>
<kc8apf> mithro, awygle: wavedrom's bitfield tool can be run locally as well. 'npm install -g bit-field' and bitfield will be in your PATH
<awygle> kc8apf: thanks!
* awygle puts "lern2node" on his list
<kc8apf> I've been using it to make register diagrams for my blog posts. source files for those are at https://github.com/kc8apf/xc7-docs/tree/master/diagrams
Miyu has quit [Ping timeout: 248 seconds]
<rqou> awygle: actually, fly-by is possible because the center chip doesn't need the clock
<rqou> so you can go around the edge
<awygle> that does make it more achievable (honestly i can't tell where the clock is coming from though)
<rqou> i mean, it comes from a 4-pin oscillator that can go anywhere
<awygle> ah
<rqou> also, does the "trace hits cap first" thing have any truth at all?
<rqou> only for shitty 2 layer?
<awygle> the rule the "trace hits cap first" thing is trying to proxy for is "minimize inductance of the loop"
<daveshah> It might for RF power feeds to MMICs and stuff
<awygle> on any board with planes, "trace hits cap first" is probably _not_ the minimum-inductance solution, unless you're using microvias or something
<rqou> what about on 2 layers?
<awygle> it depends on a lot of things, and most of the time it doesn't matter, but i'm of the opinion we shoudl just teach about loop inductance properly in the first place
<awygle> rqou: on 2 layers, it still doesn't actually matter 90% of the time, because the critical dimension is cap-to-pin. where the power pour is is ~irrelevant.
<awygle> (unless you're under-decoupled in which case you have other problems)
<rqou> but i usually don't use a pour for power, just for ground
<awygle> sometimes trace lenth is used to add inductance for complex filtering/impedance games in the RF case but that's another story (you have a complex impedance target, you're not just trying to minimize like in the power case)
<awygle> rqou: if your power delivery trace has significant inductance that can be more complicated. usually you can fix that by just decoupling moar though.
<rqou> yeah, i usually make sure there's sufficient decoupling
<awygle> if you're in a scenario where you're well decoupled from the rest of the PDN, then you just want to minimize the pin-to-cap-to-pin loop. do whatever gives you the best result for that.
m_t has quit [Quit: Leaving]
<rqou> hrm, so purposely routing around to get the power trace to hit the cap first can be worse?
<awygle> yup
<awygle> i really would like to know where that belief comes from. i somehow absorbed it too even though i don't remember ever being actually taught it, and had to un-learn it later.
<rqou> I've seen multiple articles recommending it
<awygle> next time you come across one toss it my way
<awygle> (plz)
scrts has joined ##openfpga
<rqou> awygle: there's this for instance: https://electronics.stackexchange.com/a/272546
<awygle> luv 2 make claims with no sources or reasoning
* awygle is tempted to go full sonnet on this for a blog or something
<awygle> unfortunately i'm terrible at sonnet
<rqou> there's the image in the first post of this big mess of a question: https://electronics.stackexchange.com/questions/74509/how-to-place-decoupling-capacitor-in-four-layer-pcb
<rqou> which supposedly comed from some vendor, but the stackexchange question now has higher search rank than whatever vendor note it came from
<pie__> gotta love it when ppl dont list references
<awygle> the first response to that second post is pretty good
<rqou> but it's missing a "tldr do this"
<awygle> that's why it's good :p
<awygle> but also why it's less useful yes
<awygle> okay so a 6 mil trace on 62-mil 2L FR4 is 20.4 nH/in, while a 10/20 via in same is 1.3 nH. so (to first order) if your trace is less than 64 mils, it's better than a single via in those circumstances.
<rqou> single via for what?
<awygle> on the oshpark 4l stackup a via to the adjacent plane is 0.0676 nH and a trace is 9.8 nH/in, so breakeven is ~7mil
<rqou> how are you getting these?
<awygle> Saturn PCB toolkit
<awygle> or the calculator of your choice
<awygle> that's just the one i use
<rqou> does this cost $$$?
<awygle> na
<awygle> it is cost-free
<rqou> so what exactly is the shape you're referring to by "single via" vs a trace?
<awygle> i hadn't expanded out to actual decoupling geometries, just getting some basic numbers
<awygle> i don't have time to do a real analysis (even a halfassed one) right now
<awygle> but if you want to see one ping me tomorrow, i'm easily nerd-sniped into this kind of thing -_-
<rqou> sure, since i suck at this
<awygle> http://www.x2y.com/publications/decoupling/jul24-06.pdf this presentation is really good, despite the obvious bias/sales pitch aspect
scrts has quit [Ping timeout: 256 seconds]
scrts has joined ##openfpga
<azonenberg> awygle: so what i'm hearing is, on oshpark 4L, you are almost always better off dropping another via
<azonenberg> than sharing
<azonenberg> i.e. any more than 175 um of trace and it's worse than a via
scrts has quit [Ping timeout: 256 seconds]
scrts has joined ##openfpga
ZombieChicken has joined ##openfpga
Hamilton has joined ##openfpga
<azonenberg> soooo
<azonenberg> i'm running into an interesting problem
<azonenberg> trying to get logtools to play nicely with shared libraries
<azonenberg> Since right now it defaults to being built as a static lib
<azonenberg> This is fine if you statically link and build everything at once
<azonenberg> but if you try to build a shared library that calls into logtools
<azonenberg> and use logtools elsewhere in the project
<azonenberg> i think you end up with two copies of all the logtools globals
<azonenberg> am i wrong?
<azonenberg> whitequark: ^
bitd has joined ##openfpga
X-Scale has quit [Ping timeout: 260 seconds]
<rqou> azonenberg: afaik you are wrong for ELF and maybe Mach-O, possibly correct for PE
<rqou> you can also just... not use shared libraries?
<rqou> why do you want that anyways?
<rqou> imo let "distro people" fuck it up and add this capability
<azonenberg> So if i have two shared libraries that contain the same symbol
<azonenberg> and i link an app to them
<azonenberg> what happens?
<rqou> one of them wins
<azonenberg> What happens to the loser
<rqou> depending on search order
<azonenberg> does it referecen the winning symbol?
<rqou> yes
<azonenberg> or does it have its own private copy of the global that isnt in sync with the rest
<rqou> this is why the GOT exists
<rqou> things that are static are duplicated though
<azonenberg> Hmm, ok
<rqou> this is also how LD_PRELOAD works
<azonenberg> i knew it would work for the app but i was less sure about having the two libs both pick one symbol to ref
<azonenberg> vs having them each have their own local copies
<awygle> azonenberg: well, there are probably two vias. And you might be going further than just to the next plane. But yes.
<rqou> so if you have two copies of the same version of the same lib, everything just refers to one copy
<rqou> the other one just wastes address space
<azonenberg> And the reason i came up with this issue is that i am trying to make scopehal etc build as a separate non-antikernel project
<azonenberg> which i guess means i need to pull logtools in there too
<rqou> if you have two copies of _different_ versions of the same lib, you're fucked
<awygle> Also I didn't even try to calc inductance on the plane. Probably low.
<rqou> in that case almost all symbols will use one version, but symbols that only exist in the other version will come from that version
<rqou> but when the new version calls functions that exist in both, it always calls the old version
<rqou> if some internal data structures changed, you get mysterious bugs
<azonenberg> This is why i like the PE linker model
<azonenberg> where you explicitly link to "export foo() in bar.dll"
<rqou> PE tends to lead to problems of global data becoming no longer global
<rqou> so you can't e.g. exchange FILE* correctly
X-Scale has joined ##openfpga
Hamilton has quit [Quit: Leaving]
<sorear> PE: if you link two copies of libc or libpng, it works as long as you don't try to pass a struct allocated by one to the other
<sorear> ELF: if you two copies of libc or libpng, it will not work at all because they step on each others' symbols
<sorear> the main thing ELF has going for it is that it's extremely close to the semantics of static linking
<cr1901_modern> >if you link two copies of libc or libpng, it works as long as you don't try to pass a struct allocated by one to the other
<cr1901_modern> I wonder what a minimal example of passing a struct allocated by one to the second copy looks like
<cr1901_modern> Also, you can't link in two copies of e.g. libpng at all?
<cr1901_modern> in ELF*
<mithro> quick survey - How would you draw a latch to differentiate it from a flip flop?
<daveshah> No clock triangle
<azonenberg> mithro: edge-sensitive mark present/absent on the clock input?
<azonenberg> exactly
<daveshah> Indeed a latch should really only have an enable input, not clock
<mithro> I kind of wish that a flip flop wasn't normally box shaped...
<daveshah> At least you're not in a European uni, where we are taught the IEEE convention of all logic being boxes
<daveshah> Although most of our courses use the common symbols not the box ones
<azonenberg> That's a IEEE convention? what are they smoking?
<mithro> common symbols being the "and gate" and "or gate" shapes?
<mithro> azonenberg: Drawing curves is hard on a dot-matrix printer maybe? :-P
<awygle> i like that the URL is screaming
bitd has quit [Remote host closed the connection]
<mithro> daveshah: Oh - that might explain what whitequark was trying to explain to me in their ice40 viewer thingy...
<daveshah> Exactly, that used the rectangular ones too
<mithro> So `(* FOO=1 *)(* BAR=1 *)` should actually be `(* FOO=1, BAR=1 *)` ?
<daveshah> mithro: yeah, I think that works
<daveshah> For some reason you don't see it so often
<mithro> Should the first one also work?
<daveshah> Definitely
<daveshah> More than one attribute is quite rare, so you don't see either often
<daveshah> Definitely seen the first though
<daveshah> And the latter at least once
mkal has joined ##openfpga
<mkal> first time here.
<daveshah> mkal: welcome
<azonenberg> o/ mkal
<azonenberg> are you @dsponfpga?
<mkal> yes
<azonenberg> So yeah, i would love to make an FPGA from scratch for that MPW
<azonenberg> Do you have experience doing ASIC backend work?
<mkal> yes, I probably taped-out more than a dozen small test chips; mostly with commercial tools though. need to catch up with f/oss toolset; also probably need to get permission for f/oss contributions from work
<mkal> we actually met at one of the pwn meets a couple of months back
<azonenberg> oh cool
<azonenberg> So yeah, i made a cycle-accurate / bitstream-accurate coolrunner-2 emulator in verilog
<azonenberg> to run on a 7-series FPGA
<azonenberg> but i'd love to try my hand at a from-scratch new architecture
<azonenberg> I think LUT6s might be the way to go because that means we can do more logic with less interconnect, might allow higher density in a very space constrained environment
<mkal> sounds great. we can put down an architecture and code it in RTL or gates
<mkal> yes, LUT6 makes sense.
<azonenberg> My thought was to start with a pure simulatable RTL design
<azonenberg> maybe have some of the other folks here get a VPR-based P&R working for it
<mkal> absolutely; that's the easiest/fastest way to get started.
<azonenberg> then make a second version of the design with more customized direct primitive instantiation, verify equivalence
<azonenberg> And then do custom tile-based layout
<mkal> we can always look at the generated logic and see if we dont like anything about it.
<azonenberg> yeah we could stay full synthesized logic and then just do hand placement off that
<azonenberg> Do you think 8x8 LUT6s is a reasonable target?
<azonenberg> if we use two adjacent blocks
<mkal> yep, sounds good
<azonenberg> have each tile be about 2:1 aspect ratio
<azonenberg> interconnect then lgoci
<azonenberg> logic*
<azonenberg> So the array will be logically square but physically 2:1
<sorear> it seems to me that the optimal LUT size is a function of the total chip size
<azonenberg> sorear: why do you say that?
<azonenberg> in general i am seeing a trend toward coarser grained logic elements
<azonenberg> to reduce interconnect penalty
<azonenberg> lut6 vs lut4, larger block rams
<sorear> because as the chip gets bigger, the typical length of a routing path between two LUTs increases, which means you need more interconnect per LUT
<azonenberg> The other thing is, as you shrink to leading-edge nodes
<mkal> for large chips, one can do hierarchical interconnect
<sorear> so if you want to keep the interconnect area/LUT area ratio constant, the LUTs also need to get biggee
<azonenberg> ram gets denser faster than fpga logic does
<azonenberg> So the amount of bram you can fit in a CLB-sized space grows
<sorear> in a tiny FPGA, interconnect is cheap, so you have less pressure to make coarse-grained elements
<azonenberg> For this project i'm thinking of having a single block ram sitting in the shared space, seems like they were talking about doing that
<mkal> do we have an sram compiler for the process we're considering? that's one of the critical pieces of IP
<azonenberg> it sounds like they are using UMC 180nm
<azonenberg> I can always take measurements off a coolrunner in the SEM :P (only half kidding)
<azonenberg> but i assume they can get access to one
<mkal> f/oss sram compiler exist? probably not.
<azonenberg> for the FPGA though, we cant use a normal sram compiler
<sorear> assuming that user designs roughly follow Rent's rule, the amount of interconnect you need is a superlinear function of the LUT count
<azonenberg> we need single cells so we can route to all of the config bits separately
<sorear> if user designs are fundamentally 2-dimensional and don't have long wires the story is different
<azonenberg> LUTs are not going to be 64x1 SPRAM
<mkal> that's true; regular sram compilers have a minimum size limitation
<azonenberg> They're going to be 64 DFF/latch elements and a bnuch of muxes
<azonenberg> This is how actual FPGA dies are implemented, i've seen them :)
<awygle> https://github.com/VLSIDA/OpenRAM ? not sure if S or D
<mkal> but not looking forward to doing custom sram cells either :-(
<azonenberg> why use sram at all?
<azonenberg> whats wrong with a d latch?
<azonenberg> have a shift register along the edge of the chip
<azonenberg> shift in one column of bits
<mkal> yes, latches are probably good enough for what we want.
<azonenberg> then strobe LE for that column of config bits
<sorear> sram is 6 transistors, latches are like 10
<azonenberg> yes, but its more complex write logic then
<azonenberg> coolrunner is heavily optimized
<azonenberg> they have three different 6T SRAM cells in the chip, at least
<azonenberg> tuned for different shaped places on the die
* sorear suddenly wonders if anyone has done a DRAM FPGA
<azonenberg> there's a single bit |[ shaped cell
<mkal> refresh is an issue
<azonenberg> There's a back to back ]H[ shaped one
<azonenberg> sorry i meant |[]|
<mkal> need to logout & get on an airplane. will be in redmond tonight
<azonenberg> Then there's a _-_ shaped one used in the ZIA
<azonenberg> So yeah we wont be at optimal packing density, but that's totally fine
<azonenberg> this is a PoC and tech demo, from my perspective
<azonenberg> it wont be big enough to use anyway
bitd has joined ##openfpga
mkal has quit [Ping timeout: 252 seconds]
Bike has quit [Ping timeout: 252 seconds]
bitd has quit [Ping timeout: 245 seconds]
bitd has joined ##openfpga
noobineer has quit [Remote host closed the connection]
bitd has quit [Ping timeout: 265 seconds]
bitd has joined ##openfpga
bitd has quit [Read error: Connection reset by peer]
<mithro> azonenberg: I'm interested in new FPGA developments :-)
<azonenberg> mithro: tl;dr we're in tweet discussions with onchip about making a f/oss embedded FPGA on 180nm UMC as part of a multiproject wafer they're doing using free tooling
<mithro> azonenberg: Poke me in 30 minutes
noobineer has joined ##openfpga
noobineer has quit [Ping timeout: 256 seconds]
Bike has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 264 seconds]
bitd has joined ##openfpga
bitd has quit [Quit: Leaving]
bitd has joined ##openfpga
bitd has quit [Quit: Leaving]
Miyu has joined ##openfpga
<rqou> azonenberg: your proposed arch superficially sounds like an altera arch :P
<kc8apf> azonenberg: is the symbol exported or private? If it's private, you just get a copy per library. If exported, you get the linker-dependent behaviors previously described.
genii has quit [Remote host closed the connection]