<rqou>
digshadow: what happened to my siliconpr0n account?
<digshadow>
rqou: take a guess
<rqou>
ok then
<rqou>
remove all of my uploads please
<digshadow>
what do you want removed specifically
<rqou>
all the pages that i've uploaded
<digshadow>
I can remove everything in the rqou namespace, will that suffice?
<rqou>
yes, and the secret one
<rqou>
awygle: that was painstakingly manually created; i recommend writing a script for it
<prpplague>
a script written in node.js
<prpplague>
for maximum pain
<digshadow>
rqou: the following have been removed: ./archive/data/media/protected/rqou ./archive/data/pages/rqou ./archive/data/media/tps61029_neo5x.jpg ./archive/data/pages/protected/rqou
<digshadow>
Please let me know if you have any additional questions or concerns
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
flaviusb has quit [Quit: Leaving.]
pie_ has joined ##openfpga
rohitksingh has joined ##openfpga
Bike has quit [Quit: Lost terminal]
pie_ has quit [Ping timeout: 240 seconds]
<sorear>
wtf is going on here
<rqou>
i am tired of the symbiflow team acting in bad faith
rohitksingh has quit [Quit: Leaving.]
<sorear>
that doesn't explain why you suddenly have a problem with siliconpr0n
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
m_t has joined ##openfpga
<cr1901_modern>
._. what the hell?
<q3k>
it's all very confusing
goldfinger has joined ##openfpga
X-Scale has quit [Ping timeout: 264 seconds]
rohitksingh has quit [Ping timeout: 256 seconds]
wolfspraul has joined ##openfpga
X-Scale has joined ##openfpga
<whitequark>
awygle: yes
<awygle>
Mk I'll split it in Rev c
<whitequark>
yup
<awygle>
I selected the resistor part numbers btw so I think we're ready to prototype Rev b
<whitequark>
excellent. i'll go over this later today i think
Bike has joined ##openfpga
<whitequark>
awygle: woo, i battled asyncio and migen and won
<whitequark>
i managed to figure out a way to run migen simulator and asyncio together
<awygle>
other common mentions are ppp and ax.25 but I don't know them well
<cr1901_modern>
ppp is involved
<awygle>
wait is the framing on KISS literally SLIP? lol
<awygle>
oh HDLC is what I was trying to remember
<awygle>
but that's bit stuffed so no
<whitequark>
right
<whitequark>
I'm thinking something like
<whitequark>
o wel, no idea
<awygle>
yeah I can't think of anything low overhead and also low latency on both ends
<awygle>
if (e.g.) RX latency doesn't matter then maybe there's something
<cr1901_modern>
bitstuffing isn't on average constant overhead?
azonenberg_work has joined ##openfpga
<daveshah>
Random idea, may not work, but what about a scrambler plus slip?
<daveshah>
You could then put a reasonable statistical upper limit on the number of added bytes
<daveshah>
You'd néed a small extension to slip to sync scrambler state too
<whitequark>
hmm
<cr1901_modern>
What about using an RLL coding and deliberately put in a coding violation detector to delimit packets?
<awygle>
wait we just designed usb oops
<awygle>
Bitstuffing is worst case n bits of overhead, but it's also a huge pita to deal with outside an fpga
goldfinger has quit [Quit: Page closed]
<cr1901_modern>
(Pedantry: Doesn't USB bit stuff once every 5 or 6 bits? So if using USB as a model, it would be slighly more than n bits?)
<cr1901_modern>
more than n bits of overhead*
<awygle>
yeah okay, that's fair. O(n) though :-P
<awygle>
and usb uses Manchester violations not rll violations
<cr1901_modern>
I was thinking more like ancient magnetic media w/ the RLL example, not USB :)
<awygle>
yup, I just got my wires crossed
<awygle>
interesting how similar rll codes are to 8b/10b
<awygle>
daveshah's LFSR'd SLIP idea isn't bad. could reset at the beginning of every packet even. prevents the "I am sampling an 8 bit port whose value is 0C" problem
<awygle>
err C0 whatever
<cr1901_modern>
C0?
<awygle>
END in slip, one of the escaped bytes
<awygle>
Glasgow has the unique problem that (absent some kind of RLE or delta coding) it's quite likely to produce a single byte many times in a row, so the scrambling adds a lot of value where it might not elsewhere
<cr1901_modern>
I'm not actually sure I really fully understand the problem w/ SLIP... is it being unable to determine whether SLIP escape codes are actually escape codes versus data?
<daveshah>
yeah, and the risk as awygle mentions that sampling the "wrong" constant value could effectively double the data rate with raw SLIP
<cr1901_modern>
I don't follow :(
<awygle>
right. You need to tell END from C0 as data. you do that by turning C0 as data into ESC, ESC_ESC which is two bytes. if your packet is all C0s, you've doubled its size
<cr1901_modern>
oh
<awygle>
er ESC, ESC_END but close enough
<cr1901_modern>
well that would explain how lfsr helps you (as long as both sides agree on the seed)
<daveshah>
yeah, the SLIP framing would also reset lfsr state
<awygle>
yup
<awygle>
reset every time you see END
<awygle>
lfsr can be short
<cr1901_modern>
The lsfr would be used to figure out which bit is in which position?
<awygle>
or just XOR'd into the stream before escaping to turn a long string of C0 into literally anything else
<cr1901_modern>
sounds cool
azonenberg_work has quit [Ping timeout: 260 seconds]
<awygle>
you still have to allocate 2x memory because a pathological case does exist, but it isn't "constant data" so it's less likely in our scenario
<daveshah>
depends, I would imagine in a 256 byte packet the chance of the pathological case happening is low even if everyone in the world uses a glasgow until the heat death of the universe
<awygle>
okay fair, you can decide to guarantee an X percent probability of not overflowing. but memory is cheap so I'd just 2x it to 512 bytes.
<daveshah>
some crappy maths (likely tainted by bad rounding and/or memory of stats knowledge) suggests 22 extra bytes in 256 already has a probability of 1e-16
<awygle>
Or de-stuff inline on receive which is what I did with my msp
<awygle>
it's just a one-bit state machine
<cr1901_modern>
awygle: why do you call "de-XORing" de-stuffing?
<cr1901_modern>
or am _I_ crossing wires now
<awygle>
cr1901_modern: the de-stuffing is the turning of ESC, ESC_END back into C0, taking place after the de-XOR
<awygle>
that form of escaping is also called byte stuffing
<cr1901_modern>
ahh... wait
<cr1901_modern>
I thought the xor would happen and _then_ the byte stuffing
<cr1901_modern>
b/c the xor is what decreases the likelihood of needing to byte stuff in the first place
<daveshah>
Yeah, that's what I would think too
<awygle>
Oh yeah okay, my bad
<awygle>
De byte stuff then de xor
<awygle>
Brain lapse, it's still early, it's... 11am?!
* awygle
gets out of bed
<cr1901_modern>
>awygle: it's just a one-bit state machine
<cr1901_modern>
What's the state machine- IN_ESC, NOT_IN_ESC?
<awygle>
Yup
<awygle>
NOT_IN_ESC forwards everything but ESC and END, transitions to IN_ESC on ESC. IN_ESC converts and forwards ESC_ESC and ESC_END, errors on everything else
<awygle>
Depending on how you count you need another bit for ERROR and DONE
<cr1901_modern>
Depending on how I count?
<awygle>
Whether you count ERROR and DONE as states or not
<cr1901_modern>
well, normally I count by starting at 1, and then 2
<cr1901_modern>
ahh
<awygle>
When I implemented it those both just restarted the state machine so they didn't count as states
<cr1901_modern>
cool!
<awygle>
yup :-) I like slip
<awygle>
Really my only problem with it is it's not really compatible with DMA. you need an up front packet length and you can't really have one with slip
<awygle>
without walking the whole packet anyway
<cr1901_modern>
not happening on msp430
<awygle>
big waste of time yeah. I originally had an intermediate buffer I DMA'd into but then I realized it was slower than just interrupts
<cr1901_modern>
In any case, the lfsr idea sounds pretty good as long as the fail condition is tested w/ "known to be pathologically large" strings :P
<daveshah>
Well, usb isn't exactly known for giving guaranteed bandwidth anyway
<daveshah>
But with a decent scrambler anything other than a deliberate attack should be fine
<awygle>
is there a tricky way to advance an lfsr more than one bit per cycle? Last time I did this I made a 255 byte table.
<daveshah>
I wonder if 8 differently seeded LFSRs would work?
<mithro>
I can't figure out what I'm doing wrong with these carry chains in vpr
<awygle>
how would you do that? the naive solution just has you updating 8 lfsrs one bit per cycle, still costing 8 cycles
<awygle>
oh you're thinking hardware lol
<daveshah>
Hehe
<awygle>
nvm I get it
<daveshah>
mithro: is this to do with the I3 mux or the constant input mux
<mithro>
daveshah: At the moment - I just have a totally independent SB_CARRY chain
<mithro>
But I can't convince vpr to pack more than a single SB_CARRY into one tile
<awygle>
hardware focused of course but the math is invariant
azonenberg_work has quit [Ping timeout: 265 seconds]
<X-Scale>
https://monster6502.com/ -> "Our next appearance will be at the 2018 Vintage Computer Festival West, August 4-5 in Mountain View, California."
<azonenberg_work>
awygle: you talking about line coding for glasgow in logic analyzer mode?
<azonenberg_work>
Regardless of what you decide to go with, I *strongly* recommend going with RLE for any FPGA-based LA
<awygle>
azonenberg_work: something like that? whitequark asked about packet encodings, not sure of the exact context
<azonenberg_work>
you get sooo much deeper captures out of it especially for things like buses that are idle between transactions
<azonenberg_work>
As far as uart line codes, the goal is to ensure you recover proper packet sync if a glitch on the line drops/duplicates/whatever a byte?
<awygle>
I think given the ratio of the io performance to usb speeds, on a and b at least we can just stream direct to host
<awygle>
I could be wrong though
<azonenberg_work>
50 Mbps * how many pins?
<awygle>
16. So yeah, incorrect lol
<azonenberg_work>
50 * 16 Mbps = 800 Mbps, then 350-400 Mbps is probably useable max capacity after usb encoding overhead
<azonenberg_work>
you're over 2x that
<awygle>
yup
<azonenberg_work>
You see why i went with gig-e for the starshipraider prototype / 10g for the full version now? :p
<awygle>
I originally was thinking 8 and its
<awygle>
*bits
<azonenberg_work>
(note also that ethernet solves all of these framing issues for you)
<awygle>
anyway to your uart question, basically yes, but it's not a UART, it's the weird fifo thing between the fx2 and the ice40, I assume
<awygle>
which is an 8 bit parallel interface. same problem with losing bytes and resyncing though.
<pie_>
woui wonder if there would be any point to some kind of nested RLE
<pie_>
s/woui/i/
* awygle
is having a real two-take kind of day
<azonenberg_work>
meanwhile i'm in the middle of moving and just hopping on here over lunch
<awygle>
yeah how's that going?
<azonenberg_work>
my lab is almost all boxed up, all the furniture is gone
<azonenberg_work>
the movers took everything big
<azonenberg_work>
we have a bunch of little stuff, some clothes, a few things in the fridge, etc that still have to go
<azonenberg_work>
gonna be making a trip over to the hotel with a bunch of our stuff in a bit
<azonenberg_work>
The new house is still far from livable :p
<azonenberg_work>
(sheetrock party next weekend anyone?)
<azonenberg_work>
only half kidding, i do plan to be hanging all weekend
m_t has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]
wpwrak has quit [Read error: No route to host]
wpwrak has joined ##openfpga
<mithro>
Back now - I'm obviously missing something about how the carry-chains work in VPR