Friday, 2019-09-13

*** tpb has joined #litex00:00
*** freemint has joined #litex00:10
*** CarlFK has joined #litex00:35
xobs_florent_: Another issue with doing it that way is reserved names -- if we do it that way then we can't have DCSRFields named `size`, `name`, `value`, etc. Which seems like an implementation detail leaking out.00:45
*** _whitelogger has quit IRC02:00
*** _whitelogger has joined #litex02:02
*** CarlFK has quit IRC06:12
*** rohitksingh has quit IRC06:49
*** CarlFK has joined #litex08:07
_florent_xobs: i've just experimented a bit with csr, what do you think about that: https://github.com/enjoy-digital/dreg/blob/master/ecsr.py14:25
tpbTitle: dreg/ecsr.py at master · enjoy-digital/dreg · GitHub (at github.com)14:25
_florent_https://github.com/enjoy-digital/dreg/blob/master/test.py14:25
tpbTitle: dreg/test.py at master · enjoy-digital/dreg · GitHub (at github.com)14:25
_florent_this add field and description support to CSRs, we could just also modify CSRStorage/CSRStatus to support field natively14:26
_florent_some of your usecases are still not covered: pulse, hidden and how to do write_from_dev with fields, but just wanted to know what you think14:27
xobsIt does handle gaps, which is nice.14:31
xobsIt also places everything under "fields", instead of separating it into "w" and "r".  That's nice to know you can use "setattr" like that in Python -- that seems to contradict a Stack Overflow answer that I found.14:34
xobsOne of the nice things that I added to Fields are `values`, which can be directly mapped to SVF files: https://github.com/xobs/dreg/blob/master/dcsr.py#L29014:35
tpbTitle: dreg/dcsr.py at master · xobs/dreg · GitHub (at github.com)14:35
xobsAlso, I had "readable" and "writeable" as Field properties so that they could be mapped to `reg` diagrams to indicate fields that were write-only.  I suppose the SVD specification has field values like "w1c", "w1s", and things like that.14:39
xobshttp://www.keil.com/pack/doc/cmsis/svd/html/elem_registers.html#elem_enumeratedValues14:39
_florent_for the field property, you can pass it as **kwargs, but we could also create a class that inheritate from ECSRField with more parameters?15:27
xobsThat's what I was thinking, but for the actual field, at least in SVD, it's only (possible values, description) or (possible values, enum name, description).15:55
xobsflorent: I thought about making a subclass, but I think the tuple approach covers all cases.16:15
_florent_for the values of fields?16:16
_florent_of/or16:16
*** rohitksingh has joined #litex17:36
somlo_florent_: so I ran some benchmarks on litex+rocket (hardware FPU, 60MHz, on a nexys4ddr)17:56
*** freemint has joined #litex17:56
somlo_florent_: coremark came back with "71" (lowRISC at 50MHz gets 103, and a pentium 100MHz gets 212, per google)17:57
somloso I think it's time for me to try and sort out the rocket axi memory interface -- unlike the other supported CPUs in LiteX, Rocket has two dedicated AXI interfaces, one for mmio and the other for cached RAM accesses17:58
somloand I'd like to figure out a way to have LiteDRAM's CSRs stay behind on the CSR bus with all other peripherals, but expose a separate AXI interface that I'd connect to Rocket's dedicated cached-ram AXI, so that there's no contention17:58
somloand hopefully at 64-bit width, or more :)17:59
somloI guess I'll be staring at LiteX migen source code again, but any advice before I dive in would be much appreciated!17:59
somlofunny side note, I actually scored an old original pentium-100 machine someone was about to recycle, and it still powers on. I'm waiting for a usb-to-ps2 keyboard dongle before I can run my own actual benchmark code on it, so I won't have to believe some historical numbers off the wild Internet :)18:03
daveshahfwiw, VexRiscv claims 2.27 Coremark/Mhz18:15
daveshahBut I'm not sure what it gets in a LiteX SoC18:15
somlodaveshah: I know right now rocket has to split each 64bit access in two, since the native LiteX bus is 32bit18:18
daveshahAaaa18:19
daveshahthat's no fun on anything with wideish DDR318:19
somlothat's why I included lowRISC, which uses the mig7series controller from xilinx, at native 64bit width18:19
daveshahEven litedram is pretty wide18:19
somlonot sure how much betther *that* could get, but it's a good target for optimization once I fix the bottleneck18:19
daveshahon the TrellisBoard the DDR3 side width is 32*4 (x4 gearing ratio)18:20
somlothe first priority was to get it working *at all* :) Now that that's done, it's time to actually handle all the technical debt we accumulated along the way...18:20
somlommio and cached-ram axi masters sharing the same bus, and down-shifting from 64bit to 32bit word size on top of that18:21
somloI can probably leave the mmio side downshifting to 32 bits for now, if I can only figure out a way to separate the cached-ram axi interface and have it talk to LiteDRAM on a dedicated link18:22
daveshahSomething else I'm vaguely curious about is running the RAM faster than the CPU (litedram should easily manage 100MHz), but the added clock domain crossing latency might not be worth it18:22
somlodaveshah: that, and whether I could widen Rocket's cached-RAM axi port beyond 64 bits18:23
somlosince rocket has an internal L1, it will read/write a whole cache line in an AXI burst18:24
daveshahIn the long term, one would probably want some spare memory bandwidth for video output framebuffer accesses18:24
daveshahThat seems like it could match the DDR3 nicely18:24
somloyeah, lots of room to make things better -- my goal is to approach parity with the 100MHz Pentium from the mid-90s, of which I have fond memories :)18:25
somlodaveshah: btw, fpu-less rocket at 60MHz, nexys4ddr (vivado) coremark 27, versa (yosys/trellis/nextpnr) coremark 33 :)18:31
daveshahHuh18:31
somlocan't fit the fpu on the versa, but wanted to see if all else was equal, would there be a difference between artix and ecp518:32
daveshahI thought litedram was faster on the artix718:32
somlonexys4ddr has ddr2 memory, versa is ddr3, not sure if that explains it18:32
daveshahpossibly18:32
somloalso not sure how much variability there is between multiple coremark runs on the same machine18:33
somlohaven't done e.g. average over 10 runs, or anything like that18:33
somloso not quite 100% sure why -- maybe because yosys/trellis/nextpnr are awesome like that :)18:33
daveshahYeah, our magic pipeline rewriting algorithm :p18:34
*** freemint has quit IRC18:35
*** freemint has joined #litex18:35
somloanyhow, I'll have to give in and run coremark (and my other benchmarks too) multiple times, and figure out the standard deviation, and all that scientific stuff before publishing "official" numbers18:36
somlowhich is also why I'm not happy to just google the Pentium-100 numbers, and will run them for myself18:37
*** rohitksingh has quit IRC19:01
*** freemint has quit IRC19:36
*** rohitksingh has joined #litex19:40
_florent_somlo: yes now that it's working, we need to identify and remove the bottlenecks, that fact that we downconvert from 64 bit to 32 bit then up convert to the native DRAM width seems clearly a bottleneck, i'll look at what can be done there19:58
John_K getting the following error when trying to use LiteEthPHYGMIIMII, is this a common / known issue?20:02
John_K"ERROR:Place:1108 - A clock IOB / BUFGMUX clock component pair have been found that are not placed at an optimal clock IOB / BUFGMUX site pair."20:03
John_K"The clock IOB component <eth_clocks_rx> is placed at site <AB11>. The corresponding BUFG component <eth_rx_clk_BUFG> is placed at site <BUFGMUX_X3Y7>."20:03
_florent_how many bufg are used in your design, how many available?20:13
John_KNumber of BUFG/BUFGCTRLs:                4  out of     16    25%20:17
_florent_you can probably get rid of the error with        platform.add_platform_command("""PIN "eth_clock_rx" CLOCK_DEDICATED_ROUTE = FALSE;""") , but not sure it will be functional20:24
John_Kyeah I saw that in the error message and had the same thoughts20:35
John_Kis the Spartan 6 family really this bad or am I just running into regular-ish pains?20:35
*** john_k[m] has quit IRC20:41
*** nrossi has quit IRC20:42
*** xobs has quit IRC20:42
*** freemint has joined #litex20:42
*** xobs has joined #litex20:49
*** nrossi has joined #litex21:10
*** john_k[m] has joined #litex21:10
*** rohitksingh has quit IRC21:43
*** rohitksingh has joined #litex21:47
davidc__John_K: the S6 should be plenty fast to speak MII/GMII/RGMII; I've done it with S3Es before21:51
davidc__however you need to take care in terms of clock resource allocation; sounds like there might be some contention in your design21:52
daveshahMaybe the Pano Logic designers messed up the pinout :p22:00
daveshahWe've all been there22:01
davidc__there's also a few weird modes some phys support that do strange things with clocking23:17
davidc__(ex, some phys support the master generating all the clocks and have an internal buffer to deal with the frequency delta)23:18
davidc__Others support skewing clock->data for transmit, and the receive sample point23:19
*** rohitksingh has quit IRC23:31
*** rohitksingh has joined #litex23:42

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!