<Bob_Dole>
OhGodAGuardian2, say I eventually plan on getting a competent individual to design an FPGA board for reasons that aren't mining and external SRAM caches might be something for it. mouser has some relatively fast looking ones that could get to like 8MB relatively cheap, what would it take for, re: cryptonight, to best a bunch of ddr3?
Mimoja has quit [Quit: Ping timeout (120 seconds)]
Mimoja has joined ##openfpga
finsternis has quit [Remote host closed the connection]
<azonenberg_work>
sorear, Bob_Dole: it is enough for ecc
<azonenberg_work>
generally speaking, you do bursting
<azonenberg_work>
Also, commonly ram interfaces are wider
<azonenberg_work>
Most DIMMs are 64+8 bits wide so you use a (64, 72) Hamming code
<Bob_Dole>
I was hoping 9bit wide SRAMs would be cheaper, so we could do 8x9.
<whitequark>
azonenberg_work: do you ECC then line code
<whitequark>
or line code then ECC?
<azonenberg_work>
whitequark: for sram? there normally isnt any line coding
<azonenberg_work>
there's control plane signals like address and write enable
<azonenberg_work>
but thats it
<zkms>
what about DRAM scrambling and stuff
<azonenberg_work>
Not required, but if there is scrambling it would be below the ecc
<azonenberg_work>
Scrambling has to be the lowest layer of a protocol otherwise it provides no real benefit
* zkms
nods
<whitequark>
azonenberg_work: no not sram
<whitequark>
more like
<whitequark>
floppies
<whitequark>
azonenberg_work: how do you make sure that ecc is still effective after descrambling
<azonenberg_work>
whitequark: so, the line code has to be the lowest layer because its goal is to provide a signal with spectral properties amenable to the storage/transmission medium
<whitequark>
right
<whitequark>
i thought so
rohitksingh_work has joined ##openfpga
<sorear>
whitequark: if the scrambling is just XOR with a keystream, it won’t increase the number of bit errors
<sorear>
fancier line codes are more interesting; I wish I knew more about the state of the art here
<whitequark>
sorear: right, i'm thinking something like 8b10b
<sorear>
so uh
<azonenberg_work>
whitequark: so generally ecc used for something like RAM is SEC-DED
<azonenberg_work>
with a smallish block size
<azonenberg_work>
ECC used for long-haul transmission generally has a much larger block size and can handle loss of a larger amount of data
<whitequark>
oh hm
<azonenberg_work>
Sometimes you'll do things like (at the cost of latency) striping many ecc blocks such that each line code symbol only has a few bits from each block
<azonenberg_work>
thus total corruption of one symbol doesn't corrupt any block beyond recovery
<azonenberg_work>
Other times you'd use something like a BCH code with a bigger block size
<whitequark>
oic
<SolraBizna>
interleaving (striping each line code symbol across multiple blocks) is great if your noise is "bursty"
<zkms>
ＬＤＰＣ
Bob_Dole has quit [Read error: No route to host]
<SolraBizna>
Bob_Dole wasn't using interleaving, and look at him now
<azonenberg_work>
SolraBizna: yeah it all depends on the characteristics of your errors
<azonenberg_work>
are you concerned about SEUs? bad flash cells from the factory?
<azonenberg_work>
RF interference?
<azonenberg_work>
routers between you and the endpoint dropping packets?
<azonenberg_work>
(if you stripe ECC far enough with big buffers you can even reconstitute an entire lost packet)
<SolraBizna>
whitequark is currently doing floppy stuff, so striping probably won't benefit her
<azonenberg_work>
When you get an error, do you KNOW there was an error?
<azonenberg_work>
a lot of codes can handle X errors at known bit positions and Y undetected errors, with X > Y
<sorear>
conversely, if you're using something more like classic Reed-Solomon, you *don't* want bit-level interleaving because the code can correct a certain number of wrong (multi-bit) digits
Bob_Dole has joined ##openfpga
<sorear>
concur with azonenberg_work about the differences between RAM (where people care about shaving off the last ns of coding delay at the expense of %-level capacity) and bulk storage (where a few ns for 1% is a great trade)
<Bob_Dole>
wat
azonenberg_work has quit [Ping timeout: 268 seconds]
<sorear>
one cute thing Rocket does for the D-cache (I assume commercial chips do more of the same) is to allow subsequent instructions to use the result of a load *before* the ECC logic runs; if the ECC logic discovers it needs to flip a bit, the pipeline is flushed
<sorear>
because saving 0.1ns on D1$ reads is worth the trouble…
<Bob_Dole>
brb.. hopefully my graphics drivers aren't still screwed.
Bob_Dole has quit [Remote host closed the connection]
ayjay_t has quit [Read error: Connection reset by peer]
rohitksingh_work has quit [Ping timeout: 268 seconds]
<sorear>
whitequark: if I were trying to store as much data as possible on a commercially available floppy disk using glasgow, before trying to design a line code I'd be doing write tests with test patterns - what's the shortest distance between edges that can be recognized? can the disk faithfully record phases beyond that limit?
pie__ has quit [Ping timeout: 245 seconds]
<SolraBizna>
and make sure to store test floppies between two large CRTs for a few weeks
<sorear>
gonna assume here that it's fine to have an 80-sector disk where each track is one huge sector
<cr1901_modern>
Actually even that second link doesn't really give you a "noise model" of the media surface. It's handwaved away as "Time-offset Gaussians superimposed onto each other". The read head acts as a low pass filter, so that's another limit.
<cr1901_modern>
If you try to use the 1.2MB data rate on a 360kB floppy, you'll mostly get garbage data (with some success here and there). Thus the limit of the magnetic media is flux transitions "somewhere between 0.75*250kbps and 0.75*500kbps".
<cr1901_modern>
(0.75 is the average number of transitions per data bit of a floppy)
m4ssi has joined ##openfpga
lovepon has quit [Ping timeout: 276 seconds]
rohitksingh has quit [Ping timeout: 252 seconds]
GuzTech has joined ##openfpga
rohitksingh has joined ##openfpga
pie__ has quit [Ping timeout: 246 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
pie_ has joined ##openfpga
rohitksingh has quit [Ping timeout: 260 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
marcan is now known as nekoengineer
nekoengineer is now known as marcan
<felix_>
whitequark: fyi: i repaired and reassembled my tb16 dock; really needed that working again for my business. didn't get a good trace of the control channel, since it seems to use a higher frequency than expected
s_frit has quit [Ping timeout: 240 seconds]
s_frit has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
s_frit_ has joined ##openfpga
s_frit has quit [Ping timeout: 240 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
GuzTech has quit [Quit: Leaving]
wpwrak has quit [Ping timeout: 252 seconds]
wpwrak has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
egg is now known as Guest61541
Guest61541 has quit [Killed (livingstone.freenode.net (Nickname regained by services))]
Guest61541 has joined ##openfpga
emeb has joined ##openfpga
m4ssi has quit [Ping timeout: 246 seconds]
m4ssi has joined ##openfpga
<mithro>
Can someone throw me some names of things that are kind of "part fpga, part ASIC" type flows? Things like where a bunch of chips might share the bottom layers and then have a couple of custom metal top layers?
m4ssi has quit [Remote host closed the connection]
emeb has quit [Ping timeout: 245 seconds]
emeb has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
Guest61541 is now known as oeuf
oeuf is now known as uovo
uovo has quit [Quit: moo.]
Guest61541 has joined ##openfpga
Guest61541 is now known as oeuf
pie__ has quit [Ping timeout: 272 seconds]
Bob_Dole has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
fseidel_ is now known as fseidel
pie_ has joined ##openfpga
<azonenberg_work>
mithro: structured asic?
<azonenberg_work>
easic is basically a mask-rom FPGA
<azonenberg_work>
programmed by a single via layer
pie_ has quit [Ping timeout: 240 seconds]
Miyu has quit [Ping timeout: 252 seconds]
<sorear>
I've seen "gate array", and I sat through a presentation once by a vendor that calls their version "metal-configurable standard cell"
pie_ has joined ##openfpga
pie__ has joined ##openfpga
<azonenberg_work>
sorear: yeah i remember reading a while ago that on a modern foundry something like half the overall mask cost is making the transistors
<azonenberg_work>
and the other half is the rest of the mask set
<azonenberg_work>
So you can have a full metal stack customization for half the cost of a custom asic
<azonenberg_work>
or you can have via programmed for like 5% the cost
pie_ has quit [Client Quit]
pie_ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<whitequark>
felix_: *nod* thanks anynow!
<whitequark>
*anyhow
<whitequark>
I have a different TB3 device now that I can trace myself
<awygle>
do we know anything about whether internal FPGA routing buffers are, like, symmetrical?
<awygle>
i know one of the reasons commonly cited for not routing clocks through general fabric is potential waveform asymmetry but it's never been clear to me what the mechanism for that would be
hamster153 has quit [Quit: Page closed]
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 272 seconds]
<sorear>
awygle: aren't they usually just (4/6 transistor) tristate buffers?
<sorear>
which, well, CMOS, so the rise and fall times are going to be different