Kitlith has quit [Ping timeout: 276 seconds]
Kitlith has joined ##openfpga
<pie__> dos anyone here know how to work xkb? :(
<rqou> the whitequark-esque troll answer is "don't use X"
<pie__> i wouldnt but
<pie__> god i just want to be able to write my damn notes without gteting carpal tunnel from modal keyboard layout switching and a swapping y and z constantly :'(
<pie__> also mental carpal tunnel
<cr1901_modern> >so, #opencatgirls when
<cr1901_modern> I hate to be the bearer of bad news, but: Anime Isn't Real. :)
GenTooMan has quit [Quit: Leaving]
<whitequark> lies
rqou has quit [Remote host closed the connection]
rqou has joined ##openfpga
<pie__> if only we were headed towards such a utopia
<pie__> probably more likely to get resident evil
bitd has joined ##openfpga
<pie__> rqou, the answer is zero phone numbers
<rqou> why zero?
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
rohitksingh has joined ##openfpga
<rqou> azonenberg: actually around?
<azonenberg> For another couple of minutes
<azonenberg> about to sleep
<rqou> so i'm not done fuzzing yet, but i was noticing interesting patterns in the max v lut inputs
<rqou> e.g. there are four or five bits involved (for the tracks that i've fuzzed)
<rqou> and multiple bits occasionally get set/unset
<rqou> anyways, i have a strange hypothesis for how it might work and i wanted you to think if it's reasonable
<rqou> but basically we need an 18-to-1 mux
<azonenberg> oh?
<rqou> my guess is: 6x 3-to-1 one-hot mux sharing control bits, 2x 3-to-1 one-hot mux sharing control bits, 1x 2-to-1 one-hot mux
<rqou> total 8 control bits
<rqou> nice power of 2 and everything
<azonenberg> certainly plausible
<rqou> seems to also be at a local minima of "regular shape, few bits" assuming one-hot vs dense
<rqou> almost certainly not a dense encoding
<rqou> first of all "the bits don't quite look right"
<rqou> and second that stratix paper was talking about "one-hots on inputs feeding into a buffer" is a nice structure
<rqou> anyways, waiting for the fuzzer to run so that we can have more information
<azonenberg> again, one hot is very common in sram fpgas
<azonenberg> because you dont have to waste gate area on decoding logic
<azonenberg> you can just have sram cell feeding a pass fet on the wire
<azonenberg> And have the config mem and pass fets physically distributed along the wire as the routing channels cross it
<rqou> but naive one-hot is expensive
<azonenberg> Yeah, which is why you dont see massive one-hot muxes
<azonenberg> in the 2c32a for example, you have one level of mask programmed mux feeding a second level of one hot
<azonenberg> in the larger coolrunners it's probably mask -> onehot -> onehot or something
<rqou> it is for sure
<rqou> i've fuzzed those patterns already
<rqou> btw did you see my complaint that xc2 needs much more aggressive TFF inference?
<azonenberg> No, but i believe it
<rqou> any ideas how that can be done?
<azonenberg> Yet another thing i dont have time to work on :p
<azonenberg> i was at the house until nearly 11pm tonight
<azonenberg> doing wiring followed by cleaning up the stupidity of a plumber
<rqou> the current "giant abc hammer" isn't too accurate :P
<rqou> oh?
<rqou> you hired one?
<azonenberg> the guys who did the sump pump derped hard
<rqou> you mean the fucky angle? :P
<azonenberg> that pipe, but the angle wasnt the problem
<azonenberg> The problem is that they didn't use primer on any of the joints that they solvent welded
<azonenberg> and the top 90-degree elbow had no glue whatsoever on it
<azonenberg> it was literally just friction-fit
<rqou> lol
<azonenberg> So of course it started leaking
<rqou> but it was fine when i was there?
<azonenberg> It was actually slowly leaking the whole time
<azonenberg> but nobody bothered to look closely
<rqou> also, i assumed you fixed the weird angle while you were at it?
<azonenberg> no, i couldnt fix that - the pipe outside the house was coming in off horizontal
<rqou> ah ok
<azonenberg> no real good way to work around it
<rqou> how did you discover this btw?
<azonenberg> I started putting foam insulation on the concrete behind it
<azonenberg> and framing studs over it
<azonenberg> So i was in close proximity for a while
<azonenberg> Wondered why my 2x4s were getting wet
<azonenberg> There was one obvious source
<azonenberg> Looked closer at the joints and... http://thanatos.virtual.antikernel.net/unlisted/pvc3.jpg
<rqou> i hope the sump itself is actually installed properly
<azonenberg> as soon as i started cutting into the pipe, that joint that was leaking popped open from the vibration
<azonenberg> if you look at the portion of the pipe that's stained from the sump water
<azonenberg> it's obvious that there was no glue on the inside of the fitting at all
<rqou> i see some nice mold
<rqou> needs moar biocides :P
<azonenberg> It's a sewer pipe, IDGAF what's growing in it
<azonenberg> The point is though, that should have been a solid solvent weld between the fitting and the pipe
<azonenberg> There should not have been any liquid penetration into that gap
<azonenberg> because there should not have been a gap :p
<rqou> of course
<rqou> no evidence of problems with the sump itself i hope?
<azonenberg> No, not that i can see
<rqou> or worse, the pipes under the concrete
<azonenberg> the concrete wasn't quite level, which caused problems when i tried framing the wall over it
<rqou> were you at least watching when they installed the buried drainage pipes?
<azonenberg> I was upstairs with earplugs on clocked into $work
<azonenberg> But i went down to check on progress periodically
<rqou> so basically it can't be _that_ blatantly wrong
<azonenberg> Yeah
<azonenberg> There's gravel in the trenches, then perforated drainage pipes
<rqou> i guess it's kinda hard to mess that up :P
<rqou> especially considering that this part isn't even water-tight
<rqou> and has historically been built with materials like hollow logs :P
<azonenberg> lol yes
<azonenberg> The outflow is actually under pressure though
<azonenberg> There's a check valve so it's full of water all the time
<azonenberg> and whenever the pump is running there's that dynamic pressure on top of the static head of however many feet
<azonenberg> Anyway, i need sleep
<daveshah> rqou: that structure sounds very plausible to me
<daveshah> Just like the ecp5 with an extra mux2 at the end
<daveshah> one-hot muxes sharing control signals and cascaded are a common strategy I think
<azonenberg> yeah
<azonenberg> greenpak goes one further with optimizing config memory space and has entire logic blocks sharing control signals with a final mux2 :p
<azonenberg> (makes packing a nightmare, one of the reasons i havent done any work on the larger chips)
<azonenberg> s/larger/newer/
<rqou> or you can use more explicit CSP formulations like i suggested :P
<azonenberg> When i have time to look at it
<azonenberg> i'll re-examine greenpak
<rqou> or i can just go and rewrite it if i have time before you? :P
<rqou> i even have a really really silly proposed name for the rewrite
<rqou> proposed name for gp4par rewrite: ShinyKinglerPAR
<azonenberg> no :p
<azonenberg> I'd prefer to keep greenpak as my project, in c++
<rqou> because Kingler is a crab (Rust), is an evolution
<rqou> and happens to be green :P :P
<rqou> perfect name? :P
<azonenberg> contributions are accepted, but i'm not going to go rewrite the whole thing in rust just to make you happy
<cr1901_modern> Tbh, I wish the whole thing was in C++ for consistency
<rqou> i was saying what if i just rewrite it :P
<azonenberg> cr1901_modern: me too
<azonenberg> i grudgingly accepted his rust coolrunner code because it was better than no coolrunner support at all
<rqou> or Rust for consistency? :P
<azonenberg> But i really wanted to have a single C++ par library for crossbar-based devices and then backends for each chip
<azonenberg> And if/when i have time i may well rewrite cr2par in c++ :p
<cr1901_modern> I don't care for C++ that much, but using Rust just b/c it's the hip new language when 90% of the codebase is already C++ seems less than ideal too
<azonenberg> exactly
<rqou> even in C++ the code probably wouldn't have used your library in the end
<azonenberg> rqou: you just dont like OO
<daveshah> azonenberg: you should automatically transpile rqou's Rust on push :P
<azonenberg> and i cant help you with that
<rqou> except the ratio isn't anywhere near 90%
<rqou> more like 60% maybe? no exact numbers
<azonenberg> anyway, no rewrites of existing components in rust will be accepted
<azonenberg> Or anything but c++
<azonenberg> New chip support in non-C++ languages is strongly discouraged but will be accepted if nobody writing in C++ has an alternative implementation to propose
<rqou> huh, the code ratio is about 50/50 actually
<cr1901_modern> I have to disable the Rust parts when tinkering w/ the build system b/c cargo _insists_ on rebuilding the Rust code every damn time
<rqou> $ find gp* xbpar -type f | xargs wc -l
<rqou> 9929
<rqou> $ find xc2bit/src xc2par/src -type f | xargs wc -l
<rqou> 22158
<rqou> minus about 10k lines for the ZIA
<rqou> cr1901_modern: should be a cmake/cargo integration problem
<rqou> debug it for me pl0x? :P
<rqou> oh wait i miscounted
<rqou> $ find gp* xbpar greenpak4/ -type f | xargs wc -l
<rqou> 26427
<rqou> so by not excluding ZIA on my end either it's still 50/50
<rqou> github claims 50% C++ 40% Rust 10% everything else
<azonenberg> Still my project :)
<cr1901_modern> It still reeks of "using Rust for the sake of using Rust"
<rqou> or i can just rip out xc2par into a separate project
<rqou> no, using rust because C++ is worse
<azonenberg> cr1901_modern: thats everything rqou gets his hands on
<rqou> also, azonenberg and i seem to have highly incompatible coding styles anyways
<rqou> azonenberg seems to prefer a more classic "OO-ish" approach
<rqou> including inheritance and overrides on methods
<rqou> whereas i tend to prefer dumb objects that can't do anything
<rqou> where all the state is packed into very explicit data structures
<cr1901_modern> I mean all things being equal I would've been cool using Rust from the beginning, but any contributions I make will be C++ (or "C with classes" if that's acceptable) b/c that's what most ppl agreed upon.
<rqou> but yeah, overall i would say *) i hate C++ *) i hate OO *) i especially hate classic inheritance
<whitequark> for once i agree with rqou
<cr1901_modern> azonenberg: >you just dont like OO
<cr1901_modern> Btw, Idk if you've read it and/or subscribe to its mantra, but Design Patterns is an irritating book if you don't enjoy UML diagrams :).
<rqou> so i have never ever learned about or used UML diagrams
<rqou> i don't get why people obsess over them so much
<daveshah> honestly the only time ever did them was for A-level computing (UK equivalent of high school)
<rqou> and no, i've never actually read Design Patterns
<daveshah> and I'm an OO guy
<rqou> wait correction, i think i've seen them in a "real thing"
<rqou> the VHPI spec (which nobody implements btw) is described partially with UML
rohitksingh has quit [Quit: Leaving.]
<whitequark> also the USB video class spec
<whitequark> (it's horrifying)
<rqou> what
<rqou> wtf
<whitequark> seriously
<rqou> why?
<whitequark> dunno
<whitequark> because USB is shit
<rqou> doesn't it "just transfer framebuffers"?
<whitequark> LOL
<cr1901_modern> USB doesn't "just" do anything :D
<whitequark> remember that awful chip with a digital audio crossbar?
<rqou> brilliant spec /s
<whitequark> well, UVC is designed to support stuff like that
<rqou> which one? don't all hda audio chips have that/
<rqou> ?
<whitequark> most of the spec is actually autogenerated from XMLs
<rqou> wait, so if UVC is a pile of crap, and v4l2 is also a pile of crap...
<rqou> is this why the joke is that webcams on linux never work? :P
<whitequark> that describe dozens upon dozens of descriptors that describe hardware in anincredibly abstract and generic way
<daveshah> rqou: weirdly, I've never had a webcam not work on Linux
<rqou> i have
<daveshah> it's always been capture card type devices that have been the nightmare
<rqou> the weird BRCM/APPL/ambarella PCIe one :P
<daveshah> god knows, this was maybe 8 years ago
<daveshah> PCIe
<rqou> yeah, i don't get why capture cards all have to suck so hard
<daveshah> but I've had USB ones that were crap too
<rqou> hilariously, i'm also aware of a USB <REDACTED> that at its core was basically two cameras
<rqou> it ran a "proprietary" protocol
<rqou> but the firmware was developed by taking a cypress fx3 uvc video example and duplicating ~everything twice
<rqou> including a multi-kloc file from omnivision(?) full of "set reg XX to YY"
<whitequark> amazing
<daveshah> fuck omnivision
<rqou> and apparently when they were going through some kind of driver certification process, MSFT asked them "how come it doesn't support X, Y, and Z"
<daveshah> I've wasted so much life on omnivision shit
<florolf> the part of the usb spec where they started annotating their state machine transitions using vhdl syntax failed my suspension of disbelief
<rqou> because it was being certified as a camera-like device
<rqou> even though the final application was not a camera
<rqou> apparently they eventually convinced MSFT to give them a pass
<rqou> yeah, i don't get how a giant trashfire like USB managed to take off
<whitequark> because it's more convenient than setting jumpers on PCI cards
<rqou> at least their notions of backwards compatibility work enough that i can plug modern flash drives into my g3 mac
<rqou> um, PCI cards don't need jumpers?
<whitequark> ISA cards. whatever.
<whitequark> you get the idea
<rqou> although i do remember the experience of parallel port daisy-chains and switch boxes
<rqou> e.g. an iomega zip drive couldn't work with the printer/scanner that i had a decade+ ago
<rqou> and you had to reboot to decide if you wanted to use the printer or zip drive this session
<rqou> oh yeah, i also just remembered something else hilarious
<rqou> my father had a coworker way back in the day that did "EDA stuff"
<rqou> he had a parallel port extension cable with a parallel port dongle "sword" attached to it :P
<rqou> actually multiple, because certain dongles didn't passthrough correctly with certain other dongles
<rqou> but yeah, there'd be like five dongles or something all chained together
<rqou> DRM is great /s
<florolf> rqou: probably the same reason the pc/x86-trashfire did: being good enough, remaining backwards-compatible (which also increases the size of the trashfire over time) and leveraging market dominance
<rqou> yeah i suppose
<rqou> see for example whitequark's discovery of the "virtual legacy wire" interface :P :P
<florolf> rqou: i've been busy moving the past few weeks and didn't follow the channel too closely. grep doesn't help either
<rqou> oh this might be from birbsite
<florolf> didn't follow birdsite too closely either
<rqou> whitequark was reading intel manuals and happened to remember a claim that intel dropped A20 around the original core i7 timeframe
<rqou> turns out this isn't strictly true
<rqou> the physical A20 pin was removed
<rqou> but the functionality became tunneled over DMI(?) and renamed virtual legacy wire
<rqou> so tldr A20 still exists
<rqou> 3+ decades later
<zkms> x86 is so depressing
<rqou> yeah
<rqou> oh btw, fun thing i happened to discover the other day
<rqou> valgrind doesn't support x87 float80
<rqou> i'm sure your numerics code will be very happy with that
<egg|z|egg> meow?
<rqou> ohai
* egg|z|egg purrs
* rqou pets egg|z|egg
<rqou> but yeah, afaik valgrind will just compute 80-bit operations only up to 64-bit precision (but can still store to an 80-bit float so the program mostly works right)
<rqou> so if your stuff ever rounds wrong under valgrind, this might be why
<rqou> which is great for causing heisenbugs
<florolf> rqou: yeah, that seems like an intel thing to do
<rqou> yeah, all modern x86 manuals are totally insane
<rqou> so many random features, secret features, leaks, etc.
<rqou> see for example: the tiny x86 hidden inside ME
<rqou> previously an ARC
<rqou> apparently a SPARC at one point?!
<rqou> or maybe the existence of ME itself?
<rqou> the bits that iirc @alt_kia was pointing out where if you set them it triggers an interrupt into SMM where the bios then has to set it back
<florolf> well, that actually makes sense (intel reusing x86 instead of licensing stuff)
<rqou> wtf
<rqou> why is this patentable?
<rqou> also wut
<rqou> "Once a power management agent notifies the VLW broadcaster that an agent has newly awakened. The VLW interrupt is then re-broadcast, with a mask that excludes all but the newly-awakened agent."
<rqou> everything in x86 feels like a giant hack
<florolf> that's what i thought. then, they launch into 30 pages of implementation details, which probably supplies enough complexity to make it patentable
Hamilton has joined ##openfpga
Hamilton has quit [Client Quit]
Hamilton has joined ##openfpga
_whitelogger has joined ##openfpga
<zkms> i love how every year or so someone discovers a new way to trick some hapless peripheral into breaking SMM memory isolation because none of this shit is actually amenable to reasoning about who can write what (and yet breaking SMM isolation lets you do horrid things!)
Hamilton2 has joined ##openfpga
Hamilton has quit [Ping timeout: 265 seconds]
clifford has quit [Read error: Connection reset by peer]
<marcan> 18:05:26 < rqou> hilariously, i'm also aware of a USB <REDACTED> that at its core was basically two cameras
<marcan> Leap?
<marcan> FX3 IIRC, two cameras, "proprietary" protocol, adds up :P
<marcan> and yeah, UAC is a trashfire of a spec, and I haven't looked at UVC but IIRC it's the same nonsense
<marcan> I wrote audio class descriptors for a DIY interface/DSP thing
<marcan> it's a hilariously backwards game of "guess what generic description you need to come up with to accurately describe the hardware but also will be reverse-engineered into a sane set of mixer controls by Linux"
<marcan> and I only had to care about Linux
<marcan> wrote a python script just to generate the descriptors
<marcan> and I still needed a vendor command to configure the EQ block because that wasn't going to happen generically
Hamilton2 has quit [Quit: Leaving]
user10032 has joined ##openfpga
<mithro> morning
m_t has joined ##openfpga
<balrog> are there any cheapish FPGA boards out there with plenty of I/O and HDMI?
m_t has quit [Quit: Leaving]
Hamilton has joined ##openfpga
bitd has quit [Ping timeout: 265 seconds]
bitd has joined ##openfpga
GenTooMan has joined ##openfpga
Miyu has joined ##openfpga
<kc8apf> balrog: define "cheapish"
<balrog> kc8apf: probably under $200, but using an FPGA that isn't terribly expensive
m_t has joined ##openfpga
<mietek> kc8apf: can the miniSpartan6+ be bought?
<kc8apf> doh
<mietek> I just went through the cheap FPGA board list last night
<kc8apf> spartan6 boards are disappearing
<mietek> the only board that I could find with plenty of I/O and HDMI seems to be the MYIR Z-turn with a Zynq 7020
<kc8apf> but artix7 boards with high-speed devices are expensive
<mietek> I have a Pipistrello which is pretty great, but not enough I/O
<kc8apf> but it's $$$$
<mietek> it has a bunch of crap I don’t need :)
<mietek> I was also thinking about something like a FPGA module card, maybe from https://shop.trenz-electronic.de/en/Products/Trenz-Electronic/
<kc8apf> I want an artix7 w/ DP and some I/O
<mietek> I have very little hardware experience; I’m a programmer
<mietek> DisplayPort?
<mietek> yeah, I’d like that too
<mietek> anybody here designing their own FPGA boards?
<kc8apf> I write off anything using FMC. Expensive connectors
<mietek> is that using FMC?
<mietek> the page unhelpfully states “Plug-on module with 2 x 100-pin and 1 x 60-pin high-speed hermaphroditic stacking strips”
<daveshah> kc8apf: I think the ECP5 is a good spartan 6 replacement in terms of performance/size/price tradeoff
<kc8apf> daveshah: agree
<daveshah> Particularly once tinyfpga's boards are available
<kc8apf> hard to get <$20 @ qty1 for ECP5 or Artix7. Anything with hi-speed serdes
<daveshah> kc8apf: not for the non-SERDES smallest ecp5 (12k)
<daveshah> That goes way lower
<kc8apf> I want to do DisplayPort, 10/100 Ethernet, etc
<daveshah> Sure
<mietek> how would one add DVI/HDMI/DP to a board that does not have it?
<tnt> make a daughter board using the exported pins ? :D
<kc8apf> mietek: DVI and HDMI both use TMDS (https://en.wikipedia.org/wiki/Transition-minimized_differential_signaling) signaling. protocol can be handled in FPGA. Just need to adapt CML to whatever the SERDES allows for input
<kc8apf> DP uses LVDS directly
<tinyfpga> daveshah: yes :)
mumptai has joined ##openfpga
Hamilton has quit [Quit: Leaving]
m_t has quit [Quit: Leaving]
<felix_> rqou: on the me architecture: arc was pre-skylake, x86 skylake and newer; spark was used as txe used in some atoms iirc
<balrog> grr, it sure looks like CMake has won the build systems wars
user10032 has quit [Quit: Leaving]
<rqou> i still use just make
<rqou> or the "fuck it" build.sh build system
<balrog> CMake also uses make
<rqou> which is why it's super pointless
<rqou> "oh yeah, let's wrap make with an even more crappy DSL with all kinds of weird bugs and stupid behaviors"
<q3k> cmake is not stupid
<q3k> it can target more than just make, which is useful for cross-platform projects
<q3k> s,stupid,pointless,
<q3k> i mean, i'm not a fan of the dsl they have either
<balrog> q3k: their DSL is less annoying than autotools
<q3k> lowest bar in the world (tm)
<balrog> and they decided to play nice with the distro community (unlike waf), and are scalable (unlike scons or premake)
<q3k> i'm still somewhat more partial to either bazel-style BUILD files or Nix
<rqou> meh, I've given up caring about "the distro community"
<rqou> although being an ex-waf user i agree that it's not actually very good
mumptai has quit [Quit: Verlassend]
* awygle crawls out of a hole, starts reading a week of backlog
<rqou> lol awygle
<rqou> what have you been doing?
<awygle> i have been sick
<q3k> i think i've been in a hole for a month now
<q3k> risc-v workshop, ripe76, vacation in mrs, warcon
<q3k> my backlog is hell
<awygle> i still am sick, really, but yknow how that works. at a certain point you have to get off the couch.
<awygle> rqou: i took the oldschool version of 61a
<awygle> azonenberg / azonenberg_work: interesting results. glad to hear crosstalk is not a problem, sorry to hear MAC table may be.
<rqou> with Brian Harvey?
<awygle> yup
<awygle> azonenberg_work: interesting how that queue math affects the potential of a cyclone-based switch. the lowest level has more memory but it doesn't go up nearly as fast. the MLAB blocks seem like they might be good for the MAC table though.
<awygle> the smallest cyclone has 291 blocks of 20k each, plus the MLAB blocks. vs the k70t has 135 blocks of 36k.
<awygle> i wonder what the math for HyperRAM or DDR3 might look like. but i'm not currently interested in doing it, so i'll either nerd-snipe you or push it on my stack :p
<rqou> wait you actually are an altera user?
<awygle> rqou: i'm primarily a lattice user tbh. but i think the cyclone 10 gx has some interesting properties for switches and NICs
<rqou> i assume you've seen Project Chibi?
<awygle> yes, very cool (dumb name :p)
<rqou> why dumb? :P
<awygle> if you look at the spreadsheet azonenberg and i did a while back you can see that per transceiver Altera is cheaper than Xilinx, currently, at QTY 1
<rqou> well project chibi doesn't have transceivers
<awygle> idk, your project isn't particularly chibi. it is neither particularly smol nor particularly cute.
<rqou> or block ram
<mietek> balrog: ping
<balrog> I'm here
<mietek> so I guess I could use a http://www.ti.com/lit/ds/symlink/sn75dp130.pdf in a QFN-to-DIP adapter board
<rqou> 6x4 tiles isn't cute?
<balrog> QFN isn't the worst to solder
<balrog> though we have people here who do BGA
<mietek> and then this guy http://www.elabguy.com/ has both HDMI and DP breakout boards
<daveshah> I don't think you want to be running DP anywhere near a DIP breakout board tbh
<rqou> I'm pretty sure 6x4 tiles is the smolest fpga (even more than ice40)
<mietek> daveshah: ok. why?
<rqou> and chibi is kinda the opposite of MAX :P
<awygle> o/ daveshah
<awygle> rqou: eh okay fair enough lol
<daveshah> mietek: the minimum line rate is over a gigabit, so it's pretty SI sensitive
<daveshah> You might get away with it, but it feels ugly
<mietek> what’s SI?
<daveshah> Signal integrity
<mietek> thanks
<mietek> what do you suggest for FPGA & DP?
<daveshah> I wouldn't do anything other than a board that had DP already
<daveshah> Not worth the debugging
<mietek> do you think HDMI is easier to add on to an existing board than DP?
<daveshah> The advantage of hdmi is you can clock it power, so you can use normal pins instead of transceivers in many cased
<daveshah> awygle: hi
<sorear> “Clock it power”?
<daveshah> *lower
<daveshah> Than displayport, which has fixed line rates
<mietek> I think the only board with DP I’ve seen is http://zedboard.org/product/ultra96
<mietek> I don’t know if it’s very new or what, but I don’t see it being sold
<daveshah> mietek: loads have DP
<daveshah> Genesys 2
<mietek> okay, well, that’s $1K
<daveshah> Lattice Embedded Vision platform with a DisplayPort "VIP" card
<daveshah> mietek: I bought it with academic pricing
<daveshah> Only $600 then
<balrog> those are *really* big boards too
<awygle> the pynq has HDMI
<daveshah> Numato opsis
<daveshah> Well given you really need an FPGA with transceivers to do DP you're going to struggle to find anything that small
<mietek> $250
<daveshah> Oh nice
<balrog> does Ultra96 Zynq work with free Vivado?
<balrog> or rather Zynq UltraScale+
<mietek> it’s a Zynq UltraScale+ … that seems like a really good deal, no?
<daveshah> Yes, I think the smaller ultrascale+s work fine with free Vivado
<mietek> the other Zynq boards I see are Zynq 7020
<mietek> or 7010
<daveshah> Yeah, it's pretty good deal compared to the old Zynqs
<daveshah> Tempted myself
<mietek> cool
<balrog> yeah, that Zynq is like $550 in qty 1
<balrog> so they're selling the dev board for less to push the product
<daveshah> Most vendor/distributor fpga boards do
<daveshah> But qty1 pricing for fpgas doesn't mean much
bitd has quit [Quit: Leaving]
<rqou> qty1 price for 5M"40" is great
<etrig> anything similar out there with similar pricepoint but more exposed I/O like ultrazed-eg?
<mietek> etrig: why does that one have more exposed I/O? it’s connectors in both cases, no?
<mietek> oh, you mean just more pins?
<etrig> pretty much
<mietek> right
steakpizza has joined ##openfpga
<etrig> that one is nice since you can route an entire fmc-lpc connector worth
<etrig> but yeah, zu3eg works with webpack
steakpizza has quit [Remote host closed the connection]
steakpizza has joined ##openfpga
stefanct has quit [Ping timeout: 240 seconds]
<awygle> whitequark: opened a case with onsemi about the fxma
stefanct has joined ##openfpga
stefanct has joined ##openfpga
stefanct has quit [Changing host]
<reportingsjr> anyone know what is with the weird feedback on aliexpress where it is interleaved english and russian??
<whitequark> awygle: thanks!
<reportingsjr> awygle: ohhh, that chip is an onsemi part?
<reportingsjr> I can't stand using their parts
<awygle> whitequark: gonna triage kicad symbols/footprints, try to see if i can come up with a better location for the usb protection ic, then start on rev c tickets. sound good?
<awygle> reportingsjr: yup
<awygle> their parts are usually fine but not exceptional. i've never tried to use anything complicated from them before though.
<reportingsjr> they are pretty much a high volume chip manufacturer
<awygle> they actually have their own fab, which is increasingly rare
<reportingsjr> cheap stuff, awful documentation, but if you are going to buy 100k+ chips a year they will just design the circuit for you.
<awygle> irrelevant to me as a consumer, but still cool
<awygle> they're my usual goto for standard discretes especially. like i did a BJT charge pump board that was basically all onsemi.
<awygle> because like you said, cheap
<whitequark> awygle: sounds excellent
<mietek> HDMI and 80 I/Os
steakpiz_ has joined ##openfpga
<mietek> is there open tooling for Cyclone V?
steakpizza has quit [Ping timeout: 256 seconds]
<kc8apf> mietek: nope. Only open full toolchains are ice40 and coolrunner-ii. ECP5, Max V, and 7-series are in various states of progress.
<mietek> thanks
steakpizza has joined ##openfpga
<awygle> don't forget greenpak :p
steakpiz_ has quit [Ping timeout: 265 seconds]
ym has quit [Quit: Leaving]
<sorear> curious about how far we are from vtr being usable for the adventurous for a subset of functionality of at least one real chip
steakpizza has quit [Remote host closed the connection]
steakpizza has joined ##openfpga
<kc8apf> sorear: mithro is getting close with ice40
<mithro> I have a wire pnr generating a valid bitstream!
<mithro> as of about 2 hours ago
<awygle> "wire pnr"?
<tnt> what's "vtr" btw ?
<mithro> awygle: PnR for a single wire
<awygle> ah
Miyu has quit [Ping timeout: 240 seconds]
<awygle> copy
<mithro> awygle: passes an equivalence check if we produce a bitstream with vpr and then convert it back to verilog
<kc8apf> tnt: Versatile Place and Route. Part of https://verilogtorouting.org/
<awygle> mithro: that's cool. so given the work you've done, will adding support for other architectures be any easier? or will it be a multi-month wrestling match next time too?
<mithro> awygle: should be a *lot* easier
<mithro> awygle: Will still need a bunch of cleanup -- but most of it should be very reusable
<mithro> awygle: will need some sanity checking soon
<tnt> kc8apf: tx