| *** tpb has joined #symbiflow | 00:00 | |
| *** Degi_ has joined #symbiflow | 00:02 | |
| *** Degi has quit IRC | 00:03 | |
| *** Degi_ is now known as Degi | 00:03 | |
| *** ASHR has quit IRC | 00:24 | |
| *** citypw has joined #symbiflow | 01:13 | |
| *** ASHR has joined #symbiflow | 01:34 | |
| *** citypw has quit IRC | 02:19 | |
| *** gsmecher has joined #symbiflow | 03:10 | |
| *** TMM has quit IRC | 03:11 | |
| *** TMM has joined #symbiflow | 03:11 | |
| *** ASHR has quit IRC | 03:35 | |
| *** Degi_ has joined #symbiflow | 04:01 | |
| *** Degi has quit IRC | 04:02 | |
| *** Degi_ is now known as Degi | 04:03 | |
| *** gsmecher has quit IRC | 04:19 | |
| *** kraiskil has joined #symbiflow | 06:52 | |
| *** kgugala has joined #symbiflow | 07:24 | |
| *** kgugala_ has quit IRC | 07:24 | |
| *** kraiskil has quit IRC | 07:30 | |
| *** kgugala has quit IRC | 07:47 | |
| *** kgugala has joined #symbiflow | 07:47 | |
| *** kraiskil has joined #symbiflow | 08:22 | |
| *** kraiskil has quit IRC | 08:31 | |
| *** lopsided98 has joined #symbiflow | 10:05 | |
| *** lopsided98_ has quit IRC | 10:05 | |
| *** kgugala_ has joined #symbiflow | 10:28 | |
| *** kgugala has quit IRC | 10:30 | |
| *** ssb has quit IRC | 10:39 | |
| *** ssb has joined #symbiflow | 10:45 | |
| *** ssb has quit IRC | 10:48 | |
| *** ssb has joined #symbiflow | 10:51 | |
| *** citypw has joined #symbiflow | 10:51 | |
| *** kgugala has joined #symbiflow | 11:09 | |
| *** kgugala_ has quit IRC | 11:13 | |
| *** kraiskil has joined #symbiflow | 12:02 | |
| *** TMM has quit IRC | 12:05 | |
| *** TMM has joined #symbiflow | 12:05 | |
| *** ayazar1 has joined #symbiflow | 12:14 | |
| *** kraiskil has quit IRC | 12:26 | |
| *** citypw has quit IRC | 14:48 | |
| mithro | Lofty: BTW - I have been meaning to mention that there is no reason that Mistral couldn't become a SymbiFlow project if you wanted. Intel is a low priority for my team at the moment but there could be opportunities to get someone like Microsoft onboard or something through the CHIPS Alliance (that Intel are part of). Intel are the biggest funder of the VtR and behind the https://www.nexusfpga.org/ project. | 15:11 |
|---|---|---|
| tpb | Title: Intel/VMware Crossroads 3D-FPGA Academic Research Center | Home (at www.nexusfpga.org) | 15:11 |
| mithro | Lofty: also fine to continue to do your own thing | 15:14 |
| Lofty | From my own contacts at Intel, trying to involve them is asking for a legal fight, I think | 15:15 |
| *** gromero has quit IRC | 15:30 | |
| Lofty | mithro: I think the thing I've learned is that Intel OSTC are very friendly to FOSS tooling and Intel PSG absolutely hate it | 15:33 |
| *** kgugala_ has joined #symbiflow | 16:31 | |
| *** kgugala has quit IRC | 16:33 | |
| *** kgugala has joined #symbiflow | 16:36 | |
| *** kgugala_ has quit IRC | 16:38 | |
| *** kgugala_ has joined #symbiflow | 17:05 | |
| *** kgugala has quit IRC | 17:07 | |
| *** kgugala has joined #symbiflow | 17:20 | |
| *** kgugala_ has quit IRC | 17:23 | |
| *** bjorkintosh has quit IRC | 18:34 | |
| *** kraiskil has joined #symbiflow | 18:57 | |
| *** kraiskil has quit IRC | 19:11 | |
| *** ayazar1 has quit IRC | 19:15 | |
| *** ayazar1 has joined #symbiflow | 19:16 | |
| *** jokus_malus[m] is now known as jokus_malus | 20:15 | |
| *** jokus_malus has quit IRC | 20:19 | |
| *** jokus_malus has joined #symbiflow | 20:19 | |
| nickoe | Anyone that have use litedram and wondered why data seems to be reversed in bursts according to the input address? | 20:21 |
| sf-slack1 | <cjearls> Reversed at a byte-granularity of bit-granularity? | 20:24 |
| nickoe | 2 secs | 20:31 |
| nickoe | Originally I found this discrepancey between the sim and target https://i.snipboard.io/geh8WT.jpg | 20:32 |
| nickoe | I get 4x32 bits from the DMA thing, but I get the lowest address last. Compare https://dpaste.com/E87NKBLM6 vs https://i.snipboard.io/Dqf8TW.jpg | 20:32 |
| tpb | Title: dpaste: E87NKBLM6 (at dpaste.com) | 20:32 |
| nickoe | cjearls, so I guess that is word-granularity? | 20:33 |
| nickoe | This is my code https://github.com/nickoe/litex-boards/blob/f3090247db0a7d26291c39860eede3a3aa46ca64/litex_boards/targets/mars_ax3_custom.py#L133-L152 | 20:34 |
| nickoe | I wonder if there is something fundemental that I overlook. | 20:35 |
| *** ayazar1 has quit IRC | 20:43 | |
| sf-slack1 | <butta> nickoe: This is happening because of the conversion from 128-bit native DRAM width to the 32-bit width requested here: https://github.com/nickoe/litex-boards/blob/f3090247db0a7d26291c39860eede3a3aa46ca64/litex_boards/targets/mars_ax3.py#L229 The solution is to add the parameter 'reverse=True' to the get port function call which will switch the order of 32-bit words when splitting a 128-bit word. | 21:18 |
| nickoe | butta Hmm, ok cool. I will try that straight away! | 21:23 |
| nickoe | I was not aware of that option. | 21:25 |
| nickoe | butta, do you know why this is different in simulation? | 21:28 |
| sf-slack1 | <butta> nickoe: I'm really not sure, but it could have to do with simulation not modeling DRAM precisely | 21:30 |
| nickoe | wwooooooowww It works! | 21:30 |
| sf-slack1 | <butta> Great to hear! | 21:30 |
| nickoe | Thank you very much for the hint! | 21:30 |
| nickoe | I have been, mmm, debugging this all day long | 21:31 |
| nickoe | I mean, until I found above thing about it consistently returning the correct data in chunks, but reversed | 21:31 |
| nickoe | butta, I also created the issue here to track it when writing to this channel. I didn't mention your nick there, but I was not sure if you were ok being called out so I left it out for now. https://github.com/enjoy-digital/litedram/issues/251#issuecomment-835897878 | 21:39 |
| sf-slack1 | <butta> nickoe: It would be good to figure out why simulation is different. I unfortunately have very little experience using the litex simulator so I probably wont be much help there. You can mention me on github if you feel like it, my username is andrewb1999 | 21:44 |
| nickoe | thanks | 21:44 |
| nickoe | Is there a way to offload or distribute symbiflow synthesis? | 22:40 |
| Lofty | nickoe: no, not really. I think nextpnr can utilise multiple cores to assist placement, but that's generally pretty fast anyway. | 23:15 |
| nickoe | ok | 23:16 |
| Lofty | If you mean Yosys specifically, then the core representation is intrinsically not thread safe; you'd need to write a whole new program for...limited gains. | 23:16 |
| Lofty | Even the commercial tools don't utilise multiple threads much in synthesis | 23:17 |
| nickoe | Lofty: Ok, I was more interested in it from a user perspective. So I mean, if it was supported somehow and I didn't know about it -- I would not use it and be robbed by time. Possibly. :D | 23:20 |
| Lofty | Yosys is a pretty fast synthesis tool I've found | 23:20 |
| Lofty | There's not a lot of time to rob | 23:20 |
| mithro | Surelog actually supports some parallel SystemVerilog parsing | 23:21 |
| Lofty | I mean, as a Yosys developer I'd love to talk about anything that seems subjectively slow to you | 23:23 |
| nickoe | Lofty: To be honest I am not using symbiflow right now, just trying to make my project work. So using litex directly with vivado, but I will ned to try it out with symbiflow. I did play around with the symbiflow exaples around december/january, so I am familiar with it by now. | 23:26 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
