<awygle> i wish ecad tools that use fixed-width fonts made the letter width equal to the default grid width.
m_t has quit [Quit: Leaving]
<awygle> whitequark: why are pin 34 (PA1/INT1) and pin 40 (PA7/FLAGD/SLCS) on the FX2 shorted together on glasgow?
<awygle> my best guess is lack of pins
<openfpga-github> [Glasgow] awygle pushed 1 new commit to rev-c: https://github.com/whitequark/Glasgow/commit/364410d985b70f883665937c62749f29cb13f4db
<openfpga-github> Glasgow/rev-c 364410d awygle: Refactor FX2 into hierarchical subsheet.
unixb0y has quit [Ping timeout: 244 seconds]
unixb0y has joined ##openfpga
digshadow has quit [Ping timeout: 244 seconds]
digshadow has joined ##openfpga
wpwrak has joined ##openfpga
<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
<whitequark> so now this works: https://hastebin.com/omedurovug.py
<awygle> damn, sweet
drawkula has quit [Quit: WeeChat 2.1]
drawkula has joined ##openfpga
<whitequark> awygle: do you know any good self-synchronizing packetizing encodingS?
<whitequark> there's currently an issue where resetting an applet's gateware leaves junk in buffers
<whitequark> and well, for multiplexing applets (i.e. the case where applets don't own USB interfaces) this is mandatory
<whitequark> there's "consistent overhead byte stuffing" but it requires a ton of lookahead
bibor has joined ##openfpga
azonenberg_work has joined ##openfpga
m_t has quit [Quit: Leaving]
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/12a7b0f06aed7702051d0a83d8cb1b48166a2e43
<openfpga-github> Glasgow/master 12a7b0f whitequark: applet.uart: add tests.
<travis-ci> whitequark/Glasgow#15 (master - 12a7b0f : whitequark): The build passed.
pie_ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 244 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Client Quit]
<mithro> Morning everyone!
<reportingsjr> good morning
<daveshah> morning
<awygle> whitequark: yeah COBS is good but I usually just use SLIP (the lazy one which only has END, ESC, ESC_ESC and ESC_END)
pie_ has joined ##openfpga
pie__ has quit [Ping timeout: 248 seconds]
Bike has quit [Quit: Lost terminal]
<whitequark> awygle: that has the potential for unbounded expansion
<awygle> only 2x
<awygle> err, 2x+1 I guess if you count end
<whitequark> ok, 2x+1
<whitequark> still a lot
<whitequark> in case you're streaming data every cycle that might cost you
<awygle> yep but it's easy and small and I rarely hit pathological cases
<awygle> If you have the resources COBS is better although it's not actually constant overhead iirc, just mostly constant
<awygle> (tbf it does say "consistent" not constant)
<awygle> I last did this on an msp430 so smallness was key
<whitequark> COBS introduces latency
<awygle> yep
<whitequark> so it doesn't work for interactive cases
<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
<daveshah> Oh, that's odd
<mithro> Problem is I don't have a good example of it working to compare too
<daveshah> It certainly doesn't look right
<daveshah> Is this just a simple adder or counter?
<mithro> daveshah: Actually, I should try that...
<daveshah> Is this a SoC?
<daveshah> I know picorv32 has a few structures that could confuse a bad carry packer implementation
<mithro> Yeah - this is a SoC
<daveshah> Bad place to start
<daveshah> I know my first nextpnr carry packer attempt exploded one of the chains in picotv8
<daveshah> *picorv32
<mithro> daveshah: Looking at the eblif, the SB_CARRY connects look pretty normal
<daveshah> mithro: so these are totally independent carries, do they have an I1/I2 connection even?
<mithro> daveshah: Totally independent, just 8 SB_CARRY objects inside a tile
<daveshah> mithro: but how are you representing the connections from SB_CARRYs to logic/fabric?
<mithro> daveshah: Top level pins
<mithro> daveshah: The packer doesn't know anything about the fabric
<mithro> The only weird things seems to be that I0 is always false on the SB_CARRY objects
<daveshah> mithro: that sounds like a counter type pattern
<daveshah> Where one input is a constant
<mithro> I'm going to go find some lunch, bblr
azonenberg_work has joined ##openfpga
<awygle> oh lol of course ZipCPU has an article on getting multiple bits from an lfsr
<daveshah> And formally verifying it of course
<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."
<Zorix> next up.. 6581..right? heh
<pie_> this is really cool thanks qu1j0t3 https://www.youtube.com/watch?v=O1bY66X1JKA
<qu1j0t3> it is isn't it
<qu1j0t3> wish i had his talent
<pie_> at first i thought the big black box was commercial hardware from its look
<qu1j0t3> right
<qu1j0t3> i assume he's an engineering student but i didn't check
<pie_> oh there is commercial hardware there nvm lol
<pie_> psu and stuff
<pie_> no no no why does he put it away make more animations
<awygle> oh wooow that's really cool
<awygle> I thought it was all one long exposure until he showed the cubes falling
<awygle> I wonder how automated the backend is. Given all the robots I have to assume "very".
<pie_> also given the number of frames, id hope very
<pie_> thats a real engineers wall right there https://youtu.be/W41uh2bS2Yc?t=228
azonenberg_work has joined ##openfpga
<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
<daveshah> Have the VPR docs died for you too?
azonenberg_work has joined ##openfpga
<rqou> o/ azonenberg_work
azonenberg_work has quit [Ping timeout: 264 seconds]
<mithro> daveshah: I think the issue "if (!net_id || atom_ctx.nlist.net_sinks(net_id).size() != 1) { /* One fanout assumption */"