| *** tpb has joined #litex | 00:00 | |
| benh | somlo: looking at https://github.com/litex-hub/linux/commit/3856b9eae1cd7a243faf13d0d4f41ef337c25376 | 00:27 |
|---|---|---|
| tpb | Title: litex_soc_ctrl: use published api for cpu-native access with barriers · litex-hub/linux@3856b9e · GitHub (at github.com) | 00:27 |
| benh | somlo: this comforts me in saying we should use a fixed endianness (preferably LE) for Linux SoCs :-) | 00:27 |
| benh | somlo: also we may want to add a DT concept of csr-parent pointing to the CSR master or something because for non-LiteX SoCs using LiteX components, one can have multiple CSR busses | 00:28 |
| benh | for example microwatt will probably end up with completely separate CSR busses for liteeth and litesdram | 00:28 |
| *** Skip has quit IRC | 00:31 | |
| benh | somlo: also liteeth has a bug .. the PHY CRG reset ... it's poking at the ethernet mmio instead of the CSRs :) | 00:42 |
| benh | somlo: my preference for CSRs is that any device that has some has the base of them in its "reg" property like any other MMIO range | 00:43 |
| benh | somlo: we *could* provide inline accessors for the read/write but of we make them just 32-bit LE it's not even necessary | 00:43 |
| benh | along with _florent_ work to fix CSR addresses, we completely remove the need for that common CSR layre | 00:44 |
| benh | and it removes problems with multiple CSR busses when using standalone cores etc... | 00:44 |
| benh | I think it's a much better approach this way... | 00:44 |
| benh | is there a better place to discuss this ? | 00:44 |
| benh | somlo: if we really want to keep them native, we can do an inline accessor, but at least the CSR base should just be an mmio region of the device | 00:46 |
| benh | obtained from the device-tree | 00:46 |
| futarisIRCcloud | Discussion is probably best here, or on the linux-litex mailing list ... | 01:06 |
| futarisIRCcloud | awordnot: Xilinx series 7 does work in Synopsys as of a few weeks ago. | 01:20 |
| awordnot | futarisIRCcloud: I'm not familiar with Synopsys. Is it related to the series 7 bitstream reverse engineering efforts? | 01:21 |
| futarisIRCcloud | Yep. | 01:22 |
| awordnot | cool, I'll have to take a look. | 01:23 |
| futarisIRCcloud | SymbiFlow examples: | 01:23 |
| futarisIRCcloud | https://github.com/SymbiFlow/symbiflow-examples | 01:23 |
| tpb | Title: GitHub - SymbiFlow/symbiflow-examples: Examples designs for showing different ways to use SymbiFlow toolchains. (at github.com) | 01:23 |
| mithro | somlo / kgugala: benh recently pointed out https://lwn.net/Articles/451789/ -- https://programmer.group/regmap-api-a-register-map-abstraction.html -- https://opensourceforu.com/2017/01/regmap-reducing-redundancy-linux-code/ | 01:24 |
| tpb | Title: regmap: Generic I2C and SPI register map library [LWN.net] (at lwn.net) | 01:24 |
| futarisIRCcloud | That stuff does reduce redunancy. | 01:25 |
| futarisIRCcloud | aword: SymbiFlow is what I meant before... | 01:25 |
| benh | futarisIRCcloud: where is that mailing list ? | 01:25 |
| futarisIRCcloud | awordnot: SymbiFlow is what I meant before... | 01:25 |
| awordnot | futarisIRCcloud: cool. Is this stuff to the point where I can build something like a VexRiscv soc w/ LiteDRAM? | 01:25 |
| mithro | awordnot: Yes - but it wouldn't say it is user ready yet | 01:26 |
| awordnot | wow, still, that's super impressive | 01:27 |
| futarisIRCcloud | Yeah. Like mithro says, it works. But not as well as Vivado (yet). | 01:27 |
| futarisIRCcloud | See section 3 of https://github.com/SymbiFlow/symbiflow-examples/blob/master/README.md | 01:27 |
| tpb | Title: symbiflow-examples/README.md at master · SymbiFlow/symbiflow-examples · GitHub (at github.com) | 01:27 |
| mithro | I dislike vivado intensely, but is clearly still a long way ahead of the Yosys+vtr flow for now | 01:28 |
| awordnot | this seems to be far more mature than I would have guessed though | 01:29 |
| awordnot | massively impressive work | 01:29 |
| futarisIRCcloud | benh: https://groups.google.com/forum/#!forum/linux-litex | 01:38 |
| tpb | Title: Google Groups (at groups.google.com) | 01:38 |
| benh | how do you use those google groups like a normal mailing list ? | 01:42 |
| benh | I can't find a subscribe button :) | 01:42 |
| benh | ah found "join group" | 01:43 |
| benh | hrm... it wants to send the mails to my gmail..no good | 01:43 |
| mithro | benh: You can provide any email address... | 01:45 |
| benh | mithro: how ? the web UI doesn't seem to let me | 01:45 |
| mithro | Google groups seems to always get worst :/ | 01:46 |
| benh | yeah | 01:46 |
| benh | it's a horrible web forum thing | 01:46 |
| benh | why not create a proper mailing list ? :) | 01:46 |
| benh | that stuff is unusable for me | 01:47 |
| mithro | benh: What email address do you want used? | 01:47 |
| mithro | Emailing [email protected] apparently? I can add you manually too | 01:48 |
| benh | mithro: [email protected] | 01:48 |
| benh | thanks ! | 01:49 |
| benh | ah there's a subscribe .. ok it wasn't documented in the web UI anywhere I could find | 01:49 |
| *** Degi has quit IRC | 02:27 | |
| *** Degi has joined #litex | 02:28 | |
| *** guan has quit IRC | 02:34 | |
| *** mithro has quit IRC | 02:36 | |
| *** bubble_buster has quit IRC | 02:36 | |
| *** levi has quit IRC | 02:38 | |
| *** rohitksingh has quit IRC | 02:38 | |
| *** mithro has joined #litex | 03:15 | |
| *** bubble_buster has joined #litex | 03:17 | |
| *** levi has joined #litex | 03:17 | |
| *** guan has joined #litex | 03:18 | |
| *** rohitksingh has joined #litex | 03:21 | |
| benh | mithro: just to see waht can of bloat it causes | 03:34 |
| benh | we could play around with a device-tree node below each CSR "bus" node that contains basically a set of cs_<regname> = <reg offset, first bit, last bit> | 03:34 |
| benh | and have some wrappers to pipe that into regmap | 03:34 |
| benh | as long as we do that in a way that allow different devices to point to different CSR bridges | 03:35 |
| benh | but if you're going to do things like USB devices, PCIe devices, you really need fixed CSR offsets/layout | 03:35 |
| benh | unless you want every device to carry some kind of description ROM .. I don't think it's worth the pain | 03:35 |
| *** mithro has quit IRC | 03:46 | |
| *** rohitksingh has quit IRC | 03:49 | |
| *** guan has quit IRC | 03:52 | |
| *** bubble_buster has quit IRC | 03:52 | |
| *** rohitksingh has joined #litex | 03:57 | |
| *** levi has quit IRC | 04:03 | |
| *** guan has joined #litex | 04:10 | |
| *** rohitksingh has quit IRC | 04:13 | |
| *** guan has quit IRC | 04:14 | |
| *** guan has joined #litex | 04:15 | |
| *** rohitksingh has joined #litex | 04:15 | |
| *** levi has joined #litex | 04:15 | |
| *** bubble_buster has joined #litex | 04:15 | |
| *** mithro has joined #litex | 04:19 | |
| *** st-gourichon-fid has joined #litex | 04:48 | |
| mithro | _florent_: You should talk more about the documentation you have added to the LiteX wiki -- I didn't know 90% of it existed... | 05:00 |
| *** _whitelogger has quit IRC | 05:45 | |
| *** _whitelogger has joined #litex | 05:47 | |
| *** dasdgw has quit IRC | 07:22 | |
| *** HoloIRCUser has joined #litex | 07:23 | |
| *** kgugala_ has joined #litex | 07:50 | |
| *** kgugala has quit IRC | 07:52 | |
| benh | I notice LiteX PLL feeds CLKFBOUT directly into CLKFBIN .. isn't it supposed to have a BUFG in there? | 08:58 |
| futarisIRCcloud | Yeah, the whole https://github.com/enjoy-digital/litex/wiki is a treasure. And https://github.com/enjoy-digital/colorlite is a good cheap example. | 09:21 |
| tpb | Title: Home · enjoy-digital/litex Wiki · GitHub (at github.com) | 09:21 |
| *** HoloIRCUser2 has joined #litex | 09:22 | |
| *** HoloIRCUser has quit IRC | 09:24 | |
| benh | ah forget about this, we don't need deskewing | 09:38 |
| zyp | I'm playing with the cle215, mmap()-ing the FPGA memory space and I noticed that if I try doing an unaligned access, my whole host system locks up | 11:50 |
| zyp | I don't need/expect unaligned accesses to work, but I'd like them to be more gracefully handled | 11:51 |
| somlo | benh: reading through all the stuff you said earlier :) I just checked, and I should be signed up for the linux-litex google group | 11:52 |
| *** HoloIRCUser has joined #litex | 12:20 | |
| *** HoloIRCUser2 has quit IRC | 12:21 | |
| benh | somlo: ok cool, I signed up too | 12:32 |
| benh | somlo: I need to hit the sack, but I am really keen on sorting out the CSR stuff in a way that allow multiple "things" on a given system to have completely different CSR busses | 12:33 |
| benh | somlo: there are two approaches really... the easy one is we say it's just MMIO and each device has a CSR range in it's "reg" property along with whatever other MMIO | 12:33 |
| benh | somlo: or we go full flex so we can have things with CSRs behind USB or god-knows-what like mithro would like | 12:34 |
| benh | somlo: in which case we look into using regmap for them | 12:34 |
| benh | (which conveniently also supports native endian) | 12:34 |
| benh | somlo: if we go down the regmap path, I'll need to spend a bit of time the next few days looking in more details how it actually works as I have seldom used it in the past | 12:35 |
| benh | somlo: I need to crash now :) g'night | 12:35 |
| zyp | if you're reworking the CSR stuff, I'd like a way to predefine the CSR layout, including adding gaps | 12:36 |
| *** FFY00 has quit IRC | 12:54 | |
| *** FFY00 has joined #litex | 12:55 | |
| *** CarlFK has joined #litex | 15:08 | |
| *** CarlFK has quit IRC | 15:32 | |
| *** tcal has quit IRC | 15:47 | |
| *** tcal has joined #litex | 16:01 | |
| *** Skip has joined #litex | 16:31 | |
| *** kgugala has joined #litex | 16:46 | |
| *** kgugala_ has quit IRC | 16:50 | |
| *** HoloIRCUser1 has joined #litex | 16:56 | |
| *** HoloIRCUser has quit IRC | 17:00 | |
| *** tcal has quit IRC | 17:12 | |
| *** tcal has joined #litex | 17:23 | |
| *** kgugala_ has joined #litex | 17:54 | |
| *** kgugala has quit IRC | 17:58 | |
| *** acathla has quit IRC | 18:23 | |
| *** acathla has joined #litex | 18:25 | |
| *** acathla has quit IRC | 18:25 | |
| *** acathla has joined #litex | 18:25 | |
| zyp | follow up on the unaligned accesses: I flipped some pcie options in the bios settings and unaligned reads now returns 0xffffffff and otherwise lets the host keep working | 19:19 |
| zyp | I'm not very familiar with this stuff, but I guess what I did was turn on completion timeouts that was off by default | 19:20 |
| *** kgugala has joined #litex | 20:34 | |
| *** HoloIRCUser has joined #litex | 20:35 | |
| *** kgugala_ has quit IRC | 20:37 | |
| *** HoloIRCUser1 has quit IRC | 20:38 | |
| *** tpearson-mobile has joined #litex | 20:49 | |
| tpearson-mobile | I'm working on a new module deriving from Module and AutoCSR. Fields that I define as CSRStorage show up in csr.h (i.e. appear in the SoC memory map) but all CSRConstants are removed | 20:50 |
| tpearson-mobile | Is there some trick beyond defining the constant in __init__ (e.g. self.magic_value = CSRConstant(0x123456)? | 20:50 |
| *** CarlFK has joined #litex | 21:15 | |
| tpearson-mobile | I'm working on a new module deriving from Module and AutoCSR. Fields that I define as CSRStorage show up in csr.h (i.e. appear in the SoC memory map) but all CSRConstants are removed | 21:40 |
| tpearson-mobile | Is there some trick beyond defining the constant in __init__ (e.g. self.magic_value = CSRConstant(0x123456)? | 21:40 |
| tpearson-mobile | also there seems to be a lot of issues with the Verilog external module support -- in particular relating to output signals into a CSRStatus. | 21:43 |
| tpearson-mobile | are there known issues with Verilog integration / CSRStatus? | 21:43 |
| awordnot | tpearson-mobile: how are you assigning the verilog code's output to CSRStatus? With a csr.status.eq(verilog_signal) assignment in the comb domain? | 21:49 |
| somlo | I give up... Fuck if I know WTF is going on anymore... https://pastebin.com/S5GPWkUz | 21:51 |
| tpb | Title: Here's the code with added printf statements: DSTATUS disk_initialize(uint8_t - Pastebin.com (at pastebin.com) | 21:51 |
| tpearson-mobile | awordnot: It's nothing fancy: https://paste.ee/p/i6Dni | 21:53 |
| tpb | Title: Paste.ee - View paste i6Dni (at paste.ee) | 21:53 |
| somlo | _florent_: I made `spisdcardstatus` volatile, so it "should" not "optimize" the return value based on the global default initial value... | 21:54 |
| tpearson-mobile | basically as I continue to add more o_<whatever> signals that reference that CSRStatus, at some point I get random failures, e.g. multiply assigned signals (there are none), wrong bit widths (somewhere in LiteX something changes the module's defined bit width to a wrong value, then complains when it has to change it back) etc. | 21:54 |
| somlo | but I'm ready to go find a brick wall and start hitting my head against it, at this point that sounds like more fun than this :) | 21:54 |
| tpearson-mobile | I'm about ready to just create a Verilog shim module that exposes nice, neat 32 bit registers with the desired contents to the AutoCSR system | 21:55 |
| awordnot | tpearson-mobile: Try creating an intermediate local Signal() with the correct width and connect that to the instance. Then add a `self.comb += mycsr.status.eq(intermediate)` | 21:56 |
| tpearson-mobile | how about CSRConstant not working? | 21:56 |
| awordnot | not sure about that one. The CSRConstant shown in that code you pasted doesn't show up in the outputted csr.h? | 21:57 |
| tpearson-mobile | right | 21:57 |
| tpearson-mobile | and it's just gone in the register map -- no space reserved for it at all | 21:57 |
| awordnot | odd. I haven't used CSRConstant personally but looking at some code that does, I don't see anything wrong with your example... | 22:00 |
| tpearson-mobile | Yeah, it's odd...I don't have any desire to fight with magic Python code so I'm going to go down the shim route, but still...this kind of confirmed my fears in relation to migen :) | 22:01 |
| tpearson-mobile | if something breaks it's not easy to figure out what is going wrong much less fix it | 22:01 |
| awordnot | as more of a software person than a hardware one I've found migen to be quite enjoyable, but my hardware friends certainly don't seem to agree :) | 22:03 |
| tpearson-mobile | ...guess which side I come from? :D | 22:04 |
| awordnot | heh | 22:04 |
| tpearson-mobile | I've never enjoyed masses of interlinked Python, they've always caused trouble that's taken time to fix -- on average, it's similarly opaque to when Windows has problems, with similar wastage of time, but that's just where I sit | 22:04 |
| tpearson-mobile | I will say the migen documentation is quite bad unless I'm just missing something -- lots of searching has yet to turn up anything that looks like class definitions, and many of the class names (Signal? Module?) are so generic any online searches are useless | 22:06 |
| awordnot | have you seen this? https://m-labs.hk/migen/manual/reference.html#module-migen.fhdl.structure | 22:06 |
| tpearson-mobile | s/class definition/class documentation/ | 22:06 |
| tpb | Title: API reference Migen 0.8.dev0 documentation (at m-labs.hk) | 22:06 |
| tpearson-mobile | oh, it's finally loading. Yesterday and the day before it was down | 22:06 |
| tpearson-mobile | yes, that looks better | 22:07 |
| awordnot | also the source is quite well commented, so a quick grep for 'class Signal' or some such should return a lot of valuable information | 22:07 |
| tpearson-mobile | grep where though? | 22:07 |
| tpearson-mobile | it's a ton of different repos and python modules | 22:07 |
| awordnot | i used the litex_setup.py script to clone all the litex repositories at once | 22:07 |
| tpearson-mobile | yes, I have all of them in one spot, but that's a lot of repos to have to grep through | 22:08 |
| tpearson-mobile | what I was looking for was more like this: https://doc.qt.io/qt-5/qwindow.html | 22:08 |
| tpb | Title: QWindow Class | Qt GUI 5.15.0 (at doc.qt.io) | 22:08 |
| somlo | tpearson-mobile: `grep -r` is your friend :) | 22:08 |
| tpearson-mobile | and I think now that m-labs.hk is up it might provide that? | 22:09 |
| tpearson-mobile | somlo: yes, I know about it, I also know it takes time even on SSD to run :D | 22:09 |
| awordnot | I've found ripgrep to perform extremely well for cases like this | 22:09 |
| awordnot | works great on ppc64le too :) | 22:10 |
| tpearson-mobile | sure, though I think my point of not having to grep sources for API documentation is a bit orthogonal to the exact tooling used to grep ;) | 22:10 |
| tpearson-mobile | I spent somewhere near an hour just trying to figure out how to assign a clock to an external Verilog module, and I'm still not sure it's right | 22:10 |
| awordnot | yeah that's fair. I will say that documentation has definitely been one of the biggest weaknesses i've encountered with migen/litex so far | 22:11 |
| somlo | re. "interlinked python modules" -- I generally find object-oriented code (c++ and java too) to be newcomer (to the project, not to the language) unfriendly | 22:11 |
| awordnot | in case you haven't seen it, this page is also quite helpful: https://github.com/timvideos/litex-buildenv/wiki/LiteX-for-Hardware-Engineers#instances | 22:11 |
| tpb | Title: LiteX for Hardware Engineers · timvideos/litex-buildenv Wiki · GitHub (at github.com) | 22:11 |
| somlo | can't just follow the thread of control to figure out what it does -- everything hapens magically "somewhere else" then where you're looking :) | 22:11 |
| tpearson-mobile | us hardware folks know we need to assign a certain signal to a certain line on a module or it'll fail in really nasty / hard to debug ways, and so far that has proven very difficult with so many key signals (clocks, resets) autogenerated deep in the bowels of litex/migen with no documentation on how to use or even access them | 22:11 |
| tpearson-mobile | yes | 22:11 |
| somlo | and I'm more of a software guy myself (learned verilog relatively late in my life, but would prefer it over the meta-language generator stuff any day) | 22:12 |
| awordnot | for future reference, ClockSignal(domain_name) and ResetSignal(domain_name) can be used to access the underlying Signal() object for those | 22:12 |
| tpearson-mobile | somlo: If I was to be very snarky, I'd suggest Intel is using something that behaves in that manner to generate their chips they can't seem to scrub the vulnerabilities and bugs out of ;) | 22:12 |
| somlo | and migen is not even that bad, you should see Chisel ::D | 22:12 |
| tpearson-mobile | awordnot: I managed to figure that out except the domain name | 22:13 |
| awordnot | if you omit the domain name, it'll default to `sys` | 22:13 |
| tpearson-mobile | ...that said, what's the domain for the Wishbone POR signal? | 22:13 |
| tpearson-mobile | (again, docs are lacking at best) | 22:14 |
| awordnot | by default, I think all peripherals will be on the sys domain | 22:14 |
| awordnot | s/all peripherals/everything/g | 22:15 |
| awordnot | unless you see explicit mention of other domains (a ClockDomainsRenamer(), or self.sync.<name> assignments), you can assume sys | 22:15 |
| * tpearson-mobile doesn't mean to be adversarial, it's just ... the system seems to have a lot of promise, yet at the end of the day it's hardware folks that are designing the peripherals talking to the outside world, and those do not take kindly whatsoever to any sort of undefined behavior, no matter how well intentioned. Python is great at creating | 22:15 | |
| * tpearson-mobile undefined behavior especially in the form of random uncaught exceptions ;) | 22:15 | |
| tpearson-mobile | OK | 22:16 |
| tpearson-mobile | how does the Renamer work? | 22:16 |
| tpearson-mobile | I saw an example that to be frank was abstract nonsense to me | 22:16 |
| tpearson-mobile | e.g. if I have a core that needs sysclock, some other PLL output, and a phase shifted version, how does it work? | 22:16 |
| awordnot | if you have a module that needs to operate on multiple domains, I believe the way you'd handle it is by creating all the domains you need in the top level SoC's _CRG | 22:17 |
| awordnot | then in the module itself, access the domains with self.sync.<domain_name> | 22:18 |
| awordnot | the ClockDomainsRenamer comes in when you have a module that wasn't explicitly designed to run on a different domain (i.e. all of it's logic is done on sys), and you want to instantiate it with a different sys than the parent | 22:18 |
| awordnot | at least, that's my current understanding | 22:19 |
| tpearson-mobile | ...sigh, the m-labs site doesn't even mention this magic ".sync" class | 22:19 |
| tpearson-mobile | https://m-labs.hk/migen/manual/search.html?q=sync&check_keywords=yes&area=default | 22:19 |
| tpb | Title: Search Migen 0.8.dev0 documentation (at m-labs.hk) | 22:19 |
| tpearson-mobile | is that even documented anywhere? | 22:19 |
| awordnot | https://m-labs.hk/migen/manual/fhdl.html#synchronous-statements | 22:20 |
| tpb | Title: The FHDL domain-specific language Migen 0.8.dev0 documentation (at m-labs.hk) | 22:20 |
| tpearson-mobile | OK thanks | 22:21 |
| awordnot | np | 22:22 |
| tpearson-mobile | I think I'm going to very much side with the other hardware engineers you have spoken with -- this is not a language I want to be designing anything of any complexity in :) | 22:22 |
| tpearson-mobile | that said, since Verilog can be glued in, I'll just limit my exposure to this part of it ;) | 22:23 |
| tpearson-mobile | It really seems to be mainly useful (i.e. not fighting the language) for pure behavioral descriptions of logic that isn't timing critical; i.e. single clock domain, no external interfaces beyond built-in busses like Wishbone | 22:24 |
| awordnot | yeah I definitely get where you're all coming from. thankfully the verilog interoperability seems to be quite usable so you still have a choice | 22:24 |
| awordnot | i'm not sure about that, there are some pretty complex designs written in migen (litepcie comes to mind) | 22:25 |
| tpearson-mobile | I guess more of a C++ to verilog tooling replacement than a direct VHDL/Verilog replacement | 22:25 |
| awordnot | but it is definitely targeted towards a very specific group of developers | 22:25 |
| tpearson-mobile | awordnot: that may be true, but I have my suspicions that time to market and overall maintainability would be better with pure Verilog/VHDL there | 22:25 |
| tpearson-mobile | e.g. you could write a Linux kernel in Python, but would it be the right language? | 22:26 |
| awordnot | well that would really just be down to the background skillset of the specific team in question | 22:26 |
| tpearson-mobile | eh, I'm not sure on that....it's fairly well known that software is either "pythonic" or not | 22:26 |
| tpearson-mobile | and for non-pythonic concepts, you're fighting the language more than anything else | 22:27 |
| awordnot | but the reward is that you get access to rich compile-time metaprogramming, compared to crappy generate for loops in verilog/vhdl | 22:27 |
| awordnot | for a lot of designs that probably doesn't matter though | 22:28 |
| tpearson-mobile | well, if you're using for loops in systems that need the lower level Verilog access, you have no idea what you're doing anyway :D | 22:28 |
| awordnot | i was thinking more along the lines of writing generic modules (i.e. variable bus/data widths) | 22:28 |
| awordnot | like some of xilinx's autogenerated AXI4 code tries to be generic verilog, but it ends up being quite ugly | 22:29 |
| tpearson-mobile | still, you wouldn't use for loops for that | 22:29 |
| awordnot | i've worked on some verilog code that made heavy use of verilog's `generate for` | 22:30 |
| tpearson-mobile | anyway, it's sort of academic since Verilog can be tied in to LiteX/migen. I guess much like you can write a native C module for Python | 22:30 |
| awordnot | yeah | 22:31 |
| tpearson-mobile | I can definitely see areas where it's going to be faster / easier to write migen and just let the HDL automagically come out of all the tooling, much like a compiler | 22:31 |
| tpearson-mobile | but there are also areas where if you do that you're going to take a nasty performance hit (either area or speed, or both) | 22:32 |
| awordnot | it should be possible to create an identical representation of any verilog logic in migen, though like you said it might certainly get cumbersome | 22:33 |
| tpearson-mobile | e.g. the migen system is sufficiently disconnected from the hardware concepts (blocks wired together) that it lacks the equivalent of "inline asm" if you need to take control of some low level bit (much like Python on a standard system, I guess) | 22:33 |
| awordnot | also sometimes you'll have to instantiate weird vendor primitives and such which can only work from verilog | 22:33 |
| tpearson-mobile | yeah, it's the cumbersome part that can send maintainability and expandability into the sewer :) | 22:33 |
| tpearson-mobile | well, I think I have what I need to go back and try this at least, thanks for the pointers! | 22:34 |
| awordnot | no worries | 22:34 |
| *** tpearson-mobile has quit IRC | 22:35 | |
| *** Skip has quit IRC | 22:53 | |
| *** HoloIRCUser2 has joined #litex | 22:53 | |
| *** HoloIRCUser has quit IRC | 22:57 | |
| mithro | awordnot: Yeah - I think we should probably move that page from the litex-buildenv wiki to the litex wiki now that exists | 23:34 |
| awordnot | mithro: the LiteX For Hardware Engineers page? yeah it'd be great to have it all in the litex wiki | 23:35 |
| *** tpearson-mobile has joined #litex | 23:44 | |
| tpearson-mobile | I'm back....with a new set of issues :) | 23:44 |
| awordnot | welcome :) | 23:45 |
| tpearson-mobile | I have a simple Verilog file that just provides a fixed value (0x01234567) to a 32-bit output | 23:45 |
| tpearson-mobile | I am using the same Module/AutoCSR tie-in as before | 23:45 |
| tpearson-mobile | (o_magic_number = self.magic_number.status) | 23:46 |
| tpearson-mobile | while it synthesizes etc. just fine, using "mr" on the target console is only ever giving me one byte | 23:46 |
| tpearson-mobile | it's as if the other three bytes are masked off to 0x00 | 23:46 |
| tpearson-mobile | if I add several similar CSRStatus mappings, I see basically 0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00 ... | 23:47 |
| tpearson-mobile | i.e. the last three bytes are always masked off | 23:47 |
| tpearson-mobile | err, sorry, typo | 23:48 |
| tpearson-mobile | it's actually worse than that | 23:48 |
| tpearson-mobile | I see 0x01 0x00 0x00 0x00 0x023 0x00 0x00 0x00 0x45 0x00 0x00 0x00 ... | 23:48 |
| tpearson-mobile | so it's not just masked off, it's actually inserting a bunch of unwanted bits | 23:48 |
| tpearson-mobile | when you run mr <addr> 1 it looks masked, you need to dump more words to see what it's actually doing | 23:49 |
| tpearson-mobile | ideas? | 23:49 |
| awordnot | looks like what's described here: https://github.com/timvideos/litex-buildenv/wiki/LiteX-for-Hardware-Engineers#csrs-config-and-status-registers | 23:49 |
| tpb | Title: LiteX for Hardware Engineers · timvideos/litex-buildenv Wiki · GitHub (at github.com) | 23:49 |
| awordnot | "CSRs are a bit odd, by default they are byte-wide registers that are on 32-bit word boundaries. So a "32-bit" CSR is actually broken into four bytes spanning a total address space of 16 bytes. You can zpecify 32-bit wide CSRs but you’ll probably run into compatibility issues with other IP librariers that have hard-coded the 8-bit assumption. " | 23:49 |
| tpearson-mobile | oh | 23:50 |
| tpearson-mobile | ouch | 23:50 |
| awordnot | yeah hmm that's an interesting design decision | 23:50 |
| tpearson-mobile | maybe I should back up then and ask: what is the correct way to expose a set of 32 bit registers to the host? | 23:50 |
| tpearson-mobile | this is SoC design 101, there should be an existing template for it | 23:50 |
| awordnot | I think the de facto way is to just use CSRs. I guess people just live with the address space bloat? | 23:53 |
| awordnot | that seems a little strange though | 23:53 |
| awordnot | ok, it looks like if you use the base CSR() class intead of CSRStorage() you can specify 32-bit width instead of 8-bit width | 23:55 |
| awordnot | https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/csr.py#L72 | 23:56 |
| tpb | Title: litex/csr.py at master · enjoy-digital/litex · GitHub (at github.com) | 23:56 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!