| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** Hoernchen_ <Hoernchen_!~hornulus@osmocom/hoernchen> has joined #litex | 00:37 | |
| josuah | LiteX is used in ASICs as part of the Caravel project | 00:45 |
|---|---|---|
| josuah | https://github.com/search?q=repo%3Aefabless%2Fcaravel%20litex&type=code | 00:46 |
| whitequark[cis] | i lived with someone who was doing an ASIC implementation of DWC_usb3 so i looked over her shoulder a few times | 00:46 |
| josuah | not your averge ASIC though, I know too little about either Caravel or ASICs | 00:47 |
| whitequark[cis] | aside from memories the only thing that was replaced for the FPGA prototype is the clocking module | 00:47 |
| whitequark[cis] | and the rest had minor tuning in coreConsultant to add extra pipeline stages, shrink memories, or the like | 00:47 |
| whitequark[cis] | (obviously the PHY was different but DWC_usb3 is the MAC) | 00:47 |
| josuah | USB23 :3 | 00:47 |
| whitequark[cis] | that's a large, complex module, used commercially | 00:47 |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 00:48 | |
| whitequark[cis] | so I don't think your "FPGA and ASIC code is so different" point stands the test of, well, reality | 00:48 |
| josuah | ah, no, USB 3.1, my bad | 00:49 |
| josuah | with displayport too! https://www.synopsys.com/dw/ipdir.php?ds=dwc_usb-c_31_dp_14 | 00:50 |
| josuah | I just realize that for every ASIC integrated into a computer device, there might be some Linux driver appearing some day | 00:51 |
| josuah | https://www.kernel.org/doc/html/v4.17/driver-api/usb/dwc3.html | 00:51 |
| tpb | Title: Synopsys DesignWare Core SuperSpeed USB 3.0 Controller — The Linux Kernel documentation (at www.kernel.org) | 00:51 |
| whitequark[cis] | dwc3 is very common yea | 00:51 |
| josuah | having ways to make this happen is great | 00:53 |
| josuah | gurki: anything you see missing from LiteX from ASIC point of view? Maybe this will come over time as you see more of LiteX's things around | 00:53 |
| *** Degi_ <[email protected]> has joined #litex | 01:24 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 255 seconds) | 01:25 | |
| *** Degi_ is now known as Degi | 01:25 | |
| *** feldim2425_ <[email protected]> has quit IRC (Quit: ZNC 1.8.2+deb2build5 - https://znc.in) | 04:07 | |
| *** feldim2425 <feldim2425!~feldim242@2001:871:25a:38bd:caa2:a9cc:52de:7e27> has joined #litex | 04:08 | |
| *** shorne_ <[email protected]> has quit IRC (Read error: Connection reset by peer) | 04:20 | |
| *** shorne <[email protected]> has joined #litex | 04:25 | |
| *** shorne <[email protected]> has quit IRC (Read error: Connection reset by peer) | 04:34 | |
| *** shorne <[email protected]> has joined #litex | 04:37 | |
| *** FabM <[email protected]> has joined #litex | 06:15 | |
| *** sakman_ <[email protected]> has joined #litex | 06:45 | |
| *** sakman <[email protected]> has quit IRC (Read error: Connection reset by peer) | 06:46 | |
| *** Hoernchen_ is now known as Hoernchen | 09:44 | |
| *** Foxyloxy <Foxyloxy!~foxyloxy@cpc151593-shef16-2-0-cust343.17-1.cable.virginm.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 11:21 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 13:50 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #litex | 13:51 | |
| _florent_ | MoeIcenowy: The GW2DDRPHY is now working on the Tang Primer 20K with adjusted latencies, thanks a lot for the port from ECP5DDRPHY. As a quick test, I just tested a Linux boot with Linux-on-LiteX-VexRiscv and it works. | 14:59 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 246 seconds) | 15:04 | |
| *** lexano <[email protected]> has joined #litex | 15:44 | |
| whitequark[cis] | one of the main issues wrt ASICs is the assumption that everything has a reset, which is not true for memories | 15:49 |
| whitequark[cis] | there's no "the value is not known" in simulation either | 15:49 |
| sensille | what would be the way to extract a pin from a record (acquired by self.platform.request)? i want to remove rst_n from the eth ports and hardwire it to high | 16:53 |
| somlo | sensille: something like: | 17:05 |
| somlo | pads = self.platform.request("eth", 0) | 17:05 |
| somlo | pads.rst_n = 1 | 17:05 |
| somlo | self.ethphy = LiteEthPHYxYz(..., pads = pads, ...) | 17:05 |
| somlo | ... would be my guess | 17:05 |
| somlo | unless you tried that already and it's a bit more "complicated", in which case sorry for the noise :) | 17:06 |
| sensille | hm. just forcing it high? no, i haven't tried that. self.comb += pads.rst_n.eq(1) | 17:11 |
| somlo | oh, yeah, what you said (the self.comb thing) :) | 17:11 |
| somlo | if *that* didn't work, then I'd also like to know the answer | 17:12 |
| sensille | https://dpaste.org/Bwmjw | 17:14 |
| tpb | Title: dpaste/Bwmjw (Python) (at dpaste.org) | 17:14 |
| sensille | so the driving-high part is there, but the original control code as well | 17:15 |
| somlo | weird, so your force-high statement went inbetween the force-low and the ~litehm2_ethphy_reset0 | 17:26 |
| somlo | and if I remember my verilog, the last one always wins | 17:26 |
| sensille | i assume i have to create a new record from the old one, without rst | 17:26 |
| somlo | what happens if you do `self.comb += pads.rst_n.eq(1)` *after* calling `self.ethphy = LiteEthPhy...(... pads = pads ...) | 17:27 |
| somlo | ? | 17:27 |
| somlo | if these things are inserted in the order in which they're "parsed" by migen, maybe doing that will place your statement last | 17:28 |
| sensille | nope. probably depends on the order in which they are finalized | 17:29 |
| somlo | right, so then see if you can add the `self.comb += pads.rst_n.eq(1)` somewhere in a finalize section of your own (this is already out of my depth as far as migen kung-fu is concerned) | 17:30 |
| somlo | the other thing would be to add a boolean argument to LiteEthPhy...() and tell *it* to wire rst_n to high (depending on your tolerance for having an out-of-tree patch against the LiteETH repo) | 17:31 |
| sensille | it already checks if there is a rst_n or not, so just not providing it would be fine | 17:32 |
| somlo | sorry, I don't know of a nice, "canonical" way, only thoughts of "throw stuff against the wall and see if it sticks" sorts of hacks :) | 17:32 |
| somlo | oh you mean removing the rst_n field from `pads` would work for you ? | 17:33 |
| somlo | I vaguely remember there might be examples in the code base on how to do that | 17:34 |
| somlo | I think I'll shut up now and let someone who actually speaks migen more fluently take a stab :D | 17:34 |
| sensille | yes, i want to remove it from 'pads' | 17:36 |
| somlo | would it make sense to `delattr(pads, 'rst_n')` before passing `pads` to `LiteEthPhy()` ? | 17:54 |
| somlo | and possibly after having done the `self.comb += pads.rst_n.eq(1)` bit? | 17:54 |
| sensille | this works for me now: https://dpaste.org/UqtEr | 17:55 |
| tpb | Title: dpaste/UqtEr (Python) (at dpaste.org) | 17:55 |
| sensille | ugly. | 17:55 |
| Hoernchen | oh, 5s75e: how are you hititng your eth timings? i'm currently trying to get a 5a75b 8.2 to work and eth appears to be a bit ... lossy, but i have to crank down sysclk to 40Mhz to get both eth and sysclk to pass | 17:59 |
| *** nickoe <nickoe!~nickoe@2a06:4004:21c3::cf9> has joined #litex | 18:35 | |
| nickoe | Hello, any activity in here now a days? | 18:35 |
| nickoe | I was wondering if I could use litespi to interface with any generic SPI chip, that is not a flash chip, but I don't see any example anywhere, where it is just used to talk to some simple SPI device that is not a SPI flash device. Like for example SPI based read write via a demo like app. | 18:37 |
| sensille | Hoernchen: https://dpaste.org/1NFiP | 18:44 |
| tpb | Title: dpaste/1NFiP (Python) (at dpaste.org) | 18:44 |
| sensille | yes, eth timing is hit and miss | 18:44 |
| Hoernchen | oh wow, with a -6 part? how? | 18:44 |
| sensille | it is pretty empty | 18:44 |
| sensille | Info: TRELLIS_FF: 4664/24288 19% | 18:45 |
| sensille | Info: TRELLIS_COMB: 11561/24288 47% | 18:45 |
| Hoernchen | yeah i'm basically just going for the liteeth/bench/colorlight_5a_75b.py example or the colorlite repo but both miss the target by a lot | 18:45 |
| Hoernchen | am i missing some arcane yosys arg like -abc9 or some other magic that changed during the past few years? | 18:46 |
| sensille | i added this: https://dpaste.org/xjzWP | 18:47 |
| tpb | Title: dpaste/xjzWP (Python) (at dpaste.org) | 18:47 |
| sensille | not sure if it necessary, but it can help | 18:47 |
| Hoernchen | there are basically some hints that the timing used to be better/easier: https://github.com/enjoy-digital/liteeth/pull/74#issuecomment-895978835 (?) | 18:47 |
| sensille | and no, still plain abc, no abc9 flow something | 18:47 |
| sensille | you can also try to use an older yosys, like 2 years old | 18:48 |
| sensille | but timing jumps wildly with any design change | 18:48 |
| Hoernchen | yeah i basically tried a few versions and litex releases since 2020 and there are major differences as far as the timing is concerned | 18:48 |
| Hoernchen | but either sysclock or eth clock fail by a lot, apparently depending on 32b eth datapath or not | 18:49 |
| Hoernchen | can you share your tool versions? | 18:49 |
| sensille | oss-cad-suite-20230826 | 18:49 |
| Hoernchen | oh, that new.. yeah.. that is what I am currently using | 18:49 |
| sensille | and i don't use etherbone, just ethernet from vexriscv | 18:49 |
| Hoernchen | ah | 18:50 |
| sensille | i need the new one due to ghdl improvements | 18:50 |
| sensille | you can also give that patch above a try | 18:50 |
| Hoernchen | yeah i'm on it | 18:50 |
| sensille | but i've also seen that with 105mhz eth still works fine | 18:53 |
| nickoe | Any of you two, who understands if class LiteSPI can be used as a generic spi controller? What I am not so sure about is how to define the phy argument. "phy : Module Module or object that contains PHY stream interfaces and a cs signal to connect the ``LiteSPICore`` to." | 18:53 |
| Hoernchen | no idea, the colorlight board is my first litex adventure | 18:54 |
| sensille | mine too. i use litespi with a flash, but controlled from software | 18:57 |
| *** nickoe86 <nickoe86!~nickoe@2a06:4004:21c3::cf9> has joined #litex | 18:59 | |
| *** nickoe93 <nickoe93!~nickoe86@2a06:4004:21c3::cf9> has joined #litex | 19:02 | |
| *** nickoe <nickoe!~nickoe@2a06:4004:21c3::cf9> has quit IRC (Ping timeout: 246 seconds) | 19:03 | |
| *** nickoe93 is now known as nickoe | 19:04 | |
| nickoe | sensille, but how would you use it against a non-flash chip? | 19:05 |
| *** nickoe86 <nickoe86!~nickoe@2a06:4004:21c3::cf9> has quit IRC (Ping timeout: 246 seconds) | 19:06 | |
| sensille | Hoernchen: besides the 5a75 i also use the rv901t. there timing closure is a bit easier to achieve | 19:06 |
| nickoe | Do I need to define a Module for the phy with the stream things that does the logic for: "The LMX2594 is programmed using 24-bit shift registers. The shift register consists of a R/W bit (MSB), followed by a 7-bit address field and a 16-bit data field. For the R/W bit, 0 is for write, and 1 is for read. The address field ADDRESS[6:0] is used to | 19:09 |
| nickoe | decode the internal register address. The remaining 16 bits form the data field DATA[15:0]. While CSB is low, serial data is clocked into the shift register upon the rising edge of clock (data is programmed MSB first). When CSB goes high, data is transferred from the data field into the selected register bank." | 19:09 |
| nickoe | Above description is from the datasheet. | 19:09 |
| Hoernchen | is nextpnr-xilinx usable for the rv901t? | 19:10 |
| Hoernchen | mh, apparently not, only 7 series | 19:15 |
| zyp | sensille, on the 5a75, are you building for speedgrade 6 or 8? | 19:20 |
| *** nickoe11 <nickoe11!~nickoe@2a06:4004:21c3::cf9> has joined #litex | 19:21 | |
| sensille | Hoernchen: no, ISE | 19:22 |
| Hoernchen | yeah the whole appeal is the open source toolchain (and the 15€ board) | 19:22 |
| zyp | ecp5 speedgrades doesn't seem to matter much in real life, so in practice you can just build for 8 regardless of what chip you've got | 19:22 |
| Hoernchen | oh, they do not? | 19:22 |
| Hoernchen | i'm kinda trying to, well, at least be on the safe side as far as timings are cocerned before trying to figure out why the eth is lossy | 19:23 |
| *** nickoe2 <nickoe2!~nickoe@2a06:4004:21c3::cf9> has joined #litex | 19:23 | |
| sensille | zyp: -6 | 19:23 |
| zyp | see e.g. https://github.com/smunaut/ecp5-speed/blob/master/results.txt | 19:24 |
| sensille | yeah, i also heard timing estimate in nextpnr is quite conservative | 19:24 |
| *** nickoe <nickoe!~nickoe86@2a06:4004:21c3::cf9> has quit IRC (Ping timeout: 246 seconds) | 19:24 | |
| sensille | oh, but the board actually has -7 | 19:25 |
| Hoernchen | looks like the easiest way to ensure the timing works out is to go for 1.2v vcore and pretend it's a 5g part? | 19:26 |
| zyp | so far I haven't had any issues building my ethernet stuff for colorlight i5 for -8 | 19:26 |
| *** nickoe11 <nickoe11!~nickoe@2a06:4004:21c3::cf9> has quit IRC (Ping timeout: 246 seconds) | 19:27 | |
| Hoernchen | interesting | 19:28 |
| _florent_ | Hoernchen: On a colorlight, if you want to use Etherbone, use a 32-bit datapath, this will allow you to go down to 31.25MHz sys_clk_freq (125MHz/4) | 19:31 |
| Hoernchen | how? | 19:31 |
| Hoernchen | isn't that what the data_width for etherbone already does? | 19:31 |
| zyp | IIRC there's a `with_sys_datapath` argument somewhere | 19:32 |
| _florent_ | yes, set data_width=32 in add_etherbone | 19:33 |
| _florent_ | this will enable with_sys_datapath | 19:33 |
| Hoernchen | that appears to be what https://github.com/enjoy-digital/colorlite/blob/master/colorlite.py#L82 is already doing | 19:34 |
| Hoernchen | can I just go for 31.25 for sys_clk_freq or is there some magical way to specify this as fraction of the eth clock? | 19:36 |
| _florent_ | I would still recommend a sys_clk_freq a bit higher than the minimum. | 19:38 |
| Hoernchen | 40Mhz appears to work, at least one of 10 seeds manages to pass 40/125 | 19:39 |
| Hoernchen | i'm just puzzled why the project defaults to 50/125 and older github issues make it sound like those frequencies used to work in the past | 19:39 |
| Hoernchen | but as i'Ve just learned the speed grade does not really matter so i guess violations should be fine anyway | 19:40 |
| _florent_ | The project was tested on a 7.0, I'm not well aware of the difference with 8.2. Is the FPGA the same size? Also, the RGMII timings maybe also need to be adapted. | 19:42 |
| nickoe2 | Is this not the way to use LiteSPI? https://dpaste.com/8H95F27QL.txt | 19:44 |
| Hoernchen | yeah i gave a few values of tx_delay a try to see if anything changes, but, apparently, not really | 19:44 |
| nickoe2 | I get AttributeError: 'Record' object has no attribute 'len' | 19:44 |
| Hoernchen | the fpga is the same and the same speed grade, and according to the other repo the hw had little changes | 19:45 |
| Hoernchen | different eth phy tho | 19:45 |
| *** nickoe2 is now known as nickoe | 19:45 | |
| nickoe | Does the gang primer 20k support litex_server --jtag? | 20:09 |
| *** cr1901_ <cr1901_!~cr1901@2601:8d:8600:226:5076:abde:6458:a5ba> has joined #litex | 20:18 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:226:9d3b:a53f:a76b:d5bd> has quit IRC (Ping timeout: 248 seconds) | 20:22 | |
| *** cr1901_ is now known as cr1901 | 20:56 | |
| *** nickoe <nickoe!~nickoe@2a06:4004:21c3::cf9> has quit IRC (Quit: Client closed) | 21:27 | |
| *** nickoe <nickoe!~nickoe@2a06:4004:21c3::cf9> has joined #litex | 21:27 | |
| *** Foxyloxy <Foxyloxy!~foxyloxy@cpc151593-shef16-2-0-cust671.17-1.cable.virginm.net> has joined #litex | 21:45 | |
| *** Foxyloxy <Foxyloxy!~foxyloxy@cpc151593-shef16-2-0-cust671.17-1.cable.virginm.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 22:23 | |
| Hoernchen | sensille, https://dpaste.org/WdVsd - your patch didn't help, as far as I can tell | 22:25 |
| tpb | Title: dpaste/WdVsd (Console/Bash Session) (at dpaste.org) | 22:25 |
| *** Foxyloxy <Foxyloxy!~foxyloxy@cpc151593-shef16-2-0-cust671.17-1.cable.virginm.net> has joined #litex | 22:49 | |
| *** cr1901_ <cr1901_!~cr1901@2601:8d:8600:226:c051:a10a:e0b1:d641> has joined #litex | 23:12 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:226:5076:abde:6458:a5ba> has quit IRC (Ping timeout: 248 seconds) | 23:15 | |
| *** Foxyloxy <Foxyloxy!~foxyloxy@cpc151593-shef16-2-0-cust671.17-1.cable.virginm.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 23:37 | |
| *** Foxyloxy <Foxyloxy!~foxyloxy@cpc151593-shef16-2-0-cust671.17-1.cable.virginm.net> has joined #litex | 23:42 | |
| *** Foxyloxy <Foxyloxy!~foxyloxy@cpc151593-shef16-2-0-cust671.17-1.cable.virginm.net> has quit IRC (Client Quit) | 23:42 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!