Friday, 2019-11-08

*** tpb has joined #litex00:00
*** freemint has quit IRC01:03
*** freemint has joined #litex01:05
*** _whitelogger has quit IRC03:15
*** _whitelogger has joined #litex03:18
*** _whitelogger has quit IRC05:12
*** _whitelogger has joined #litex05:15
*** _whitelogger has quit IRC05:36
*** _whitelogger has joined #litex05:39
*** _whitelogger has quit IRC06:06
*** _whitelogger has joined #litex06:09
*** _whitelogger has quit IRC06:54
*** _whitelogger has joined #litex06:57
*** _whitelogger has quit IRC07:30
*** _whitelogger has joined #litex07:33
*** freemint has quit IRC10:10
*** freemint has joined #litex10:16
*** freemint has quit IRC10:35
*** rohitksingh has quit IRC11:18
*** rohitksingh has joined #litex11:24
*** rohitksingh has quit IRC11:51
*** freemint has joined #litex14:00
*** freemint has quit IRC14:03
*** freemint has joined #litex14:16
*** freemint has quit IRC14:45
*** freemint has joined #litex15:28
*** rohitksingh has joined #litex17:04
*** rohitksingh has quit IRC17:51
somlothe default Rocket Linux variant is set up with (nSets=4, nWays=1, nTLBs=4) for both the L1D and L1I caches, and per my earlier experiments connecting LiteDRAM directly to the cached-RAM axi port, we get a 7% performace boost going from 64-bit to 128-bit data width, and a 1% boost going 128->256.17:55
somloit was nagging at me that some of that is muddied by the presence and size of the cache, so I generated low-cache Rocket variants with (nsets=4, nways=1, ntlbs=4)17:56
*** rohitksingh has joined #litex17:56
somloMUCH worse performance overall, but going from 64-128 mem_axi data width got me 18% better perormance, and going from 128->256 data width got me a 3% improvement17:56
somloso, more improvement from mem_axi width doubling in the absence of a large L1 cache17:57
somlo_florent_, daveshah: ^^17:57
somlojust wanted to make sure it's actually worth adding "wide" rocket variants as a first choice, and keeping data-width FSM based conversion as a backup plan only17:58
*** ambro718 has joined #litex18:07
somlobut with small caches, performance was really BAD in absolute terms, so it took a few days to get all the results :)18:07
*** keesj has quit IRC19:00
*** freemint has quit IRC20:08
scanakci_florent_: I am a bit confused about --rom-init in terms of provided file format. My understanding is that mem.init file in generated gateware folder contains rom content. If I put my program into mem.init (each line includes 32 bit number in hexa format), I successfully simulate the program. If I use the --rom-init with the same file, It does not work.20:15
scanakciFor a reason, mem.init file does not contain what I want to have in ROM.20:16
*** freemint has joined #litex20:22
_florent_somlo: thanks for the results, so do you think it's useful to use 128-bit data-width with the L1 cache?20:34
_florent_scanakci: --rom-init should point to a binary file, mem_x.init are the memory initialization files for the generated verilog20:40
_florent_scanakci: but if you pass a binary file to --rom-init, you should have a mem_x.init file with the same content (but in hexa format)20:41
scanakcithanks _florent:. I will try it soon.20:41
scanakciI could generate a bitstream of Litex+Blackparrot. As far as I see, there is not --rom-init option in genesys2.py file.20:42
scanakciHow am I supposed to load Litex-ROM? I thought that it is again reading from file during systhesis with readmemh.20:43
*** CarlFK has quit IRC20:46
_florent_indeed, it's not available from the command line, but i could add that20:46
*** rohitksingh has quit IRC21:02
*** rohitksingh has joined #litex21:10
scanakciokay. using binary file with --rom-init still did not give me my expected mem.init file. For now, I will manually update mem.init in gateware for both simulation and FPGA.21:54
*** ambro718 has quit IRC22:08
*** rohitksingh has quit IRC22:15
*** CarlFK has joined #litex22:15
*** somlo has quit IRC23:44
*** somlo has joined #litex23:46

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