Sunday, 2019-03-10

*** tpb has joined #tomu00:00
VercasSo... How's the gnuk port goin'? :D00:10
*** AmosSam has left #tomu01:50
*** AmosSam has joined #tomu01:50
*** cdmatter has joined #tomu02:19
xobsmithro: I just specified the constraint for each wire. Nextpnr will pick one of them at "random", so as long as it's over-specified its fine.02:50
*** xkapastel has quit IRC02:59
*** Farscrap has quit IRC03:41
*** rohitksingh has joined #tomu06:11
AmosSamVercas: still need to figure out why usb comm is not working, as gnuk compiles and flashes to tomu, and just loops in main loop waiting for usb connection...06:26
*** rohitksingh has quit IRC07:01
*** rails_ has joined #tomu07:04
*** jacobrosenthal has quit IRC07:05
*** rails has quit IRC07:05
*** rohitksingh has joined #tomu08:22
*** _anomaly_ has joined #tomu08:34
*** rohitksingh has quit IRC09:33
*** rohitksingh has joined #tomu09:49
*** rohitksingh has quit IRC09:58
*** rohitksingh has joined #tomu09:59
xobstnt: that fix works fantasticly, thanks for coming up with it!11:29
tntxobs: Ah good to hear :)11:30
tntat least it confirms the issue and that the rest of the logic is fine.11:30
xobsNow I think the only problem might have to do with transmission, because my logic analyzer is just telling me "Invalid PID sequence", which I think it does whenever it goes "Something was wrong, but I don't know what."11:30
xobsIt could be that, without a signal, the frequency compensation circuit is coming unsynced.11:31
* xobs uploaded an image: image.png (68KB) < >11:31
xobs^ example of three SETUP packets that were acked.  The first two had "Something" wrong with them, but who knows what.11:31
xobsI believe they were received properly, though.11:32
tntWell, the ACK you TX is going to be way later than 6.5 bit time since that fifo adds almost 10 bits of latency by itself. Not sure if the host will like that much.11:35
tntAny chance of a scope trace ?11:35
xobsI'll try  to get one tomorrow. According to the LA it's 900 uS after, which you're right is outside of the 550 uS window of a response.11:36
*** rohitksingh has quit IRC11:37
xobsI'm actually not sure what those times mean.11:37
xobsOr, wait, I'm off by a few orders of magnitude.11:38
tnt550 ns11:38
*** jacobrosenthal has joined #tomu11:40
tntThe host is not supposed to time out before 1.3 us in theory since it has to accept delays from various places, so 900 us should probably still work.11:40
tntNot sure if your scope can trigger on SETUP packets, but a trick I used is to trigger on Nth edge to 'skip' all the SOF packets.11:41
xobsAn easy way I could see of doing that is to direct the "tx_en" pin to a test point and trigger on that, with a delay.11:48
tntThat works tool. Also note that in the original patch I posted, I waited 8 cycles before starting reading from the FIFO, but that's to account for worst case drift ( 1000 ppm difference over a 1023 byte packet with worst possible bitstuffing ... ).11:53
tntThat can probably be reduced as a first check to see if less latency helps.11:53
xobsThat's this line? If(nrzi.o_data, If(~fifo_idle[2], fifo_idle.eq(fifo_idle + 1))).Else(fifo_idle.eq(0))11:55
xobs(Erm, which I've already changed to [2])11:55
tntNo, it's the fifo_filling thing.11:55
xobsOh, it's fifo_delay11:56
tntfifo_idle is to not push anything in the fifo when you're not inside of a packet.11:56
tntfifo_idle[2] might not be good, it will turn off too quickly, you can get 4 '1's in a row inside a packet.11:58
xobsOkay, this is looking so much better.12:23
xobsI'm getting protocol-level errors now rather than PHY or MAC errors.12:24
tnt\o/ :)12:25
xobsDo you know if there's any easy way to reset an AsyncFIFO?  The problem I'm running into now is that I'll write data into a FIFO, but then the other side won't ever read it.12:30
xobsFor example, I'll write the result of a SETUP packet, it'll get it via IN, I'll write the next data, but then it'll issue a new SETUP packet.12:30
tnthuh ? That fifo should empty always.12:31
tntOr are we talking about another fifo ?12:31
xobsDifferent fifo.12:32
xobsThis is the FIFO that I'm writing data to when queueing it up for transmission.12:32
tntAh oki. Huh, nope, don't know off-hand. That patch is like the second time I write migen code :)12:33
xobsIt's a fantastic patch.  Mostly because it seems to fix the issue :)12:33
xobsThanks again!12:33
tntCan you post a log of what you're seeing on the bus ?12:34
xobsAre images okay, or would you like something text-based?12:34
tntimages are fine12:34
* xobs uploaded an image: image.png (72KB) < >12:35
xobsAh, I See part of the problem.12:37
xobsDefinitely a protocol issue.12:37
xobsIt's treating that OUT packet as a SETUP packet.  That's easy enough to ignore...12:38
tntWhy are the transfer 8 bytes btw ?12:38
xobsHabit and history.  It actually works much better if I bump it up to 64 bytes:12:41
* xobs uploaded an image: image.png (53KB) < >12:41
xobsBecause then it doesn't need to split transactions across multiple requests.12:42
tntBut in the 8b case I would also have expected a ZLP after the 2 8 byte packets to indicate the end.12:42
xobs`New USB device found, idVendor=1209, idProduct=70b1`12:57
xobs`Found DFU: [1209:70b1] ver=0101, devnum=60, cfg=1, intf=0, path="1-1.3", alt=0, name="UNKNOWN", serial="UNKNOWN"`12:59
xobsIt's got some issues, but hooray!12:59
tntNice. that was pretty quick from hw working to the stack running :)13:07
xobsI still need to ensure it's in the right state for various things, but this is almost usable as a DFU device.  It's certainly good enough to indicate there isn't any issue at the hardware level, and it validates that this is at least *posslble*.  And it means I'll sleep very well tonight.13:09
tntYeah, ensuring everything 'goes' right was my main issue. I actually did small designs changes to my core hw to make it easier to ensure all goes well during control transfers and that it handles all the 'failure modes' properly.13:19
xobsWhat changes did you make, if I might ask?13:19
xobsUsing a 12 MHz crystal is one change I'm considering.13:19
tntI originally had just a ring (well 2) buffers for the EP0 IN/OUT. What I did is introduce a special mode for control end point where one buffer is always used for SETUP and one is always used for OUT, so I can ensure that I'm always ready for a SETUP even if the previous transfer got aborted or something.  Also when receiving a SETUP, I prevent I will NAK any IN/OUT after it until the soft core got a chance to see what's going on, to make sure that I don't accidently r13:22
tntI did actually get it working without any of those changes, but (1) I didn't like the resulting code much (2) I'm prett sure there was race conditions that could make it fail in some weird corner cases. Hopfully the new code will be much more robust.13:26
xobsI might look into making those changes in the release software.  But this is looking good enough to at least implement DFU mode, which will get me an updater, which is what users need.13:27
xobsDid you make any changes to your hardware?  Or, actually, what hardware *is* that?13:27
tpbTitle: ice40-playground/cores/usb/rtl at experimental · smunaut/ice40-playground · GitHub (at
xobsAh, okay, mostly for the ICEBreaker.13:29
tntWell, the usb core itself is good for any ice40 (and any fpga with small changes to the few blocks I instanciate)., but I'm testing on the icebreaker ATM for ease of development.13:30
*** Farscrap has joined #tomu14:25
*** xkapastel has joined #tomu14:59
*** rohitksingh has joined #tomu16:27
*** rohitksingh has quit IRC17:05
*** rohitksingh has joined #tomu17:33
*** rohitksingh has quit IRC18:07
*** rohitksingh has joined #tomu18:09
*** rohitksingh has quit IRC19:59
*** AmosSam has left #tomu20:10
*** AmosSam has joined #tomu20:10
*** xkapastel has quit IRC21:58
*** futarisIRCcloud has joined #tomu23:56

Generated by 2.13.1 by Marius Gedminas - find it at!