| *** tpb has joined #tomu | 00:00 | |
| *** Farscrap has joined #tomu | 01:09 | |
| xobs | tnt: the sw/ dir is a mix, yeah. | 01:16 |
|---|---|---|
| xobs | I think the reason hosts are so agressive is that you're never supposed to NAK them, you're always supposed to have a dedicated buffer for a SETUP packet on EP0. | 01:17 |
| xobs | Still, I think the transmission issue comes from the fact that state machiens in Migen are asynchronous, and I'm doing the equivalent of `assign` in there. That's probably a no-no. | 01:18 |
| xobs | I'll make some fixes and verify them this afternoon, when I'm around the oscilloscope again. | 01:18 |
| xobs | Okay, I think the problem may be that the Migen simulator treats FSMs as clocked, but the generator makes them async. | 03:02 |
| *** futarisIRCcloud has joined #tomu | 03:27 | |
| *** Farscrap has quit IRC | 04:04 | |
| xobs | I'm developing such an appreciation for Gray code, though. I totally get why it's a thing. Makes combinatorics work out better during state changes. | 07:37 |
| tnt | xobs: what do you mean migen fsm are asynchronous ? | 07:43 |
| tnt | xobs: and wrt to EP0 SETUP, yeah, you can't NAK, but the state diagram still shows the if you don't have space you can ignore the packet. I'm having trouble having the softcore submit another buffer in time in my stack :/ | 07:46 |
| xobs | tnt: if you generate a FSM using the FSM() primitive, then everything inside of it goes in a `always @(*) begin` block. State transitions (using `NextState()`) are synchronous, and `NextValue()` is used to synchronously set registers on the next cycle, but any `value.eq(x)` commands are asynchronous and operate outside of a clock domain. | 07:46 |
| tnt | xobs: Ah yeah, I see. But that assignement is only done if the state is the one that was declared in right ? Kind of wondering what happens for other states where you don't assign that signal to anything then ... | 07:58 |
| xobs | tnt: migen assigns them the default value of "0". | 07:59 |
| tnt | ok makes sense. at least it doesn't create a latch :) | 08:00 |
| xobs | Except when you're transitioning between states you can get glitches. For example, I was seeing a very brief (12 ns?) glitch on one line when enabling USB transmission. | 08:00 |
| xobs | In one state it was "0", and in the next state it was also "0", but in the transition it was a "1". | 08:00 |
| tnt | Ah yeah of course. Although, I'm surprised you'd not using the IOB registers ? | 08:01 |
| tnt | 12 ns is a bit more than 'brief' :/ | 08:02 |
| xobs | I am using the IOB registers. | 08:03 |
| tnt | on when you said "on one line", you weren't talking about the DP/DN ? | 08:03 |
| tnt | just some signal your exported on the scope ? | 08:04 |
| xobs | I rerouted the DP/DN lines to pads that I can probe more easily. This was on the "DP" line. | 08:05 |
| tnt | io.py pinstate doesn't have IOB regs enabled AFAICT, unless I'm not looking at the right code. | 08:05 |
| xobs | Ah, you're right. No latch. | 08:09 |
| tnt | Why did you go for the Vexriscv vs the picorv32 btw ? | 08:29 |
| xobs | There are a few reasons. A big one is that vex has a debug plugin, which means we'll get openocd support (once I get USB working, of course). | 08:31 |
| xobs | It's also easier to scale Vex, and the latest version has a single-cycle multiplier using the UP5k DSP blocks. | 08:32 |
| tnt | I'm trying to understand the core structure, but all I see is a direct fifo conneciton to the cpu ? basically cpu -> 8:1 serdes -> pad ? | 09:08 |
| xobs | tnt: the current setup in Git is using the "unififo" connection, which is indeed just a shift register. It's definitely not fast enough, but it's simple enough that I can hook up a scope and a logic analyzer to figure out what it's doing. | 09:09 |
| tnt | Also, I don't understand how the RX 48M -> 12M works ? I mean, the local 12M isn't synchronized and can be 'slower' than the usb 12M, so they'll drift over time and at some point you might need to receive 2 bits or 0 bits from the 48M -> 12M ? | 09:09 |
| xobs | Now I'm working on the epfifo implementation. I see some waveform issues that may be contributing to the problem. | 09:09 |
| xobs | The local 12M is derived from 48M by dividing it by 4. It didn't used to be that way, and in fact 12M used to come from the HFOSC. But that was causing some clock-domain crossing issues, so I made 12M slaved off of 48M and removed the CDC registers. | 09:10 |
| xobs | https://github.com/xobs/foboot/blob/master/hw/foboot-bitstream.py#L135 | 09:11 |
| tpb | Title: foboot/foboot-bitstream.py at master · xobs/foboot · GitHub (at github.com) | 09:11 |
| tnt | I don't meant he 12M/48M clock inside the FPGA. I mean the bits coming from USB. The clock recovery RX bit strobe can be 3/4/5 clock cycles appart depending on the incoming timing of the usb data. | 09:12 |
| xobs | That's a good point. That shoudl be taken care of by `line_state_phase`, which tries to center it up on the pulse, +/- one cycle: https://github.com/xobs/valentyusb/blob/master/valentyusb/usbcore/rx/clock.py#L134 | 09:15 |
| tpb | Title: valentyusb/clock.py at master · xobs/valentyusb · GitHub (at github.com) | 09:15 |
| tnt | Yes, the sampling in the 48 MHz domain is going to be good. But then the result of that sampling seems to be "just passeD" in the 12M domain with no fifo, no sync, ... and that 'line_state_phase' can/will drift over time vs the local 12M clock and so when crossing the bit you captured at 48M in the local 12M domain, it may be missed or it may be sampled twice. | 09:17 |
| *** futarisIRCcloud has quit IRC | 09:17 | |
| *** awe00 has joined #tomu | 10:16 | |
| xobs | tnt: I'll have to see how often that's a problem in practice. Right now I'm seeing lots of corruption, and I don't think that's the issue. Mostly because I was seeing the same behavior when the cdc registers were in place. | 10:20 |
| xobs | Something isn't working right. Simulation isn't matching up to reality. The raw FIFO receives fine, but the automated endpoint system isn't responding correctly. | 10:22 |
| *** futarisIRCcloud has joined #tomu | 10:54 | |
| *** futarisIRCcloud has quit IRC | 13:54 | |
| *** awe00 has quit IRC | 16:14 | |
| *** awe00 has joined #tomu | 16:21 | |
| *** awe00 has quit IRC | 20:26 | |
| *** awe00 has joined #tomu | 22:42 | |
| *** AmosSam has left #tomu | 23:12 | |
| *** AmosSam has joined #tomu | 23:12 | |
| *** Farscrap has joined #tomu | 23:33 | |
| *** awe00 has quit IRC | 23:36 | |
| *** xkapastel has joined #tomu | 23:44 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!