<xobs>
florent: Do you have any recommendations on how I can avoid double-naming? Should I have DCSR inherit from CSRStatus and CSRStorage? Or is there some way I can inhibit the name of the instantiated CSR?
<_florent_>
xobs: i wanted to play a bit with your code to figure that out, i'm just finishing something and will look at that
<_florent_>
xobs: the way you did it, it's difficult to improve the naming. You have a common Reg Module, but then switch inside it if it's readable/writable
<xobs>
_florent_: I was mimicking how CSR does it. Is there a way you'd suggest doing it instead?
<_florent_>
xobs: i think you should have some helpers functions outside of Reg to do the common processing on the fields
<_florent_>
then maybe just have RegStorage be RegStorage(CSRStorage)
<_florent_>
and do the processing of the field before the CSRStorage.__init__(self, ...)
<_florent_>
and the reset logic insertion after
<xobs>
Okay, I'll change my approach and do that then. Thanks for the advice!
<_florent_>
and the same for RegStatus
<_florent_>
this is just what i think, but this way, the naming will be similar to using regular CSRStatus/CSRStorage
<xobs>
Well, one thing I want to avoid is namespace collisions. For example, what if you want a field called "status"? Or "re"? That's one of the reasons behind the requirement that fields not begin with "_".
<xobs>
I see you're right, florent, it really doesn't want to work that way. That's unfortunate.
<xobs>
For example, the global `csrprefix` def appears to assume that all CSRs have a `.name` property, which means I can't do a `DCSR` with a `name` Field on it. Not unless I add it to a sub-property.
vup has joined #litex
<somlo>
mithro: I'll take a look (as soon as finish waking up :)
guan has joined #litex
freemint has quit [Ping timeout: 264 seconds]
freemint has joined #litex
freemint has quit [Ping timeout: 250 seconds]
davidc__ has joined #litex
freemint has joined #litex
john_k[m] has joined #litex
freeemint has joined #litex
freemint has quit [Ping timeout: 264 seconds]
<_florent_>
John_K: i don't have the right license right now so can't test the implementation, but i adapted your code to be closer to what is used on Numato Opsis:
<tpb>
Title: GitHub - ikwzm/udmabuf: User space mappable dma buffer device driver for Linux. (at github.com)
<john_k[m]>
thanks _florent_ I'll look into it. For the toolchain, you need the "Windows 10" version of ISE 14.7 (Xilinx are really bad at versioning)
<john_k[m]>
I'mI'm going to write up instructions for how to get the "Windows 10" version to work under Linux (at mithro's prodding) - it adds support for S6 LX100/LX150 devices and comes with a permanent license
<mithro>
john_k[m]: that would be awesome!
<john_k[m]>
:) it takes a lot of tools, going to see if I can optimize it a bit and and a shell script to transform it into something usable
<tpb>
Title: Soft CPU · enjoy-digital/litex Wiki · GitHub (at github.com)
<john_k[m]>
that reads well somlo, was surpised that the FPU isn't enabled in the Linux config
<_florent_>
john_k[m]: l55, you have p = 8, it should work with p=16
<_florent_>
mithro: i'll look at udmabuf and compare to what we are doing in litepcie
<john_k[m]>
_florent_: aha, trying that now (was attempting to change CPU back to 100MHz to see if that would fix it)
<john_k[m]>
at some point, would like to pick your brain about the different styles of instantiating PLLs
<_florent_>
john_k[m]: i would say the style you started implemented things is now recommended (using S6PLL)
<_florent_>
but the thing is that getting DRAM working is already complicated on Spartan6, so that's better just using the code that is known to work on the Opsis for now
<john_k[m]>
it does seem a bit neater, will have to play around with it a bit after we get this working
<john_k[m]>
makes sense
<_florent_>
once working, it will be easier to try the S6PLL with DDR3
<john_k[m]>
DDR3?
<john_k[m]>
(I presume you mean on a different board?)
<_florent_>
isn't the panologic using a ddr3 memory?