| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** cr1901_ is now known as cr1901 | 00:41 | |
| AndrewD | anyone had success using JTAG debug of vexriscv-smp on ecp5 with openocd_vex? | 01:04 |
|---|---|---|
| AndrewD | Info : JTAG tap: ecp5.tap tap/device found: 0x81112043 (mfg: 0x021 (Lattice Semi.), part: 0x1112, ver: 0x8) | 01:04 |
| AndrewD | Info : JTAG tap: vexrisc_ocd.bridge tap/device found: 0xffffffff (mfg: 0x7ff (<invalid>), part: 0xffff, ver: 0xf) | 01:04 |
| AndrewD | Warn : JTAG tap: vexrisc_ocd.bridge UNEXPECTED: 0xffffffff (mfg: 0x7ff (<invalid>), part: 0xffff, ver: 0xf) | 01:04 |
| AndrewD | Error: JTAG tap: vexrisc_ocd.bridge expected 1 of 1: 0x10001fff (mfg: 0x7ff (<invalid>), part: 0x0001, ver: 0x1) | 01:04 |
| AndrewD | I've tried both of these: | 01:07 |
| AndrewD | if self.cpu_type in ["vexriscv_smp"]: | 01:07 |
| AndrewD | if False: | 01:07 |
| AndrewD | self.submodules.jtag = jtag = ECP5JTAG() | 01:07 |
| AndrewD | self.comb += self.cpu.jtag_clk.eq(self.jtag.tck) | 01:07 |
| AndrewD | self.comb += self.cpu.jtag_enable.eq(1) | 01:07 |
| AndrewD | self.comb += self.cpu.jtag_capture.eq(self.jtag.capture) | 01:07 |
| AndrewD | self.comb += self.cpu.jtag_shift.eq(self.jtag.shift) | 01:07 |
| AndrewD | self.comb += self.cpu.jtag_update.eq(self.jtag.update) | 01:07 |
| AndrewD | self.comb += self.cpu.jtag_reset.eq(self.jtag.reset) | 01:07 |
| AndrewD | self.comb += self.cpu.jtag_tdi.eq(self.jtag.tdi) | 01:07 |
| AndrewD | self.comb += self.jtag.tdo.eq(self.cpu.jtag_tdo) | 01:07 |
| AndrewD | # JTAG clock domain ------------------------------------------------------------------------ | 01:07 |
| AndrewD | self.clock_domains.cd_jtag = ClockDomain() | 01:07 |
| AndrewD | self.comb += ClockSignal("jtag").eq(jtag.tck) | 01:07 |
| AndrewD | self.specials += AsyncResetSynchronizer(self.cd_jtag, ResetSignal("jtag")) | 01:07 |
| AndrewD | else: | 01:07 |
| AndrewD | self.specials += Instance("JTAGG", | 01:07 |
| AndrewD | o_JRSTN = self.cpu.jtag_reset, | 01:07 |
| AndrewD | o_JSHIFT = self.cpu.jtag_shift, | 01:07 |
| AndrewD | o_JUPDATE = self.cpu.jtag_update, | 01:07 |
| AndrewD | o_JTCK = self.cpu.jtag_clk, | 01:08 |
| AndrewD | o_JTDI = self.cpu.jtag_tdi, | 01:08 |
| AndrewD | o_JCE1 = self.cpu.jtag_capture, | 01:08 |
| AndrewD | i_JTDO1 = self.cpu.jtag_tdo, | 01:08 |
| AndrewD | ) | 01:08 |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:88ac:298c:9499:1cf2> has quit IRC (Quit: Leaving) | 01:28 | |
| *** Degi_ <[email protected]> has joined #litex | 01:43 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 01:44 | |
| *** Degi_ is now known as Degi | 01:44 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Remote host closed the connection) | 01:58 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 01:58 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 02:03 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 02:06 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 02:10 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 02:14 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 02:18 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:fcfc:de6a:5826:a17a> has joined #litex | 02:31 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 02:59 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 250 seconds) | 03:05 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 03:08 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 252 seconds) | 03:12 | |
| tnt | AndrewD: use pastebin please ... | 06:18 |
| AndrewD | tnt: OK - will do in the future. Or should I repeat the above with pastebin? | 06:21 |
| AndrewD | The ECP5 JTAG issue is porbably related to capture being derived from JCE1 and requiring a custom command (IR==0x32)? | 06:22 |
| *** FabM <FabM!~FabM@2a03:d604:103:600:8327:1f7c:26a:bd86> has joined #litex | 06:52 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 07:15 | |
| *** lexano <[email protected]> has joined #litex | 07:55 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 08:05 | |
| *** lexano <[email protected]> has joined #litex | 08:19 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 08:24 | |
| tnt | _florent_: ping ? Any clue on the ILAS issue ? I mean if you're using it with 20b data path, I must be missing somewhere. | 08:31 |
| *** lexano <[email protected]> has joined #litex | 08:38 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:fcfc:de6a:5826:a17a> has quit IRC (Remote host closed the connection) | 08:39 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:fcfc:de6a:5826:a17a> has joined #litex | 08:40 | |
| *** essele <[email protected]> has joined #litex | 09:07 | |
| *** essele_ <[email protected]> has quit IRC (Read error: Connection reset by peer) | 09:07 | |
| tnt | I switches to a 40b phy data width and running the JESD domain at line_rate / 40 instead of / 20 and so now it gets 32b at a time and the ILAS check does pass and link gets established. Still no idea how it's supposed to work with 20. | 09:30 |
| tnt | Looking at the source.converterN data streams (after having put the ADI chip in test 'RAMP' mode), I see the ramp correctly on converter0 but converter[1..3] seem to be garbage. | 09:31 |
| tnt | Disabling scrambling "fixes" it, so I guess the scrambler has an issue. | 10:29 |
| tnt | mmmmh, nm, it might have been pebkak and I might have screwed up the order of the init in that previous test. | 10:46 |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 11:10 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 11:14 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 11:18 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 11:22 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 11:25 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 250 seconds) | 11:29 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 12:11 | |
| _florent_ | tnt: Sorry, I was on something else, 20b is what I'm using on 7-Series Artix7/KinteX7. I'm not sure I already tested JESD RX with on Ultrascale, so that's possible Comma alignement was not configured correctly. | 13:12 |
| _florent_ | tnt: If you have issue with the ILAS check, you could disable to check or reset to at least be able to observe the full ILAS sequence with LiteScope | 13:12 |
| _florent_ | for the 40b/20b issue, it could be an issue in the clocking | 13:13 |
| tnt | yeah, looking at your code, the jesd domain is set to linerate / 40 | 13:13 |
| tnt | I thought the jesd domain had to be linerate / phy_width basically. | 13:14 |
| tnt | (so I had it set to linerate / 20 when phy_width was 20 and now I have it set to linerate / 40 with phy_width set to 40. I didn't try linerate / 40 with phy_width=20). | 13:15 |
| _florent_ | tnt: I should have mention this, but the core is always working on 32-bit and and inserting adapters when phy is configured to 16-bit (20-bit + 8b10b) | 13:18 |
| _florent_ | https://github.com/enjoy-digital/litejesd204b/blob/master/litejesd204b/core.py#L88-L89 | 13:18 |
| _florent_ | https://github.com/enjoy-digital/litejesd204b/blob/master/litejesd204b/core.py#L53-L54 | 13:18 |
| tnt | yeah, that's what I saw in the code and why I was confused. | 13:19 |
| tnt | I didn't realize that implied that the jesd rate was always linerate / 40, independent of the phy_width. | 13:20 |
| tnt | (to get 32b per cycle and not 32b every 2 cycles since there is no 'valid/ready'). | 13:20 |
| tnt | But good to confirm that this is normal operation. And so in the end the phy_width doesn't really matter ... that just changes the phy clock frequency but this gets down to linerate / 40 anyway. | 13:22 |
| _florent_ | tnt: Once you'll have this working, I'll try to do a pass to document the points that were not clear. The hardware that I used to developed the core is also not open-source, so don't have a good example I can share. If your project end up being open-source, future users could also use it as reference. | 13:25 |
| tnt | I don't think it'll be open-source. I want to put the board file and a basic target upstream, but that wouln't include the JESD, that takes a shit-ton of init code to setup the whole clock tree and the whole ADI chip bringup. | 13:28 |
| tnt | However starting from your example relly the main obstacles were (1) GTHE4 support and ultrascale comma alignement in general (which hopefully will be upstreamed) and (2) the clocking, the example you had has switchable clocks, I simpified that to just use a simple buffer, no mmcm, no mux. (3) that confusion with jesd domain and it needing to be inerate/40. and (4) knowing that you need to set all the enables bit for phy/rx/tx cores and that needs to be done _after | 13:31 |
| *** lexano <[email protected]> has joined #litex | 14:19 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 252 seconds) | 17:16 | |
| *** essele <[email protected]> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 18:26 | |
| *** essele <[email protected]> has joined #litex | 18:29 | |
| tnt | Am I correct that if I have a Module createing ClockDomain('blah') and some of its submodule refering to it ( using ClockSignal('blah') or ClockDomainsRenamer('blah') or self.sync.blah += xxx ), they will indeed all be the same domain ? And that if my top module instanciates 2 of those Modules, it will create two distinct clock domains but each of the subsubmodule will be correcty using the one of its parent ? | 19:10 |
| tnt | (not sure if I'm making myself super clear here ...) | 19:10 |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 19:18 | |
| *** essele <[email protected]> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 20:05 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 252 seconds) | 20:08 | |
| zyp | I believe that is the case | 20:44 |
| SpaceCoaster | My snickerdoodle platform code doesn’t pass CI because it doesn’t have a clock pin. The only clock is a ps7 derived internal clock. | 21:22 |
| cr1901 | tnt: I wrote this a while ago, and it doesn't mention ClockDomainsRenamer, but it should still be correct: https://gist.github.com/cr1901/5de5b276fca539b66fe7f4493a5bfe7d | 21:25 |
| cr1901 | tnt: The bad news is... if that gist does NOT help you... I've not been doing so hot this week, so me correcting the gist to help you will have to wait :( | 21:26 |
| _florent_ | tnt: That's correct yes | 21:33 |
| cr1901 | _florent_: If I were to buy e.g. a litefury, could you recommend something (M2 to PCIe adapter) that would let me put it into a PCIe slot on a desktop motherboard? | 23:11 |
| zyp | any pcie to m-key m.2 adapter should work | 23:20 |
| zyp | and most of them will be m-key since that's what nvme ssds use | 23:21 |
| cr1901 | https://www.amazon.com/M-2-Adapter-Aluminum-Heatsink-Solution/dp/B07JJTVGZM Like this? | 23:26 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!