<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.
<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
<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>
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.
<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
<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?
<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>
"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?
<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
<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.