| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** nthiel <nthiel!~nthiel@2001:a61:2554:cc01:8c1f:9713:2d70:1650> has joined #litex | 00:38 | |
| *** nthiel <nthiel!~nthiel@2001:a61:2554:cc01:8c1f:9713:2d70:1650> has quit IRC (Ping timeout: 272 seconds) | 00:43 | |
| *** tweakoz <[email protected]> has joined #litex | 01:54 | |
| tweakoz | Is it possible to easily decouple sys_clk_freq from cpu frequency using an MMCM or PLL ? (If I change sys_clk_freq to an integer multiple of the driving oscillator I can get the SOC to build and even boot - but I am pretty sure it is just an illusion as I have to multiply uart connect speed on litex_term times the inverse of the change) | 01:58 |
|---|---|---|
| tweakoz | or maybe it is easier to just drive the whole design from a MMCM or PLL ? | 02:00 |
| tweakoz | I am not sure how to drive sys_clk from PLL or MMCM (if there is an vendor abstract method that would be awesome too). | 02:01 |
| tweakoz | Also - I have this board brought up (minimally - booting bios and communicating via litex_term) : https://www.micro-nova.com/mercury-2 - I can make a pull request when it is a little further along.. | 02:03 |
| tpb | Title: Mercury 2 - Xilinx Artix-7 FPGA development board — MicroNova (at www.micro-nova.com) | 02:03 |
| tweakoz | TLDR of the MMCM/PLL questions - the mercury-2 has a 50mhz oscillator connected to theFPGA - I want to run the litex cpu at some arbitrary speed that is not 50Mhz | 02:13 |
| *** nthiel <nthiel!~nthiel@2001:a61:2554:cc01:170:93ce:ac72:d853> has joined #litex | 02:39 | |
| *** nthiel <nthiel!~nthiel@2001:a61:2554:cc01:170:93ce:ac72:d853> has quit IRC (Ping timeout: 272 seconds) | 02:43 | |
| *** Degi_ <[email protected]> has joined #litex | 02:52 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 02:54 | |
| *** Degi_ is now known as Degi | 02:54 | |
| *** FabM <FabM!~FabM@2a03:d604:101:1200:c4bd:1e46:cbd0:ec12> has joined #litex | 04:04 | |
| *** nthiel <nthiel!~nthiel@2001:a61:2554:cc01:884a:dabc:8eb7:64ab> has joined #litex | 04:30 | |
| *** nthiel <nthiel!~nthiel@2001:a61:2554:cc01:884a:dabc:8eb7:64ab> has quit IRC (Remote host closed the connection) | 04:36 | |
| *** nthiel <nthiel!~nthiel@2001:a61:2554:cc01:884a:dabc:8eb7:64ab> has joined #litex | 04:36 | |
| *** nthiel <nthiel!~nthiel@2001:a61:2554:cc01:884a:dabc:8eb7:64ab> has quit IRC (Client Quit) | 04:36 | |
| *** TMM__ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 04:55 | |
| *** TMM_ <[email protected]> has joined #litex | 04:55 | |
| Melkhior | tweakoz: Using a PLL to drive cd_sys is standard, i.e. look at https://github.com/litex-hub/litex-boards/blob/627408ac81b868cd49be952b8a8c27a9c9a9636c/litex_boards/targets/qmtech_wukong.py#L49-L52 | 05:46 |
| Melkhior | for an Artix-7 example | 05:46 |
| tpb | <https://x0.no/4uy0q> (at github.com) | 05:46 |
| Melkhior | then there is a further 2 PLL to have completely unrelated clocks for the memory idelay and the optional framebuffer | 05:47 |
| *** ewen <[email protected]> has joined #litex | 06:17 | |
| *** Melkhior <Melkhior!~dolbeau@2a01:e0a:1b7:12a0:225:90ff:fefb:e717> has quit IRC (Remote host closed the connection) | 06:40 | |
| *** Melkhior <Melkhior!~Melkhior@2a01:e0a:1b7:12a0:225:90ff:fefb:e717> has joined #litex | 06:59 | |
| *** ewen <[email protected]> has quit IRC (Ping timeout: 264 seconds) | 07:07 | |
| _florent_ | Thanks zyp for the various PRq, I think Greg already merged your LiteHyperbus PR, the LiteSPI PRs also looks good. I'll just do a test in a couple of hours on Artix7/ice40 boards and will merge if also working (will look at it if not). | 07:13 |
| *** ewen <[email protected]> has joined #litex | 07:13 | |
| _florent_ | jevinskie[m]: Your approach for capturing your synchronous serial stream seems fine, you could indeed reuse LiteEthUDPStreamer for that. | 07:16 |
| _florent_ | You just need to provide the destination IP address, UDP port and then pass your stream of data (valid/ready/data), it will stream it over UDP, no need to have a CPU to control it | 07:18 |
| _florent_ | That's indeed what is used in the scope project, there it's connected to the DMA (generating a stream from DRAM data) | 07:19 |
| _florent_ | You could work on the two separate parts of your systems: 1) Capture of your synchronous stream (with a 1:8 Deserializer as you suggest and could also look at the HAD1511 peripherals from the scope project for this) and 2) The UDP Streaming (with a counter in a first time). Once each part is validated, connecting the two should be easy | 07:21 |
| tweakoz | @Melkhior : Thank you, that did the trick. | 07:36 |
| tweakoz | Hmm, there is hyperram on the mercury 2 as well. I should also try out litehyperbus | 07:41 |
| tweakoz | although it looks like I would have to port from ECP5 to Xilinx 7 | 07:46 |
| zyp | depends how fast you want it | 07:47 |
| tweakoz | I don't need it quite yet - just curious. | 07:50 |
| _florent_ | tweakoz: https://github.com/litex-hub/litehyperbus/blob/master/litehyperbus/core/hyperbus.py is generic (but low speed) so should work on Artix7 | 07:51 |
| tpb | <https://x0.no/4uy0z> (at github.com) | 07:51 |
| _florent_ | https://github.com/litex-hub/litex-boards/blob/228a9650d4cd624de3e9f51612bb5b3970e2e2e0/litex_boards/targets/trenz_te0725.py#L59-L63 | 07:52 |
| tpb | <https://x0.no/4uy10> (at github.com) | 07:52 |
| zyp | that core is probably also gonna need the latency to be made adjustable eventually | 07:53 |
| _florent_ | zyp: Indeed, with the current setting, IIRC it should work with all HyperRAM, but configuring latency could increase perf | 07:55 |
| zyp | no, the hyperram I've got has a default latency of 7 | 07:55 |
| zyp | hence why I had to make it configurable for the X2 core | 07:56 |
| _florent_ | ah ok | 07:56 |
| zyp | the W956A8MBYA5I does max 200 MHz, and needs 7 cycles to achieve that, which it also defaults to | 08:01 |
| _florent_ | zyp: If I add it to the generic core, would you mind testing on your hardware? | 08:01 |
| zyp | sure, I can do that | 08:01 |
| _florent_ | zyp: BTW I had first quick look at #942, this looks good, thanks! (will try to review it more carefully soon). | 08:02 |
| zyp | nice | 08:02 |
| zyp | I don't think it'll break any existing functionality, and should be a good starting point for moving out the libraries | 08:03 |
| _florent_ | Indeed, I like the direction it takes, thanks. | 08:12 |
| tweakoz | I misread the manual, the mercury2 is not hyperram, just async sram - 18-20 address lines, 8 data lines, and a write enable and chip enable and thats it. | 08:14 |
| tweakoz | so to pull off async-sram would cloning-mutating Wishbone.SRAM be reasonable ? (mutating to use external IO instead of block ram) - looks like I would also have to reproduce what is done in SoC.add_ram (pointing to my wishbone AsyncSRAM class) | 08:34 |
| zyp | I would expect there to be an existing core you could make use of somewhere | 08:37 |
| zyp | maybe this would be relevant: https://github.com/betrusted-io/gateware/blob/master/gateware/sram_32.py | 08:38 |
| tpb | <https://x0.no/4uy16> (at github.com) | 08:39 |
| *** RaYmAn <[email protected]> has joined #litex | 09:42 | |
| *** ewen <[email protected]> has quit IRC (Quit: leaving) | 09:50 | |
| *** lkcl_ <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 09:54 | |
| tweakoz | the betrusted-io did not seem to fit - so I did start with wishbone.SRAM and soc.add_ram() - and modified it. seems to work | 10:22 |
| tweakoz | litex> mem_list | 10:22 |
| tweakoz | Available memory regions: | 10:22 |
| tweakoz | VEXRISCV_DEBUG 0xf00f0000 0x100 | 10:22 |
| tweakoz | ROM 0x00000000 0x8000 | 10:22 |
| tweakoz | SRAM 0x10000000 0x20000 | 10:22 |
| tweakoz | ISSIRAM 0x20000000 0x80000 | 10:22 |
| tweakoz | CSR 0xf0000000 0x10000 | 10:22 |
| tweakoz | litex> mem_test 0x20000000 0x80000 | 10:22 |
| tweakoz | Memtest at 0x20000000 (512KiB)... | 10:22 |
| tweakoz | Write: 0x20000000-0x20080000 512KiB | 10:22 |
| tweakoz | Read: 0x20000000-0x20080000 512KiB | 10:22 |
| tweakoz | Memtest OK | 10:22 |
| tweakoz | or at least the mem_test passes - not sure how thorough mem_test is | 10:23 |
| *** acathla <[email protected]> has quit IRC (Quit: [Guru Meditation]) | 10:30 | |
| tweakoz | 640K should be enough for anyone. | 10:31 |
| *** acathla <[email protected]> has joined #litex | 10:32 | |
| *** tweakoz <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 10:47 | |
| Melkhior | Hello, | 11:17 |
| Melkhior | I'm trying to write through the Wishbone in a Litex SoC with no CPU (bridging from the bus of a host system) to the CSR of a Litex LedChaser. | 11:17 |
| Melkhior | I've instantiated a wishbone.Interface and added it as master on the bus with: | 11:17 |
| Melkhior | self.bus.add_master(name="SBusBridgeToWishbone", master=self.sbus_slave.wishbone) | 11:17 |
| Melkhior | Litex tells me: | 11:17 |
| Melkhior | INFO:SoCCSRHandler:leds CSR allocated at Location 0. | 11:17 |
| Melkhior | (...) | 11:17 |
| Melkhior | INFO:SoC:32-bit wishbone Bus, 4.0GiB Address Space. | 11:17 |
| Melkhior | (...) | 11:17 |
| Melkhior | csr : Origin: 0x00040000, Size: 0x00010000, Mode: RW, Cached: False Linker: False | 11:17 |
| Melkhior | So I'm trying to write my data to 0x00040000 (first location in the csr area) on the wishbone bus with: | 11:17 |
| Melkhior | wb_fsm.act("Write", | 11:17 |
| Melkhior | self.wishbone.adr.eq(csr_data_w_addr), | 11:17 |
| Melkhior | self.wishbone.dat_w.eq(csr_data_w_data), | 11:17 |
| Melkhior | self.wishbone.we.eq(1), | 11:17 |
| Melkhior | self.wishbone.cyc.eq(1), | 11:17 |
| Melkhior | self.wishbone.stb.eq(1), | 11:17 |
| Melkhior | If(self.wishbone.ack == 1, | 11:17 |
| Melkhior | self.wishbone.we.eq(0), | 11:17 |
| Melkhior | self.wishbone.cyc.eq(0), | 11:17 |
| Melkhior | self.wishbone.stb.eq(0), | 11:17 |
| Melkhior | NextState("Idle") | 11:18 |
| Melkhior | ) | 11:18 |
| Melkhior | ) | 11:18 |
| Melkhior | Some added Leds tell me this state is reached and the ack received, but the chaser keeps chasing instead of goingo to _CONTROL_MODE, so I guess the write didn't complete as I want it to. | 11:18 |
| Melkhior | Any suggestion welcome. | 11:18 |
| *** C-Man <[email protected]> has quit IRC (Read error: Connection reset by peer) | 11:50 | |
| Melkhior | https://github.com/rdolbeau/SBusFPGA/blob/49b4dae59dcac2374a9d3c8ef5de311d88eee629/sbus-to-ztex-gateware-migen/sbus_to_fpga_slave.py#L482-L494 | 13:21 |
| tpb | <https://x0.no/4uy2f> (at github.com) | 13:21 |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has quit IRC (Ping timeout: 244 seconds) | 13:58 | |
| *** Leon[m] <Leon[m]!~leons@2001:470:69fc:105::abc> has quit IRC (Ping timeout: 244 seconds) | 13:58 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Ping timeout: 244 seconds) | 13:58 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC (Read error: Connection reset by peer) | 13:59 | |
| *** david-sawatzke[m <david-sawatzke[m!~david-saw@2001:470:69fc:105::1634> has quit IRC (Read error: Connection reset by peer) | 13:59 | |
| *** dcallagh <dcallagh!~dcallagh@2001:470:69fc:105::9c5> has quit IRC (Read error: Connection reset by peer) | 13:59 | |
| *** jryans <jryans!~jryansmat@2001:470:69fc:105::1d> has quit IRC (Read error: Connection reset by peer) | 13:59 | |
| *** jryans <jryans!~jryansmat@2001:470:69fc:105::1d> has joined #litex | 14:00 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #litex | 14:01 | |
| *** dcallagh <dcallagh!~dcallagh@2001:470:69fc:105::9c5> has joined #litex | 14:01 | |
| *** Leon[m] <Leon[m]!~leons@2001:470:69fc:105::abc> has joined #litex | 14:01 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #litex | 14:01 | |
| *** david-sawatzke[m <david-sawatzke[m!~david-saw@2001:470:69fc:105::1634> has joined #litex | 14:01 | |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has joined #litex | 14:01 | |
| *** gregd <gregd!~gregdavil@2001:44b8:263:b00:dec2:9712:21d:266a> has quit IRC (Remote host closed the connection) | 15:38 | |
| _florent_ | Melkhior: The Wishbone bus is word addressed (something we should eventually change...) so the issue is probably here: self.wishbone.adr.eq(csr_data_w_addr) | 17:10 |
| _florent_ | it should be self.wishbone.adr.eq(csr_data_w_addr/4) (or self.wishbone.adr.eq(csr_data_w_addr[2:]) | 17:10 |
| Melkhior | @_florent_ ok it figures, this was definitely a byte address | 17:12 |
| Melkhior | thanks | 17:12 |
| Melkhior | will try that ASAP | 17:12 |
| Melkhior | I feel the other way around (Wishbone master sending request that I will have to translate to SBus DMA somehow, and figuring out the SW side) is going to be harder | 17:13 |
| *** gruetze_ is now known as gruetzkopf | 17:14 | |
| Melkhior | But the endgame is tempting: potentially the first OHCI USB Host on a SBus-based SPARCstation :-) | 17:14 |
| *** FabM <FabM!~FabM@2a03:d604:101:1200:c4bd:1e46:cbd0:ec12> has quit IRC (Remote host closed the connection) | 17:14 | |
| Melkhior | _florent_: another Wishbone while I'm at it; any 'easy' way to do CDC ? I see some 'obvious' stuff for AXI-list & Stream, but not for Wishbone | 17:23 |
| Melkhior | I will likely need to run Wishbone in its own domain rather than synchronous with the SBUs (which can be anywhere from 16.67 to 25 MHz) | 17:24 |
| Melkhior | although that's probably for later when i can read & write csr... | 17:25 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 18:19 | |
| *** TMM_ <[email protected]> has joined #litex | 18:19 | |
| _florent_ | Melkhior: We don't have our own Wishbone CDC yet but you can find some in verilog only and instantiate it | 19:33 |
| Melkhior | _florent_: ok thx | 19:33 |
| Melkhior | Also I might need FIFO to buffer between SBus and Wishbone, async FIFO could also work I suppose... | 19:34 |
| Melkhior | I'm not quite there yet anyway :-) | 19:34 |
| Melkhior | Bus bridging between different era doesn't look easy... | 19:35 |
| Melkhior | (SBus is virtually addressed on the Master side... I'm guessing Wishbone isn't) | 19:35 |
| _florent_ | I could help on this when you'll need it in your system | 19:38 |
| Melkhior | ok thx a lot | 19:39 |
| Melkhior | :-) | 19:40 |
| cr1901 | _florent_: Just a heads up, I've started porting jcore to LiteX. It's going to be a proof-of-concept level port for now (no cache, single variant), due to the high latency in getting feedback from the jcore devs. Will you still merge it if I give a PR? | 19:42 |
| *** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Remote host closed the connection) | 20:56 | |
| *** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 20:57 | |
| *** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Remote host closed the connection) | 20:59 | |
| *** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 20:59 | |
| cr1901 | mithro: How do you use pythondata-auto to create a cpu module? | 21:39 |
| mithro | cr1901: You just add configs | 21:42 |
| mithro | cr1901: In https://github.com/litex-hub/pythondata-auto/blob/master/modules.ini | 21:43 |
| tpb | <https://x0.no/4uy3o> (at github.com) | 21:43 |
| mithro | But things are currently broken due to https://github.com/litex-hub/pythondata-auto/issues/8 | 21:43 |
| tpb | <https://x0.no/4uy3p> (at github.com) | 21:43 |
| cr1901 | How should j-core be added then to that repo for the time being? | 21:44 |
| cr1901 | (Basically I'm asking "Is it okay if I point to my own copies of j-core and pythondata-cpu-j-core from the litex repo for now"?) | 21:44 |
| mithro | Sure! | 21:45 |
| cr1901 | Once we go past minimum viable product we can discuss pointing to the j-core repo that belongs to GH user j-core, and adding pythondata-cpu-j-core to the litex-hub user | 21:46 |
| mithro | Yeap! SGTM | 21:54 |
| cr1901 | mithro: How are you supposed to initialize a pythondata-cpu-* repo from the first commit using that script? | 22:21 |
| cr1901 | I created this empty repo: https://github.com/cr1901/pythondata-cpu-j-core | 22:22 |
| cr1901 | But the script bombs with "Your configuration specifies to merge with the ref 'refs/heads/master' | 22:22 |
| cr1901 | from the remote, but no such ref was fetched." | 22:22 |
| cr1901 | Well, yea, because I'm trying to create the repo to push | 22:22 |
| mithro | I'll create the repo | 22:25 |
| cr1901 | mithro: Thanks (in addition, I also just figured it out: comment out the "download()" function :P | 22:26 |
| mithro | cr1901: I'm guessing it would be probably be pythondata-cpu-jcore instead? | 22:29 |
| cr1901 | They have the hyphen on the website, but I seriously doubt it'll cause problems to remove it for the sake of keeping the package namespace neater | 22:30 |
| cr1901 | (and if it does cause problems, well... we'll cross that bridge later) | 22:31 |
| cr1901 | I built a bare-metal SuperH toolchain w/ the j-core insns yesterday, so that's taken care of. | 22:32 |
| mithro | cr1901: https://github.com/litex-hub/pythondata-cpu-jcore | 22:34 |
| mithro | cr1901: I gave you access to the repo | 22:35 |
| cr1901 | mithro: Tyvm | 22:35 |
| cr1901 | mithro: I'm putting this minddump here as a reminder to myself. To get pythondata-auto to work for me locally, I had to do a few things: | 23:04 |
| mithro | okay SGTM | 23:04 |
| cr1901 | 1. While there's an empty repo, the download() part of the script needs to be commented out, because it'll fail with the error I mentioned above re: refs/master | 23:06 |
| cr1901 | 2. I removed everything except the jcore section from modules.ini, because I don't need it locally :D | 23:07 |
| cr1901 | 3. I had to set GIT_MODE=https, even with commit access to pythondata-cpu-jcore, because I otherwise get "denied publickey" (I think the ssh url is "ssh://[email protected]", the script hardcodes "{MODE}://github.com") | 23:08 |
| cr1901 | I manually added a ssh to the repo that the script created | 23:08 |
| cr1901 | 4. Optionally, I will probably run "setup.py develop" in pythondata-cpu-jcore that pythondata-auto created | 23:09 |
| cr1901 | This is so I can use the script to quickly update the VHDL repo, since I anticipate a change or two will be necessary | 23:10 |
| cr1901 | /minddump | 23:10 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!