| *** tpb has joined #litex | 00:00 | |
| *** futarisIRCcloud has joined #litex | 00:03 | |
| *** ambro718 has quit IRC | 00:10 | |
| *** Bertl is now known as Bertl_zZ | 00:12 | |
| *** lf_ has quit IRC | 00:39 | |
| *** lf has joined #litex | 00:39 | |
| *** lkcl has quit IRC | 01:44 | |
| *** lkcl has joined #litex | 01:56 | |
| *** Degi_ has joined #litex | 03:32 | |
| *** Degi has quit IRC | 03:35 | |
| *** Degi_ is now known as Degi | 03:35 | |
| *** lkcl has quit IRC | 04:01 | |
| *** lkcl has joined #litex | 04:14 | |
| *** futarisIRCcloud has quit IRC | 04:33 | |
| *** kgugala_ has joined #litex | 06:18 | |
| *** kgugala has quit IRC | 06:19 | |
| *** lkcl has quit IRC | 07:23 | |
| geertu | nickoe: Why? Flipping USB connectors is part of our heritage ;-) | 07:27 |
|---|---|---|
| geertu | s/our heritage/the full USB experience/ | 07:33 |
| *** lkcl has joined #litex | 07:36 | |
| *** kgugala_ has quit IRC | 07:40 | |
| *** kgugala has joined #litex | 07:41 | |
| *** proteusguy has quit IRC | 10:29 | |
| *** proteusguy has joined #litex | 10:42 | |
| *** Zguig has joined #litex | 11:00 | |
| Zguig | Hi all, is it just me or there was a change somewhere related to ethernet? I don't manage to receive packets with ECPIX-5 boards. I see them going out and being received, but the reply is not catched in Linux... Am I missing something? Some days ago it was working... :( | 11:01 |
| Zguig | What is strange is that boot from tftp is working fine | 11:10 |
| Zguig | So it should mean that at Ethernet core level everything is fine and that the issue is related to Linux? | 11:11 |
| _florent_ | Zguig: I switched back to IRQ mode a few days ago: https://github.com/litex-hub/linux-on-litex-vexriscv/commit/1e05fad048a28520015a696d46499de6cbe15dee | 11:11 |
| _florent_ | this also requires: https://github.com/enjoy-digital/litex/commit/7abfbd9825188d1f6d97453838e18ed7af5526a7 | 11:12 |
| _florent_ | Zguig: can you check your .dts to see if there is the status = "okay"; in the ethernet peripheral? | 11:13 |
| Zguig | Yes I have it | 11:14 |
| Zguig | mac0: mac@f0004800 { | 11:14 |
| Zguig | compatible = "litex,liteeth"; | 11:14 |
| Zguig | reg = <0xf0004800 0x7c>, | 11:14 |
| Zguig | <0xf0004000 0x0a>, | 11:14 |
| Zguig | <0xb0000000 0x2000>; | 11:14 |
| Zguig | tx-fifo-depth = <2>; | 11:14 |
| Zguig | rx-fifo-depth = <2>; | 11:14 |
| Zguig | interrupts = <2>; | 11:14 |
| Zguig | status = "okay"; | 11:14 |
| Zguig | }; | 11:14 |
| _florent_ | OK, and you are booting from SDCard? | 11:14 |
| Zguig | Nop from TFTP | 11:14 |
| Zguig | I can try with SDCard also | 11:14 |
| Zguig | But that was the strange thing that at bios level it was ok with udp | 11:15 |
| _florent_ | no tftp is fine, was just wondering of the rv32.dtb has been updated on your tftp server | 11:16 |
| Zguig | I check this file | 11:16 |
| _florent_ | otherwise, can you try setting polling to True here: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/soc_linux.py#L259 | 11:16 |
| _florent_ | regenerate the rv32.dtb with ./make.py --board=ecpix5, copy images/rv32.dtb to your tftp server and retry with it | 11:17 |
| _florent_ | if working with polling and not working with irqs, I could have a closer look in the next days | 11:18 |
| Zguig | I test all this, thanks _florent_!: | 11:19 |
| *** Zguig has quit IRC | 11:26 | |
| *** Zguig has joined #litex | 11:26 | |
| Zguig | Ok so when I enable back polling, it works fine | 11:47 |
| Zguig | I will dig a bit this dts file, never heard about it before :) | 11:48 |
| Zguig | there might be something there or with linux kernel conf | 11:48 |
| Zguig | I had also issues with multicore boot, this might be where I need to dig on what is going on | 11:48 |
| *** Bertl_zZ is now known as Bertl | 11:49 | |
| Zguig | But regarding to linux kernel, to make sure it was not me, I did some tests also with prebuild kernels you provided in beginning of the year | 11:52 |
| *** lkcl has quit IRC | 12:03 | |
| _florent_ | somlo: your ECPIX5 port is also working here: https://twitter.com/enjoy_digital/status/1356573386055569410 | 12:05 |
| *** lkcl has joined #litex | 12:16 | |
| somlo | _florent_: thanks, looks great! :) | 12:21 |
| geertu | somlo: How many LEs do you need for rocket? | 12:30 |
| *** lkcl has quit IRC | 12:55 | |
| *** lkcl has joined #litex | 13:08 | |
| somlo | geertu: off the top of my head, the whole LiteX+Rocket SoC (with ethernet and sdcard) uses about 70% of TRELLIS_SLICEs on an 85k ecp5 | 13:18 |
| somlo | geertu: and here's the hierarchical place utilization report from vivado (for the nexys4ddr): https://pastebin.com/erVHtDn2 | 13:24 |
| tpb | Title: -------------------------------------------------------------------------------- - Pastebin.com (at pastebin.com) | 13:24 |
| somlo | (this one was built with the added analyzer, so hopefully that's reflected in there somewhere :) | 13:25 |
| *** Bertl is now known as Bertl_oO | 13:35 | |
| geertu | somlo: Hmm, so no small task to make it fit in the 24K part. | 13:50 |
| *** lkcl has quit IRC | 14:16 | |
| *** lkcl has joined #litex | 14:16 | |
| *** lkcl has quit IRC | 14:27 | |
| somlo | geertu: it's hit-or-miss even on the versa (45k ecp5) -- don't think a rocket/litex soc can fit on a 24k... | 14:36 |
| somlo | or by "24k part" you mean a xilinx chip? no idea if/how that would work, in that case | 14:37 |
| *** lkcl has joined #litex | 14:40 | |
| *** Zguig has quit IRC | 14:51 | |
| *** Zguig has joined #litex | 14:52 | |
| geertu | somlo: I did mean the small ECP4 on the OrangeCrab | 14:56 |
| *** lkcl has quit IRC | 15:00 | |
| *** Melkhior has joined #litex | 15:04 | |
| Melkhior | Datapoint: using vivado (not an OSS toolchain), the Rocket SoC just fit using 95% of the LUT in a Artix-7 35k ; that's with just memory controller, serial port, sdcard; no ethernet or any fancy options | 15:06 |
| Melkhior | | Site Type | Used | Fixed | Available | Util% | | 15:08 |
| Melkhior | +----------------------------+-------+-------+-----------+-------+ | 15:08 |
| Melkhior | | Slice LUTs | 19792 | 0 | 20800 | 95.15 | | 15:08 |
| Melkhior | | Slice Registers | 10758 | 0 | 41600 | 25.86 | | 15:08 |
| Melkhior | | Slice Registers | 10758 | 0 | 41600 | 25.86 | | 15:08 |
| Melkhior | | Site Type | Used | Fixed | Available | Util% | | 15:08 |
| Melkhior | +-------------------+------+-------+-----------+-------+ | 15:08 |
| Melkhior | | Block RAM Tile | 25.5 | 0 | 50 | 51.00 | | 15:08 |
| geertu | s/ECP4/ECP5/ | 15:08 |
| Melkhior | But rocket uses no DSP block at all ? Weird, VexRiscV uses some for the multiplier. | 15:09 |
| *** lkcl has joined #litex | 15:14 | |
| *** lambda has quit IRC | 15:26 | |
| *** lambda has joined #litex | 15:37 | |
| nickoe | geertu: hehe | 15:53 |
| nickoe | (usb) | 15:54 |
| somlo | _florent_, daveshah: here's my attempt at an ecp5 jtag patch for litex: mirror.ini.cmu.edu/litex/litex-ecp5-jtag.patch and here's trying to use that by adding analyzer support for the trellisboard: mirror.ini.cmu.edu/litex/litex-boards-trellisboard-analyzer.patch | 16:28 |
| somlo | and here's what happens when I try to connect to it with litex-server: https://pastebin.com/fkdmx68N | 16:28 |
| tpb | Title: $ dist/litex_server --jtag --jtag-config /usr/share/trellis/misc/openocd/trellis - Pastebin.com (at pastebin.com) | 16:28 |
| somlo | anything obvious I might have missed? | 16:29 |
| daveshah | I think something is failing in the OpenOCD integration. Something that I don't see is something telling OpenOCD about the custom opcodes to use (0x32/0x38) to access the JTAGG | 16:30 |
| somlo | would that be in the openocd config file ? | 16:30 |
| daveshah | I'm not sure how that works tbh | 16:30 |
| daveshah | but I know it needs to be somewhere :) | 16:30 |
| somlo | yeah, then I'm screwed :) I know a lot *less* and was just hoping for some easy cut'n'paste, monkey-see-monkey-doo success, but things rarely work out for me like that :D | 16:31 |
| somlo | guess that's how I end up learning things, I'll keep staring at the various moving parts until they slowly and painfully start making sense, eventually, hopefully... | 16:32 |
| daveshah | you could try something like changing "irscan $_CHIPNAME.tap $_USER1" to "irscan ecp5.tap 0x32" | 16:33 |
| daveshah | in https://github.com/enjoy-digital/litex/blob/2a542e150de8715fa07e4b43bb7ec37f4d788fec/litex/build/openocd.py | 16:33 |
| daveshah | and same here, $_CHIPNAME to ecp5 https://github.com/enjoy-digital/litex/blob/2a542e150de8715fa07e4b43bb7ec37f4d788fec/litex/build/openocd.py#L143 | 16:35 |
| daveshah | I think the Xilinx OpenOCD stuff is setting $_CHIPNAME but the ECP5 stuff isn't so this would be a quick way to check (I don't know what the proper fix here would be) | 16:35 |
| somlo | daveshah: that definitely got things started -- I can fire up litex_server | 16:40 |
| daveshah | that's good | 16:41 |
| somlo | running litescope_cli gets stuck "downloading" the vcd file | 16:41 |
| daveshah | there might be timing differences compared to the Xilinx primitive | 16:41 |
| somlo | but that might just be the ecp5 jtagg utilization being wrong on my end | 16:41 |
| daveshah | > o_JRSTN = ~self.reset | 16:43 |
| daveshah | huh does LiteX allow inversion of an output this way (it may well, I've just not seen this before) | 16:43 |
| somlo | I've grepped around for how one would invert a signal, and there's examples like that elsewhere in the code base | 16:43 |
| somlo | I think there's one even in soc/cores/jtag.py further above where I added mine... | 16:44 |
| daveshah | that looks like an input though | 16:45 |
| somlo | oh you mean I screwed up and should have written "i_JRSTN" ? | 16:46 |
| daveshah | no, o_JRSTN is an output | 16:46 |
| daveshah | but I think what you might need to do is output to a temp signal and then assign self.reset to be the inverse of that temp signal | 16:46 |
| daveshah | unless that really is valid syntax for an inverted output | 16:47 |
| somlo | I can try that and see if it makes a difference... I don't get an error and it's done elsewhere, and did I mention cut'n'paste is how I get things done ? :D | 16:47 |
| somlo | but yeah, worth a shot... | 16:48 |
| *** peeps[zen] has joined #litex | 17:38 | |
| *** peepsalot has quit IRC | 17:39 | |
| somlo | daveshah: same behavior with the explicitly negated signal -- I'm going to assume it was OK with the original syntax, and dig elsewhere for why the vcd isn't getting downloaded from litescope_cli... | 17:46 |
| _florent_ | somlo: you should indeed use o_JRSTN = self.reset_n and have a self.reset.eq(~self.reset_n) below | 17:47 |
| somlo | but thanks for tracking down the openocd magic in litex_server! | 17:47 |
| _florent_ | somlo: also litescope will be stressing the link a bit, that's a bit ambitious for a first test :) I would first test with simple accesses to the scratch register (eventually with litex_client --read/--write/--regs) | 17:49 |
| somlo | _florent_: the "direct negation" syntax is also used elsewhere: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/jtag.py#L31 -- but looking more closely, the negated signal is an "lvalue" (or source to an input), and in my case it's an output, so maybe that's why *I* shouldn't do it like that and it's ok for the line I linked to :) | 17:49 |
| somlo | _florent_ I'm going to try writing (reading still won't work for me over the jtag debug link on nexys4ddr, so I can't rely on it) | 17:50 |
| _florent_ | somlo: in the other case it's an input, which works | 17:50 |
| somlo | _florent_ -- I mean writing from litex_cli, and checking from the litex bios on the board itself | 17:50 |
| somlo | reading registers via litex_cli is still not making sense for me on the nexys4ddr, is what I meant to say -- so either I'm doing something wrong, or there's a bug in the analyzer -> jtag -> server -> client read path... | 17:51 |
| _florent_ | for bringing this up, I would recommend using a design with a SoC and both uartbone and jtagbone bridge with Litescope on the JTAG signals | 17:52 |
| _florent_ | run Litescope over the uartbone to capture the write/read accesses from the JTAG | 17:53 |
| somlo | ok, so the ecp5 jtag patch now has additionally this: https://pastebin.com/JUy1PjuV | 17:54 |
| tpb | Title: diff --git a/litex/soc/cores/jtag.py b/litex/soc/cores/jtag.pyindex 3fc1a601.. - Pastebin.com (at pastebin.com) | 17:54 |
| somlo | _florent_: I'm going to try writing to the trellisboard registers via jtag (what I know to already work on the nexys4ddr). We should probably stick to the nexys4ddr to further debug the read-register-over-jtagbone problem, IMHO (fewer unknown unknowns :) ) | 17:59 |
| somlo | and writes do *not* make it through over the ecp5 jtagg thing, so back to the drawing board | 18:01 |
| somlo | it does not help that jtagg is practically undocumented (beyond a list of inputs and outputs) | 18:01 |
| somlo | I'm sure there's probably 17.5 things I'm getting wrong about it by just guessing :) | 18:02 |
| somlo | maybe I should put in a RFC-dont-apply-PR if that makes it easier to look at it together? | 18:02 |
| _florent_ | somlo: just for info, I'm been using jtagbone the last few days to do bus control/LiteScope since need it on a Kintex7 boards that only has a JTAG connector and haven't reproduced the issue you see on nexys4ddr yet | 18:10 |
| somlo | _florent_ I wonder if it's specific to the nexys4ddr, and/or the bitstream (or analyzer-enabling patch) I'm applying to it | 18:11 |
| _florent_ | I'll try to do some tests on the nexys4ddr to see if I reproduce | 18:12 |
| somlo | _florent_: I use http://mirror.ini.cmu.edu/litex/litex-nexys-analyzer.patch | 18:16 |
| somlo | ok, PR #797 for the ecp5 jtag "candidate" | 18:28 |
| somlo | now back to nexys4ddr... | 18:28 |
| *** Melkhior has quit IRC | 18:53 | |
| *** Zguig has quit IRC | 18:53 | |
| *** kgugala_ has joined #litex | 19:09 | |
| *** kgugala has quit IRC | 19:12 | |
| *** kgugala has joined #litex | 19:21 | |
| *** kgugala_ has quit IRC | 19:24 | |
| *** kgugala_ has joined #litex | 19:30 | |
| *** kgugala has quit IRC | 19:32 | |
| *** kgugala_ has quit IRC | 19:42 | |
| *** kgugala has joined #litex | 19:42 | |
| nickoe | Anyone who has some notes on doing boundry scan test practically with openocd and the artix7 somehow? | 19:44 |
| *** kgugala_ has joined #litex | 19:44 | |
| *** kgugala has quit IRC | 19:48 | |
| nickoe | On another topic, how does one define the platform for a board where you have the FPGA for a sub module and you want to remap those "pins" to something on that base board and make it more accessible. | 19:48 |
| *** peeps[zen] is now known as peepsalot | 20:15 | |
| *** ambro718 has joined #litex | 20:18 | |
| *** ambro718 has quit IRC | 20:28 | |
| nickoe | ok, verified the board could be flashed with nmigen and a couple of LEDs, now I just need to figure out how that RAM and flash works... | 20:44 |
| nickoe | Does the spiflash_model have any real meaning in the platforms ? | 21:13 |
| nickoe | Ok, I think I did define the flash correctly now. Next up the ddr3 stuff :S | 22:02 |
| nickoe | What does the grouping to the Pins object mean for a? https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/arty_s7.py#L91-L93 | 22:11 |
| nickoe | Why isn't that just one list? | 22:11 |
| nickoe | I have a signal called VREF_DDR3, but I am not sure what to make that to in the platform conf, is that "cs_n"? | 22:18 |
| nickoe | https://dpaste.com/4Q342VQHY | 22:18 |
| tpb | Title: dpaste: 4Q342VQHY (at dpaste.com) | 22:18 |
| nickoe | so I have not assigned the A's and the VREF_DDR3 is the one one "left" (I updated the other variables) | 22:19 |
| nickoe | The board has a 100R pull down on something called "CS#"... so I wonder.. maybe I shall just remove it? | 22:26 |
| nickoe | or do I need to connect it elsewher? | 22:27 |
| nickoe | mithro: yo, trying to "upgrade" from the basys3 to something with DDR3 SDRAM. Any hints? :d | 22:28 |
| daveshah | 10:11 PM <nickoe> What does the grouping to the Pins object mean for a? https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/arty_s7.py#L91-L93 | 22:29 |
| daveshah | It is just one list | 22:30 |
| nickoe | daveshah: ok, cool | 22:30 |
| daveshah | The grouping is arbitrary to make it a bit clearer, Python joins the strings together | 22:30 |
| daveshah | Sorry, not Python joining the strings here but LiteX (I missed the comma) | 22:30 |
| daveshah | same thing though | 22:30 |
| daveshah | Sounds like chip select is always enabled if it is permanently pulled down and has no associated pin, then yes you should be able to remove it | 22:31 |
| daveshah | from the LiteX board file | 22:31 |
| nickoe | is that VREF_DDR3 to be used for anything? it looks like it is the center of a voltage divider on the board | 22:32 |
| daveshah | Yes, although often it doesn't need a pin constraint because it's a fixed pin | 22:33 |
| nickoe | ok, I think it is correct now, although there is a high likelyhood of typos after all those parameters. What is the best way to test this? | 22:33 |
| daveshah | Build a test SoC and see if the memory test passes is pretty much the only way | 22:34 |
| nickoe | this is my platform code for now, https://dpaste.com/3XLTBU5CV | 22:34 |
| tpb | Title: dpaste: 3XLTBU5CV (at dpaste.com) | 22:34 |
| daveshah | Many typos will cause the build to fail | 22:34 |
| nickoe | I am not exactly sure about the SPI flash parameters, but I think they are correct. | 22:34 |
| nickoe | I asume the IOStandard and misc args to those signals are correct, but I don't really know. I just copied the skeleton from another thing that had a DDR3 SDRAM comment to the block. | 22:35 |
| daveshah | It looks decent at a glance | 22:36 |
| daveshah | The next step is to get a target written, if you haven't already | 22:36 |
| nickoe | I don't but I guess I can copy one and replace some bits | 22:36 |
| nickoe | I am new to litex | 22:36 |
| nickoe | and migen in general | 22:36 |
| daveshah | Yeah the target files tend to involve fewer changes than the platform file | 22:37 |
| daveshah | Mainly it will be setting it up with the right RAM chip etc | 22:37 |
| nickoe | I guess I could copy the arty_s7.py | 22:38 |
| daveshah | Yep | 22:39 |
| nickoe | mmm, it has a "from litedram.modules import MT41K128M16" :S Is that something that should match my RAM? | 22:39 |
| daveshah | Yes | 22:39 |
| daveshah | If it's not in litedram.modules already then you'll need to add it | 22:40 |
| nickoe | being NT5CC128M16IP-DI | 22:40 |
| nickoe | daveshah: Is that in the form of these yaml files? https://github.com/enjoy-digital/litedram/tree/master/examples | 22:42 |
| daveshah | no, it's an entry like this | 22:43 |
| daveshah | https://github.com/enjoy-digital/litedram/blob/master/litedram/modules.py#L621 | 22:43 |
| daveshah | create a class for your chip using the values from its datasheet | 22:43 |
| nickoe | oh, ok, I will have a look | 22:49 |
| nickoe | Datasheet is https://www.nanya.com/Files/696?Filename=2Gb_DDR3_I_Die_component_Datasheet.pdf&ProductId=3,771 But, daveshah, but I can I figure out what nrows and ncols should be? | 23:03 |
| daveshah | nrows is 2^14=16384, ncols is 2^10=1024, based on the number of row and column address bits | 23:04 |
| nickoe | so that is for 128Mb x 16 ? | 23:05 |
| nickoe | deduced from the "Density and Addressing" table on the front page? | 23:05 |
| daveshah | Yes | 23:06 |
| nickoe | and the fact that NT5CC128M16IP-DI is listed as "128M x 16" organization. ok | 23:06 |
| daveshah | yup | 23:06 |
| nickoe | What about the timings then? | 23:06 |
| nickoe | why is that set as tREFI=64e6/8192 for some of the other devices? | 23:08 |
| nickoe | the table has a temperature dependent value, tREFI(us) 4 Tc<=85 °C :7.8, Tc>85 °C :3.9 | 23:08 |
| daveshah | that is 64ms (the total refresh time) divided by 8192 rows, I think | 23:09 |
| daveshah | I think just copying the 64e6/8192 should be fine | 23:12 |
| nickoe | under section "Extended Temperature Usage" it talks about supporting extended temperateture ranges, and having a faster refresh rate. Is that because leakage current is higher? | 23:12 |
| daveshah | given DRAM is somewhat standardised, I would expect most of the timings to be the same as another 128Mx16 part | 23:12 |
| nickoe | at higher temperatures? | 23:12 |
| daveshah | Yes | 23:12 |
| nickoe | ok, so the last thing, the speedgrade timings | 23:12 |
| mithro | nickoe: Get an Arty A7.... | 23:16 |
| nickoe | ugh, build_waxwing.sh: line 4: xst: command not found | 23:24 |
| nickoe | mithro: I mean; I have another board now with DDR | 23:25 |
| mithro | nickoe: That needs ISE.... | 23:25 |
| nickoe | mithro: ehh, no | 23:25 |
| mithro | xst == ISE | 23:26 |
| nickoe | oh.. then I did something wrong, this has an artix7 | 23:26 |
| nickoe | oh, it detected P=waxwing ... mmmm | 23:26 |
| nickoe | is there some place I need to specify a new platform to make it be detected properly when I set PLATFORM and sources the enter env? | 23:27 |
| nickoe | oh, right. I added the "target" in another litex-boards repo | 23:28 |
| nickoe | instead of the litex-buildenv | 23:28 |
| nickoe | ok, so far so good, some fiddling with the "target" needed, but it is getting late here. GN. https://dpaste.com/3P3FRECM4 | 23:36 |
| tpb | Title: dpaste: 3P3FRECM4 (at dpaste.com) | 23:36 |
| daveshah | yep looks like it is just getting confused by the lack of a reset in the platform (if the board doesn't have anything usable as a reset button you should just be able to remove the reset from the target) | 23:39 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!