IRC logs for #openrisc Sunday, 2013-08-11

--- Log opened Sun Aug 11 00:00:06 2013
stekernolofk: works fine!02:56
stekernorpsocv3 is really maturing, you have an user base that gives bug reports and do patch testing for you and all! =P02:57
stekern...and ethmac is even worse than I thought03:26
stekernwhy is it doing CRC check in the RX clock domain??03:27
stekernthe only thing you should have clocked by the RX/TX clocks are the fifos03:30
olofkstekern: There's way too much crap going on in the RX clock domain08:34
olofkAnd thank you for breaking my orpsoc, so I had to fix it08:35
olofkBut if you doing CRC check before the FIFO, you can throw away the packets08:36
olofkstekern: 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
stekernolofk: I tested running it, just to see that all tests passes if I'd get into the mood of poking at it08:43
stekernbut I'm not sure how likely that is after looking around...08:43
stekernyou can drop packages on the other side of the fifo too, or what did you mean?08:44
olofkYes, you can, but if you have a slow internal clock, it's probably better to never let them enter the FIFO08:45
olofkBut in reality you probably want packages with CRC errors forwarded anyway08:45
olofkI just mean that it's not completely wrong to do the check before the FIFO08:46
stekernyeah, agreed08:46
stekernbut it's not like it's going to make a big difference in your case anyways08:47
stekernI mean, most of the packet has entered the FIFO when the RXCLK side can do CRC calculation anyway08:49
olofkAhh.. yes that's true08:49
olofkAnd I totally agree on that we should have as little as possible in the RX domain08:50
stekernIMO the fifo should just be {rxclk_rxdv, rxclk_rxd[3:0]} => fifo => {wbclk_rxdv, wbclk_rxd[3:0]}08:52
olofkI 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 interface08:54
stekernumm, mii is 4 bit08:55
olofkahh.. sorry08:56
stekernbut sure, I can stretch my requirement to move the combining of two rxdv transitions to the rx clock08:57
stekernbut then you have to do incomplete frame detection in the rx clock domain too08:59
stekernfor the case when you'd only have rxdv asserted for half a byte08:59
olofkHow does that work for rmii? Can you have incomplete two-bit segments there?09:01
stekernno, because the rxdv is muxed with crs in rmii, so each rxdv is for 4 bits there too09:02
olofkok, then it's the same situation as for mii and it's probably better to move to the sys clock domain09:04
stekerni.e. the transitions are: rxvd & rxd[1:0], crs & rxd[3:2]09:04
stekern(I might remember the endianess wrong though)09:05
olofkI seem to recall something like that too09:07
olofksmii seems to be 8 bit (after deserializing). But I guess that can be cut up into nibbles as well09:10
olofkIf we want to do gigabit, we would probably need byte FIFOs09:17
stekernmmm, but you'll need the same changes for that, regardless what side of the fifo you do them10:09
--- Log closed Mon Aug 12 00:00:08 2013

Generated by 2.15.2 by Marius Gedminas - find it at!