| *** tpb has joined #litex | 00:00 | |
| shuffle2 | daveshah: fwiw seems the syn_preserve is injected because of FX681 :...|Initial value on register arp_table_request_timer_count[23:0] is non-zero which can prevent the register from being packed into a block RAM or DSP. (occurs for a few other registers in ip/mac stack as well) | 00:14 |
|---|---|---|
| shuffle2 | seems migen emits the initial value as an initial assignment in addition to putting it in the reset block, is it worthwhile to avoid that? | 00:15 |
| shuffle2 | i had left the udp_loopback example in with my own logic, and the loopback path is what was causing timing failures (mostly because of this deoptimization, i'm thinking) | 00:17 |
| *** CarlFK has quit IRC | 00:21 | |
| *** Skip has quit IRC | 00:32 | |
| *** CarlFK has joined #litex | 00:33 | |
| shuffle2 | eh, is there any good way to do it? after some trial/error, seems like any nonzero value assigned in initial _or_ reset will cause synplify to warn/inject syn_preserve :( | 00:44 |
| shuffle2 | strange ive never seen it on the rather sizable amount of other (native) verilog im pushing through synplify | 00:44 |
| *** futarisIRCcloud has quit IRC | 01:01 | |
| benh | what would it take to make litex add a default_nettype wire to generated files ? | 01:10 |
| benh | serv is setting it to none, and litedram breaks | 01:10 |
| benh | (depending on order files are built by vivado, as it incorrectly carries the default from file to file) | 01:11 |
| benh | that or make litex use explicit wire in the module generated | 01:11 |
| *** futarisIRCcloud has joined #litex | 02:19 | |
| *** HoloIRCUser has joined #litex | 02:53 | |
| *** HoloIRCUser2 has joined #litex | 02:54 | |
| *** HoloIRCUser1 has quit IRC | 02:55 | |
| *** HoloIRCUser has quit IRC | 02:57 | |
| *** Degi has quit IRC | 03:44 | |
| *** Degi has joined #litex | 03:44 | |
| shuffle2 | changing liteeth\examples\targets\udp_loopback\versa_ecp5.py to target ecp5um (instead of ecp5um5g) causes the timing issue on the plain example, as well. suppose that's why no one has noticed it until now | 06:21 |
| shuffle2 | same size/speed otherwise, kinda curious :s | 06:37 |
| *** HoloIRCUser has joined #litex | 06:53 | |
| *** HoloIRCUser2 has quit IRC | 06:57 | |
| *** zyp_ has joined #litex | 07:06 | |
| *** zyp has quit IRC | 07:09 | |
| *** captain_morgan has quit IRC | 07:09 | |
| *** palmer has quit IRC | 07:09 | |
| *** goran-mahovlic_ has quit IRC | 07:09 | |
| *** kbeckmann has quit IRC | 07:09 | |
| *** captain_morgan has joined #litex | 07:16 | |
| *** palmer has joined #litex | 07:16 | |
| *** goran-mahovlic_ has joined #litex | 07:16 | |
| *** kbeckmann has joined #litex | 07:16 | |
| _florent_ | benh: you could probably do some tests by modifying https://github.com/enjoy-digital/litex/blob/master/litex/gen/fhdl/verilog.py | 07:21 |
| tpb | Title: litex/verilog.py at master · enjoy-digital/litex · GitHub (at github.com) | 07:21 |
| _florent_ | shuffle2: we indeed have to optimize the timings of the LiteEth hardware stack on ECP5, it has been developed mostly for 7-series but hasn't been optimized yet for slower devices. | 07:27 |
| *** HoloIRCUser1 has joined #litex | 07:44 | |
| *** HoloIRCUser has quit IRC | 07:46 | |
| benh | Hrm ... standalone litedram with serv instead of vexriscv is smaller ... but also doesn't quite work :-) | 08:00 |
| benh | anything special to do other than including all the serv rtl verilog files in the project ? It builds, I get the banner but .. | 08:01 |
| benh | ah wait.. it comes up eventually but extremely slowly | 08:01 |
| benh | BIOS built on May 5 2020 11:15:21 | 08:01 |
| benh | it stops after that for a long time] | 08:01 |
| benh | then | 08:01 |
| benh | BIOS CRC failed (expected 000000000000000000, got 000000000000000000) | 08:01 |
| benh | The system will continue, but expect problems. | 08:01 |
| benh | and the RAM init seems to fail | 08:02 |
| _florent_ | benh: yes, since SERV is a lot slower, that's possible we need to modify the BIOS a bit to speedup the initialization | 08:02 |
| _florent_ | benh: are you sure all the BIOS files have been recompiled for SERV (and you are not using old VexRiscv ones?) | 08:03 |
| _florent_ | benh: be sure to remove the software build directory when switching CPU | 08:04 |
| benh | _florent_: I think so, but I'll dbl check. I'm using fusesoc so it should be clean but ... | 08:04 |
| benh | I'll try to build a LiteX one to compare, this is microwatt + standalone litedram with built-in serv for inits (works fine with VexRiscV mini) | 08:04 |
| _florent_ | benh: ok, at least i remember having this issue in simulation when testing lxsim --cpu-type=vexriscv and then lxsim --cpu-type=serv without removing the build directory | 08:15 |
| *** HoloIRCUser2 has joined #litex | 08:23 | |
| *** HoloIRCUser1 has quit IRC | 08:26 | |
| benh | _florent_: ok, let me just build a standard LiteX SoC from scratch with serv see what happens... | 08:34 |
| benh | ERROR: [Synth 8-6735] net type must be explicitly specified for 'serial_rx' when default_nettype is none [/home/benh/hackplace/litex/litex-boards/litex_boards/targets/soc_basesoc_arty/gateware/top.v:6] | 08:35 |
| benh | :-) | 08:35 |
| benh | You need to fix the problem I mentioned above :) | 08:35 |
| benh | it's a Vivado bug but you know how long it takes Xilinx to fix anything ... | 08:35 |
| benh | fusesoc sets the default_nettype to none at the top of each .v file, vivado "carries" it over to the next file, and thus applies it to the litex generated ones who then fail to build | 08:36 |
| daveshah | That's the Verilog standard afaik | 08:36 |
| benh | so you can have either litex use explicit "wire" in module defs | 08:36 |
| daveshah | Nothing to do with Vivado | 08:36 |
| benh | daveshah: to carry it over to subsequent .v files ? | 08:36 |
| daveshah | Yes | 08:36 |
| benh | Odd ... I've read otherwise but maybe I'm wrong, I haven't read the standard | 08:37 |
| benh | it sounds very bogus to have a compiler carry such definitions to another compile unit | 08:37 |
| daveshah | There is an ambiguity as to whether default_nettype requires wire in "input wire" but I'm pretty sure the conclusion was it is | 08:37 |
| benh | so the fix here is either to make litex slaps a default_nettype back to wire on top of every generated .v file | 08:37 |
| benh | or use explicit "wire" in module definitions | 08:38 |
| benh | for now I'm just hacking serv to reset the nettype to wire at the end of each file as a temporary workaround | 08:38 |
| benh | _florent_: ok with the workaround above, serv based SoC comes up, inits RAM fine, not entirely sure what's wrong, I'll dig a bit more | 08:42 |
| _florent_ | benh: for the default_nettype, can you create an issue on LiteX repo with a minimal example to reproduce it? | 08:45 |
| *** futarisIRCcloud has quit IRC | 08:49 | |
| benh | _florent_: well, just checkout litex, try ./arty.py --cpu-type=serv :-) | 08:52 |
| benh | with Vivado 2019.2 | 08:52 |
| benh | but yes, I can | 08:52 |
| benh | odd... serv is working now | 08:52 |
| benh | though its bus is so slow, the memory test is taking minutes | 08:52 |
| benh | the init per se is quick, the memory test is useless | 08:52 |
| benh | it's somewhat odd actually... | 08:53 |
| benh | Memtest OK | 08:54 |
| benh | Memspeed Writes: 10Mbps Reads: 16Mbps | 08:54 |
| benh | _florent_: what's the licence on LiteX generated .v files & binaries ? | 08:55 |
| benh | _florent_: for standalone litedram, the generator I did is too awkward for most users, they would have to install litex, it breaks when you change thinggs etrc... I'd like to ship pre-generated .v files and BIOS images with microwatt along with the scripts to re-generate | 08:55 |
| *** zyp_ is now known as zyp | 09:08 | |
| _florent_ | benh: that's the aim of the generators: allow users to easily reuse pre-generated cores without having to install/understand LiteX. The license is similar to LiteX (BSD-2) | 09:14 |
| benh | _florent_: thanks, that's perfect. I'll include some pre-generated stuff with microwatt then. I'll try to get you patches to fix LiteX tonight or tomorrow | 09:16 |
| benh | _florent_: serv does save a few % LUT usage but with the memory test taking minutes, it's not very useful :) | 09:17 |
| benh | _florent_: so I'll stick to built-in VexRiscV "Min" for now ... | 09:18 |
| _florent_ | benh: the idea is to reduce the memtest size or do something more clever to speed up init with SERV | 09:18 |
| _florent_ | benh: what difference do you have in resource usage between VexRiscV Min and SERV? | 09:19 |
| benh | _florent_: with the whole of microwatt I go from about 51% slice LUT down to 48% from memory | 09:34 |
| benh | _florent_: and a couple % down on registers as well | 09:34 |
| benh | I'd have to rebuild later if you want precise numbers, that's what I remember from earlier | 09:35 |
| benh | it's not huge at this point (on the Arty 35) | 09:35 |
| benh | _florent_: the standalone sdram init seem to hang with VexRiscV_Mini compared to VexRiscV | 09:49 |
| benh | _florent_: not sure what's up at this point... I did clean up build cache etc... | 09:49 |
| benh | same as before with serv, I get the banner and it stops after "BIOS built xxxx" | 09:50 |
| benh | it's odd ... I would swear it worked yesterday... ugh | 09:54 |
| zyp | how fast are you running serv? I assume it'll have on the order of 1/32th the performance per clock compared to vexriscv | 09:54 |
| _florent_ | benh: i also remember having some hang with VexRiscv mini but haven't intestigated it | 09:55 |
| _florent_ | investigated | 09:55 |
| benh | I wonder if I'm building the BIOS with the wrong options... | 09:56 |
| sorear | someone has found an actual use case for serv? | 09:56 |
| benh | sorear: it would be nice for initializing litedram "standalone" just bcs it's small ... | 09:56 |
| benh | yup ! | 09:57 |
| benh | -march=rv32im | 09:57 |
| benh | litedram_gen doesn't pass the variant down so core.py assumes a full vexriscv | 09:58 |
| benh | unless I can specify it in the yaml, I need to dig | 09:58 |
| zyp | sorear, I figure it could be nice for running the software part of a usb stack in applications that otherwise wouldn't need a cpu | 09:59 |
| zyp | without having to handle control requests in gateware | 10:00 |
| benh | _florent_: ah ! litedram gen.py need to collect cpu_variant from the yaml | 10:02 |
| benh | and pass it down | 10:02 |
| benh | let me work around and see if that helps | 10:03 |
| benh | I | 10:14 |
| benh | I'll send you a patch if it does | 10:14 |
| benh | _florent_: works now. However, it takes several seconds to do the memory test which is a bit nasty | 10:18 |
| *** lambda has quit IRC | 10:30 | |
| benh | _florent_: so ppc64 needs custom CSR access functions... where should i put them ? | 10:31 |
| benh | _florent_: I'd rather not add special ifdef's in hw/commmon.h... I could define CSR_ACCESSORS_DEFINED | 10:32 |
| benh | _florent_: is there an include file in cpu/ that's force-included before anything else ? | 10:32 |
| *** lambda has joined #litex | 10:34 | |
| benh | oh my ... csr accessors in common.h are ghastly | 10:35 |
| _florent_ | benh: i just tried to avoid any CPU specific code in the BIOS, so if possible, the custom functions should be put in the CPU directory. If this is not possible with the current structure, we could think about that | 10:37 |
| benh | _florent_: right, we might need cpu specific include that goes before anything else | 10:40 |
| benh | _florent_: also I really really really don't like how we access CSRs today :) | 10:41 |
| benh | doing unsigned long* accesses regardless of the size of the CSR for example | 10:41 |
| benh | and the csr_rd_* etc... casting integers into pointers etc... it's all rather gross | 10:42 |
| benh | finally _csr_rd always doing a 64-bit access is somewhat of a nonsense | 10:42 |
| benh | on 32-bit cpus with 8 bit CSR bus that means 2x32-bit bus accesses per byte of the CSR ! | 10:43 |
| _florent_ | benh: the one you are looking at are probably the one in common.h that are purposed to be the most generic, the bios is generating specialized CSR access functions in csr.h | 10:43 |
| benh | _florent_: anyways, sent you 2 patches to get microwatt going for now | 10:43 |
| benh | _florent_: yup | 10:44 |
| benh | _florent_: though the generic ones should be written more nicely too :) but before hacking that to death | 10:44 |
| _florent_ | benh: thanks for the patch, i already integrated your suggestions /findings yesterday for MicroWatt: https://github.com/enjoy-digital/litex/commit/9bef218ad6616d4d8b958e34de1f6e87b7cbdd99 | 10:44 |
| tpb | Title: cpu/microwatt: fix integration/crt0.S (thanks Benjamin Herrenschmidt). · enjoy-digital/litex@9bef218 · GitHub (at github.com) | 10:44 |
| benh | _florent_: I suppose we should first decide whether to ditch 8-bit CSR busses | 10:44 |
| benh | and stick to 32-bit and no funny games of CSR sizes | 10:44 |
| benh | bcs that would simplify things quite a bit | 10:44 |
| benh | _florent_: oh, oops, I didn't re-pull today :) | 10:45 |
| benh | _florent_: I also sent you a patch to litedram gen.py to grab the cpu variant | 10:45 |
| benh | _florent_: so MW will still break once we take out the hack to treat c******* as cache-inhibited and start requiring the use of the special instructions (or the MMU) | 10:45 |
| benh | _florent_: that's what we need to fix CSR accesses for | 10:45 |
| benh | so there's a bit of time, the hack can stay for a while | 10:46 |
| benh | so I'd rather you guys decide what to do with CSRs long run and whether to ditch those funky variable sizes things alltogether or not before I start hackign through it :) | 10:46 |
| *** CarlFK has quit IRC | 10:49 | |
| _florent_ | benh: what we could do is switching to 32-bit CSR as default and see if we need to keep 8-bit CSR for retro-compatibility or just remove it. Even if 8-bit is still supported, we could still add some restrictions for it it to simplify things (ie would not be supported by Linux SoCs for example) | 10:50 |
| benh | _florent_: hrm... I would still like to gget rid of the mess in hw/common.h but ok :) | 10:51 |
| benh | _florent_: at least we should probably make the generic _csr_rd/wr use the _simple ones and have only those latter be in ifdef CSR_ACCESSORS_DEFINED | 10:52 |
| benh | _florent_: so things like microwatt only need to redefine the simple read/write | 10:52 |
| benh | the generated csr.h is already just using csr_simple_read/write | 10:53 |
| benh | so that's fine | 10:53 |
| _florent_ | benh: yes, we can try to have a simple solution for that. A few months ago, not all design were able to work with 32-bit CSR, for example being able to do the DRAM calibration with 32-bit CSR is a few months old | 10:54 |
| zyp | even more of a reason to standardize on one CSR size | 10:56 |
| _florent_ | benh: so for you it seems to be a mess now, but it's because there is some history and because we worked hard to make 32-bit CSR possible and work on all designs | 10:57 |
| benh | _florent_: of course, I apologise if I come accross a bit more rude that I intend ... | 10:58 |
| benh | I've written my share of mess over time :) | 10:58 |
| _florent_ | benh: no problem, but it's just that supporting both is probably temporary and now that all designs can use 32-bit CSR and since it also seem to be ok on resource usage, we can now discuss to see if we should keep 8-bit support | 10:59 |
| benh | tbh my main nitpick for the general case (not specifically linux) is the structure of the helpers in common.h ... the fancy _csr_rd/wr ones should be built on top of the "basic" ones and there should thus be only one pair of "basic" ones that do the actual HW access with the right size | 10:59 |
| benh | and which can then be easily overriden if a CPU needs extra nits such as memory barriers or special IO instructions | 10:59 |
| benh | and thus CSR_ACCESSORS_DEFINED would allow to re-define just those two (ie csr_simple_*) and the rest would just build on top... not hard, I could give it a go myself but not tonight | 11:00 |
| benh | ok | 11:00 |
| _florent_ | benh: we are open to suggestions/ideas and if using 32-bit CSR work for all projects and simplify things, that's probably what we'll do | 11:03 |
| *** CarlFK has joined #litex | 11:05 | |
| benh | _florent_: yup | 11:08 |
| benh | all good | 11:09 |
| benh | btw, I need the litedram patch I sent you merged for microwatt generator to work with vexriscv_min | 11:09 |
| benh | (to specify cpu_variant) | 11:09 |
| benh | I haven't yet figured out how to fix litedram gen for cpu type "None", that's for another day, it seems more intricate | 11:10 |
| benh | sso for now microwatt+litedram will use vex | 11:10 |
| _florent_ | ok, i'll going to apply your patch | 11:12 |
| _florent_ | i'm | 11:12 |
| benh | thanks ! | 11:13 |
| shuffle2 | _florent_: seems you're the main author of the ecp5 pll code in litex? https://gist.github.com/shuffle2/f102897f100ab4b5995720c9214bda32 see anything concerning in the diff between litex/clarity? | 11:43 |
| tpb | Title: pll.v · GitHub (at gist.github.com) | 11:43 |
| somlo | benh: as the person to blame for the common.h "ghastliness", using [] indexing on an `unsigned long *` in `_csr_[rd|wr]` felt more expressive than `MMPTR(a)` or calling `csr_[read|write]_simple()`. Besides, those were (re)added for backward compatibility with externally written bios code by downstream. And they had to support multiple (8/16/32) subregister data widths, all of which were aligned at either 32 or 64 bits, depending on the CPU. And try to | 11:45 |
| somlo | glue them back into 8, 32, 64, 128, etc. bit wide "compound" registers :) | 11:45 |
| somlo | so if you want to apply some additional awesomeness to that ghastly mess, I'm super excited to learn how one would do it better! | 11:45 |
| benh | heh | 11:58 |
| benh | somlo: it's hard to write that sort of stuff without ending up with a mess ;-) Look at the MMIO accessors in Linux ... | 11:58 |
| _florent_ | somlo: you are the one we should thanks for allowing 32-bit CSRs to be used in all designs :) Most of the mess probably comes from the various configurations that need to be supported which make things complicated, as discussed just before, if limiting the configurations can help simplifying things, we should probably go in this direction | 11:59 |
| benh | somlo: I'll do some suggestions when I'm not about to fall asleep. The key thing though is that you really want to isolate the functions that do the actual HW access and have as few of these as possible | 11:59 |
| benh | somlo: and build the other "fancier" stuff on top of these. The reasons come from a number of factors such as the need for CPU specific memory barriers or even special instructions to do that type of MMIO access | 12:00 |
| benh | somlo: for example ARM and powerpc in theory need memeory barriers. I suppose none of the CPUs supported by LiteX today really re-order accesses but that's not an impossibility :) | 12:00 |
| benh | somlo: or you could end up with x86 style split IO bus with inb/outb style instructions (yuck ,.. but heh, they do exist) | 12:01 |
| benh | somlo: also I would strongly suggest keeping the address argument as a pointer all along | 12:01 |
| benh | anyway, off to bed ! | 12:01 |
| somlo | benh: good night, sleep tight -- talk again tomorrow :) | 12:03 |
| somlo | _florent_: of course, if we *do* get rid of 8/16 bit csr data widths and go with 32 exclusively, we can totally simplify that crazy setup in common.h (but that almost feels like cheating now after all the hardship) :D :D | 12:04 |
| somlo | (not that I'm against simplifying things in any way, and 32-bit-only csr-data-width is probably the right thing to do) | 12:04 |
| _florent_ | shuffle2: i wrote the ECP5 PLL code yes (mostly reading the docs and testing on hardware) but haven't really compared it to clarity results, so if you find obvious improvements, we could integrate them | 12:07 |
| _florent_ | somlo: i think for now what we can do is: default to 32-bit, only support 32-bit on Linux SoC (if that can simplify upstreaming the Linux patches) and keep support for the other CSR data-width until we are sure that 32-bit work fine for all configurations and that keeping others configuations is not useful. So i will change the default to 32-bit and see if we have complains :) | 12:12 |
| *** futarisIRCcloud has joined #litex | 12:14 | |
| *** gregdavill has joined #litex | 13:06 | |
| gregdavill | benh: fyi, serv doesn't have a hardware multiplier. So you need to compile with -march=rv32i. | 13:07 |
| gregdavill | Also this is the same reason memory tests are slow. For standard tests the "random" generator is multiplying some numbers. Which needs to be emulated in sw. | 13:09 |
| gregdavill | Which on a serial CPU where everything is *32 clocks, will be slower than Vex. | 13:09 |
| zyp | shuffle2, looks to be 100 / 1 * 5 / 4, vs 100 / 4 * 5 / 1, end result is the same, difference is just in whether the division happens before or after the VCO | 13:11 |
| zyp | although, according to the ECP5 datasheet, the config from clarity falls outside the f_VCO range specced in the datasheet (400-800 MHz) | 13:12 |
| shuffle2 | the ui actually says the vco is 625mhz | 13:13 |
| zyp | oh, my bad | 13:14 |
| zyp | hmm, no, that doesn't add up | 13:15 |
| *** gregdavill has quit IRC | 13:15 | |
| zyp | ah, yes it does, the clarity config is 100 / 4 * 5 * 5 for the VCO and / 5 for the output | 13:18 |
| shuffle2 | ah | 13:19 |
| zyp | I'm still unused to this pll structure, I forgot that the feedback path runs through both the CLKOx_DIV and CLKFB_DIV, so you get a 25x multiplication, not 5x | 13:20 |
| zyp | anyway, both configs are within the legal ranges then | 13:21 |
| zyp | 100 / 1 * 5 / 4 vs 100 / 4 * 25 / 5 | 13:22 |
| zyp | _florent_, I also found the answer now to the question we were discussing some weeks ago on CLKI range | 13:23 |
| zyp | f_PFD is the frequency after the CLKI_DIV, has a specified range of 10-400 MHz, so the 10MHz minimum is indeed after dividing | 13:24 |
| zyp | although the datasheet also mentiones that «For f_PFD < 10 MHz, the jitter numbers may not be met in certain conditions.» | 13:25 |
| zyp | which sounds to me like «you can go lower, but we can't give guarantees about jitter then» | 13:26 |
| _florent_ | zyp: thanks, in your case allowing a lower frequency was enabling you to generate the 48MHz with a single PLL right? | 13:39 |
| zyp | yes, it's been working fine so far | 13:40 |
| _florent_ | zyp: ok so that could be interesting to keep this, or at least allow it and create a warning if CLKI is bellow the specified range | 13:43 |
| *** Skip has joined #litex | 14:58 | |
| *** spacekookie has quit IRC | 15:17 | |
| *** spacekookie has joined #litex | 15:18 | |
| somlo | _florent_: after b0578580 (litex) and da61aab (litex-boards) if I try to build a rocket+litex design (on either nexys4ddr or trellisboard), it just stops after building the bios and never goes into vivado (or, respectively, yosys/nextpnr) | 16:26 |
| somlo | no error, just declares victory once the bios is compiled :) | 16:26 |
| _florent_ | somlo: indeed, you now have to add --build to build the gateware | 16:26 |
| somlo | aaaah | 16:27 |
| somlo | ok, let me update my bash history :D | 16:27 |
| somlo | (I just up-arrow and hit enter, if things don't work the way I expect then I start asking :D ) | 16:27 |
| somlo | _florent_: thanks, I'm back in business now :) | 16:30 |
| somlo | _florent_: does that also apply to litex_sim.py ? I'm actually updating my notes, not just .bash_history :) | 16:32 |
| _florent_ | somlo: no, that's only for the targets | 16:32 |
| somlo | ok, thanks! | 16:33 |
| _florent_ | ./target.py now generate the software generated files, compile the BIOS and generate the gateware files | 16:33 |
| _florent_ | --build build the bitstream | 16:33 |
| _florent_ | --load load the bistream | 16:33 |
| somlo | oh, so if I had tried to dig around the build folder, I would have found the verilog file there :) | 16:33 |
| somlo | it's just running the toolchain that's now an explicit command-line flag | 16:34 |
| somlo | got it! | 16:34 |
| _florent_ | i did that for project external to LiteX and found that more convenient | 16:34 |
| zyp | nice, I like that change | 16:34 |
| _florent_ | this way, if you just want to work on software, you just generate the files but don't build the gateware | 16:35 |
| _florent_ | and if you want to load bitstream to the FPGA, you no longer need external script | 16:35 |
| somlo | I have to try openocd on nexys4ddr -- so far I've been loading the .bit file to the sdcard, and had the nexys set up to load it from there | 16:36 |
| somlo | but "tethered" mode via usb cable is much better for development | 16:37 |
| daveshah | I can recommend xc3sprog | 16:37 |
| zyp | I've been thinking it'd be nice to have some sort of change tracking as well, as in --load would rebuild the gateware only if it changed | 16:37 |
| daveshah | Despite the name it supports a lot of xc7 devices etc | 16:37 |
| somlo | zyp: that's something we should at least try to use `make` for, before rolling our own :D | 16:38 |
| zyp | somlo, well, I were thinking instead of reimplementing it from scratch, maybe we could reuse parts of scons | 16:39 |
| _florent_ | somlo: which version of GCC are you using to compile https://github.com/litex-hub/linux? | 16:55 |
| tpb | Title: GitHub - litex-hub/linux: Linux kernel source tree (at github.com) | 16:55 |
| _florent_ | (i'm trying to build the Linux-On-LiteX-Vexriscv kernel with the branches from https://github.com/litex-hub/linux) | 16:56 |
| tpb | Title: GitHub - litex-hub/linux: Linux kernel source tree (at github.com) | 16:56 |
| *** HoloIRCUser has joined #litex | 17:36 | |
| *** HoloIRCUser2 has quit IRC | 17:38 | |
| *** captain_morgan has quit IRC | 19:36 | |
| *** captain_morgan has joined #litex | 19:37 | |
| *** CarlFK has quit IRC | 19:38 | |
| *** robert2 has joined #litex | 19:48 | |
| *** robert2 is now known as rw1nkler | 19:48 | |
| somlo | _florent_: it's `riscv64-unknown-linux-gnu-gcc (GCC) 9.2.0` | 19:59 |
| john_k[m] | anyone know what FPGA is on this card? https://www.ebay.com/itm/ACCOLADE-ANIC-40K-QUAD-PORT-10GBE-10GB-PCI-E-SFP-ETHERNET-FULL-PACKET-CAPTURE/254574845178 | 20:08 |
| tpb | Title: ACCOLADE ANIC-40K QUAD PORT 10GBE 10GB PCI-E SFP+ ETHERNET, FULL PACKET CAPTURE | eBay (at www.ebay.com) | 20:08 |
| john_k[m] | ANIC-40Ku has a Kintex Ultrascale | 20:09 |
| john_k[m] | guessing maybe a Kintex? For $80 I grabbed one | 20:10 |
| daveshah | Looks like it was released in 2011, so Virtex-6 is a possibility too | 20:19 |
| rw1nkler | Hello Everyone! Please, could somebody provide me any tips about using the wishbone-tool with LiteX? Do I have to instanciate any special core, or simple serial is enough? | 20:34 |
| zyp | rw1nkler, you'll need an instance of UARTWishboneBridge if you wanna use it over serial | 20:43 |
| scanakci | https://usercontent.irccloud-cdn.com/file/dNEH9Kdd/BP_LiteX_Linux_Genesys | 20:46 |
| scanakci | I fixed the final bug. BP works on FPGA! | 20:46 |
| scanakci | I tested it on genesys 2 kintex-7 for 100MhZ. | 20:47 |
| daveshah | Great! | 20:49 |
| sajattack[m] | sweet | 20:50 |
| Finde | scanakci: awesome work!! | 20:50 |
| scanakci | thank you daveshah, sajattack[m], and Finde | 21:02 |
| *** rjeschmi has quit IRC | 21:07 | |
| benh | So it might make sense to replace that random number generator in the memory test with an lfsr for example... | 22:10 |
| benh | I'll have a look. it's also slow with VexRiscV_Min but of course not nearly as bad as serv | 22:10 |
| *** CarlFK has joined #litex | 22:59 | |
| *** rw1nkler has quit IRC | 23:18 | |
| *** darren099 has quit IRC | 23:28 | |
| *** gregdavill has joined #litex | 23:31 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!