<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>
(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]
<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?
<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
<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
<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_>
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)
<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]