diadatp has joined ##openfpga
<pie__> * azonenberg finds it funny that people complain about nuke waste
<pie__> <azonenberg> while also banning reprocessing that would turn 98% or so of it back into usable fuel :p
<pie__> hopefully solid nuke storage gets turned into a superfund site before 100,000 years is up
<Ultrasauce> I think the short answer is if it were easy they'd be doing it
<azonenberg> Ultrasauce: reprocessing in general is politically difficult
<rqou> but but but but terroristsssssssss :P
<azonenberg> people are worried that transporting / doing anything to waste could cause environmental issues, increase risk of it being stolen by terrorists, etc
<rqou> also the potential of an arab nuclear reactor? :P
<rqou> gotta get your tech from north korea instead :P :P
<rqou> does Best Korea have reprocessing? :P
<rqou> they do right? hence the failed stuxnet attempt on them?
<rqou> (failed because they had almost no connection with the outside world, unlike iran)
<rqou> azonenberg: when are you building that ultracentrifuge? :P
<azonenberg> rqou: lol
<azonenberg> gas diffusion might be a fun way to make booze too
<whitequark> awygle: nice story
<awygle> whitequark: yeah I liked it
<rqou> amazingly, it's apparently _not_ a reference to nuclear weapons
<rqou> just "traditional" warfare
<rqou> well, "modern" but pre-nuclear
diadatp has quit [Ping timeout: 265 seconds]
<Bike> warsaw and manila got it worse right
<awygle> did anyone get pissed by that MOAB reporting a while back?
<rqou> MOAB?
<awygle> Mother of All Bombs
<Bike> "daisycutter" sounds better
<azonenberg> awygle: apparently the proper name now is "massive ordnance air blast"
<azonenberg> of course i'm sure nobody in the service uses that unless they're on camera :P
<awygle> The point is it's 11 tons, which makes it 500 times less powerful than Little Boy, but it was reported as like a dangerous escalation in the potential of warfare
<awygle> "the biggest non nuclear explosion" but no context on what that means
<Bike> i can see that making sense. i mean, the military is way less likely to deploy a nuclear weapon
<whitequark> it also produces a volumetric explosion
<Bike> but then it's more like, measuring war-ness by tons of TNT kind of sucks
<Bike> warocity
<whitequark> which is significantly more damaging afaik
<Bike> what is a volumetric explosion?
<awygle> it's true that damage doesn't scale linearly with yield
<whitequark> instead of having this chunk of fuel+oxidizer that quickly increases in volume and becomes gas, it spreads fuel over a large volume and ignites it, which creates more of a pressure differential or something like that
<whitequark> the bottom line is that you don't get shredded by fragments, your innards get liquefied by the shockwave
<whitequark> also if you get it into a building it exhausts oxygen in the building as the products take less volume than the reagents after they cool down a bit
<whitequark> and the building folds onto itself
<whitequark> at least, i think that's what happens, i might be wrong
<rqou> wow
<Bike> i'm gonna be honest, both options re: my innards sound unfortunate
<rqou> we've certainly come a long way since "yellow dyes" :P
<Bike> "escalation" makes me think less technical things like altering the RoE or increasing deployment into new areas or suchlike
<whitequark> i don't think it's a paradigm shift either
<whitequark> it's just a pretty nasty weapon
<awygle> "fuel air bomb" is the term of art
<rqou> <ha ha only serious> which company's stock will go up/down once one of these weapons actually gets used?
<rqou> i.e. who is profiting from developing these?
<whitequark> Bike: oh
<whitequark> i was referring to https://en.wikipedia.org/wiki/Father_of_All_Bombs actually
<whitequark> the naming is a bit confusing
<Bike> thermobaric
<whitequark> rqou: MOAB is Air Force's internal development
<Bike> that's what i thought a fuel air explosive was
<Bike> introducing the new Second Cousin of All Bombs, which is actually a recoilless rifle
<whitequark> "Another Defense Intelligence Agency document speculates that because the "shock and pressure waves cause minimal damage to brain tissue…it is possible that victims of FAEs are not rendered unconscious by the blast, but instead suffer for several seconds or minutes while they suffocate"."
<rqou> whitequark: i don't have a link handy, but iirc somebody back in the day managed to figure out that the "secret new material" used in thermonuclear weapons was lithium
<rqou> solely by looking at stock data
<whitequark> rqou: yup
<Bike> you know, today i saw the headline ««Is curing patients a sustainable business model?» Goldman Sachs analysts ask» but i think you managed to top that, as far as impersonal reports go
<whitequark> even worse
<whitequark> rqou: USAF decided to check if a few rando physics students can develop a functional nuke just from open materials, hired a few, and they did a good job
<rqou> a gun-type nuke? or a more modern design?
<whitequark> i don't recall
<Bike> i did not, though i've heard of PLUTO and the churchill crocodile
<Bike> i like how wwii had all these nuts engineering projects but their results were uh, equivocal
<Bike> pluto didn't take over from tankers, mulberry harbors didn't last very long
<awygle> Woo boards
<Bike> the nazis had all kind of sci-fi bullshit that did them very little good
<Bike> bombsights were considered so important they were mounted with self-destructs (who knew anyone's actually ever done that) but the nazis had the tech already anyway
<awygle> Yeah but also radar lol
<awygle> The nuts projects are only more nuts than the ones that worked with the benefit of hindsight
<Bike> fair
<Bike> oh yeah, and that brother? of JFK who died in a prototype drone bomber
<Bike> controlled by television
<awygle> Skinner wanted to put pigeons in missiles. Did we ever try that?
<Bike> never deployed, it seems
<Bike> «Project Pigeon was revived by the Navy in 1948 as "Project Orcon"» hey nice
<Bike> the "static flame trap" in the PWD article is exactly like half life two. that's kind of weird, honestly
<Bike> whitequark: wtf, the "harvey flamethrower" looks even shittier than a farming flamethrower
diadatp has joined ##openfpga
<sorear> 3 mg/m^3
diadatp has quit [Ping timeout: 264 seconds]
<sorear> How far does zeolite tech need to advance before this is an interesting number
<sorear> How long do we have until then
<awygle> sorear: huh?
<sorear> awygle: natU in seawater.
<awygle> ahhh
<awygle> TIL about zeolites, incidentally
<whitequark> zeolites are super neat.
<whitequark> I use them to make absolute EtOH
Xark has quit [Ping timeout: 245 seconds]
pie__ has quit [Ping timeout: 264 seconds]
Xark has joined ##openfpga
diadatp has joined ##openfpga
<rqou> oh wheee, apparently the dorito in chief decided to have some "fun"
<rqou> i take a nap and this happens
<whitequark> azonenberg: awygle: should I route 1V2 over one of the signal layers, or over the inner 3V3 plane?
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 264 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
Lord_Nig- has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 265 seconds]
Lord_Nig- is now known as Lord_Nightmare
<awygle> whitequark: whatever is easiest. signal is marginally better probably.
<whitequark> alright
<awygle> just because you don't want to route stuff directly over a split in the 3v3 plane
<awygle> If it's on the adjacent signal layer
digshadow has quit [Ping timeout: 268 seconds]
eric_ has quit [Read error: Connection reset by peer]
digshadow has joined ##openfpga
<cr1901_modern> How many layers is this board ._.?
kmehall has joined ##openfpga
<awygle> 4
<awygle> cr1901_modern: i goofed up pretty bad by not reading the fine print.... or the normal size print as the case may be
<awygle> so i have a controleo kit... and no oven
<cr1901_modern> awygle: Yes you have to buy the oven separately
<cr1901_modern> they have a "reference oven" to buy that's $30
<awygle> yes but i got the convection oven kit (and i really want a convection oven)
<cr1901_modern> I've considered buying the one azonenberg uses tho (which implies the bigger kit)
<awygle> so i got one on amazon for like 45$
<cr1901_modern> I never seem to be in a position where I'm comfortable spending $300 on a hobbyist endeavor with a real risk of failure...
<cr1901_modern> (in a position financially*)
<awygle> yeah i hear you
<cr1901_modern> (not that the inside of a toaster oven is complicated. Just I have a knack for making things worse when I open them)
<cr1901_modern> s/them/anything/
<awygle> i'm a little skeptical myself but i'm kind of pot-committed lol
<awygle> anyway i'll keep you updated, oven arrives tomorrow
<cr1901_modern> I appreciate that :). And "should I route 1V2 over one of the signal layers". There's more than two signal layers?
<awygle> i think whitequark meant "as traces on a signal layer, or as a cut-out section of the power plane"
<awygle> rather than "on top of" an additional signal layer
<whitequark> yup
<whitequark> wtf
<whitequark> while I was laying out the board, one of the capacitors sold out at mouser
<awygle> ugh hate when that happens
<awygle> this cap shortage is for the birds
<awygle> oh actually i didn't fuck up the micrel symbol/footprint as badly as i thought i did. there are actual reasons for everything, i didn't just.... fail.
<awygle> that's reassuring
<openfpga-github> [Glasgow-JTAG] whitequark pushed 2 new commits to master: https://github.com/whitequark/Glasgow-JTAG/compare/40a8c91dd432...36ef79c0d97a
<openfpga-github> Glasgow-JTAG/master 36ef79c whitequark: Design and lay out most of the board, except for Vtg DAC/ADC/LDOs.
<openfpga-github> Glasgow-JTAG/master 15767bf whitequark: Update schematics and add preliminary layout.
<whitequark> okay that's enough glasgow for today
<whitequark> awygle: should I connect I2C to the FPGA or an RGB LED
<whitequark> the usefulness of either appears marginal
<whitequark> but, the RGB LED is more colorful
<awygle> whitequark: I2C seems more potentially-useful to me but i have a marked lack of enthusiasm for blinkenlights
<whitequark> hah
<awygle> so if RGB LED would bring you joy i say go for it
<awygle> oh my god is _that_ what they meant?? the "description" on the footprint appears to be labeled "Document Link"
<awygle> no wonder i was so fucking confused
<azonenberg> awygle: yeah i've dealt with that before
<azonenberg> (re cap shortage)
<awygle> bluhhhhhhhhhh footprints lol
<whitequark> azonenberg: it's me who's hitting it now :/
<whitequark> also
<whitequark> there are so many decoupling caps designed into this board that i blew right through BOM target
<azonenberg> You can probably back off a bit in the final version
<azonenberg> But footprints are cheap
<azonenberg> I put in more than i really need, then if i really want to cost optimize i can DNP some in the final version
<whitequark> that's an entire... $3.83 of capacitors
<azonenberg> ... oh
<whitequark> lol
<azonenberg> lol
<whitequark> i mean
<azonenberg> you... wouldn't like the bom on some of my designs :p
<whitequark> i could order a reel
<whitequark> and never think about caps again
<whitequark> azonenberg: well consider
<whitequark> that's 10% of BOM on capacitors
<azonenberg> whitequark: yeah, see i normally spend so much on silicon that $20 of passives is insignificant
<whitequark> well i specifically chose the cheapest possible silicon!
<azonenberg> Check out Digikey 587-3976-1-ND
<azonenberg> I used that on the vccint rail of a board a few years ago
<azonenberg> That one capacitor costs as much as your entire passive BOM
<azonenberg> Of course it was also vccint on an XC7K70T
<whitequark> jesus wept
rohitksingh has joined ##openfpga
<cr1901_modern> you... wouldn't like the bom on some of my designs <-- I want the money tree you're hiding azonenberg
<awygle> cr1901_modern: be a fancy security consultant :p
<azonenberg> cr1901_modern: i did that design back in grad school on a student's income
<azonenberg> it was my project budget for the semester
<azonenberg> :p
<awygle> actually azonenberg is kind of pushing me to want to specialize more
<whitequark> awygle: https://imgur.com/a/zYrfg
<whitequark> even more pretty now
<awygle> hard to command fancy salaries and WFM deals as a generalist
<awygle> ... WFH
<awygle> not waveforms per minute
<azonenberg> awygle: see, i'm more like a special-generalist or general-specialist? lol
<cr1901_modern> Waveforms Fer Minute
<awygle> whitequark: verrah naize!
<azonenberg> My niche is "low level hardware"
<azonenberg> and "the hardware-software interface"
<azonenberg> But i can, and have, done work in development of HW or SW, reversing, security testing, etc
<awygle> this is really coming together
<whitequark> yep
<awygle> go team go
<whitequark> awygle: should probably credit you on the pcb
<awygle> whitequark: do you think it would be rude to poke the PRs that haven't been commented on in several days?
<whitequark> awygle: probably ok
<awygle> mk
<awygle> whitequark: that would be nice of you, although it's not necessary
<awygle> would you mind if i posted it on my Gallery O' PCBs though? https://www.awygle.com/portfolio/
* awygle will learn to take good photographs... someday....
<whitequark> awygle: of course not! it's open hardware
<awygle> :D
<whitequark> i feel it might be insufficiently cool for that though
<awygle> nonsense
<awygle> scroll to the bottom :p
<whitequark> pfah
<whitequark> you should have seen *my* first pcb
<awygle> observe the wildly different trace sizes! the traces running wildly all over the board! the huge through-hole components!
<awygle> the very blurry photography!
<awygle> i wish i could put some boards i did at planetary on here...
<azonenberg> awygle: lol
<azonenberg> let me show you guys one of my first pcbs
<whitequark> how about: very bad toner transfer! shitty etch!
<awygle> but that seems like it would be not kosher
<whitequark> zero decoupling whatsoever!
<awygle> whitequark: "artisinally hand-crafted!"
<whitequark> impressively though that board still works
<whitequark> it's an atmega programmer based on an atmega
<awygle> i want to etch a pcb just for nerd cred
<whitequark> i eventually graduated to DIY PCBs with solder mask
<whitequark> although i never figured out double-sided PCBs well enough to make a "production" board
<awygle> my _second_ PCB was like 1000$ and did not even work a little bit
<awygle> but that's what you get for having interns designing ATE
<azonenberg> this wasn't #1 ever but it was the first one in my home lab (I did one or two in the e-club before that)
<whitequark> azonenberg: "REV 6"?
<whitequark> I'm kinda afraid to imagine how REV 1 looked like
<azonenberg> whitequark: yeah i went through a couple of revs... i don't know if many ever got fabbed
<awygle> that doesn't look so bad
<azonenberg> that was done in expresspcb
<azonenberg> :p
<whitequark> awygle: https://imgur.com/pPz0Ofv
<azonenberg> http://thanatos.virtual.antikernel.net/unlisted/S7308947.JPG this was done in the eclub a bit earlier
<awygle> azonenberg: do you know why USB 2.0 is so willing to be an aggressor signal if the routing is sub-optimal?
<azonenberg> check out those awesome decouplnig caps :p
<whitequark> yes that's plated vias
rohitksingh has quit [Quit: Leaving.]
<awygle> i have empirical evidence that's the case but no real theoretical explanation
<awygle> lol nice inductance azonenberg
<azonenberg> That was february 2010
<awygle> whitequark: damn! how'd you do the plating?
<azonenberg> let's say i've learned a bit since :p
<whitequark> awygle: found an obscure russian patent
<azonenberg> A year later, august 2011, my first FPGA design http://thanatos.virtual.antikernel.net/unlisted/S7301729.JPG
<azonenberg> (not home etched)
<awygle> the pcb at the bottom of my website dates to 2011
<whitequark> copper hypophosphite decomposes upon mild heating into copper and some junk
<whitequark> awygle: https://imgur.com/cMCXdvS
<whitequark> azonenberg: ^ too
<azonenberg> With a bodge wire, because expresspcb has no DRC/ERC :D
<awygle> whitequark: o_o so pretty! that's super cool
<whitequark> that was done with film photoresist, CNC mill to make holes, and photosensitive film solder mask
<whitequark> 1st try btw
diadatp has quit [Ping timeout: 264 seconds]
<whitequark> i've spent *weeks* tuning the process
<azonenberg> awygle: January 2012, first BGA FPGA (I did a BGA coolrunner beforehand and oshpark overetched heavily at the time, 0.5mm pitch did not go well) http://thanatos.virtual.antikernel.net/unlisted/S7302457.JPG
<azonenberg> Worked first try
<azonenberg> i was oshpark-ing already
<azonenberg> (except it wasn't called oshpark at the time)
<whitequark> azonenberg: those caps are massive
<whitequark> on the servo board
<azonenberg> whitequark: in which board?
<azonenberg> yes
<azonenberg> I wanted to not brown out the MCU when 32 motors all turned on at once
<azonenberg> :p
<azonenberg> my power traces could have been fatter but what did i know
<azonenberg> brown out the FPGA*
<azonenberg> Which had 32 PWM cores and an 8-bit softcore of my own design
<whitequark> there are power traces? :P
<azonenberg> exactly
<azonenberg> (i wrote the assembler while waiting for the board to get fabbed)
<azonenberg> awygle: then my boards grew rapidly in complexity, http://thanatos.virtual.antikernel.net/unlisted/S7302739.JPG
<azonenberg> this was may 2012
<azonenberg> CPLD to do some glue logic, spartan6 for the brain
<azonenberg> enc424j600 10/100 MAC+PHY chip for ethernet, ftdi uart, ddr1 sdram
<awygle> "rev 0.1" no, i refuse
<azonenberg> some nand flash i never ended up using
<azonenberg> awygle: that was around the time i started using 0.x version numbering for prototypes
<azonenberg> from then on, 1.0 is the first release i consider ready for general consumption
<azonenberg> i.e. by someone not getting handholding from me
<azonenberg> 0.1 is the first fabbed design
<whitequark> awygle: this reminds me
<whitequark> should we add polyfuses and testpoints
<azonenberg> whitequark: test points are never a bad thing
<azonenberg> and overcurrent protection of some sort
<awygle> testpoints are a good, and we have lots of room
<whitequark> i feel like testpoints are kinda pointless on this design because you can route out any signals you want on the external headers
<whitequark> and, importantly, that doesn't require soldering to the board
<azonenberg> my rule is to use polyfuses or active overcurrent protection for things that i expect may pull excessive current during normal, but incorrect, operation
<azonenberg> and smt soldered fuses for things that should never, barring a pcb malfunction/design bug, blow
<whitequark> azonenberg: "normal, but incorrect"
<awygle> whitequark: buy that huge bag of pogo pins, no soldering required :p
<azonenberg> So for example, power suppleid to an external device may short due to no fault of your own
<azonenberg> you dont want to blow a fuse if that happens
<azonenberg> But if your fpga vcore rail pulls too much power the S has HTF
<azonenberg> amd ot
<azonenberg> oops
<azonenberg> and it's perfectly ok to require rework to reuse the board
<azonenberg> because odds are something else is wrong too :p
<whitequark> hmm
<whitequark> so glasgow doesn't need a polyfuse, i think, since the current drawn by the target is limited by the Vtg LDOs
<azonenberg> Often i dont have protection on individual rails
<whitequark> at 100mA or so
<azonenberg> And i just have something on the input rail before regulators
<azonenberg> If you have active limiting, great
<azonenberg> Figure out how much current the whole board should draw worst case with all limiting active
<azonenberg> then put a single 0402 fuse on the input rail sized for decently more than that
<azonenberg> say 500 mA?
* whitequark whispers "0603"
<azonenberg> fiiine
<azonenberg> but my point is, i use soldered-in fuses for last ditch protection against "the board needs rework anyway" level malfunctions
<azonenberg> i.e. there should never be a way to make that fuse blow from external interfaces only
<azonenberg> internal component failure, solder short, etc should be the only things that can trip it
<whitequark> afaict even if I force contention on every possible bus the device has it still won't exceed 500mA input
<azonenberg> yeah
<azonenberg> So if you ever do hit 500 mA something is really wrong
<azonenberg> like a dead short from power to ground
<whitequark> i guess just guarding against solder shorts
<azonenberg> basically, that fuse is there to keep the board from going up in flames if all else fails
<whitequark> thats a polyfuse
<azonenberg> Polyfuses have higher Ron than actual one-time fuses
<whitequark> i think azonenberg means a regular fuse
<azonenberg> and slower response times
<awygle> uh i don't think it is?
<azonenberg> whitequark: btw you've seen my pcb design checklist right?
<azonenberg> Have you gone through it yet?
<azonenberg> awygle: you too
<awygle> i think that's just a regular fast-blow fuse
<azonenberg> on glasgow
<awygle> azonenberg: yes i've seen it, no i haven't run it (board's not done)
<awygle> although i suppose we could run the schematic bits
<azonenberg> My recommendation is to run through the sch portion before beginning layout
<whitequark> the schematic's not fully done either
<azonenberg> to minimize wasted effort if you find a mistake
<whitequark> i'm interleaving schematic and layout
<azonenberg> ah ok
<azonenberg> i normally do pretty clean waterfall to start
<whitequark> mostly because fpga pin assignment depends hugely on layout in this case
<awygle> it's interesting how some people really like to do that, and some people really don't
<azonenberg> oh, ok
<azonenberg> well
<azonenberg> So there's iterations involved
<azonenberg> Basically i start by doing bank-level pin planning in the schematic
<azonenberg> and a floorplan-level architecture of major subsystems on the pcb
<azonenberg> Then i finish the schematic, do the signoff review
<whitequark> awygle: $0.76, ew
<azonenberg> Lay it out, then as i do routing i swap fpga pins as needed
<awygle> i was surprised it was so much
<azonenberg> then do a second delta review of those changes prior to sending it out
<azonenberg> gimme a sec
<cr1901_modern> floorplan level? Well at least your checklist can accomodate interleaving
<azonenberg> yeah i see 0402 sized fuses at 500 mA down to 27 cents
<awygle> whitequark: lgtm!
<azonenberg> on digikey
<azonenberg> in qty 1
<whitequark> azonenberg: now, where do I put the fuse exactly
<azonenberg> cr1901_modern: basically, i just sketch out on paper where major connectors and chips will be
<azonenberg> then figure out what banks go where
<whitequark> between Vusb and 5V plane?
<whitequark> between 5V plane and Vreg?
<azonenberg> whitequark: i'd put it immediately after the power connector before it touches anything else
<azonenberg> Since your goal is to protect against the greatest possible number of faults
<azonenberg> Safety systems should be designed to be as simple and broad as possible
<azonenberg> an actual melting-wire fuse is about as simple as it gets, and putting it as far upstream as possible maximizes coverage
<cr1901_modern> azonenberg: Why on paper? Why not (assuming the footprints exist) fire up pcbnew and just draw the basic layout without connections there?
<azonenberg> cr1901_modern: Because more often than not, the footprints don't exist yet :p
<azonenberg> And i dont even start making them until the sch has hit first-pass completion
<azonenberg> There's often some iteration
<azonenberg> but i dont start layout until my first attempt of the schematic has passed review because there's often major changes during that phase
<cr1901_modern> Seems like tedious (nevermind duplicated) work to draw to-scale layout on paper
<azonenberg> once i start layout changes are usually small, like adding a test point or indicator LED or swapping fpga pins
<awygle> yeah that's a good plan, you often realize pretty late in the game you really need the two-output DAC
<azonenberg> lol you're reading way too much into it
<cr1901_modern> Not judging you/saying you're wrong :P
<azonenberg> i dont do a scale drawing
<azonenberg> this is more like a toddler's sketch
<azonenberg> "ethernet over there"
<azonenberg> "power in there"
<azonenberg> "fpga somewhere in the middle"
<awygle> a sketch preserving relative orientations is sufficient for bank-level planning, typically
<azonenberg> Yeah
<cr1901_modern> ahhh okay.
<azonenberg> Ok, transcievers have to go to the SFP connector
<azonenberg> so that means pin 1 is to the top left
<awygle> sometimes, if you're being clever, you might want to sketch actual circuits
<azonenberg> then bank 30 goes to blah
<azonenberg> etc
<awygle> just to make sure you're not being an idiot (often more useful with analog, you can do the math on your drawing)
<azonenberg> awygle: that happens during schematic capture
<azonenberg> i often include calculaitons in descriptive text in the sch
<azonenberg> But basically at this level of the floorplan design process i want to know what the major components are, what voltage they run at
<cr1901_modern> awygle: Well I have a failed (currently anyway) project to do an ice40 board, and I discovered that my layout was insufficient while doing the schematic; I decided I needed a new part that wasn't there before.
<azonenberg> how many pins they need
<awygle> azonenberg: i do too, but i often start with a napkin to figure out if i'm clever or "clever"
<azonenberg> And if there's any special requirements like transceivers or "must be on front panel because it talks to the outside world"
<azonenberg> etc
<awygle> azonenberg: also you barely do analog :p
<cr1901_modern> That kinda put a dent in the original layout and actually kinda ballooned the board size b/c now I needed all 4 sides of the FPGA lol
<azonenberg> :p
<azonenberg> anyway, thats about all of the pcb that i do until sch has hit the signoff review milestone
<azonenberg> Once the sch has passed review, then i make all of the footprints, do a more detailed rough placement in pcbnew that's actually to scale
<azonenberg> just major ICs plus estimated space around each for passives and routing
<azonenberg> Then i start routing
<azonenberg> Typically at this point i have the pcb open on my main monitor and the sch on the side so i can easily go between them and swap pins etc
<awygle> i usually do block diagram, major component selection, detailed block diagram, schematic, layout with some trips back to the schematic, then send the layout to the best PCB layout guy i know (kbaker) to get a second opinion
<azonenberg> awygle: btw does kevin irc at all?
<awygle> azonenberg: not afaik
<azonenberg> he's missing out lol
<awygle> lol yup
<azonenberg> oh also... When making new footprints/symbols, I first create the design
<azonenberg> then before i even close the editor, i go back and double check every dimension or pin name/number against the datasheet
<azonenberg> then during the review, unless it's a part i've used on a board previously, i go back and do it again
<azonenberg> This has saved my butt sooo many times its not even funny
<awygle> i wish EDA tools didn't conflate "symbol" and "component". altium gets this right with their "component libraries" but almost no one else does (including altium's lower level products).
<azonenberg> awygle: at least kicad doesnt attach footprints to sch symbols
<azonenberg> like eagle
<awygle> yeah i always go check footprints on ICs again before fab. typically layout takes long enough that my cache has been flushed and i can actually _see_ the footprints/symbols again.
<azonenberg> for me, connectors dominate screwups
<azonenberg> either pin numbering or pitch or something
<awygle> connectors are ICs, change my mind :p
<azonenberg> IC packages tend to be pretty regular
<azonenberg> esp bgas
<azonenberg> basically the only thing you can do wrong with a normal bga is have wrong pad size, wrong pin pitch, or REALLY screw up the numbering
<awygle> yeah you're right, connectors are worse. but at least it's hard to screw up "edge mount SMA" and "100-mil header" which are what i mostly use
<azonenberg> And kicad's new pin numbering tool largely eliminates that
<azonenberg> tell that to my self from 5 years ago
<azonenberg> i made the mistake of using kicad's library footprint for 0.1" headers
<azonenberg> The drill pitch was too small for my header
<azonenberg> drill diametr*
<awygle> i once specifically picked a through-hole USB so that if i got the footprint wrong i could just put it on the other side of the board lol
<cr1901_modern> YUP! Been there
<azonenberg> so my pins didn't fit
<awygle> yeah me too lol. everybody does that once.
<awygle> 60/40 for lyfe
<azonenberg> awygle: i've also been using sac305 since i got my own hardware lab in 2010
<azonenberg> So i'm used to it :p
<awygle> azonenberg: i meant 60 mil pad 40 mil hole for the 100-mil headers :p 63/37 is the superior leaded solder
<azonenberg> ... oh
<azonenberg> lol
<azonenberg> when i hear 60/40 i think non-eutectic solder
<awygle> i still don't like SAC305 btw. i'll get used to it eventually i suppose
<azonenberg> i keep a bit of 63/37 around for reworking non-RoHS boards
<azonenberg> But honestly? i almost never use it
<azonenberg> i understand how SAC acts now
<azonenberg> and snpb confuses me :p
<awygle> i want to do a comparative x-ray imaging study of SAC305, 60/40 and 63/37
<awygle> just cuz it'd be cool
<awygle> okay, time for fetch and then bed
<awygle> goodnight moon
<azonenberg> the one difference i do notice is that, while slightly more viscous, sac has higher surface tension
<azonenberg> and holds parts to the board better in 2-sided reflow
<openfpga-github> [Glasgow-JTAG] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow-JTAG/commit/ea0c2b0310d44699ba30df05c60b68e391b3c9f1
<openfpga-github> Glasgow-JTAG/master ea0c2b0 whitequark: Add 500mA fuse on VUSB.
indy has quit [Read error: Connection reset by peer]
indy has joined ##openfpga
diadatp has joined ##openfpga
RaivisR_ has joined ##openfpga
RaivisR has quit [Read error: Connection reset by peer]
RaivisR_ has quit [Quit: Leaving]
<cr1901_modern> https://twitter.com/whitequark/status/985043329929723906 What primitives does an ice40 have to allow sampling out of phase w/ clk?
<whitequark> cr1901_modern: none, none required
<whitequark> oversample and discard
<whitequark> use a PLL and/or DDR for best results
<awygle> cr1901_modern: alternately I believe you could use the PLL output fine delay adjust for this as well
<whitequark> yes but only for one clock pin
<whitequark> oversampling lets you have as many as you want *and* no setup latency
<awygle> True, wouldn't work for both banks simultaneously I suppose
<cr1901_modern> setup latency?
<cr1901_modern> I don't think I understand the tweet then. You're 4x multiplying the clk and then "averaging" together to get a 50MHz sampled signal?
<awygle> But you could crossbar an input pin to the PLL input, if I remember the clock rules for ice40 right. You'd have more jitter though.
<whitequark> what I mean is
<whitequark> you need to set the fine delay
<whitequark> and for that you need to observe several transitions
<whitequark> and you lose data for those
<cr1901_modern> oh
<azonenberg> whitequark: yeah i plan to do exactly that on kintex7 for SGMII
<azonenberg> in my ethernet switch project
<cr1901_modern> https://twitter.com/cr1901/status/928995037249261568 I got less than stellar results last time I tried something like this
<whitequark> azonenberg: how much starshipraider costs again?
<awygle> whitequark: you could always set fine delay from the host to avoid that
<azonenberg> whitequark: The full version, or the scaled down prototype?
<cr1901_modern> (assuming I understand correctly)
<azonenberg> and for the host board or with i/o cards?
<awygle> you don't have to do full delay calibration/tuning. But the two banks thing is a deal breaker.
<whitequark> full version host board plus a few i/o cards
<azonenberg> whitequark: well it doesnt exist yet so i can only give estimates
<whitequark> maybe one or two
<whitequark> sure
<azonenberg> and the minimum load is four digital i/o cards
<azonenberg> if you want to make it fully usable
<azonenberg> i mean you can always only load half and have only 16 channels instead of 32
<whitequark> let's go with four
<azonenberg> So, the base board for the single-io-card scaled down prototype was $213.95 BOM plus $40 for the PCB (oshpark qty 3 price, $117 per 3 bare boards)
<azonenberg> That includes an xc7a100t as the FPGA, until i finish firmware i won't know if that's overkill or not
<azonenberg> (The FPGA is over half the bom cost there)
<azonenberg> The full version will tentatively have a kintex7 since i wanted to do 10GbE
<azonenberg> Assuming the 7k70t that's going to be the same ballpark price as the artix, maybe a bit more so say $250 so far, then i think the DDR3 is about the same price as the hyperram but a lot bigger capacity
<azonenberg> Probably no more than $300 BOM for the host but the PCB will be ~6 layers and cost a lot more in low volume
<azonenberg> maybe $350 worst case since q-strip's are not cheap
<azonenberg> As far as i/o cards, let' see
<whitequark> $350 per PCB?
<azonenberg> no, $350 BOM in qty 1
<whitequark> ah
<azonenberg> Plus PCB
<azonenberg> Dimensions unknown, the big bga drives the stackup to 6-8 layers with a goal of 6
<azonenberg> The io cards will be targeting oshpark 4 layer process
<azonenberg> So, the 8-bit digital io card will have four 2-channel high speed comparators, estimating about $10 a pop so $40 so far
<cr1901_modern> whitequark/awygle: I'm not seeing how you can get away sampling a 50MHz signal at 50Mbps (or 200Mbps with "oversample and discard") at get a usable real-time signal dump in return.
<azonenberg> Two level shifters per lane for 1.2-3.3 and 3.3-5V ranges, assuming i buy in digikey qty 100 is about 40 cents each is another $6.40
<whitequark> Msps*
<whitequark> cr1901_modern: well consider it like this
<cr1901_modern> yes, sorry
<whitequark> if the SPI master is driving the bus at 50 MHz
<whitequark> the slave is sampling it at 50 MHz
<whitequark> so I can do that too and get all the data
diadatp has quit [Ping timeout: 260 seconds]
<azonenberg> whitequark: then a variable LDO for VCCO, a DAC for Vt, an ADC for optionally tracking an external Vref
<azonenberg> some mosfets and passives
<azonenberg> and the PCB
<whitequark> but I'll need to do it at two clock edges simultaneously
<azonenberg> You should be looking at less than $100 per io card
<whitequark> so ~$1k total?
<azonenberg> Under 1K for an assembled system with four io cards is my goal
<azonenberg> But the specs have changed over time, for the better
<azonenberg> my new io card design is slightly cheaper, smaller pcb area, and better bandwidth than the old one (in theory)
<azonenberg> but has yet to be hardware proven
<azonenberg> I still have a lot of work to do, like for example designing a mechanical standard for io cards so i can attach them to the host board without them colliding with the adjacent one
<azonenberg> i've defined the connector and pinout but have to think about how big i want to let them be
<cr1901_modern> Okay, starting to make sense
<cr1901_modern> But SPI samples during one clock edge for both components and shifts during the other.
<cr1901_modern> >but I'll need to do it at two clock edges simultaneously
<cr1901_modern> for both master/slave*
<whitequark> if you're trying to output data as for an LA you need to return two samples for each actual sample
<cr1901_modern> So you don't _need_ both edges, just the one which is being used to sample?
<whitequark> is what I mean
<cr1901_modern> And you're doing it at 4x's
<cr1901_modern> (for extra insurance I imagine)
<whitequark> no, just to make sure I have setup/hold margin
<azonenberg> whitequark: Then the FPGA i'm using will have probably four GTXes
<azonenberg> I'll be using one for 10GbE
<azonenberg> (in addition to a RGMII or SGMII PHY for 1000baseT)
<whitequark> since I cannot actually like, have that many clock domains
<whitequark> well I mean I can but it seems like a recipe for pain
<azonenberg> The other three will tentatively be brought out to an expansion header
<azonenberg> But i have yet to define the pinout, functionality, etc
<azonenberg> The other option is to bring out all four GTXes to a QSFP+
<azonenberg> And give you 40GbE to the host system, or four lanes of 10GbE to different hosts, or one lane to the host and three to other instrumentation, etc
<azonenberg> Yet another option is to put all four GTXes on an expansion header and require use of an addon card if you wanted 10GbE
bitd has joined ##openfpga
<azonenberg> whitequark: oh, the other thing is that starshipraider's modular io design, while it increases the cost a bit
<azonenberg> also lets you swap things out for other than single ended digital GPIO
<azonenberg> you can do LVDS, or CAN, or ADC/DAC
<azonenberg> etc
<azonenberg> CAN in particular is one i expect to use at work moderately often
<cr1901_modern> whitequark: So by sampling at 200MHz you essentially sample on the edges of your logic analyzer clock when the 50MHz clock is _not_ transitioning (either posedge/negedge)?
<awygle> whitequark: sync pin is a great idea
<whitequark> awygle: yep gonna add that
<whitequark> still unsure about routing i2c to fpga
<whitequark> it might be useful for e.g. FT232 compatibility mode?
<whitequark> switching between MPSSE and UART mode
<whitequark> good thing that I only have open-drain pins left and all I have is also open-drain tasks
<awygle> I have no idea what I'd use it for honestly
<awygle> I just like connecting things to things
<whitequark> lol
<awygle> arright actual sleep now
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 264 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
diadatp has joined ##openfpga
genii has quit [Remote host closed the connection]
diadatp has quit [Ping timeout: 240 seconds]
diadatp has joined ##openfpga
diadatp has quit [Ping timeout: 260 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
<openfpga-github> [Glasgow-JTAG] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow-JTAG/commit/cbce8061dfab46f2c65d876898fc3cb274e6b25e
<openfpga-github> Glasgow-JTAG/master cbce806 whitequark: Add SYNC port.
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
X-Scale has quit [Ping timeout: 264 seconds]
gruetzko- is now known as gruetzkopf
DrLuke has quit [Remote host closed the connection]
DrLuke has joined ##openfpga
diadatp has joined ##openfpga
Zorix has quit [Ping timeout: 276 seconds]
diadatp has quit [Ping timeout: 240 seconds]
diadatp has joined ##openfpga
Zorix has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
GenTooMan has joined ##openfpga
diadatp has quit [Ping timeout: 256 seconds]
pie__ has joined ##openfpga
rohitksingh has joined ##openfpga
X-Scale has joined ##openfpga
Bike has quit [Quit: Lost terminal]
diadatp has joined ##openfpga
eduardo has joined ##openfpga
<whitequark> rqou: why the f does broadcom make outdoor sign LEDs
<marcan> whitequark: btw, Glasgow is pretty much a scaled down version of something I've been designing in my head
<marcan> that is to say, I'm interested, and may wind up stealing some ideas :)
<whitequark> marcan: so do you want a board or
<daveshah> AFAIK Avago bought Broadcom, but rebranded everything including their opto stuff to Broadcom
<marcan> I do :)
<whitequark> one?
<marcan> yeah, I think one should be fine assuming I don't destroy it somehow
<whitequark> it's supposed to be hard to destroy
<marcan> yeah, I like that
<marcan> 16 pins is barely enough to PoC some of the things I want to try, but I've had tons of uses for something with low pin count over the years (e.g. all the twlfpga abuse)
<marcan> I'm interested in how well those level shifters work, and I can find out with one
<whitequark> marcan: you could get two and sync them!
<marcan> I could, though that would be... somewhat inconvenient :P
<marcan> for anything active anyway
<marcan> passive sniffing, sure
<whitequark> I do wonder how much can I paper it over in software
<whitequark> it's one of those things that is harder than it seems
<marcan> the problem is triggering. if you can get the clocks synced then plain old sniffing is not a problem
<marcan> but anything smarter complicates things
<whitequark> the SYNC pin is supposed to be a bidirectional trigger pin
<whitequark> the first device that triggers, also triggers all the others
<marcan> yeah, the issue is if you need conditions that span across multiple units :)
<whitequark> yes, that is a pain
<marcan> you know the twlfpga, right? https://marcan.st/transf/twlfpga.jpg
<marcan> same basic idea with a lot more I/O (sometimes broken out with extraneous use cases that we never used; should've just been numbered pin headers)
<marcan> and no level shifters
<marcan> (but it does have configurable bank voltage)
<marcan> oh, do you have any LEDs? because you want LEDs :P
<whitequark> not currently
<whitequark> I was actually looking at LEDs right now
<whitequark> the FPGA doesn't have any free pins for LEDs, the Cypress chip has some
<marcan> hm, pushing the FPGA quite a bit, eh
<marcan> that's kind of unfortunate
<marcan> how are you doing FPGA configuration?
<whitequark> the Cypress chip configures it via slave SPI
<whitequark> it then reuses those pins for communication
<marcan> one of the neat things about the twlfpga is we could use the FTDI in bitbang mode to blast the config via an 8-bit parallel bus, took less than a second (no configuration memory, it was always loaded via usb)
<whitequark> it takes 0.8s currently
<marcan> sounds good
<whitequark> there is configuration memory in case you want it to emulate something on powerup
<whitequark> like a bus blaster
<marcan> ah, that's what U2 and U3 are
<whitequark> U2 also stores USB VID/PID and board revision/serial
<whitequark> U3 can be DNP on a hypothetical low-cost model
<marcan> so U2 is a config EEPROM and U3 is more like flash?
<whitequark> they're both I2C EEPROMs and they hold code and bitstream respectively
<marcan> gotcha
<whitequark> but U2 also holds some configuration data
<marcan> sounds like it'll be useful for a lot of stuff
<whitequark> that's the idea :p
<whitequark> marcan: yeah this is like only a little bit higher end than what i'm building
<whitequark> i wonder if we could even reuse software?
<marcan> quite possibly
<marcan> what are you planning for the firmware/HDL/host software?
<whitequark> HDL: migen, ship the entire Yosys toolchain to be able to build bitstreams on the fly
<whitequark> lil bit heavy but for a very versatile debug tool? I'll take it
<whitequark> firmware: boring old cypress stuff written in sdcc
<whitequark> compiled with*
<whitequark> its only responsibility after initial bringup is basically to poke all the shit on the I2C bus
<marcan> migen was my plan too
<whitequark> so, FPGA (not enough pins... there is only one GPIO and it is multiplexed with a FIFO flag)
<whitequark> FPGA sits on I2C too and exposes user-writable registers for slow out-of-band configuration in case you don't want to stuff it all in-band into USB bulk pipes
<whitequark> then, ADCs and DACs
<marcan> ah, that's different from what we did for OV3 (which is what I was going to base the USB bit on)
<marcan> that one has a framing protocol for config/data over the single pipe
<whitequark> sure, you *can* do that
<whitequark> doesn't mean you *have* to
<marcan> of course
<marcan> having out of band I2C sounds like a handy option
<whitequark> for example, if I'm emulating FTDI, I need to communicate selection of alternate interface modes to the FPGA
<marcan> ah, yeah, if you're emulating higher level stuff you kind of want that
<whitequark> the FPGA even has an I2C hard IP... which is totally useless because it's written to be put on wishbone
<marcan> the framing is easy when the host side deals with it all
<whitequark> probably will be less slices to implement I2C than to interact with that thing
<whitequark> so, DACs are just stupid DACs that drive an LDO
<daveshah> whitequark: yep definitely from my experience
<daveshah> also easier to write an i2c core than get the Lattice one working for a given application
<daveshah> even moreso for spi
<whitequark> lol
<whitequark> why even *have* an spi core
<whitequark> it's spi goddamnit
<whitequark> what a waste of silicon
<whitequark> ADCs have alert capability and are routed to an interrupt-capable pin on the Cypress chip
<daveshah> it's not even that fast, 45MHz max
<daveshah> I think a SPI core in fabric could go a bit faster than that...
<marcan> what does an SPI core even *do*
<marcan> I mean if you have a CPU, sure, you can implement the register side interface
<marcan> but in an FPGA? what?
<daveshah> it's obviously intended for a cpu
<daveshah> there's no other way you could use it - the state machine to control it would be bigger than the i2c/spi state machine
<marcan> exactly
<whitequark> so, as soon as ADCs go into alert, the Cypress chip kills the IO buffer OE and tristates the LDO
<whitequark> actually, I think I can even hardwire ADC alert to LDO disable
<marcan> ADCs for the current sense?
<whitequark> nope
<whitequark> Vtarget sense
<marcan> ah
<marcan> yeah, that makes sense
<whitequark> the current is limited by design by the LDO
<marcan> though you always want to have an override for this stuff, because sometimes you *do* want to shoot yourself in the foot
<whitequark> the alert functionality is controllable in software
<marcan> cool
<whitequark> the ADC can continuously sample by itself
<whitequark> so I don't really care about having the FPGA do it
<whitequark> which is convenient
<marcan> yeah, anything that makes the FPGA design simpler is a good idea
<marcan> less crap to worry about
<marcan> my udeaplan is to have a scaffolding
<marcan> EEARLYRETURN
<marcan> my idea was to have a scaffolding to make it trivial to write little blocks of functionality for a given project
<whitequark> yep same here
<whitequark> you'd have a template for having one bidirectional USB pipe and doing whatever you want with all 16 pins
<whitequark> or, having two bidirectional pipes, and being able to set one such module to serve the A port and another for B port
<marcan> yeah, or several framed together with a register interface and such for more complex projects
<whitequark> yep
<whitequark> similarly, the idea is to have something like CSR system in migen that automatically exposes registers via I2C
<whitequark> then on the host side, it would use the same numbering to let you issue control requests using register names
<marcan> yeah
<openfpga-github> [Glasgow-JTAG] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow-JTAG/commit/922e5766ea6327738fb00d0fd305e03fae9464e0
<openfpga-github> Glasgow-JTAG/master 922e576 whitequark: Voltage translator has a ~OE pin, not OE, oops.
<awygle> Morning!
<marcan> since you're further ahead than I am how does this sound. I'm going to mess with some preliminary stuff and use my OV3 as a PoC platform for the SDRAM side of things, since that really needs testing for viability before I commit to a design
<whitequark> awygle: hi
<marcan> and probably by the time I know what I want to do you'll have hardware and I can base it off of that :)
<whitequark> sure that seems fin
<whitequark> *fine
<whitequark> SDRAM in my case is an explicit non-goal, it would hugely increase complexity of the design
<marcan> oh I agree
<marcan> it makes no sense on something that small
<marcan> and with trivial compression and the RAM inside the ice40 you should be able to do realtime streaming of all but the most pathological inputs
<whitequark> it's almost not necessary
<whitequark> i can do realtime streaming of 7 channels period
<marcan> at 50MHz?
<whitequark> yes
<marcan> that sounds just about what I got on the FTDI
<whitequark> it's basically limited by USB at this point
<marcan> 42MB/s was the highest I've gotten out of it IIRC, with an xHCI host controller (which is slightly more efficient than EHCI)
<whitequark> the Cypress<>FPGA interface is 384 Mbps
<whitequark> but Cypress could only get around 360 Mbps out of it
<whitequark> or at least they say so in their appnote
<marcan> yeah, that's the ballpark
<marcan> of the FTDI
<whitequark> and I'm probably not going to beat Cypress using their own chip lol
<marcan> the FTDI actually has a 480mbps interface but that's overkill obviously
<whitequark> the Cypress also has one.
<whitequark> well, a 768 Mbps one, actually
<whitequark> 16-bit bus
<marcan> ah
<whitequark> but the FPGA doesn't have enough pins.
<marcan> nah, FTDI just runs the 8-bit bus at 60MHz
<whitequark> but it doesn't really make any sense because of USB protocol overhead.
<balrog> btw any of you seen this? https://www.domesday86.com/?page_id=978
<whitequark> you can't even run isochronous transfers at over 192 Mbps
<marcan> IIRC someone said the fastest you could make USB run was to fill it up with isoc transfers over multiple endpoints
<whitequark> sort of
<whitequark> in practice this fails miserably because hosts hate isochronous endpoints
<whitequark> and also you lose data
<marcan> yeah, of course
<marcan> isoc is always a PITA
<marcan> re: that tweet, I was really proud when I got webcams to work properly on my virtual USB thing
<marcan> which at the time didn't work properly in vmware or vbox
<marcan> but it was a hack (totally bypassed the qemu USB code, went straight from virtual device to libusb)
<marcan> worked great but not upstreamable as-is... unfortunately adding all the layers in the middle breaks a lot of things
<whitequark> awygle: ah crap
<whitequark> we need... another voltage level translator
<awygle> whitequark: ruh roh
<awygle> why?
<balrog> marcan: that IceFace thing seems to be one part of a universal chip programmer
<balrog> the other would be a universal pin driver
<balrog> which is... $$$
<marcan> balrog: it could be used as such, yes, with such a daughterboard
<whitequark> awygle: the I2C bus of ADCs gotta be at 5V
<whitequark> awygle: because the datasheet says pullups should go to reference voltage
<whitequark> hm
<balrog> kevtris was working on something built around the allpro pin drivers (which he RE'd)
<whitequark> alternatively
<whitequark> we can divide the input voltage
<awygle> whitequark: divider yes
<marcan> I'll check it out
<whitequark> yes that's better
<marcan> gotta go get some sleep, early wake up tomorrow :P
<awygle> careful on filters if it's a SAR ADC, cap needs to be fairly large
<whitequark> 470pF
<awygle> that seems too low to handle the increased input impedance of the divider but maybe not
<awygle> I guess it's very slow... gotta check the ds
<whitequark> up to 188ksps
<whitequark> . The ADC081C021 will deliver best performance when
<whitequark> driven by a low-impedance source (less than 100Ω).
<whitequark> hmmm
<whitequark> awygle: i need to sleep
<whitequark> can you think a bit about the analog stage?
* whitequark -> zzz
<awygle> yup
ZipCPU has quit [Ping timeout: 264 seconds]
ZipCPU has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
noobineer has quit [Remote host closed the connection]
noobineer has joined ##openfpga
rohitksingh has quit [Ping timeout: 276 seconds]
rohitksingh has joined ##openfpga
diadatp has quit [Read error: Connection reset by peer]
diadatp has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
diadatp has quit [Ping timeout: 240 seconds]
diadatp has joined ##openfpga
<awygle> azonenberg: if you have a second to glance at the above your input is always valued
<rqou> er, why the heck is there an adc?
<awygle> rqou: to sample target voltage and match it on the level shifters
<rqou> wut?
<rqou> don't you just feed Vtg into the level shifter directly?
<awygle> no, because then we load Vtg
<rqou> and?
<rqou> usually that's fine?
<awygle> the adc also allows us to shut down if Vtg goes crazy
<rqou> hmm
<rqou> i personally don't see the point, but ok
<awygle> admittedly the adc was more valuable when we were planning on not using level shifters
<rqou> btw, does anyone here know how to find the setup/hold/clk2out/routing-delay numbers for ice40?
<rqou> are these published?
<rqou> daveshah?
<rqou> (trying to back-of-the-envelope see if i can push performance figures even higher than glasgow, which I think I can)
<daveshah> you can also get an html report from the Makefile
<awygle> rqou: i think everything you just mentioned except maybe the routing delay is in the family handbook
<rqou> daveshah: and what units are these? ps?
<daveshah> rqou: yep
<rqou> awygle: not that i could find
<rqou> wat so in3 is faster?
<rqou> (on hx8k)
<rqou> SETUP posedge:in0 posedge:clk 377.695:417.653:469.902
<rqou> SETUP posedge:in3 posedge:clk 219.852:243.112:273.525
<rqou> daveshah: so the timing model is the simple "add all the delays and see if setup/hold is violated" method?
<rqou> e.g. not based on loading?
<daveshah> yes, that's how it works afaik
<rqou> and can icetime handle clocks that don't go through the global network?
<rqou> (presumably not)
<daveshah> no, I don't think so
<daveshah> it is very basic
<daveshah> no multiclock or hold analysis
<daveshah> actually i don't think it cares where the clock comes from, it just assumes all are the same iiirc
<rqou> also, what about additional delay due to VCCIO?
<rqou> the "iCE40 Family Timing Adders" numbers?
<daveshah> not modelled in icetime, i don't think it does io analysis
<rqou> ok
<rqou> (yes, this design if it works is probably pushing an ice40 actually to/past its limits)
<awygle> rqou: what's your design?
<rqou> i'm still trying to see if i can squeeze rgmii into/out of an ice40hx
<rqou> and i'm pretty sure i can
<rqou> but i have to actually try writing out the proposed frontend and manually run timing analysis on it
<rqou> daveshah: in icestorm, can i fix FFs to a specific logic block inside a tile? or only to a specific tile?
<awygle> ah
<awygle> i would be more likely to look at ULPI+daisho in an attempt to lower cost, personally
<rqou> and yes, i do know about PTV variations :P
<awygle> but gigabit to push more samples would be cool too
<daveshah> rqou: I don't think you can do either
<rqou> what
<daveshah> I think arachne-pnr only supports placement constraints on IO
<rqou> no LOC attribute?
<daveshah> No
<rqou> wtf
<daveshah> The only option is an entire placed blif
<rqou> hmm
<daveshah> But then you would have to update that at every design change
<rqou> can I have just a portion of the design be a manually placed blif?
<daveshah> No, unfortunately I don't think so
<daveshah> Someone worked on it, but it never got merged
<rqou> so how does the "entire placed blif" feature work?
<awygle> you just give arachne --route-only
<rqou> hrm
<rqou> this is bullshit
<daveshah> and give a LOC attribute in the (e)blif like `.attr loc "4,30/4"` for (4, 30, 4)
<awygle> hrm, adding loc attributes doesn't actually seem that hard...
<awygle> iirc yosys will already persist attributes into the blif correctly
<daveshah> Yeah, the problem at the moment is the need to place all or nothing manually
<awygle> there's only a couple of places you'd actually have to change in arachne
<awygle> basically place initial and then put a guard on the swap function to nop it if there's a LOC attribute on one of the cells
<awygle> (and persist attributes to cells which might not currently happen)
<awygle> oh hey, clifford said exactly this on that issue :p well nvm me then
bitd has quit [Quit: Leaving]
RaivisR has joined ##openfpga
diadatp has quit [Read error: Connection reset by peer]
diadatp has joined ##openfpga
diadatp has quit [Read error: Connection reset by peer]
diadatp has joined ##openfpga
noobineer has quit [Ping timeout: 276 seconds]
noobineer has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga