<marcan>
whitequark: btw, you did some LPC stuff on glasgow if I remember correctly? or was it something else?
<marcan>
is any of that upstream?
<marcan>
I ask just because that stuff is semi-fresh in my list of things I've recently messed with, might make sense to validate it with revC and tick that box
<marcan>
(someone asked about it on twitter recently)
<whitequark>
marcan: it's waiting on nmigen
<whitequark>
marcan: well, i could work around it, i guess
<whitequark>
but it's not easy
<whitequark>
needs async reset
<whitequark>
anyway there's a wip branch for lpc
<marcan>
ah
<marcan>
whitequark: what's the status of nmigen?
<marcan>
one thing I kind of want to do, which *should* be more practical with ice40 stuff, is making it work without a reset at all
<marcan>
on xilinx I had horrible FPGA hangups even though the inbound side of the async FIFO was a totally trivial thing that shouldn't be crashing
<marcan>
there is no good reason to *require* a reset to make a trivial synchronous logic analyzer not randomly latch up as far as I can tell
<marcan>
the worst that should happen is you get garbage output
<whitequark>
marcan: hrm
<marcan>
the rest should just be a counter clocking data into one side of a dual port BRAM
<whitequark>
yes but there are the gray counters
<whitequark>
which can stop being gray counters if you have severe setup/hold violations on the clok
<marcan>
yes but the worst thing that can happen for those is the pointer goes wack
<whitequark>
mm right, there's the 2FF between then
<whitequark>
them*
<marcan>
yeah
<marcan>
like I don't care if I get a bunch of garbage out when the receive side is unstable
<marcan>
I just want it to work when the clock is good
<whitequark>
so actually my LPC applet does decoding synchronous to the LPC clock
<marcan>
yeah so I would move that to the other side
<whitequark>
it wasn't fast enough on revB
<whitequark>
30 vs 33
<marcan>
and just have a trivial synchronous logic analyzer on the LPC clock
<marcan>
yeah but on revC it's fine
<marcan>
also you could introduce an internal clock domain in between if you really wanted to (let's validate that PLL)
<whitequark>
the reason it does decoding synchronous to the LPC clock is i wanted to make a flash emulator
<marcan>
oh sure
<marcan>
there is totally merit to doing it right with a proper reset and clean logic
<marcan>
I'm just interested in the idea of a synchronous logic analyzer that doesn't require well-behaved reset to not completely fuck up
<whitequark>
yeah, i mean, it doesn't actually fuck up at all
<marcan>
(my xilinx one did)
<whitequark>
you just get stale data when you reset the AsyncFIFO
<marcan>
(like it would just hang)
<marcan>
I ended up adding a reset pushbutton, and hitting it at the same time as reset on the target, because I didn't have a proper reset pin brought out
<whitequark>
ooof
<marcan>
xilinx shit seems to be really good at producing logic that can just *crash* when going metastable
<marcan>
I've had that several times
<marcan>
which is why I'm interested in doing better with ice40
<marcan>
"defensive logic"; even if I break all the rules it shouldn't just completely die
<marcan>
at worst it should just produce garbage out
<whitequark>
sure, this would be interesting
<marcan>
whitequark: so what's the story with nmigen right now?
<whitequark>
marcan: i'm working on it, basically
<whitequark>
it's not really usable as a whole yet
<marcan>
ah
<electronic_eel>
whitequark: unfortunately no 480 in the ltm2884
<whitequark>
yes, i misread it
<daveshah>
marcan: interestingly from poking around I've found both iCE40 and ECP5 typically have more hold time margin than Xilinx parts
<daveshah>
On both iCE40 and ECP5 it's possible to run a picorv32 fine with no global clock routing (so crazy amounts of clock skew)
<daveshah>
On Xilinx even a blinky without global clock routing misbehaves due to hold time issues
<marcan>
hah
<gruetzkopf>
interesting, and useful
<marcan>
whitequark: I might try to implement a 7-bit clocked logic analyzer with trivial compression (which is good enough for LPC and a bunch of other things)
<marcan>
that makes sense from both an IO and protocol perspective (7 bits + clock for a port, data format is 0<data> or 1<repeat count>)
<marcan>
compression would happen on the FX2 iface end
<marcan>
and then just parse LPC on the software side (compression should make it good enough to do in python, since with LPC the vaaaast majority of cycles are idle)
<marcan>
my old xilinx one was an 8-bit LA with no compression, with parsing in C
<marcan>
(and I had bitstreams for both ext clock, 20MHz, 30MHz)
<electronic_eel>
marcan: why compression on the fx2 and not in t
<marcan>
electronic_eel: I mean the FX2 side of the FPGA
<marcan>
the clock domain
<marcan>
not actually on the FX2
<electronic_eel>
ah, ok
<marcan>
because I want the capture side to be a super dumb "dump stuff into a CDC FIFO" thing so I can try to make it robust against misbehaving clock signals
<electronic_eel>
makes sense
<marcan>
if I can get the robustness thing right, the reset signal can just be one of the captured pins, and handled in software (reset low = ignore data, reset state machine)
<marcan>
you might still get $crap when the clock is crazy of course, but it should have clean output once the clock is stable and reset is released
<marcan>
which for a synchronous logic analyzer is all you want, really
<whitequark>
yeah
m4ssi has joined #glasgow
Jasjar has quit [Ping timeout: 246 seconds]
Jasjar has joined #glasgow
_whitelogger has joined #glasgow
gsuberland^ has joined #glasgow
gsuberland^ has left #glasgow [#glasgow]
gsuberland has quit [Disconnected by services]
gsuberland has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
ali_as has joined #glasgow
carl0s has joined #glasgow
m4ssi has quit [Remote host closed the connection]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<esden>
I was planning to place the order for the parts and PCBs today. As you have seen on twitter I was bit busy ...
<whitequark>
ohh I missed that one
<whitequark>
nice re: icebreakers
<esden>
;) :D
<ali-as>
Is C1 a fixed design now?
<whitequark>
yes.
<esden>
Still want to assemble the remaining early bird icebreakers before the end of the week.
<esden>
But I want to order the C1 stuff today so that this can "work in the background" :D
<whitequark>
sounds good
<ali-as>
Have people put in their orders yet or will that happen later?
* esden
spawns a background process :D
<esden>
hold your horses... this batch will be only a few units for testing, not that we end up with another dealbreaker like with C0. I will make a few units send them to marcan and whitequark and the other designated early testers. When that is 100% validated we will start making bigger batches.
<ali-as>
That's cool, I only joined the mailing list a few days agoso I didn't want to have missed it.
<esden>
you won't don't worry. :D We will definitely let people know when we open up the orders for everyone. :D
<ali-as>
Cool, what was wrong with C0?
<ali-as>
(or is the answer to that everything that was changed to make C1?)
<sorear>
The ECOs page on the github wiki has a reasonably complete list of C1 changes