futarisIRCcloud has joined ##openfpga
GenTooMan has joined ##openfpga
<rqou> so, i just discovered a fun side-channel leakage from the computer I'm currently using
<rqou> afaict the usb control causes audible "inductor-noise-like" sound emissions when i transfer a lot of packets over it
<kc8apf> and the library is live: https://crates.io/crates/gaffe-xilinx
<awygle> woo you're official!
<sorear> I take it s6 does _not_ use a similar configuration protocol?
* sorear should read a s6 datasheet
unixb0y has quit [Ping timeout: 256 seconds]
<rqou> s6 is understood enough that someone could pick it up and build a toolchain
unixb0y has joined ##openfpga
<rqou> the only problem is that nobody wants to do the work to clean everything up
<rqou> especially given that like azonenberg said it's the windows me of Xilinx
<rqou> s6 has actually been understood enough to build some kind of toolchain for like five years
<rqou> except the docs were always a ginormous mess
<sorear> Presumably this will be easier once vtr is in shape
<rqou> you can always try writing your own vtr description
<rqou> no, but that sounds pretty neat
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
GenTooMan has quit [Quit: Leaving]
<sorear> that's what i'm saying, writing a vtr description will hopefully be easier for interested parties than writing a whole toolchain
digshadow has joined ##openfpga
<kc8apf> sorear: everything up to configuration frames is very similar in s6. Big changes are word size is 16-bit instead of 32-bit and frames are a different length.
<kc8apf> awygle: then there's https://github.com/nebulet/nebulet
<rqou> wow, this fuzzer is slow
<rqou> it's still going
<rqou> hrm, 54 R4s going into a LAB
<rqou> coupled with 37 unique C4s fuzzed from last time
<rqou> that's 91 unique inputs
<rqou> coupled with some unknown number of neighbor LABs
<rqou> maybe only 5?
<rqou> that would yield 96 unique inputs for LAB
<rqou> each LAB has inputs from both the C4 column to the left and to the right
<rqou> but only inputs from the R4 column that according to the coordinates is above
<rqou> this further "does not refute" the speculation that rows physically exist in the middle of each tile
<rqou> rather than between tiles
<rqou> i am increasingly of the opinion that all fpga RE should in the future begin with die images
<rqou> and counting all the resources
<rqou> offtopic rant: i really need to get my father to use better passwords
<rqou> (yes, despite being a "computer person" he has terrible password habits)
<rqou> let's just say that most of the passwords are a simple concatenation of two dictionary words and is a very "1990s" password (in the sense that that was when it was first being used, in the sense of the amount of entropy in these words, and in the sense of "words that would be likely to be chosen by a 'tech'-ish person in the 1990s")
<rqou> (this rant triggered by me connecting a device to the wifi (which i will eventually reconfigure as i work on moving out of berkeley))
<mietek> any KiCAD experts?
<rqou> azonenberg is an occasional kicad dev
<rqou> i've used it but wouldn't call myself an expert
<mietek> actually I just need someone who’s not a complete noob like me
<mietek> when editing a part: is it really not possible to edit properties for multiple pins at the same time? e.g. change from input to output
<mietek> is it really not possible to visualise pin type? e.g. input or output
<rqou> you can always edit the data files in a text editor :P
<mietek> thanks for not telling me that it’s open-source and I can also fix it myself
<openfpga-github> [libfx2] whitequark tagged v0.2 at master: https://github.com/whitequark/libfx2/commits/v0.2
<mietek> I’m just fascinated, as a newcomer, what must be the level of Stockholm syndrome
<rqou> "it's open source and you can always add the features you want yourself" :P
<rqou> but yeah, kicad internally is really really bad
<mietek> when editing a schematic: does moving components really not move attached wires together with the components?
<rqou> especially the schematic parts
<rqou> um, i think there are two modes?
* qu1j0t3 hopes mietek never has to use AWS Console
<rqou> yeah
<mietek> qu1j0t3: I did and I kinda hated it, but this is RSI-inducing already
<rqou> M - move just the part
<rqou> G - move the part and the wires, but the wires will move naively
<rqou> unfortunately there is no mode that moves wires intelligently afaik
<mietek> whew! that’s still better than noting, thanks
<mietek> how could I have discovered G?
<rqou> press ?
<mietek> oh.
<mietek> thanks.
<mietek> OTOH the OpenGL for editing footprints is nice
<mietek> I wish the part and schematic editors also did OpenGL
<rqou> opengl mode is a complete rewrite
<rqou> yeah that's coming Soon(TM)
<mietek> cool
<rqou> the joke name i've been giving it is eeschema-new
rohitksingh_work has joined ##openfpga
<rqou> but yeah, kicad internally is a disaster
<rqou> wow whitequark you actually tag versions? :P
<openfpga-github> [libfx2] whitequark tagged v0.3 at master: https://github.com/whitequark/libfx2/commits/v0.3
<rqou> whitequark doing real software engineering rather than just "herp derp use master" :P :P
<whitequark> lol
<awygle> https://github.com/jonpe960/ufsm/tree/ufsm-0.1.0 this is cool. Something I wanted badly like, three years ago.
<rqou> wut
<rqou> i've never needed diagrams like that
<mietek> GraphViz can do this, too
<awygle> The diagram is not the thing, it's just a visualization. State charts/hierarchical state machines are awesome.
<awygle> A very good way to structure most small-to-medium embedded systems
<rqou> hmm wait, i just noticed something
<awygle> mietek: yeah but that doesn't like, output C code, does it?
<rqou> afaict there are no R4 wires that claim to "originate" from the io tiles
<rqou> so now i once again can't seem to understand how the numbers add up
<awygle> Lol
<mietek> awygle: ah, I misunderstood
<mietek> awygle: I thought this was just a visualisation library
<awygle> You should have started with a bigger part
<rqou> 704 total R4s over 4 rows means 176 R4s per row
<awygle> You're all edge cases
<rqou> somehow these need to be split among 6 tiles
<rqou> the larger part isn't even that much larger
<rqou> and it has other fun like having a big corner missing
<kc8apf> I've used http://smg.sourceforge.net/smg_guide_nf.html when I needed to do complex state machines
<awygle> We used https://www.state-machine.com/qpc/ and their tools at PRI, iirc
<awygle> But I wasn't software there
<awygle> I'd like to see hsm/SC done in Rust with the "state transitions encoded in the type system" trick
<mietek> does the OpenGL view in the PCB editor have a dark-on-light mode?
<mietek> basically, can I invert the default colour scheme
<kc8apf> apparently that's how await/async is going to work. It expands the call site into a small state-machine.
<rqou> wow tinyfpga's boards look pretty nice
<rqou> mine always seem to be covered with gross flux that azonenberg hates as well as bodge wires
<rqou> ok, based on some of the indices i've been observing the new hypothesis about R4 tracks is that each cell originates 16 left and 16 right
<rqou> except one of the cells is somehow missing some wires
<rqou> 32*6*4 is 768 but we're only supposed to have 704
Bike has quit [Quit: Lost terminal]
<rqou> we can get 704 by (32*5+16)*4
<rqou> so now the question is just "where did the 16 missing wires per row go?"
<rqou> probably at the edges?
<rqou> hrm, R4 wires seem to somehow be in groups of 8
<rqou> not sure exactly how
<rqou> also, afaict the coordinates for C4 wires get clamped at Y=0 (inside an IO tile) but R4 wires get clamped at X=2 (not inside an IO tile)
<rqou> i wonder what's up with this coordinate system?
digshadow has quit [Ping timeout: 245 seconds]
<rqou> so the logic cell at the bottom of a column only has 32 unique C4->LAB pairs it seems?
<rqou> whereas the others had 64
<rqou> huh, i'm not getting a consistent number of C4->LAB unique connections
<rqou> *R4->LAB
<rqou> i'm getting 128, 131, 130, 130
<rqou> ok, fuzzing isn't _quite_ done yet but i'm pretty certain now that the bits i guessed the other day control LAB inputs
<rqou> 16*4*2=128 total bits to control LAB line inputs
<rqou> what doesn't make too much sense is that this isn't divisible by 26 in any way
<rqou> ok, fuzzing more (actually less) accurately seems to be showing that some of those bits are not actually part of it
<rqou> 112 bits to control LAB inputs?
<rqou> the problem is that none of these are divisible by 26 wtf
<rqou> ping azonenberg
<azonenberg> back
<rqou> what do you think is going on here?
<azonenberg> I dont think i can be of much use without actually spending a lot of time getting familiar with the architecture
<azonenberg> Time i don't have right now
<rqou> nah, i just need shots in the dark :P
<rqou> right now my problem is "there are no multiples of 26 that fit nicely with the observed data"
<rqou> anyways, is it possible not all of the local tracks have the same amount of connectivity?
<rqou> hence not the same number of control bits?
<azonenberg> i would expect the edges of the array to vary
<rqou> that seems a bit too weird, doesn't it?
<rqou> no, this isn't at the edge
<azonenberg> It's also very likely that not all of the local interconnect lines are the same
<azonenberg> one particular line might only be able to connect to (say) half of the other ones
<rqou> "very likely?"
<azonenberg> Just like the ZIA, what matters is that the *set* of routes always be achievable
<rqou> seems quite weird
<azonenberg> a full crossbar would be huge
<rqou> oh, this part of the interconnect already has plenty of weird shuffling options
<rqou> also, the interconnect i've observed so far is suuuuper sparse
<rqou> is that normal?
<rqou> e.g i was fuzzing row interconnect into tiles in a particular column earlier
<azonenberg> that makes sense
<rqou> and at every tile in the column the _total_ unique observed row interconnect wires is 216
<rqou> out of 704
<rqou> that's normal?
<rqou> why are there _so many_ wires in an fpga
<rqou> is this also normal?
<rqou> why don't they teach anything like this in class? :P
<azonenberg> lol
<azonenberg> sec
<rqou> imagine: fpga class that uses icestorm as reading material
<azonenberg> sooo to give you an idea
<azonenberg> a 7 series CLBLM
<azonenberg> has something like 91 connections to fabric routing resources
<azonenberg> at the input
<azonenberg> (that was a rough count in the vivado floorplanner so i could be off by a few)
<rqou> ok, OOM is similar in max v
<rqou> heh i also measure 91 :P
<rqou> um, which parts are programmable/hardwired?
<azonenberg> The two switch boxes are programmable
<azonenberg> with all the diagonal lines
<rqou> everything else is fixed?
<azonenberg> Then the vertical and horizontal routes are just nets between interconnect tiles
<rqou> huh so both xilinx and lattice seem to use the "big switch box next to a slice" design
<azonenberg> this is the legal set of connections for one particular input to a switch box
<rqou> whereas siliconblue and altera seem to use multiple sets of switch boxes with local tracks in each tile
<azonenberg> As you can see, sparse
<rqou> why are there those wires on the right that don't go anywhere?
<rqou> or the two wires going into the funny box?
<azonenberg> I dont know what the nulls are, this is 2 mins of poking around in vivado
<azonenberg> The funny box is a "tieoff" module
<azonenberg> that supplies constant 0 and 1 to the switch box
<rqou> wut
<rqou> does that actually exist in the silicon or is that a logical concept for the toolchain?
<azonenberg> I imagine there is a way to pull nets to a constant value
<azonenberg> but its probably in the switch box and not dedicated hardware
<azonenberg> This is very much a stylized rendering
<azonenberg> For example in spartan3a, they show the ram on one side of the dsp slice in planahead
<azonenberg> while die analysis shows the columns are in the opposite order :p
<rqou> oh really
<rqou> i never knew that :P
<azonenberg> In reality, the software treats the two as kinda one attached element, spartan3 bram and multiplier share some routing resources
<azonenberg> i think you have to have the ram in SDP mode if you use the mult, TDP blocks the mult
<rqou> i did vaguely know that
<azonenberg> and there's some local paths to do multiplies on the ram data or something
<azonenberg> idk, its been a while since i've worked with s3
<rqou> anyways, do you know of any pros/cons of the "big switch box and small tiles" archs vs "multiple types of switches and long tiles" archs?
<merskiasa> Can anyone tell me why I am getting errors in the decoding with the software of my Saleae logic analyzer? https://pastebin.com/4QjGhYGL here are the .logicdata files: https://www.sendspace.com/file/dd2ju6
<rqou> wait a sec
<rqou> azonenberg: the xilinx die photos on pr0n show rather tall tiles too?
<azonenberg> rqou: which chip?
<rqou> hmm maybe i misremembered, let me double check
<azonenberg> s3 is almost square
<azonenberg> A DCM and {MULT18x18SIO + RAMB18BWER} are each the same size
<azonenberg> namely, four CLBs wide and four high
<merskiasa> Anyone?
<azonenberg> the aspect ratio of a CLB seems to be about 20% wider than it is tall
<rqou> merskiasa: sorry, nobody here really uses saleae _that_ much
<azonenberg> In the XC3S50a...
<azonenberg> the actual array is 16 wide x 16 high tiles, however one entire block of 4 columns is eaten up by a DCM at the top then three RAM+MULT blocks
<azonenberg> So the CLB array is 12 wide x 16 high
<rqou> ok, i'm looking at the protected xc3s50a
<azonenberg> With a 4x4 cutout at the top just left of center
<azonenberg> For the second DCM
<azonenberg> Looking at the RAM/MULT tiles you can see the RAM is at right and the mult is left
<azonenberg> vs in planahead they're swapped
<rqou> is this the protected one?
<rqou> i'm looking at the protected xc3s50 (no a)
<azonenberg> no i'm looking at the a
<azonenberg> Then the standard cells in the bottom right are presumably the boot/jtag etc logic
<rqou> is a vs e vs nothing very different?
<azonenberg> This is the unprotected azonenberg:xilinx:xc3s50a
<azonenberg> there are uarch changes, i forget all the details
<azonenberg> i think they're all the same process
<rqou> ah ok i was looking at the mcmaster one
<azonenberg> i have a delayer of the 3s50a on mine
<rqou> ah so this array is 16x16
<rqou> i thought it was smaller
<rqou> ok, so xilinx clbs really are squareish
<azonenberg> Yes
<azonenberg> But a CLB is two slices
<rqou> altera clbs are super tall
<rqou> wait, so it's CLB->slice->LUT?
<azonenberg> in older xilinx arches, pre ultrascale
<azonenberg> a CLB was two slices, each of four luts
<rqou> and post-ultrascale?
<azonenberg> One slice per CLB of 8 luts i think
<azonenberg> The slice is a logical group for some packing stuff, carry chain, and control sets
<rqou> ah ok
<azonenberg> So in say 7 series each CLB has two clocks, two set/reset signals, etc
<azonenberg> one per slice
<azonenberg> but all ffs in that slice have to use the one clock, the one set/reset, etc
<rqou> altera doesn't have (in their older archs) this three levels of hierarchy
<azonenberg> The switch box is dedicated to the CLB
<rqou> altera just has LAB->LE
<azonenberg> the other thing is, not all slices are created equal
<rqou> and altera LABs have multiple control signals and it's a big mess
<rqou> yeah i do know about SLICEL/M/X
<azonenberg> in spartan6, there were three types of CLB
<azonenberg> of slice*
<merskiasa> https://imgur.com/a/ZPzkJ are the 0V TP4X etc ICSP programming points on this remote? next to the battery
<azonenberg> Each CLB was a SLICEM plus either a SLICEL or a SLICEX
<rqou> merskiasa: almost certainly
<rqou> yeah the xilinx arch seems way more complicated for some reason
<azonenberg> 7 series killed SLICEX, thankfully
<azonenberg> that was one of the worst decisions they made in spartan6
<azonenberg> SLICEX had no wide muxes or carry chains
<azonenberg> Meaning 25% of your chip can't do addition or high fan-in logic
<merskiasa> rqou, what makes you think so?
<azonenberg> Now they only have SLICEL and SLICEM
<rqou> what did that gain them?
<azonenberg> i.e. with and without bram
<daveshah> azonenberg: didn't know that, thats really weird
<azonenberg> Presumably SLICEX was a tiny bit smaller since a few less config bits
<daveshah> Never seen a slice without carry before
<merskiasa> rqou, and which would I use with pickit3 - which test point would I hookup
<daveshah> ECP5 is nice, one type of slice
<azonenberg> daveshah: like i said, spartan6 was xilinx's "windows ME"
<azonenberg> The architecture so bad they killed it
digshadow has joined ##openfpga
<rqou> merskiasa: just "the usual way hardware people tend to design things"
<azonenberg> and based everything subsequent on virtex
<daveshah> azonenberg: yeah, that makes like for use much easier :P
<rqou> merskiasa: you'll have to probe and find out which test point is what though
<daveshah> *us
<merskiasa> rqou, how do I know what testpoints to hookup with pickit3
<merskiasa> With what
<rqou> use a multimeter and compare against the datasheet for the pic
<rqou> azonenberg: so, thoughts as to why the xilinx arch seems so complicated?
<azonenberg> rqou: legacy? it seems like with 7 series and ultrascale they burned it all down and rebuilt it fairly sanely
<azonenberg> ultrascale is even more unified than 7 series
<merskiasa> rqou, the programming datasheet for tthe PIC or just the normal datasheet?
<rqou> it still feels like a lot more "stuff" going on
<daveshah> yeah, the Ultrascale arch is nice
<rqou> or maybe it's just because ice40/maxv don't have enough features :P
<daveshah> The garbage fire in the ecp5 are the DSPs
<daveshah> Some documents suggest there are DDR registers inside the DSP blocks
<merskiasa> rqou, doesnt 'TP' means 'Test Point'
<rqou> although ice40 has a nice and complicated AF routing fabric too
<rqou> yes
<azonenberg> rqou: try actually using a 7 series or ultrascale device for a real design
<azonenberg> and you'll appreciate the features
<rqou> daveshah: yeah? coolrunner-ii has ddr FFs in fabric too
<rqou> although it makes more sense here
<daveshah> IMO DDR registers in a DSP slice seems crazy
<azonenberg> yeah thats absurd
<daveshah> But the docs are so terrible I have no idea how or why you would use them
<rqou> it probably allows for clever "stealing" timing
<daveshah> The ecp5 DSPs are 2-3 times more complicated than a DSP48E1 but with half the documentation
<rqou> just why asic designers use latches and do clever retiming
<daveshah> The challenge with them won't be bitstream documentation, it will be writing documentation full stop
<daveshah> Lattice expect you to use inference or wizards rather than instantiating them yourself it seems
<azonenberg> daveshah: lol
<azonenberg> meanwhile, i cut my teeth on MULT18x18SIO
<azonenberg> These things could be async or sync
<azonenberg> in ASYNC mode it was literally 18*18 = 36 bit mult
<azonenberg> the registered version just added a 36-bit register, clock, CE, and reset
<rqou> oh is this the block in s3?
<rqou> i've used those too, nice and simple
<rqou> although i basically always used inference
<azonenberg> yes
<daveshah> yeah, that seems like a real nice and simple block
<azonenberg> oh ok they had a little bit more, they had optional registers on the inputs too
<azonenberg> So you actually had ce/rst on A, B, and output
<daveshah> unlike the ECP5 one where every single internal clock is also individually selectable
<daveshah> Just in case you want all your pipeline registers in different clock domains
<daveshah> It's also fracturable rather than a single block
<rqou> um...
<azonenberg> lol
<daveshah> Which should make packing/PAR harder
<rqou> yeah
<daveshah> Does have some nice features, like serially shifting coefficients between adjacent DSPs for filters
<rqou> altera's weird fracturability is going to be a pain too
<daveshah> Without needing general routing and logic
<rqou> oh btw i refuzzed and the bottommost tile is missing 8 C4 inputs
<rqou> it has 56
<daveshah> yeah, I'm not sure how well Yosys/ABC supports fracturable LUTs either
<rqou> what's interesting is that the resource count is _not_ missing anything
<rqou> i'm still going to have to keep investigating what is going on here
<rqou> daveshah: i'm probably just not going to even bother for general logic
<rqou> just map arithmetic into the fracturable luts
<sorear> ddr buffers on a dsp don't seem completely ridiculous, assuming they're inferred
<daveshah> rqou: yeah that seems sensible
<daveshah> Arithmetic is a special case and specified manually in the tech map anyway
<daveshah> sorear: I don't think they're actually supported by the tools in any way
<rqou> hrm
<rqou> i think i have a new guess for C4 wires
<rqou> since 14 up/down wires wasn't making too much sense
<rqou> i think it's 16 up/down wires just like there are 16 left/right wires
<sorear> it lets you make one multiplier look like two lower-fmax multipliers
<rqou> and that just some are missing at the top/bottom
<sorear> which is great if something else is limiting your fmax
<rqou> it was just a coincidence that 784 has more prime factors than 704
<daveshah> sorear: no, it's not like that
<sorear> mm
<rqou> this is since i see lots of stuff implying a grouping into 8
<daveshah> It's just dual edge registers internally
<daveshah> There's not full DDR input logic or anything
<daveshah> I think the option to enable it might be CLKx_DIV which is normally enabled
<daveshah> Presumably by default it divides clock by 2 if the internal registers are all dual edged
<rqou> lol
<rqou> that's exactly why coolrunner-ii has DDR FFs
<rqou> they even market it with some fancy name
<daveshah> I wonder if its STA actually copes with the dual edge mode or whether it catches fire
<rqou> CPLD STA is easy :P
<rqou> so that one probably works
<rqou> although the foss toolchain doesn't have STA
<rqou> because i've been lazy and didn't care enough
<rqou> you don't even have to fuzz anything
<rqou> just copy the timing numbers out of the datasheet
<rqou> they're all there
<rqou> btw the "RGH" bitstream has DDR mode set
<rqou> so that they can overclock the CPLD a bit
<rqou> :P
<rqou> this totally blew up the RE tools i was working on
<rqou> since i wanted to test them on a bitstream that i really didn't have the source code to
<rqou> but yeah, if you run a design with DDR FFs through our RE flow, yosys will actually hard abort and exit
<rqou> ooh shit
<rqou> azonenberg: i realized a feature that xc2par is missing
<rqou> the clock divider lol
<rqou> fortunately since there's only 1 i can just special-case it
<rqou> alright, i'm going to zzz since staring at the fuzzer doesn't make it fuzz any faster :P
Sinclair2 has joined ##openfpga
bitd has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
soylentyellow_ has quit [Ping timeout: 240 seconds]
afiskon has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
soylentyellow has joined ##openfpga
massi has quit [Ping timeout: 256 seconds]
massi has joined ##openfpga
<implr> azonenberg: for your switch, is there a particular reason why you're using a kintex + an arm soc instead of a big zynq?
genii has joined ##openfpga
<pie_> azonenberg, re: crypto thingy, maybe they were just trying to make a really fast rubiks cube solver
<pie_> totally missing context. I too should name all my children digital signal processor. https://twitter.com/samknight_one/status/1005080789091053570
ondrej2 has quit [Quit: Leaving]
Bike has joined ##openfpga
digshadow has joined ##openfpga
Sinclair2 has quit [Quit: Bye Bye]
digshadow has quit [Ping timeout: 268 seconds]
<rqou> hrm, total unique possible connections C4->LAB varies across tiles too
* awygle looks at rqou and daveshah, imagines quitting job to hack all day, sighs wistfully
<qu1j0t3> lol
<daveshah> awygle: pick a better day job :P
digshadow has joined ##openfpga
<awygle> daveshah: I *like* my job, it just gets in the way of hax
<awygle> Unfortunately sum(fpga license costs) is not >> my salary
<awygle> So "pay me to do prjtrellis" for example is not a compelling business case :-P
<daveshah> solution: embed malware in Diamond, claim Trellis is the only option
<awygle> Hmmmm
<daveshah> it is almost certainly possible to come up with an edge case that Diamond fails to synth but Yosys allows
<daveshah> then say Diamond is blocking your work :P
<awygle> Lord knows that's true lol
<daveshah> if you use LSE it certainly is
<awygle> Doesn't even have to be that edge :-P
<daveshah> Synplify to some extent, but I haven't really isolated a particular issue per se
<daveshah> just weird crashes on big/odd designs sometimes
<awygle> Oh but we use VHDL. Bummer.
<daveshah> even more work then
<daveshah> I had a design in VHDL that Diamond synthesised fatally badly
<daveshah> it was a motor controller state machine, and it optimised away the deceleration part
<daveshah> checked in every other tool and it was fine, so I'm pretty sure it was a LSE bug
<daveshah> to be fair, if you buy a verific license, you can use Yosys with VHDL already
<azonenberg> implr: a bunch of reasons
<azonenberg> first off, the soc i'm using has integrated ram
<azonenberg> it's like 5 dies wirebonded on a single substrate (arm, lpddr3, ldo, buck, eeprom)
<azonenberg> plus 100+ passives
<azonenberg> If i went with a zynq i'd have to do all that layout myself
<azonenberg> second, in order to fit the number of GPIOs I need on the FPGA side, while also having a DDR3 bus and another RGMII interface
<azonenberg> i'd have to go with an xc7z035 in FFG676 or even FFG900
<azonenberg> or possibly the Z030 in FFG676 but that would really be pushing it
<azonenberg> The z035 is, i think, not supported by free vivado
<azonenberg> the z030 is $420 on digikey vs the $260 FPGA + $30 SoC I'm using now
<azonenberg> A 676-ball FPGA would also use more PCB layers to fan out
<azonenberg> The brain board is PCB area constrained and the multi-die arm module is significantly smaller than equivalent packaged components
<azonenberg> Finally, on the security front i dont like zynq's architecture of having the arm be in charge of everything and manage the boot process etc
<azonenberg> If it was like the old virtex2pro where there was just a cpu thrown off in a corner with the bus going out to fabric, and the cpu didn't have access to the ICAP or anything
<azonenberg> and i could boot the fpga first without the arm, etec
<azonenberg> Then i might consider it
<azonenberg> but i really dont like the way xilinx has the cpu be the boss of everything, i build systems where the FPGA brings up the ARM and not the other way around :p
<pie_> arm slavery
digshadow has quit [Ping timeout: 264 seconds]
<awygle> azonenberg: you seem like you'd know about ear protection. is there a good solution which blocks *both* high *and* low frequencies?
<azonenberg> Low frequencies are actually harder because they go through bone conduction etc better
<azonenberg> Power tools are moderate to high frequency
<azonenberg> Hammering and gunfire are what i use ear pro for most, which is basically a series of Dirac impulses
<azonenberg> Super fast rise time single impulse then some ringing after
<azonenberg> and helicopters too i guess, which is basically a series of said impulses plus turbine noise
<azonenberg> awygle: what frequency range are you talking about? How powerful is the source / how long are you being exposed for?
<awygle> it seems like active noise cancelling is good for low frequencies (engine noise, air conditioners) and things like earmuffs are good for higher frequencies (people talking, etc)
<azonenberg> (And how many dB of attenuation do you want?)
<awygle> azonenberg: i'm just in the office. i have an air conditioner right above me that oscillates wildly all day and a cubicle neighbor that doesn't understand phone courtesy. i'm not target shooting or anything.
<azonenberg> ah ok so this is for distraction removal?
<awygle> i have earmuffs but then it sounds like i'm in a plane, the LF of the AC is constantly rumbling
<awygle> and i have noise cancelling headphones but then i can hear people just fine
<awygle> yeah distraction and i'm pretty sure the oscillating AC is bothering my tinnitus
<azonenberg> Personally, i'd go for a nice set of over-the-ear headphones with active noise canceling plus your music of choice
<azonenberg> If you just wanted absolute silence, you could go with insertable earplugs and then noise canceling headphones over that
<azonenberg> Which should give you 30-50 dB attenuation across a very wide frequency band, but i find insertable plugs unpleasant to wear for a long time and total auditory deprivation might get annoying after a while
<awygle> yeah, i hate insertables :/ okay well, thanks for confirming my options
<azonenberg> Idea: music with foreign-language vocals
<azonenberg> a language you don't know, that is
<awygle> yeah my jpop playlist is invaluable
<azonenberg> It drowns out the frequency bands of human speech nicely, while not taking much brainpower to process vs a language you know
<azonenberg> i've become a fan of Ukrainian techno for that purpose
digshadow has joined ##openfpga
<azonenberg> as i know about five words of russian :p
<azonenberg> But a good set of over-the-ear headphones is helpful too, you'll get some attenuation that way
<azonenberg> If you have active noise canceling, then just rely on the music to reduce the SNR
<azonenberg> you should be set
* awygle scrolls and scrolls and scrolls to get into his budgetary range
<azonenberg> personally i dont have much trouble working with music going and a relatively cheap pair of Sennheiser HD202's, which are not noise canceling but do fit snugly and block some sound
<pie_> song of my people https://imgur.com/gallery/WjojLUD
<pie_> comments: "audio gifs" siiiigh
* kc8apf has a pair of those I've used at work daily for a few years
<awygle> kc8apf: things ahead of that on my list - roomba, shop-vac, rack-mount kits, new car
<awygle> maybe i can talk the company into buying them for me as a bonus or something :p
<kc8apf> real talk: HD202s are cheap and great.
<awygle> pie_: what else would you call that? there's moving pictures, and also sound! i can't think of a single thing that could be other than an audio gif
<awygle> yeah i'm thinking 202s or maybe that monoprice one. i generally like the point on the price/performance curve monoprice occupies.
<awygle> i don't care that much about the actual _audio_ so *shrug*
<azonenberg> me and $wife have used hd202s for years, i'm on my second pair after the first broke
<azonenberg> (fatal accident with a rolling desk chair iirc)
<awygle> I've never owned a pair of headphones for more than like, eighteen months
<awygle> I am hard on my stuff apparently
<kc8apf> awygle: interestingly I've heard that a lot. When I give people a good set of speakers, they suddenly care a lot more.
<azonenberg> i'm on my second pair since... 2010?
<qu1j0t3> awygle: i've had my AKG's for.. 13-odd years...
<azonenberg> of hd202s
ZombieChicken has joined ##openfpga
user10032 has joined ##openfpga
m_t has joined ##openfpga
digshadow has quit [Ping timeout: 256 seconds]
bitd has quit [Remote host closed the connection]
<awygle> do C ABIs specify struct packing?
<awygle> i seem to remember that C itself specifies some things but not everything
<awygle> though i could be wrong
<awygle> cool. this implies that screwing with packing with gcc's pack pragma or similar will violate the ABI and could break interop
<kc8apf> well, it's a bit more complicated
<kc8apf> I believe x86 alignment is defined but packing is not
<kc8apf> generally struct members will be naturally aligned with padding. pack pragma can force removal of the padding _or_ pad to even longer alignment
<awygle> hm. don't (e.g.) gcc and clang need to agree on packing though?
<awygle> in order to cross-link
pie_ has quit [Ping timeout: 264 seconds]
<kc8apf> yes. The defaults are consistent as are the results of applying pragma pack
<kc8apf> so, messing with packing can break interop but not necessarily ABI
<awygle> hm, okay. thanks :)
GenTooMan has joined ##openfpga
pie_ has joined ##openfpga
<rqou> at risk of causing moar drama, does anybody know why my entire birbsite timeline is currently talking/implying about self-harm?
<Bike> that chef who killed himself?
<rqou> ah ok, i guess i didn't hear about that
Bike has quit [Ping timeout: 260 seconds]
<gruetzkopf> Protip for german-speakers trying to drown out people with music: do not use danish, your German parser will constantly resync and then crash horribly
<gruetzkopf> (why do I feel like replacing SGIs SPIDER ASIC again (NumalinkII router)
genii has quit [Remote host closed the connection]
Bike has joined ##openfpga
m_t has quit [Quit: Leaving]
pie_ has quit [Ping timeout: 256 seconds]
user10032 has quit [Quit: Leaving]