*** tpb <[email protected]> has joined #litex | 00:00 | |
*** Degi_ <[email protected]> has joined #litex | 00:03 | |
*** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 00:05 | |
*** Degi_ is now known as Degi | 00:05 | |
*** Coldberg <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 01:02 | |
*** futarisIRCcloud <[email protected]> has quit IRC (Quit: Connection closed for inactivity) | 03:13 | |
yosys-questions | jevinskie[m] .. Will give it a shot, thanks! | 03:28 |
---|---|---|
jevinskie[m] | Np, here is an example: https://github.com/enjoy-digital/litedram/blob/db879ae3f7d591482e4665801c946241bb663bce/bench/arty.py#L71 | 04:22 |
sajattack[m] | Just a heads up, I ran into an error with sbt and jdk16, had to downgrade to jdk11 | 04:30 |
sajattack[m] | in case anyone else runs into the same | 04:31 |
sajattack[m] | https://hastebin.com/uhaxisidal.rb | 04:32 |
tpb | Title: hastebin (at hastebin.com) | 04:32 |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 04:47 | |
*** TMM_ <[email protected]> has joined #litex | 04:47 | |
sajattack[m] | I guess the litepcie kernel driver for linux-vexriscv would be different than the one for the litex-boards? Because it has more CSRs? Is that my issue? | 04:48 |
sajattack[m] | and how do I pass the --driver down to litex-boards from way up in linux-vexriscv | 04:48 |
sajattack[m] | hmm | 04:48 |
sajattack[m] | how do I turn a csr.csv or csr.json to a csr.h | 05:01 |
sajattack[m] | ahhh I think I might be onto something | 05:04 |
sajattack[m] | I think I got it now, but I need a tool to send the linux bitstream over pcie uart | 05:11 |
sajattack[m] | I don't think litex_term does that yet? | 05:11 |
sajattack[m] | I wish the litepcie driver made a tty | 05:23 |
sajattack[m] | or litex_term supported pcie | 05:27 |
sajattack[m] | brb, rewriting litex_term in rust for litepcie xD | 06:23 |
sajattack[m] | I already rewrote litepcie_util uart_test, now I just need the actual upload code | 06:24 |
_florent_ | sajattack[m]: LitePCIe hasn't really been tested/integrated with Linux-on-LiteX-VexRiscv so that's indeed possible some adaptations will be required. | 06:39 |
sajattack[m] | on it boss :P | 06:39 |
_florent_ | To load the Linux images, you could use litex_server in pcie mode and then litex_term in bridge mode | 06:40 |
sajattack[m] | how hard would it be to ioctl in python? | 06:40 |
sajattack[m] | ahh | 06:40 |
sajattack[m] | I tried litex_server in pcie mode and got some errors | 06:40 |
_florent_ | but this could also be interested to use the LitePCIe MMAP interface and just let the CPU directly access the Host's memory to load the binaries | 06:41 |
sajattack[m] | yeah that would be smarter | 06:42 |
sajattack[m] | let me try the litex_server again to show you | 06:42 |
sajattack[m] | https://hastebin.com/evucaticeb.sql | 06:43 |
tpb | Title: hastebin (at hastebin.com) | 06:43 |
_florent_ | ok, the code should probably be updated (https://bugs.python.org/issue40785) | 06:49 |
tpb | Title: Issue 40785: `mmap.mmap(..., 0)` doesn't work as advertised in docs (fails with EINVAL); relies on compatibility behavior no longer permitted by [some] Unix OSes - Python tracker (at bugs.python.org) | 06:49 |
sajattack[m] | aha | 06:50 |
_florent_ | instead of 0, can you try passing a valid length | 06:50 |
sajattack[m] | what length is it then? | 06:50 |
_florent_ | the size of the BAR0, let me check | 06:51 |
sajattack[m] | ok so like sys.stat or whatever | 06:51 |
_florent_ | The default side for BAR0 is 1MB in LitePCIe | 06:52 |
sajattack[m] | k thx | 06:52 |
sajattack[m] | it's 128KB for acorn I think | 06:55 |
sajattack[m] | oh but that's in 128bit chunks | 06:55 |
sajattack[m] | maybe? | 06:55 |
sajattack[m] | so 2mb I think | 06:56 |
sajattack[m] | that gives me a new error... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/53961e09b6c14cfabd72ac8c6e177f1c2df9ca93) | 06:58 |
_florent_ | Can you try to reduce it to 1MB? https://github.com/enjoy-digital/litepcie/blob/master/litepcie/phy/s7pciephy.py#L20 | 07:04 |
* sajattack[m] uploaded an image: (4KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/XhVXLwjyyAXVebhSgVuKsQma/2021-09-06-000504_681x93_scrot.png > | 07:05 | |
sajattack[m] | 1mb gave the same error as before and also | 07:05 |
sajattack[m] | hmm, you right... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/61eae87b1b7abe12a43136605fb58898bf4e24a1) | 07:07 |
sajattack[m] | gonna turn off resizable bar in my bios and see if that does anything | 07:11 |
sajattack[m] | derp, that wasn't it, I just had to unload the litepcie driver | 07:14 |
sajattack[m] | this is bad too | 07:16 |
* sajattack[m] uploaded an image: (45KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/DpiIgeblUtSdKBDDqdBHpILt/2021-09-06-001642_1693x384_scrot.png > | 07:16 | |
sajattack[m] | I might go back to trying to do shitty uart, what do you think? | 07:18 |
sajattack[m] | interestingly, this value is 0xf0001040 | 07:25 |
sajattack[m] | which is slightly outside of the uart_xover address space I think | 07:26 |
sajattack[m] | csr_register,uart_xover_rxfull,0xf000103c,1,ro | 07:26 |
*** FabM <[email protected]> has joined #litex | 07:31 | |
sajattack[m] | well I guess I'll see if I can get my shitty uart coded before florent comes back | 07:33 |
*** Guest9134 <[email protected]> has joined #litex | 08:32 | |
_florent_ | sajattack[m]: I created https://github.com/enjoy-digital/litex/issues/1026 for the mmap issue | 08:43 |
_florent_ | I'm still with Python3.6 and it's probably has to be updated for Python 3.7+ | 08:44 |
_florent_ | for litex_server over PCIe, maybe first try litex_cli --regs | 08:45 |
_florent_ | also, on the PCIe designs where I'm using LitePCIe, the idea is to reduce BAR0 size and just expose the CSR to it to allow the Host to control the board | 08:46 |
_florent_ | so we add an offset in add_pcie: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1685 | 08:47 |
_florent_ | That then has to be removed when using the generated csr.csv: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_client.py#L93-L95 | 08:48 |
_florent_ | you'll also have to do this in litex_term | 08:49 |
_florent_ | (sorry the PCIe integration on this is not yet very clean... that's not really a use case I've been using) | 08:49 |
sajattack[m] | interesting, thanks for the info | 09:03 |
sajattack[m] | I just don't want an extra damn cable going into my computer when the darn thing is already in my computer | 09:04 |
sajattack[m] | I just hacked a -0xf0000000 on the address in comm_pcie and it looks like it's doing something? but the upload percent is stuck at 0 | 09:10 |
sajattack[m] | maybe it's just incredibly slow | 09:10 |
*** Guest9134 <[email protected]> has quit IRC (Quit: Client closed) | 09:11 | |
sajattack[m] | I think it's uploading | 09:22 |
sajattack[m] | slow as balls btw | 09:24 |
sajattack[m] | not quite 9gbps | 09:24 |
sajattack[m] | xD | 09:24 |
sajattack[m] | one 8-bit ioctl at a time | 09:24 |
sajattack[m] | or maybe not | 09:24 |
sajattack[m] | idk how litex_server works | 09:25 |
sajattack[m] | --============== Boot ==================--... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d8f8499e4c7e3736471ea8bc86e1d979026db595) | 09:25 |
sajattack[m] | seems the libera bridge is a bit glitchy with long messages | 09:26 |
sajattack[m] | I was showing a couple lines of the bios output, upload at 6% | 09:27 |
*** yosys-questions <[email protected]> has quit IRC (Quit: Client closed) | 09:38 | |
sajattack[m] | the linux image would fit in spi flash if we had a driver for it | 09:39 |
pftbest | _florent_: Hello. I noticed that etherbone stops working when sys_clk is < 20MHz both on ecp5 and xilinx. Is there some easy way to fix this? Or I should switch to uartbone? | 09:43 |
sajattack[m] | did it default to 115200 baud maybe? | 09:51 |
sajattack[m] | that would be silly but I bet that's why it's so slow | 09:51 |
sajattack[m] | (talking to myself, not pftbest) | 09:51 |
zyp | pftbest, < 20 MHz or < 31.25 MHz? does it work at e.g. 25 MHz? | 10:11 |
pftbest | it works at 20, but fails at 10 | 10:12 |
pftbest | I also tried 16 and it didn't work | 10:12 |
pftbest | Why 31.25? is it some special ratio? | 10:13 |
zyp | I would guess there's an overrun or underrun somewhere when it becomes too slow to keep up | 10:13 |
zyp | 31.25 is 1Gb/s divided by a 32b wide stream | 10:13 |
pftbest | As I understand GMII frequency is 125MHz | 10:14 |
pftbest | BTW the ping works, but connecting from litex_server fails | 10:15 |
zyp | ping is handled in the 125 MHz domain | 10:15 |
pftbest | Maybe I can increase some fifo length? | 10:16 |
zyp | IIRC etherbone got a 32b wide UDP stream heading over into the sys domain | 10:16 |
zyp | perhaps | 10:16 |
zyp | or you could put etherbone itself in a faster domain and cdc the memory bus | 10:17 |
pftbest | I added depth=32 parameter here https://github.com/enjoy-digital/liteeth/blob/master/liteeth/core/udp.py#L50 | 10:23 |
pftbest | now it seems to work at 10MHz | 10:24 |
pftbest | zyp: thanks | 10:24 |
zyp | np | 10:28 |
pftbest | zyp: I added it at random and it helped, but I don't understand why :( | 10:28 |
pftbest | need to undo it and confirm again | 10:29 |
_florent_ | pftbest: with the current architecture, the minimum working freq will be 31.25MHz (125/4). If it works below, it's just luck (or effect of the internal buffering for small packets, but won't work for large packets) | 10:30 |
zyp | yeah, and the more buffering you add, the larger packets it'll work for | 10:30 |
_florent_ | pftbest: there is no assert in the integration code, but I could eventually add one | 10:30 |
pftbest | _florent_: ok, I see | 10:31 |
_florent_ | but even with working with increased depth, I would not recommend using this, it will cause you troubles later when you'll have long forget about this :) | 10:31 |
pftbest | I just need to check some signals using litescope @ 10MHz | 10:32 |
pftbest | and I don't like uartbone because it's slow | 10:32 |
zyp | you know you can run litescope slower than the sys domain? | 10:33 |
pftbest | But it seems there is no way around it | 10:33 |
pftbest | zyp: I know, but I need sys itself to be slow | 10:33 |
zyp | in that case I suggest putting etherbone in a faster domain | 10:34 |
pftbest | zyp: Sorry, I don't know how to put some module in another clock domain. If I knew I wouldn't be running sys at 10MHz | 10:37 |
zyp | putting a module in another clock domain is the easy part, you just wrap the instance in a ClockDomainsRenamer | 10:43 |
zyp | the slightly harder part is adding CDC to the signals | 10:43 |
pftbest | zyp: But what about CSR and Wishbone bus | 10:49 |
pftbest | As I understand they will not just work as is | 10:49 |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Remote host closed the connection) | 11:02 | |
_florent_ | pftbest: LiteScope has a clock_domain parameter that you can use for this: https://github.com/enjoy-digital/litescope/blob/master/litescope/core.py#L229 | 11:28 |
_florent_ | just create a specific clock_domain for your 10MHz logic and use it for LiteScope | 11:29 |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 11:30 | |
pftbest | _florent_: in my case changing the clock domain for litescope wont help. I am trying to enable DLL-off mode for DDR3 memory and run it at low frequency. | 11:49 |
pftbest | I don't know how to move whole litedram to another clock domain, so I'm just trying to run whole "sys" slower, so I can probe the signals | 11:50 |
Melkhior | Hello; for my design I have a bunch of set_input_delay/set_ouput_delay to deal with the unmatched length of traces on a parallel bus. So far I had hard-coded the path to the XDC file in vivado.py, but now i need some adaptability | 12:21 |
Melkhior | Is there a way to add some extra constrain file to Litex ? (so XDC for Vivado) | 12:21 |
Melkhior | Or to specify the input/output delay per-pins ? | 12:21 |
Melkhior | TIA | 12:22 |
_florent_ | Melkhior: you should be able to pass the extra constraints with platform.add_platform_command("...") | 12:29 |
_florent_ | Otherwise, for your parallel bus, if you want to have the best possible delays, make sure to use IO registers (will automatically be the case with SDRInput/Output) | 12:30 |
Melkhior | _florent_: I tried duplicating the file line-by-line with add_platform_command, but it complains about my parallel signal with a 'KeyError' | 12:33 |
Melkhior | File "/home/dolbeau/LITEX/litex/litex/build/generic_platform.py", line 409, in resolve_signals | 12:33 |
Melkhior | named_pc.append(template.format(**name_dict)) | 12:33 |
Melkhior | KeyError: 'SBUS_3V3_D' | 12:33 |
Melkhior | | Design Timing Summary | 12:33 |
Melkhior | In the XDC, each signal of the group is specified independently (e.g. : et_input_delay -clock SBUS_3V3_CLK -min 0.838 [get_ports {SBUS_3V3_D[1]}] ) | 12:34 |
Melkhior | Not sure if it's related - but the other signals before are fine | 12:35 |
Melkhior | So I'm guessing the bracket is an issue | 12:35 |
Melkhior | nothing serious (I can just add a list of extra files in the platform.toolchain and specify that in my platform), just wondering what the 'proper' way was, if any | 12:36 |
Melkhior | Also trying to make usable by third-parties, so the fewer patches to Litex the better :-) | 12:37 |
Melkhior | As for the delay, the bus is just 25 MHz (technically, anything between 16.67 and 25), so the Artix-7 has no problem with timings | 12:39 |
Melkhior | (those timings constraints are probably overkill... didn't know better so I did everything by-the-book ... ISBN 9781461229421 to be accurate ;-) ) | 12:42 |
pftbest | Melkhior: try to escape the braces with the double, for example instead of "{SBUS_3V3_D[1]}" use "{{SBUS_3V3_D[1]}}" | 12:50 |
Melkhior | already done :-) | 12:51 |
Melkhior | sorry I copy / pasted from the source file, not the exact line I feed to the tool :-( | 12:51 |
Melkhior | _florent_: just realized I had a typo, I was only replacing *some* curly braces :-( | 12:52 |
Melkhior | Trying again | 12:52 |
Melkhior | Hehe, always ask an expert; with all the curly braces properly duplicated, it seems to work | 12:54 |
sajattack[m] | Any ideas why my PCIe UART xover serial boot keeps getting stuck at 99% | 12:54 |
Melkhior | thanks ! | 12:54 |
_florent_ | sajattack[m]: is if with litex_term or your own code? | 13:00 |
sajattack[m] | Any ideas why my PCIe UART xover serial boot keeps getting stuck at 99% | 13:00 |
sajattack[m] | Oops | 13:00 |
sajattack[m] | It's with litex_term | 13:00 |
sajattack[m] | And a modified litex_server using address 0 instead of 0xf0000000 | 13:04 |
sajattack[m] | I also tried wishbone-tool at zyp's suggestion but it didn't work and I found an issue mentioning they don't support the upload protocol yet | 13:06 |
sajattack[m] | it just sits at 99 until I spam enter about 10 times and then it crc errors | 13:09 |
sajattack[m] | waited probably 45m-1h at 99 | 13:10 |
_florent_ | ok, can you try to set sfl_outstanding to 0?: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_term.py#L208 | 13:12 |
_florent_ | you can also try to increase the delay here: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_term.py#L322 | 13:13 |
sajattack[m] | ok, it'll be about half an hour until I have a result | 13:13 |
_florent_ | it takes that long? | 13:14 |
*** yosys-questions <[email protected]> has joined #litex | 13:14 | |
sajattack[m] | yeah | 13:14 |
_florent_ | to validate things, maybe try to load small binaries | 13:14 |
sajattack[m] | got anything handy? | 13:15 |
_florent_ | just try to send any small random file you have on your computer, just to see it's able upload correctly | 13:15 |
_florent_ | at least if it passes the 99% | 13:15 |
sajattack[m] | yeah it uploaded a 192 byte bash script just fine | 13:17 |
sajattack[m] | the opensbi.bin is optional right? | 13:18 |
tnt | I don't think so. | 13:19 |
tnt | You need a machine mode "bios" and opensbi provides that in recent linux-on-litex. | 13:20 |
sajattack[m] | ok I'll try sticking that in there then | 13:21 |
sajattack[m] | maybe it was getting stuck looking for that file | 13:21 |
sajattack[m] | it seems happier now | 13:48 |
sajattack[m] | and it reports 4KB/s | 13:49 |
sajattack[m] | yey https://hastebin.com/holemakuge.yaml | 14:06 |
tpb | Title: hastebin (at hastebin.com) | 14:06 |
sajattack[m] | well that was an amusing diversion | 14:06 |
* sajattack[m] uploaded an image: (294KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/vCVEPVDTqNxAatCMHitnWcXR/image.png > | 14:15 | |
Melkhior | <sajattack[m]: congrats! nice to have 1 GiB for Litex :-) Presumably the FPGA is big enough for several cores, to justify the memory :-) | 14:30 |
sajattack[m] | yes | 14:30 |
Melkhior | BTW, if you don't have a 'better' way than serial to load the binaries, the 'C' extension will save a lot of space in Buildroot and is fine in VexRiscv | 14:31 |
sajattack[m] | better to have motivation to develop an improved pcie loader :) | 14:32 |
Melkhior | (better == microsd for non-memory-based root, == ethernet for memory-based root) | 14:32 |
Melkhior | hehe, yes PCIe would be 'better' | 14:32 |
sajattack[m] | well it is pcie at the moment | 14:33 |
sajattack[m] | it's just slow as balls uart pcie | 14:33 |
sajattack[m] | rather than dma pcie | 14:33 |
Melkhior | 4 KiB is small though, you can get more than that - I was getting 20+ KiB/s with an old BeagleBone White as the data source | 14:33 |
Melkhior | Oh, OK, thought it would be a 'regular' uart | 14:34 |
Melkhior | this explains that | 14:34 |
sajattack[m] | this is a 200kLUT board 🤣 https://hastebin.com/otaguvukun.rb | 14:39 |
tpb | Title: hastebin (at hastebin.com) | 14:39 |
sajattack[m] | oh wait that was the wrong one | 14:40 |
Melkhior | I can fit 4 VexRiscv RV32IMACFDBK comfortably in an Artix-7 100T, you should be able to reach the 8 HARTs limit easily :-) | 14:40 |
sajattack[m] | I thought it was too low | 14:40 |
sajattack[m] | maybe this is actual usage https://hastebin.com/jiyilebeqi.rb | 14:42 |
tpb | Title: hastebin (at hastebin.com) | 14:42 |
sajattack[m] | I don't understand the logs very well | 14:42 |
sajattack[m] | ok I will try 8 core next | 14:43 |
Melkhior | depends on your use case I guess, I recompiled a bunch of stuff (to test the B and K extension I had added) so more cores were better | 14:48 |
Melkhior | 2 or 4 has been tested a lot ... 8 might be much less charted territory | 14:49 |
sajattack[m] | I don't really have a use case | 14:53 |
sajattack[m] | I'm just goofing around | 14:53 |
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 14:57 | |
*** yosys-questions <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 14:59 | |
_florent_ | sajattack[m]: congrats :) | 15:01 |
sajattack[m] | thanks | 15:01 |
_florent_ | sajattack[m]: the upload is still very slow | 15:01 |
sajattack[m] | it was all your hard work :P | 15:01 |
sajattack[m] | yes | 15:01 |
_florent_ | have you finally changed litex_term parameters? | 15:02 |
sajattack[m] | I changed the sfl_outstanding | 15:03 |
sajattack[m] | should I change the other one too? | 15:03 |
_florent_ | ok, since you'll have to pay the PCIe latency for each frame, maybe you could to increase it now that you got a first version working | 15:04 |
_florent_ | have you also increased the delay? | 15:04 |
sajattack[m] | ok | 15:04 |
sajattack[m] | I haven't yet | 15:04 |
_florent_ | BTW, I want to add an auto-calibration for these parameters but haven't had time yet | 15:05 |
sajattack[m] | should I increase the payload length too? | 15:05 |
_florent_ | not yet | 15:05 |
sajattack[m] | 1e-4 a good delay? | 15:05 |
_florent_ | you can try it and then increase sfl_outstanding to 2, 4, 8, etc... | 15:06 |
_florent_ | when increasing sfl_outstanding fails, try to increase the delay | 15:07 |
_florent_ | I think you should be able to get almost equivalent speed than with USB FIFOs (400-500KB/s) | 15:08 |
_florent_ | BTW once you have something you are happy with, would you mind filling an issue to summarize the changes you made? This way I'll make sure to address the issues | 15:09 |
sajattack[m] | sure | 15:09 |
_florent_ | thanks | 15:12 |
sajattack[m] | any sfl_outstanding greater than 0 causes it to get stuck at 99 | 15:23 |
_florent_ | ok, I'll try to do some tests | 15:37 |
sajattack[m] | my best results are 0-delay, 0-outstanding, 255 payload | 15:50 |
sajattack[m] | still only 8KB/s though | 15:50 |
sajattack[m] | I'll try using a non-hipster kernel | 15:52 |
sajattack[m] | maybe some of my tickless bullshit is breaking it | 15:52 |
sajattack[m] | that gets it up to 10 | 15:59 |
*** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 16:30 | |
*** yosys-questions <[email protected]> has joined #litex | 16:32 | |
jevinskie[m] | sajattack: do you happen to be using this alinx atrix board? I’ve been meaning to bring up litex on it for the last month since I’ve had it http://www.alinx.com/en/index.php/default/content/124.html | 17:25 |
tpb | Title: [AX7A200] XILINX Artix-7 XC7A200T FPGA Development Board A7 SoMs - Artix-7 - ALINX Electronics Technology (Shanghai) Co., Ltd. (at www.alinx.com) | 17:25 |
jevinskie[m] | _florent_: Sorry about the noise, I ran the BIST again on the arty to get the logs for you and it passed fine. My brain and workstation were cluttered yesterday trying to clean up my diffs against upstream so I must have mixed something up. | 17:57 |
jevinskie[m] | I managed to get BIST to pass on the arty at 200 MHz sys_clk for a peppy 1600 MT/s at CL 8 for about 1850 MB/s read! | 17:58 |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Remote host closed the connection) | 18:09 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 18:10 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Ping timeout: 240 seconds) | 18:14 | |
*** yosys-questions <[email protected]> has quit IRC (Quit: Client closed) | 18:44 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 19:08 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Ping timeout: 252 seconds) | 19:12 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 19:32 | |
_florent_ | jevinskie[m]: nice! So we still have some margin at 800MT/s (which is already > to the specified 667MT/s :) ) | 19:44 |
*** lkcl <[email protected]> has quit IRC (Quit: BNC by #bnc4you) | 19:50 | |
*** bjonnh <bjonnh!~jo@about/aquilenet/bjonnh> has joined #litex | 19:51 | |
bjonnh | I'm considering buying a board to start playing with FPGA and DSPs for audio | 19:51 |
bjonnh | https://digilent.com/shop/zybo-z7-zynq-7000-arm-fpga-soc-development-board/ | 19:51 |
tpb | Title: Xilinx Zynq-7000 SoC Development Board - Digilent Zybo Z7 (at digilent.com) | 19:51 |
bjonnh | would that do? | 19:51 |
bjonnh | (I want a fully open workflow if possible) | 19:52 |
bjonnh | or is that overkiil | 19:52 |
*** lkcl <[email protected]> has joined #litex | 20:05 | |
*** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 252 seconds) | 20:36 | |
jevinskie[m] | You might want a non-zynq part so you don’t have the additional complexity of the hard processors | 20:41 |
sajattack[m] | <jevinskie[m]> "sajattack: do you happen to be..." <- nope, I'm using acorn_cle_215 | 21:08 |
bjonnh | can't you just ignoret he arm part? | 21:22 |
*** yosys-questions <[email protected]> has joined #litex | 21:37 | |
jevinskie[m] | bjonnh: I’m not familiar with Xilinx personally but read that you have to boot the arm to load the PL bitstream (while altera SoCs can be configured to boot only the fpga side) | 21:52 |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Read error: Connection reset by peer) | 22:53 | |
sajattack[m] | I made an 8 core rv32gc with 8 fpus and when I try to lxterm into it my pc reboots 😂 | 23:09 |
sajattack[m] | oh I also gave it l2 cache | 23:10 |
sajattack[m] | but I don't think that matters | 23:10 |
sajattack[m] | I think maybe it was just a bad flash | 23:12 |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 23:19 | |
sajattack[m] | Hmm, reflashed, still not happy | 23:38 |
sajattack[m] | Maybe I'll go down to 4 fpus | 23:39 |
jevinskie[m] | Need a pcie firewall :P | 23:42 |
tpw_rules | i have not ben having much luck with cle-215 | 23:50 |
tpw_rules | it's inconsistent and unstable | 23:50 |
tpw_rules | no pcie weirdness, but it only works on some syntheses | 23:50 |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 23:51 | |
*** TMM_ <[email protected]> has joined #litex | 23:51 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!