<pointfree> rqou: I don't know all of the context here. Looking at the colors cells to the left of the green boxes in your spreadsheet...
<pointfree> colors of rows 1-20 are a reflection of rows 27-46. Could this be some kind of reflected/gray-code with sections sliced out of it?
bitd has quit [Remote host closed the connection]
<rqou> not sure about the gray code part, but the bottom is definitely a reflection of the top
digshadow has joined ##openfpga
unixb0y has quit [Ping timeout: 248 seconds]
unixb0y has joined ##openfpga
<pointfree> rqou: I guess the patterns that repeat with the finest granularity of repetition are innermost in a tree and likely controlled by patterns with coarsest granularity of repetition.
<pointfree> Count the frequency of each pattern you see. Denote more frequent patterns with less significant bits and less frequent patterns more significant bits. Use a bitmask if there are any gaps in frequency.
<rqou> wut
<rqou> what exactly is in a tree?
<pointfree> rqou: A pattern of the next highest frequency. Doesn't matter what the pattern represents. This is just if you want to describe the list concisely. The red-orange... pattern occurs with highest frequency so I would denote that with bit #0 (aka leaves of a tree).
<rqou> well, I'm not exactly "just trying to describe the list concisely"
<rqou> i actually want to see if there is some kind of logical pattern in any of the numbers
<rqou> there is some kind of pattern in the right-going wire numbers
GenTooMan has quit [Quit: Leaving]
ZipCPU has joined ##openfpga
pie_ has quit [Ping timeout: 264 seconds]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 245 seconds]
<rqou> huh, "down" wires from the io cells really are two separate lengths
<rqou> there are 10 in each channel, and 7 are full length and 3 are short
<rqou> kinda makes sense?
<rqou> i wonder if the same is true for "up" wires from the bottom
<rqou> azonenberg, awygle, pointfree: https://twitter.com/rqou_/status/1008201953292083202
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Bike has quit [Quit: Lost terminal]
iximeow has joined ##openfpga
rohitksingh has joined ##openfpga
indy has joined ##openfpga
<rqou> azonenberg: ping?
* azonenberg appears in a puff of smoke
<rqou> heh lol
<rqou> how's the house?
<azonenberg> We almost finished rough-in today, took an hour off to get ice cream because it was so hot and so we didn't get the kitchen light hooked up
<azonenberg> We decided at the last minute to replace the kitchen lights
<azonenberg> originally were going to hold off until kitchen renovation
<azonenberg> but the flickering fluorescents from the failing ballast were totally intolerable
<rqou> i thought normally replacing a ballast doesn't need any kind of permit or anything?
<azonenberg> well i figured as long as i was doing that level of repair
<azonenberg> might as well convert to LED like i'm donig for the rest of the house
<azonenberg> And use MC instead of splicing into the old romex
<rqou> yeah makes sense
<azonenberg> I have the switch and power wired up, all i have to do is hang the new box for each of the two fixtures then wire them together
<rqou> just like how when i moved ~all my stuff out of my berkeley apartment today i also took with my the fancy LED bulbs that i bought
<azonenberg> Then the other remaining TODO is putting a box in to splice the left-side wall outlets to MC and run a riser down to the cable tray area
<rqou> i replaced them back with the burned out incandescents from the landlord :P :P
<azonenberg> The right side of the kitchen is a separate circuit and i already have that romex bridged over to my new cable plant
<azonenberg> I just have to do the left
<rqou> i'm definitely the best tenant :P
<azonenberg> Lol
<rqou> leaving zero working bulbs for the next people to deal with :P
<azonenberg> But today we ripped out all of the old kitchen/dining room wiring, moved the microwave and fridge over to extension cords running down to my temporary outlet by the breaker panel
<azonenberg> (since the outlets we had been running them off no longer have power)
<rqou> but hey, i'm definitely not giving the next tenant some fancy expensive LED bulbs :P
<azonenberg> Drilled holes in the siding for the exterior lights by the garage, hung boxes and wired them up
<azonenberg> Put a light in the closet under the stairs
<rqou> anyways, fpga stuff
<azonenberg> and finished hanging a 3/4" flex metal conduit
<rqou> i poked around the top/bottom IO cells in max v
<azonenberg> that will eventually have the new power feed to the kitchen range
<azonenberg> and?
<azonenberg> i saw something about multi-length wires
<rqou> there are 10 inputs to each pin and 7 bits controlling a mux
<azonenberg> Which makes sense although i'm a little surprised to see it in a chip that tiny
<azonenberg> in the xilinx fabric i last studied in detail (spartan6) they had length 1, 2, and 4 wires
<rqou> so i thought "ok, 2-to-1 followed by 5-to-1"
<azonenberg> 1 = N/S/E/W, one hop
<rqou> but that's not what the bit pattern looks like
<azonenberg> 2 = N/S/E/W 2 hops, plus NE/NW/SE/SW one
<azonenberg> 4 = N/S/E/W 4 hops, plus NE/NW/SE/SW 2 hops
<rqou> it looks like 3-to-1 followed by 4-to-1
<azonenberg> interesting
<azonenberg> and 2 unused combinations?
<rqou> which has _12_ values
<azonenberg> Or are power/ground the last 2
<rqou> so one of the values seems to be set in "unused" pins
<azonenberg> For tying off unused routs
<rqou> which is different from what happens on the left/right
<rqou> is it possible it just is a constant zero?
<rqou> i can probably mess with the "unused pin termination" options i guess
<azonenberg> Constant zero sounds very plausible
<rqou> this probably means that i'm missing something on the row IO bits
<azonenberg> you dont want to be driving noise into the fabric and upping power consumption
<azonenberg> this may not be configurable
<rqou> it definitely is configurable
<rqou> because the fitter gives me a warning that i didn't set it :P
<azonenberg> lol
<rqou> Warning (169174): The Reserve All Unused Pins setting has not been specified, and will default to 'As output driving ground'.
<rqou> so maybe the missing setting is indeed "use constant 0"
<azonenberg> There's a difference between behavior of the IOB
<azonenberg> and behavior of the net coming off the IBUF if the IOB isn't used
<rqou> the wording of the warning seems to imply that it is actually driving out a constant zero
<rqou> anyways, i guess i can just mess with it
<rqou> but does this possibly/probably mean that my left/right io is missing some mux bits too?
<azonenberg> Plausible yes
<rqou> anyways, i also have an idea for fuzzing the actual fabric interconnect
<rqou> you know, the hard part :P
<rqou> i wanted to see if you think it has any major issues
<rqou> anyways, the proposed algorithm is:
<rqou> 0) use a human brain to manually determine a superset of all possible connections between wires in the chip (this is not n^2 because there are wires that obviously cannot connect to certain other wires)
<azonenberg> 0) sounds like it would scale VERY well
<azonenberg> :p
<rqou> 1) use manual/semi-automated methods to fuzz just the part involving getting in/out of IO pins
<rqou> 2) import _all_ bitstreams that have been generated by fuzzers so far and store all connections that exist in them. this builds partial knowledge of the interconnect graph
<rqou> 3) now for every connection that is not known about yet, use a very naive dfs-based router to try to route *) from an IO pin to the source of the pair *) from the sink of the pair to a LUT *) some other wires to make the LUT work
<rqou> 4) if the naive dfs router cannot find a path, defer this pair for now
<azonenberg> and then see if the path actually toggles like it should?
<rqou> 5) if the naive dfs router succeeds, ask quartus to try and route a design using these routes
<azonenberg> oh yeah you can ask quartus to do specific routes
<rqou> 6) if quartus succeeded, this connection is possible. otherwise this connection cannot be possible
<azonenberg> That should work lol
<rqou> (it cannot be possible because we have planned everything else such that it cannot fail due to congestion elsewhere in the chip)
<rqou> ((this was a big problem with previous fuzzers))
<rqou> and finally add this information to our db and repeat
<rqou> sounds like this should work?
<azonenberg> Yes
<rqou> but anyway, a huge problem that i observed from previous fuzzers was:
<azonenberg> (I can actually provide plausible feedback here since it's a generic enough algorithm that i dont need intimate knowledge of the microarchitecture to comment)
<rqou> *) routing constraints don't affect io pin placement, even if the pin is unconstrained. quartus runs placement _first_
ZipCPU has quit [Ping timeout: 248 seconds]
<rqou> *) for many fuzzers i wound manually find _one_ plausible route for "the other lut input i don't care about" and the lut output
<rqou> this can congest out quite a few routing resources if this was chosen badly
<rqou> e.g. if you pick the "wrong" pair of input pins and lut inputs, i saw some signals going right, left, right, LUT :P
<rqou> blocking a bajillion muxes along the way
<rqou> quartus seems much better at not doing _that_ :P
<rqou> but that might just be because this chip is nice and smol
<azonenberg> this was also ISE
<azonenberg> :p
<rqou> yeah ISE is a piece of crap
<rqou> i don't get why its placer is just _awful_
<azonenberg> idk, vivado's seems much better
<azonenberg> not perfect but it takes less finagling to get something sane
<rqou> e.g. for a class project i managed to manually floorplan a (shitty) ~70-80 MHz design to work at 100.0 MHz
<rqou> good enough to turn it in :P
<rqou> it actually reached a local minima and actually congested one path not part of our core such that it failed timing by several ps
<rqou> but we got the professor to accept it :P
<azonenberg> I still have to floorplan vivado designs sometimes, but we're talking about say node granularity
<rqou> i joked that if the several ps timing really causes a problem (it didn't) we can just overvolt the chip by 100mV :P
<azonenberg> processor granularity*
<azonenberg> i havent had to RLOC a design to make a critical path work :p
<azonenberg> and lol
<azonenberg> 5-10 mV would likely be plenty
<azonenberg> Or you could just not let it hit more than 80C instead of 85
<rqou> lol
<azonenberg> (easier to do in a class environment)
<rqou> i heard rumors they made the assignment harder afterwards :P
<rqou> because our report pretty much explicitly said "we had an awful microarchitecture, but we floorplanned it until it worked"
<azonenberg> lolol
<azonenberg> in other news, guess what insanity i'm doing now? :p
<rqou> another barrel processor? :P
<rqou> or your mac table?
<azonenberg> No, and kinda-sorta
<azonenberg> a reusable IP block i expect to use in part of the mac table
<azonenberg> It's basically a std::unordered_set :p
<azonenberg> a de-duplicated key store
<rqou> you should do another barrel processor DSP thing and call it pentagon :P :P
<rqou> "ADSP5" :P
<rqou> oh wait, i think blackfin is already using "ADSP"
<azonenberg> you saw the ISA i did a while ago right?
<azonenberg> for symmetric crypto acceleration
<rqou> the NSA one?
<rqou> or your own?
<azonenberg> my own
<azonenberg> 5 IPC VLIW with a Y-shaped pipeline
<rqou> no i don't think i saw that
<azonenberg> So, all operations are ternary
<azonenberg> there's no mips-like R/I type
<rqou> hmm, i've actually noticed a trend _away_ from VLIW
<azonenberg> every basic operation is reg op reg op imm
<azonenberg> and you just set reg or imm to identity if you don't need it
<azonenberg> This is a very special purpose DSP architecture
<azonenberg> its goal is to implement any current or probable future block/stream cipher or hash
<rqou> why not a dataflow ISA?
<azonenberg> more efficiently than a general purpose CPU
<azonenberg> this is kinda dataflow-y i think?
<azonenberg> So, there's dedicated FIFO memory for input and output data
<rqou> there was a paper floating around birbsite about qualcomm research doing experiments with a dataflow isa
<azonenberg> A scratchpad RAM, single cycle access, for temporary data
<azonenberg> a dedicated memory for constants
<azonenberg> and a special area for s-boxes
<rqou> so far sounds like a "relatively traditional-ish" DSP design
<azonenberg> this is where it gets fun
<azonenberg> The Y-shaped pipeline :D
<azonenberg> fetch/decode are pretty bog-standard VLIW, basically 2-issue superscalar with no hazard checks between the two units
<azonenberg> Then when you get to execute 1, you have two execution units
<azonenberg> processing a total of four registers and two immediates, all 32-bit
<azonenberg> So now you have two intermediate results
<azonenberg> (reg1 opA reg2 opA imm1) and (reg3 opB reg4 opB imm2)
<azonenberg> follow so far?
<rqou> yeah, seems pretty typical still
<azonenberg> a normal CPU would then have a 2-input retirement unit to write back to the register file
<azonenberg> But instead, i have a third ALU
<azonenberg> And I do temp1 opC temp2
<azonenberg> i forget if there was an immediate in there too
<azonenberg> Then write the final result back to a single register
<azonenberg> This is meant for very wide fan-in operations typical of cryptography
<rqou> hmm, doesn't immediately sound like it's significantly better
<azonenberg> the goal was to avoid a multi-write-port reg file
<azonenberg> which has a huge die area overhead
<azonenberg> Or a complex retirement unit
<azonenberg> Everything was designed for deterministic run time
<rqou> scheduling instructions for this will be a pain
<azonenberg> no dataflow dependencies on run time whatsoever, single cycle on every instruction, no pipeline hazards possible (instructions scheduled statically at compile time to avoid dependencies - I was expecting you to write in asm)
<azonenberg> Then i also had a SIMD sbox instruction
indy has quit [Read error: Connection reset by peer]
<azonenberg> takes in a 32-bit data register, a base pointer in a register, and an immediate offset
<azonenberg> and does bytewise lookups into a table in one clock
<rqou> i mean, AVX512<KEYBOARDMASHHERE> includes basically a "do LUT" opcode
<rqou> but i think it only has 3 inputs
<azonenberg> yeah but is it exactly single cycle, all the time, for arbitrary input?
indy has joined ##openfpga
<azonenberg> This was intended to be deployed on a long-lived embedded system
<rqou> i can't find the name (all intel SIMD opcodes have stupid names) but iirc it was supposed to be something like `whatever zmmA, zmmB, zmmC, imm8`
<azonenberg> where you might potentially need to outlive AES
<azonenberg> And not throw out the hardware if your crypto becomes obsolete
<azonenberg> So having the software be hand tuned assembly that takes a while to write is fine
<azonenberg> As you won't be changing algorithms often
<rqou> ah here we go: VPTERNLOGQ
<azonenberg> Also, to be fair
<azonenberg> I never actually implemented said ISA
<rqou> but then intel also has the fun unfeature where if you hammer AVX enough the core then downclocks :P
<azonenberg> i designed it on paper
<azonenberg> But never had a good reason (or sufficient time) to actually build it
<azonenberg> So i have no idea how it would actually perform
<azonenberg> It was just an experiment in a rather radical ISA
<azonenberg> i had never seen a Y-shaped ALU pipeline before
<azonenberg> But for this one problem domain it seemed plausible
<rqou> so why not another barrel processor? :P
<rqou> you can call it Heptagon if you think you can do better :P :P
<rqou> oh btw azonenberg
<rqou> the multiple wire lengths i was talking about don't seem to be all that special in this case
<rqou> because the lengths other than 4 are length 1 :P
<rqou> e.g. "looks like a quick hack"
indy has quit [Ping timeout: 265 seconds]
<rqou> azonenberg: i assume you're aware of bloom filters btw?
<rqou> might be useful to have that in an fpga at some point
<azonenberg> Interesting, but wont work for my use case
<azonenberg> I need 100% accuracy over a small (single or double digit) number of elements
<rqou> why is "as output driving an unspecified signal" even a legal setting for unused outputs
<rqou> thanks altera
<daveshah> For fun, of course
<daveshah> Life would be so boring without fpga toolchains
<rqou> this feature is stupid
<rqou> also it doesn't change anything, so lol
<rqou> ok, i know what the "weird stripe pattern" bits control now lol
<rqou> they control io settings of some kind
<rqou> e.g. bus hold, pull-up
<azonenberg> Makes sense
<rqou> huh this is interesting
<rqou> this seems to mean that the "fabric" section of the bitstream only controls routing signals in/out of "some io structure somewhere"
<rqou> and the io is configured completely separately
<rqou> somewhat analogous to the coolrunner-ii voltage level bits
<rqou> azonenberg: what are the chances that the user flash is just tacked onto extra "IO" cells of some kind?
<daveshah> rqou: that is how they do the hard IP in the ice40lm
<daveshah> And the PLLs
<daveshah> For the Ultra/UltraPlus they use fake logic tiles with the logic cells ripped out
<daveshah> I think the latter was actually a genuine Lattice rather than SiliconBlue decision, because it matches the ECP5
_whitelogger has joined ##openfpga
<rqou> hmm, not sure what to make of this
<rqou> if i just write `assign o = 1;` i get ~no bits set anywhere near IOs that i expect
<rqou> driving zero sets a bit
<rqou> so maybe the default state is 1?
<azonenberg> could be
<azonenberg> or like coolrunner, one bit is inverted?
<rqou> well, then discovering it will be hard :P
<azonenberg> f.ex in altera chips
<azonenberg> you cant init a dff to 1 vs 0
<azonenberg> everything is reset to, i think, 0
<rqou> wait wut
<azonenberg> To init to 1, you put an inverter on the output
<azonenberg> and invert the input
<azonenberg> anyway sleeps
<daveshah> yeap, ice40 and Lattice FPGAs are the same too
<daveshah> afaik icecube doesn't even support init to 1, but Yosys does
<daveshah> using the inverter trick of course
eduardo_ has joined ##openfpga
<rqou> ok, top io cells are doing something weird
eduardo has quit [Ping timeout: 265 seconds]
<rqou> yeah wtf something totally insane is going on with "top" io cells
<rqou> oh wait
<rqou> lol
<rqou> i just put in the wrong pin numbers in the wrong order
<rqou> nvm
<rqou> but this seems to mean that there's something missing in the muxes
bitd has joined ##openfpga
<rqou> there's a funny gap in the column io bits for some reason
indy has joined ##openfpga
<rqou> hmm
<rqou> i just checked the datasheet again
<rqou> the bit that changes for 0/1 might be an inverter inside the io cell
<rqou> going to take a look at this tomorrow
eduardo_ has quit [Ping timeout: 240 seconds]
DocScrutinizer05 has quit [Quit: EEEEEEK]
DocScrutinizer05 has joined ##openfpga
eduardo_ has joined ##openfpga
eduardo_ has quit [Ping timeout: 240 seconds]
Bike has joined ##openfpga
soylentyellow__ has joined ##openfpga
soylentyellow_ has quit [Ping timeout: 256 seconds]
ZipCPU has joined ##openfpga
eduardo_ has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
digshadow has quit [Quit: Leaving.]
m_w has quit [Ping timeout: 264 seconds]
m_w has joined ##openfpga
pie__ has quit [Ping timeout: 276 seconds]
digshadow has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
pie__ has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
pie_ has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
bibor has joined ##openfpga
digshadow has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
digshadow has joined ##openfpga
ZipCPU|ztop has joined ##openfpga
ZipCPU has quit [Ping timeout: 268 seconds]
rohitksingh has quit [Quit: Leaving.]
pie_ has quit [Ping timeout: 276 seconds]
<mithro> So what can we do to get Bunnie's NeTV2 campaign to $60k mark? (https://www.crowdsupply.com/alphamax/netv2/updates/second-and-third-stretch-goals) The 100T upgrade would be extremely good
<rqou> troll answer: you can't, since the project is clearly about the politics and not about the hardware
<rqou> less troll answer: because the project is clearly for the politics, the strech goal should be a "political" objective of some kind, not just a bigger fpga
<rqou> azonenberg: ok, i just confirmed; the "connect to GND" bit is actually the "invert output" bit
<rqou> also at this point i should just go and fuzz all io bits
pie_ has joined ##openfpga
<daveshah> Personally, it's probably been several years since I watched anything encrypted by HDCP...
<daveshah> IMO the whole debate is a bit obselete (but perhaps that's partly a UK centric view where most people watch unencrypted DVB-T TV)
<rqou> you're also in (or at least were in :P ) the EU, where you cannot get _criminal_ penalties for bypassing protective measures
<rqou> yes, the US managed to convert what is normally a civil issue into a criminal issue
<pie_> i
<pie_> wait what
<pie_> i thoguth that was just a us thing :p
<pie_> not that i ever really looked into it for the eu
<rqou> yeah, pretty much just a US thing
<rqou> DMCA provides for _criminal_ penalties
<pie_> ok now im confused
<pie_> oh *CANNOT*
<rqou> and no, intent is not required
<daveshah> AFAIK the only thing that gets criminal penalties in the EU is uploading, selling or public performance
<daveshah> wrt copyright
<rqou> usually this is just a civil issue though?
<pie_> you wouldnt upload yourself, you wouldnt sell yourself, you wouldnt be an exhibitionist - wait what
<pie_> data is people
<rqou> ok no, dmca _criminal_ penalties do still require mens rea
<rqou> but the standard may not be as high as for other criminal convictions
digshadow has quit [Quit: Leaving.]
<daveshah> Certainly in the UK criminal penalties are very clearly specified for activities in the course of a business only, and even then it will often end up as a civil case
<awygle> Yeah I was assuming it was just that I am not a Video Person but it does seem like a weird portion of a universally terrible law to get worked up about
<rqou> hence "less troll answer: because the project is clearly for the politics, the strech goal should be a "political" objective of some kind, not just a bigger fpga"
<rqou> (mithro: this one actually is serious btw, unlike the first one)
<daveshah> Quite frankly live modifications to an encrypted HDMI stream is not something I see as particularly important, and also something I feel is quickly decreasing in importance
<awygle> Someday I'd like to talk to the FPGA Video People and the FPGA CPU People and try to understand what drives them.
digshadow has joined ##openfpga
<daveshah> I do find some FPGA video stuff pretty fun
<rqou> i'm still of the opinion that all "video" hardware should be of the form of "allows you to escape the insane world of video where everything you know is wrong as fast as possible"
<awygle> Neither realm is particularly interesting *to me* but I'm not arrogant enough to assume that it's inherently uninteresting
<daveshah> My main FPGA video experience was making a mixed reality headset, which was nice as it was a closed system with simple interfaces and no crazy video stuff really
<daveshah> The only nasty part was finding a decent config for the Omnvision camera modules
<rqou> video stuff can be pretty cool, but i don't get people willing to stay in the "video universe"
<rqou> e.g. if i ever hear the words "frame and field" you are already way way way doing it wrong
<awygle> To rqou's point, video (and graphics generally maybe) seems like one of those sand traps of complexity, like text or time
<mithro> daveshah: The problem is that newer video standards all are adding HDCP like encryption -- IE MIPI and such
<awygle> I barely even know what a color space *is*
digshadow has quit [Client Quit]
<daveshah> mithro: source please?
<rqou> solution: get a FIB, dump all keys, pastebin all keys, profit
<rqou> er, sorry
<daveshah> No evidence of MIPI encryption that I know of
<rqou> include a "forward all keys into RU secretly" step before the pastebin step
<awygle> how relevant is MIPI? I have run into M-PHY but again idk much about the world
<rqou> apparently mipi DSI is reasonably common
<daveshah> awygle: every decent small LCD or camera module used MIPI
<rqou> but afaict there's no encryption there?
<mithro> awygle: Very relevant in phones
<rqou> just a bunch of "bang on registers until the thing works, then send it raw pixels"
<daveshah> Normally CSI-2 for cameras or DSI for displays over D-PHY
<daveshah> Yep, never seen encryption
<awygle> M-PHY supports scrambling but I don't remember encryption in the spec
<daveshah> Some really high end stuff is compressed using DCS
<rqou> the hard part is the "bang on registers" part
<rqou> apparently if you do it wrong you can cause semi-permanent damage to some screens
<daveshah> rqou: normally you can find the register values in kernel dtsi files
<daveshah> Yes, I think I damaged a phone screen slightly hacking with the config
<daveshah> Always was more flickery than it should be afterwards
* awygle grumbles about hardware designs that allow software to break things
<rqou> hey, maybe one of the registers is "set bias voltage" or something :P
<rqou> how would you secure that?
<daveshah> Remember LCDs will also die eventually if driven at too low a frequency or DC
<rqou> yeah, i assume that's what's going on
<daveshah> Which can also happen for all kinds of config or timing issues
<daveshah> I don't see how you can ever secure that without ridiculous failsafe systems
ZipCPU|ztop has quit [Ping timeout: 268 seconds]
<rqou> afaik the "oldschool" way was a trimpot labeled "VCOM" which is just as failure-prone
<daveshah> Ultimately phone screens smashed is probably 6-7 orders of magnitude higher than screens destroyed by bad DSI config
<daveshah> Doesn't seem like a big problem to me
<awygle> My take is that if your software knows about physics you've drawn your boundaries wrong. All that stuff sounds like it should be in a hard controller of some kind. But I am hugely ignorant so this is a bad hot take.
eduardo_ has quit [Ping timeout: 268 seconds]
<rqou> i mean, "VCOM" trimpots are hardware
<daveshah> awygle: the software knows nothing but a blob of init values supplied by the panel manufacturer
<rqou> huh this is an interesting quote from an appnote:
<rqou> "For panels exceeding 19", the
<rqou> backplane cannot be considered
<rqou> in various locations of the s
<rqou> a single low-impedance node. Multiple corrections are needed
<rqou> creen. There may be up to 5
<rqou> localized compensation networ
<awygle> that's horrifying.
<rqou> ks, four in the
<rqou> corners and one
<rqou> in the center. In this case, Digi
<rqou> tally Controlled Potentiometer
<rqou> s
<rqou> (DCPs) allow the manufacturer
<rqou> to automate the process, a
<rqou> necessity for larger panels where a manual adjustment is not
<rqou> practical. "
eduardo_ has joined ##openfpga
<rqou> so awygle, what are your thoughts on mandatory DVFS or the chip melts?
<awygle> I don't have too much of a problem with it because I assume it's done in hardware, but I'm afraid you're about to correct my beliefs.
<rqou> when people were RE-ing the lm32 hidden in AMD chipsets, some OSINT implied that it controls DVFS in software
<rqou> running on the lm32
<rqou> with the software having some kind of physical model of the chip/PSU/etc. and running a control loop
<daveshah> The battery data in Qualcomm device tree files always worries me a bit
<awygle> I would not have done it that way but if the software is mask ROM or otherwise inaccessible it doesn't sound intrinsically terrible
<rqou> it's not
<daveshah> I am sure there are hardware safeguards, but it feels like a lot of battery charging is software
<rqou> there was an RCE in it too
<daveshah> At least the fast charging which could also go horribly kaboom
<awygle> daveshah: if you keep linking to huge blobs of opaque binary data I'm going to cry
<rqou> battery charging is definitely software-controlled nowadays
<pie_> rqou, so youre telling me there was an rce in a monitor controller or what is this?
<rqou> also afaik QCOM really really loves software blobs
<rqou> pie_: no, in the DVFS controller for AMD cpus somewhere in the chipset
<rqou> and yes, it has access to a pcie endpoint of some kind
<pie_> i might not know what dvfs is
<rqou> dynamic voltage/frequency scaling
<jn__> the newest qcom soc needs a blob for the UART
<daveshah> awygle: to get an optimum image out of the ov5640 on the mixed reality project, I had about 300 register writes
<jn__> (SDM845)
<daveshah> Copied mostly from random Chinese app notes and tweaked until it worked
<rqou> jn__: broadcom enterprise switches need a blob for the LEDs
<pie_> jn__, ....well at least maybe you can repurpose it
<pie_> rqou, jesus fucking christ
* awygle hates everything
<rqou> well, afaik the switch still works without it
<mithro> daveshah: How do I determine using the icebox the tiles which have global drivers and that nets they drive?
<rqou> just the LEDs don't
<daveshah> mithro: there are two sections
<daveshah> The global net is different for GB or GB_IO
<daveshah> This is a tuple (X, Y, glb)
<mithro> (x,y,0) in ic.padin_pio_db() ?
<daveshah> This is a tuple (X, Y, Z) in order of buffer number
<daveshah> In the UltraPlus, two of the padins are actually the internal oscillators
<daveshah> In all parts, two of the padins become the PLL outputs if the PLL is used and the global output of the PLL used
<daveshah> Also note. All globals can be used for clock, even number globals for set/reset and odd number globals for clock enable
<daveshah> Any four out of eight globals can drive the local tracks in each logic tile
<daveshah> Globals cannot directly connect to outputs pins, IIRC, a route through LUT is needed.
<rqou> so, anybody have a guess what the 12th input does in max v column IOs?
<rqou> there are 10 local tracks
<rqou> one pattern seems to be connected to VDD
<rqou> and there's one more, that doesn't seem to be used?
<rqou> the row IOs seem to just use "all 1s" as the pattern for VDD
<rqou> maybe it really just is unused?
<awygle> That thing about padins is probably true of the LM as well
<daveshah> awygle: yeah, I think it looked like that
<daveshah> Although I presume it is like the UltraPlus where you can set an attribute and it is routed through fabric instead
<awygle> Everything lines up for that to be true but I didn't dig in deep enough to 100% prove it
<daveshah> But the LM presumably uses a fake IO tile to route that, as it doesn't have the IPConnect tiles that the UltraPlus uses
<daveshah> ISTR discussing something weird with the LM globals
<daveshah> Like they were only ever instantiated in pairs or something
<mithro> daveshah: Which way around are gbufin / padin ?
<daveshah> mithro: what do you mean?
<mithro> daveshah: Well, when driving from an IO -> glb_network is different from driving fabric->glb_network ?
<daveshah> IO use padin and fabric use gbufin, if that's what you are asking?
<awygle> There's a weird phantom global yeah. You can't instantiate just one. But you can do 3
<mithro> daveshah: So, I should use the index for the glb_network number on the padin_pio_db ?
<daveshah> mithro: yes
<daveshah> awygle: hmm, will need to work out that behaviour so it can be replicated in pnr
<awygle> Yeah I wonder what actually happens. Could be a tooling thing
<rqou> hrm, "no bits set" seems a valid setting for column ios that don't correspond to a pin
<rqou> i wonder why the default has a particular mux setting set?
<mithro> Does this look right?
<pie_> im having an rqou moment right now
<pie_> dns is shit
<mithro> 1k cm36
<daveshah> Yeah, looks good as far as I can see
<rqou> whelp, left-side IO muxes are missing a bunch of settings
<rqou> for like 3 more pins
<rqou> i guess that must be where they hid some stuff
<rqou> also, pin N2 on the left hand side has better connectivity than the others
feuerrot has quit [Ping timeout: 276 seconds]
feuerrot has joined ##openfpga
<rqou> whee, apparently getting into the fabric from the right hand side is more complicated than from the left hand side
<rqou> or the top/bottom for that matter
bitd has quit [Quit: Leaving]
<mithro> daveshah: So, it looks like there is never a case where both an z==0 and z==1 pad drive a global network?
<daveshah> mithro: No, that never happens
<rqou> wut
<rqou> N0 and N3 in the bottom IO cells also has more connectivity
eduardo__ has joined ##openfpga
m_w has quit [Ping timeout: 264 seconds]
eduardo_ has quit [Ping timeout: 264 seconds]
digshadow has joined ##openfpga