*** tpb has joined #litex | 00:00 | |
sajattack[m] | pdp7: maybe something is wrong with your formatting? | 00:02 |
---|---|---|
sajattack[m] | I used gparted, it provides sensible defaults for fat16 | 00:03 |
sajattack[m] | also make sure to properly eject the card | 00:03 |
pdp7 | looks like i missing rootfs.cpio on this new card :) | 00:10 |
pdp7 | darn same results, nothing after liftoff | 00:25 |
pdp7 | https://github.com/litex-hub/linux-on-litex-vexriscv/issues/123#issuecomment-604753175 | 00:25 |
tpb | Title: Test SDCard boot with OrangeCrab · Issue #123 · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com) | 00:25 |
*** CarlFK has joined #litex | 00:46 | |
*** Degi has quit IRC | 02:03 | |
*** Degi has joined #litex | 02:04 | |
sajattack[m] | any gotcha's with the fsm module? I don't see the fsm I made showing up in my design | 02:10 |
sajattack[m] | is it because I named it self.fsm instead of self.submodules.fsm? | 02:12 |
sajattack[m] | I think that was it | 02:13 |
sajattack[m] | now quartus fails to compile my design completely because it says I have multiple constant drivers | 02:14 |
sajattack[m] | I thought if there were multiple drivers it took the one furthest down the file | 02:14 |
sajattack[m] | oh is it because some of them are sync and some of them are comb? | 02:16 |
*** gregdavill has quit IRC | 02:49 | |
*** gregdavill has joined #litex | 02:49 | |
*** gregdavill has quit IRC | 02:53 | |
*** gregdavill has joined #litex | 02:53 | |
sajattack[m] | inside a state machine, what is the difference between `NextValue(foo, 1)` and `foo.eq(1)`? | 03:18 |
gregdavill | The FSM module is a bit tricky before you know how it works. | 04:41 |
gregdavill | Everything inside `fsm.act` is combinational logic. | 04:41 |
sajattack[m] | yep | 04:42 |
gregdavill | `NextValue()` and `NextState()` are special and operate in synchronously | 04:43 |
gregdavill | *operate synchronously | 04:43 |
sajattack[m] | ok | 04:43 |
gregdavill | So in migen terms `foo.eq(1)` is a comb statement, `NextValue(foo, 1)` is a sync statement. | 04:44 |
sajattack[m] | yeah ok I think I should be using eq | 04:44 |
gregdavill | A trap I've fallen into is that `foo.eq(foo + 1)` will not work, because it creates a combinational loop. | 04:45 |
sajattack[m] | thanks | 04:45 |
sajattack[m] | mhm | 04:45 |
sajattack[m] | with tristates, am I correct that i is the input sensed value, o is the value to output, and oe is whether the pin is o or i? | 04:52 |
sajattack[m] | or rather a gate between o and i | 04:53 |
*** CarlFK has quit IRC | 05:06 | |
*** CarlFK has joined #litex | 06:24 | |
_florent_ | sajattack[m]: yes that's correct for the Tristate, set oe to 1 to use it as output | 06:35 |
_florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/gpio.py#L35 | 06:35 |
tpb | Title: litex/gpio.py at master · enjoy-digital/litex · GitHub (at github.com) | 06:35 |
keesj | gregdavill: on your example foo.eq(foo +1) I think it should normaly work (at least it doen in VHDL) but the thing to remember is that in such case there are twoo foo's , the input foo and the output foo and that the output foo will not be updated until en the of the statment e.g. doing 10 times foo.eq(foo +1) would in the end result in foo.eq(foo +1) | 06:45 |
keesj | that is at least how I understand it | 06:45 |
keesj | gregdavill: also .. did you ever look at my orange crab drc ? https://github.com/keesj/orange_crab_drc | 06:46 |
tpb | Title: GitHub - keesj/orange_crab_drc: Script to perform some drc tests on the orange crab fpga board (at github.com) | 06:46 |
gregdavill | in migen if I type self.comb += foo.eq(foo + 1). It locks-up the simulator, rightly so. The isn't a way you can create a loop like that in combinational logic. | 06:48 |
gregdavill | keesj: I did! I'm already using this script, which covers all my needs: https://github.com/gregdavill/OrangeCrab/blob/master/lib/kicad-length-matching-checks/length_match.py | 06:50 |
tpb | Title: OrangeCrab/length_match.py at master · gregdavill/OrangeCrab · GitHub (at github.com) | 06:50 |
keesj | thanks . I will have a look at your script | 06:52 |
gregdavill | The one I'm using pulls net groups out of the KiCad project itself, so it's very easy to configure. But it runs in a separate terminal window, and it's not an Action Plugin. | 06:53 |
keesj | the default lenght matching was taking the full trace lenght including the terminaor resistors | 06:53 |
gregdavill | Yep, there are changes I made so it's now only checking distance of traces between two ICs. | 06:54 |
keesj | I borrowed the litex syntax. https://github.com/keesj/orange_crab_drc/blob/master/orange_crab_drc_action.py#L18 | 06:55 |
tpb | Title: orange_crab_drc/orange_crab_drc_action.py at master · keesj/orange_crab_drc · GitHub (at github.com) | 06:55 |
keesj | I was/am working on a ddr interposer | 06:56 |
keesj | anyway.. I will have a good look at your script | 06:59 |
gregdavill | The pad2pad_track_distance code is pretty cool, looks a bit better than mine performance wise. | 07:01 |
gregdavill | I ended up coding a messy tree structure based on track segments corresponding to a net, I then do a recursive search on this tree until I find a segment that connects to the target chip. | 07:03 |
keesj | Still.. quite slow. but .. in my search for a ddr3 layout.. I only found olimex and you doing stuff | 07:03 |
keesj | (in kicad) | 07:03 |
keesj | that is not my code https://github.com/MitjaNemec/Kicad_action_plugins/tree/master/pad2pad_track_distance | 07:05 |
tpb | Title: Kicad_action_plugins/pad2pad_track_distance at master · MitjaNemec/Kicad_action_plugins · GitHub (at github.com) | 07:05 |
keesj | I was also thinking it might be cool to try and push things further e.g. from the migen/litex code generate a netlist | 07:07 |
dkozel | pdp7: Hope you enjoyed it | 08:37 |
dkozel | I got a bit enthusiastic and don't think I matched the explanation to the audience. | 08:42 |
*** scanakci has quit IRC | 08:51 | |
_florent_ | dkozel: hi, about litepcie, you should see something in dmesg when loading the kernel module, that's strange. | 09:25 |
dkozel | Hi _florent_ | 09:30 |
dkozel | I'm just settling down to try things again | 09:30 |
dkozel | Do you have any ideas why I had to add to kernel header includes to the main.c? | 09:30 |
_florent_ | not sure, i'm going to prepare a repository with all the files, this way i will also do some checks. | 09:34 |
dkozel | Other than the kernel module is there anything I do to check that the gateware is appropriately loaded and running | 09:39 |
dkozel | PCI device id is different for my FPGA | 09:47 |
dkozel | 10ee:7024 | 09:47 |
dkozel | Much better | 09:49 |
dkozel | [ 4564.845337] BUG: unable to handle page fault for address: ffffa3ac403fc000 | 09:49 |
dkozel | [ 4564.845340] #PF: supervisor read access in kernel mode | 09:49 |
dkozel | [ 4564.845341] #PF: error_code(0x0000) - not-present page | 09:49 |
dkozel | https://pastebin.com/xKqZNb7h | 09:52 |
tpb | Title: [ 4564.845200] litepcie [Probing device] [ 4564.845215] litepcie 0000:03:00.0: - Pastebin.com (at pastebin.com) | 09:52 |
_florent_ | dkozel: i just created https://github.com/enjoy-digital/litepcie_aller_test | 09:55 |
tpb | Title: GitHub - enjoy-digital/litepcie_aller_test: Test with LitePCIe and Numato Aller board. (at github.com) | 09:55 |
dkozel | Thanks will switch to that | 09:57 |
_florent_ | With the current LiteX design, the device should be 10eee:7021, so i think the Numato bitstream is still loaded | 09:57 |
dkozel | Ok, Vivado does think it programmed the FPGA | 09:58 |
dkozel | Hmm, can we get a mask file from LiteX/Migen to use Vivado to verify the loaded bitstream? | 09:59 |
dkozel | yes, found the migen opts | 10:02 |
dkozel | My build environment for the kernel module is clearly different from yours, paths don't match | 10:13 |
_florent_ | since you are probably just loading the bistream, you can only do a reset of the host computer, not a power on/power off otherwise the FPGA will reload the bitstream from SPI Flash | 10:13 |
_florent_ | dkozel: which paths for example? | 10:14 |
dkozel | ah, and the host isn't reenumerating the PCIe device with the new bitstream | 10:14 |
dkozel | home/dkozel/src/litepcie_aller_test/software/kernel/csr.h:12:10: fatal error: hw/common.h: No such file or directory | 10:14 |
dkozel | 12 | #include <hw/common.h> | 10:14 |
dkozel | and the soc, mem, csr.h files needing to be in kernel/generated/ or the kernel/ directories | 10:15 |
_florent_ | the bistream i prepared should already put the header at the right location: https://github.com/enjoy-digital/litepcie_aller_test/blob/master/aller.py#L152 | 10:19 |
tpb | Title: litepcie_aller_test/aller.py at master · enjoy-digital/litepcie_aller_test · GitHub (at github.com) | 10:19 |
_florent_ | also, here we have different header files for the CPU running in the FPGA and for the Host that will interfact with the FPGA over PCIe | 10:20 |
_florent_ | the headers in generated directlry are for the CPU | 10:20 |
dkozel | Ok. I'm going to clean all directories, restart (kernel mod cannot be removed because it's in use) and rebuild. Back in 10 minutes | 10:25 |
_florent_ | ok | 10:26 |
dkozel | Bitstream is building into the directory ./soc_pciesoc_aller/ | 10:47 |
dkozel | so the generated files don't get written into the ./software directory | 10:47 |
dkozel | I can easily copy over files, is that correct? | 10:48 |
_florent_ | with the aller.py target i provided, the header that are used by the kernel should automatically be generated to software/kernel | 10:59 |
_florent_ | https://github.com/enjoy-digital/litepcie_aller_test/blob/master/aller.py#L152-L158 | 11:00 |
tpb | Title: litepcie_aller_test/aller.py at master · enjoy-digital/litepcie_aller_test · GitHub (at github.com) | 11:00 |
dkozel | Ah. Just noticed that it does generate them twice, cool | 11:01 |
dkozel | the two kernel headers are still missing from main.c | 11:01 |
dkozel | I am on 5.6.0rc6 so maybe things have moved? | 11:02 |
dkozel | And the kernel module is loaded and detects the board! | 11:20 |
dkozel | And the user program works | 11:21 |
dkozel | 3.20 Gbps DMA works | 11:22 |
_florent_ | nice! | 11:27 |
dkozel | Thanks! | 11:29 |
_florent_ | so now if you want to generate a dumy stream on the DMA RX receive it on the computer, you can add this to the gateware: https://github.com/enjoy-digital/netv2/blob/master/netv2.py#L203-L209 | 11:29 |
tpb | Title: netv2/netv2.py at master · enjoy-digital/netv2 · GitHub (at github.com) | 11:29 |
_florent_ | and then do litepcie_test record dump.bin 0x1000 for example | 11:30 |
dkozel | Ok, that's useful | 11:30 |
dkozel | is there a CPU on the current bitstream? I think the default SoC does include one? I didn't pay attention to the build log | 11:31 |
*** _whitelogger has quit IRC | 11:36 | |
_florent_ | dkozel: yes you should have a CPU and DDR3 controller, you can verify it's working correctly by doing litepcie_util uart_test | 11:38 |
_florent_ | you should see the LiteX bios and DDR3 initialization | 11:38 |
*** _whitelogger has joined #litex | 11:38 | |
dkozel | Splended, works | 11:39 |
dkozel | I really like this ecosystem. Lots to learn! | 11:39 |
dkozel | Memspeed Writes: 253Mbps Reads: 320Mbps | 11:40 |
*** rohitksingh has quit IRC | 11:42 | |
_florent_ | cool, that's the speed tested from the CPU, the actual speed with DMAs is a lot higher (probably around 10Gbps on Aller with a 100MHz sys_clk) | 11:44 |
dkozel | the netv has Gen2 x4 for it's PCI interface right? | 11:46 |
dkozel | https://github.com/enjoy-digital/netv2/blob/master/netv2.py#L160 | 11:46 |
tpb | Title: netv2/netv2.py at master · enjoy-digital/netv2 · GitHub (at github.com) | 11:46 |
dkozel | Or not | 11:46 |
_florent_ | i could do the change to use PCIe Gen2 X4 on the Aller, but first wanted to validate with PCIe Gen2 X1 | 11:57 |
dkozel | Absolutely makes sense | 12:01 |
dkozel | I'm reading through the various wishbone-tool and other utility documentation now and trying things | 12:02 |
_florent_ | with https://github.com/litex-hub/litex-boards/commit/89dd00d3a233cd6fc56cbe7fa4760e7d84c9c432 | 12:09 |
tpb | Title: platforms/aller: rename pcie to pcie_x4 (for consistency with others … · litex-hub/litex-boards@89dd00d · GitHub (at github.com) | 12:09 |
_florent_ | and https://github.com/enjoy-digital/litepcie_aller_test/commit/993e05ef32a65c064e953ac169668a342c5f9fb6 | 12:09 |
tpb | Title: target/software: add pcie_x4 support and use it as default. · enjoy-digital/litepcie_aller_test@993e05e · GitHub (at github.com) | 12:09 |
_florent_ | you should now have PCIe gen2 X4 :) | 12:10 |
*** gregdavill has quit IRC | 12:14 | |
dkozel | lol | 12:19 |
dkozel | too easy, can't work :P | 12:19 |
dkozel | litex.build.generic_platform.ConstraintError: Resource not found: pcie_x4:None | 12:20 |
dkozel | ah | 12:21 |
dkozel | walk before running. aka update both repos | 12:21 |
dkozel | Bitstream built but I need to finish a few things before rebooting the host :D | 12:35 |
dkozel | Thanks, will jump back in this evening on this | 12:35 |
*** tcal has quit IRC | 13:26 | |
*** CarlFK has quit IRC | 14:37 | |
*** CarlFK has joined #litex | 15:00 | |
*** tcal has joined #litex | 15:01 | |
*** _franck_9 has joined #litex | 15:08 | |
*** _franck_ has quit IRC | 15:11 | |
*** _franck_9 is now known as _franck_ | 16:04 | |
pdp7 | anyone successfully used an SD card with LiteX? If so, what brand and model? I | 16:37 |
dkozel | Hmm. Not sure how I loaded that one image successfully earlier. | 16:42 |
dkozel | _florent_: How do you reboot/reset your computer without powering down the PCIe bus? I seem to be losing the image with `telinit 6` | 16:43 |
somlo | pdp7: hit-and-miss with LiteSDCard, pretty solid with SPI-mode SDCard -- 32 and 64 GB sandisk models | 17:12 |
pdp7 | ah, so maybe I should be going to bigger cards like 32GB. I was thinking the opposite, trying to find smaller, older cards | 17:13 |
somlo | pdp7: I specifically got a 2GB card to test with LiteSDCard, and it didn't work :) The 64GB sandisk worked, the 32GB one did not | 17:14 |
somlo | they all work solidly with SPI-mode "spisdcard", been using the 32GB ones for the last week or so | 17:14 |
somlo | however -- I made a dos partition table, and added a 1GB fat16 partition table (with fdisk) | 17:15 |
somlo | spi-mode sdcard boot only works with fat16 | 17:15 |
somlo | so most of the card is unused, and 1GB is "plenty space for everyone" :D | 17:16 |
somlo | disclaimer: I'm using litex with 64bit Rocket, so I'm only exercising this branch of spisdcardboot(): https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/boot.c#L522 | 17:18 |
tpb | Title: litex/boot.c at master · enjoy-digital/litex · GitHub (at github.com) | 17:18 |
pdp7 | somlo: does the sandisk show that it is from a particular product line? i could order one from amazon. | 17:31 |
pdp7 | somlo: oh, and what commands did you use? | 17:32 |
pdp7 | I used fdisk to make a 100MB partitition with FAT16 (used partition type 6) | 17:32 |
pdp7 | and i then did "mkfs.vfat" | 17:32 |
somlo | pdp7: https://imgur.com/7w6Nlc0 | 17:59 |
tpb | Title: Imgur: The magic of the Internet (at imgur.com) | 17:59 |
pdp7 | Thanks | 18:07 |
somlo | pdp7: also, https://pastebin.com/rWi6SpgU | 18:07 |
tpb | Title: # fdisk /dev/sdb Welcome to fdisk (util-linux 2.33.2). Changes will remain i - Pastebin.com (at pastebin.com) | 18:07 |
pdp7 | somlo: thanks | 18:28 |
pdp7 | somlo: the photo was of 32GB, but you said the 64GB worked? | 18:28 |
somlo | yeah, I'm looking for the amazon link of the 64 I ordered three weeks ago, stand by... | 18:30 |
somlo | pdp7: it was from officedepot: https://www.officedepot.com/a/products/9950594/SanDisk-Ultra-PLUS-microSD-Card-64GB/ | 18:34 |
pdp7 | thanks | 18:34 |
*** HoloIRCUser has joined #litex | 18:50 | |
*** HoloIRCUser1 has quit IRC | 18:52 | |
*** rohitksingh has joined #litex | 19:21 | |
*** CarlFK has quit IRC | 19:32 | |
*** HoloIRCUser1 has joined #litex | 21:02 | |
*** HoloIRCUser has quit IRC | 21:02 | |
*** CarlFK has joined #litex | 21:28 | |
*** HoloIRCUser has joined #litex | 21:41 | |
*** HoloIRCUser1 has quit IRC | 21:44 | |
*** HoloIRCUser has quit IRC | 21:48 | |
*** gregdavill has joined #litex | 23:27 | |
*** FFY00 has joined #litex | 23:57 | |
mithro | FFY00: Humans are bad at remembering and doing things reliably -- machines are great at that | 23:58 |
FFY00 | sure | 23:58 |
FFY00 | but unless you have machines writing your tests to make sure they cover every base, you shouldn't have automated releases on test passes | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!