| *** tpb has joined #tomu | 00:00 | |
| *** futarisIRCcloud has joined #tomu | 00:01 | |
| xobs | tnt: not yet, but I'm getting close | 00:37 |
|---|---|---|
| xobs | mithro: same place I've been stuck for a while -- massive corruption when using epfifo on real hardware, even to the point where responses aren't coming when they should. | 00:38 |
| xobs | But I'm starting to narrow down the problem. The current working theory is that it has to do with the phase relationship between usb48 and usb12. I'm narrowing the delay down and I think it's getting better. I'm going to spend today trying to convince the PLL to give me a perfectly-aligned 48 MHz clock. | 00:39 |
| mithro | xobs: If I recall, didn't we have it responding at some point? | 00:41 |
| xobs | mithro: it responds, just not well. I don't think we've ever had it responding, meeting timing, and working on hardware. | 00:44 |
| mithro | xobs: At LCA we were only receiving the data? | 00:45 |
| xobs | We were, yeah. And that pathway works just fine, as far as I can see. | 00:46 |
| mithro | xobs: Way I would debug is start with just adding the NZRI and making sure it will send a sequence, then add in the bit stuffer, then add in the shifter | 00:49 |
| xobs | mithro: Sending works fine, too. I can send data using the unififo and see it reliably on the scope. | 00:50 |
| xobs | I couldn't figure out how to get access to the state machine bits, so I manually had it set various signals inside the Transfer SM. I noticed the "ERROR" state was getting entered. | 00:51 |
| xobs | That's why I spent a lot of time this week trying to figure out how FSMs work in Migen. I really wish they were documented. | 00:51 |
| xobs | And now I've come to the conclusion that it has to do with the delay in clock signal between usb12 and usb48. I got the delay down to... 2.5ns? 1.5ns? I forget, I had to leave it yesterday. But after doing that, the number of errors went down. | 00:52 |
| mithro | xobs: Looks like you removed all the CDC from the USB12 to USB48 | 00:55 |
| xobs | mithro: I did, and that didn't change the pattern of corrupt transmissions. | 00:55 |
| mithro | xobs: Do you have a capture of the corrupt transmissions? | 00:59 |
| mithro | xobs: Also, if you remove the bitstuffer + nrzi from the front end you can get a better idea of what bytes the shift register is sending | 01:00 |
| xobs | I can get one in a few hours, when I go to the office. | 01:00 |
| xobs | But oftentimes it's doing things like not even sending ACKs/NAKs. | 01:00 |
| mithro | xobs: What docs do you need beyond https://github.com/m-labs/migen/blob/master/migen/genlib/fsm.py#L91-L128 ? | 01:01 |
| tpb | Title: migen/fsm.py at master · m-labs/migen · GitHub (at github.com) | 01:01 |
| mithro | xobs: I can try and help you debug it when you get into the office | 01:02 |
| xobs | mithro: Lots. What does `NextValue()` do? What does `NextState()` do? Why would you use `NextValue()` instead of `signal.eq()`? What does `before/after_entering/leaving()` do? How can I access the current state? | 01:03 |
| xobs | I've managed to answer a lot of those questions by looking at the Verilog that gets output. | 01:03 |
| mithro | * synchronous statements of form `NextValue(a, b)`, equivalent to self.sync += a.eq(b)` when the FSM is in the given `state`; | 01:04 |
| mithro | xobs: https://github.com/m-labs/migen/blob/master/migen/genlib/fsm.py#L141-L151 | 01:04 |
| tpb | Title: migen/fsm.py at master · m-labs/migen · GitHub (at github.com) | 01:04 |
| futarisIRCcloud | Sounds like good progress guys. | 01:30 |
| futarisIRCcloud | xobs / mithro: NB, cbjamo was asking a couple of questions re: USB3340 / ULPI on on #timvideos ... Would it be easy to remove the USB phy from valentyusb hardware / gateware and replace it with ULPI? | 01:34 |
| mithro | futarisIRCcloud: Yeah I saw | 01:34 |
| mithro | futarisIRCcloud: I looked at it a while back and can't remember the conclusion of it it make sense or not... | 01:35 |
| futarisIRCcloud | mithro: Yep. I haven't looked enough into ULPI either. I'd think rohitksingh might know. | 01:37 |
| mithro | futarisIRCcloud: Yeah | 01:38 |
| *** Farscrap has quit IRC | 03:50 | |
| *** Farscrap has joined #tomu | 04:05 | |
| xobs | Okay, I think I got the phase difference between clk48 and clk12 down to 1.6ns. Let me see if that affects things. | 04:50 |
| * xobs uploaded an image: image.png (175KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/ZgzamehNEAsMgdXzRBgbvtCx > | 04:55 | |
| xobs | mithro: it's looking much better in that it's actually "ACK"ing now. But neither the Pi nor the Beagle think those packets are acceptable for some reason. | 04:56 |
| *** rohitksingh_work has joined #tomu | 05:07 | |
| * xobs uploaded an image: image.png (363KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/vPFZTXYZoUjjoSgODjbGoLCg > | 05:13 | |
| xobs | Though it still does this, where it doesn't NAK or ACK an IN token for some reason. | 05:13 |
| mithro | xobs: I'm back around now | 05:35 |
| mithro | xobs: So the unififo interface is able to transmit a sequence of bytes correctly, it just can't respond quick enough? | 05:37 |
| xobs | I'll come up with something that responds automatically. At the very least it should be sending ACK packets in response to SETUP packets. | 05:39 |
| xobs | And it's just not doing that. | 05:39 |
| xobs | <xobs "I'll come up with something that"> Weird. I sent those message two days ago. | 05:40 |
| xobs | mithro: correct, USB needs to respond within 6.5 bit times, which is well below even the interrupt latency of Vex. | 05:40 |
| mithro | xobs: Was the epfifo working before you tried to reduce the turn around time? | 05:40 |
| xobs | mithro: no, same issue. | 05:45 |
| mithro | xobs: Do you have an example of that issue? | 05:48 |
| mithro | xobs: 6.5 bit times == 6.5 * 12MHz clock right? | 05:49 |
| xobs | Yes, 6.5 * 12 MHz clock. | 05:50 |
| xobs | I could check out an earlier version of valentyusb and build that... | 05:50 |
| mithro | xobs: There is a lot I don't understand about this commit -> https://github.com/xobs/valentyusb/commit/b057db14ddcc7b70dd768c51f7dc7fbd1dd715ea#diff-7a422fa9e4ceee0d84a8e4e052e94a6b | 05:55 |
| tpb | Title: partially working commit · xobs/valentyusb@b057db1 · GitHub (at github.com) | 05:55 |
| xobs | mithro: That was me guessing how FSMs work. But the idea there is to enable tx.i_oe (i.e. start transmitting) as soon as possible, without wasting one cycle going between the IDLE state and the QUEUE_SYNC state. | 05:57 |
| mithro | xobs: Can you get me a capture of what the output is like before you made those changes? | 06:06 |
| xobs | mithro: I still think it has to do with the clocks. | 06:08 |
| * xobs uploaded an image: image.png (512KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/dcjCMPNiDexOgmnYubIEtdHr > | 06:08 | |
| xobs | I'm running at revision 14e116ff82b825069a92292308f4f66ad6167dff | 06:08 |
| xobs | I'm using the newer clock tree, where usb48 is 1.5ns delayed from usb12. | 06:09 |
| xobs | Even with that version I'm getting strange behavior, such as usb_ep_0_in_ibuf_empty_read() getting stuck at 0 and never emptying out. | 06:14 |
| mithro | xobs: I think the clocks are a red herring | 06:15 |
| xobs | And sometimes it just never responds. | 06:15 |
| * xobs uploaded an image: image.png (198KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/KFqQiDudUptuttaRzdVDPFbN > | 06:15 | |
| mithro | xobs: If the state machine goes into the error state, it will stop responding | 06:17 |
| mithro | xobs: You probably want to expose the error state in a CSR somewhere | 06:18 |
| xobs | mithro: I'm not sure how to do that, so I'll just hook it up to the PMOD header. | 06:23 |
| xobs | It looks like there are at least two states it gets into: The first is where it's in the ERROR state, and the second is where it refuses to empty the ibuf, and /then/ it goes into the ERROR state. | 06:25 |
| xobs | mithro: Is there any documentation on how to use CSRs? I've made my class derive from "AutoCSR" and I've wired up CSRStatus objects in a comb so that their `status` output gets assigned the value I'm looking at, but it's not showing up in the header file. | 06:37 |
| rohitksingh_work | Hi guys! I'll be diving in fomu and ice40 today. Hoping to follow the progress on the USB side. Which repos are the latest one which I should follow? xobs's valentyusb repo seems to be latest one...any more? | 06:39 |
| mithro | xobs: If it isn't appearing in the header, then it's most likely your not including the module? | 06:42 |
| mithro | xobs: Are you sure you are arming the endpoint correctly? | 06:43 |
| mithro | Hrm, it looks like I might need to head to bed as have an early meeting tomorrow.... | 06:44 |
| xobs | Hi rohitksingh_work , I'm not sure what the best repository to start on is. Probably https://github.com/xobs/foboot | 06:44 |
| tpb | Title: GitHub - xobs/foboot: FPGA-half (at github.com) | 06:44 |
| xobs | mithro: I'm creating the CSR in my BaseSoC (which derives from Module). Does that not work? | 06:45 |
| rohitksingh_work | xobs: awesome! thanks | 06:46 |
| mithro | xobs: You sure you are having the right BaseSoC called? | 06:46 |
| mithro | xobs: also check you are looking at the right header file | 06:47 |
| mithro | xobs: rm ing it is a good way to check | 06:48 |
| xobs | And sometimes you'll notice that it enters the ERROR state right away, which shouldn't happen because I do usb_ep_0_out_respond_write(EPF_ACK); usb_ep_0_in_respond_write(EPF_ACK); right before doing usb_pullup_out_write(1); so it should always respond with ACK. | 06:48 |
| xobs | My BaseSoC derives from SoCCore (which derives from Module), and from AutoCSR. | 06:48 |
| xobs | mithro: I moved the CSRStatus from my BaseSoC into the epfifo, and the registers appeared. | 06:54 |
| *** _florent_ has joined #tomu | 07:09 | |
| *** xkapastel has quit IRC | 07:30 | |
| xobs | It always seems to be in the WAIT_DATA state when it gets what I think is an OUT packet. | 07:38 |
| xobs | I'm still wondering: why is it missing packets sometimes? Such as ignoring a SETUP followed by a DATA0 packet. | 07:39 |
| xobs | mithro: how does sm/header.py even work? It sets NextValue(self.o_pid, pid) in the WAIT_PID state, then maybe moves on to WAIT_BYTE0 and WAIT_BYTE1. How does the pid not get reset? I thought migen reset values to 0 if nothing is driving them... | 07:51 |
| tnt | xobs: Isn't that only for the '.eq' stuff and not the NextValue() stuff. | 08:08 |
| xobs | tnt: The comment mithro posted says that in an FSM, you can have "synchronous statements of form `NextValue(a, b)`, equivalent to `self.sync += a.eq(b)` when the FSM is in the given `state`;", which means that when it changes states there's nothing driving it anymore. | 08:10 |
| xobs | Maybe you're right, tnt , and this issue is caused by the bit detector not aligning correctly... | 08:11 |
| tnt | Looking at some migen code my understanding is more like it creates a mux in front of a register with a CE. | 08:12 |
| tnt | mux controlled by state and CE is '1' if in anystate that has a NextValue for that signal. | 08:12 |
| tnt | xobs: not sure how you do testing, but when I was trying out my core, I basically 'replayed' a captured sequence and purposefully drifted the clock +- 1000 ppm to make things drift in simulation. | 08:14 |
| xobs | tnt: That seems like a good way to do it. What do you use for simulation? | 08:16 |
| futarisIRCcloud | tnt: Sounds like a good way to test. | 08:18 |
| rohitksingh_work | ok, my attempt at soldering jumpers wires to fomu test pads blew up. it's been so much time since I used soldering iron. I will just get it soldered by a professional :-| | 08:19 |
| futarisIRCcloud | rohitksingh_work: Try using test clips... | 08:22 |
| rohitksingh_work | futarisIRCcloud: oooh, that's a nice idea...you meant the salae kind of test clips? | 08:24 |
| xobs | rohitksingh_work: https://github.com/im-tomu/fomu-hardware/tree/master/hacker | 08:26 |
| tpb | Title: fomu-hardware/hacker at master · im-tomu/fomu-hardware · GitHub (at github.com) | 08:26 |
| rohitksingh_work | xobs: that's nice! I've a some of those clips. I'll try with them, thank you so much! | 08:37 |
| futarisIRCcloud | rohitksingh_work: giomasce wrote up the document about the poor man's programmer. | 08:43 |
| rohitksingh_work | oh okay. I can see his commit on github | 08:59 |
| tnt | xobs: iverilog. | 09:37 |
| tnt | xobs: test bench and data file I used are here https://github.com/smunaut/ice40-playground/tree/experimental/cores/usb/sim | 09:37 |
| tpb | Title: ice40-playground/cores/usb/sim at experimental · smunaut/ice40-playground · GitHub (at github.com) | 09:37 |
| tnt | but it's pure verilog not migen stuff :/ | 09:37 |
| tnt | not sure how adaptable it would be to your case. | 09:38 |
| xobs | tnt: it might be interesting to use. Or at least to test! | 10:22 |
| xobs | Okay, it looks like the input pathway is corrupting about 10% of packets. At least I know that's the source of the problems. I'm Going to take a break for now. | 10:54 |
| *** awe00 has joined #tomu | 10:55 | |
| tnt | xobs: did you reproduce it in sim or was that on real hw ? | 10:58 |
| xobs | Real hardware. Simulation still says everything is peachy. | 11:02 |
| tnt | Trying to simulate it now, but I have no idea what I'm doing, never really used migen before :p | 11:37 |
| futarisIRCcloud | 10% ??? | 11:40 |
| tnt | tbh, I would also expect that to be build dependent. I mean the 12m alignement to the 48m is going to be dependent on how far the FF generating it is to the global buffer input. Also, it's relying on nextpnr to actually promote that signal to a global buffer automatically. | 11:43 |
| futarisIRCcloud | The FF? | 11:54 |
| tnt | flip flop | 11:55 |
| tnt | register | 11:55 |
| tnt | The 12m is generating by dividing the 48m using a couple of register. The resulting clock sure is not drifting vs the 48m, but it's phase is basically random. So outputing a signal in the 48m domain and sampling it in the 12m domain and hoping it's good is a bit optimistic. | 11:57 |
| tnt | (imho) | 11:57 |
| tnt | Especially if you hope to transmit a new data at every 12m rising edge. | 11:57 |
| tnt | Ideally you'd need after reset to determine which phase you have btw the 48m and the 12m one, then select one of 4 possible phase in the 48m domain to output data to be crossed from 48m -> 12m and only use that one. | 11:58 |
| tnt | But that would only solve the internal 48m -> 12m crossing. The problem of having a recovered strobe from the incoming usb stream that can be slower/faster than your internal 12m clock would remain. | 11:59 |
| xobs | <freenode_tnt "But that would only solve the in"> tnt: I have a build I'm using that I need to push. I'm dividing the 48 down through a FF, then running that through the pll. They're 1.6ns out of phase with that trick, and it doesn't change between builds. | 12:06 |
| tnt | I just realized the pins usb_d_p / usb_d_n are not actually the pins used for usb ... probably why I couldn't get anything to do anythin gin my simu lol | 12:11 |
| tnt | xobs: ok. Is that the rising edge of clk12 lagging behind by 1.6ns or being 1.6 ns the 48m edge ? | 12:13 |
| xobs | Clk12 rises first, as it's driving clk48 | 12:16 |
| tnt | why are you just not using the PLL to get both 12 and 48 btw ? | 12:18 |
| xobs | Can it do that? My impression was that (1) the lowest frequency it'll output is 16 MHz, and (2) the dividers are fixed to 3.5 or 7. | 12:19 |
| tnt | mmm, right, it can pass along the (delayed) input reference clock, which in my case is 12M that's why I can get 12M and 48M, but your input clock is 48M. | 12:22 |
| tnt | You might still be able to use it to pass along your 48M, program the PLL for 24M and then use the GENCLK_HALF output mode. | 12:23 |
| xobs | Yeah, I'm considering changing the crystal to 12 MHz in the final version. | 12:23 |
| xobs | Doesn't genclk_half say nothing about the phase relationship? | 12:23 |
| tnt | AFAIK the edges are aligned ... but ... the doc on the PLL are really not that clear / explicit. | 12:24 |
| tnt | Is the output of the rx shifter o_put / o_data supposed to be the packet bytes already aligned ? | 12:35 |
| tnt | https://i.imgur.com/8r3UhzR.png | 12:38 |
| tnt | First packet is fine, but even the second is already screwed up PID byte is reported as C2 instead of C3 | 12:39 |
| xobs | I'm pretty sure it's supposed to be aligned (cc: mithro), but that sounds like exactly the problem that I'm hitting. | 12:53 |
| xobs | tnt: I just got home. THis is my clock tree that generates the 1.6ns delay I was talking about: https://github.com/xobs/foboot/blob/master/hw/foboot-bitstream.py#L75 | 12:58 |
| tpb | Title: foboot/foboot-bitstream.py at master · xobs/foboot · GitHub (at github.com) | 12:58 |
| tnt | Also btw, nextpnr reports Info: Max delay posedge clk48_1 -> posedge clk12_$glb_clk: 13.05 ns | 12:59 |
| tnt | at the very least, it should go register to register because nextpnr doesn't constrain cross-clock path at all, just reports them. | 12:59 |
| xobs | That's fine, depending on which "clk48" it's talking about. With the PLL-derived clk48, there are two "clk48" domains: one that's raw from the crystal, and one that's derived from the PLL. | 13:00 |
| tnt | err maybe. But I had some much troubles in the past with CDC that I don't take any chances nowadays. The only way I would trust output from 48m to be captured in 12m success fully is to ensure the 48m strobe rising edge matches the 12m falling edge and go register to register to be right in the middle of that data valid eye. | 13:08 |
| *** rohitksingh_work has quit IRC | 13:09 | |
| futarisIRCcloud | CDC = clock domain crossing | 13:09 |
| tnt | yes. | 13:09 |
| xobs | Well, I /can/ tell you that I accidentally discovered that the timing is very good on it, because I was measuring the phase relationship between them and accidentally set my scope to 12 kHz. It didn't seem to mind, and the aliasing made it seem reasonable. | 13:09 |
| xobs | But I agree, CDC is hard. Which, again, is why I'm considering changing the BOM item for the next batch. | 13:10 |
| tnt | But without explicit sync you can always get what I posted in the screenshot above. | 13:10 |
| xobs | I wonder if it's worth it to run the PLL at 12 MHz despite it being out of sync. | 13:10 |
| tnt | The clock recovery stobes moves one cycle back/forth and that just happens to make it go from one 12m cycle to the next, completel screwing up the data. | 13:11 |
| xobs | Yeah, totally agreed. It's not great at all, and the bit error rate right now is too high to be usable. | 13:12 |
| xobs | But at least the clock is *mostly* good now, and thanks to your admonishments we're pretty sure where the problem lies. | 13:13 |
| tnt | When I talked to mithro at ccc, I though that the 8:1 serdes was done in the 48m domain, thus you just had 1 strobe every so often from 48m to 12m giving you ample time to cross clock. | 13:13 |
| tnt | You could just try to instanciate an sync fifo passing the bits back and forth between the two domain ... it's hugely wastefu resource wise, but should be easy to do in migen and safe. | 13:14 |
| tnt | "async fifo" not "sync" obviously | 13:15 |
| tnt | lol, I had to google "admonishments" :) I hope I didn't come out as pushy or anything, just trying to help with stuff I've seen in the past. | 13:16 |
| xobs | It's okay, I'm sorry, I'm just getting a bit frustrated with this. It's very challenging, and not something I've done extensively before. So I know I'm running into all sorts of issues. | 13:18 |
| xobs | I'm pretty sure it's not a problem with CDC, because I'm using an older version that has async fifos all over the place. It won't necessarily respond in time, but even that's getting corrupt packets. | 13:21 |
| tnt | :/ Do you have a commit id ? I'm curious to run it through the sim I have setup here. | 13:24 |
| xobs | ...at least I thought it did. Now I'm just seeing it use cdc.MultiReg | 13:24 |
| tnt | oh yeah, MutiReg wouldn't help. | 13:24 |
| xobs | Ah, the AsyncFIFOs are in the CPU interface. Maybe I'll throw that hammer at it then. | 13:25 |
| xobs | https://github.com/xobs/valentyusb/tree/14e116ff82b825069a92292308f4f66ad6167dff is the tree that I'm looking at. | 13:25 |
| tpb | Title: GitHub - xobs/valentyusb at 14e116ff82b825069a92292308f4f66ad6167dff (at github.com) | 13:25 |
| xobs | How are you running this through your testbench? Just generating the Verilog files and hooking them up to iverilog? | 13:27 |
| tnt | Just a thought, but the RxShifter is pretty small ... I don't see why that couldn't be moved to the 48m domain, IMHO that would be way simpler to cross 8 bits at once every 32 clock cycles than 1 bit every 4. | 13:27 |
| tnt | xobs: Let me zip the whole thing. | 13:27 |
| tnt | http://people.osmocom.org/~tnt/stuff/sim.tar.bz2 | 13:30 |
| tnt | I generated the top.v normally. Then I did manually patch a couple of things in it. I decreased the reset counter from 4096 to 100 to get it to start quicker, and I also added a 5 ns delay between clk_12m edge and clk_48m edge (that was to simulate the hw, before I knew about the PLL). | 13:31 |
| xobs | That seems very, very sane. | 13:51 |
| tnt | running the older tree through that sim still shows error for me. At different places, but still bytes are corrupted. Also the shifter data bus seems bit-reversed ? | 13:57 |
| xobs | That does make sense. I think that, because of how it's set up (with the sentinal bit shifting right), it ends up going into the shifter backwards, and when it's wired into the CPU interface it gets sorted out the right way. | 13:58 |
| tnt | yeah, migen is a bit weird that way with 0:7 vs 7:0 in verilog, ... sorts itself out if you stay in migen I guess but when looking at it externally it's a bit confusing. | 13:59 |
| *** awe00 has quit IRC | 14:05 | |
| *** xkapastel has joined #tomu | 14:05 | |
| *** awe00 has joined #tomu | 14:11 | |
| xobs | tht: Ah, I see. You're ignoring the CSR problem and just sending data to it. That's a really good approach. | 14:47 |
| tnt | What's the CSR problem ? :) | 14:48 |
| xobs | tnt: The thing I haven't figured out yet is how to simulate the whole thing. CSRs are how you control the block and get status. For example, there are signals that get wired to an EventManager that shows up in a memory-mapped register. I've been trying to figure out how to access those registers in a simulator. | 14:50 |
| tnt | Ah yeah. Here since I just wanted to see the behavior of the clock crossing / deserializer, I didn't bother. | 14:53 |
| xobs | But since that's where the problem lies, that's probably good enough. | 14:53 |
| *** awe00 has quit IRC | 15:06 | |
| *** awe00 has joined #tomu | 15:08 | |
| xobs | Wow, tnt, this iverilog output looks so cool. And it's super fast to generate. Now I need to get the USB sigrok filter working, too. | 15:20 |
| tnt | xobs: https://pastebin.com/T7dUXrtL | 15:22 |
| tpb | Title: [Diff] diff --git a/valentyusb/usbcore/rx/nrzi.py b/valentyusb/usbcore/rx/nrzi.py index - Pastebin.com (at pastebin.com) | 15:22 |
| tnt | That's a quick hack to put a fifo in there. The data output of the shifter looks a whole lot saner to me with this. | 15:23 |
| tnt | the sigrok decoding can be a bit fussy, sometime I have to 'refresh' (using the reload button) several time for it to decode properly. | 15:26 |
| *** awe00 has quit IRC | 15:35 | |
| *** futarisIRCcloud has quit IRC | 15:39 | |
| *** awe00 has joined #tomu | 15:41 | |
| mithro | tnt: fixing the clock 48 to 12 handling was on my to-do list | 15:51 |
| tnt | the hack I posted above might be enough to confirm it's the issue and it fixes the corruption xobs was seeing on RX. But not sure I'd call it a 'fix'. That fifo adds unacceptable latency. | 15:52 |
| mithro | tnt: correct | 15:53 |
| xobs | It's enough to get started. | 15:53 |
| xobs | I'm stuck trying to get sigrok filtering working now, though :) | 15:53 |
| tnt | Ah, well might be able to help with that. What are the symptoms ? | 15:54 |
| xobs | tnt: no errors, but nothing happens. | 15:55 |
| xobs | Fair warning: I'm running this on Windows. | 15:56 |
| xobs | So if I run it under gtkwave.exe and I add the filter of "C:\Python36\python.exe" and set the args to "gtkwave-sigrok-filter.py -P usb_signalling:signalling=full-speed,usb_packet:signalling=full-speed" then it at least shows decoded bits. | 15:56 |
| xobs | If I run it under `gtkwave` on Ubuntu 16.04, and add `dec-usb.sh` as the filter, then I just get a solid yellow line. | 15:57 |
| mithro | xobs: check the time scale in the vcd file? | 15:58 |
| xobs | I guess it's a good sign that, under Ubuntu, if I run "dec-usb.sh < [vcdfile]" it also has no output, so at least it's being consistent. | 15:59 |
| tnt | This is what I do : https://pastebin.com/DGXzhjFf | 15:59 |
| tpb | Title: Open VCD From usb_tb, Add usb_dp From usb_tb, Add usb_dn Select them both in - Pastebin.com (at pastebin.com) | 15:59 |
| tnt | well you can't just feed the simulation vcd file to dec_usb. gtkwave will generate a specially formatted vcd with just the data selected. | 16:00 |
| tnt | But if you see the bits, you just need to insert blank traces at the right place to see the rest. | 16:00 |
| xobs | So on Windows, I see bits, and if I do "Insert Blank" I get a red trace with no data that I can drag up to be directly between "USB" and "usb_dn". | 16:02 |
| xobs | On Ubuntu I just get a solid yellow line and no error messages. | 16:02 |
| xobs | Oh, that's nice, Ubuntu's console actually works. | 16:03 |
| xobs | `--protocol-decoder-samplenum` | 16:03 |
| xobs | Rather, `Unknown option --protocol-decoder-samplenum` | 16:03 |
| xobs | Guess I need to update sigrok. | 16:03 |
| tnt | ah yeah, that's the option to get it to output which sample number each decoded output matches to. | 16:04 |
| mithro | xobs: btw I would expect iverilog to be roughly 1000 times faster then Migen's simulator | 16:04 |
| tnt | Can you post a screenshot of windows ? Never saw that beahvior :/ | 16:04 |
| * xobs uploaded an image: image.png (53KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/FuuTEHyRQloYVfJAgQjADfMa > | 16:05 | |
| tnt | Oh, the decoder filter isn't even active or you wouldn't see 'USB' as the name of the trace. | 16:05 |
| mithro | xobs: I would make sure you have sigrok from head | 16:09 |
| xobs | Alright, I'll figure out how to build it tomorrow. I actually modified the Python file to call sigrok-cli.exe, and I think that's actually working, it's just not able to read the tempfile. | 16:09 |
| mithro | xobs: I would make sure you have sigrok from head | 16:09 |
| xobs | Anyway, thanks for the help! This is looking very promising. | 16:10 |
| xobs | For now, I think I'm going to head to bed. | 16:10 |
| mithro | I'm sure I showed you how to view this on Migen output to? | 16:11 |
| *** xkapastel has quit IRC | 16:15 | |
| *** xkapastel has joined #tomu | 16:25 | |
| tnt | Oh, there is the samll issue that with the fifo it doesn't meet timing :/ | 16:29 |
| mithro | tnt: Need to create a 1bit buffer using flipflops | 16:31 |
| tnt | Info: 6.1 ns logic, 16.5 ns routing | 16:35 |
| tnt | ICESTORM_LC: 4797/ 5280 90% is probably part of the issue. | 16:37 |
| tnt | Ok, tweaking the synthesis options brought that to 4575/ 5280 and 10 MHz faster, to 53 MHz | 16:41 |
| tnt | I have no idea if migen allows it, but adding "-relut -dffe_min_ce_use 4" to synth_ice40 options is pretty much always a gain in both size and frequency. | 16:43 |
| *** awe00 has quit IRC | 17:01 | |
| *** rohitksingh has joined #tomu | 17:33 | |
| *** rohitksingh has quit IRC | 19:36 | |
| *** rohitksingh has joined #tomu | 19:49 | |
| *** rohitksingh has quit IRC | 21:13 | |
| *** Farscrap has joined #tomu | 23:54 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
