keesj has quit [Ping timeout: 256 seconds]
nrossi has joined ##openfpga
indefini has joined ##openfpga
AlexDaniel` has joined ##openfpga
sielicki has joined ##openfpga
jfng has joined ##openfpga
hl has joined ##openfpga
anuejn has joined ##openfpga
<mithro> Yay, my HLC sorter kind of works!
<mithro> Hrm -- this is worrying, icebox_hlc2asc.py fails once the hlc is sorted...
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
* mithro fixes another bug
<rqou> wtf is going on with "badbios guy?"
<qu1j0t3> badbois
<balrog> rqou: what now
<rqou> idk
<rqou> i just see marcan yelling at him on birbsite
<jn__> more photos of dead raspis?
<marcan> rqou: he's mentally ill
<marcan> but *sometimes* if enough people yell at him about something he might see the light, so I am
<marcan> unfortunately by the time that happens he'll probably be off to another conspiracy theory
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
keesj has joined ##openfpga
<cyrozap> Looks like Rigol has a fancy new scope: https://www.eevblog.com/forum/testgear/new-rigol-ds7000/
GenTooMan has quit [Quit: Leaving]
<mithro> hrm...
<mithro> Does anyone know if round tripping through HLC is suppose to create bit-identical asc files?
<awygle> why a 10Gsps adc but only a 500MHz front-end...?
<rqou> i strongly advise not using hlc
<rqou> <colorful language redacted because gsoc students are, well, students>
<mithro> rqou: Too late - sunk cost fallacy has kicked in...
<awygle> lol
<mithro> rqou: Problem is actually the routing bits are not bi-directional like originally explained
<awygle> i always thought that was weird. i wonder if that's one of those things that's been discovered and forgotten and re-discovered a few times.
keesj has quit [Ping timeout: 268 seconds]
<mithro> awygle: Nope
<awygle> then we got very lucky that icestorm ever worked (or unlucky, as the case may be, given this latent bug)
<mithro> awygle: It looks like it
<awygle> mithro: for the record i don't necessarily think "clifford doesn't remember knowing it before" is definitive proof that he didn't know it at one point :P but it's irrelevant i suppose
<mithro> awygle: Welp, when I revert my change which made bidirectional stuff actually bidirectional I can now roundtrip through HLC
<mithro> It WORKS!@?#
* awygle pulls a cracker
<mithro> According to icetime -- vpr - Total path delay: 7.28 ns (137.33 MHz), arachne - Total path delay: 10.84 ns (92.21 MHz)
<awygle> it's almost like timing-driven placement is good for something
<mithro> awygle: But the thing is - I don't have valid timing in the description...
<mithro> It's just full of random values...
<awygle> ... o
<mithro> I guess it does try to minimize the values...
<cyrozap> mithro/rqou: What's HLC?
<mithro> cyrozap: "High level configuration" format for describing the ice40 configuration
<rqou> some "high level" file format for ice40 bitstreams that was created the last gsoc round
<awygle> high level circuit(?) it's a higher level description of an ice40 bitstream that a gsoc student came up with last year. there was High Drama about licensing though, not sure it was ever merged
<mithro> awygle: It was merged
<cyrozap> What's the purpose of that? Wouldn't "high-level configuration" just be Verilog with a bunch of instantiated primitives?
<rqou> it turns a grid of 1/0 characters into an ostensibly-human-readable format
<rqou> idk what the reason for doing that is
<awygle> >> human-readable
<awygle> so humans can read it, probably
<rqou> not very human readable
<mithro> It's not that bad of a format, but it wasn't a good choice for my purpose
<rqou> it doesn't seem to be a particularly good format for anything
<rqou> parsing it is a pain, it doesn't have a spec, not really all that human-readable, not really all that well tested
<cyrozap> awygle: Regarding the ADC, that's the sample rate if you only use one channel. With al four channels active that drops down to 2.5 Gs/s per channel.
keesj has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
digshadow has joined ##openfpga
genii has quit [Read error: Connection reset by peer]
m_w has quit [Read error: Connection reset by peer]
m_w has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
m_w has quit [Quit: leaving]
keesj has quit [Ping timeout: 240 seconds]
<rqou> ok, pretty sure i see bits controlling wires that go out of io tiles
keesj has joined ##openfpga
<rqou> so, huge wtf
<rqou> a column io tile seems to originate 6(?!) wires
<rqou> and their numbers are X{n-1}Y1S0I14, X{n-1}Y1S0I15, X{n-1}Y1S0I23, X{n}Y1S0I1, X{n}Y1S0I4, X{n}Y1S0I9
<rqou> wtf is going on?!
<rqou> oh wait
<rqou> something else is going on wtf
Bike has quit [Quit: Lost terminal]
shadowdancer has joined ##openfpga
<rqou> wtfwtf
<rqou> there might be more wires?!
<rqou> but why so many?
<rqou> and why the sparse connectivity?
<rqou> why do some io cells have better connectivity than others wtf
<rqou> so, wut
<rqou> unless i messed up something, N0 and N3 in a column io tile has better connectivity than N1/N2
<rqou> they connect to 6 possible wires rather than 4 possible wires
<awygle> cyrozap: ah, that makes more sense (although still a bit of a bummer)
<rqou> also each column io tile originates 10(?!) wires
<rqou> wtf is going on here
<awygle> rqou: your eventual blog post should just be a transcript of all these irc message
<balrog> what a fucking mess...... https://news.ycombinator.com/item?id=17289536 (that's the same strncat who was involved with rust quite a while back)
<balrog> (sorry, offtopic)
<balrog> (but of impact to anyone who might be using CopperheadOS)
<rqou> huh, the bits actually do add up for the connections to work like this
<rqou> each column io seems to have 20 bits to control wires?
<rqou> 10 on each side
<rqou> and each wire has 2 one-hot bits controlling what drives on it
<rqou> but the fact that there's 5 per column certainly might explain the fucky coordinates
azonenberg_work has quit [Ping timeout: 256 seconds]
<rqou> wow, idcode bits really are nestled right up against some other bits
<rqou> that's a bit surprising
shadowdancer has quit [Ping timeout: 240 seconds]
gnufan has quit [Quit: Leaving.]
<rqou> ok, the io fast path is clearly a hack
<rqou> each one only works for one single lut
shadowdancer has joined ##openfpga
<rqou> hmm, row io tiles in the small parts seem wired for 7 IOBs
<rqou> even though they should only have 5
<rqou> i wonder how likely the UFM/JTAG/etc blocks are just hooked up this way?
shadowdancer has quit [Read error: Connection reset by peer]
shadowdancer has joined ##openfpga
shadowdancer has quit [Ping timeout: 260 seconds]
shadowdancer has joined ##openfpga
<rqou> alright, not sure what's happening but there seem to be an extra set of "right-going" wires in the last column that actually go left?!?!
<rqou> but there's no room for such bits on the left hand side
<rqou> wtf is going on?!
<azonenberg> rqou: is the topology a torus instead of a grid?
<azonenberg> i mean it's vaguely plausible on such a tiny chip
<azonenberg> but i've never seen such a thing
<rqou> no, the wires don't go all the way left
<rqou> they span only 1 tile
<rqou> also, have you finally finished your goddamn house yet? :P
massi has joined ##openfpga
<azonenberg> Lol
<azonenberg> We almost finished electrical today
<azonenberg> For real
<rqou> how are you still not done?
<azonenberg> It's a LOT of work
<azonenberg> our 50+ item checklist is now like 8
<azonenberg> what remains now is a light in the closet under the stairs, the exterior lights by the driveway
<azonenberg> The emergency light in the lab
<azonenberg> Strapping down the last ~10 feet of the data conduits for the living room (one end is fully installed but we ran out of time before doing the full run)
<rqou> why does it seem like your checklist is just getting longer and longer?
<azonenberg> then splicing new cables to the two circuits for the kitchen wall outlets
<azonenberg> removing the old supply lines for that circuit, and removing the old supply lines for the dining room circuit
<azonenberg> Because we find things we missed, or break one large item into several small ones
<azonenberg> Today i ran a bunch of the data conduit for the living room, fished power through the conduit for the 3-way light in the garage, fully wired the garage lighting, secured a bunch of romex in splice boxes that wasn't nailed down
<azonenberg> Identified two old pieces of romex that were no longer in use, removed as much as i could and labeled the unreachable parts over the bath/laundry room as "abandoned in place, to be removed in future remodel"
<azonenberg> Installed a new 30A 240V breaker and outlet box for the supply to the future rack UPS
<azonenberg> Installed the feeder from the future UPS to the subpanel
<rqou> and how exactly did you ever expect all of this to have been done ~2 weeks ago?
<azonenberg> Added crush-protection wood strips around various wiring in the attic near the access door
<azonenberg> Lots of seeing trees or forest but never both at once
<azonenberg> Ally is useful to do support tasks but i'm doing the entire project management myself
<azonenberg> And while i'm neck deep in a breaker panel it's almost impossible to pay attention to the global strategy without losing sight of the tactical situation
<azonenberg> It was only a couple of days ago that i had time to sit back and make the checklist, basically walked around the house room by room looking at the existing circuits and asking what was incomplete
<azonenberg> and as i went along during the next few days i kept finding missing things that never made the list
<azonenberg> Things like "hook up the existing overhead light in the laundry room"
indy has quit [Read error: Connection reset by peer]
<azonenberg> So any assessments of progress based on length of the list were almost always inaccurate
<rqou> so ~2 weeks ago it was "throw up these walls and we should be imminently done"
<azonenberg> And i knew it, but i couldn't sit back and spend significant time on management
<azonenberg> without falling behind on the hands-on stuff that nobody else could do but me
<rqou> and somehow you didn't realize all of the other "miscellaneous" that needed to be done?
<azonenberg> I knew about a lot of it
<rqou> suggestion: rely on your $WIFE more :P
<azonenberg> But i had no feel for how long it would take
<azonenberg> She has no strategic plan
<azonenberg> Or spatial reasoning for figuring out where wires should go
<azonenberg> if i say "go put pigtails on all the wires in these boxes" she can do that
<azonenberg> if i say "go put outlets and a light switch in this room" she's lost
<rqou> i still get the feeling you should have more faith in your $WIFE
<azonenberg> It's the other way around, she has no confidence in her own ability to do things
<azonenberg> i've tried to give her more independent tasks and she complains :p
<azonenberg> She's an artist, not a techie or tradesman
indy has joined ##openfpga
<rqou> ok, right-hand-side row io cells seem to have 16 wires going left
<rqou> 8 that are in the "expected" position given that there is an "extra" column of "stuff"
<rqou> and 8 more where "right-going" wires would normally live
<rqou> but this means that the left-hand-side and right-hand-side are not symmetric
<rqou> i wonder if the left-hand-side also has some secret hidden wires?
<rqou> for bonus fun, the "R1" wires from the right hand side have a full set of mux bits
<rqou> they're not limited to just the io cells
<rqou> you can route through them
<rqou> so, wtf is going on on the LHS?
<rqou> there has to be some wires there too?!
<rqou> azonenberg: ideas?
<rqou> think they just shoved the bits somewhere weird?
<azonenberg> maybe?
<azonenberg> i mean coolrunner has that giant thing in the middle
<azonenberg> which has things related to the io banks and other "not middle" stuff
<rqou> i mean, this chip has some "stripe" bits that i have absolutely no clue what they could be controlling
<rqou> they interrupt the normal pattern of bits
<rqou> if you see my recent pngs they form the black lines at the bottom
<azonenberg> are they the same in all bitstreams?
<rqou> no, they do change
<rqou> well, the solid black lines of zeros do not change
<rqou> so those are probably some kind of "sync" bits
<rqou> or padding
<rqou> or something
<rqou> also, i'm still convinced that this part has many many unused bits
<rqou> like hundreds
<rqou> but you keep thinking it's unlikely?
<azonenberg> transfer bits?
<azonenberg> some kind of framing?
<rqou> some of these are definitely transfer bits/framing
<rqou> but some of the other bits change too, and i have no idea why
<rqou> oooh ridiculous guess: parity bits?
<rqou> ugh it really bugs me how afaict different io pins have different amounts of connectivity
<azonenberg> Clock capable?
<azonenberg> does this part even have a clock tree?
<rqou> it does have a clock tree
<rqou> i can see the bits running along the middle of the array :P
<rqou> it matches exactly where the datasheet draws the clock buffers :P
bitd has joined ##openfpga
<azonenberg> yeah but the feed into the clock tree
<azonenberg> is it the extra iob stuff?
cr1901_modern has left ##openfpga [##openfpga]
<rqou> oh that
<rqou> at this point i have no idea how that works
<rqou> ok, there appear to be 8 more right-going wires in the left-hand side
<rqou> but they seem to be smaller muxes and you can't route through them
<rqou> or at least i don't think you can?
shadow_dancer has joined ##openfpga
shadowdancer has quit [Read error: Connection reset by peer]
<rqou> ok, wires originating from the left hand side seem to be full length?
cr1901_modern has joined ##openfpga
<rqou> azonenberg: can you take a look at this real quick?
<azonenberg> i see it, not sure how to interpret it though
<rqou> so first of all, what first impressions do you get? :P
<rqou> what do you think about the empty space around the main array?
<azonenberg> bottom and right?
<rqou> yeah
<azonenberg> could be a couple of things
<azonenberg> there might be some dummy bits in there that are used to delay reset synchronization or something silly
<azonenberg> They might be default-blank bits that are used during test/bringup and never used in prod bitstreams (but thats an awful lot of bits for some test muxes)
<rqou> it's all ones in every bitstream i've seen
<azonenberg> Could be unused address space that has no physical embodiment
<rqou> could be wasted?
<azonenberg> like the gaps in the coolrunner, where physical toplogy requires a logical address
<azonenberg> but theres not actually a bit cell there
<rqou> um, coolrunner has bit cells there
<rqou> in the flash array
<rqou> just not in the sram
<azonenberg> my guess? that's fab constraints
<azonenberg> it's not practical to have a non-rectangular eeprom array
<azonenberg> (also its not flash, flash is 1T bitcells... coolrunner is 2T)
<rqou> anyways, so quick overview of what your looking at (since there's no legend or anything :P )
<rqou> azonenberg: blue squares are LUTs
<azonenberg> also unused eeprom cells are almost zero power consumption
<azonenberg> unused sram wastes power
<azonenberg> no sense putting bit cells there if nothing is using them
<rqou> bright green is "muxes for getting into a tile"
<azonenberg> (on that note, there's several large registers on coolrunner that might be jtag related that i havent figured out what they do yet)
<rqou> er sorry
<rqou> that's not right
<rqou> bright green is "local tracks within a tile"
<rqou> or more precisely "muxes for going from local tracks within a tile to the 'actual function'"
<rqou> so the green rectangles to the left of the blue squares are logic local track to LUT muxes
<rqou> and the funny-shaped ones on the far left/right are for the IO tiles
<rqou> and then red is "muxes for going into a tile from the interconnect"
<rqou> azonenberg: make sense so far?
<rqou> then pink is "column wires going up"
<rqou> light green is "column wires going down"
<azonenberg> you really need to put a legend box on this
<azonenberg> "light pink" is kinda subjective
<rqou> purple-ish is "row wires going left"
<azonenberg> etc
<rqou> and darker-not-255-green is "row wires going right"
<azonenberg> Sounds plausible
<azonenberg> Then the black and white pixels are raw bits you're still trying to figure out?
<rqou> yes
<rqou> although the raw bits are understood for LUTs and logic tile local track to LUT inputs
<rqou> so first of all: does it seem plausible that i've marked all of the muxes driving interconnect?
<rqou> i don't really see anywhere that any more muxes can be hiding
<azonenberg> yeah the way its structured that makes sense
<rqou> but the total count does not add up to the number in the report
<azonenberg> having a nice well defined region for each mux/block of muxews
<azonenberg> Lol
<azonenberg> Of course
<rqou> well, i thought the regions were well-defined, except they're not completely
<rqou> e.g. the column to the right of the last logic tile (between it and the io) does not appear to have any right-going tracks
<rqou> those bits instead seem to be controlling 1-tile-long left-going tracks
<rqou> and the leftmost logic column does not have any left-going muxes
<rqou> (the bits seem to be taken over by io 'interconnect-to-local-tracks' muxes)
<rqou> and there are those very tiny boxes in the left io column that seem to control extra right-going wires
<rqou> so yeah, there's a bunch of weirdness happening
<azonenberg> Yeah there is obviously going to be some non-orthogonality at the edge of the array
<rqou> so azonenberg: how would you begin to try and correlate these mux bit locations with the quartus internal coordinate system?
<azonenberg> Without reading a bunch of datasheets to learn more about the internal arch and routing? i wouldnt :p
<rqou> well, that's not very helpful is it :P
<azonenberg> well you're already the world expert (outside altera) on this chip, i'd imagine
<azonenberg> Welcome to research
<rqou> except for the part where the quartus coordinate system is totally wrecking me
<azonenberg> Where there's nobody you can ask for help because you know more about the subject than anybody else
<azonenberg> :p
<rqou> azonenberg: hmm, maybe the wires "rotate" like in ice40?
<rqou> but it's just extremely not obvious that that is happening because of how quartus messes with the coordinates?
<azonenberg> What about reflection? e.g. 2 right of the right edge is actually 2 left
<azonenberg> is that a possibility?
<rqou> er, that would be weird
<rqou> hmm, actually i'm not sure exactly what you mean
<azonenberg> So, normally when you are designing a large tile-based ASIC
<azonenberg> you don't P&R every tile separately
<azonenberg> or hand lay out each tile separately
<azonenberg> You design the tile once, then you shove them in a grid
<rqou> right
<azonenberg> Which means the leftmost tile still has leftbound route capability on it
<azonenberg> You have a couple of options for how to handle this
<azonenberg> You can hook it up to I/O
<azonenberg> You can tie it off to a constant input value and ignore the outputs
<azonenberg> Or you can loop it back around into the array
<azonenberg> and provide additional routing bandwidth
<rqou> hrm
<rqou> i see no evidence of that happening
<azonenberg> (or you can special-case the tiles on the edge of the array to simply not have these routes whatsoever)
<azonenberg> I'm not saying it's happening
<azonenberg> I'm saying, it's a common design practice
<azonenberg> and you should consider the possibility
<rqou> wait, maybe it is happening
<azonenberg> If you can rule it out, sure
<rqou> which might be why the right-hand-side has some "left-going span-1 wires"
<rqou> that were probably originally right-going wires that got looped around
<rqou> s/probably/possibly
<azonenberg> well, look into it
<azonenberg> I'm going to look into my pillow for the next few hours :p
<rqou> yeah me too
<rqou> but real quick first
<rqou> from the bitstream layout i can totally see how horizontally-adjacent cells can both drive into the same R4 wire
<rqou> but how does it make sense for vertically-adjacent cells to drive into the same C4 wire?
<rqou> unless it's just "only works for a small subset of the wires?"
<azonenberg> not a clue
<azonenberg> I havent really looked into fpga routing architectures at the wire/bit level at all
<rqou> hmm ok
<azonenberg> all of my tooling work has been on CPLD crossbars
<rqou> you should probably actually look into max v at some point
<azonenberg> And while i've done a ton of FPGA dev, i normally stop optimizing with placement and hand tuned luts etc
<rqou> other than the coordinate system and other weirdness, it's a pretty simple architecture internally
<azonenberg> and let the toolchain do the routing
<rqou> what about your "build a custom fpga" dream?
<rqou> ok azonenberg final quick strategy question
<azonenberg> Still on the long term roadmap
<rqou> after max v is done, any use looking at max ii?
<azonenberg> and i will want to study a lot more of existing arches after
<rqou> or leave that to somebody else?
<azonenberg> I'd focus on current gen stuff
<azonenberg> maybe a cyclone or arria?
<azonenberg> assuming you cant afford a stratix board
<rqou> max10?
<azonenberg> That's an option too, if you want to stay on the low end
<rqou> let's start with affording a stratix software license :P
<rqou> (the free tools cannot do any current-gen arria/stratix)
<rqou> also the max10 goes up to 50K LEs
<rqou> so it's not just for toys
<rqou> anyways, zzz time
* rqou zzzzzzz
shadow_dancer has quit [Ping timeout: 240 seconds]
shadowdancer has joined ##openfpga
shadowdancer has quit [Ping timeout: 260 seconds]
StCypher has quit [Read error: Connection reset by peer]
pie_ has quit [Ping timeout: 245 seconds]
pie_ has joined ##openfpga
Bike has joined ##openfpga
genii has joined ##openfpga
ZombieChicken has joined ##openfpga
pie_ has quit [Ping timeout: 256 seconds]
ZombieChicken has quit [Quit: Have a nice day]
pie_ has joined ##openfpga
bitd has quit [Quit: Leaving]
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
Bike has quit [Ping timeout: 260 seconds]
massi has quit [Ping timeout: 260 seconds]
Bike has joined ##openfpga
massi has joined ##openfpga
azonenberg_mobil has joined ##openfpga
<azonenberg_mobil> hi guys... can somebody do me a favor? i need to know if my main nick dropped offline last night
<azonenberg_mobil> and if so what time range
<cr1901_modern> No it's still there
<cr1901_modern> At least in my client
<azonenberg_mobil> did it go down and come back?
<cr1901_modern> No
<azonenberg_mobil> around 3 am pacific?
<pie_> lol debugging reboots
<pie_> or whatever
<azonenberg_mobil> not reboots. upstream issues
<pie_> i know that feeling
<cr1901_modern> azonenberg_mobil: I don't see anything saying you left the room
<azonenberg_mobil> i missed a 3am call from sar that never reached my phone
<azonenberg_mobil> the 4:30 stand down message connected
<azonenberg_mobil> not surr if the tmobile wifi bridge and/or my comcast upstream is a factor
<azonenberg_mobil> pulling server logs from both dispatch and tmobile now
<azonenberg_mobil> when you call your carrier and tell them this screwup had the potential to get somebody killed they tend to escalate your complaint quickly :p
shadowdancer has joined ##openfpga
<pie_> wut
<pie_> oh sar
<cr1901_modern> That's... serious ._.
massi has quit [Remote host closed the connection]
<mithro> morning!
<cr1901_modern> But it's nearly 1PM
azonenberg_work has joined ##openfpga
azonenberg_mobil has quit [Quit: Bye]
shadow_dancer has joined ##openfpga
<cr1901_modern> Fine, it's morning
<cr1901_modern> Good morning mithro!
shadowdancer has quit [Ping timeout: 256 seconds]
<rqou> whitequark: how does UGT work for people with bouncers who never really join/leave? :P
shadow_dancer has quit [Ping timeout: 240 seconds]
hilmipilmi has joined ##openfpga
<hilmipilmi> Unless you missed it: Xilinx has released a decrypt util for their xilinxt_2017_05 encrypted source: https://pastebin.com/raw/usWNKC2W . It works and you should save it before it is removed.
<hilmipilmi> enjoy
<cr1901_modern> Well, there's a name I haven't seen in a while
<hilmipilmi> Run inside a VirtualBox Ubuntu 17.04 image if you are afraid of a virus. Please spread.
<genii> 17.04 is EOL
<sorear> go away, we don’t do that here
<daveshah> This is for people doing legitimate documentation efforts. It is not helpful to prejudice that.
<hilmipilmi> :-).
<daveshah> I was referring to ##openfpga, not your tools.
<hilmipilmi> It is not illegal. Only in the Americas.
<daveshah> I think you will find it is almost certainly illegal in most of the world including Europe too.
<hilmipilmi> No you are wrong. Only in the land of Trump it is illegal.
<shapr> hilmipilmi: be nice
<hilmipilmi> shapr: i'm nice. keep up your great work.
<hilmipilmi> see ya:-)
hilmipilmi has quit [Quit: Page closed]
* shapr sighs
<cr1901_modern> I ran the script and now I see a bank transfer I didn't authorize
<jn__> o.O
<shapr> I'd rather work with vendors who encourage/support reverse engineering efforts.
<cr1901_modern> I mean I downloaded it, but I don't plan to actually look at it
<cr1901_modern> jn__: Joke, don't worry :)
<daveshah> I wouldn't even download such a thing
<daveshah> shapr: but it's not going to help our case with vendors when stuff like this happens
<shapr> yeah, exactly
<cr1901_modern> Last time this person gave a crack IIRC, it was for IP like the PCI express core
<shapr> treat others with respect, they're not enemies
* genii makes a fresh pot of coffee
<daveshah> cr1901_modern: I swear that's free anyway? And it's not like you could easily port it to another fpga given its half hard silicon
<daveshah> AFAIK all vendors with pcie give you a free core of some sorts
<cr1901_modern> It's free, but the PHY is encrypted _IIRC_. In any case, take everything I say w/ a grain of salt
<cyrozap> shapr: I'd rather work with vendors that release enough documentation and (FOSS) source code so we don't _have_ to reverse engineer things ;)
moho1 has quit [Quit: WeeChat 2.0.1]
<awygle> cyrozap: let me know when you find one of those :p
<shapr> I think if there were more publicity around the increase in sales of ice40 chips due to yosys, vendors might start to take notice
<sorear> I am a bit genuinely curious how we’re going to handle PCIe
<daveshah> shapr: Lattice's European sales office did let us give a workshop at their training days about icestorm
<shapr> oh wow
<cyrozap> shapr: Well, Lattice hasn't suddenly started being more open, and they have all the ice40 sales information, so...
<shapr> that's amazing!
<cr1901_modern> sorear: Tbh I wasn't aware it was actually hard IP on chip
<sorear> Yes well ice40 sales had more room to increase :p
<cr1901_modern> I thought the PHY was pure verilog plus SERDES primitives
<daveshah> sorear: ice40 devices are selling in 100s of million to consumer electronics firms
<cr1901_modern> They just encrypt it for the hell of it
<daveshah> cr1901_modern: depends on the family
<daveshah> ECP5 is mostly soft, but some line coding and sync stuff is part of the SERDES
<daveshah> So called PCS (physical coding sublayer)
<daveshah> I think xilinx 7-series have more hard logic for PCIe
<cyrozap> daveshah: I was looking at some Virtex-7 parts a while back and they seemed to have PCIe 2.0 hard IP but supported PCIe 3.0 with a soft core.
<daveshah> cryozap: that makes sense
<cyrozap> No idea why it wasn't the other way around :P
<daveshah> PCIe 3 not being finalised when they were designing stuff
<daveshah> A bit like routers doing IPv4 in hardware and IPv6 in software
moho1 has joined ##openfpga
<cyrozap> Oh, I see.
<shapr> daveshah: which consumer devices are using ice40? any random names?
<daveshah> shapr: everyone
<daveshah> Including Apple and Samsung
<cyrozap> shapr: HTC Vive
<shapr> huh, wow
<daveshah> I know my Galaxy Note 3 had an iCE40 in it
<shapr> neato
<daveshah> Know a few other intersting apps, but can't share
<shapr> fair enough
<shapr> daveshah: I continue to hear useful/interesting tech gossip because I don't reshare, I get it.
<awygle> the altera FPGAs have a ton in hard silicon, generally
<shapr> I still wish that risc-v expansion board had used a yosys friendly FPGA, I'd have bought it as expensive as it is.
<daveshah> shapr: on the plus side, microsemi seem to really be supporting riscv
<daveshah> Perhaps a good first step to open source
* awygle is skeptical
<awygle> but maybe
<shapr> I'm amazed risc-v went anywhere at all, thrilled but amazed.
<daveshah> Yeah it's awesome
<shapr> My approach is to vote with my wallet, I'll buy the expensive first run boards to learn and encourage.
<daveshah> Lattice are showing signs of support for it too
<shapr> I got five of the arduino sized risc-v boards, they're neat.
<cyrozap> I don't understand how everyone is thinking an open ISA will result in IC companies making chips that are any more open than the ones they're building now.
<shapr> I want a spec I can test against, I hope that will prevent future spectre/meltdown problems.
<daveshah> cyrozap: at least it means compiler work will be more unified
<shapr> cyrozap: do you see any better path to laptops that don't have a management engine?
<daveshah> Instead of all the crap like the Xtensa in the ESP32 etc
<daveshah> Going in the opposite direction, this is neat in its own way: https://bitbucket.org/vahidi/arm-foss/overview
<shapr> oh that's interestingn
<cyrozap> daveshah: Risc-V is just one more option to add to ARM, Xtensa, 8051, OR1K, etc.
<awygle> i think microsemi only cares about risc-v because they don't have a soft core of their own
<awygle> no NIOS, no microblaze, no lm32 or whatever
<daveshah> shapr: it should mean using Yosys to formally verify arm is also possible
<daveshah> awygle: I think Lattice are actually abandoning lm32 for risc-v
<daveshah> Working together with Vectorblox
<cyrozap> shapr: Risc-V doesn't prevent companies from building CPUs/SoCs with ME-like add-ons. In fact, now that they won't have to pay fees to use the core, they'll have that much less incentive to _not_ add something like that.
<cr1901_modern> Guess I better make sure getting lm32 to work on tinyfpga isn't for naught
<cr1901_modern> or nowt
<daveshah> cyrozap: I think you're right, in a couple of years intel will doubtless use RISC-V for their ME
<qu1j0t3> progress!
<daveshah> cr1901_modern: Lattice don't tend to move quickly
<daveshah> The announcement to product delay in the FPGA world always seems very long
<daveshah> Particularly for Xilinx
<daveshah> How long have the RFSoCs been "sampling" for...
<cr1901_modern> Well I like lm32 as a study CPU, and there isn't really any (pipelined) RISC-V impl that I like. (And lm32 also has problems)
<cyrozap> The main benefit of Risc-V to me is that if everyone starts using it, I won't have to write custom disassemblers for weird custom/uncommon ISAs any more in order to RE their firmware :)
<daveshah> cyrozap: no, only for the weird extensions that they've added...
m_w has joined ##openfpga
<shapr> like if they really do add a ME
bitd has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<awygle> daveshah: that's not too surprising, lm32 is an openrisc variant isn't it? so they're just keeping up with the joneses
<cr1901_modern> Nah, lm32 isn't openrisc
<daveshah> Haven't heard that before either, but haven't looked at the details either
<daveshah> They certainly don't share a toolchain or anything
<awygle> okay then, nvm
<awygle> why tf is it called "lattice mico"
<awygle> inb4 "lattice miko" fanart
<cr1901_modern> lattice miku
<rqou> whee, "web infosec people" gimping webusb again
<awygle> lattice miku also accepted
<cr1901_modern> lattice-tan
<cr1901_modern> mico-tan
<awygle> lattice armpit miko
<pie_> what
<cr1901_modern> do I _want_ to know?
<pie_> well armpit fetish is a thing but im having trouble crossing dat logicc gap
<awygle> reimu from tohou is sometimes called armpit miko
<awygle> i'm... not entirely sure why tbh
<zkms> 腋巫女
<Bike> her outfit has like, detached sleeves, so the upper part of the arms are uncovered.
<cr1901_modern> Ahhh touhou, that's why I didn't know
bitd has quit [Quit: Leaving]
<rqou> wtf are we now comparing waifus or something?
<rqou> ##openfpga-anime-club
<shapr> I was explaining waifu to my gf yesterday, she thought I was making it up.
<rqou> ##openwaifus :P
<rqou> diy artisinal waifu AIs :P :P
<mithro> gah, I spend so much time dealing with email :-/
<rqou> don't all googlers?
Bike has quit [Ping timeout: 260 seconds]
<shapr> I still wanno know what exciting adventures kc8apf has coming up
<kc8apf> shapr: www.prevoty.com
<rqou> wow, that's so full of marketing-speak I can't even tell what it's supposed to be
<kc8apf> I know :(
<kc8apf> AppSec product targeting large enterprise
<reportingsjr> haha, it finally happened to me. I had an entire waffle tray shipped to me with 3 QFN ICs in it
<rqou> lol
<rqou> I've gotten that once
sgstair has quit [Read error: Connection reset by peer]
<awygle> mmm waffles
<awygle> IHOW
<cr1901_modern> Please don't start this, awygle, I'm begging you
<awygle> lol
<awygle> i accidentally ruined the local breakfast place for myself :(
<reportingsjr> ... how?
<awygle> i would always go there when i worked a night shift, or was in the office stupidly late
<awygle> to make myself feel better
<awygle> which totally worked, but now that's what i associate it with, so i never go there
<reportingsjr> yeeepp
<awygle> so yay, not working late nights anymore, but boo, no more good cheap omlettes and french toast and whatnot
<reportingsjr> awygle: what sort of job do you have?
<awygle> reportingsjr: i currently work as a software engineer at a company called Data I/O, we make industrial programming machines
<awygle> but back when i was working late nights i was at Planetary Resources, a now-mostly-defunct asteroid mining startup
<reportingsjr> ahhh, interesting
<awygle> it was that. there were unfortunately a lot of bad things about it, but it definitely was not boring :p
<sorear> some people will fund anything?
<reportingsjr> very interesting idea
bofh_ has joined ##openfpga
sgstair has joined ##openfpga
<rqou> awygle: so when can we send all the billionaires off to Mars permanently? :P
<awygle> meh. i'm not convinced asteroid resource extraction is an intrinsically terrible idea, even though it was quite badly mismanaged at my former employer.
<awygle> but i don't really want to get into it, because the discussions tend to devolve quite rapidly in my experience. for, arguably, good reasons, but still exhausting and unproductive use of time/energy.
<pie_> awygle, mumble mumble something about guis https://github.com/ocornut/imgui/issues/973
<sorear> the "we're going to extract dark matter from asteroids for energy production" was a different group I think?
<reportingsjr> awygle: have you read seveneves?
<awygle> pie_: oh yeah i ran into this a while ago. pretty! if i was convinced to abandon native widgets this would be on my shortlist.
<awygle> sorear: wat.
<awygle> reportingsjr: um. about half of it? :p
<pie_> awygle, if only it had haskell bindings
<awygle> i met Neal Stephenson while he was writing it though, very interesting guy
<awygle> pie_: but rust tho :p
<reportingsjr> awygle: just a halfway relevant book
<reportingsjr> oh, that's cool
<awygle> yeah, i started seveneves but didn't make it to the end. stephenson is about a 50% hit rate for me historically.
<rqou> huh, how does imgui do text rendering?
<reportingsjr> awygle: I didn't like the ending very much tbh
<rqou> pie_: does imgui have "advanced text rendering" support?
<balrog> how well does imgui work with screen readers?
<balrog> does it work at all?
<pie_> i doubt it
<rqou> I'm assuming it's the typical vidya gaem answer of "a11y? wtf is that? just git gud"
<balrog> ugh :(((((
<awygle> zero clue unfortunately
<balrog> not supporting people who need screen readers seems to be the m.o. for most things
<pie_> but maybe its not hard to write a plugin or something
<pie_> apparently imgui is very EZ
<rqou> hence why i like "use a browser"
<pie_> or something
<rqou> pie_: try rendering some Nastaliq in it and see if it renders correctly
<pie_> kind of makes me want to try actually writing somthing with it in a non pure functional language
<rqou> also test Devanagari
<pie_> i wonder if the python bindings dont suck
<pie_> rqou, apparently fonts are hard or someshit
<pie_> i think i read somewhere imgui does freetype
<rqou> languages are hard and Europeans didn't think far ahead enough when they designed computer fonts
<pie_> i would have guessed americans
<rqou> well, both
<rqou> the typical "white people" standard seem to be "supports rendering English, French, Spanish, _and_ Chinese/Japanese; that already covered enough userbase for us"
<balrog> whitequark: imo: SDL is not necessarily a bad idea
<balrog> widgets... a mess
<awygle> >> July 2017
<rqou> I'm just going to continue to repeat "use a browser"
<awygle> that thread was kind of wild, it started out pretty straightforward, took a couple of hard turns into VR and ascii-centrism, and then straightened itself back out again.
* awygle should really dig into solvespace's code at some point
<balrog> what's kinda funny about these sorts of things is that when Apple made their "opengl is deprecated" announcement a lot of people were @-replying (on twitter) telling people who were not happy with it to "use bgfx"
<balrog> imgui and bgfx are different things, I know, but I seem to associate them
<awygle> huh, i'd never heard of this
<rqou> well, depending on what specifically I'm trying to do, webgl isn't going to get deprecated anytime soon
<rqou> hence "use a browser use a browser use a browser use ..."
<awygle> yes rqou, we know your position
<awygle> note that i'm not reiterating arguments about platform native guis :p
<awygle> i don't even think you're wrong, for the record. using a browser (or browser-adjacent technologies) is a reasonable approach if you're abandoning all nativeness, want cross-platformability, and care about accessibility and internationalization.
<awygle> which, clearly, you are, do, and do
<balrog> rqou: I'm not a fan of that myself.
<balrog> browsers are big, heavy, and slow.
<sorear> why
<pie_> awygle, shit...are you telling me i should use a browser
<pie_> but <balrog> browsers are big, heavy, and slow.
<awygle> it wouldn't be an unreasonable idea
<pie_> fml :D
<pie_> i didnt really like the idea of backend+browser frontend but thats mainly my desire to be tasteful :p
<pie_> ugh, anyway im just putting off all the backend work as well because i dont want to figure out the ELF spec
<balrog> pie_: what are you working on?
<pie_> working on? nothing lol
<pie_> i dont work
* pie_ wants to play with writing some binary analysis stuff
<pie_> (functioning, efficient people? what are those :P)
<pie_> lol https://github.com/ocornut/imgui/issues/1607#issuecomment-377882323 you know ive been thinking window manager the whole time
<balrog> pie_: does that work with screen readers? :P
<balrog> (fwiw, if you're ever working in government or academia, especially academia, it's really important that software has support for screen readers and assistive devices)
<balrog> (and, well, for good reason)
<pie_> balrog, thats been in the back of my mind for a while
<pie_> but like
<pie_> id probably be happy just having been able to write anything that works at all
<pie_> :I
<balrog> it's probably easier with a browser than something like imgui
<pie_> fucking javascript and css
<pie_> but now we have all that declarative stuff so maybe its doable in a nonhorrible way
m_w has quit [Quit: Leaving]
<pie_> somethng somethin elm, typescript, $idunno
<pie_> actually fuck it, full on canvas *shrug* not native anyway
<pie_> aint nobody got time fo backwards compat either
* pie_ codes on a what is for once not a toaster
Bike has joined ##openfpga
ondrej2 has quit [Read error: Connection reset by peer]
ondrej2 has joined ##openfpga
gnufan has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
<azonenberg_work> imgui actually looks interesting
<azonenberg_work> I might have to try it for my scope app
<rqou> wait, i thought you were one of those people obsessed with making apps look "native"?