| --- Log opened Sun Aug 11 00:00:06 2013 | ||
| stekern | olofk: works fine! | 02:56 |
|---|---|---|
| stekern | orpsocv3 is really maturing, you have an user base that gives bug reports and do patch testing for you and all! =P | 02:57 |
| stekern | ...and ethmac is even worse than I thought | 03:26 |
| stekern | why is it doing CRC check in the RX clock domain?? | 03:27 |
| stekern | the only thing you should have clocked by the RX/TX clocks are the fifos | 03:30 |
| olofk | stekern: There's way too much crap going on in the RX clock domain | 08:34 |
| olofk | And thank you for breaking my orpsoc, so I had to fix it | 08:35 |
| olofk | But if you doing CRC check before the FIFO, you can throw away the packets | 08:36 |
| olofk | stekern: Have you seen the testbench for ethmac btw? It's a 18kLOC verilog file launching the test cases. That too could need some refactoring. | 08:40 |
| stekern | olofk: I tested running it, just to see that all tests passes if I'd get into the mood of poking at it | 08:43 |
| stekern | but I'm not sure how likely that is after looking around... | 08:43 |
| stekern | you can drop packages on the other side of the fifo too, or what did you mean? | 08:44 |
| olofk | Yes, you can, but if you have a slow internal clock, it's probably better to never let them enter the FIFO | 08:45 |
| olofk | But in reality you probably want packages with CRC errors forwarded anyway | 08:45 |
| olofk | I just mean that it's not completely wrong to do the check before the FIFO | 08:46 |
| stekern | yeah, agreed | 08:46 |
| stekern | but it's not like it's going to make a big difference in your case anyways | 08:47 |
| stekern | I mean, most of the packet has entered the FIFO when the RXCLK side can do CRC calculation anyway | 08:49 |
| olofk | Ahh.. yes that's true | 08:49 |
| olofk | And I totally agree on that we should have as little as possible in the RX domain | 08:50 |
| stekern | IMO the fifo should just be {rxclk_rxdv, rxclk_rxd[3:0]} => fifo => {wbclk_rxdv, wbclk_rxd[3:0]} | 08:52 |
| olofk | I would expand the data interface to a byte instead. That would make it more consistent if you want to hook up a smii or mii interface | 08:54 |
| stekern | umm, mii is 4 bit | 08:55 |
| olofk | ahh.. sorry | 08:56 |
| stekern | but sure, I can stretch my requirement to move the combining of two rxdv transitions to the rx clock | 08:57 |
| stekern | but then you have to do incomplete frame detection in the rx clock domain too | 08:59 |
| stekern | for the case when you'd only have rxdv asserted for half a byte | 08:59 |
| olofk | How does that work for rmii? Can you have incomplete two-bit segments there? | 09:01 |
| stekern | no, because the rxdv is muxed with crs in rmii, so each rxdv is for 4 bits there too | 09:02 |
| olofk | ok, then it's the same situation as for mii and it's probably better to move to the sys clock domain | 09:04 |
| stekern | i.e. the transitions are: rxvd & rxd[1:0], crs & rxd[3:2] | 09:04 |
| stekern | (I might remember the endianess wrong though) | 09:05 |
| olofk | I seem to recall something like that too | 09:07 |
| olofk | smii seems to be 8 bit (after deserializing). But I guess that can be cut up into nibbles as well | 09:10 |
| olofk | If we want to do gigabit, we would probably need byte FIFOs | 09:17 |
| stekern | mmm, but you'll need the same changes for that, regardless what side of the fifo you do them | 10:09 |
| --- Log closed Mon Aug 12 00:00:08 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!