*** tpb has joined #litex | 00:00 | |
*** CarlFK has quit IRC | 00:04 | |
John_K | running into a bit of trouble trying to use litedram with DDR2 on Spartan6, are there any good examples to follow? I can't seem to find any. (caveat: I haven't done DDR memory things before) | 00:43 |
---|---|---|
John_K | things seem to be stalling out during Phase 3 of Routing | 00:57 |
John_K | non-DDR2 builds of the same SoC take ~10min for everything, this has been stalled out for 20min at Routing Phase 3 | 00:58 |
*** CarlFK has joined #litex | 01:07 | |
*** freemint has quit IRC | 01:27 | |
*** freemint has joined #litex | 01:28 | |
*** freemint has quit IRC | 01:34 | |
*** freemint has joined #litex | 01:34 | |
*** freemint has quit IRC | 01:39 | |
*** rohitksingh has joined #litex | 02:18 | |
John_K | changed the clock generation by adapting PPL config from DDR3 on S6, but I must not be doing it right as I'm getting Unroutable messages | 02:30 |
John_K | "Unroutable signal: GLOBAL_LOGIC0 pin: OSERDES2_1/IOCE" for OSERDES2_1 through OSERDES2_10 | 02:30 |
John_K | https://github.com/John-K/litex-boards/blob/PanoLogicG2_DDR2/litex_boards/community/targets/panologicg2.py#L74 is where I'm at right now, '__init0__' was my previous attempt | 02:43 |
tpb | Title: litex-boards/panologicg2.py at PanoLogicG2_DDR2 · John-K/litex-boards · GitHub (at github.com) | 02:43 |
*** CarlFK has quit IRC | 03:16 | |
mithro | We should add rocket at https://github.com/enjoy-digital/litex/wiki/Soft-CPU | 04:03 |
tpb | Title: Soft CPU · enjoy-digital/litex Wiki · GitHub (at github.com) | 04:03 |
mithro | somlo: Any chance you could do that? | 04:03 |
John_K | mithro: inching closer to linux-on-litex-vexriscv for PanoLogicG2 - DDR is giving me issues right now, but have the core running at 100MHz with UART - going to work on Ethernet tomorrow | 04:39 |
_florent_ | John_K: i'll try to implement your design to see if i understand what is going wrong | 05:07 |
John_K | thanks _florent_, the litedram and litex-board changes are on my github linked above | 05:07 |
*** rohitksingh has quit IRC | 05:38 | |
xobs | Hi all, I'm trying to solve the issue of how to document register sets. I've come up with this, which I'd like to start using. Does anyone have any feedback? https://gist.github.com/xobs/9bda0fb09b2cb3e5316592b96d4d4087 | 06:05 |
tpb | Title: dreg sample · GitHub (at gist.github.com) | 06:05 |
xobs | The idea is that each bit of the CSR is now documented, and it will create signals that can be easily manipulated (e.g. `self.status.pend` is the correct thing). | 06:06 |
xobs | This should be enough to make full register sets, including wavedrom `reg` graphs. | 06:08 |
*** CarlFK has joined #litex | 06:21 | |
_florent_ | xobs: that's a good idea to add something on top of CSR to help describing registers, have you already implemented RegStorage/RegStatus? i'd like to have a look if so | 06:43 |
xobs | _florent_: I'm mostly done implementing it, I'm just trying to figure out how to fix the CSR naming. I'm getting registers named things like `usb_address_address`. | 06:46 |
xobs | Let me put together something really quick. One moment. | 06:47 |
xobs | _florent_: https://github.com/xobs/dreg/blob/master/dreg.py | 06:49 |
tpb | Title: dreg/dreg.py at master · xobs/dreg · GitHub (at github.com) | 06:49 |
_florent_ | regarding the naming, for more consistency, maybe you could call things: DReg/DRegStorage/DRegStatus/DRegField | 06:55 |
_florent_ | (naming of the classes, not naming of the generated registers) | 06:56 |
_florent_ | this could also be DCSR/DCSRStorage/DCSRStatus/DCSRField : Documented Control Status Register | 06:59 |
_florent_ | since it would also be useful for others purposes, would you ok to have it integrated directly in LiteX? | 07:01 |
xobs | Sure, I can do that. Naming things in computer science is hard. I'll change the class names to match that. | 07:01 |
xobs | Sure! That was one of the goals. Then have the build process generate a reference manual as part of the output. | 07:01 |
_florent_ | would you/would you be | 07:01 |
_florent_ | ok good | 07:02 |
_florent_ | that's indeed something that is missing both for designing and documenting, so i really like the idea | 07:03 |
xobs | I've been putting documentation at the top: https://github.com/xobs/valentyusb/blob/tri-fifo/valentyusb/usbcore/cpu/eptri.py#L64 | 07:06 |
tpb | Title: valentyusb/eptri.py at tri-fifo · xobs/valentyusb · GitHub (at github.com) | 07:06 |
xobs | But I realized why that feels so clunky. | 07:07 |
xobs | It's because that kind of documentation is for Python users, not for end-SoC users. | 07:07 |
xobs | So it'd be good to put how to use the python class there (e.g. what `iobuf` and `debug` mean), but it's not the place to put register-level documentation. | 07:07 |
xobs | Hence the push to defined DReg. | 07:07 |
xobs | *DCSR | 07:08 |
_florent_ | indeed, even for using the register internally it would be easier, instead of doing self.status.[4].eq(X) you just do self.status.data.eq(X) | 07:10 |
mithro | Why DReg? | 07:12 |
xobs | mithro: It's a Documented Register. | 07:13 |
xobs | And I wanted to avoid any namespace collisions in case florent wanted to do his own approach. | 07:13 |
mithro | xobs: I would say that the documentation is more of a side-effect of the way you are structuring the code? | 07:14 |
_florent_ | i'm fine doing a common thing | 07:14 |
mithro | xobs: Does feel very argparse like.... | 07:14 |
xobs | mithro: How do you mean? | 07:14 |
mithro | xobs: https://docs.python.org/3/library/argparse.html | 07:15 |
tpb | Title: argparse — Parser for command-line options, arguments and sub-commands Python 3.7.4 documentation (at docs.python.org) | 07:15 |
xobs | mithro: How do you mean it's a side-effect? | 07:15 |
_florent_ | We could also call it ECSR: Enhanced CSR, Control and Status Registers with field and documentation support | 07:16 |
mithro | xobs: Well, even if you left the description field off all that example above, I feel like this structure kind of still has some advantages | 07:16 |
mithro | _florent_: This kind of feels like Records a bit too? | 07:17 |
_florent_ | yes but records don't have descriptions | 07:17 |
mithro | https://github.com/enjoy-digital/litex/blob/8634401b33ff1101987b1dfda8a781716835a7ec/litex/tools/remote/etherbone.py#L14-L24 | 07:17 |
tpb | Title: litex/etherbone.py at 8634401b33ff1101987b1dfda8a781716835a7ec · enjoy-digital/litex · GitHub (at github.com) | 07:17 |
mithro | _florent_: Maybe they should? :-P | 07:17 |
mithro | _florent_: The fact that every field in that record has a comment after it, kind of makes my argument :-P | 07:18 |
xobs | mithro: I still don't know what a Record is, and the documentation of it isn't very helpful... https://github.com/m-labs/migen/blob/master/migen/genlib/record.py | 07:19 |
tpb | Title: migen/record.py at master · m-labs/migen · GitHub (at github.com) | 07:19 |
mithro | I think it is basically a "`struct` for Signal objects"? | 07:20 |
mithro | For example, https://github.com/enjoy-digital/litex/blob/2638393b53a6ae77e4bfcbaed9d15ca434ce3c6f/litex/soc/integration/soc_zynq.py#L16-L24 could really use some description strings :-) | 07:21 |
tpb | Title: litex/soc_zynq.py at 2638393b53a6ae77e4bfcbaed9d15ca434ce3c6f · enjoy-digital/litex · GitHub (at github.com) | 07:21 |
_florent_ | i was also thinking about adding layout/record support to existing CSR when first saw xobs work, but this also complicate CSR code, so for now i dont' know what is best: building something on top of CSR (as xobs is doing), or improving actual CSR. | 07:21 |
mithro | xobs: Agreed that record.py should have more docs... | 07:22 |
mithro | _florent_: The fact that record takes a bare tuple rather than something like a Field object has always kind of bothered me... | 07:25 |
mithro | https://github.com/enjoy-digital/litex/blob/ccc2cbd9d4a82c8599bca1d9b6de901c0f24ef67/litex/soc/interconnect/axi.py#L22-L34 <- another example where every field in a record has a comment... | 07:25 |
tpb | Title: litex/axi.py at ccc2cbd9d4a82c8599bca1d9b6de901c0f24ef67 · enjoy-digital/litex · GitHub (at github.com) | 07:25 |
mithro | Would pretty simple create a `class RecordField(namedtuple):` which also supports setting a description? | 07:27 |
mithro | ps - I should be in bed asleep right now :-P | 07:28 |
xobs | mithro: Being able to document individual bits is nice, with the values[] parameter. | 07:28 |
xobs | Also, having "pulse" values and offsets is a nice feature I use to make various disparate CSRs have their fields line up. | 07:29 |
mithro | What does the "pulse" value mean? | 07:29 |
mithro | xobs: I would also recommend chatting with whitequark about this topic | 07:30 |
xobs | It means the Field value is only valid if the `.re` signal is also valid. | 07:31 |
xobs | (Which reminds me -- I should `Replicate()` the `.re` signal...) | 07:31 |
mithro | xobs: You should probably use a Python enum in those "values()" case? https://docs.python.org/3/library/enum.html | 07:32 |
tpb | Title: enum — Support for enumerations Python 3.7.4 documentation (at docs.python.org) | 07:32 |
xobs | mithro: what would that look like? | 07:33 |
mithro | xobs: whitequark had an example (in nmigen but should be pretty easily backported) | 07:35 |
xobs | xobs: the goal with that information is to be able to generate tables like this: | 07:37 |
* xobs uploaded an image: image.png (76KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/JlyYodqFpLsWQJKOlNCxSftJ > | 07:37 | |
mithro | xobs: Yeah - whitequark is doing a lot of stuff like that for boneless IIRC | 07:37 |
mithro | https://github.com/whitequark/Boneless-CPU/blob/master/boneless/gateware/decoder.py | 07:37 |
tpb | Title: Boneless-CPU/decoder.py at master · whitequark/Boneless-CPU · GitHub (at github.com) | 07:37 |
mithro | https://github.com/whitequark/Boneless-CPU/blob/master/boneless/arch/opcode.py | 07:37 |
tpb | Title: Boneless-CPU/opcode.py at master · whitequark/Boneless-CPU · GitHub (at github.com) | 07:37 |
xobs | mithro: How would the enum work? And how would it work for ranges? | 07:39 |
mithro | https://github.com/whitequark/Boneless-CPU/blob/master/doc/manual/manual.pdf | 07:40 |
tpb | Title: Boneless-CPU/manual.pdf at master · whitequark/Boneless-CPU · GitHub (at github.com) | 07:40 |
mithro | xobs: I don't quite remember how it all ties together... | 07:41 |
mithro | xobs: whitequark is in Hong Kong, so good timezone for you to chat with | 07:41 |
*** _whitelogger has joined #litex | 07:49 | |
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? | 07:50 |
_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 | 07:52 |
_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 | 08:54 |
xobs | _florent_: I was mimicking how CSR does it. Is there a way you'd suggest doing it instead? | 08:55 |
_florent_ | xobs: i think you should have some helpers functions outside of Reg to do the common processing on the fields | 08:55 |
_florent_ | then maybe just have RegStorage be RegStorage(CSRStorage) | 08:55 |
_florent_ | and do the processing of the field before the CSRStorage.__init__(self, ...) | 08:56 |
_florent_ | and the reset logic insertion after | 08:56 |
xobs | Okay, I'll change my approach and do that then. Thanks for the advice! | 08:56 |
_florent_ | and the same for RegStatus | 08:56 |
_florent_ | this is just what i think, but this way, the naming will be similar to using regular CSRStatus/CSRStorage | 08:57 |
_florent_ | and you will avoid having the: | 08:57 |
_florent_ | https://www.irccloud.com/pastebin/A1l1SLrf/ | 08:57 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 08:57 |
_florent_ | since it will be directly accessible | 08:58 |
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 "_". | 08:58 |
_florent_ | ok i see, maybe you could also do it with a specific __getattr__ (of otherwise prohibit the use of "status", "storage", "re", "we" in the fields as we are doing on streams: https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/stream.py#L33 | 09:03 |
tpb | Title: litex/stream.py at master · enjoy-digital/litex · GitHub (at github.com) | 09:03 |
*** freemint has joined #litex | 09:06 | |
xobs | I see you're right, florent, it really doesn't want to work that way. That's unfortunate. | 10:30 |
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. | 10:32 |
*** vup has joined #litex | 10:51 | |
somlo | mithro: I'll take a look (as soon as finish waking up :) | 11:02 |
*** guan has joined #litex | 11:19 | |
*** freemint has quit IRC | 12:35 | |
*** freemint has joined #litex | 13:37 | |
*** freemint has quit IRC | 15:54 | |
*** davidc__ has joined #litex | 15:55 | |
*** freemint has joined #litex | 15:57 | |
*** john_k[m] has joined #litex | 16:05 | |
*** freeemint has joined #litex | 17:04 | |
*** freemint has quit IRC | 17:06 | |
_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: | 17:29 |
_florent_ | https://hastebin.com/yitexeheto.m | 17:30 |
_florent_ | You can find the opsis here: https://github.com/timvideos/litex-buildenv/blob/master/targets/opsis/base.py | 17:30 |
tpb | Title: litex-buildenv/base.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 17:30 |
_florent_ | in a first time, i would recommend using the exact same frequency we are using on opsis: 50MHz | 17:31 |
_florent_ | you can find the ddram constraints of the opsis here: https://github.com/timvideos/litex-buildenv/blob/master/platforms/opsis.py#L184-L209 | 17:32 |
tpb | Title: litex-buildenv/opsis.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 17:32 |
mithro | _florent_: is https://github.com/ikwzm/udmabuf have any potential use with LiteX? | 17:46 |
tpb | Title: GitHub - ikwzm/udmabuf: User space mappable dma buffer device driver for Linux. (at github.com) | 17:46 |
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) | 17:46 |
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 | 17:47 |
mithro | john_k[m]: that would be awesome! | 17:48 |
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 | 17:49 |
john_k[m] | florent | 18:06 |
john_k[m] | * florent it's close, https://hastebin.com/raw/orayudutom | 18:06 |
CarlFK | john_k: have you seen https://github.com/timvideos/litex-buildenv/wiki/Bash-On-Windows | 18:19 |
tpb | Title: Bash On Windows · timvideos/litex-buildenv Wiki · GitHub (at github.com) | 18:19 |
john_k[m] | I haven't, but I prefer to use Linux for FPGA development. Plus the "Windows 10" version of ISE is a Linux VM that runs on Windows anyway | 18:20 |
somlo | _florent_, mithro: PTAL @ https://github.com/enjoy-digital/litex/wiki/Soft-CPU and let me know if the rocket stuff looks about right, or if you think I missed anything | 18:44 |
tpb | Title: Soft CPU · enjoy-digital/litex Wiki · GitHub (at github.com) | 18:44 |
john_k[m] | that reads well somlo, was surpised that the FPU isn't enabled in the Linux config | 19:09 |
_florent_ | john_k[m]: l55, you have p = 8, it should work with p=16 | 19:18 |
_florent_ | mithro: i'll look at udmabuf and compare to what we are doing in litepcie | 19:19 |
john_k[m] | _florent_: aha, trying that now (was attempting to change CPU back to 100MHz to see if that would fix it) | 19:20 |
john_k[m] | at some point, would like to pick your brain about the different styles of instantiating PLLs | 19:21 |
_florent_ | john_k[m]: i would say the style you started implemented things is now recommended (using S6PLL) | 19:24 |
_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 | 19:25 |
john_k[m] | it does seem a bit neater, will have to play around with it a bit after we get this working | 19:25 |
john_k[m] | makes sense | 19:25 |
_florent_ | once working, it will be easier to try the S6PLL with DDR3 | 19:25 |
john_k[m] | DDR3? | 19:26 |
john_k[m] | (I presume you mean on a different board?) | 19:26 |
_florent_ | isn't the panologic using a ddr3 memory? | 19:26 |
john_k[m] | DDR2 | 19:29 |
john_k[m] | MT47H32M16HR-25E:G https://www.micron.com/~/media/Documents/Products/Data%20Sheet/DRAM/DDR2/512MbDDR2.pdf | 19:29 |
somlo | john_k[m]: the FPU burns a lot of LUTs, and currently will not fit on an ecp5 45k FPGA (the versa-5g board from lattice) | 19:31 |
John_K | somlo: that makes sense | 19:32 |
_florent_ | ah, then it's probably better to use the Atlys as a reference instead of the Opsis: https://github.com/timvideos/litex-buildenv/blob/master/targets/atlys/base.py | 19:32 |
tpb | Title: litex-buildenv/base.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 19:32 |
somlo | so I decided that the 'linux' variant will have the MMU only, and do floating point via software traps in the BBL | 19:33 |
John_K | _florent_: ah, hrm | 19:33 |
_florent_ | John_K: you should be able to almost copy/paste the CRG | 19:33 |
_florent_ | you don't need the peripheral clock / encoder clock part | 19:34 |
somlo | I built a 'full' variant on the nexys4ddr (with Vivado) and it fits, and beats the pants off of the emulated variant in linpack :) | 19:34 |
_florent_ | then also copy the sdram instance | 19:34 |
john_k[m] | _florent_: ok will try that if p=16 doesn't work | 19:34 |
_florent_ | be sure that you have 1:2 in the sdram module, not 1:4 | 19:35 |
john_k[m] | in general, is HalfRate or QuarterRate preferred? I'd want to think that QuarterRate would give more BW? | 19:35 |
_florent_ | john_k[m]: sorry the code i adapted before won't work, i was thinking it was a DDR3 | 19:35 |
john_k[m] | oh | 19:35 |
_florent_ | ok Spartan6 it's pretty limited, we only validated DDR2 with HalfRate and DDR3 with QuarterRate | 19:36 |
_florent_ | ok/on | 19:36 |
_florent_ | john_k[m]: sorry i have to go, if it's not working, you can post your results here, i'll have a look later | 19:38 |
John_K | sounds good, thanks for all of your help _florent_ | 19:38 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!