<tpb>
Title: litex_soc_ctrl: use published api for cpu-native access with barriers · litex-hub/linux@3856b9e · GitHub (at github.com)
<benh>
somlo: this comforts me in saying we should use a fixed endianness (preferably LE) for Linux SoCs :-)
<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
<benh>
for example microwatt will probably end up with completely separate CSR busses for liteeth and litesdram
Skip has quit [Remote host closed the connection]
<benh>
somlo: also liteeth has a bug .. the PHY CRG reset ... it's poking at the ethernet mmio instead of the CSRs :)
<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
<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
<benh>
along with _florent_ work to fix CSR addresses, we completely remove the need for that common CSR layre
<benh>
and it removes problems with multiple CSR busses when using standalone cores etc...
<benh>
I think it's a much better approach this way...
<benh>
is there a better place to discuss this ?
<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
<benh>
obtained from the device-tree
<futarisIRCcloud>
Discussion is probably best here, or on the linux-litex mailing list ...
<futarisIRCcloud>
awordnot: Xilinx series 7 does work in Synopsys as of a few weeks ago.
<awordnot>
futarisIRCcloud: I'm not familiar with Synopsys. Is it related to the series 7 bitstream reverse engineering efforts?
<benh>
how do you use those google groups like a normal mailing list ?
<benh>
I can't find a subscribe button :)
<benh>
ah found "join group"
<benh>
hrm... it wants to send the mails to my gmail..no good
<mithro>
benh: You can provide any email address...
<benh>
mithro: how ? the web UI doesn't seem to let me
<mithro>
Google groups seems to always get worst :/
<benh>
yeah
<benh>
it's a horrible web forum thing
<benh>
why not create a proper mailing list ? :)
<benh>
that stuff is unusable for me
<mithro>
benh: What email address do you want used?
<mithro>
Emailing linux-litex+subscribe@googlegroups.com apparently? I can add you manually too
<benh>
mithro: benh@kernel.crashing.org
<benh>
thanks !
<benh>
ah there's a subscribe .. ok it wasn't documented in the web UI anywhere I could find
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #litex
guan has quit [Ping timeout: 240 seconds]
mithro has quit [Read error: Connection reset by peer]
bubble_buster has quit [Ping timeout: 260 seconds]
levi has quit [Ping timeout: 260 seconds]
rohitksingh has quit [Ping timeout: 240 seconds]
mithro has joined #litex
bubble_buster has joined #litex
levi has joined #litex
guan has joined #litex
rohitksingh has joined #litex
<benh>
mithro: just to see waht can of bloat it causes
<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>
<benh>
and have some wrappers to pipe that into regmap
<benh>
as long as we do that in a way that allow different devices to point to different CSR bridges
<benh>
but if you're going to do things like USB devices, PCIe devices, you really need fixed CSR offsets/layout
<benh>
unless you want every device to carry some kind of description ROM .. I don't think it's worth the pain
mithro has quit [Read error: Connection reset by peer]
rohitksingh has quit [Ping timeout: 272 seconds]
guan has quit [Ping timeout: 256 seconds]
bubble_buster has quit [Ping timeout: 256 seconds]
rohitksingh has joined #litex
levi has quit [Read error: Connection reset by peer]
guan has joined #litex
rohitksingh has quit [Ping timeout: 272 seconds]
guan has quit [Read error: Connection reset by peer]
guan has joined #litex
rohitksingh has joined #litex
levi has joined #litex
bubble_buster has joined #litex
mithro has joined #litex
st-gourichon-fid has joined #litex
<mithro>
_florent_: You should talk more about the documentation you have added to the LiteX wiki -- I didn't know 90% of it existed...
_whitelogger has joined #litex
dasdgw has quit [Ping timeout: 272 seconds]
HoloIRCUser has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
<benh>
I notice LiteX PLL feeds CLKFBOUT directly into CLKFBIN .. isn't it supposed to have a BUFG in there?
<tpb>
Title: Home · enjoy-digital/litex Wiki · GitHub (at github.com)
HoloIRCUser2 has joined #litex
HoloIRCUser has quit [Ping timeout: 272 seconds]
<benh>
ah forget about this, we don't need deskewing
<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
<zyp>
I don't need/expect unaligned accesses to work, but I'd like them to be more gracefully handled
<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
HoloIRCUser has joined #litex
HoloIRCUser2 has quit [Read error: Connection reset by peer]
<benh>
somlo: ok cool, I signed up too
<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
<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
<benh>
somlo: or we go full flex so we can have things with CSRs behind USB or god-knows-what like mithro would like
<benh>
somlo: in which case we look into using regmap for them
<benh>
(which conveniently also supports native endian)
<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
<benh>
somlo: I need to crash now :) g'night
<zyp>
if you're reworking the CSR stuff, I'd like a way to predefine the CSR layout, including adding gaps
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #litex
CarlFK has joined #litex
CarlFK has quit [Ping timeout: 256 seconds]
tcal has quit [Ping timeout: 256 seconds]
tcal has joined #litex
Skip has joined #litex
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 264 seconds]
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 265 seconds]
tcal has quit [Ping timeout: 264 seconds]
tcal has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
acathla has quit [Read error: Connection reset by peer]
acathla has joined #litex
acathla has quit [Changing host]
acathla has joined #litex
<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
<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
kgugala has joined #litex
HoloIRCUser has joined #litex
kgugala_ has quit [Ping timeout: 256 seconds]
HoloIRCUser1 has quit [Ping timeout: 256 seconds]
tpearson-mobile has joined #litex
<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
<tpearson-mobile>
Is there some trick beyond defining the constant in __init__ (e.g. self.magic_value = CSRConstant(0x123456)?
CarlFK has joined #litex
<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
<tpearson-mobile>
Is there some trick beyond defining the constant in __init__ (e.g. self.magic_value = CSRConstant(0x123456)?
<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.
<tpearson-mobile>
are there known issues with Verilog integration / CSRStatus?
<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?
<somlo>
_florent_: I made `spisdcardstatus` volatile, so it "should" not "optimize" the return value based on the global default initial value...
<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.
<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 :)
<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
<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)`
<tpearson-mobile>
how about CSRConstant not working?
<awordnot>
not sure about that one. The CSRConstant shown in that code you pasted doesn't show up in the outputted csr.h?
<tpearson-mobile>
right
<tpearson-mobile>
and it's just gone in the register map -- no space reserved for it at all
<awordnot>
odd. I haven't used CSRConstant personally but looking at some code that does, I don't see anything wrong with your example...
<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 :)
<tpearson-mobile>
if something breaks it's not easy to figure out what is going wrong much less fix it
<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 :)
<tpearson-mobile>
...guess which side I come from? :D
<awordnot>
heh
<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
<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
<tpb>
Title: QWindow Class | Qt GUI 5.15.0 (at doc.qt.io)
<somlo>
tpearson-mobile: `grep -r` is your friend :)
<tpearson-mobile>
and I think now that m-labs.hk is up it might provide that?
<tpearson-mobile>
somlo: yes, I know about it, I also know it takes time even on SSD to run :D
<awordnot>
I've found ripgrep to perform extremely well for cases like this
<awordnot>
works great on ppc64le too :)
<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 ;)
<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
<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
<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
<tpb>
Title: LiteX for Hardware Engineers · timvideos/litex-buildenv Wiki · GitHub (at github.com)
<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 :)
<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
<tpearson-mobile>
yes
<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)
<awordnot>
for future reference, ClockSignal(domain_name) and ResetSignal(domain_name) can be used to access the underlying Signal() object for those
<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 ;)
<somlo>
and migen is not even that bad, you should see Chisel ::D
<tpearson-mobile>
awordnot: I managed to figure that out except the domain name
<awordnot>
if you omit the domain name, it'll default to `sys`
<tpearson-mobile>
...that said, what's the domain for the Wishbone POR signal?
<tpearson-mobile>
(again, docs are lacking at best)
<awordnot>
by default, I think all peripherals will be on the sys domain
<awordnot>
s/all peripherals/everything/g
<awordnot>
unless you see explicit mention of other domains (a ClockDomainsRenamer(), or self.sync.<name> assignments), you can assume sys
* 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
* tpearson-mobile
undefined behavior especially in the form of random uncaught exceptions ;)
<tpearson-mobile>
OK
<tpearson-mobile>
how does the Renamer work?
<tpearson-mobile>
I saw an example that to be frank was abstract nonsense to me
<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?
<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
<awordnot>
then in the module itself, access the domains with self.sync.<domain_name>
<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
<awordnot>
at least, that's my current understanding
<tpearson-mobile>
...sigh, the m-labs site doesn't even mention this magic ".sync" class
<tpb>
Title: The FHDL domain-specific language Migen 0.8.dev0 documentation (at m-labs.hk)
<tpearson-mobile>
OK thanks
<awordnot>
np
<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 :)
<tpearson-mobile>
that said, since Verilog can be glued in, I'll just limit my exposure to this part of it ;)
<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
<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
<awordnot>
i'm not sure about that, there are some pretty complex designs written in migen (litepcie comes to mind)
<tpearson-mobile>
I guess more of a C++ to verilog tooling replacement than a direct VHDL/Verilog replacement
<awordnot>
but it is definitely targeted towards a very specific group of developers
<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
<tpearson-mobile>
e.g. you could write a Linux kernel in Python, but would it be the right language?
<awordnot>
well that would really just be down to the background skillset of the specific team in question
<tpearson-mobile>
eh, I'm not sure on that....it's fairly well known that software is either "pythonic" or not
<tpearson-mobile>
and for non-pythonic concepts, you're fighting the language more than anything else
<awordnot>
but the reward is that you get access to rich compile-time metaprogramming, compared to crappy generate for loops in verilog/vhdl
<awordnot>
for a lot of designs that probably doesn't matter though
<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
<awordnot>
i was thinking more along the lines of writing generic modules (i.e. variable bus/data widths)
<awordnot>
like some of xilinx's autogenerated AXI4 code tries to be generic verilog, but it ends up being quite ugly
<tpearson-mobile>
still, you wouldn't use for loops for that
<awordnot>
i've worked on some verilog code that made heavy use of verilog's `generate for`
<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
<awordnot>
yeah
<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
<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)
<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
<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)
<awordnot>
also sometimes you'll have to instantiate weird vendor primitives and such which can only work from verilog
<tpearson-mobile>
yeah, it's the cumbersome part that can send maintainability and expandability into the sewer :)
<tpearson-mobile>
well, I think I have what I need to go back and try this at least, thanks for the pointers!
<awordnot>
no worries
tpearson-mobile has quit [Remote host closed the connection]
Skip has quit [Remote host closed the connection]
HoloIRCUser2 has joined #litex
HoloIRCUser has quit [Ping timeout: 264 seconds]
<mithro>
awordnot: Yeah - I think we should probably move that page from the litex-buildenv wiki to the litex wiki now that exists
<awordnot>
mithro: the LiteX For Hardware Engineers page? yeah it'd be great to have it all in the litex wiki
tpearson-mobile has joined #litex
<tpearson-mobile>
I'm back....with a new set of issues :)
<awordnot>
welcome :)
<tpearson-mobile>
I have a simple Verilog file that just provides a fixed value (0x01234567) to a 32-bit output
<tpearson-mobile>
I am using the same Module/AutoCSR tie-in as before
<tpb>
Title: LiteX for Hardware Engineers · timvideos/litex-buildenv Wiki · GitHub (at github.com)
<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. "
<tpearson-mobile>
oh
<tpearson-mobile>
ouch
<awordnot>
yeah hmm that's an interesting design decision
<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?
<tpearson-mobile>
this is SoC design 101, there should be an existing template for it
<awordnot>
I think the de facto way is to just use CSRs. I guess people just live with the address space bloat?
<awordnot>
that seems a little strange though
<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