<mithro> So - anyone want to help me :-P
f003brv has joined ##openfpga
<f003brv> Oh hi
<kc8apf> hello
<f003brv> How do you do? New to the channel, but looks cool
<kc8apf> if you're interested in FPGAs, yup, it's the place to be
<f003brv> Cool thanks I am. I have a Spartan 6 at the moment
<kc8apf> what do you want to do with it?
<f003brv> I have worked on firmware for ARM chips, but I am new to the world of FPGA's
<f003brv> I am currently trying to collect image data from an Arducam
<f003brv> and running an algorithm I had for ARM on an FPGA instaed
<f003brv> instead*
<kc8apf> so what about that brings you here?
<f003brv> that's the current project, but aside from that just learning more about FPGA's and Analog circuits. I was actually referred to the channel
<f003brv> form ##electronics
<kc8apf> ah
<f003brv> by pointfree, I have an FPAA too
<kc8apf> most of us are working on understanding the internals so we can write our own tools for them
<f003brv> yeah I heard
<f003brv> for both FPGA and FPAA?
<kc8apf> I haven't heard anything about FPAAs
<pointfree> f003brv: welcome!
<pointfree> f003brv: qu1j0t3 is also interested in FPAA's
<f003brv> Oh okay, it's this chip by Anadigm. There aren't many
<f003brv> Hi pointfree
* qu1j0t3 thankss pointfree this is true
<qu1j0t3> f003brv: I do have an Anadigm 5V kit but haven't played with it yet
<f003brv> there are a healthy amount of people in this channel :)
<f003brv> I am the same way
<pointfree> there's also a lattice fpaa
<f003brv> I've just looked at it briefly. I got it on sale when they were about to bring out the 3.3v
<f003brv> hmm interesting
<f003brv> Which one is that?
<f003brv> Apparently Dialog has one too, but it seems small
<qu1j0t3> f003brv: Same
<pointfree> f003brv: ispPAC-10 and ispPAC-20
<f003brv> I'll take a look thanks. I am also looking for a good document on Configurable Analog Blocks.
<ZombieChicken> How many FPGAs are understood well enough to make a toolchain for? I'm only aware of some of Lattice's offerings
<f003brv> I see some on Google behind IEEE doors
<q3k> ZombieChicken: ICE40 is the poster child of FPGA RE, Xilinx 7-series is in progress (project xray), so is the ECP5 series (project trellis)
<ZombieChicken> How far along is project xray?
<q3k> ask mithro, I guess :P
<q3k> or kc8apf
<ZombieChicken> I may
<kc8apf> ZombieChicken: CLBs and interconnect are understood. BRAM is partially worked out. IOB, CMT, DSP, etc are not.
<ZombieChicken> ty
<ZombieChicken> I don't know FPGAs well enough to know how much of the system that is
<ZombieChicken> I'm quite new to this
<kc8apf> CLBs are the main logic elements
<kc8apf> so the core fabric can be programmed
<kc8apf> IOB is the I/O buffers
<kc8apf> CMT is clock management (PLLs, MMCMs)
<pointfree> ZombieChicken: there's the greenpak's which now seem to have pretty good open source tooling (by azonenberg, rqou, et al). They're small but they also have analog features.
<kc8apf> so we don't know how to route pins into the fabric or startup clocks
<pointfree> All of the fpaa's currently available are voltage-mode switched-capacitor fpaa's. I'm interested in current mode switched-current fpaa's. They don't need the voltage headroom of switched-capacitor designs and and they can be manufactured with a digital process. You only need FET's.
<ZombieChicken> Greenpaks?
<pointfree> cyrozap originally brought SI signal processing to my attention when he was talking about analog memory cells http://www.onmyphd.com/?p=si.analog.memory
<mithro> ZombieChicken: If your question is just "I want to get into FPGAs and don't know where to start" - then the answer is "you should use the open source tools with an ice40 compatible FPGA"
<ZombieChicken> mithro: Oh, I have plenty to dive into before I start with that. I just like knowing where everything roughly is and sating my curiosity as things go along.
<ZombieChicken> if I was going to get into FPGAs, I think I'd likely just look at a simulator before anything else
<q3k> ZombieChicken: also, can't stress this enough, simulate your designs earl...
<q3k> this.
<q3k> I like Verilator a lot, especially for cosimulation. Other people have different opinions though :P
* awygle really needs to write that blog post collecting all the projects...
<q3k> also try yosys and formal verification of your designs
<ZombieChicken> Yeah
<ZombieChicken> Don't recall the name of it, but there is something that lets you write a spec for software and it auto(matically|magically) generates code. Seems like something that might be useful here as well
<q3k> well, closest thing to that magic that I know is that yosys-smtbmc can automatically generate testbenches/signals to reach a certain state in your design (via formal proof failures or the cover statement)
<f003brv> thanks pointfree, I'll read that
f003brv has quit [Ping timeout: 260 seconds]
<rqou> ZombieChicken (and others): Coolrunner-II also has a complete-ish toolchain
<ZombieChicken> ish?
<rqou> but currently only supporting the XC2C32A unless you live in the EU
<rqou> also needs much more testing, expect bugs
<rqou> also the packing efficiency isn't quite as good as ise
<rqou> if you live in the EU you can patch your own version to support the larger devices, but i probably cannot/should not explain to you exactly how
<rqou> MAX V is also a work in progress (Project Chibi)
<rqou> currently only LUT bits and LUT inputs are understood
<rqou> currently struggling with understanding the interconnect
<rqou> but seriously, azonenberg: what are the potential legal problems with someone like whitequark distributing an "EU edition" of xc2par?
<rqou> or heck, someone like q3k (who (if i am accurately understanding you) also is very unimpressed with the state of intellectual property in north america) can also release an "EU edition"
<awygle> we gotta get a ##openlawyer :-P
<rqou> isn't that the EFF? :P
<awygle> there's obvious differences in everyone's understanding. or level of paranoia, if nothing else
<awygle> has anyone brought this up to the EFF?
<rqou> probably not
<rqou> yet another option is for somebody to come up with some trick for eliminating the need for an "EU edition"
<rqou> ZombieChicken: potential contribution? :P
<ZombieChicken> no clue
<ZombieChicken> don't bet on it tbh
<rqou> if you are indeed interested, i can explain in more detail what is going on
<rqou> unless digshadow has made any significant progress, azonenberg's "fuzz the hardware" idea might be viable
<rqou> unfortunately the barrier to entry here is annoyingly high thanks to lack of time amongst most people here
<ZombieChicken> I'm mostly asking questions because I like knowing what options there are.
<ZombieChicken> and really distrust anything closed source and/or proprietary
<rqou> improving packing efficiency for Coolrunner-II is also a good place for contributions if you're more a software/theory/algorithms person
<ZombieChicken> when I heard about the Ice40 toolchain, my first thought was "Oh neat. Maybe one could translate some Lisp and load it into that thing and do X a lot faster/cheaper"
<digshadow> rqou: I have made some significnat progress, but I was trying to hold off sharing until I fixed some things
<ZombieChicken> right now, though, I have a lot of other crap I need to deal with before trying to pick something like this up
<rqou> if you like "toil" you can consider figuring out how to make gp4par work with newer devices that have shared resources
<rqou> hey ping azonenberg
<rqou> oh i just remembered
<rqou> ZombieChicken: if you like pcb design you can probably try designing a better Coolrunner-II dev board
<rqou> because azonenberg's is quite buggy and suboptimal :P
<rqou> and/or you can help us write an svf exporter (which is only about 100-200 LOC that nobody has had time to write and debug)
unixb0y has quit [Ping timeout: 256 seconds]
unixb0y has joined ##openfpga
kmehall has quit [Quit: No Ping reply in 180 seconds.]
kmehall has joined ##openfpga
<digshadow> rqou: whats buggy about it
<rqou> usb connector does not have enough mechanical support and easily shears off
<rqou> some of the labels are the wrong way around, leading to massive confusion
<rqou> and many of the global control signal pins aren't wired out anywhere
<digshadow> gotcha
m_w has quit [Quit: leaving]
<rqou> oh (not actually a problem, just a fun observation) and the vast majority of the power consumption is supposedly the FTDI asic :P
<rqou> ftdi is a piece of shit, news at 11
digshadow has quit [Ping timeout: 256 seconds]
ZombieChicken has quit [Quit: Have a nice day]
<mietek> noob question: do PCB manufacturing houses plate holes in boards, as you would want for through-hole soldering?
<mietek> so, say, I could layout a PCB that is all perfboard and have it manufactured without issues?
<mietek> balrog: meep
<balrog> yes they do, if you specify plated through-hole
<balrog> some don't do non-plated
<mietek> would that be “via process”?
<mietek> I don’t see anything obvious to me
<balrog> it's a standard feature everyone offers (plated that is)
<mietek> cool
<mietek> thanks
<mietek> could you explain what the choices in “via process” mean?
<mietek> I assume I want the default “tenting vias”
ZombieChicken has joined ##openfpga
<balrog> that's for vias, not through holes
<mietek> do you agree with “All through-holes are vias, but not all vias are through-holes”?
<balrog> no, only plated through holes are vias
<balrog> oh, that shows what blind and buried vias are
<mietek> so they say “1” is a through-hole
<balrog> that becomes relevant with 4+ layers, and even then with more expensive processes
<rqou> mietek: usually the convention is that holes that intersect with copper are plated
<rqou> otherwise they're unplated
<balrog> rqou: that's when you have a combined drill file?
<balrog> (which is what most fabs want)
<rqou> that's all i've ever used
<rqou> ugh so right now i'm "very brute force" trying to fuzz valid connections from C4 lines into LABs
<rqou> and after _24 hours_ it's not only not done but has only discovered _one_ legal path so far
<rqou> i must be doing something wrong, but what?
Lord_Nightmare has quit [Ping timeout: 240 seconds]
<awygle> lol
<mietek> balrog: thanks, that was a very nice read. I like the “via in pad” concept.
Lord_Nightmare has joined ##openfpga
<rqou> not sure if i should leave this running further, or cancel it
digshadow has joined ##openfpga
<rqou> ok, something in my fuzzer is fucked for sure
Lord_Nightmare has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined ##openfpga
<rqou> AAAAAARGH
<rqou> FUUUUUUCK
<rqou> there was a typo
<rqou> goodbye 24hrs of fuzzing
<kc8apf> what language are you using for fuzzing?
<rqou> python
<rqou> but the typo wasn't in the python code itself
<rqou> it was in the routing constraints file for quartus
<kc8apf> oh dear
<rqou> i guess i can also use this opportunity to debug why i can't get more parallel ssh connections working
<ZombieChicken> Well, at least it found 1 working route...
<rqou> that i already knew about
<ZombieChicken> Oh. Well then
<kc8apf> why do these tools allow syntax errors?!?
<rqou> apparently back in the day you could make it hardfail on errors
<rqou> but i tried it and it doesn't appear to work anymore
<ZombieChicken> kc8apf: Maybe the syntax is too complex?
<rqou> nah, it's dirt simple
<kc8apf> does it use SDC?
<rqou> it does also use sdc
<kc8apf> for as much as I loathe tcl, it does error on invalid syntax
<rqou> oh, the syntax (in this sense) was valid
<ZombieChicken> one of those teh==the errors?
<rqou> pretty much
<rqou> ok, well, i seemed to have fixed the issue with ssh
<rqou> now we can at least fuzz faster
<rqou> not sure what was wrong before
Lord_Nightmare has joined ##openfpga
<rqou> must have been tiredness or something
<rqou> wheee, load average: 28.06
<ZombieChicken> My laptop coughed just reading that
<balrog> rqou: what are you trying to fuzz?
Lord_Nightmare has quit [Excess Flood]
<rqou> C4 wires into LABs
<kc8apf> depending on how much fuzzing is required, the distributed approach I'm using in https://github.com/gaffe-logic/xc7-data-gen might be useful
<rqou> at this point in time i don't yet want to bother with true distributed-ness
<rqou> although retrofitting such a thing would not be too difficult
azonenberg_work has quit [Ping timeout: 268 seconds]
<rqou> yeah, now the bits are pouring in
<rqou> anyways, kc8apf: since i have 10 cores (20 threads) and the entire fpga is only 6x8 tiles i think i'll be fine with just one machine :P
<kc8apf> I figured
<kc8apf> xc7 is a different beast
<rqou> yeah, i would consider making that distributed
<ZombieChicken> xc7?
<rqou> right now my scripts are already kinda distributed-ready
<rqou> it uses ssh to run commands (since quartus is installed in a container)
<kc8apf> ZombieChicken: Xilinx 7-series (Spartan7, Artix7, Kintex7, Virtex7)
<rqou> but i currently assume the remote filesystems are mounted
<ZombieChicken> k
<rqou> (which for lxc is trivially true)
<kc8apf> I'm using a framework that takes care of storing/retrieving artifacts from an S3-compatible service
<rqou> that sounds way overengineered
<kc8apf> not for xc7
<kc8apf> there's a _lot_ of parts
<kc8apf> and having the intermediate files is very helpful when debugging
<rqou> if i wanted something like that i would just go and hope that somebody has coded s3fs-fuse :P
<kc8apf> it's convenient for me as I have a 3-machine kubernetes cluster at home
<kc8apf> I can also spin one up on Google Cloud with as many machines as I need
<rqou> > Argo is an open source container-native workflow engine for getting work done on Kubernetes. Argo is implemented as a Kubernetes CRD (Custom Resource Definition).
<rqou> brilliant /s
<rqou> that tells me absolutely nothing
<ZombieChicken> It tells you someone in marketing is writing their stuff
<ZombieChicken> instead of someone with a clue
<rqou> pretty much :P
<rqou> i mean, i do actually like the idea of containers
<kc8apf> basically, you feed it a DAG where each node is a Kubernetes job (Docker image + args)
<rqou> but somehow all of the implementations seem really overdone
<kc8apf> artifacts are carried across edges
<rqou> meanwhile i just use "worse is better" techniques
<rqou> using cutting-edge technology like "python" and "filesystems" :P
<kc8apf> meh. I'm just used to running large workflows over _lots_ of machines
<kc8apf> Processing PBs of data over 8k machines was routine for me a few years ago
<ZombieChicken> rqou: Nothing wrong with using the filesystem
<kc8apf> definitely not worth the hassle if you can use a single machine
<ZombieChicken> Nice thing about living in this age is all the fairly cheap machines you can buy
<rqou> yup
<kc8apf> friend is remarketing old cloud servers: http://www.horizon-computing.com/?page_id=1562
<kc8apf> $750 gets you a pretty beefy machine
<ZombieChicken> I've been pondering some of the Firefly systems
<ZombieChicken> Not especially powerful, but certainly interestingish
<rqou> i'm already running a comparable machine (except RAM, which was way way too expensive recently (and still?))
<rqou> except since this is a workstation it's not quite so fancy
<ZombieChicken> I'm envious
<rqou> i'm running a broadwell-e xeon in an x99 HEDT motherboard
<ZombieChicken> I'm on a 1.3GHz dual core Intel machine
<kc8apf> I'm typically on a macbook air
<kc8apf> have a few i5 machines around though
<rqou> hmm ping azonenberg
<rqou> ping daveshah
<rqou> in other news, afaict linux caching/paging is _really good_
Bike has quit [Quit: Lost terminal]
ZombieChicken has quit [Ping timeout: 250 seconds]
ZombieChicken has joined ##openfpga
Lord_Nightmare has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 265 seconds]
<rqou> hrm, quartus appears to hammer the linux special filesystems a nontrivial amount
<rqou> i see `lxcfs` occasionally appearing in top
<kc8apf> I wonder what it's doing
<rqou> just a guess: measuring cpu time
<kc8apf> I really hope they aren't that dumb
<rqou> measuring memory? :P
<rqou> i guess none of these _require_ poking proc
<ZombieChicken> memory usage is in /proc/meminfo
<rqou> or in the heap data structures inside your own process? :P
<kc8apf> it certainly doesn't need to know _system_ RAM usage
<rqou> (although tbh i don't know if there's a standard api to access those)
<kc8apf> it takes a lot of abusing proc to have it take up any significant amount of cpu time
<rqou> well, who knows how slow lxcfs is internally
<rqou> iirc lxcfs is implemented on top of FUSE?
<rqou> hmm yeah it is
<rqou> honestly lxcfs is probably just not that optimized
<rqou> because usually proc isn't really in the hot path of any code
<ZombieChicken> unless it's something like top
<ZombieChicken> and even then I don't think it would be hammering away at /proc or /sys enough to notice
<awygle> yeah ram is crazy right noe
<rqou> sure, but usually use of top isn't in the hot path of any system deployments either
<awygle> I need a bunch of fast ddr4 for this new system to really be worth it
<kc8apf> I spent quite a bit of time optimizing top's code paths at Apple
<awygle> But it'd be as much again as the cpu+mobo
<rqou> huh
<rqou> maybe i'm wrong
<rqou> i guess some people really want their top to be fast?
<awygle> Top optimization matters so when you run top you don't get top at the top :-P
<ZombieChicken> I'd assume you want something like top to take the bare minimum from programs doing real work
<rqou> lol awygle
<kc8apf> admitidly it was doing really dumb things that caused top to effective hang on processes with heavily fragmented memory maps
<rqou> blame gnu again? :P
<azonenberg> rqou: how is my board buggy?
<azonenberg> other than the solder defect and me putting one dip switch on backwards
<azonenberg> its very straightforward
<rqou> <rqou> usb connector does not have enough mechanical support and easily shears off
<rqou> <rqou> some of the labels are the wrong way around, leading to massive confusion
<rqou> <rqou> and many of the global control signal pins aren't wired out anywhere
<kc8apf> ZombieChicken: top doesn't matter that much. Profilers tend to be extremely lightweight during collection.
<azonenberg> So, the labels are not wrong
<azonenberg> the dip switch was soldered backwards
<azonenberg> thats an assembly issue, not a pcb bug
<azonenberg> The usb connector can be epoxied
<rqou> fine, then the assembly sheet is wrong :P
<azonenberg> there was no assembly drawing
<azonenberg> i put it in backwards
<rqou> ah ok
<azonenberg> So the design is fine
<azonenberg> I just built it wrong
<ZombieChicken> kc8apf: One would hope that would be the case with profilers, but what should be the case and what is the case isn't exactly the same thing
<rqou> "many of the global control signal pins aren't wired out anywhere" isn't _wrong_ per se but is quite suboptimal especially for what you wanted the board for
<azonenberg> Yes, that was a legitimate oversight
* kc8apf wrote profilers for many years
<azonenberg> Not a bug, but something that could be improved on certainly
<awygle> rqou: where's your chibi code?
<rqou> my github
<awygle> oh. duh.
<rqou> anyways azonenberg i wanted to annoy you with some questions
<awygle> Actually I think you linked it on Twitter or something even.
<kc8apf> MAX V looked perfect for an upcoming project. Then I realized it doesn't have any LVDS inputs.
<rqou> azonenberg: now that i made my C4 track fuzzer actually working, i'm noticing that some of the C4 tracks that go into a particular tile actually originate out of that same tile (at least according to the coordinates)
<rqou> why would this be useful?
<awygle> LUT cascades?
<rqou> separate wire
<rqou> actually afaict there's no cascades at all between tiles
<rqou> only within a tile
<rqou> which has _two_ cascades
<rqou> unlike other fpgas i've seen
<rqou> but yeah, the max v tile internal structure is _weird_
<rqou> all sorts of random bullshit features
azonenberg_work has joined ##openfpga
<rqou> ooh i think i figured out why
<rqou> if i'm reading the datasheet correctly, adjacent up/down tiles can drive the wire too
<rqou> unless of course that's not what it actually says
<rqou> hmm i think i just realized something
<rqou> ping azonenberg?
<azonenberg> rqou: ?
<rqou> i think i know why the column "routing channel width" is claimed to be 56
<azonenberg> oh?
<rqou> all "up" tracks will have their coordinates set to the tile they originate from
<rqou> but "down" tracks are named from the _bottom_ (vpr convention)
<rqou> but that would exceed the array size for every single tile
<rqou> so all of these get clamped at Y=0
<rqou> if like we guessed/assumed the other day that there are 14 up and 14 down tracks in every tile
<rqou> and there are 4 logic tiles in a column
<rqou> then 4*14 = 56
<azonenberg> that seems to make sense
<rqou> although what's weird to me is that this would assume that the topmost/bottommost tiles still have up/down tracks
<rqou> which seems useless?
<rqou> i guess the io cell is there
<rqou> in other news, ecdsa/ecdh are slow as shit :P
<sorear> how many scalar multiplications are you getting per second
<rqou> no idea
<azonenberg> what are you doing with ecdsa/ecdh??
<rqou> but when i didn't have controlmasters working correctly in ssh, the majority of the fuzzing time was apparently taken up by opening/closing the connection
<rqou> e.g. it's been ~2 hours and the new fixed fuzzer is almost done
<azonenberg> They're quite fast compared to RSA of equivalent security
<rqou> whereas the previous one would have taken an estimated ~48 hrs
<sorear> enable ed25519 public keys in ssh? :p
<sorear> although tcp also kinda sucks at spinning up connections
<rqou> it's already ed25519
<rqou> the private key is actually in the repo :P
<sorear> hi, i mostly deal with trans-continental links and i measure in "round trips", not µs or cycles
f003brv has joined ##openfpga
<azonenberg> sorear: lol, meanwhile i'm working on LAN switching here
<azonenberg> And i'm hoping to get latency sub us
<azonenberg> for some operations
<rqou> 50ns? :P
<rqou> (idk if this is even possible)
<sorear> have fun with buffer management
<azonenberg> probably not THAT low
scrts has quit [Ping timeout: 268 seconds]
<rqou> so, something interesting
<rqou> the fuzzer is not quite done yet, but from what i have so far each tile can only accept input from 41 C4 tracks
<rqou> out of 224 possible
<azonenberg> sorear: right now pinging my FPGA TCP/IP stack
<rqou> that's... very sparse
<azonenberg> from my pc
<azonenberg> worst case was 115 µs, probably right during a context switch or something
<azonenberg> average was 50 µs
<azonenberg> Best case was 16 µs
<azonenberg> Round trip
<rqou> azonenberg: does this number make any sense?
<rqou> seems too low?
<azonenberg> isn't 41 prime?
<azonenberg> that sounds really odd
<rqou> it might not be exactly 41
<rqou> now i get 37 upon rechecking
<rqou> whelp that's also a prime :P
<rqou> anyways, my issue is that that seems like it's too few wires?
<azonenberg> it does
<rqou> although this is _one_ tile
<rqou> there are 4 in a column
<rqou> maybe somehow the tool can't figure out how to get a signal onto some of the other wires?
<ZombieChicken> or maybe some of the wires rely on other cell/blocks/whatever?
<rqou> i told the tool that i can use any number of routing resources to get to the C4 track being fuzzed
scrts has joined ##openfpga
<rqou> and there cannot be congestion issues because the entire design only has a single lut
<rqou> hmm at some point i really should probably have some actual hardware to test on :P
<rqou> so azonenberg, a max v devboard will have to deal with BGA
<rqou> sounds exciting?
f003brv has quit [Ping timeout: 260 seconds]
<azonenberg> rqou: in my limited spare time i'm working on plans for a board with five large-ish bgas
<azonenberg> so... sounds kinda boring :P
<ZombieChicken> Is there a sane way to do BGA soldering at home?
<ZombieChicken> that's reliable
<azonenberg> Yes
<rqou> oh this is only 1mm pitch
<rqou> so no problem
<rqou> fortunately a max v devboard will only require 4 parts to actually cover the entire family
<azonenberg> Stencil paste, place bga with tweezers, put it in a convection toaster oven, cook at ~450F until solder melts (no preheat, let the oven's ramp-up control the rate of temp rise)
<rqou> unlike an xc2 one where ebay/taobao is the only way to build an affordable one :P
<rqou> woo fuzzer complete
<rqou> 2hrs vs 48 hrs
<rqou> the power of ecdh :P
<azonenberg> ZombieChicken: i can't actually tell you my yield accurately for assembling 1mm bga because i've never had it fail
<azonenberg> i must have done a couple of dozen ftg256 fpgas and some larger stuff like a fbg484
<azonenberg> With perfect yield
<ZombieChicken> I've heard of using a hotplate and a hot air gun
<ZombieChicken> the toaster oven sounds like a good idea
<azonenberg> a convection toaster oven gives much better results and is really the only viable way to do 2-sided placements
<azonenberg> For any nontrivial design you'll want at least decoupling capacitors on the bottom
<rqou> so i'm going to need a 256-ball bga and a 324-ball bga
<azonenberg> rqou: totally doable on oshpark 4-layer as long as you dont need all of the ios on the 324
<azonenberg> (assuming the 324 is 1mm too)
<rqou> both 1mm
<azonenberg> you can probably even get away with 2-layer if you don't plan to clock it that fast, but layout will be much easier on 4
<rqou> and then to minimize cost everywhere else i'll also need a tqfp144 and a eqfp64
<rqou> (0.5 mm pitch vs 0.4 mm pitch on the qfps)
<azonenberg> honestly i'd expect better assembly yield on the 324 1mm bga
<rqou> lol
<azonenberg> than the tqfp144
<azonenberg> in my experience with anything but a perfect paste print you WILL get a bridge somewhere on one of those
<rqou> in lieu of the eqfp64 you can have a 0.5mm pitch mbga64
<azonenberg> eh, that is actually starting to push into the "have to be careful" range for DIY bga
<azonenberg> not impossible, i've done 0.35mm WLCSP at home
<azonenberg> But it requires care
<rqou> but the tqfp144 is unavoidable if you want to play "the specific price-saving game that i'm planning on playing"
<azonenberg> while 1mm pitch is nearly impossible to do wrong
<azonenberg> basically if you're less than ~half a mm off in both X and Y
<azonenberg> and have the paste vaguely on the pads (or just smeared flux around with a swab)
<azonenberg> it's going to self align
<azonenberg> basically if you can do 0402 passives, 1mm bga should not even be a challenge
<rqou> well, using the tqfp144 "in this specific situation" cuts the cost of this part by more than half vs the bga
<azonenberg> yeah i know
<rqou> aka the tqfp144 is a defeatured larger part
<azonenberg> personally i won't even consider a qfp unless it's a unique part i can't avoid
<azonenberg> And it's not available in another package
<rqou> which is much cheaper than the official non-defeatured version
<azonenberg> my default ic package search just filters out tqfp and soic entirely :p
<rqou> gotta test the un-defeaturing at some point :P
<azonenberg> i generally consider 1mm bga and QFN first
<azonenberg> then expand if that doesn't get me what i want
<rqou> interestingly max v is not available in QFN
<rqou> i don't think i've seen _any_ altera parts in qfn actually
<rqou> the changelog of altera's packaging doc has mention of some
<rqou> but none are actually listed
<rqou> so afaict no qfn on any current altera part
<rqou> hmm, just i thought
<rqou> i wonder if you can squeeze picorv32 into a max v?
<rqou> it fits in an hx1k, right?
<daveshah> rqou: no
<daveshah> definitly doable in 3000 LEs
<rqou> hrm
<daveshah> Anything less will be tricky
<rqou> largest part is 2K LEs
<daveshah> But dist ram will help
<azonenberg> meanwhile i'm thinking about doing my first spartan7 design soon
<rqou> so some squeezing is probably required
<daveshah> Probably
<rqou> i did manage to squeeze a <redacted (for now at least)> into an xc2c32a the other day
<rqou> using up all macrocells and about 100 pterms
<azonenberg> That is a very full coolrunner
<rqou> it turns out that knowing the architecture inside and out helps with extreme optimizations
<rqou> unfortunately this is with ISE
<rqou> xc2par seems to not be able to pack the logic as tightly
<rqou> the problem is mostly on the yosys/abc side though
scrts has quit [Ping timeout: 260 seconds]
<rqou> i'm pretty sure this is about the maximum amount of logic that can fit in an xc2c32a
<rqou> azonenberg: ok, this makes more sense
<rqou> despite 37 unique inputs
<rqou> there are 64 total input->local-track pairs
<rqou> sounds better? :P
<azonenberg> yeah
<azonenberg> So not all input-track combos are possible
<rqou> although to make it weird again 39 of the combos are on the left and 25 are on the right
<rqou> so much strange asymmetry
<rqou> at least(?) every LAB line is represented here
<sorear> when i have time™ i'm going to see about making something more logic-efficient
ZombieChicken has quit [Quit: Have a nice day]
Lord_Nightmare has joined ##openfpga
genii has quit [Remote host closed the connection]
massi has joined ##openfpga
<rqou> azonenberg: something is weird
<rqou> there are 26 local tracks per tile
<rqou> but 26 is 2*13
<rqou> again a weird prime number
<rqou> i don't see how 26 sets of anything can be reasonably squeezed into the bitstream
<rqou> maybe some bits are wasted?
<azonenberg> unlikely
<azonenberg> die space is expensive
<azonenberg> address space unused? yes, i can see that
<azonenberg> actual bitstream bits? no
<rqou> hey, xc2 has a lot of bits wasted
<azonenberg> most of them arent physically present though
<rqou> they are in the eeprom array
<rqou> i tested it
<azonenberg> in the eeprom, yes
<azonenberg> (were you able to read back?)
<rqou> yes
<azonenberg> So my conjecture about stego is valid
<rqou> not in the sec/done and usercode rows though
<azonenberg> you can hide data in a crbit that does not affect device functionality and can be used for watermarking etc
<rqou> unless i messed up
<rqou> which is also possible
<azonenberg> But thats a unique case b/c on die config mem the full width of the array
<rqou> because every time you mess up sec/done the chip gets really confused for a while
<azonenberg> most normal FPGAs have a row/col/frame type address space
<azonenberg> and i think its fully dense
<azonenberg> within the frames
<rqou> so by wasted bits i mean like 2
<rqou> or 4
<rqou> total bits
<rqou> (per tile)
<rqou> so i think it's plausible?
<rqou> it's also possible some other random tile-wide controls are shoved in there instead
<azonenberg> that sounds more plausible
<azonenberg> sdr vs ddr ff, rst vs set
<azonenberg> anything like that
<rqou> since altera has a stupid number of tile-wide signals
<azonenberg> xilinx has control sets
<rqou> including a signal they call addnsub :P
<azonenberg> So the carry chain can go +/-?
<azonenberg> interesting
<rqou> what do you think that does?
<rqou> nope
<rqou> not for carry chain
<azonenberg> what then
<rqou> it inverts input B on every LUT
<azonenberg> Lol
<azonenberg> So for making add-sub cells
<rqou> yeah
<rqou> exactly
<azonenberg> with the carry chain
<rqou> hence addnsub
<azonenberg> and then you swap the carry in from 0 to 1?
<azonenberg> on the LSB?
<azonenberg> to do a full twos complement almost for free
<rqou> i think it automatically does that?
<azonenberg> that's actually pretty cool
<azonenberg> so addnsub also toggles the carry in of the lsb?
<rqou> there's also a "fractured" lut mode just for building adders
<azonenberg> i.e. when not carrying from the adjacent tile, it uses that value
<rqou> splitting the 4-lut into 4 2-luts
<azonenberg> thats interesting
<rqou> there's also two carry wires
<azonenberg> most luts i see they only break out the last mux stage
<azonenberg> like 6->1 turning into 5->2
<rqou> oh, and there's two cascade wires too
<rqou> a cascade wire for LUTs
<rqou> and a second one just for registers
<rqou> for compact shift registers apparently
<rqou> like i said, the insides of a tile have a ridiculous amount of random stuff
<rqou> i actually haven't fuzzed any of this btw
<azonenberg> the general impression i've had is that altera tiles are much more complex than xilinx
<azonenberg> xilinx prefers to just have more tiles
<rqou> i'm assuming it's going to be pretty easy once the interconnect is understood
<rqou> but anyways
<rqou> isn't this a ridiculous feature set for a "CPLD?"
<rqou> i kinda like it
<azonenberg> lol altera doesnt make cplds
<azonenberg> They make tiny flash fpgas and brand them as cplds
<azonenberg> which i dont like, i think the term cpld should have died when product term devices died
<azonenberg> the distinction of architecture makes a lot more sense than volatile vs nonvolatile
<azonenberg> since there's so much gray in the latter realm
<sorear> how much of a head start does maxv give on high-end devices?
<azonenberg> antifuses in the fabric? otp/flash that then loads sram?
<azonenberg> etc
<rqou> sorear: what do you mean?
<azonenberg> all the way up to spi flash in package like spartan3an
<azonenberg> theres a wide continuum of nonvolatile tech
<rqou> max v is basically a cut-down cyclone 1
<rqou> Marex was claiming that not too much has changed up to cyclone 4 at least
<azonenberg> rqou: i think he means in terms of speeding boot time
<rqou> btw azonenberg: i just realized why the max ii codename is typhoon
<azonenberg> lol
<azonenberg> successor to cyclone?
<rqou> a typhoon is much smaller than a cyclone :P
<rqou> so azonenberg, stratix 10 RE when? :P :P :P
<sorear> rqou: symbiflow answers "why xilinx" with "because they aren't completely reinventing the arch every few years", so i'm wondering just how much has changed between 4 and 10 or whatever they're up to now
<azonenberg> sorear: xilinx reinvented the arch once, with 7 series
<rqou> um, afaict so far xilinx has changed up their arch a lot more
<sorear> tropical cyclone nomenclature is aggravating
<azonenberg> and it was needed
<azonenberg> rqou: not true
<rqou> no?
<Marex> rqou: right, CIV and CV are very different, but CI...CIV are very similar
<azonenberg> all current gen devices trace their lineage directly to virtex6
<azonenberg> Which is a pretty clear descendent of virtex2, although there have been arch changes in between
<Marex> rqou: CI has less LUTs per LAB compared to CII I think, but since then it's the same mostly
<Marex> CIV is in fact only a dieshring of CIII
<rqou> Marex: do you have any idea how V/10 are different?
<azonenberg> v6 introduced the current columnar architecture with lut6s
<azonenberg> spartan6 meanwhile was the "windows ME" of xilinx
<Marex> rqou: I _think_ max10 is a derivative of CIV
<azonenberg> they had two parallel product families, the low-end one was so awful they killed it
<azonenberg> And now the low end parts are cut-down virtexes rather than being an entirely different uarch
<rqou> was virtex2 not a column architecture?
<rqou> also, does this mean that altera basically always had a column architecture?
<azonenberg> i dont think v2 was quite as much so as v6
<azonenberg> i know the spartans were an entirely new layout for each one
<daveshah> rqou: afaik cyclone 10 lp and cyclone iv e are almost identical
<azonenberg> things like hard ip blocks and dcms just bumping into the array and shoving luts around
<daveshah> not sure about the 10 gx
<azonenberg> while in 7 series and newer the CMTs are full columns
<rqou> oh yeah, altera has a ridiculous number of product line variants
<rqou> oh wait wtf
<rqou> i just looked at the flagship features for stratix 10
<rqou> (which you can't even target with free quartus btw)
<rqou> and one of the flagship features is "we just can't make wires any faster anymore, but transistors keep getting cheaper, so we're going to put a _fuckton_ of transistors along all routing wires"
<azonenberg> yes, they let you put pipeline registers in long-distance routs
<rqou> "The Intel HyperFlex FPGA Architecture introduces additional bypassable registers everywhere throughout the FPGA fabric. These additional registers, called Hyper-Registers, are available on every interconnect routing segment and at the inputs of all functional blocks. Hyper-Registers enable three key design techniques to achieve the 2X core performance increase"
<rqou> such a dumb name too
<azonenberg> if you ever want to get an earful of altera fanboying / stratix uarch discussion hop in ##fpga and chat with matthiasm
<azonenberg> he's a cool guy, i had dinner with him in The Hague last summer when i was there for a con
<azonenberg> does broadcast video stuff for a German company
<sorear> the alternative of course being a LE register / i wonder how much dedicated non-LE registers help with capacity (doesn't use LEs!) versus speed (no LUT, just a register and presumably a mux of some kind)
<rqou> hmm yeah cyclone5 really does seem quite a bit different
<rqou> it's a weirdly-fracturable 6lut arch
<rqou> but cyclone4 seems to just be a rehash of the older arch
<rqou> and max10 looks like cyclone4
<azonenberg> meanwhile since virtex6 xilinx's architectural changes have basically been die shrinks, better hard ip and transceivers
<azonenberg> and some clocking structure tweaks
<azonenberg> i mean theres been little things re how many luts pack into a slice or how the slicems vs slicel's/slicex's are packed etc
<azonenberg> But nothing super massive like changing lut size
<rqou> anyways, if i were to ever RE another altera part, it'd probably be the max10
<rqou> not a cyclone
<rqou> nv parts are always pretty cute
<azonenberg> y u no stratix?
<rqou> no $$$
<rqou> requires cracking quartus first
<rqou> you can't even target any stratix nor arria devices in the free version
<rqou> ok, apparently it supports arria ii
<rqou> but nobody cares about that
<rqou> heck, it doesn't even support cyclone 10 gx (with transceivers?)
<sorear> was v6 also SLR-ready?
<azonenberg> sorear: not to my knowledge
<azonenberg> so ok thats an arch change
<azonenberg> But its not super massive
<azonenberg> basically you take tiles of the same fpga fabric you had before
<azonenberg> and shove laguna sites where you'd otherwise have io banks
<azonenberg> so more iobs with shorter range, physically smaller drivers that have TSVs instead of bond pads on the output
<azonenberg> then the interposer is purely passive
<rqou> huh the pro version of quartus is actually "only" $4k/seat
<azonenberg> The config process basically daisy-chains the jtag registers
<rqou> that's not actually that bad if you're a "real company"
<azonenberg> rqou: full vivado is around there too iric?
<azonenberg> iirc*
<rqou> i expected more
<azonenberg> its not like virtuoso-level pricing
<azonenberg> if thats what you were thinking
<rqou> yeah
<azonenberg> i'm seriously considering buying a full vivado seat at some point in the not too distant future
<azonenberg> as in maybe 2-5 years out
<sorear> is the «laguna site» configurationally identical to an iob? (should that be lacuna?)
<azonenberg> sorear: no, it doesnt have an ioserdes or ddr registers or any of that fluff
<azonenberg> there's no iostandards
<azonenberg> no differential io
<sorear> and that's /seat not /seat/year like microsemi? :p
<azonenberg> with xilinx, when you buy vivado (or ise in the old days)
<azonenberg> you get a perpetual license to that version plus any updates released for 1 year from when you bought it
<azonenberg> while you can't upgrade past that and keep the license, the old seat stays valid forever
<rqou> oh btw azonenberg have i showed you this? https://photos.app.goo.gl/WtSslJ9afbVVKrjy1
<rqou> (and no, i absolutely will not attempt to pirate it)
<sorear> apparently tsmc considers their *file names* super top secret
<sorear> be careful
<rqou> yeah well, tough luck for cadence since almost any student can see these filenames
* sorear would like to know more about the "Stanford tech file incident" c.f. https://github.com/ucb-bar/hammer/pull/24#issuecomment-291541460
<rqou> i don't know, but i'm assuming stanford accidentally leaked a nda cell library at some point?
<rqou> happens
<rqou> it's a university
<azonenberg> rqou: nyu leaked a good chunk of the ibm... 32nm? design kit
<rqou> right, i remember you mentioning that
<azonenberg> Along with a buttload of architectural docs, compilers, even ISA spec and pin diagrams, for the nsa codebreaking supercomputer they were building :p
<azonenberg> about the only thing missing was the rtl and gds
<rqou> oh, this is public knowledge now?
<azonenberg> it was easily enough info to program it
<azonenberg> I dont know if the full dump ever went public
<azonenberg> i know folks who have it, i've seen it
<azonenberg> the intercept did a story on it but didnt dump all of the nda'd ibm stuff publicly for obvious reasons
<azonenberg> It wasnt relevant
<rqou> aw, not going to turn into "oman v2"? :P
<azonenberg> the design kit sadly didnt include full gds layers
<azonenberg> it did have cell dimensions/outlines, sim models, and contact locations for m2 wires to hook up though
<azonenberg> i.e. probably enough to do your own tapeout
<azonenberg> then design kits for pll ip and some other fun stuff
<rqou> did anybody get disappeared afterwards? :P
<azonenberg> this wasnt leaked-leaked a la snowden
<azonenberg> this was, somebody chmod 755'd their home dir
<azonenberg> and the server had /home/ in the web root
<azonenberg> so you could go to http://foo.nyu.edu/~bar/
<azonenberg> and see everything
<rqou> does the nsa have some super sekrit tech that nobody else has? or was it not too far from "usual industry custom HPC work"
<azonenberg> it was well beyond what anybody else had at the time and would probably even beat a modern supercomputer at crypto
<azonenberg> it was an interesting hybrid of dsp and fpga
<azonenberg> they had datapath elements that ran some kind of microcode then bitstream-programmed luts and muxes and stuff
<azonenberg> the microcode included a GF(2^8) multiply instruction
<rqou> but this is all comp arch stuff that people have thought about before
<azonenberg> Which left zero doubt in my mind for what the thing was supposed to do
<rqou> it doesn't have any alien nanocrystals or anything like that :P
<azonenberg> No
<rqou> hey, it could be some compression/coding thing too :P
<azonenberg> But it was a well designed architecture that was clearly tuned for cryptanalysis
<pie_> nice
<pie_> when was this?
<sorear> "nyu nsa supercomputer" turns up a pretty content-free intercept article
<azonenberg> yes, there's a lot more than they published
<azonenberg> bunnie has the full dump, as do several other people
<sorear> i can't even tell what kind of code this is supposed to break, although they're tipping their hands by saying the Chudnovskys were involved
<pie_> oh damn, 2017
<sorear> the Chudnovskys wouldn't be touching AES
<pie_> sorear enlighten us not so crypto-nerds? :p
<rqou> can someone please leak it and make it into "oman v2"?
<rqou> :P
<rqou> or maybe a number >2 since apparently there are less secret and more secret oman archives
<azonenberg> sorear: i dont think its specificially for ecc if thats what you're thinking
<azonenberg> I think it was meant to accelerate cracking of all known crypto algorithms via appropriately written code
<sorear> the chudnovskys are number theorists, this is the first i've heard of them being involved in crypto
<sorear> so presumably rsa/dsa
<sorear> yeah
<azonenberg> yeah but the gf polynomial multiply means aes
<sorear> multi-purpose
<azonenberg> i think this is meant to be generic
<azonenberg> But still crypto focused
<rqou> i mean, rsa1024 is considered accessible to state-level attackers at this point, right?
<azonenberg> Kinda similar idea to the crypto DSP core i designed a while ago
<sorear> yes
<azonenberg> rqou: I'm certain somebody who had one of these could break rsa1024 on a regular basis
<rqou> including the necessary io bandwidth?
<azonenberg> 2048 would likely require an algorithmic breakthrough, but i'm far from confident they don't have one :p
<rqou> gnfs generates a ton of data
<azonenberg> This thing was a bunch of asics on cards plugged into some kind of fast interconnect
<azonenberg> it was a multi-rack system
<sorear> gnfs has multiple phases
<azonenberg> they were talking petascale performance iirc
<azonenberg> for the whole thing
<azonenberg> And the *leak* was in 2017, the docs are several years older than that
<pie_> man all this teasering is horrible
<azonenberg> it just took this long for someone to stumble across it
<sorear> relation generation (according to djb et al more recent designs) is basically bitcoin mining
<rqou> yeah azonenberg plz 2 leak teh archive
<pie_> inb4 is the leak actually a psyop
<azonenberg> rqou: you assume i actually have a copy of it on me
<azonenberg> i said i've seen it
<azonenberg> Not that i had it
<pie_> ^^^
<cr1901_modern> rqou: I know I've talked about it before, but why/how do you know about the oman archive anyway :P?
<azonenberg> Side note
<azonenberg> i wonder how many nsa analysts have been fired for mining bitcoins on this thing?
<azonenberg> :p
<pie_> lmao
<azonenberg> Because it would excel at it, especially 2-3 years ago before asics were really popuilar
<rqou> cr1901_modern: you posted it? :P
<pie_> cr1901_modern, was that the nintendo thing?
<cr1901_modern> No you knew about it before I posted it
<pie_> rqou, opsec pls
<rqou> hrm i probably heard about it from some random emudrama forum thread
<pie_> <azonenberg> Because it would excel at it, especially 2-3 years ago before asics were really popuilar
<pie_> illuminati confirmed
<cr1901_modern> More seriously, nobody talks about it, not even in emu circles. It's n64's dark secret.
<azonenberg> pie_: conclusion: satoshi works for nsa
<pie_> well we all know emu people are all elitists anyway right :p
<cr1901_modern> No shit
<pie_> cr1901_modern, ^
<rqou> although gruetzkopf mentions that the "common" oman archive is pretty incomplete
<rqou> missing shadows entirely or something?
<sorear> algorithmic breakthroughs for rsa/dsa are worryingly plausible
<sorear> considering that the small-characteristic case is dead
<rqou> and not for ecdlp?
<pie_> rqou, since im not networkingally equipped for it, i appont you our local dump archivist :p
<rqou> heh, you don't want me
<pie_> i know
<sorear> ecdlp and finite field dlp have close to nothing in common for an attacker
<rqou> my curation skills suck
<pie_> but who else is going to do it
<cr1901_modern> pie_: Emu dev is a "how deeply can I memorize esoteric knowledge and how voltages on pins relate to each other temporally" contest.
<rqou> sorear: yeah, i know
<pie_> cr1901_modern, as opposed to "pls document"?
<pie_> well its not like documentation happens in normal software either
<cr1901_modern> I mean that too, but...
<pie_> which is all the more ironic since niche knowledge is exactly what youd want to preserve
<cr1901_modern> look, ppl look for reasons to feel superior to each other/get recognition, even when goals are ultimately noble.
<pie_> oh yeah sure thats fine xD
<cr1901_modern> I'm not immune to this either
<pie_> as long as theyre atually contributing to the common good
<pie_> i mean
<cr1901_modern> But hey, maybe I'm bitter b/c I'm just a luker for 5+ years and have jack shit to my name in emu dev
<pie_> not workng to undermine eachoter
<pie_> haha yeah :(
* sorear sleep
<pie_> sorear, o/ bye bye
* pie_ plugs sorear into charger
<pie_> rqou, i want cool dumps from you next ccc :P
<pie_> get collectin
<rqou> i did put oman on one of the servers
<rqou> but it somehow got lost
<cr1901_modern> I mean, the link I posted months ago should still work
<cr1901_modern> just search the archives
<rqou> um
<rqou> i personally wouldn't keep such links around
<cr1901_modern> You can't "unleak" something
<cr1901_modern> In any case, it's more that I forgot to invalidate it :P
<rqou> yeah, even though people seem to think i act very cavalier about everything, i do still have some rules and standards
<pie_> well threes the cliche of seem aloof but actually be a sekrit badass or something
<pie_> rqou, also, same here i guess
<pie_> also <cr1901_modern> You can't "unleak" something
<pie_> which actually kind of leaves one feeling in a weird state
<pie_> like, its already leaked and public and shit, but you feel a bit uneasy nevertheless?
<cr1901_modern> pie_: My personal feeling is that it doesn't matter now that it's leaked and ppl shouldn't hoard it for e-points
<rqou> probably still doesn't compare with people actually trying to _compile_ it
<pie_> rqou, ?
<cr1901_modern> I thought about it as a joke- too much effort
<cr1901_modern> waaay too much effort
<pie_> oh the oman thing
<pie_> cr1901_modern, im more of the "if its hard to get, hoard it so you can give your friends useful things" party
<pie_> you know, like a library
<cr1901_modern> pie_: Ppl make the argument that if you've seen the archive you're "tainted"/can't morally/legally help out w/ creating a clean impl, but...
<pie_> how long till the patents expire
<cr1901_modern> nobody was gonna make a clean room RE of RDP or a MIPS core. There's just too much internal state
<cr1901_modern> clean room "cycle accurate" RE
<pie_> need to make dat auto cmos re workfloo
<cr1901_modern> Oh well, I guess that's also an option for n64 lol
scrts has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
bitd has joined ##openfpga
Hamilton has joined ##openfpga
soylentyellow_ has joined ##openfpga
soylentyellow has quit [Ping timeout: 264 seconds]
Hamilton has quit [Quit: Leaving]
<pie_> today im releasing my functional unit testing framework called PieUnit https://bpaste.net/show/d453d854cb3b
<pie_> our slogan is shitty unit testing in 20 lines
<pie_> our logo is shitty charmander holding a wrench
rohitksingh_work has quit [Read error: Connection reset by peer]
Bike has joined ##openfpga
scrts has quit [Remote host closed the connection]
scrts has joined ##openfpga
genii has joined ##openfpga
rohitksingh has joined ##openfpga
<cr1901_modern> so you took the pokemon green/red sprites and superimposed a wrench?
<pie_> sadly i didnt actually do anything but
<jn__> pie_: "grrrr, arrrrr"
<pie_> i think i wouldnt actually mind a shitty charmander with a wrench tshirt
<pie_> but none of my friends
rohitksingh has quit [Quit: Leaving.]
<gruetzkopf> what's the startup time like on a ice40up5k running from internal clock and external SPI memory?
<pie_> 1 like 1 clock cycle
<jn__> pie_: that's rather impossible when the bitstream needs to be loaded from external memory though :)
<daveshah> gruetzkopf: probably a few hundred ms
<gruetzkopf> that's short enough
<daveshah> You can actually change the SPI frequency in the bitstream if you want it a bit faster
<gruetzkopf> i have like 3s before the end-user could notice it
<daveshah> 140ms at default frequency according to the datasheet
<awygle> rqou: you can't target cyclone 10 GX with the low tier quartus but you can install pro for free and it has a free cyclone 10 GX license
<awygle> Also I'm pretty sure I've been told that max 10 is cyclone IV and cyclone 10 is arria V, I try to find citations later
stefanct has quit [Ping timeout: 256 seconds]
stefanct has joined ##openfpga
stefanct has joined ##openfpga
stefanct has quit [Changing host]
Hamilton has joined ##openfpga
Hamilton2 has joined ##openfpga
Hamilton has quit [Ping timeout: 265 seconds]
Hamilton3 has joined ##openfpga
Hamilton2 has quit [Ping timeout: 265 seconds]
Hamilton3 has quit [Ping timeout: 264 seconds]
ym has quit [Quit: Leaving]
ym has joined ##openfpga
digshadow has quit [Ping timeout: 245 seconds]
<awygle> the rust unicode identifiers discussions are fascinating
digshadow has joined ##openfpga
f003brv has joined ##openfpga
<f003brv> I have the Spartan 6 atm, is that a good FPGA to learn or are there betters?
<f003brv> better ones out there? *
<awygle> f003brv: the spartan 6 is possibly not the best place to start, as Vivado, xilinx's newest tool suite, doesn't support it. as far as what might be better, what are your goals?
<f003brv> Well I am currently just learning FPGA's. I do have a project too. I'm collecting image data from an Arducam and running an algorithm
<f003brv> on the fpga for image processing
<f003brv> that I have ran on an embedded system. I'm sure a Spartan 6 is fine for that
<f003brv> but I was just curious if there are better FPGA's to learn since I'm going to have to do that anyway with the Spartan 6
<f003brv> I don't have any familiarity with it as I'm new to the world of FPGA's
<awygle> if you want to use xilinx fpgas in the future, learning Vivado instead of ISE is probably a good idea
<azonenberg> f003brv: If you want to stick with Xilinx architectures, 7 series (either a spartan-7 or artix-7) is the way to go
<azonenberg> pricing is comparable to spartan6, possibly a bit less per unit logic
<azonenberg> But it supports the new tools
<f003brv> hmm I see, are there other architectures to try out?
<f003brv> I'm not tied to one particular one, though Xilinx did seem cool
<azonenberg> There's other vendors, each vendor has their own and totally incompatible architecture
<azonenberg> xilinx and altera are the two big players on the high end
<f003brv> Okay
<azonenberg> lattice and microsemi are midrange to small
<f003brv> I will go with the Spartan 7
<azonenberg> silego does really tiny parts (tens of luts) but they're also very cheap
<azonenberg> and have some analog
<f003brv> I also went with Spartan 6 because of the papillio-pro
<f003brv> it seemed as a good way to get started with FPGA
<azonenberg> Regarding tooling availability, all vendors have free-as-in-beer tools for their lower end parts, however i've had trouble getting microsemi's tools to run on linux
<azonenberg> most of the others run on linux and windows, osx tooling is basically nonexistent except for silego
<f003brv> Okay, thanks for the info
<f003brv> much appreciated
<azonenberg> Lattice ice40 parts have a third-party open source toolchain that is working and usable now
<azonenberg> there's a mostly-finished open toolchain (missing support for a few little features) for the 4th gen silego greenpak parts but i havent had time to add support for 5th gen
<azonenberg> there is active reverse engineering and development work towards an open 7-series toolchain but i'd say it's 6-12 months at least from anything that could actually be used by an average engineer
<f003brv> that's for silego?
<azonenberg> Xilinx
<awygle> lol @ optimism
<azonenberg> awygle: "at least" :)
<awygle> :p
<azonenberg> my silego toolchain is fairly stable but only supports a couple of chips
<f003brv> I see
<f003brv> How about Cypress digital logic?
<azonenberg> ice40 is the way to go if you want an open toolchain right now
<f003brv> like the psoc
<f003brv> how does that compare?
<azonenberg> pointfree and cyrozap here have been doing some reversing on psoc5lp
<azonenberg> nothing usable by average joe yet, i think they understand the logic mostly but havent had much time to do tooling dev
<f003brv> yes I was talking to pointfree
<awygle> the psoc stuff is interesting as it's basically an ARM core with FPGA stuff wrapped around it, like a mini-Zynq
<azonenberg> the official tools are windows only and ok-ish but the chips have lower gate capacity
<awygle> iiuc
<f003brv> about it. seemed an interesting project
<f003brv> I see
<azonenberg> It depends on what you're doing, if you want programmable analog and a MCU on top of the FPGA it might be a good choice
<azonenberg> But its not large and its not super fast
<f003brv> oh okay
<azonenberg> ice40 + a standalone mcu is probably better if you want open tooling and a bit more gate capacity
<azonenberg> the ice40 hx8k is the largest device with open tooling available afaik
<f003brv> well seems the Spartan 7 is good. I am interested in programmable analog and FPAA but that's for a different project
<awygle> yeah all of this depends on your values, which is why i asked what you were doing
<f003brv> yes definitely
<awygle> for example ice40s are super low power, and 7-series is... not :p
<azonenberg> Lol
<awygle> but that cuts both ways obviously
<azonenberg> yeah you're not gonna be doing 10G ethernet on an ice40 :p
<f003brv> are ice40's powerful?
<azonenberg> probably not even 1G
<awygle> mu. insufficient context.
<awygle> they're on the lower end of FPGAs
<awygle> but there are things below them
<azonenberg> f003brv: depends on what you need done :p
<awygle> and they're very good for some things
<f003brv> Ah I see, ofcourse : )
<azonenberg> you have to look at gate count, availability of hard IP, ram, plls, io, max speeds of various components
<rqou> ice40 can probably handle 1GbE
<azonenberg> rqou: gmii yes, rgmii probably not
<rqou> just rgmii is questionable
<azonenberg> But i could be wrong on that
<azonenberg> And sgmii is right out
<awygle> PoC||GTFO :p
<azonenberg> awygle: somebody should port tragiclaser to ice40
<azonenberg> phy? who needs that
<awygle> yeah actually that would be really cool for certain applications
<f003brv> I guess I'm also thinking what is a good architecture to learn and it seems Xilinx might be good to start with
<awygle> did you hook tragiclaser up through magnetics?
<rqou> my father put gigabit ethernet through a spartan3 back in the day, which seems to be comparable speeds to ice40 hx
<azonenberg> awygle: yes
<f003brv> though I like FPGA's and will probably learn other architectures in the future
<rqou> but i asked him and it was gmii
<f003brv> depending on project requirements
<awygle> f003brv: yeah xilinx is a good default starting point. no point breaking your neck looking around.
<azonenberg> f003brv: most of the folks here seem to be xilinx and lattice users, we have one guy (rqou) working on reversing some altera chips
<rqou> apparently the spartan3 io cells aren't fast enough for rgmii
<azonenberg> a few of the big guys in ##fpga are diehard altera folks
<azonenberg> rqou: oh? interesting
<azonenberg> i thought they were faster
<f003brv> Has anyone tried quick logic?
<rqou> or maybe they are and it was deemed too much work
<f003brv> they are smaller, lower powered FPGA's
<rqou> since they didn't want to waste time twiddling idelays or whatever
<awygle> oh i should run through some non-mainstream architectures for completeness. Gowin, Aeroflex, Achronix. anybody else?
<azonenberg> f003brv: interesting, seems like the same design space as what ice40 is targeting
<rqou> and also because my father always prefers to design with way more timing margin than that :P
<azonenberg> awygle: how about some of the efpga folks?
<azonenberg> can you get devkits for those?
<rqou> awygle: add them to the wiki? :P
<awygle> azonenberg: "achronix" :p
<f003brv> what is efpga?
<awygle> "embedded" FPGA
<awygle> so FPGA IP sold to ASIC manufacturers
<azonenberg> flex-logix
<f003brv> ah I see
<azonenberg> is another efpga company
<awygle> oh yeah nice catch
<azonenberg> google says adicsys
<f003brv> hmm
<azonenberg> never heard of them before
<azonenberg> but apparently they sell an fpga ip
<f003brv> Does the Sparten 7 architecture change much compared to Spartan 6?
<rqou> everything
<awygle> rqou: where on the wiki is your cheat sheet? i can't find it from the front page
<rqou> ok, not quite "everything"
<rqou> awygle: idk, you have to search for it in the list of pages
<f003brv> but if it's a significant difference, that's a good enough answer
<f003brv> I'm just trying to find a good board
<azonenberg> f003brv: basically, spartan6 is xilinx's "windows ME"
<rqou> feel free to take over wiki curation awygle :P
<f003brv> lol
<azonenberg> originally spartan and virtex were separate lines just like windows ME and NT
<azonenberg> spartan got so bad that they killed it
<azonenberg> and now, just like windows XP
<rqou> also how come nobody ever talks about using Coolrunner-II?
<azonenberg> all of their low end parts are cut down virtexes
<awygle> rqou: as soon as i find your damn page i'll link it from the homepage :p
<azonenberg> Rather than a totally different arch
<azonenberg> All modern xilinx FPGAs are descendents of virtex6, then all the way back to virtex2
<f003brv> any recommendations for spartan 7 board?
<rqou> Coolrunner-II is a product-term CPLD rather than an fpga, but there's a working open source toolchain for it
<azonenberg> Which had a hard powerpc core on it, the ancestor of today's zynq :p
<rqou> note that this tool currently "has" an "EU edition"
<rqou> thanks azonenberg
<f003brv> looks good actually
<azonenberg> I wouldn't say "best" but it's a popular one
<azonenberg> Depends on what you want to use it for :p
<azonenberg> What peripherals do you need?
<azonenberg> how much logic do you need?
<azonenberg> what are you going to connect to it?
<azonenberg> a lot of the lower end digilent boards are severely lacking in high speed I/O which handicaps you a lot
<f003brv> I'm connecting it to an Arducam
<rqou> hey azonenberg i just realized something
<azonenberg> ?
<rqou> in Coolrunner-II you can feed the output of a register through _both_ zia paths (the iob path and the macrocell path)
<rqou> this means that you probably _can_ fuzz the zia in hardware easily
<daveshah> f003brv: the icevision ice40 board has arducam connectors it
<azonenberg> interesting
<rqou> you don't need to mess around with a bazillion different pins
<f003brv> hmm interesting daveshah
<daveshah> But it's only an iCE40 UltraPlus so you'll be limited in what you can do with it
<rqou> you just need three: clock, out0, out1
<daveshah> And it's pretty expensive for what it is IMO
<rqou> oh and you can use the tff trick to determine whether you got the macrocell path or the iob path
<rqou> so the idea is to configure the zia for a certain pattern
<rqou> then place the "guessing" macrocell everywhere
cr1901_modern has quit [Read error: Connection reset by peer]
keesj has quit [Ping timeout: 256 seconds]
<rqou> set the macrocell feedback path to the xor anf the iob feedback path to the register
cr1901_modern has joined ##openfpga
<rqou> make the register a tff
<f003brv> azozenberg: which spartan 7 board do you like? (for comparison)
<rqou> and see what you get on the output pin
<azonenberg> f003brv: i dont have any
<azonenberg> i'm currently sitting in front of...
* azonenberg counts
<rqou> low = wrong, high = macrocell, toggling = iob
<azonenberg> Three coolrunner-2 boards
<rqou> sound reasonable?
<azonenberg> One spartan-6 board
<f003brv> lol nice
<azonenberg> Six artix-7 boards
keesj has joined ##openfpga
<azonenberg> A zynq-7 board
<azonenberg> And a virtex ultrascale+ board
<f003brv> mad respect
<azonenberg> I have more in the lab, this is what's at my desk
<f003brv> haha nice
<f003brv> are you a researcher?
<azonenberg> My day job is embedded security testing but i do lots of high end FPGA projects for fun and occasionally consult on the side
<azonenberg> five of the six artix boards are client prototypes, and the virtx board is a loaner from another client
<azonenberg> The rest are my personal ones
<rqou> apparently azonenberg also likes to build houses on the side too :P
<azonenberg> s/build/fix/
<f003brv> lol
<f003brv> nice
<azonenberg> if they had sold me a house that was livable, i'd have moved in
<azonenberg> But they didnt :p
<azonenberg> f003brv: anyway i literally *just* decided to do my first spartan7 design last night btw, so i started looking at them
<rqou> wait what
<rqou> what is this s7 design?
<azonenberg> rqou: the LATENTRED brain card
<rqou> ah
<azonenberg> with all of the RGMII and the QDR-II+
<azonenberg> i can't fit all of the i2c and mdio etc
digshadow has quit [Ping timeout: 276 seconds]
<f003brv> azozenberg: the information you have provided is much appreciated
<azonenberg> So i'm pushing all of the slow buses off to a second fpga
<azonenberg> it's cheaper and easier than going from a 484-ball kintex to a 676 and adding more pcb layers
<azonenberg> (all of the SGMII sorry, not RGMII)
<azonenberg> rqou: basically the spartan's job will be polling all of the PHYs periodically to get link speed/state info
<rqou> not a Coolrunner-II or a max v?
<azonenberg> polling I2C sensors
<rqou> i am saddened
<azonenberg> reading i2c eeproms on SFP+ modules
<azonenberg> rqou: i don think i would have enough state bits in a coolrunner
<azonenberg> i could see maybe an ice40 hx8k or something
<f003brv> I'll report back as I make further progress on FPGA development. Thanks for all the input !
<rqou> not a max v?
<rqou> :P
<azonenberg> when you have a working toolchain maaaaybe :P
<rqou> so smol :P
<azonenberg> i havent made the final call yet, i need to see how many ios and how much logic i need
digshadow has joined ##openfpga
<rqou> 64 pin 0.5mm bga smol :P
<azonenberg> What i know i need for SURE is...
<azonenberg> 3 lanes of MDIO, 4 lanes of I2C, reset and power rail sequencing for 3 line cards, four JTAG masters
<azonenberg> three*
<awygle> so smol so fresh so cleen
<azonenberg> oh wait, four more I2C lanes
<rqou> how many pins total?
<azonenberg> i need to read the SFP+ descriptors
<awygle> kc8apf: i fixed my clock problems, thanks for all your help
<azonenberg> Because they all use the same i2c address i need multiple buses
* awygle burns another copy of the i2c standard
<azonenberg> then SFP+ status pins (fault, module present, etc) comes out to four status pins
<gruetzkopf> yeah, SFPs are annoying
<rqou> i3c? :P
<awygle> as much as we complain about "sixteen-bit tuples" i guess this is what happens when you don't have them.
<rqou> yeah i guess
<rqou> but 8 bits is still much smaller than 32 bits :P
<awygle> i'd still prefer not having them, on balance :p but at least i see *a* point
<gruetzkopf> (but still, yay for digital optics monitoring)
<awygle> all IDs are 128 bits, generate them randomly, no collisions ever
<azonenberg> rqou: Let's see... 3*MDIO is 6, 8*I2C is 16, reset/power*3 cards is 15, 3*jtag is 12, sfp+ status is 16 so that's 65 GPIOs so far
<azonenberg> i'll probably need a few more for various things, this is just what i have off the top of my head
<rqou> ok, you've exceeded the smolest package
<azonenberg> Plus the bus back to the kintex
<rqou> I'd probably put in a real fpga
<daveshah> Seems like a HX8K job
<azonenberg> My plan was to use a ftgb196 spartan7 which has two 50-pin banks
<gruetzkopf> cutie
<gruetzkopf> (still need to aquire a 10GE switch)
<rqou> LB6M?
<gruetzkopf> that's the plan
<azonenberg> daveshah: do they have a 1mm pitch package?
<gruetzkopf> (including crossflashing it to i can also use 1G modules)
<daveshah> azonenberg: 0.8 I think
<azonenberg> i was hoping to not get the higher end design rules for 0.8mm bga on this design
<azonenberg> current plan is to have two 1mm fpgas, a 1.27mm arm soc, a 1mm flash, and a 1mm sram
<awygle> i mean you need >4L anyway. i don't see you running dirtypcbs for this.
<azonenberg> lol no this would be multech
<awygle> so are, what, 6mil traces actually a cost adder?
<rqou> which arm soc is this?
<awygle> i guess maybe tiny vias are...
<azonenberg> i'd be doing 4-5 mil, it's more the smaller drills and annular ring
<azonenberg> rqou: osd3358
<azonenberg> 256 ball 1.27mm multi-die package
<rqou> that's 1.27?!
<rqou> that's weird
<azonenberg> has an am3358, pmic, buck converters, and 512 MB of DDR3L
<azonenberg> and 100+ passives
<azonenberg> it's really more of a SoM in a BGA form factor
<rqou> yeah i know about it
<azonenberg> They made it 1.27mm because the package had to be that big anyway
<gruetzkopf> ah!
<azonenberg> no point in having smaller pitch
<gruetzkopf> BBBOAC
<azonenberg> Yeah
<azonenberg> I was planning to use it as basically a ssh-to-uart bridge
<azonenberg> and probably implement the CLI command processor there too
<azonenberg> and use a binary uart protocol for register writes
<azonenberg> or maybe i2c/spi or something, i havent decided - but something
<gruetzkopf> i really like the am3358, even as a baremetal arm chip
<awygle> in ls -l , "rws" means "setuid" right?
<azonenberg> pretty sure, yes
<gruetzkopf> it's still a fast microcontroller, not a "i heardyou like clocktrees, so we put clocktrees in your clocktrees" mobile AP
<azonenberg> gruetzkopf: yeah
<azonenberg> i was planning to use linux just b/c i dont know of a good bare metal ssh server
<azonenberg> and i trust openssh more than some random ssh stack on github
<azonenberg> it will be completely outside the packet datapath and, in fact, not even have access to the switch fabric whatsoever
<gruetzkopf> yep
<azonenberg> all datapath will be in the kintex
<gruetzkopf> control plane separation is a good thing
<azonenberg> And a physically separate RJ45 for the management interface
<gruetzkopf> ^
<azonenberg> Going to a dedicated RGMII PHY
<azonenberg> The RGMII bus will be proxied through the kintex in order to allow me to implement a hardware firewall in front of the management engine
<azonenberg> But my RTL won't have any connection between that and the fabric
<azonenberg> Basically the kintex will simultaneously be a 24+4 port switch
<azonenberg> and a 2-port firewall
<gruetzkopf> i really need to mess with my hp stuff, and see if i can get at the 10GE links that are not populated
<azonenberg> But for now i still have to finish the line card
<azonenberg> gruetzkopf: you've seen the pics i tweeted of that?
<gruetzkopf> a few, yeah
<azonenberg> So yeah working on tweaking power planes until $boss gives me something to do
<azonenberg> the joys of being a consultant in between gigs :p
<azonenberg> i actually sent them a research proposal to see if they'd let me do starshipraider as an official R&D project
<azonenberg> But no response yet
<azonenberg> it would certainly move a lot faster if i was doing it during $dayjob hours
<azonenberg> And it's something i would definitely use at the office on a daily basis
<gruetzkopf> yeah, proper switches definitly get to need out of the single-supplier situation
<gruetzkopf> the broadcom based one at cccac ate certain ipv6 packets..
<rqou> probably not broadcom's fault
<rqou> oh btw azonenberg you probably know this already but i don't trust the boot chain in TI SoCs either
<rqou> although it sounds like this is not a problem for you
<gruetzkopf> oh it was
<gruetzkopf> bug in their sdk stuff
<azonenberg> rqou: yeah my soc is going to be on a physically isolated management network
f003brv has quit [Ping timeout: 260 seconds]
<azonenberg> With a hardware firewall
<gruetzkopf> i have friends in the "put the whole computer inside epoxide" business
<rqou> gruetzkopf: ah, the sdk
<rqou> yeah, that I'm not surprised at all
<azonenberg> yeah i am not going that far b/c this isnt a HSM
<azonenberg> It's a switch
<azonenberg> if somebody is in your datacenter jtagging your fabric, you have much bigger problems
<azonenberg> My goal is however to make the management network safe against all possible attacks that come in on the main fabric
<azonenberg> if you dont have a physical connection between the management port and the fabric you can't touch it
<azonenberg> And since there will be no software or persistent state in the FPGA, there's nothing you can really pwn
<lain> we just need fpgaHAMMER
<lain> flip adjacent bitstream bits by hammering logic appropriately
<lain> :P
<azonenberg> lol
<azonenberg> actualyl xilinx has what they call the "isolation design flow"
<azonenberg> Which i read about briefly
<azonenberg> but didnt look at in great detail
<azonenberg> basically, it's a partitioning strategy that keeps X CLBs worth of unused space between two unrelated subsystems and blocks out the routes in those spaces
<azonenberg> To guarantee that no possible SEU or single silicon component failing short could lead to state leakage between the two domains
<azonenberg> meant for things like handling classified plaintext and ciphertext on the same FPGA
<azonenberg> it would likely guard against that
<azonenberg> lain: btw, i just got approval from my boss to work on starshipraider during work horus
<azonenberg> hours*
m_w has joined ##openfpga
<azonenberg> at least the io test board pending final approval of the whole project
<awygle> Wooo get money get paid
* awygle updates priors on "starship raider ever exists"
<lain> azonenberg: lol nice
<azonenberg> also it looks like i am going to have four power rails fed to this board lol
<azonenberg> 12v0, 2v5, vt, vcco
<rqou> hey, dumb verilog question
<azonenberg> ?
<rqou> if you declare both `output foo` and `reg foo` what happens?
<rqou> is that one thing or two different kinds of things with the same name?
<azonenberg> that's one thing
<azonenberg> But i dislike that style of declaration
<azonenberg> since verilog 2001 you can declare module foo(output reg bar);
<rqou> ok
<azonenberg> you can even (on FPGA or in simulation where "initial" is legal)
<azonenberg> do module foo(output reg bar = 0);
<rqou> nah, this is just output from write_verilog, not something i wrote
<azonenberg> to specify a C-style initializer
<azonenberg> ah ok
<rqou> hey azonenberg, whatever happened to "ida for hardware"? :P
<azonenberg> rqou: i still want to do it but my research proposal never got approved
<azonenberg> and i dont have time to do it outside $dayjob hours
<rqou> wait, wasn't it ioa that originally wanted you to do it?
<rqou> e.g. the hardwear.io talk and the deadline for it
<kc8apf> awygle: what was causing the time jumps?
<awygle> kc8apf: lots of things. primarily, we were using the busybox version of hwclock, which doesn't write adjtime
<kc8apf> ?!?
<kc8apf> Busybox needs to be burned to the ground
<awygle> and our filesystem of course was transient, so no matter what i did to set hwclock to use utc mode, it didn't persist on reboot and caused issues
<awygle> busybox hwclock _reads_ adjtime, it just won't write it
bitd has quit [Quit: Leaving]
<awygle> me before lunch: "it's impossible to safely fix this bug". me after lunch: "... oh, duh."
<azonenberg> rqou: yes, i was doing it for the presentation
<azonenberg> then i got pulled away to billable work
<azonenberg> My proposal for continuing the research has waited in purgatory ever since
<awygle> darn those billable customers
<azonenberg> Now that i'm on the bench again, 8 months of nonstop billable work later
<azonenberg> the project hasnt been signed off but i have to do something
<azonenberg> the iob board is a fairly well defined step towards the project
<rqou> you should figure out a way to make your friggin house into billable work :P
<azonenberg> LOL i wish
<rqou> have you gotten it inspected yet?
<azonenberg> We're down to one side of a handwritten notebook page
<azonenberg> for our checklist of electrical work to finish
<awygle> surely the end is in sight
<rqou> wtf why still not done?
<awygle> checklist items never hide unbounded amounts of work
<azonenberg> "finish cable trays"
<azonenberg> is one line :p
* awygle is feeling very "up" after lunch, wondering what his blood sugar is
<azonenberg> Downstairs hallway with a bunch of the drops from the tray to second-floor circuits
<azonenberg> http://thanatos.virtual.antikernel.net/unlisted/DSCF4535.JPG my future soldering / PCB bringup bench
<rqou> i thought you were supposed to be done by now?
<azonenberg> rqou: I'm doing it as fast as i can and that's all there is to it
<rqou> seems like barely anything has happened
<azonenberg> rqou: we lost most of a day to the dumpster thing, ~2 hours to the leaking sump pump drain
<azonenberg> little things add up
<azonenberg> the most recent is when i realized my fire alarm boxes were too full
<rqou> too full?
<azonenberg> having two 4-conductor+ground wires plus a device on the box in a 1.25" deep octagon box puts you over the NEC capacity limit
<azonenberg> So i had to add extension rings to the front and move each box up 1.25" to get the necessary volume
<rqou> huh
<azonenberg> The code specifies how many cubic inches of box space you need per conductor
<azonenberg> to prevent overheating and allow room to work
<azonenberg> overheating isnt really a concern with a fire alarm circuit but #14 wire is still theoretically capable of passing 15A
<rqou> oh you mean they discourage tetris-ing wires into a box?
<azonenberg> So they make you size the box to handle the current dissipation from four splices each passing 15A
<rqou> :P
<azonenberg> I'm trying to find these issues NOW
<rqou> so all of those photos online of boxes that have like 50 wires in them are all noncompliant?
<azonenberg> rather than when the inspector sees it, fails it
<azonenberg> and makes me pay for a second inspection a day or two later
<azonenberg> This is the calculator i use
<azonenberg> its easier than parsing all of the formulas in the code and doing the algebra with a pencil
<azonenberg> And from the few double-checks i've done by hand it's accurate
<gruetzkopf> here in germany it's box tetris land
<azonenberg> So if you plug in the calculations, say a wall box in the middle of a run with two outlets and a 2-conductor #12 wire coming in each side
<rqou> oh azonenberg did you sweep the floor again? just noticed it looks a lot cleaner in these photos
<azonenberg> and a #12 grounding conductor
<azonenberg> you need 20.3 in^3 minimum
<azonenberg> I normally use 2.125" deep 2-gang boxes which are 30.3 in^3 and gives me a bit more space to work
<azonenberg> but a 1.5" deep box would be legal there too
<azonenberg> however if i were to have a T in the run, say to hook up to the cable tray or to put an outlet higher on the wall
<azonenberg> i'd need 24.8 in^3 which would require the larger box
<azonenberg> easier to use them everywhere than do the math every box
<gruetzkopf> a 75*75*40mm box is good for 6 connectors and 18 conductors at 1.5mm² cross-section
<azonenberg> And i dont think we swept again but we did more vacuuming
<gruetzkopf> 5 and 15 at 2.5mm² wire crosssection
<azonenberg> gruetzkopf: you also run 240V though
<azonenberg> so current is a lot lower
<gruetzkopf> 1.5mm² is rated at 16A here
<rqou> so azonenberg, no future 300VDC wiring? :P
<rqou> (wow, very arc hazard)
<azonenberg> rqou: lol, no
<azonenberg> the only DC wiring i have planned will be 48V
<gruetzkopf> that's pretty much the normal breaker size here
<rqou> but much current
<gruetzkopf> i do have -24V and -60V wiring here
<rqou> i would expect 300 VDC to come from a solar array btw
<sorear> be the MBTA and wire all of your lighting for 600VDC
<rqou> which i guess isn't too useful in the PNW
<azonenberg> rqou: all of my 48V stuff will be fairly low current, i'd only use it for FPGAs and servers
<azonenberg> probably 1-2 kW max
<rqou> sorear: be German and run your trains off of 16.7 Hz AC (is this right, gruetzkopf?)
<gruetzkopf> my connector block of choice is wago 2273 series
<gruetzkopf> yep
<gruetzkopf> legacy from times of brushed, series-wound motors
<azonenberg> rqou: re the house we actually checked off 25+ items on the checklist over the last day or two
<gruetzkopf> wago 221 is great if you have to mix with multi-strand or many-conductor wiring
<azonenberg> all of the garage and office circuits needed power feeders, there was lots of data conduit for them
<azonenberg> we did the other data conduit for the master bedroom
<azonenberg> hooked up risers from almost the entire second floor to the cable tray
<gruetzkopf> USA likes metal conduits?
<gruetzkopf> over here https://upload.wikimedia.org/wikipedia/commons/5/5d/Wellschlauch.jpg stuff like this is extremely common
<azonenberg> That looks very similar to what we'd call ENT (electrical nonmetallic tubing) aka Smurf tube because the most popular brand is blue
<azonenberg> It's very common for data applications, while it's legal for power it's less commonly used for that purpose
<azonenberg> i'm using it for all of my data runs, as well as a couple of power runs where i needed some unusual mix of conductors e.g. for a 3-way light
<gruetzkopf> also, our earth conductors are also double-isolated
<azonenberg> what do you mean?
<gruetzkopf> gn/ye conductor is earth, br live, bl neutral
<azonenberg> oh so you mean the earth is insulated inside the outer jacket?
<gruetzkopf> yes
<azonenberg> yeah our NM cable doesn't have that however the armored cable i'm using now does
<azonenberg> technically "metal clad" aka type MC
<azonenberg> type AC, the older armored cable, had a bare grounding strip that shorted to the outer jacket and the jacket actually carried current
<gruetzkopf> in this house there's a bit of metal-clad cable
<azonenberg> in a fault
<azonenberg> This is what i'm using in my house
<azonenberg> both with aluminum armor
<rqou> have i told you about my ground wire in my apartment?
<azonenberg> one is a black live / white neutral / green ground cable, 12 AWG (rated for 20-25A depending on temperature) that i use for general circuit wiring
<rqou> it originates in the kitchen
<rqou> goes alongside the stairs
<azonenberg> The other is black live / white neutral / green ground / red interconnect / blue unused (couldnt find any cables without the 4th conductor)
<azonenberg> used for fire alarm circuits
<rqou> eventually goes around some doors
<azonenberg> and has red-painted armor to allow instant ID
<rqou> goes through a gap in the door that exists because the house has settled over the past decades
<gruetzkopf> there's also 3-wire cable which doesn't carry earth, which is the correct one for a switch drop, though 5-conductor cable is usually cheaper ;)
<rqou> then, because i didn't want to take up valuable floor space, it's stretched over to a post on the bed
<rqou> where it makes a few more turns
<gruetzkopf> 12AWG is something like 3.3mm²?
<rqou> and finally connects to the ground tab of a cheater plug
<rqou> :P
<azonenberg> gruetzkopf: i'm using metal boxes everywhere
<azonenberg> and no matter whats in the box, even if it's just a splice pointc
<azonenberg> code requires the box itself to be grounded
<gruetzkopf> ah, 99% plastic here
<azonenberg> That's the de facto standard here for residential work
<azonenberg> I'm building this place closer to commercial standards
<azonenberg> If you're using metal conduit or metal jacketed cable the boxes have to be metal
<azonenberg> because you have to bond the conduit or armor to ground
<azonenberg> and while the fittings are conductive, if the box isnt conductive you lose your bonding
<azonenberg> i guess somebody might make a fitting with a screw terminal that you can use to bond cable armor around a plastic box but i've never seen such a thing
<gruetzkopf> ah, the standards are not that really different between residential and commercial here
<azonenberg> (conversely, putting plastic jacketed cable or plastic conduit into a metal box is totally legal, as long as the cable contains a grounding conductor you can connect to the box)
<azonenberg> Most commercial buildings use metal-clad cable or conduit
<azonenberg> while most residential work is plastic sheathed multiconductor cables just stapled to the studs
<azonenberg> Also, most commercial buildings here are steel/masonry framing and most residential are wood frame
<rqou> azonenberg: what about illegal K&T retrofits? :P
<gruetzkopf> people here really dislike stapling cable
<azonenberg> rqou: all bets are off with un-inspected work :p
<azonenberg> gruetzkopf: for the MC cable i'm using, i use ? shaped metal clips
<azonenberg> that you screw in on one side
<azonenberg> they can't overtighten because the clip will just bend
<azonenberg> if there's excessive force on the wire
<gruetzkopf> plastic clips, nailed
<azonenberg> And they're a lot easier to remove than a staple or nail if you need to do renovations later
<gruetzkopf> or installed in solid plastic conduit
<gruetzkopf> metal or plastic conduit is usually mounted with https://www.obo.de/produkte/verbindungs-und-befestigungs-systeme/rohr-systeme/quick-pipe-system/quick-schelle-lichtgrau.html stuff like this here
Bike has quit [Ping timeout: 260 seconds]
<gruetzkopf> https://images.obi.de/product/HU/415x415/316667_1.jpg bare cable with clips like these
<awygle> i approve of armored cable because then i won't accidentally drill into it and fry myself
<awygle> this has never happened, and i know the general ways to avoid it happening, but that doesn't stop me from being paranoid every time i drill into a wall
<azonenberg> awygle: it's far from drill proof, but better than romex
<azonenberg> Code does have some further protections against it though
<awygle> it's not drill *proof* but it's drill "holy shit wtf was that?!!?!?!?!"
<azonenberg> in particular, you're not allowed to have any wire, armored or not
<gruetzkopf> and for *big installs* https://i.ytimg.com/vi/TcOsblJskx8/maxresdefault.jpg these are common
<azonenberg> less than 1.25" from the face of a stud
<awygle> by which i mean, you'd have to really try to drill into it without noticing
<azonenberg> If you have to, because you're doing multiple wires on a stud or something
<azonenberg> you need to put a 1/16" steel plate over the stud
<azonenberg> Which, unlike the cable armor, is actually considered relatively drillproof unless someone is really trying
<azonenberg> You dont need plates in between studs for two reasons
<azonenberg> first, most people drill into studs to hang things and there's less of a reason to drill between studs (unless you use drywall anchors which are non-conductive)
<azonenberg> Second, the wire between studs is relatively free and if you hit it with a drill you'll probably just push it out of the way
<azonenberg> vs on a stud it's either run through a hole or clamped down and will probably have nowhere to escape
<awygle> i make no claims that my paranoia is rational :p
<awygle> if it was, it wouldn't be paranoia
<azonenberg> Well, i'm just saying the people who wrote the code considered the situation
<azonenberg> What the armor *is* good for is a couple of things
<azonenberg> rodentproofing is a big one
<gruetzkopf> cardboard home construction is still pretty unusual here
<azonenberg> it also does provide some protection against drilling etc, yes
<azonenberg> also the outer shell is nonflammable
<azonenberg> So in the event of a fire in the surrounding area, it's less likely to spread the fire and won't release much smoke
<azonenberg> Which is one of the reasons that romex is generally not allowed to be exposed (it has to be inside a wall behind sheetrock)
<azonenberg> while MC is allowed to be run in the open
<gruetzkopf> the big thing where residential and commercial code differ here is in flexible wiring for tools
<gruetzkopf> where commercial usage implies more resilient cable
<gruetzkopf> btw, if anyone has a source for three- or four- conductor telco patćh wire, i could use some..
Bike has joined ##openfpga
xdeller_ has quit [Ping timeout: 260 seconds]
xdeller_ has joined ##openfpga
gnufan1 has joined ##openfpga
digshadow has quit [Ping timeout: 256 seconds]
gnufan has quit [Ping timeout: 245 seconds]
<kc8apf> Gaffe's xc7 bitstream writing is all committed
genii has quit [Remote host closed the connection]
mwk has quit [Ping timeout: 240 seconds]
<awygle> huh, TIL about ANSI Y32.2-1975 / IEEE 315