futarisIRCcloud has joined ##openfpga
Miyu has quit [Read error: Connection reset by peer]
wpwrak has quit [Ping timeout: 240 seconds]
lovepon has joined ##openfpga
_whitelogger has joined ##openfpga
unixb0y_ has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
jn___ has joined ##openfpga
jn__ has quit [Disconnected by services]
jn___ is now known as jn__
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/e82ecabb6219...273ee5c326e4
<openfpga-github> Glasgow/master fd1e397 whitequark: applet.spi.master: simplify.
<openfpga-github> Glasgow/master 3bc0da8 whitequark: applet.spi.master: fix refactoring issue....
<openfpga-github> Glasgow/master 273ee5c whitequark: access.direct.multiplexer: fix FIFO flush write port forwarding....
<travis-ci> whitequark/Glasgow#90 (master - 273ee5c : whitequark): The build has errored.
pie_ has quit [Ping timeout: 268 seconds]
<openfpga-github> [Glasgow] moriczgergo opened issue #69: Can we get SWIM/SWD support? https://github.com/whitequark/Glasgow/issues/69
pie_ has joined ##openfpga
gruetzkopf has quit [Quit: quit]
gruetzkopf has joined ##openfpga
gruetzkopf is now known as Guest49623
<SolraBiz1a> so... "121 ucBGA (5 mm x 5 mm, 0.4 mm)" → the package is 5mm by 5mm, and the space between ball centers is 0.4 mm?
<azonenberg_work> SolraBiz1a: correct
<azonenberg_work> probably 11x11 balls
<azonenberg_work> that's a fun microvias-a-must package :p
<azonenberg_work> They're not THAT scary to solder in an oven if you have a good stencil and the PCB
<azonenberg_work> But the board won't be cheap in low volume
* SolraBiz1a has a small heart attack
<SolraBiz1a> I thought my eyes were malfunctioning or I misplaced a zero, when I actually looked at that footprint
<openfpga-github> [Glasgow] whitequark pushed 2 new commits to master: https://github.com/whitequark/Glasgow/compare/273ee5c326e4...7b0737e56e1c
<openfpga-github> Glasgow/master e5b57b8 whitequark: applet.spi.flash_25c: use proper dummy byte count for RDP.
<openfpga-github> Glasgow/master 7b0737e whitequark: applet.spi.master: SS should always be driven....
<sorear> i like how all electronics these days is "choking hazard" sizes
<Bob_Dole> soldering will be via oven
<Bob_Dole> but.. the PCBs will also be small volume. :/
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/eccd9de6b1eb9b052ed07b68928459017454bc4f
<openfpga-github> Glasgow/master eccd9de whitequark: applet.spi.flash_25c: add HOLD# pin, always high....
<azonenberg_work> sorear: the good stuff isnt a choking hazard as much
<azonenberg_work> because its so small it won't block much lung capacity :p
<SolraBiz1a> if I bend over backwards, I can get 0.5mm spacing instead... but the FACT will have a beefier FPGA that only comes in 0.4mm spacing
Miyu has joined ##openfpga
<Bob_Dole> going ecp5?
<SolraBiz1a> the FACT design floating in my head has an LP8k and an LP1k
<openfpga-github> [Glasgow] whitequark commented on issue #69: There is already a (preview quality) SWD applet! There's no actual gdbserver (or flasher) support *right now* mostly because I was going to integrate with @azonenberg's jtaghal, and jtaghal isn't evolving quite quickly enough. There will likely be native gdbserver support, the same as for MIPS EJTAG applet. https://github.com/whitequark/Glasgow/issues/69#iss
<sorear> so what's the deal with 0.4 versus 0.5. why does it make boards more expensive, and why don't high-volume customers care?
<Bob_Dole> what footprints are big ecp5's available in?
<Bob_Dole> well. I suppose all ecp5's are going to look big vs ice40s >.>
<sorear> the ecp5s are all 0.5mm and 0.8mm
<travis-ci> whitequark/Glasgow#91 (master - 7b0737e : whitequark): The build has errored.
<Bob_Dole> hey SolraBiz1a how 'bout that
<sorear> i wish lattice datasheets were linkable
<Bob_Dole> they are on mouser!
<sorear> i should make some kind of server so I can rehost lattice datasheets
<SolraBiz1a> even the smallest ECP5 is massive massive overkill, and more expensive, but...
<SolraBiz1a> not *enough* more expensive to offset the cost savings on the PCB
<sorear> page 11 of ECP5™ and ECP5-5G™ Family Data Sheet
<sorear> i thought the price ranges overlapped?
<SolraBiz1a> the iCE40 LP1k we were going to use is $4.45 for one unit, the ECP5 LFE5U-12F I found was ... $5.00 for one unit
<sorear> yeah, the -12F is cheaper than the hx8k
<Bob_Dole> cheapest ecp5 is.. 5 bucks in single quantities
<zkms> what about the most expensive ecp5
<zkms> with the most logic elements and DSPs and serdeses
<Bob_Dole> more logic on it, how Fast is it vs the ice40LP8k or hx8k?
<travis-ci> whitequark/Glasgow#92 (master - eccd9de : whitequark): The build has errored.
<Bob_Dole> generally- considering the main cpu will be 6-12mhz on the board. anywhere in that range Reliably would be good.
<SolraBiz1a> we will not find an FPGA that is too slow for FACT or STB
<sorear> that would be the LFE5UM5G-85F-8BG756C ( $64 @1 on mouser )
<Bob_Dole> it's 64? thought I didn't see any over 50 last I was looking at the Biggest
<Bob_Dole> (but for my considerations I may have not been looking at single.. can't remember)
<sorear> anyway
<azonenberg_work> sorear: 0.4 and 0.5 are both pretty small and hard to work with
<azonenberg_work> 0.8 is doable on "real fab" design rules and sometimes, if you get lucky, on batch fab
<azonenberg_work> 1mm is comfortable on batch fab
<Bob_Dole> SolraBiz1a, I was considering, that the ice40up5k has had complaints about the fabric being -super- slow
<sorear> what do you mean by real fab vs batch fab?
<azonenberg_work> sorear: generally with something like oshpark your design rules are fixed
<azonenberg_work> no microvias, no via-in-pad, etc
<azonenberg_work> fairly large (say 125-150 micron) minimum trace size
<SolraBiz1a> wait... when did I turn into my ghost
SolraBiz1a is now known as SolraBizna
<azonenberg_work> But it's cheap because they combine dozens of people's designs onto one panel and send it to fab all at once and you split the setup fee
<Bob_Dole> so unoptimized big designs on it might go exceptionally slow if it's the same slow fabric
<azonenberg_work> They charge $5/in^2 for 2-layer and $10/in^2 for 4-layer, no minimums
<azonenberg_work> three boards
<azonenberg_work> No setup fee
<sorear> what. it's literally a shuttle.
<azonenberg_work> Yeah, its a pcb shuttle run
<azonenberg_work> on the flip side if you go directly to a fab, expect to pay a few hundred bucks minimum for setup fees
<azonenberg_work> But you have control over the design rules
<azonenberg_work> with fairly modest increases beyond default specs 0.8mm bga is doable
<SolraBizna> and I'm pretty sure my password wallet just crashed and took my Freenode password with it
<azonenberg_work> 0.5 and below take some work, cheaper fabs may not even be capable of working with them
<sorear> what does the fab physically change on their end to enable 0.5?
<azonenberg_work> higher end ones will, but you'll pay dearly for the privilege
<azonenberg_work> Most fabs probably have a couple of lines
<azonenberg_work> the older one they use for low spec and the high-end one they use for leading edge
<azonenberg_work> also just things like requiring more attention during etching and plating
<azonenberg_work> higher chance of the panel going bad and needing to be redone
<azonenberg_work> smaller drill bits that break more often
<sorear> do pcbs use photomasks these days?
<azonenberg_work> I think some may be direct write for low volume
<azonenberg_work> depends on the fab
<azonenberg_work> sorear: anyway, more importantly
<azonenberg_work> as you hit 0.5 to 0.4 mm pitch, you start to need microvias and/or via-in-pad
<azonenberg_work> Which adds more fab steps and costs more because there's more processing involved
<SolraBizna> guess I'm using an ECP5 now
<Bob_Dole> how do ecp5's do speed grades anyways?
<SolraBizna> there are HX4k and HX8k with 0.8mm spacing, but they're not available in single quantity as far as I can tell
<sorear> so for wafer work at modern nodes you have ~10^14 resolution elements per wafer (guesstimate 300mm wafer, 30nm features before multi-patterning), which is the core of why cheap direct write for wafers isn't happening any time soon
<sorear> not sure what the resolution elements per PCB is
<sorear> *-6* is slowest, *-8* is fastest
<openfpga-github> [Glasgow] esden commented on issue #69: You might be able to plug it into https://github.com/orbcode/orbuculum https://github.com/whitequark/Glasgow/issues/69#issuecomment-432926242
<openfpga-github> [Glasgow] whitequark commented on issue #69: That's mostly pointless, it's just more C code I cannot actually distribute with Glasgow itself... Really, the protocol is not very complex. https://github.com/whitequark/Glasgow/issues/69#issuecomment-432926433
<Bob_Dole> different at the bottom in a -12f-6 and -8 is 85 cents, may as well go with the -8 with that small of a difference.
<sorear> the datasheet gives no information about what the difference is, and we haven't fuzzed the timing characterization yet
<SolraBizna> I felt a lot better about using an iCE40 because it's basically fully reverse engineered
<sorear> project idea: set up your own timing characterization and see how conservative it is :p
<sorear> bad project idea: PnR for devices where you have *different* timing models for every LE
<Bob_Dole> over 9000 fpgas, and they're all different versions?
<sorear> not sure if intra-chip process variation is large enough for it to be worthwhile
<SolraBizna> anybody selling iCE40 breakouts?
<azonenberg_work> sorear: you know i've been doing timing characterization on greenpak right?
<azonenberg_work> it's on hold pending the lab getting back operational, i'm losing like a year of work due to this construction
<azonenberg_work> But once i'm up and running i hope to get back to it
<azonenberg_work> and, ideally, continue the research on other chips too
<sorear> azonenberg_work: yes, we discussed measurement strategies
Miyu has quit [Ping timeout: 246 seconds]
<sorear> I posted a ring-oscillator-based testbench idea a couple months ago
<azonenberg_work> ah yeah i remember now
<azonenberg_work> i want to try characterizing coolrunner too
<Bob_Dole> SolraBizna, full pinout breakouts?
<azonenberg_work> conjecture: some paths through the fabric are measurably faster than others
<SolraBizna> I miss being a software-only person... I never had to throw out a program because I single-spaced it instead of double-spacing
<SolraBizna> Bob_Dole: STB is using 115 pins out of the 121 available
<SolraBizna> so...
<SolraBizna> I was afraid of that
<SolraBizna> hefty price tag, extra ICs
<rvense> not everything's brought out, either
<azonenberg_work> $49 hefty price tag
<azonenberg_work> i miss working on designs with two-digit BOMs
<rvense> at least not as far as i remember
<azonenberg_work> as a student
<azonenberg_work> I could assemble the board in a matter of minutes, certianly no more than an hour
<azonenberg_work> if i screwed up it was annoying but i only wasted a pizza or two worth of spare cash
<SolraBizna> I'm poor enough I can't even afford STB... even before I found out how tiny 0.4mm actually is
<SolraBizna> Bob_Dole's cryptocurrency empire is funding it
<azonenberg_work> Now my projects have grown to the point that I'm trying to keep the price tag to 3 digits instead of 4
<azonenberg_work> of course they also involve months of R&D before i ever order hardware
<rvense> also, there was something about the way the programming headers were on that board that meant you either had to bodge some things or just use usb
<azonenberg_work> So i don't think the actual $/day has gone that much higher
<sorear> why assemble boards in 2k18, can't the fab's robots do it cheaper for any reasonable time/money factor
<azonenberg_work> sorear: Not for O(1) volume
<Bob_Dole> I have like 160 dollars in cryptocurrency from the past month and a half
<azonenberg_work> somebody has to program the PnP
<Bob_Dole> about 70 is Profit
<azonenberg_work> sorear: i am looking at getting one of the cheap chinese desktop pnp units and running openpnp on it
<azonenberg_work> So i can have quick turn in house prototype assembly
<azonenberg_work> little things like needing to put leader/trailer on tape for each unique component adds u
<Bob_Dole> I would like to be able to do that, but I.. mostly know how to solder things and work with manual tools.
<azonenberg_work> if you have 30 different passives on your board, a $9 digi-reel fee comes out to $270 of setup fees
<azonenberg_work> just to make it machine placeable
<Bob_Dole> all these new fancy tools you have to program, outside of what I know how to do
<sorear> doesn't the $machine_readable_package you submit to a fab/shuttle contain a pnp program or something convertable to oe
<azonenberg_work> sorear: yeah but they still have to develop configuration
<azonenberg_work> manually load all the feeders, etc
<azonenberg_work> Thats nothing when you're making a thousand boards
<azonenberg_work> at one board it probably doubles the price
<azonenberg_work> anyway, the desktop pnp's can run on cut tape for passives and pick up ICs out of loose piles
* sorear was imagining some kind of tape library-style automated parts warehouse
<azonenberg_work> they only go down to 0402 but i have no problem hand placing the handful of 0201s and WLCSPs i might use in a design, and letting it do the rest
<Bob_Dole> I would love to be able to fab 4layer boards myself
<SolraBizna> as far as I know, only 3 FACTs have homes
<azonenberg_work> sorear: no, i used to work at a SMT line
<azonenberg_work> back in school
<azonenberg_work> You have to manually load a reel into the feeder then tell the machine which bom line goes to which feeder
<azonenberg_work> You normally only have a few dozen feeders, details depend on the machine in question
<Bob_Dole> SolraBizna was trying to get me to do a 0201 component.. that looks like it's smaller than a grain of sand
<azonenberg_work> So you have to constantly pull reels off and put them on between designs
<Bob_Dole> like much smaller
<azonenberg_work> Bigger fabs will have standard library components they keep on feeders all the time ,and charge less/no setup fees for
<sorear> yeah, I was imagining that part was automated, but I keep forgetting how few PCB designs there are
<azonenberg_work> Smaller ones cant afford the number of feeders they need to have that kind of library
<sorear> (how many boards don't have at least one 0.47µ …)
<Bob_Dole> consider the FACT board has a few constants: a 65816 based MCU, an MRAM, SRAM, an FPGA, and a header for adding expansions, including IO. what features would be wanted, if we wanted to turn it into something others here might want to buy a few extra boards for? >.>
<azonenberg_work> sorear: prpplague i think was the one who recommended this one to me
<azonenberg_work> i'm seriously considering it but need to get the lab finished first
<azonenberg_work> little details like walls, floors, and working lights come first :p
<SolraBizna> having zero budget is liberating
<Bob_Dole> wot
<Bob_Dole> also SolraBizna I've had the assumption the final design will be Open, too, though I haven't thought much of FACT having bigger audiences.
<SolraBizna> I have a 100% open tools 100% open source policy when it comes to hardware designs
<prpplague> azonenberg_work: i know nothing!
<Bob_Dole> Good
<Bob_Dole> so for anyone here: assume we want to make Up To Ten of these our selves, and only have 3 people after them. What features, Including what is listed, be desired to want to Buy a board for whatever, if anything?
<Bob_Dole> because if it's a small change or design consideration it'd be reasonable to do
<azonenberg_work> Bob_Dole: count me out, if the FPGA is anything under ~100K LEs and there's not some fast serial transceivers or ethernet or something
<azonenberg_work> Just not useful for me
<SolraBizna> the FPGA isn't a feature, it's an implementation detail
<azonenberg_work> my point is, sounds like a cool project but utterly useless to me :)
<Bob_Dole> biggest ecp5 is ~85k LUT4's so to get 100LEs would need 2 of 'em.
<zkms> gosh i want a thicc ecp5 fpga to play with
<Bob_Dole> SolraBizna, zkms... dumb idea suggestion: footprint to use extra pins on an ecp5 to connect a second ecp5 to it, along with extra memory. for FACT, as a base-model, only needing the one and the already planned for memory. so you can get 2 big FPGAs, if you want it.
<Bob_Dole> so I can get a risc-v Something.
<Bob_Dole> it's not sorear's gigabox though
<SolraBizna> you mean gigacube
lovepon has quit [Ping timeout: 260 seconds]
m4ssi has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/eccd9de6b1eb...6114a216e3b3
<openfpga-github> Glasgow/master 6114a21 whitequark: applet.spi.master: optimize to not use IN autoflush.
<openfpga-github> Glasgow/master 02e9b22 whitequark: gateware.fx2: finish manual-flush code paths....
<openfpga-github> Glasgow/master 5e44acb whitequark: access.direct.demultiplexer: simplify. NFC.
<whitequark> eeee
<whitequark> manual-flush works
* cr1901_modern also just had a convenient burst of productivity on his end
<whitequark> I needed to reflash roommate's BIOS
<whitequark> ended up not doing that due to a stupid bug in the SPI applet
<whitequark> but also ended up fixing the bug and a few others
<cr1901_modern> I've been playing with micropython on up5k. Just got a configuration to work that uses all 128kB of SPRAM from migen/litex
<travis-ci> whitequark/Glasgow#93 (master - 6114a21 : whitequark): The build has errored.
<plaes> whitequark: this mailinglist address you created for Glasgow, would it be possible to add it to project's readme?
<azonenberg_work> rqou: sooo if you're curious
<azonenberg_work> This is my current roadmap for having the house finished and livable
<whitequark> plaes: sure
<plaes> I would do it myself via pull request, but I seem to have lost the link :(
<whitequark> done
<plaes> yay \o/
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/3bda882a0461d816fd845635e1be07aba3d9e3da
<openfpga-github> Glasgow/master 3bda882 whitequark: README: add announcements mailing list.
<whitequark> oh wow, 116 subscribers
<whitequark> every ~4th person...
<Bob_Dole> the greenpaks are slow, right? how slow are they?
wpwrak has joined ##openfpga
<Bob_Dole> (application may be: programming ecp5)
<whitequark> "10 MHz"
<Bob_Dole> I'm now wondering how viable that is, want to fire up a bare 65186, read memory, config ecp5 with greenpak, use greenpak to chipselect from memory to fpga, go from there.
<SolraBizna> I need to learn how greenpaks initialize
<azonenberg_work> SolraBizna: The greenpak4 family, at least, is pretty simple
<azonenberg_work> You have two options
<azonenberg_work> Option 1: near-instant boot at power on, from internal ONE TIME PROGRAMMABLE memory
<azonenberg_work> the OTP is loaded via a factory test mode that uses ~all pins, so you need to socket the device in a programmer (not in system programmable)
<SolraBizna> maybe it actually is, if I system hard enough
<azonenberg_work> The same factory test mode lets you load a bitstream into internal SRAM, which is obviously volatile but can be done as many times as you want
<azonenberg_work> SolraBizna: I have access to documentation of the protocol
<azonenberg_work> it can be done but the support parts would cost >> the greenpak itself
<SolraBizna> blast
<azonenberg_work> you basically would need an analog switch on every io
<azonenberg_work> tl;dr you have ~7v Vpp on one pin
<SolraBizna> :C
<azonenberg_work> a few GPIOs are straps that have to stay constant to specify things like "load OTP", "load SRAM", "readback"
<azonenberg_work> the ADC and opamp have internal test voltages brought out to IOs
<azonenberg_work> this is literally a factory test mode that they ship
<azonenberg_work> my understanding is that greenpak was originally not a product, silego sold pre-programmed chips as "ASICs" for power sequencing in laptops, phones, etc
<azonenberg_work> it was cheaper to make a programmable device and progam than do a zillion mask respins
<azonenberg_work> Eventually they decided to start selling them blank
<Bob_Dole> the sockets are relatively cheap
<azonenberg_work> But when you understand the history of how it happened you realize why the programming is so awkward
<azonenberg_work> There is a trend toward better reconfig
<SolraBizna> indeed
<azonenberg_work> iirc greenpak5 can be runtime reprogrammed over I2C
<azonenberg_work> but i dont know if you can write the nvram or if you still need external vpp
<azonenberg_work> (and my toolchain doesnt support gp5 because i've been too busy to touch the project)
<SolraBizna> all I would need it to do would be to handle chip-select for a big MRAM and a GPIO array for bit-banging SPI
<SolraBizna> and then get the heck off the bus when the real controller is done configuring
<azonenberg_work> a coolrunner might be a worthwhile option if you dont need 5V compat
<SolraBizna> 3.3V for life
<azonenberg_work> idk about status of rqou's toolchain but they're mostly RE'd
<Bob_Dole> is it supported by the foss tools?
<azonenberg_work> Bob_Dole: The bitstream for the smallest one is 100% RE'd
<travis-ci> whitequark/Glasgow#94 (master - 3bda882 : whitequark): The build has errored.
<azonenberg_work> the larger ones are mostly known but missing a few tidbits, we know where in the ISE data files to illegally get that info
<azonenberg_work> but nobody's found a clean, legal way to discover it other than invasive silicon RE
<azonenberg_work> rqou has synthesis and par mostly working i think but i dont remember exactly
<azonenberg_work> i havent tried his toolchain
<azonenberg_work> So basically, they're close to being supported but may not be usable yet
<Bob_Dole> for some reason I think a small coolrunner actually got used in something vaguely similar, spi accelerator core for a 6502.
<SolraBizna> ugh, I might be looking at ~30 seconds for initial bootup this way
<SolraBizna> why does the iCE40 LP1k have to be so small...!?
* cr1901_modern likes smol FPGAs :(
* SolraBizna likes actually being able to use things
<SolraBizna> howabout we buy some, uncap them, and repackage them in a bigger package
<whitequark> lol
<whitequark> UP5K?
CoffeeFlux has quit [Ping timeout: 260 seconds]
CoffeeFlux has joined ##openfpga
CoffeeFlux has joined ##openfpga
CoffeeFlux has quit [Changing host]
rohitksingh_work has quit [Read error: Connection reset by peer]
<daveshah> You can probably buy dice from Lattice if your order is large enough
<SolraBizna> 5 isn't large enough
<daveshah> I doubt it
<daveshah> btw if you decap and rewirebond an UltraPlus you might be able to get 12 more IO pins
<SolraBizna> interesting
<whitequark> SolraBizna: but LP1K is fine?
<whitequark> or do you mean IOs?
<SolraBizna> an order of 5 is not large enough
<whitequark> oh
<plaes> now there's also question of the yield :)
<SolraBizna> solder test board was using about 86 IOs, FACT would use somewhere between that and 150
<whitequark> HX8K?
<SolraBizna> that's what I'm thinking now
rohitksingh_work has joined ##openfpga
<SolraBizna> the problem is programming it without flash
<SolraBizna> the datasheet says you can't program it in slave mode slower than 1MHz
<SolraBizna> if I knew for sure that was true or false, it would make things easier
<whitequark> SolraBizna: AFAIK you can do it in reality
<whitequark> I've experimented a bit
<whitequark> but I'd need to confirm again
<whitequark> I don't have my HX8K board anymore sadly
<whitequark> and Glasgow is UP5K
<SolraBizna> I would consider it a great help if you could test very slow (~100kHz) slave programmin
<whitequark> but I can easily program Glasgow arbitrarily slowly
<SolraBizna> drat
<whitequark> would UP5K work?
<SolraBizna> does UP5K have ~80-150 IOs, 3.3V compatibility, not awful power usage, ≥0.8mm ball spacing?
Bob_Dole has quit [Ping timeout: 252 seconds]
<SolraBizna> looks like it has everything I need except lots of IOs and wide spacing
<SolraBizna> if a UP5K accepts slave programming very slowly, the HX8k probably does too
<whitequark> yes, that's what I mean
<SolraBizna> ah! you meant "would testing it on a UP5K work"?
<SolraBizna> because it would be 100% better than what I have now, which is no test
<azonenberg_work> SolraBizna: if you need large ball spacing a small xilinx part might be worth looking at
<azonenberg_work> that's 196 balls (100 IO), 1mm pitch
<SolraBizna> Spartan-7 is significantly reverse engineered, right?
<cr1901_modern> No
<azonenberg_work> SolraBizna: artix-7 and kintex-7 are
<azonenberg_work> spartan-7 is based on the same fabric, the scripts should work on it
<azonenberg_work> but nobody's done the analysis
<azonenberg_work> no 7-series parts have a working f/oss toolchain yet
<azonenberg_work> It's a high priority target though
<azonenberg_work> the free-as-in-beer vendor tools do work with those chips though, and are not a horrible option until the f/oss tools catch up
<SolraBizna> whitequark: sorry if I seem especially dense right now
Bob_Dole has joined ##openfpga
<Bob_Dole> so what did I miss
<cr1901_modern> I can't sleep again but I'm useless for doing any actual work.
<Bob_Dole> how are we programming the fpga?
Bob_Dole has quit [Ping timeout: 252 seconds]
s_frit has quit [Ping timeout: 244 seconds]
Bob_Dole has joined ##openfpga
oeuf is now known as xn--trng-h15a
Patater_ is now known as Patater
<mwk> azonenberg_work: so um
<mwk> I got a basys 3 on my hands now as well
<azonenberg_work> ?
<azonenberg_work> :)
<mwk> that thing has basically a standard FTDI interface to JTAG, right?
<mwk> it should work with jtaghal?
<azonenberg_work> mwk: if it's a FTDI jtag, yes
<azonenberg_work> what fpga is it?
<mwk> artix 7
<azonenberg_work> Then yeah it should work fine out of the box
<azonenberg_work> if it's a digilent board, jtaghal works with their binary blob too
<azonenberg_work> So it guaranteed will work thatway
<azonenberg_work> that way*
<mwk> it's digilent
<mwk> but the digilent programmer I used for basys 2 doesn't recognize it
<azonenberg_work> yeah their newer stuff is mostly ftdi
<azonenberg_work> try it and see?
<Bob_Dole> rqou, not sure if solra got to ask, but is the Software to use the Smallest coolrunner in-place? (and does IT support any nvcram?)
<mwk> yeah, trying to compile libftd2xx now
<mwk> or rather find it
<rqou> the xc2c32a does work, but doesn't generate as good results as ISE
<rqou> there are no programming algorithms included right now
<rqou> so it doesn't exactly "support nvcram" in any sense
<Bob_Dole> rqou, the goal is simple: program an ice40 or ecp5 with an mram, spi ones don't support the fast-read-mode thing ice40's need at least.
<mwk> uh.
<rqou> why?
<mwk> libftd2xx is a closed piece of crap?
<Bob_Dole> because he won't touch flash. at all.
<rqou> and what does the coolrunner have to do with anything?
<Bob_Dole> and we're buying mram for other reasons
<mwk> that... is suboptimal
<azonenberg_work> mwk: There is a PR to make it work with libftdi, which is an open source not-quite-compatible implementatoin
<whitequark> hating flash is a weird idiosyncrasy
<whitequark> one of the weirder i've seen so far
<Bob_Dole> because the 65816 will have trouble programming the ecp5/ice40 that's acting as its memory controller
<azonenberg_work> mwk: as of when i started the project ten years ago, libftdi didn't work reliably with my hardware
<azonenberg_work> that may have changed
<azonenberg_work> i havent had time to play wit hit
<cr1901_modern> Just use a Mach XO2 or a greenpak and call it a day
<azonenberg_work> you can try the patch in the PR and see if it works
<rqou> ah, so you're adding yet another block of glue logic?
<mwk> "This branch has conflicts that must be resolved"
<mwk> eh
<azonenberg_work> (or not)
<mwk> that's going to be fun
<azonenberg_work> mwk: generally i replace blobs when they cause me trouble, and not sooner
<whitequark> greenpak might not be quite large enough
<cr1901_modern> On my hypothetical 65816 SBC I plan to use a greenpak (or two!) for addr decoding and clk gen
<Bob_Dole> rqou, yep
<azonenberg_work> These havent caused me much trouble
<mwk> ah well, I'll try to hack it up
<whitequark> not sure
<rqou> yeah, you can try it out
<mwk> but it seems I don't have that kind of time now
<rqou> the coolrunner does have a nonvolatile config flash
<rqou> in fact, direct sram programming does not appear to work
<rqou> but unfortunately it is currently "bring your own board" and "bring your own programming algorithm"
<Bob_Dole> if they greenpaks can actually get the ecp5, or ice40hx8k programmed, they would work for the job as well
<rqou> so you're currently on your own
<cr1901_modern> oh. gp4 is too small
<cr1901_modern> mach xo2 is prob fine
<whitequark> rqou: inb4 glasgow coolrunner programmer...
<cr1901_modern> it's nonvolatile memory is built-in
<whitequark> (ship me a coolrunner board i guess get that written)
<cr1901_modern> absolute minimum number of external parts
<Bob_Dole> assuming the x02's got nvcram, being cpld, and supported by the open tools?
<rqou> whitequark: there's currently a bikeshedding problem too
<azonenberg_work> whitequark: you dont need that, you can use jtaghal + glasgow-jtag?
<cr1901_modern> nope no open tools
<Bob_Dole> Oh hrrm
<cr1901_modern> you'll have to make sacrifices to get what you want :P
<whitequark> azonenberg_work: i ended up rewriting most of jtaghal in glasgow
<cr1901_modern> alternatively, use a microcontroller to program the fpga?
<whitequark> or more like making a JTAG HAL for Glasgow
<azonenberg_work> whitequark: lol
<whitequark> azonenberg_work: this was necessary for my MIPS EJTAG work
<Bob_Dole> what's the greenpaks lacking? SolraBizna discussed taking a 6502 mcu to bitbang the fpga
<azonenberg_work> you're turning into rqou :p
<azonenberg_work> Bob_Dole: logic capacity mostly
<azonenberg_work> ~25 LUTs
<azonenberg_work> total
<azonenberg_work> there's hard IP so you can stretch it a bit
<azonenberg_work> but theyre tiny
<cr1901_modern> Bob_Dole: Nothing inherently wrong with bitbang probably...
<cr1901_modern> Do you have a budget for a 65c22?
<rqou> there's also max V in the works
<cr1901_modern> that'll give you a shift reg to do bitbang
<whitequark> azonenberg_work: not exactly, i think; it would be hard to ship jtaghal, just like any other C++ code
<cr1901_modern> or an I/O port to do slower bitbang
<whitequark> azonenberg_work: plus there's the more general problem of "applet composition"
<Bob_Dole> the math he had for the Documentation that it HAS to be 1mhz+ of actual IO to program makes him uncertain it'll work because of the logic to do the bitbanging slowing it down
<whitequark> azonenberg_work: i.e. you can add eight JTAGs if you want but Glasgow will only expose up to 4 USB EPs
<whitequark> azonenberg_work: and you need to transfer the config for multiplexing between bitstream building and runtime
<Bob_Dole> 65C134 is the mcu he was looking at using
<Bob_Dole> I think it has one of those vias on it?
<whitequark> azonenberg_work: anyway, my stance on "rewrite everything in python" (eech) is that i will have to *both* port algorithms and concepts from other successful software like jtaghal
<whitequark> *and* support it directly
<whitequark> but in reduced functionality mode
<whitequark> i.e.: no multiplexing
<Bob_Dole> the 6522 is the VIA chip isn't it?
<azonenberg_work> whitequark: yeah i'm using big FPGAs so i can just have everything fit
<azonenberg_work> at once
<whitequark> azonenberg_work: i don't think even a virtex-7 will fit *every* combinatorial configuration glasgow provides
<whitequark> i have dozens of applets
<whitequark> and you dont want to mux an IBM floppy interface onto every pin
<azonenberg_work> yeah i dont plan on having that many odd configs
<azonenberg_work> i plan on having common stuff like i2c, spi, etc, gpio bitban
<azonenberg_work> and then relying on you to recompile the fpga to add custom features
<azonenberg_work> Which, yes, will not be instant
<azonenberg_work> I may eventually support PR for dynamically loadable applets, havent looked into PR on 7 series yet
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/12cb8bfd32bdbfc8468c9526c45ce123dd835519
<openfpga-github> Glasgow/master 12cb8bf whitequark: revB: add missing BOM.
Guest49623 is now known as gruetzkopf
gruetzkopf is now known as gruetze
<whitequark> azonenberg_work: right, glasgow and ssr do not *exactly* converge
gruetze is now known as gruetzkopf
<whitequark> glasgow is all about reconfiguration on the fly
<azonenberg_work> Yeah
<azonenberg_work> i'm mostly focusing on performance
<gruetzkopf> whitequark: amiga floppy when?
<whitequark> hence the focus on having everything in python, and also in migen
<whitequark> gruetzkopf: ship me one i guess
<gruetzkopf> same FDD interface
<whitequark> gruetzkopf: tef has *literally* predicted this a few hours ago
<gruetzkopf> different encoding
<whitequark> fucking congratulations
<gruetzkopf> generic transition mapping when
<gruetzkopf> the kryoflux people deserve to be replaced
<whitequark> wow, that bad?
<whitequark> looks like i hit a nerve
<whitequark> i know nothing about kryoflux other than their webpage being kind of insufferabke
<whitequark> le*
<gruetzkopf> "no we won't ship to anyone who'll likely image disks not their own"
<whitequark> HAHAHAHA
<whitequark> ok spite motivates me pretty well
<whitequark> should i *explicitly* market glasgow for piracy?
<whitequark> :P
<cr1901_modern> ibm format disks have rather boring copy protection schemes
<whitequark> i mean you could already use it for that, just do ibm-floppy read-raw 0 79...
<cr1901_modern> compared to the horror you can do on Apple disks
<whitequark> not that i have pushed that
<whitequark> let me unfuck the PLL/DLL i guess
<gruetzkopf> amiga HD floppies are *fun*
* cr1901_modern knows almost nothing about Amiga
<cr1901_modern> ironic considering I like 68k
<cr1901_modern> (well everything except it's encoding)
<gruetzkopf> soo they didn't replace the encode/decode block to handle the higher data rate
<gruetzkopf> but instead use half-rotational-speed drives
<gruetzkopf> (i own exactly zero of those)
<whitequark> wait
<whitequark> other than the bit time it's the same, or?
<rqou> oh, so it's like a gd-rom?
<whitequark> if yes then my *existing* code can handle that
<cr1901_modern> You can't read an Amiga disk w/ an IBM controller though AIUI (citation needed). Not that Glasgow is striving to be _only_ an IBM controller :P.
<whitequark> well the applet says ibm-floppy because uh
<whitequark> ok
<whitequark> shugart-floppy?
<whitequark> is that better?
<gruetzkopf> yeah
<gruetzkopf> amiga floppies are also MFM but their sector format is slightly less idiotic
<gruetzkopf> so they fit 880k of payload data onto a DSDD disk
<whitequark> oh so they dont use 20% of the drive for gap bytes?
<whitequark> incredible
<cr1901_modern> more than 40 tracks?
<gruetzkopf> yeah no inter-sector-gaps
<cr1901_modern> Huh, this is _very_ similar to IBM's format... (although I see a few differences)
<travis-ci> whitequark/Glasgow#95 (master - 12cb8bf : whitequark): The build has errored.
keesj_ has quit [Quit: leaving]
keesj has joined ##openfpga
<Bob_Dole> maybe an eeprom to program a 1k to program an 8k or ecp5 is the best option..
<cr1901_modern> >above 4 bytes treated as one longword for purposes of MFM encoding
<cr1901_modern> gruetzkopf: What does this even mean? MFM is encoded per bit, so why does it matter if we treat 4 bytes as a longword as opposed to individually?
<Bob_Dole> for the constraints I'm selecting parts for.
<cr1901_modern> If you reset the "0 follows a 1" flag at the end of each longword, you could get "two 1s back to back" which defeats the whole point of using MFM
<cr1901_modern> (Also, I'm not sure I like the idea of "having to rewrite the whole damn track if you just change 512 bytes" :P)
<whitequark> i like it for sure
<cr1901_modern> It's one step closer to your multi-track drifting floppy format
<whitequark> lol
inoor has joined ##openfpga
inoor has quit [Client Quit]
<cr1901_modern> whitequark: Whether it should be called shugart or ibm floppy is an interesting bikeshed; IBM PC compat floppies are using an IBM track format that the outside world talks to using an electrical interface derived from Shugart.
<cr1901_modern> So I guess it depends on whether an applet should be named based on pinout or not :)
<whitequark> other applets are called like...
<whitequark> spi-flash-25x
<whitequark> jtag-mips
<whitequark> er, -25c
<whitequark> i should rename it to -25x actually
<whitequark> so yeah, interface-device-devicekind is the usual pattern
<whitequark> shugart-floppy seems to fit
<cr1901_modern> cool
Bob_Dole has quit [Ping timeout: 246 seconds]
Bob_Dole has joined ##openfpga
wpwrak has quit [Ping timeout: 268 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
pie_ has quit [Ping timeout: 246 seconds]
pie__ has joined ##openfpga
Bike has joined ##openfpga
wpwrak has joined ##openfpga
genii has joined ##openfpga
rohitksingh has joined ##openfpga
Bike has quit [Ping timeout: 256 seconds]
m4ssi has quit [Ping timeout: 252 seconds]
GuzTech has quit [Ping timeout: 260 seconds]
m4ssi has joined ##openfpga
emeb has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
pie__ has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
pie__ has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<SolraBizna> I don't actually hate flash memory in general, per se
<SolraBizna> The kind of flash I have access to is just inappropriate for a device that needs to be reliable on a multi-decade timescale, including very long stretches of zero power and mild mistreatment
<SolraBizna> Also, it's ubiquitous so it's boring
<SolraBizna> I certainly trust flash more than I trust spinning rust storage, and I make use of both on a daily basis
m4ssi has quit [Remote host closed the connection]
<daveshah> I wonder if you could use the parallel flash mode of a Xilinx FPGA with a E(E)PROM
<daveshah> or perhaps even slave parallel mode on an ECP5 with a counter to do the addressing
<SolraBizna> We've already got a flash-free stack, except for boot-time configuration of an FPGA... without which the rest of the system is just strange jewelry
<daveshah> If E(E)PROM is OK, then I think it should work to configure an ECP5 in slave parallel mode with a few 74 series chips to do address control
<SolraBizna> My main reason for avoiding actual EEPROM (as opposed to Flash-based EEPROM) was limited write cycles... and I just realized that the EEPROM itself need only contain logic that works well enough to boot the machine, and then I could probably reconfigure it through dark magic afterward
<SolraBizna> (and yes, I do realize that even the "limited write cycles" on a Flash-based EEPROM are almost certainly more than enough for any sane quantity of logic iterations)
<daveshah> real EEPROM has >1million write cycles usually
<SolraBizna> if I were to manage to deploy over a million different iterations of the memory control and IO logic for this system, I am doing something very wrong or very interesting
<SolraBizna> (inclusive or)
<daveshah> however, I don't know if there are parallel EEPROMs big enough for an ecp5 configuration actually
<daveshah> maybe with clever use of bitstream compression
<SolraBizna> for other reasons, I'm using an iCE40 HX8k
<daveshah> oh, ok
<daveshah> then you have the 0b read command problem
<SolraBizna> indeed
<SolraBizna> there are SPI MRAMs that are perfect except for that
<daveshah> the ecp5 could actually boot from a SPI EEPROM, if it were big enough, as it uses the 03 command
<daveshah> by default
<SolraBizna> interesting
<daveshah> the smallest uncompressed bitstream is around 1MByte though
<SolraBizna> one reason to favor the "slave configuration + CPLD-based lite bus" strategy is arbitrarily compressed bitstream
<daveshah> smallest compressed bitstream for ecp5 is 99kB
<daveshah> so ecp5 could boot natively of a SPI MRAM or EEPROM I think
<SolraBizna> I was really in love with the iCE40's low power consumption, but having to abandon the LP series for the largest member of the HX series ended that
<daveshah> this supports fast read
<daveshah> "151-year" retention (does it fail in the 152nd year??)
<SolraBizna> o_o
<daveshah> 1E14 write cycles, should be enough design mistakes?
<SolraBizna> The only problem with FRAM is that it's theoretically a destructive-read technology
<SolraBizna> If I were making an FRAM-based EEPROM I would try to include enough capacitance to do the rewrite "come what may", but I haven't found anything in the various datasheets to indicate that the manufacturer did that
<gruetzkopf> core memory 2.0
<SolraBizna> Otherwise, using FRAM to configure the FPGA would be a big plus, since "use weird memory technologies, down with DRAM and flash!" is a main design goal here
<SolraBizna> *Aside from that problem
<etrig> what would be the best choice of part to emulate something like dallas timekeeper nvram with fram?
<etrig> assuming something 5v tolerant to add the extra needed ce strobe on access
<SolraBizna> actually... if I just include a big enough decoupling capacitor, the destructive read is probably moot
<daveshah> it wouldn't even need to be that big
<daveshah> but you would want a diode or something to guarantee the FPGA loses power before the FRAM
<SolraBizna> especially since we already have a reset controller that will drive CRESET low as soon as the voltage falls below 3V
<daveshah> yup
<SolraBizna> problem solved, hooray!
<SolraBizna> now I can be excited about this project again instead of sad
<prpplague> sad project is sad
xn--trng-h15a is now known as oeuf
Laksen has joined ##openfpga
<Bob_Dole> SolraBizna, so what're we doing here? FRAM with big cap? eeprom booted ice40 booting something bigger? mram booted ecp5?
<Bob_Dole> all of the above at once?
oeuf has quit [Ping timeout: 264 seconds]
<SolraBizna> FRAM with normal-sized cap because the reset controller will squelch the FPGA long before there isn't enough voltage to fix a byte
egg has joined ##openfpga
<TD-Linux> the fram I used explicitly mentioned that it had enough capacitance to complete writes on-die
<SolraBizna> which one was it?
<TD-Linux> one of the fujitsu soic-8 parts
<Bob_Dole> for a matter of Curiosity, what would it take to "make something", potentially Dumb, for retrocomputers using your floppy work?
<Bob_Dole> I'm kinda unfamiliar with floppies In Practice, so is this something controlling the drive through the bus interface or does a specific model need sourced to Directly Implement it?
prpplague has quit [Read error: No route to host]
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/be4f931070120167ee1be09892a12e789d6ab3ba
<openfpga-github> Glasgow/master be4f931 whitequark: applet.shugart_floppy: new applet....
<plaes> what's this RN1..RN4 in the BOM?
<plaes> revB
<TD-Linux> resistor network
<plaes> oh, indeed
<travis-ci> whitequark/Glasgow#96 (master - be4f931 : whitequark): The build has errored.
Laksen has quit [Quit: Leaving]
<sorear> SolraBizna: you're aware the ice40 parts have NVCM right? no need to add greenpaks *just* for bootup
<TD-Linux> whitequark, the other thing about kryoflux is that they intentionally don't document the format that their archiving software writes to, because they don't trust anyone else to make "correct" floppy dumps
<Bob_Dole> sorear, i thought nvcm wasn't supported by icestorm?
<sorear> Bob_Dole: you can fix that
<sorear> i can't imagine it'd be difficult if you have the budget for a few test boards
<Bob_Dole> I've been thinking about that though
<sorear> at worst you could make a board that MITMs icecube
<daveshah> Yes, it shouldn't be hard to implement if you can spare a few boards
<Bob_Dole> getting a 1k or whatever and just turn it itno a memory controller ASIC
<daveshah> You can look at the svf files Lattice Diamond generates to figure out the algorithm
<cr1901_modern> I definitely misread this as "swf" files. That would be the day...
<daveshah> Knowing EDA tools, nothing is impossible
<daveshah> istr, actually, that NVCM writes are something like sending a special unlock command then treating it like a normal SPI memory
<daveshah> But I didn't look in much detail
<sorear> there was some speculation in this channel many months ago that the NVCM might be an ordinary commercial SPI PROM die integrated in the package
<whitequark> sounds about right
<whitequark> but
<whitequark> oh no buts
<TD-Linux> has no one actually decapped one
<TD-Linux> also putting an extra die in the package sounds expensive
<sorear> nope, nobody has
<Bob_Dole> chinese SoCs do it a lot
<rqou> chinese fabs also don't have flash IP
eightdot_ has quit [Quit: Reconnecting]
eightdot has joined ##openfpga
<TD-Linux> maybe it's time I learned how to decap
<daveshah> It's definitely not another die
<daveshah> There are wafer scale packages too small to fit one in
<daveshah> There was a low res decap of an ice40 on birdsite a while ago
<Bob_Dole> you could figure out if it was another die easier than decap, just xray it
kem_ has joined ##openfpga
futarisIRCcloud has joined ##openfpga
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/0971ff276876e9115022d270b5710975e4aed3c3
<openfpga-github> Glasgow/master 0971ff2 whitequark: applet.shugart_floppy: add some docs.
GenTooMan has joined ##openfpga
s_frit has joined ##openfpga
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/76fd124b311ec15903f00c4c6c3c1958b82ab4dc
<openfpga-github> Glasgow/master 76fd124 whitequark: applet.shugart_floppy: improve dirty clock recovery, fix docs.
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/cb1fbcf41e4818cdb9450a28c1f1ce02d16a9272
<openfpga-github> Glasgow/master cb1fbcf whitequark: applet.shugart_floppy: pedantic doc fixes.
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/d6d70b776ccf51e23baf4aa7d1df5bc1030ea955
<openfpga-github> Glasgow/master d6d70b7 whitequark: applet.shugart_floppy: bring diagram in line with PLL algorithm.
<travis-ci> whitequark/Glasgow#98 (master - 76fd124 : whitequark): The build has errored.
<travis-ci> whitequark/Glasgow#99 (master - cb1fbcf : whitequark): The build has errored.
<travis-ci> whitequark/Glasgow#100 (master - d6d70b7 : whitequark): The build has errored.
<SolraBizna> sorear: yes, but my reading of the datasheet made me believe that programming the NVCM makes it unable to be externally configured anymore
<Bob_Dole> I think that's part of the "if you're willing to use a couple of extra boards"
<Bob_Dole> SolraBizna, how you would you feel about.. adding ethernet. and then putting expansion hardware on ethernet, including maybe a pci host, which apparently can run under 33mhz. like 10mhz is doable.
<daveshah> SolraBizna: AIUI if you enable NVCM then boot from SPI flash is then unavailable
<daveshah> It can still be programmed as a SPI slave though
<SolraBizna> that would make sense
<SolraBizna> Bob_Dole: at that point I could just put PCI on
<Bob_Dole> well yes, someone linked to AVR MCUs, which are all Slow. very Slow. bitbanging pci.
<Bob_Dole> but PCI-over-Ethernet is ridiculous, hilarious, and you can add as many slots as you want with a switch.
<SolraBizna> and a lot of expensive hardware
<gruetzkopf> there's a spec for that
<gruetzkopf> and an ethertype
<gruetzkopf> i've semi-commited to building something like that
<Bob_Dole> oh my
<Bob_Dole> SolraBizna, honestly my original suggestion of just getting a single slot working and then use various kinds of PLX cards to get more if needed is the Sane option
<SolraBizna> having a separate IO board is partly so that I don't have to worry about any of this right now
<whitequark> whatthe fuck is pci over ethernet
<whitequark> cursed
<gruetzkopf> explicitely pcie
<gruetzkopf> they tunnel TLPs
<TD-Linux> is it over ip or raw ethernet
<gruetzkopf> raw eth
<gruetzkopf> i need to get some SFP+ optics which do 8G
<gruetzkopf> (and also replicate the "lol let's hook up a 4G-SFP directly to PET/PER" experiment
WilhelmVonWeiner has quit [Quit: Lost terminal]
WilhelmVonWeiner has joined ##openfpga
<SolraBizna> Bob_Dole: oh, THAT'S why you want me to make a PCI over Ethernet thing
<Bob_Dole> what
<Bob_Dole> because it's hilarious?
<SolraBizna> because you want to make a giant video card array
<Bob_Dole> That has been a former idea.
<Bob_Dole> being able to get 128 GPUs all sharing 16mhz 64bit PCI on a single system would also be a hilarious implementation though.
<Bob_Dole> on an iommu'd x86 vm on a risc-v softcore on a 40 dollar fpga.
<azonenberg_work> lololol
<gruetzkopf> SolraBizna: i want to build it
<gruetzkopf> i'll do pcie if rqou does ecp5 serdes
<azonenberg_work> gruetzkopf: i have another fun fpga project i want to do
<Bob_Dole> (I actually considered a rack with a backplane that'd take cards each with like 5 ecp5's each that'd do tiled rendering, with a host fpga, that would connect via cables to a host to act as a single gpu despite being a large rack.)
<azonenberg_work> big kintex7 or maybe small kintex ultrascale
<azonenberg_work> in a 1U case with a [Q]SFP+ port on the front
<azonenberg_work> and a bunch of m.2 sata ports on the backplane
<azonenberg_work> basically m.2 to iscsi bridge
<gruetzkopf> so if consumer u.2 disks were a thing
<azonenberg_work> i'd use sata so i could only use one transceiver per ssd, vs pcie would need four and then the ethernet interface would become the bottleneck
<gruetzkopf> i'd already have one in my laptop
<gruetzkopf> despite having to manually steal lanes from the gpu to do it
<gruetzkopf> pcie SSDs will run at x1
<gruetzkopf> x1 is mandantory
<azonenberg_work> gruetzkopf: yeah but i think the sata protocol would be easier to do than nvme
<gruetzkopf> sure
<azonenberg_work> in terms of bridging to iscsi
<gruetzkopf> if you're not feeding that box pcie over ethernet that is :P
<azonenberg_work> no, i wanted to make it be a SAN-in-1U box
<Bob_Dole> I never proposed it, for multiple reasons, including not knowing how tiled rendering needs its memory arranged, and various other concerns.
pakesson has quit [Ping timeout: 268 seconds]
pakesson has joined ##openfpga
Bike has joined ##openfpga
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/91a783d24aa162cca2fc7e007171e2b34f67e0d2
<openfpga-github> Glasgow/master 91a783d whitequark: applet.shugart_floppy: eliminate K.C2 sync, update docs....
<travis-ci> whitequark/Glasgow#101 (master - 91a783d : whitequark): The build has errored.
genii has quit [Remote host closed the connection]