| *** tpb has joined #tomu | 00:00 | |
| Vercas | So... How's the gnuk port goin'? :D | 00:10 |
|---|---|---|
| *** AmosSam has left #tomu | 01:50 | |
| *** AmosSam has joined #tomu | 01:50 | |
| *** cdmatter has joined #tomu | 02:19 | |
| xobs | mithro: 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 IRC | 02:59 | |
| *** Farscrap has quit IRC | 03:41 | |
| *** rohitksingh has joined #tomu | 06:11 | |
| AmosSam | Vercas: 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 IRC | 07:01 | |
| *** rails_ has joined #tomu | 07:04 | |
| *** jacobrosenthal has quit IRC | 07:05 | |
| *** rails has quit IRC | 07:05 | |
| *** rohitksingh has joined #tomu | 08:22 | |
| *** _anomaly_ has joined #tomu | 08:34 | |
| *** rohitksingh has quit IRC | 09:33 | |
| *** rohitksingh has joined #tomu | 09:49 | |
| *** rohitksingh has quit IRC | 09:58 | |
| *** rohitksingh has joined #tomu | 09:59 | |
| xobs | tnt: that fix works fantasticly, thanks for coming up with it! | 11:29 |
| tnt | xobs: Ah good to hear :) | 11:30 |
| tnt | at least it confirms the issue and that the rest of the logic is fine. | 11:30 |
| xobs | Now 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 |
| xobs | It could be that, without a signal, the frequency compensation circuit is coming unsynced. | 11:31 |
| * xobs uploaded an image: image.png (68KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/NmnSCLyTNruWgfMQCsojIUNz > | 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 |
| xobs | I believe they were received properly, though. | 11:32 |
| tnt | Well, 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 |
| tnt | Any chance of a scope trace ? | 11:35 |
| xobs | I'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 IRC | 11:37 | |
| xobs | I'm actually not sure what those times mean. | 11:37 |
| xobs | Or, wait, I'm off by a few orders of magnitude. | 11:38 |
| tnt | 550 ns | 11:38 |
| *** jacobrosenthal has joined #tomu | 11:40 | |
| tnt | The 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 |
| tnt | Not 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 |
| xobs | An 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 |
| tnt | That 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 |
| tnt | That can probably be reduced as a first check to see if less latency helps. | 11:53 |
| xobs | That'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 |
| tnt | No, it's the fifo_filling thing. | 11:55 |
| xobs | Oh, it's fifo_delay | 11:56 |
| tnt | fifo_idle is to not push anything in the fifo when you're not inside of a packet. | 11:56 |
| tnt | fifo_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 |
| xobs | Okay, this is looking so much better. | 12:23 |
| xobs | I'm getting protocol-level errors now rather than PHY or MAC errors. | 12:24 |
| tnt | \o/ :) | 12:25 |
| xobs | Do 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 |
| xobs | For 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 |
| tnt | huh ? That fifo should empty always. | 12:31 |
| tnt | Or are we talking about another fifo ? | 12:31 |
| xobs | Different fifo. | 12:32 |
| xobs | This is the FIFO that I'm writing data to when queueing it up for transmission. | 12:32 |
| tnt | Ah oki. Huh, nope, don't know off-hand. That patch is like the second time I write migen code :) | 12:33 |
| xobs | It's a fantastic patch. Mostly because it seems to fix the issue :) | 12:33 |
| xobs | Thanks again! | 12:33 |
| tnt | Can you post a log of what you're seeing on the bus ? | 12:34 |
| xobs | Are images okay, or would you like something text-based? | 12:34 |
| tnt | images are fine | 12:34 |
| * xobs uploaded an image: image.png (72KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/JiFMOhZqZkEzlnIYInLMcLct > | 12:35 | |
| xobs | Ah, I See part of the problem. | 12:37 |
| xobs | Definitely a protocol issue. | 12:37 |
| xobs | It's treating that OUT packet as a SETUP packet. That's easy enough to ignore... | 12:38 |
| tnt | Why are the transfer 8 bytes btw ? | 12:38 |
| xobs | Habit and history. It actually works much better if I bump it up to 64 bytes: | 12:41 |
| * xobs uploaded an image: image.png (53KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/HHFUysvTgalyQhPywMrutrNQ > | 12:41 | |
| xobs | Because then it doesn't need to split transactions across multiple requests. | 12:42 |
| tnt | But 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 |
| tnt | :) | 12:59 |
| 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 |
| xobs | It's got some issues, but hooray! | 12:59 |
| tnt | Nice. that was pretty quick from hw working to the stack running :) | 13:07 |
| xobs | :) | 13:08 |
| xobs | I 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 |
| tnt | Yeah, 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 |
| xobs | What changes did you make, if I might ask? | 13:19 |
| xobs | Using a 12 MHz crystal is one change I'm considering. | 13:19 |
| tnt | I 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 r | 13:22 |
| tnt | I 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 |
| xobs | I 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 |
| xobs | Did you make any changes to your hardware? Or, actually, what hardware *is* that? | 13:27 |
| tnt | This: https://github.com/smunaut/ice40-playground/tree/experimental/cores/usb/rtl | 13:28 |
| tpb | Title: ice40-playground/cores/usb/rtl at experimental · smunaut/ice40-playground · GitHub (at github.com) | 13:28 |
| xobs | Ah, okay, mostly for the ICEBreaker. | 13:29 |
| tnt | Well, 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 #tomu | 14:25 | |
| *** xkapastel has joined #tomu | 14:59 | |
| *** rohitksingh has joined #tomu | 16:27 | |
| *** rohitksingh has quit IRC | 17:05 | |
| *** rohitksingh has joined #tomu | 17:33 | |
| *** rohitksingh has quit IRC | 18:07 | |
| *** rohitksingh has joined #tomu | 18:09 | |
| *** rohitksingh has quit IRC | 19:59 | |
| *** AmosSam has left #tomu | 20:10 | |
| *** AmosSam has joined #tomu | 20:10 | |
| *** xkapastel has quit IRC | 21:58 | |
| *** futarisIRCcloud has joined #tomu | 23:56 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!