<awygle> earlier i said futan, apparently i meant furan-- . oops.
<rqou> awygle: smolfpga?
<rqou> not hugefpga c3? :P :P
<awygle> rqou: i apologize to whitequark in the README :p
<rqou> didn't like hugefpga? :P
<awygle> well it's not huge is the thing
<awygle> it's quite unhuge
<rqou> true enough
<rqou> i just thought hugefpga c3 would be a funny name
<rqou> we should use it for a 7-series board or something
<rqou> e.g. a vu+ board
<rqou> although tbh i don't really "get" why tinyfpga b2 is getting so much hype
<rqou> luke valenty must be really really good at marketing to some specific groups
<awygle> "marketing at all" puts him head and shoulders above most projects lol
<awygle> that being said i'd be interest in hearing from tinyfpga about his efforts to succeed as a business
<rqou> the other day i was trying to "reverse engineer" why adafruit is so successful as a business
<rqou> but the only thing i could figure out was "there must be something i'm completely missing"
<awygle> is the oshstencils website super buggy for anyone else in firefox?
<awygle> i think adafruit succeeds because of how easy they make it to use their stuff for people who don't do traditional embedded already
<rqou> idk, i always find their products (and SFE's) annoying to use
<rqou> usually because of not exposing the options i want and exposing too many options i don't care about
<awygle> so the boards cost me 4.95 at oshpark, stencil 12.91, parts for 3 boards 43.99, so the net cost was about 20$/board. that's not bad.
<rqou> but then i guess i don't have much insight into how "people who don't do traditional embedded already" think
<awygle> yeah i bet you are like "i have this project let me find a part" rather than "oo cool part what could i build with it", which is my theory-of-mind for adafruit/sparkfun customers
<awygle> i could be wrong tho
<rqou> i mean, i do the "oo cool part" thing too
<awygle> i bet ladyada has given a talk or two on this somewhere
<rqou> usually those end up in the devkit pile after a short amount of time :P
<azonenberg_work> cr1901_modern: the large xilinx parts are a bit more sophisticated than that
<azonenberg_work> They're "2.5D integration"
<rqou> anyways, a good example of what i'm talking about
<azonenberg_work> not full 3D (multiple stacked active layers)
<rqou> i just went to adafruit's website and this product was featured: https://www.adafruit.com/product/2465
<rqou> i actually (failed) at designing basically exactly this a while back
<azonenberg_work> basically they make a super dense "PCB" on a ~65nm CMOS process (i dont recall the exact dimensions)
<rqou> (failed because it was my first kicad design after moving off of eagle)
<azonenberg_work> then bond a bunch of dies to it
<rqou> and it's _almost_ great
<azonenberg_work> these are a combination of FPGAs, SERDES, RAM, etc
<rqou> except that the config straps for the charger IC aren't exposed
<rqou> which is a fail
<azonenberg_work> altera actually is starting to do this too, their latest stuff has serdes off the main logic die on a separate die
<azonenberg_work> The interposer is completely passive wiring, no actual transistors afaik
<sorear> does that add a meaningful amount of latecy?
<azonenberg_work> There is a slight increase in latency from die to die but it's not that bad, i have a pair of xcvu9p's (which are 3 identical logic dies) and so far havent had problems making timing
<azonenberg_work> i mean you dont want to have super tight nets crossing boundaries
<azonenberg_work> As far as memory usage my biggest designs so far have used somewhere around 12GB of ram when par-ing but i'm far from max utilization
<rqou> azonenberg_work you need to be more like my father :P
<rqou> he got >95% lut utilization before (on a s3)
<azonenberg_work> rqou: i've pushed s3's that far too
<azonenberg_work> and s6's, i think i hit 98% on a 6slx25 (at ~25 MHz, it was congested as all heck)
<rqou> yeah no, iirc he was doing GigE
<azonenberg_work> the vu9p is big enough that the stuff i've run so far hasnt maxed it out
<rqou> on an s3
<rqou> at >95%
<azonenberg_work> I was too (on the s6) but the bulk of the system logic was at 25 MHz
<azonenberg_work> only the NIC was at 125
<rqou> the whole thing was a "NIC" :P
<rqou> let's just say the design started out at 40% utilization :P
<rqou> when prototypes were first ready
<rqou> and shipped at 60%
<rqou> and EOL'ed at >95%
<azonenberg_work> lol
<rqou> it was an "ethernet over legacy telco crap" product
<azonenberg_work> ... oh
<rqou> and the telcos kept asking for more and more monitoring etc. features
<azonenberg_work> eeeeew
<azonenberg_work> baseT ethernet is bad enough
* azonenberg_work is looking forward to a mostly-optical cable plant at his new house
<rqou> yeah, it was stuff like ethernet over T1, ethernet over sonet, etc.
<sorear> did it support t1 and sonet simultaneously and did it need to?
<azonenberg_work> Did he implement this?
<rqou> lol no
<rqou> sorear: no, those were different product lines iirc
<rqou> apparently one of their most popular products was a low-cost 10base-t over 8x T1 box
<rqou> so that telcos could run data services over all the wet string they had installed in the flyover states
<azonenberg_work> lol
<rqou> because in the US, due to physical size and (presumably) people having to maximize extracted profit, installing new wires is astronomically expensive
<rqou> see also: why does public transit suck a** in the US
gruetzko- has joined ##openfpga
jn___ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
brizzo_ has joined ##openfpga
dx- has joined ##openfpga
marcan_ has joined ##openfpga
brizzo has quit [Disconnected by services]
dx has quit [Disconnected by services]
dx- is now known as dx
brizzo_ is now known as brizzo
jn__ has quit [*.net *.split]
marcan has quit [*.net *.split]
Ellied has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
marcan_ is now known as marcan
Ellied has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
noobineer has joined ##openfpga
noobineer has quit [Ping timeout: 276 seconds]
noobineer has joined ##openfpga
pie_ has quit [Ping timeout: 256 seconds]
Marex has quit [Remote host closed the connection]
Marex has joined ##openfpga
jn___ is now known as jn__
noobineer has quit [Ping timeout: 260 seconds]
noobineer has joined ##openfpga
noobineer has quit [Read error: Connection reset by peer]
futarisIRCcloud has joined ##openfpga
noobineer has joined ##openfpga
kuldeep has quit [Quit: Its never too late!]
kuldeep has joined ##openfpga
digshadow has quit [Ping timeout: 276 seconds]
rohitksingh_work has joined ##openfpga
ym has quit [Ping timeout: 268 seconds]
noobineer has quit [Remote host closed the connection]
hackworth has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 240 seconds]
hackworth has quit [Quit: hackworth]
Lord_Nightmare has joined ##openfpga
hackworth has joined ##openfpga
Bike has quit [Quit: Lost terminal]
hackworth has quit [Client Quit]
digshadow has joined ##openfpga
<awygle> has anybody in here tried icestudio?
<rqou> is that the weird thing done by some group of Spanish-speaking devs?
<awygle> yes
<awygle> it's either an IDE or it does HLS, or both
<rqou> yeah, i have a very hard time figuring out what that group is trying to achieve because everything is in Spanish :P
* rqou wishes i knew ALL THE LANGUAGES
<rqou> wait awygle don't you know Spanish?
<awygle> somewhat. not as well as when I was younger. But I could probably read those pages yeah
* awygle should really spend some time brushing up on his Spanish...
* rqou should work on my Chinese, but everyone knows that's not happening. Just ABC Things :P :P
wpwrak has quit [Ping timeout: 264 seconds]
<awygle> I read the first 20 pages of Bunnie Huang's book and now I want to learn Chinese and move to Shenzhen....
<rqou> do it :P
<awygle> do your parents have an apartment to unload there too?
<rqou> no
<rqou> but you can commute from HK :P
* awygle can't even speak Japanese in any meaningful way
<rqou> (yes, this is actually not that unreasonable and usually takes _less_ time than commuting in the Bay)
<awygle> Huh cool
<rqou> (yes, a "cross-border-ish" commute can be faster than commuting in the Bay)
<rqou> (yes, the Bay is f*cked)
<awygle> Yup
<rqou> and yes, you can make this "cross-border-ish" commute by public transit (but the routing is currently a bit suboptimal, they're working on it)
<rqou> what a concept
<rqou> although if you do this as a us citizen you will quickly find that you'll have to explain why the f*ck you need a new passport so soon :P
<rqou> (every round you accumulate 4 stamps)
wpwrak has joined ##openfpga
<whitequark> awygle: well you can stay at my apartment i guess
<whitequark> if you don't mind a kitchen so disgusting that i never actually found it in me to clean it
<whitequark> whoever lived there before had an outstandingly poor taste in ceramic tile and architectural skills of a drunk badger
<whitequark> awygle: okay I can't find what I want
<whitequark> what I want is a level shifter that has OE inputs connected to a shift register inside
<whitequark> or rather DIR input
<whitequark> *inputs
<rqou> you can connect a level shifter with individual DIR inputs to a shift register :P
<whitequark> not really
<whitequark> most multi-bit level shifters have DIR inputs only on rough granularity
<whitequark> like 4 or 8 bits
<whitequark> so this will be a whole lotta packages
<awygle> What if 5V wasn't a thing?
<awygle> Makes this all a lot easier
<rqou> without 5V just slap on an XC2C32A or similar and be done with it
<awygle> do we have room for http://www.ti.com/product/tca9535 to control OEs.
<awygle> (or similar)
<awygle> That's one 1$ part
<rqou> btw if you only need 5V tolerance rather than 5V io and don't mind nrnd parts you can use an older cpld
<cr1901_modern> whitequark: You need a shift register interface to a level shifter with individual dir?
<awygle> Oh wait I see the issue
<awygle> Never mind
<rqou> wait, grouped dir control is perfectly fine for jtag?
<cr1901_modern> http://www.ti.com/lit/ds/symlink/pcf8574.pdf (I2C port expander. I don't think it'll work for your use case, but it gives some ideas?).
<cr1901_modern> "Each quasi-bidirectional I/O can be used as an input or output without the use of a data-direction control signal."
<whitequark> sigh
<marcan> ha, good old 8574
<whitequark> cr1901_modern: if you read the backlog you'll see that we've considered a lot of bidirectional expanders
<rqou> yeah, nobody likes bidirectional expanders
* cr1901_modern does
<whitequark> the bidirectional expander is still the next best option if I can't get what I like
<whitequark> rqou: XC2C32A doesn't yet have a working FOSS toolchain does it?
<rqou> define "working"
<rqou> i can blink LEDs
<whitequark> "at least as good as icestorm"
<cr1901_modern> whitequark: Okay, it was a few days ago but yes I see you did discuss it and I missed it, oops.
<rqou> dumb suggestion (I don't remember if this has been suggested already): have two "probe cards": one fast one with XC2C32A and one slow one with SLG46621
<rqou> only the slow one supports 5V
<rqou> also, definitely not as good as icestorm at this point
<rqou> icestorm is surprisingly polished
<whitequark> rqou: that doesn't fit through our expansion card pinout
<whitequark> which is bus blaster compatible
<whitequark> awygle: rqou: the main reason i don't just go for bidir level shifter
<whitequark> is because if we want to get >60 MHz with it
<whitequark> and at the same time support 1V8
<whitequark> we need to vary the FPGA I/O bank voltage
<rqou> why?
<awygle> Because at 1v8 it only gets 50 mhz
<whitequark> ^
<awygle> And vcca had to my
<whitequark> if not for this
<awygle> *had to be less than vccb
<rqou> why can't the fpga side be constant 3.3V?
<whitequark> I would just put a TXB0108 there
<rqou> oh
<whitequark> because that's how bidir level shifters work
<rqou> right
<whitequark> so we need two ADCs and three DACs
<whitequark> and logic to poll them
<rqou> anyways, I've been wanting to do a jtag thing (but with different design goals than you) and I'd probably go with the fast and slow probe card idea
<awygle> whitequark: what about http://www.onsemi.com/PowerSolutions/product.do?id=CS8182 to avoid two DACs at least?
<awygle> (or similar)
<whitequark> 2.8V min?
<whitequark> 0.35V dropout?
<whitequark> and that doesn't really help in the first place does it?
<awygle> Just an example...let me see if I can find a lower vmin
<awygle> Dropout isn't a problem
<whitequark> since the DACs are for plug-in boards that don't hav vsense
<kmehall> there's a fairchild / onsemi 1.8-5.5 autosensing level shifter without the vcca < vccb requirement. I built a board with it trying to meet the same 1.8-5.5V variable voltage requirement, but never got around to testing it much.
<whitequark> kmehall: ooooh.
<kmehall> http://www.onsemi.com/PowerSolutions/product.do?id=FXMAR2104 is the one I used; IIRC there are also 2 and 8 bit versions
<whitequark> HA
<whitequark> awygle: rqou: remember I exclaimed yesterday about something I found in a schematic then said I misread?
<whitequark> well, THIS device works exactly as I expect
<whitequark> it's an SRAM memory cell
<whitequark> two inverters in a loop
<whitequark> $1.38@1
<whitequark> 80 MHz
<whitequark> awygle: yes absolutely let's go for FXMA108
<awygle> That's a really fucking good idea
<whitequark> and it will even give us 100 MHz with 3.0-3.6V DUT
<whitequark> or rather Mbps, they actually qualify it for data rate
<whitequark> wait
<marcan> data rate is 2x frequency
<whitequark> 16. Maximum data rate is specified in megabits per second with all outputs switching, (see Figure 10). It is
<whitequark> equivalent to two times the F-toggle frequency, specified in megahertz. For example, 100Mbps is equivalent to
<whitequark> 50MHz.
<whitequark>
<whitequark> ok that's cheating
<cr1901_modern> That's an SRAM memory cell in Figure 1?
<marcan> effectively yes
<awygle> Yeah just broken in half
<marcan> well it's a 4-inverter loop instead of 2
<marcan> but yes
<whitequark> well this FXMA108 is at least as good as my GreenPAK idea
<whitequark> and it also is definitely hotplug-safe and has ESD protection built in
<awygle> I want to check something on the txb part....
<whitequark> and qualified to 7V
<awygle> Mm OK nvm
<awygle> dumb idea: Build the FXMA108 from discrete logic
<awygle> (fast discrete logic)
<whitequark> yes, I thought about this, actually
<awygle> That's what, 5 inverters and a buffer? On two voltage rails? So a 24 inverter and a 16-inverter-8-buffer per port lol
<whitequark> no, it's much more complex
<whitequark> page 12
<kmehall> you've probably already discussed this, but if you have enough board space and FPGA IOs, another option is a bunch of 74lvc1t45s
<whitequark> kmehall: three free FPGA I/Os
<kmehall> ah
<awygle> we could do it with a gpio expander but that's a lot of 74s
<whitequark> $3 of them...
<kmehall> do you want to support SWD? an IO expander might be suboptimal when you have to turn around SWDIO a couple times per transaction.
<whitequark> ^ that
<awygle> Yeah
<awygle> I think the ti part is probably the least bad option (if it works)
<whitequark> awygle: why not FXMA108?
<awygle> Slower, innit?
<whitequark> but on the plus side it works well with pullups/pulldowns
<whitequark> of any value
<awygle> Yeah fair
<awygle> I'm okay either Aya
<awygle> ... Way
<whitequark> how about uh
<whitequark> both footprints?
<whitequark> ah no won't fit
ym has joined ##openfpga
<whitequark> awygle: plus if we go for TI part we won't get those 100 MHz unless we do the three DAC thing
<awygle> This family is cool but doesn't go up to 5v
<whitequark> so I think it's not really a question here
<whitequark> FXMA108 it is
<awygle> "3V3 and don't explode from 5" would work tho
<azonenberg> whitequark: So, for starshipraider
<azonenberg> I pretty much gave up on that exact problem you have
<rqou> ^ why i suggested "probe cards"
<azonenberg> i think my current plan for the io card calls for two discrete single-bit level shifters
<azonenberg> Per channel
<whitequark> azonenberg: rqou: I want a simple device
<whitequark> awygle: if we really want to go >50MHz at some point in the future
<whitequark> let's do a respin with a different level shifter and voltage capacity then
<whitequark> IMO
<awygle> sounds good
<rqou> hmm, it sounds like the performance target you two want is slightly lower than what i want
<whitequark> rqou: my priorities are basically simplicity, safety, speed
<whitequark> I traded off speed for major improvement in simplicity and safety
<rqou> the goal for starshipraider/bus armada is >=500 mhz, and the "mid-range jtag thing" i've been wanting to build is <=100 mhz
<whitequark> and not even that much speed
<rqou> sounds like you're going for <= 50 mhz?
<rqou> of course there are then the potato-quality devices at <= 24 mhz and <= 1 mhz
<whitequark> rqou: well
<rqou> yeah, my priorities are pretty much speed, safety, simplicity
<rqou> so the opposite :P
<whitequark> just use starshipraider then lol
<rqou> no, i still want a mid-range device for <= 100 mhz
<whitequark> rqou: btw
<whitequark> are you interested in using our device at all?
<rqou> especially since the software stack i envision is completely different from what azonenberg wants
<rqou> hmm
<whitequark> or is 1/2x speed a complete deal breaker?
<whitequark> one thing I can easily do
<rqou> i'm not sure
<rqou> the deal breaker isn't the speed exactly
<whitequark> is to put a few 0R resistors on the back of the board
<whitequark> so you can just remove the level shifter
<rqou> which fpga were you planning to use again?
<whitequark> iCE40UP5K
<whitequark> the IO buffers are good for >150 MHz
<awygle> I really like that sram level shifter idea
<awygle> I need to go to sleep now
<rqou> does this have fewer logic cells than the 8k?
<awygle> Goodnight all
<whitequark> it has 5K, yes
<azonenberg> kmehall: re bus turnaround
<whitequark> but it has much more RAM
<whitequark> 1 Mbit
<whitequark> of SPRAM
<azonenberg> that is something i have to look at for the starshipraider io cell
<rqou> and how big is picorv32?
<whitequark> ... why the hell would you put a CPU there
<whitequark> especially picorv32
<azonenberg> as far as selection of parts
<awygle> rqou: it's 2k
<azonenberg> kmehall: the line card connector has eight LVDS inputs, eight LVCMOS33 outputs, eight LVCMOS33 output enables, and one channel of 3.3V I2C
<rqou> hmm
<azonenberg> Plus 12, 5, and 3.3V power
<azonenberg> But what i hang off that is kinda TBD
<rqou> whitequark: given the specific part of the design space you've optimized yourself into, whether or not i would use it would depend pretty much exclusively on "the software ecosystem"
<rqou> i probably wouldn't develop for it
<whitequark> rqou: but developing for this board is, like, the interesting part of it
<whitequark> the slow part of conventional JTAG isn't the IO buffers
<whitequark> it's host bus turnarounds
<azonenberg> whitequark: yeah same with starshipraider, the *intent* is that you will eventually push your application layer into the fpga
<rqou> yeah, exactly
<rqou> but the feature set i want in this case is different
<whitequark> so you get the baseline FTDI MPSSE
<whitequark> so that it "just works" with openocd
<whitequark> and then you can make something actually interesting
<azonenberg> Incidentally, the reason i went with that "infinite DR" jtag architecture for antikernel
<azonenberg> was to minimize host bus turnarounds
<azonenberg> you just keep a constant pipeline of data going
<rqou> the design i was envisioning for my "mid range jtag thing" would *) have ethernet *) not have a potato 8051 controlling the host interface
<azonenberg> rqou: it sounds like you want a starshipraider but cant afford one
<rqou> no
<azonenberg> my solution would thus be, get a job and buy one :p
<rqou> i actually want to target a lower performance range
<rqou> i want a real starshipraider too but not with the software stack you envision
<whitequark> edited
<azonenberg> rqou: what did you want done differently?
<whitequark> rqou: do you have any specific issue with potato 8051
<cr1901_modern> It's 8051
<whitequark> cr1901_modern: its job is to run init code and never wake up again
<rqou> azonenberg: for one thing, my control plane would have a soft-cpu :P
<daveshah> Minimum picoRV32 is 2500-3000 LCs on the 5k
<whitequark> whyyy would you use a soft-CPU
<whitequark> so wasteful
<daveshah> BTW 5k is not actually a massive drop from the 8k as it sounds because of rounding - 5280 vs 7680 LCs iirc
<rqou> for all the "misc. bullshit"
<rqou> e.g. what if you wanted mdns on the ethernet interface?
<rqou> i'm not going to code it in verilog
<cr1901_modern> writing a programmable state machine is not an enjoyable task
<azonenberg> rqou: why would you want mdns? :P
<rqou> why not?
<whitequark> ...
<cr1901_modern> you could use picoblaze if the licensing didn't suck
<azonenberg> i dont like excessive broadcast spam
<rqou> azonenberg: you don't even properly implement all of SLAAC
<rqou> :P
<rqou> cr1901_modern: no, that's a bit too potato
<azonenberg> rqou: i dont have ipv6 support on this 10G stack at all yet
<rqou> also iirc it required dosbox to run the assembler
<azonenberg> and what did i not implement? pinging to make sure the ip isnt in use?
<daveshah> ZPU might be good, or the tiny forth one. I think both might only use circa 1000 LCs
<cr1901_modern> daveshah: ZPU fits in hx1k if you try
<rqou> er, i heard sb0 had some "rather not nice" words to say about that
<cr1901_modern> it also doesn't work half the time :)
<rqou> azonenberg: that, and multiple prefixes
<cr1901_modern> Also the ZPU ISA itself kinda blows
<azonenberg> rqou: yeah my old ipv6 stack did not support multiple IPs whatsoever
<whitequark> rqou: so your device is as overkill like azonenberg's
<azonenberg> The next generation one probably will
<whitequark> but in a completely wrong direction :P
<rqou> how so?
<azonenberg> but idk, i'm not sure i see a use case for it
<whitequark> azonenberg's overkill is "way more bandwidth than anyone could ever need"
<azonenberg> why would you ever want a link local address when you have a routable one?
<rqou> azonenberg: my networks advertise two prefixes
<whitequark> your overkill is "weird features"
<azonenberg> whitequark: um...
<rqou> a ULA and a public prefix
<whitequark> azonenberg: joke
<azonenberg> whitequark: you do realize that bitbanging 32 bits @ 500 Mbps wont even *fit* in 10 Gbps
<whitequark> azonenberg: no i meant on the bitbang side
<whitequark> I cant possibly imagine any use case for bitbanging 32 bits @ 500 Mbps
<whitequark> I'm sure you do, hence, joke
<azonenberg> yeah i do, but more importantly i wanted it for the LA mode
<rqou> also, i definitely want the USB interface (not sure how i would implement this part) to not just "run init code and never wake up again"
<azonenberg> being able to download a large LA capture quickly
<rqou> because i also want to implement a large pile of "pretend to be <vendor dongle>"
<rqou> i guess you can call that a weird feature too
<azonenberg> yeah see i have zero interest in that
<azonenberg> half the point of starshipraider is "vendor dongle sucks, i want something far superior"
<rqou> sure
<rqou> but pretending to be a vendor dongle may still be useful
<rqou> "yes, i'm totally a segger j-link, trust me"
<rqou> also azonenberg i think i complained about this already
<rqou> but i was trying to hack in support for xvcd into jtaghal
<azonenberg> rqou: and?
<azonenberg> i mean in general jtaghal was intended to be used the other way around
<rqou> but you don't have a FootgunJTAGInterface that exposes enough raw control :P
<azonenberg> i didnt want to pretend to be somebody else's dongle
<azonenberg> i wanted to have jtaghal always be the client
<azonenberg> and have it connect to whatever the heck dongle was at hand
<azonenberg> it was never meant to be a shim for bolting a random ftdi dongle into $OLD_VENDOR_IDE
<rqou> how about $NEW_VENDOR_IDE? :P
<rqou> it works with vivado too
<rqou> diamondman's thing was _supposed_ to let you shim anything to anything
<rqou> but it doesn't particularly play well with your abstractions either
<rqou> although that's partially his fault
<azonenberg> In general i build cleanly architected SW/HW that is intended to work correctly and be easily maintainable
<rqou> but overall would everyone please please build more FFI-friendly interfaces?
<azonenberg> And hard to use wrong
<azonenberg> legacy-friendliness tends to be antithetical to all of that
<azonenberg> So backward compatibility is the first thing i drop in a new project
<rqou> btw azonenberg your interfaces tend to be particularly FFI-unfriendly
<azonenberg> Because i use C++?
<rqou> you heavily use "very OO" C++
<azonenberg> i'm not java-level OO
<azonenberg> i still have global functions etc
<azonenberg> I have member variables without get/set functions
<azonenberg> But like i said, i'm not going to sacrifice clean architecture in order to appease users of other languages
<azonenberg> It's a C++ API intended to be used from C++, period
<rqou> i don't think my architectures are ugly either
<rqou> i just tend to build very very dumb data structures
<azonenberg> i have nothing against bindings
<rqou> on purpose
<azonenberg> But i'm not going to change my architecture to make it easier
<azonenberg> and yeah i heavily encapsulate in my designs
<azonenberg> I like a clear delination between internal state and public api
<rqou> so one thing i've done (other than lack of type-level integers, rust plz fix) is to make almost all of my core data structures serializable and deserializable
<rqou> so the worst-case ffi interface is "here, have a json blob"
<azonenberg> that doesnt play well with things like jtaghal where 98% of the code depends on external hardware state in some way
<azonenberg> serialization is kinda nonsensical
<azonenberg> the onyl thing that is NOT is parsing bitstreams etc and that is pretty much already serialization by definition
<azonenberg> jtaghal heavily optimizes to reduce unnecessary state transitions
<azonenberg> so it assumes nothign is poking the chain out from under it
<azonenberg> how would it even make sense to serialize a jtag adapter?
<rqou> write out the fd? :P
<rqou> if serializing to a domain socket you can even sendmsg() the fd
<azonenberg> what would the benefit be to serializing and then deserializing while the fd is still open
<azonenberg> i implement features i have a use for :p
<azonenberg> Not ones that are theoretically possible
<rqou> it's not as useful for jtaghal no
<azonenberg> and gp4par has serialization to/from bitstream
<azonenberg> i dont see the point in serializing intermediate state
<rqou> in general though my designs tend to be "here are all the functions you can call. if you fucked it up that's your fault"
<azonenberg> meanwhile my designs tend to enforce correctness as much as possible
<azonenberg> i dont always succeed but that is the goal :p
<rqou> i mean, i agree that getting correct answers is important
<rqou> but i also feel "ask a dumb question, get a dumb answer" :P
<rqou> xc2par can totally serialize/deserialize internal state
<rqou> it's useful for debugging
<rqou> it took 1 LOC to add
<rqou> thanks rust
<rqou> i just wrote ![derive(Serialize, Deserialize)]
<rqou> and the internal state became serializable/deserializable
<cr1901_modern> And serde generated a horrifying mess behind the scenes :P?
<rqou> yeah
<rqou> but it's fast enough, so not my problem :P
<rqou> in fact faster than many other json parsers
<cr1901_modern> Not an issue w/ Rust in the past year at least, but at one point I had to use the intermediate output from serde for some reason. The generated code is... not a pleasant read.
<cr1901_modern> Dunno if it's due to macro formatting or just inherent to serde's complexity tho (prob both)
<azonenberg> i've just always been a fan of simplicity
<azonenberg> i add features if i have a good reason
<rqou> i did have a good reason
<rqou> you can easily set up corrupt or otherwise weird internal states for testing
<rqou> without having to "backstep" them all the way to yosys json objects
<rqou> too bad derive doesn't work on closures
<rqou> also, why doesn't rust have "yield" yet?
<rqou> serializable generators would be really really cool
<cr1901_modern> It probably will (unfortunately); the rust devs are _huge_ on async/coroutines and stuff
<rqou> <3 coroutines
<rqou> i haven't used async nearly as much though
<azonenberg> rqou: see, my response is
<azonenberg> if you have a corrupt internal state, ever, you have a bug
<azonenberg> detect it as early as possible then abort
<azonenberg> then single-step the offending code to find it
<rqou> so imagine if we did have serializable closures and coroutines
<rqou> you can checkpoint and reload the entire compiler state
<cr1901_modern> rqou: That makes one of us... but the world disagrees w/ me so I'm not gonna fight it
<rqou> i think that would be extremely useful
<rqou> cr1901_modern: er, what?
<cr1901_modern> makes one of us who "<3 coroutines"
<rqou> wait, this opinion is uncommon?
<cr1901_modern> In Rust land it is, IME
<rqou> huh, that seems highly unusual
<rqou> how is async expected to work?
<cr1901_modern> err, let me rephrase: Rust land in general loves coroutines. I don't care for them
<rqou> ah ok
<cr1901_modern> And the world disagrees w/ me, and so I'm not really going to put energy into arguing. Just I find them difficult to reason about
<cr1901_modern> and their internal impl is even worse
<rqou> how so?
bitd has joined ##openfpga
* cr1901_modern thinks carefully before answering
<rqou> btw do you know if the plan is for symmetric or asymmetric coroutines in rust?
<rqou> i sure hope it's "both!"
<cr1901_modern> Idk :(
<rqou> symmetric coroutines basically give you cooperative multithreading
* rqou expects azonenberg to jump in at any moment and call this "PL wankery" :P :P
rohitksingh_work has quit [Read error: Connection reset by peer]
<rqou> azonenberg: i seem to get the impression that you don't particularly care for "modern" PL features? is this accurate?
<cr1901_modern> rqou: I can't honestly give a satisfactory answer than "I'm extremely sensitive to syntax/new semantics", and "In Python 3.5, for example, I have trouble figuring out when "async {block}" will be called in the grand scheme of the program >>
<cr1901_modern> and when results of async code will be available to the main control code
rohitksingh_work has joined ##openfpga
<cr1901_modern> So it's personal issues, not necessarily technical. Though thread + mutex is easier for me to reason about, esp in Rust.
<cr1901_modern> (Isn't a big point of async/coroutines to avoid a second/third/4th/erc thread?)
<rqou> i basically treat them as cooperative threads
rohitksingh_work has quit [Read error: Connection reset by peer]
<azonenberg> rqou: there are some features I like and some i don't
<azonenberg> for example i use the C++ 11 foreach heavily
rohitksingh_work has joined ##openfpga
<azonenberg> as well as the new "auto"
<azonenberg> strong typing without having to explicitly specify the type? seems like a win-win
<rqou> i barely count those as real features
<rqou> ok, auto is
<rqou> foreach isn't
<azonenberg> But what kind of features did you have in mind?
<rqou> how about coroutines? :P
pakesson has quit [Ping timeout: 264 seconds]
pakesson has joined ##openfpga
<rqou> btw azonenberg, have you seen rust/go in client code yet?
azonenberg has quit [Ping timeout: 255 seconds]
azonenberg has joined ##openfpga
Ellied has quit [Ping timeout: 256 seconds]
<azonenberg> Back... netsplit or something
<azonenberg> (01:07:30) rqou: foreach isn't
<azonenberg> (01:09:45) azonenberg: i dont like garbage collection etc
<azonenberg> (01:09:36) azonenberg: rqou: as "modern"
<azonenberg> (01:07:51) azonenberg: But what kind of features did you have in mind?
<rqou> how about coroutines?
<rqou> also, have you seen rust/go in client code yet?
<cr1901_modern> The more features Rust add, the more I question whether "no GC" is worth the hassle. The subset of Rust I've used has served me well tho (no coroutines, I can't even tell you what "?" does, etc)
<azonenberg> rqou: i'd just use threads for that in most cases
<rqou> cr1901_modern: i'm interested in their ideas of having GC marker traits
<azonenberg> and no, i have seen neither
<azonenberg> i recall some other folks have seen Go in one or two projects
<rqou> at some point i need to send you some rust malcode :P
<azonenberg> But i mostly work on the deeply embedded side of things
<cr1901_modern> "no GC" just pushes the problem into dealing with wonderful edge cases to ensure your code satisfies the constraints of linear types
<rqou> at some point i need to send you some rust malcode running on embedded :P
<azonenberg> so i'd be the last to see stuff like that
<rqou> brb need to design an iot project and use rust so that azonenberg can go pwn it
<rqou> :P
<cr1901_modern> azonenberg: I can fit Rust code that's a rewrite in C into 2kB on msp430. No printf, no malloc. Is that deeply embedded enough :)?
<azonenberg> cr1901_modern: i dont mean it cant be done
<azonenberg> but it's rare enough that i havent seen it
<azonenberg> also, safety-critical stuff (most of what i do) tends to be very conservative and slow to embrace new tech
<azonenberg> right now actually i'm on a gig involving (of all things) simulink
<azonenberg> makes me want to jump out the window
<cr1901_modern> azonenberg: I am sympathetic
<cr1901_modern> MATLAB is a scourge
<rqou> lolol
<rqou> simulink is garbage
<cr1901_modern> I didn't used to think so tho
<rqou> used it briefly
Ellied has joined ##openfpga
<rqou> azonenberg: ever see labview?
<rqou> hmm azonenberg are there even proper tools for doing RE on labview/simulink?
<azonenberg> rqou: not that i recall but i think some of the other people have
<azonenberg> we have the "source"
<rqou> ah
<azonenberg> or whatever passes for it
<rqou> the "source"
<azonenberg> Lol
<rqou> what if you didn't? :P
<rqou> i should send you a .vi with "the diagram deleted"
<rqou> (yes, this is how security works in labview)
<rqou> (you can also add a password)
<azonenberg> rqou: i've never encountered such a thing and i sincerely hope i never do
Lord_Nightmare has quit [Ping timeout: 240 seconds]
<rqou> brb need to go build a chemical plant run by NI instrumentation :P
<azonenberg> graphical programming languages are a nightmare
<rqou> although to be fair it could be worse
<rqou> could be ladder logic
<rqou> yeah, i agree
* azonenberg runs and hides behind a hex dump
<azonenberg> and makes the sign of the C
<rqou> i used to hear "what if the operation you want to do is inherently centered around dataflow?
<rqou> except that even then working with a _graphical_ environment _sucks_
<rqou> azonenberg: should send you to a client with "ladder logic PLCs" made of actual hardwired diodes
<rqou> :P
<rqou> although that might actually be better
<rqou> because since it's physical you can also just connect wires to it to inspect it
<rqou> it also has much smaller attack surface because it's so dumb
<rqou> e.g. you can't ROP your way into hardwired diodes :P :P :P
Lord_Nightmare has joined ##openfpga
<rqou> azonenberg: how do you feel about "no, this can't be hacked because it's made up of diodes/opamps/vacuum tubes/etc."
<azonenberg> rqou: you can still have logic bugs
<azonenberg> That being said
<azonenberg> I am a big fan of "security through stupidity"
<azonenberg> That was one of the guiding principles of antikernel
<azonenberg> make it so simple and dumb it can't do anything but what you want
<rqou> "correct by construction"
<azonenberg> by all means formally verify after, and add additional effort for fault tolerance if that matters
<azonenberg> But architecture is the easiest time to address a lot of these issues
<rqou> so how do you feel about "yeah, this _was_ correct by construction and built out of diodes, but then we added an _IoT_ monitoring and control solution to one set of inputs"
<azonenberg> ...
<rqou> i bet it's happened somewhere :P
<azonenberg> i havent had that happen yet
<azonenberg> but there are a lot of gigs in whcih i really wish my recommendation to the client could be
<rqou> they just outright replace everything with iot? :P :P
<azonenberg> "the thing you are asking me to test is fundamentally a bad idea and you shouldn't do it"
<rqou> but azonenberg, i want to be able to remotely monitor how much electricity my nuclear plant is producing :P :P
<azonenberg> UART -> optoisolator -> whatever the hell you want
<azonenberg> One way
* cr1901_modern needs to stop reading chat for now... gets sucked in "Night" all. Even though I'm still here. Just need to do work.
<rqou> but but azonenberg, what if the boss wants to shut down the chemical plant remotely while he's on vacation in indonesia? :P :P :P
<azonenberg> rqou: tell him no
<azonenberg> :p
<rqou> lol
<rqou> but but but azonenberg, we tried locking down all endpoint machines, but the boss keeps complaining that the firewall is blocking his "work-related video sites" :P :P :P :P
<rqou> he needs them to... uh... manage stress :P :P :P :P
<rqou> hmm azonenberg, can you give some general comments about endpoint security in industrial-type settings?
<rqou> in software it's pretty famously shit
<azonenberg> Havent done any scada PC type stuff
<azonenberg> i work close to the metal
<azonenberg> i.e. i've tested single PLCs
<azonenberg> but not HMIs or full systems
<azonenberg> we have other people who do that
<rqou> have you/IOA burned an israeli/US operation yet? :P
<azonenberg> I don't do IR so, no
<rqou> IR?
<azonenberg> incident response
<azonenberg> idk if we have people in the company who do
<rqou> ah
<azonenberg> but basically, all of what i do is "here's this product we're going to sell / have out in the field, how bad is it and how can we fix it?"
<rqou> "it's a disaster and should never have been put on the market" :P
<azonenberg> with the occasional corp network/webapp thrown in when the folks who do that are booked out and we dont have much embedded work
<azonenberg> (which happens a few times a year)
<azonenberg> There have been products like that
<rqou> are corp networks still the usual flaming piles of disaster?
<azonenberg> The ones i've tested? yes
<azonenberg> but i dont do them often enough to have a general impression
<rqou> including my joke about "work-related video sites"? :P
<azonenberg> i have yet to catch a client watching pr0n
<azonenberg> More often if i do non-embedded stuff it's a webapp or mobile thing
<azonenberg> i dont like them but it pays the bills until the next embedded gig comes in, which is usually mercifully quick
<rqou> i'm still surprised any embedded people even know what security is
<azonenberg> most dont :p
<azonenberg> which makes the job boring at times :
<azonenberg> :p
<rqou> but they know enough to hire IOA
<azonenberg> The repeat customers usually improve
<rqou> unless they're japanese vidya companies? :P
<azonenberg> I personally have never done work for one, i dont know if we as a company have and if i did know i couldnt say
<azonenberg> :p
<rqou> nah, i was just referring to how nintendo/sony get totally pwned repeatedly
<rqou> including not understanding the importance of ecdsa nonces :P :P :P
<rqou> also, everbody please switch to deterministic signatures kthx
<azonenberg> definitely
<azonenberg> anyway, i need to sleep
FabM has quit [Read error: No route to host]
FabM has joined ##openfpga
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 256 seconds]
<whitequark> rqou: what do the numbers "7799520" tell you
openfpga-github has joined ##openfpga
openfpga-github has left ##openfpga [##openfpga]
<openfpga-github> openfpga/new-bittwiddle 8056eb6 Robert Ou: xc2bit: Bit twiddling can handle defaults and Result
<openfpga-github> openfpga/new-bittwiddle 52d5399 Robert Ou: xc2bit: First attempt to start refactoring bit twidding into macros
<openfpga-github> openfpga/new-bittwiddle 7742f18 Robert Ou: xc2bit: Refactor global bits into a new file
<openfpga-github> [openfpga] rqou created new-bittwiddle (+4 new commits): https://git.io/vxymA
<rqou> whitequark: that seems to be a chinese dating site?
<rqou> you do realize that "ABC culture" != "mainland CN culture" right? :P
<rqou> but hmm
<rqou> i _think_ "77" = "妻妻" (wife)
<rqou> "99" might be "求求" (to seek)
<rqou> i don't know what 520 is
<rqou> also holy sh*t it's late
<whitequark> rqou: "ABC culture"?
<rqou> ABC = american-born chinese
<whitequark> okay but this was in HK
<whitequark> does HK have mainland CN culture or am I missing something
<rqou> as in, i'm an ABC and I don't completely know what's going on over in HK/CN
<rqou> hmm, maybe they have an HK presence too? but the site that pops up on google is clearly mainland-targeted
<whitequark> I think it might have a hk. subdomain
* whitequark types numbers and hanzi into google translate
<whitequark> holy shit
<rqou> anyways, afaik this weird number code thing is only really popular back in asia and not among the overseas community
<rqou> anyways, i'm definitely going to sleep now
<rqou> whitequark: yeah, the numbers and the words are near-homophones
<rqou> whitequark: ah, wikipedia claims "520" is "i love you" https://en.wikipedia.org/wiki/Chinese_Internet_slang#Numbers,_representing_Chinese_words_(%E6%95%B0%E5%AD%97%E8%A1%A8%E7%A4%BA%E6%B1%89%E5%AD%97_sh%C3%B9z%C3%AC_bi%C7%8Eosh%C3%AC_h%C3%A0nz%C3%AC)
<rqou> i didn't get this because the sounds aren't as close
* rqou zzz
rohitksingh_work has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
egg|work|egg has joined ##openfpga
rohitksingh has joined ##openfpga
X-Scale has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
[X-Scale] is now known as X-Scale
rqou has quit [Remote host closed the connection]
rqou has joined ##openfpga
X-Scale has quit [Ping timeout: 256 seconds]
mumptai has joined ##openfpga
digshadow has left ##openfpga [##openfpga]
X-Scale has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 264 seconds]
user10032 has joined ##openfpga
azonenberg_work has joined ##openfpga
<pie__> re chemical safety
rohitksingh has quit [Quit: Leaving.]
digshadow has joined ##openfpga
eric_ has quit [Read error: Connection reset by peer]
eric_ has joined ##openfpga
<awygle> Related to my question from last night, what is APIO?
<rqou> i don't know
<rqou> you speak spanish, you should find out :P
<awygle> Fiiiiine
user10032 has quit [Quit: Leaving]
openfpga-github has joined ##openfpga
openfpga-github has left ##openfpga [##openfpga]
<openfpga-github> openfpga/master 35badfc Robert Ou: bittwidder: Refactor out attribute parsing
<openfpga-github> openfpga/master 2ab57e8 Robert Ou: xc2bit: Refactor "clock stuff" to use new bit twiddler
<openfpga-github> [openfpga] rqou pushed 2 new commits to master: https://git.io/vxSmx
<rqou> eh, decided to push the new magic procedural macro bit encoding stuff
<rqou> now it just has to be done for the actual packing into arrays
xdeller has quit [Ping timeout: 255 seconds]
xdeller has joined ##openfpga
bitd has quit [Quit: Leaving]
<awygle> huh this APIO stuff is actually pretty cool
<awygle> Woah
<awygle> The person who did that "ghdl Yosys front-end" is the project maintainer for ghdl
<awygle> I didn't realize that
<rqou> yeah, but last i looked it wasn't working
<awygle> Still my hopes are somewhat raised
<awygle> I assumed it was some random university student or something
<rqou> is this a reference to me? :P
<awygle> Lol no but it should have been
<awygle> Also Spanish update: I can read it but it feels like my brain is lifting weights.
Bike has joined ##openfpga
noobineer has joined ##openfpga
<kc8apf> needs some cleanup but seems workable for reading in xc7 bitstreams
<kc8apf> next up is wrapping that in some sort of graph so the bitstream is a child of the bitfile instead of hard-coding the behavior
pie__ has quit [Remote host closed the connection]
mumptai has quit [Remote host closed the connection]