| --- Log opened Wed Oct 04 00:00:14 2017 | ||
| mtn2 | Where can I find latest version of wb_intercon_gen | 07:29 |
|---|---|---|
| juliusb | stekern: can you help refresh my memory on how caches work - in the mor1kx cache, what do BLOCK_WIDTH and SET_WIDTH mean with regards to the number of lines of cache instantiated? | 08:29 |
| juliusb | and this guy: https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_icache.v#L65 | 08:29 |
| juliusb | We add those two together and 2**WAY_WIDTH is basically the number of lines we have? | 08:30 |
| juliusb | defaults are parameter OPTION_ICACHE_BLOCK_WIDTH = 5, parameter OPTION_ICACHE_SET_WIDTH = 9 | 08:31 |
| juliusb | and I think i got it, BLOCK_WIDTH is the line size log2 and SET_WIDTH is number of lines log2 | 08:31 |
| juliusb | BLOCK_WIDTH of 5 is 32 bytes a line, 9 for width is 512 lines, total cache size per way of 16kB | 08:32 |
| stekern | yeah, SET is the number of lines and BLOCK is the size of each line | 08:32 |
| juliusb | Nice, thanks. | 08:32 |
| juliusb | Sorry it only took me 4 years to look at your cache implementation. It's nice :) | 08:33 |
| stekern | some of it is wallento's work too ;) | 08:33 |
| juliusb | It's much nicer than what ended up in the OR1200. | 08:34 |
| stekern | I can't remember what that looked like anymore | 08:35 |
| juliusb | Don't remind yourself. It wasn't pretty. | 08:35 |
| shorne | juliusb: what are you looking at this for? | 09:24 |
| shorne | mtn2: is this what you are looking for? https://github.com/stffrdhrn/orpsoc-cores/blob/master/cores/wb_intercon/sw/wb_intercon_gen | 09:26 |
| shorne | (sorry thats my fork or opencores) The original is in olofk's repo but its old | 09:27 |
| shorne | https://github.com/olofk/wb_intercon | 09:27 |
| mtn2 | Thanks | 09:28 |
| mtn2 | I need some reference configuration file also, as I need to regenerate. Can't find in above 2 links | 09:29 |
| mtn2 | Configuration file, which is input to https://github.com/olofk/wb_intercon/blob/master/sw/wb_intercon_gen | 09:31 |
| juliusb | shorne: helping out mithro - just figuring out if we can fit the mor1kx onto the LX9 spartan 6 | 09:32 |
| juliusb | This board: https://numato.com/product/mimas-v2-spartan-6-fpga-development-board-with-ddr-sdram | 09:35 |
| juliusb | Pity it was such a small FPGA, but I don't know if he's done an entire SoC or just the mor1kx | 09:35 |
| juliusb | shorne: we missed you at ORConf this year man! | 09:36 |
| juliusb | But I understand it's a long way to go. | 09:36 |
| mtn2 | Got one here. https://github.com/myriadrf/STREAM/blob/master/stream_openrisc_soc/src/stream/data/wb_intercon.conf | 10:01 |
| shorne | mtn2: there are a bunch of example config files here | 10:05 |
| shorne | https://github.com/openrisc/orpsoc-cores/tree/master/systems/de0_nano/data | 10:05 |
| shorne | basically https://github.com/openrisc/orpsoc-cores/tree/master/systems/*/data | 10:05 |
| shorne | juliusb: yeah, my parents were visiting and the baby is still young, it didnt work out | 10:06 |
| shorne | mithro asked me to help look into the mimas v2 board as well, but I am trying to finish up some patches for GDB | 10:08 |
| shorne | hope it can finally get merged | 10:08 |
| shorne | then qemu SMP, linux SMP, orpsoc-cores multicore, and openocd multicore patches! | 10:08 |
| shorne | :( | 10:08 |
| mtn2 | Thanks Shrone. Kind of new to orisc... hence basic questions | 10:58 |
| mithro | ZipCPU: Is your autofpga a reinvention of FuseSoC and MiSoC? | 20:45 |
| ZipCPU | mithro: That's a really good question. | 20:45 |
| mithro | btw I love your blog | 20:45 |
| ZipCPU | After chatting with olof, I can tell you with certainty that it is not a reinvention of FuseSoC. | 20:45 |
| ZipCPU | (Thanks--I'm trying to put some AutoFPGA blog articles together as we "speak") | 20:46 |
| ZipCPU | As for MiSoC ... that's a harder one to answer. | 20:46 |
| ZipCPU | AutoFPGA isn't a programming language. It's an ability to copy things from a configuration file to pieces of code that AutoFPGA will generate. | 20:46 |
| mithro | MiSoC tries to take a lot of the work out of creating a bunch of SoCs | 20:47 |
| ZipCPU | AutoFPGA also builds files that go well beyond just the RTL. | 20:47 |
| ZipCPU | AutoFPGA assigns bus addresses, and builds a bus of the components on it. | 20:47 |
| mithro | ZipCPU: MiSoC then generates you gateware, bios, C headers for accessing CSRs, etc | 20:47 |
| ZipCPU | It also builds a linker file, C-headers, host-based command and control header files, Make file includes, and more. | 20:48 |
| ZipCPU | I haven't gone so far as to generate a BIOS with it, but it does put (some) of the gateware together, as well as the C-headers. | 20:48 |
| ZipCPU | Unlike migen ... no Python is required! Ok, realistically, that's an irrelevant fact. | 20:49 |
| ZipCPU | Or is it? To add a file into AutoFPGA, you just specify what values need to be pasted into what files where. That's it. | 20:49 |
| ZipCPU | There's not much more magic going on behind the scenes ... although there is some. | 20:49 |
| ZipCPU | There's an integer expression evaluator, the bus address calculator, the bus composer, an interrupt assignment module, and so forth. | 20:50 |
| ZipCPU | AutoFPGA also helps you to build a Verilator simulation--one that can (potentially) use multiple dissimilar clocks (if necessary). | 20:51 |
| ZipCPU | My goal was that the AutoFPGA user shouldn't need to learn a new language, but rather provide snippets of source languages: Verilog or C++, that would then get pasted into the files it produces. | 20:52 |
| ZipCPU | When I've examined MiGen, it looks like you need to "import" your design into their hierarchy and structure--something that really isn't required at all with AutoFPGA. | 20:52 |
| mithro | ZipCPU: Yeah - I'm hoping to add "auto import" into Migen / MiSoC in the near future -- but it doesn't exist currently | 20:53 |
| ZipCPU | Are you a migen/misoc maintainer? | 20:53 |
| mithro | ZipCPU: nope! | 20:54 |
| ZipCPU | "I'm hoping to add 'auto import' into ..." <--- no? | 20:54 |
| mithro | ZipCPU: Just possibly the third biggest user I think.... | 20:54 |
| ZipCPU | Really? | 20:54 |
| ZipCPU | Please, then .... tell me what you think of it! | 20:55 |
| ZipCPU | I've never used it .... ;) | 20:55 |
| mithro | ZipCPU: the #m-labs guys are the owners / maintainers of Migen / MiSoC | 20:55 |
| mithro | _florent_ from Enjoy-Digital is probably the next biggest user | 20:55 |
| mithro | Then my TimVideos HDMI2USB project is likely the next one after that.... | 20:55 |
| mithro | But there could be users I don't know about | 20:56 |
| ZipCPU | Ok, sure but ... what do you think about it? | 20:56 |
| mithro | ZipCPU: The big win for me is writing in a high level language rather than having to write Verilog | 20:56 |
| ZipCPU | Go on ... | 20:57 |
| FL4SHK | What are Migen / MiSoc? | 20:57 |
| ZipCPU | https://m-labs.hk/gateware.html | 20:57 |
| ZipCPU | https://github.com/m-labs/migen/blob/master/doc/introduction.rst | 20:58 |
| mithro | Okay - Migen is the "Python based HDL", MiSoC is a library of cores written in Migen which makes building SoCs very easy | 20:58 |
| ZipCPU | That's a pretty decent definition | 20:58 |
| mithro | At a high level you can think of Migen as just an easy way to generate Verilog | 20:59 |
| ZipCPU | But ... you were saying that it does more than Verilog, right? | 20:59 |
| mithro | But the big win for me in Migen is it means you can do things like modules which when connected together can "negotiate" how they talk to each other before generating any low level code | 20:59 |
| FL4SHK | why specifically does it use Python? | 20:59 |
| mithro | For example you could have a module which supports multiple bus types - say wishbone and axi -- then when you connect it to a wishbone bus it uses the wishbone config automatically, and when connected to an axi bus it uses the axi config automatically | 21:00 |
| ZipCPU | At one time I was going to place such "negotiation" into AutoFPGA ... I just didn't get that far before my project needed to move on (and my presentation needed to be written) | 21:01 |
| ZipCPU | I like that idea, though. | 21:02 |
| FL4SHK | It does seems this is ignoring SystemVerilog at the very least | 21:02 |
| mithro | Another example would be a PLL module which just takes "Input frequency is 100MHz, I want clocks outputs of X, Y, Z" you can write Python code to figure out how the PLL needs to be configured to meet those requirements | 21:02 |
| mithro | (That doesn't exist yet - but it's on my todo list :-) | 21:02 |
| ZipCPU | Yeah, I've thought about adding that to AutoFPGA as well --- especially since the PLL's are a limited resource, that many modules want access to. | 21:03 |
| mithro | Yeah - Peripherals also just define "I want a CSR which looks like this" and then when it's added to a SoC it's automatically connected to the CSR bus (addresses are calculated), C header files are automatically generated (in the future device tree fragments too), etc | 21:04 |
| mithro | ZipCPU: It also has a lot of the things that you talk about on your blog - like XXX to Wishbone bridges | 21:05 |
| mithro | ZipCPU: I gave a talk about it here -> https://www.youtube.com/watch?v=MkVX_mh5dOU | 21:05 |
| ZipCPU | Right now, the XXX to wishbone bridge within AutoFPGA needs to be done manually--as it's own component, but with a given bus as the slave and another as the master. | 21:05 |
| mithro | https://j.mp/pyhw-lca2017 | 21:06 |
| ZipCPU | Fascinating ... although it'll take me a while to watch through those ... | 21:08 |
| ZipCPU | mithro: Ever used Verilator? | 21:18 |
| mithro | Sorry, be back later meeting | 21:19 |
| ZipCPU | Rgr. | 21:19 |
| mithro | ZipCPU: have a look at my talk and then we should chat again | 22:35 |
| ZipCPU | Just watched the youtube video. Haven't looked at j.mp yet at all. | 22:35 |
| ZipCPU | The youtube video was fun to watch, because it looks like both you and I are being driven by some of the same realizations about creating hardware. | 22:35 |
| mithro | I'm a software engineer at heart who occasionally pretends to know things about hardware ;-) | 22:36 |
| ZipCPU | Yeah. Me too. I'm very much in my element when I'm writing software. | 22:36 |
| mithro | FL4SHK: SystemVerilog (nor VHDL) is not well supported by the FOSS tools like iverilog, verilator or yosys | 22:38 |
| juliusb | I disagree. I think there's a large chunk of the synthesisable subset which is supported by those tools. It's all of the verification stuff which isn't, and admittedly there's a lot of it, but thankfully we have other ways of doing verification. | 23:54 |
| --- Log closed Thu Oct 05 00:00:15 2017 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!