| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** pftbest_ <[email protected]> has joined #litex | 00:01 | |
| *** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Ping timeout: 252 seconds) | 00:05 | |
| *** Degi_ <[email protected]> has joined #litex | 00:18 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 00:19 | |
| *** Degi_ is now known as Degi | 00:19 | |
| *** pftbest_ <[email protected]> has quit IRC (Remote host closed the connection) | 00:38 | |
| *** pftbest <[email protected]> has joined #litex | 00:54 | |
| *** pftbest <[email protected]> has quit IRC (Remote host closed the connection) | 00:58 | |
| *** pftbest <[email protected]> has joined #litex | 00:58 | |
| *** pftbest <[email protected]> has quit IRC (Remote host closed the connection) | 01:33 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Read error: Connection reset by peer) | 01:47 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 01:47 | |
| *** pftbest <[email protected]> has joined #litex | 01:53 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 01:58 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 02:05 | |
| *** TMM_ <[email protected]> has joined #litex | 02:05 | |
| *** C-Man <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 02:15 | |
| *** pftbest <[email protected]> has joined #litex | 02:28 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 02:32 | |
| *** alainlou <[email protected]> has quit IRC (Quit: Client closed) | 03:01 | |
| *** pftbest <[email protected]> has joined #litex | 03:05 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 03:09 | |
| *** pftbest <[email protected]> has joined #litex | 03:26 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 03:30 | |
| *** pftbest <[email protected]> has joined #litex | 03:47 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 03:51 | |
| *** pftbest <[email protected]> has joined #litex | 04:49 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 04:54 | |
| *** pftbest <[email protected]> has joined #litex | 05:31 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 05:36 | |
| *** pftbest <[email protected]> has joined #litex | 06:13 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 06:17 | |
| _florent_ | kbeckmann: The longer stalls can indeed be caused by the refresh. To confirm this, you can add the refresher's fsm to your litescope analyzer: https://github.com/enjoy-digital/litedram/blob/master/litedram/core/refresher.py#L259 | 06:33 |
|---|---|---|
| _florent_ | Providing deterministic latency with SDRAM can indeed be tricky due to refresh but there are technique to mitigate the impacts (ex postpone them) | 06:35 |
| _florent_ | to confirm your issue is related to this, you can also try to disable refreshes by setting with_refresh to False: https://github.com/enjoy-digital/litedram/blob/master/litedram/core/controller.py#L34 | 06:37 |
| _florent_ | the data should stay in SDRAM without corruption for at least a few seconds | 06:38 |
| *** pftbest <[email protected]> has joined #litex | 06:45 | |
| *** pftbest <[email protected]> has quit IRC (Remote host closed the connection) | 06:50 | |
| *** pftbest <[email protected]> has joined #litex | 06:50 | |
| *** FabM <[email protected]> has joined #litex | 06:56 | |
| kbeckmann | thanks, i will give it a shot later today :) | 07:00 |
| _florent_ | nice project BTW! | 07:12 |
| _florent_ | what's the maximal expected latency for the N64 accesses? | 07:14 |
| kbeckmann | thanks! it seems to be around 300ns. there is a way to get slower accesses but it would be fun to stay compatible with the default config. | 07:32 |
| kbeckmann | i am targeting an ECP5 speedgrade 6, so i'll probably keep the system clock at around 50 MHz and run the SDRAM with 1:2 gearing. currently i am doing 32 bit reads but it probably makes more sense to go for raw 16 bit accesses since that's the width of the n64 cartridge bus and the physical SDRAM, maybe i can save a few cycles going for that. | 07:36 |
| *** futarisIRCcloud <[email protected]> has quit IRC (Quit: Connection closed for inactivity) | 07:37 | |
| tnt | 300 ns should be plenty of time, even running the SDRAM at 50 MHz. | 07:52 |
| tnt | You can operate down to CL=1 at that frequency. | 07:53 |
| tnt | "<ACTIVE> <READ> <NOP (grab data)> <NOP (auto-precharge)> <AUTO-REFRESH> <NOP> <NOP> <NOP>" that cycle can be repeated (at 50 MHz), includes continuous refresh and is only 160 ns. And if you don't need the refresh at that time, you can sneak in a R/W for CPU. | 08:04 |
| kbeckmann | ah, good to know! | 08:29 |
| tnt | What speedgrade did you use btw ? | 08:32 |
| kbeckmann | right now i just use a more or less "random" SDRAM that i had around. K4S561632J-UC75 | 08:32 |
| tnt | arf, that's the slowest there is, might need a couple more cycles. | 08:37 |
| kbeckmann | ah i see. i need to get a better understanding of what to look for in SDRAMs. | 08:38 |
| tnt | -6 or -6A :) | 08:39 |
| kbeckmann | this is just on an old board that i made a few years ago. the project will use whatever is suitable :). haven't finished the design. | 08:39 |
| kbeckmann | alright | 08:39 |
| tnt | I'm surprised you have that long TBH. At 300 ns, you could use one of those SPI PSRAM and be fast enough. | 08:43 |
| RaYmAn_ | I think those SDRAM chips there was some random aliexpress purchase at like 2$ for 10 so can't expect much =P | 08:44 |
| *** RaYmAn_ is now known as RaYmAn | 08:44 | |
| kbeckmann | ah that's right. literally random sdram :). | 08:44 |
| kbeckmann | i have a bunch of those PSRAMs as PMODs so that should be easy to set up. could use two in parallel | 08:45 |
| tnt | You have time to grab the 16 bits from a single one. | 08:45 |
| kbeckmann | cool. might give it a shot after work today | 08:46 |
| _florent_ | kbeckmann: the 300ns also seems high, I'm not familiar with the N64, but just looked at a N64 cart | 08:55 |
| _florent_ | https://farm1.staticflickr.com/690/30974001534_0114ece39b_h.jpg | 08:55 |
| _florent_ | the latency of the MX23L6402-35E seems to be around 100-150ns | 08:55 |
| kbeckmann | it could be that the latency requirements are more relaxed during the early boot. the bootloader loads 1MB of the ROM into RAM and executes from there. later, maybe the program can do faster accesses later on, i'm not sure. | 08:58 |
| kbeckmann | here's a saleae logic screenshot of a read https://allg.one/Lvr6.png | 09:03 |
| kbeckmann | during this phase, i could also start the read when i have received the address but before the read signal is sent, and then i'd have the data ready immediately when the read pin toggles. however, it seems that this is just a special case during boot. | 09:10 |
| _florent_ | that would indeed be nice to sniff the access after boot to be sure of minimal latency you have to emulate (if the info is not already available somewhere) | 09:23 |
| *** C-Man <[email protected]> has joined #litex | 09:51 | |
| Melkhior | kbeckmann:I'm not a HW guy, but why not HyperRam? From my (limited) understanding, it should be smaller/faster/easier than SDRAM | 09:55 |
| RaYmAn | might not matter but isn't it also fairly high latency? | 09:56 |
| Melkhior | There were some effort for LItex already it seems https://github.com/gregdavill/litex-hyperram/ | 09:57 |
| Melkhior | RaYmAn: I don't know TBH... | 10:00 |
| tnt | from a latency PoV it's not better. | 10:00 |
| tnt | might actualy be worse. | 10:00 |
| zyp | with the HyperRAMX2 module hooked up to a W956A8MBYA5I I measured 16 cycles of latency at the wishbone bus | 11:26 |
| zyp | at the 75 MHz I ran it at, that's 213ns, but I figure it'll do the same number of cycles at 100 MHz, bringing it down to 160ns | 11:27 |
| zyp | (those numbers are wishbone clock, hyperram clock is twice that) | 11:27 |
| *** C-Man <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 11:33 | |
| *** C-Man <[email protected]> has joined #litex | 11:47 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 244 seconds) | 11:47 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** dcallagh <dcallagh!~dcallagh@2001:470:69fc:105::9c5> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** leons <leons!~leons@2001:470:69fc:105::abc> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** OmkarBhilare[m] <OmkarBhilare[m]!~ombhilare@2001:470:69fc:105::4e51> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** vomoniyi[m] <vomoniyi[m]!~vomoniyig@2001:470:69fc:105::3023> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** david-sawatzke[m <david-sawatzke[m!~david-saw@2001:470:69fc:105::1634> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** DerekKozel[m] <DerekKozel[m]!~dkozelgnu@2001:470:69fc:105::2f14> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has joined #litex | 12:44 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #litex | 12:45 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #litex | 12:45 | |
| *** dcallagh <dcallagh!~dcallagh@2001:470:69fc:105::9c5> has joined #litex | 12:45 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has joined #litex | 12:45 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has joined #litex | 12:45 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has joined #litex | 12:45 | |
| *** leons <leons!~leons@2001:470:69fc:105::abc> has joined #litex | 12:45 | |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has joined #litex | 12:46 | |
| *** vomoniyi[m] <vomoniyi[m]!~vomoniyig@2001:470:69fc:105::3023> has joined #litex | 12:46 | |
| *** david-sawatzke[m <david-sawatzke[m!~david-saw@2001:470:69fc:105::1634> has joined #litex | 12:46 | |
| *** DerekKozel[m] <DerekKozel[m]!~dkozelgnu@2001:470:69fc:105::2f14> has joined #litex | 12:46 | |
| *** OmkarBhilare[m] <OmkarBhilare[m]!~ombhilare@2001:470:69fc:105::4e51> has joined #litex | 12:46 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has joined #litex | 12:46 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 15:00 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 244 seconds) | 15:06 | |
| *** alainlou <[email protected]> has joined #litex | 15:25 | |
| Melkhior | _florent_: hypothetically, if I wanted to connect a SATA device to a LiteSata controller in an Artix-7, is there something comlpex to do ? Or would I just connect a MGT_TX to SATA_TX, MGT_RX to SATA_RX, and have a set of 10 nF coupling capacitors? | 15:33 |
| Melkhior | do the TX and RX pair need to be length-matched to each other, or does it not matter (i.e. they just need the + and - to be matched) | 15:34 |
| Melkhior | ... and is it MGT_TX to SATA_TX (pins 2/3), or SATA_RX (pins 5/6) - I can never figure out if RX/TX is from the PoV of the device (RX to RX), the host (RX to RX as well), or both (RX to TX, i.e. serial lines) | 15:36 |
| Melkhior | TIA | 15:36 |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 16:02 | |
| jevinskie[m] | Is it possible to submit read commands in all four phases of DFI in a single cycle or do I have to always submit reads only on the “read phase” (and likewise for the write phase)? | 16:05 |
| _florent_ | Melkhior: SATA is in fact very easy to add to an Artix-7, the coupling is generally already present in the device so not required | 16:12 |
| _florent_ | https://github.com/enjoy-digital/litex/wiki/Use-LiteX-on-the-Acorn-CLE-215#make-a-sata-adapter-optional | 16:12 |
| somlo | Melkhior: semi-related, if anyone sells a reasonably ($$$ as opposed to $$$$) priced FMC-to-SATA adapter, that'd be great to know :) | 16:13 |
| _florent_ | even this was working at 6Gbps IIRC :): https://twitter.com/enjoy_digital/status/1320747775626272769 | 16:13 |
| _florent_ | PCIe --> PCIe Riser --> USB3 cable --> SATA | 16:13 |
| _florent_ | you can also swap P/N, the core will detect it | 16:14 |
| Melkhior | _florent_: thx, it's swapping RX/TX I'm worried about mostly, as I understand those MGT pins are one-way ? | 16:15 |
| _florent_ | and length matching is not required between TX/RX (only between P/N of a pair) | 16:15 |
| _florent_ | the MGT pins are on-way yes, so TX of the FPGA to the RX of the Device, TX of the Device to the RX of the FPGA | 16:17 |
| Melkhior | OK... but when I see a diagram for the pins of PCB-side socket, do they show device-side or host-side? I always find this confusing for some reason :-/ | 16:19 |
| Melkhior | They say 'A' (pins 2&3) is TX, so it should go the the MGT_TX of the FPGA ? | 16:21 |
| Melkhior | sorry, MGT_*RX* of the FPGA ? | 16:21 |
| Melkhior | to match RX with TX | 16:21 |
| Melkhior | Unless it's TX from the host PoV ... that's what I like SBus, big parallel thingy with no +/- or RX/TX :-) | 16:23 |
| Melkhior | Thanks for the answers, clearer in my head and I know what I need to look for in more details | 16:24 |
| Melkhior | Should I go mad(der) and do a SBusFPGA V2 with SATA and HDMI | 16:25 |
| Melkhior | :-) | 16:25 |
| Melkhior | By then I guess there will be a Wishbone PCIe root complex in Litex, and i'll want to add PCIe as well :-) | 16:26 |
| Melkhior | THX | 16:26 |
| _florent_ | https://www.edaboard.com/attachments/sata-png.155609/ | 16:27 |
| _florent_ | On the device side, A is RX, B is TX | 16:28 |
| Melkhior | Oh perfect thanks ! So the FPGA's MGT_TX goes to A, the FPGA MGT_RX goes to B, and they can be length-mismatched | 16:29 |
| Melkhior | as long as the pair is properly done | 16:29 |
| Melkhior | so SATA is probably not hard on a PCB, even with the decoupling capacitors, if there's enough room | 16:30 |
| Melkhior | THX again :-) | 16:30 |
| _florent_ | Melkhior: that's the nice thing with serial links: the core can be complex but it simplifies the hardware :) | 17:21 |
| Melkhior | _florent_: suits me fine - as you're the one doing the core and I'm the one doing the HW ;-) | 17:22 |
| Melkhior | And indeed, routing the 28 adress, 32 data, clock and other assorted signals of SBus is not the easiest part... | 17:23 |
| Melkhior | Buf I were to do a 'high-speed serial' version of my design, I'd probably need to use something like a Trenz TE0712, and the 'peripheral' would be more powerful than the host with an Artix-7 100T-2 ... | 17:24 |
| Melkhior | First, I need to get back the V1.2 from Seeed and make sure it works, in particular the USB stuff | 17:26 |
| somlo | hmmm, I wonder if the "Xilinx FMC XM 104" card should allow me to use litesata with LiteX, without having to solder anything (https://www.xilinx.com/products/boards-and-kits/hw-fmc-xm104-g.html) -- at least it's sub-$1000, cheaper than the dgway board I saw used previously... | 19:18 |
| _florent_ | somlo: without soldering, it you have a SFP on your board, this one is also interesting: https://shop.trenz-electronic.de/en/TE0424-01-SFP-2-SATA-Adapter | 19:24 |
| tpb | Title: SFP 2 SATA Adapter | SFP | Products (at shop.trenz-electronic.de) | 19:24 |
| _florent_ | https://mobile.twitter.com/enjoy_digital/status/1327222480306630657/photo/2 | 19:25 |
| somlo | heh, I have a bunch of cards with FMC; and the FMC-to-SFP adapters bring me right back to the original price range :D | 19:31 |
| _florent_ | somlo: if you have pcie it can also be cheap | 19:48 |
| _florent_ | somlo: In fact the Acorn base board will also be cheap alternative with a M2 SATA SSD: https://twitter.com/enjoy_digital/status/1429742762044399616/photo/3 | 19:51 |
| _florent_ | happy to send you one once validated if you want to work on the LiteSATA linux driver :) | 19:52 |
| somlo | hmm... sounds interesting :) | 19:53 |
| somlo | btw, I seem to recall that the lambdaconcept ecpix5 board has a sata connector out of the box -- was the issue that litesata isn't currently supported on ecp5, or did I misunderstand that part ? | 19:55 |
| Melkhior | _florent_: dumb question about those drivers; wouldn't it be "easier" to re-use a standard driver by emulating an existing controller or a standard like AHCI ? | 20:07 |
| Melkhior | Having out-of-the-box support for the OHCI USB was a boon - I could assume the driver was working when working on my bridge | 20:08 |
| Melkhior | (but then, I have no idea how complex AHCI is...) | 20:08 |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 240 seconds) | 20:21 | |
| tpw_rules | _florent_: i re-installed litex from scratch and tried to build the crossover uart for the cle-215 with vivado 2018.2 and it still dies with the set_clock_group command because there's no clock named 'main_crg_clkout0' | 20:59 |
| tpw_rules | i'm puzzled that you say it works | 21:00 |
| *** pftbest <[email protected]> has quit IRC (Remote host closed the connection) | 22:24 | |
| *** pftbest <[email protected]> has joined #litex | 22:45 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 22:49 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 22:56 | |
| *** TMM_ <[email protected]> has joined #litex | 22:56 | |
| *** pftbest <[email protected]> has joined #litex | 23:22 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 23:27 | |
| *** pftbest <[email protected]> has joined #litex | 23:35 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 23:39 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
