richbridger has quit [Remote host closed the connection]
richbridger has joined #glasgow
<d1b2>
<konsgn[no-Mic]> alright, time to take a break and work on an old project similar to glasgow, Ft601+ice40
Stary has quit [Ping timeout: 260 seconds]
Stary has joined #glasgow
GNUmoon2 has quit [Remote host closed the connection]
Twix has quit [Ping timeout: 260 seconds]
Twix has joined #glasgow
Twix has quit [K-Lined]
Twix has joined #glasgow
Twix has quit [K-Lined]
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 245 seconds]
PyroPeter_ is now known as PyroPeter
d_olex_ has joined #glasgow
d_olex has quit [Ping timeout: 264 seconds]
bvernoux has quit [Quit: Leaving]
d_olex_ has quit [Ping timeout: 245 seconds]
d_olex has joined #glasgow
d_olex has quit [Ping timeout: 264 seconds]
d_olex has joined #glasgow
Foxyloxy has quit [Ping timeout: 276 seconds]
GNUmoon2 has joined #glasgow
d_olex has quit [Ping timeout: 240 seconds]
levi_ has joined #glasgow
cqc_ has joined #glasgow
sorear_ has joined #glasgow
englishm__ has joined #glasgow
XgFgX has joined #glasgow
XgF has quit [Disconnected by services]
nyaanotech has joined #glasgow
ma1_ has joined #glasgow
tobbez_ has joined #glasgow
ec0_ has joined #glasgow
miek___ has joined #glasgow
Foxyloxy has joined #glasgow
tobbez has quit [*.net *.split]
nyanotech has quit [*.net *.split]
sorear has quit [*.net *.split]
ma1 has quit [*.net *.split]
englishm_ has quit [*.net *.split]
levi has quit [*.net *.split]
cqc has quit [*.net *.split]
miek has quit [*.net *.split]
ec0 has quit [*.net *.split]
tobbez_ is now known as tobbez
cqc_ is now known as cqc
levi_ is now known as levi
sorear_ is now known as sorear
d_olex has joined #glasgow
miek___ is now known as miek
d_olex has quit [Ping timeout: 264 seconds]
d_olex has joined #glasgow
XgFgX is now known as XgF
richbridger has quit [Ping timeout: 256 seconds]
<d1b2>
<kbingham> @Attie Aha, great I can finally catch up on your video.
<d1b2>
<kbingham> has anyone got the capability to add holes on the 3d printed case lid over the LEDs before I 3d print a new full case for @Attie ?
ec0_ has quit [Quit: WeeChat 3.0]
<d1b2>
<Attie> :)
<d1b2>
<Attie> @kbingham can't you add holes to the model before printing? (if it doesn't have then already) I have tools if needs be...
<d1b2>
<kbingham> I don't have fusion 😦
<d1b2>
<kbingham> I create my models with openscad.
<d1b2>
<kbingham> Seems to be the only lacking 'feature' of the 3d printed case 😉
<d1b2>
<kbingham> Seems a shame to print the case without being able to see the leds. But I can print one without holes anyway. (How many glasgows do you have ?)
<d1b2>
<kbingham> the print uses 33p of filament each, so I think I can print you a case for each board you have. 🙂
<d1b2>
<Attie> maybe freecad?
<d1b2>
<kbingham> Ok, yes I can open the STL in freecad so I'll see if I can cut the hole there.
<d1b2>
<kbingham> I won't be able to feed that back to the fusion model though.
ec0 has joined #glasgow
<d1b2>
<Attie> true
d_olex_ has joined #glasgow
d_olex has quit [Ping timeout: 264 seconds]
<d1b2>
<Attie> @whitequark i know you're keen on COBS for various things ... have you made a start on it?
<d1b2>
<Attie> i think i'd quite like to use it to frame CAN packets, so if not, i may have a poke
<whitequark[m]>
go ahead!
<d1b2>
<Attie> i'm thinking the interface will be almost identical to a FIFO, with a "packet boundary" type strobe
<d1b2>
<Attie> neat, thanks!
<d1b2>
<Attie> i've also been thinking about buffer depth, as it's necessary to "look ahead" n-bytes... is there any specific reason to actually buffer a full 255 bytes, or is a (much) lower threshold (like 8 or 16) acceptable too, with the associated overhead implications / perhaps configurable on instantiation
<whitequark[m]>
hm, thats not how i planned to do it
<whitequark[m]>
oh yeah lookahead is more like it
<whitequark[m]>
lets discuss this in detail a bit later
<d1b2>
<Attie> sure 🙂
<agg>
i have recently implemented three or four different designs of "frame FIFO", might be interesting to chat about
<agg>
though not using in-band framing a la COBS
<d1b2>
<Attie> oo, interested to hear more - any specific schemes?
<agg>
Attie: my general requirement was that the writer streams words in, then can 'commit' or 'cancel', allowing it to cancel after e.g. the CRC turned out to be bad
<agg>
version 1: very similar to SyncFIFO, but separate w_level and r_level, on cancel w_level is reset to 0 and w_addr is reset to the last uncommitted address, on commit w_level is reset to 0 and r_level is incremented by w_level (plus some accounting for simultaneous write+commit)
<agg>
so basically batches of writes are moved through to the read side; I used a width+1 memory and store a 'first' flag in the extra bit, which is set after commit/cancel and is exposed directly to the reader, who sees ready/valid/data/first
<agg>
this worked great but didn't quite meet my timing requirements. version 2 replaced the 'first' bit in memory with a short fall-through FIFO for start addresses, so the write side wrote as normal then pushed start addresses through this side FIFO when committing, the read side grabbed them and read from there, but it used in-band knowledge of the frame length to know when to stop
<agg>
this was kind of messy, version 3 instead used a deeper FIFO and partitioned it into slots which could each hold one max-length frame, which might be OK for CAN, and had a separate valid bit for each slot
<agg>
the write side writes into the current slot until commit, then marks that slot as valid and moves to the next slot. the reader waits until its current slot becomes valid and then reads from it until the end (again using in-band knowledge of frame length), then marks that slot as invalid and moves to the next. the underlying memory address is partitioned into slot index and slot address.
<agg>
that worked OK too but my average-to-max frame length was quite varied so it was a bit wasteful
<agg>
version 4 uses a second narrow memory to store start and stop bits, which is more efficient than the wider memory of version 1 (since one narrow bram can store the metadata for several word-width brams), the write side streams data in, resets to start on cancel, and on commit it sets the 'stop' bit on the last data word, rewinds to the first word and sets the 'start' bit, then jumps back to the next word,
<agg>
and the read side waits to see the 'start' bit, then streams until it sees a 'stop' bit, then waits for the next 'start'
<agg>
the write side goes not-ready when its pointer is one below the read sides'
<agg>
again some extra accounting for simultaneous things, but in the end this way was good for timing, good for bram efficiency, doesn't require in-band knowledge of frame length
<agg>
the read side swapped from having a 'first' output to having ready stay asserted during a frame and go away for at least one cycle between frames, but you could generate 'first' instead
<agg>
s/ready/valid
<agg>
in practice this means: the write side (e.g. a CAN frame receiver) streams words in as they arrive, if the final checksum is good it strobes 'commit' otherwise 'cancel', the reader becomes 'valid' as soon as a complete frame is available and remains valid until the frame is completely read
<agg>
oh, there was a version 0 too: use a bram for the data and push start address and length into a regular SyncFIFO, sized such that if the SyncFIFO is not full there's always space to write a full frame to the BRAM, that was very simple but used a lot of wide SyncFIFOs
<d1b2>
<bburky> Watched the video yesterday and managed to learn a few new things. It was nice to have a quick description of the problems around USB. I always knew that the FX2 was a black box to make things easier for... reasons. But talking about the USB challenges (mostly keeping the channels full for good bandwidth), helps me understand why the Glasgow design is actually quite nice.
<d1b2>
<Attie> @agg interesting, thanks - i'll have to read that again later and digest it
<d1b2>
<Attie> sounds like v4 is basically a start:1[data:n] memory?
<agg>
yea sorry for the bit of an infodump, happy to discuss details whenever
<d1b2>
<Attie> np, thank you!
<agg>
not sure I understand what you mean by a start:1[data:n] memory
<d1b2>
<Attie> you referred to a "narrow memory" in conjunction with the normal FIFO, so if the data is 8-bit, the start+stop is 2-bit, then you effectively have a 10-bit memory? (even if implemented as two separate blocks)
<agg>
ah
<agg>
not exactly
<agg>
by using one 2-bit memory and one 8-bit memory, the 8-bit can be 512 deep on an ice40, and the 2 bit can be 2048 deep
<agg>
which means you could use four data brams and still only one start/stop bram, 5 total
<agg>
whereas using a 10-bit memory would mean each bram can only be 256 deep (16x256), so while you'd still need 2 brams for 512 (and could have only one bram for 256 deep), after 512 deep you'd need more brams
<agg>
also - it needs to be able to write the config bits separately from the data bits, though you could do this with the byte-enable write mask inputs
<agg>
so if you're ok with just 256 deep, then you can use one 10-bit FIFO and use byte enable, if you want 512 then either is the same, beyond that depth it's more efficient to use separate memories
<d1b2>
<Attie> hmm... would there be any need / use for mis-matched depths? what is the 513->end used for in the 2-bit memory?
<agg>
not used, just means you can keep adding data memory without adding more 2-bit memory
<d1b2>
<Attie> gotcha
<agg>
in my case I wanted quite deep fifos, so this was more efficient (and didn't need to use the write enables), for 256 deep it's more efficient to use one wider memory
<d1b2>
<Attie> i suspected there would be a good reason for using two separate memories, but i didn't reason it through properly... thanks
<agg>
I think in nmigen you'd need to make it a 16-bit-wide memory and set granularity=8 on the write port to get a two-bit enable, but it should work fine
<whitequark[m]>
yep
Twix has joined #glasgow
roybatty has joined #glasgow
<roybatty>
Reading the latest update @ CrowdSupply ... What's a "Ram-Pak"?
<tnt>
Optional add-on with 2 hyperram chips to add some memory.
<roybatty>
Thanks! Will they be available via CrowdSupply?
<tnt>
No idea ...
<tnt>
But this is really early and they're also busy with the actual campaign ...
<tnt>
*early work/proto I meant.
<sorear>
if esden makes them they'll show up on 1bitsquared I'm almost sure