<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 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
<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
<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>
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
<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>
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]