Friday, 2020-07-31

*** tpb has joined #symbiflow00:00
*** proteusguy has quit IRC00:33
*** proteusguy has joined #symbiflow00:46
*** Degi has quit IRC00:50
*** Degi has joined #symbiflow00:51
*** rvalles_ has joined #symbiflow01:34
*** rvalles has quit IRC01:35
*** citypw has joined #symbiflow04:20
*** andrewb1999 has quit IRC04:46
*** sjkelly1 has quit IRC05:12
*** enriq has joined #symbiflow06:05
*** _whitelogger has quit IRC06:21
*** _whitelogger has joined #symbiflow06:23
*** kgugala_ has joined #symbiflow07:17
*** kgugala__ has joined #symbiflow07:19
*** kgugala has quit IRC07:19
*** kgugala_ has quit IRC07:22
*** OmniMancer has joined #symbiflow07:24
*** az0re has quit IRC07:36
*** jordigw has quit IRC07:40
sf-slack<timo.callahan> Hi @mholenko, I'm still working on LiteX differences between timvideos and the tensorflow demo.   It seems the base CSR address has changed -- I see 0x8200000 and 0xE0000000, respectively.   The overlay created by generate-zephyr-dts.py doesn't have any information about these....is the CSR base address determined somehow else?   Thanks!08:03
sf-slack<kgugala> @timo.callahan litex_term requires software running on the programmed CPU that will receive the UART transferred data and write it to RAM. If you want to use it with your Zephyr app, you need to include this functionality in the app (probably you can "borrow" some code from LiteX' Bios)08:09
*** kraiskil has joined #symbiflow08:19
*** xtro has quit IRC08:25
sf-slack<mholenko> @timo.callahan: what addresses do you see in the generated overlay DT (it's located in buildenv's build/platform/software/zephyr directory)? The `reg` property should already contain a value that is based on the CSR base address (i.e., it should be 0x8200000/0xE0000000 plus some offset)08:30
*** jordigw has joined #symbiflow08:31
*** enriq has quit IRC08:40
*** craigo has quit IRC08:44
*** enriq has joined #symbiflow08:45
*** kraiskil has quit IRC08:54
*** enriq has quit IRC09:16
*** kraiskil has joined #symbiflow09:32
*** enriq has joined #symbiflow09:41
*** proteus-guy has joined #symbiflow10:23
*** enriq has quit IRC11:02
*** _whitelogger has quit IRC11:12
*** _whitelogger has joined #symbiflow11:14
*** sjkelly1 has joined #symbiflow11:37
*** kraiskil has quit IRC12:26
*** enriq has joined #symbiflow12:57
*** citypw has quit IRC13:06
*** kraiskil has joined #symbiflow13:13
*** kraiskil has quit IRC13:18
*** kraiskil has joined #symbiflow13:24
*** enriq has quit IRC13:32
*** andrewb1999 has joined #symbiflow13:36
*** kraiskil has quit IRC13:37
*** kraiskil has joined #symbiflow13:57
LoftyPing kgugala__14:05
sf-slack<kgugala> ping about what?14:06
LoftyQuickLogic14:06
LoftyOr specifically synth_quicklogic14:06
sf-slack<kgugala> but what was the question?14:07
LoftyThe flop mapping can be simplified a lot by using the `dfflegalize` pass that was recently introduced14:07
LoftyAdditionally, you should not map latches unless the fabric is glitchless, because Yosys assumes if latches are mapped they are glitchless14:08
sf-slack<kgugala> I'm working on this right now, just rebased the PR14:08
LoftyYeah, I saw, just wanted to make sure you were aware14:09
sf-slack<kgugala> need to introduce the dff/latch changes and test it14:09
*** proteus-guy has quit IRC14:10
LoftyWhat do the QuickLogic flops initialise to? It's not mentioned in the EOS S3 TRM, as far as I can tell14:10
sf-slack<kgugala> to 0 AFAIK, but have to check this14:12
LoftyThen all you need really is to add `dfflegalize -cell $_DFFSRE_PPPP_ 0` to your flow and map one cell14:13
sf-slack<kgugala> thanks for the hints, I'll update the code and push the changes14:20
*** proteus-guy has joined #symbiflow14:22
*** enriq has joined #symbiflow14:23
tntkgugala: Is the direct LUT -> FF path implemented now ?   Also true LUT4 mapping (rather than mapping to 2 LUT3 + FMUX) ?14:39
sf-slack<kgugala> @tnt: LUT4 works, LUT -> FF support is here https://github.com/antmicro/symbiflow-arch-defs/tree/lut-ff-direct, will open a PR once this https://github.com/QuickLogic-Corp/python-symbiflow-v2x/pull/3  is merged14:42
tpbTitle: Allow specification of multiple pack patterns by mkurc-ant · Pull Request #3 · QuickLogic-Corp/python-symbiflow-v2x · GitHub (at github.com)14:42
tntkgugala: Ah nice tx for the pointers.14:43
*** kraiskil has quit IRC15:00
-_whitenotifier-b- [sv-tests] hzeller opened issue #972: Sorting tool columns: doesn't take partial passing into account - https://git.io/JJamV15:00
*** proteus-guy has quit IRC15:05
*** kraiskil has joined #symbiflow15:13
*** enriq has quit IRC15:15
*** enriq has joined #symbiflow15:24
*** enriq has quit IRC15:37
*** craigo has joined #symbiflow15:45
*** enriq has joined #symbiflow15:53
-_whitenotifier-b- [fpga-tool-perf] mithro opened issue #198: Define a set of tests which run on all devices - https://git.io/JJas616:00
-_whitenotifier-b- [FPGA-Tool-Performance-Visualization-Library] TypingKoala opened issue #15: Legacy Icestorm Processor - https://git.io/JJasi16:01
-_whitenotifier-b- [fpga-tool-perf] mithro opened issue #199: Make sure a test which works for a35t works for all a35t compatible toolchains - https://git.io/JJasx16:02
*** proteus-guy has joined #symbiflow16:09
andrewb1999Does anyone know if it's possible to constrain a top level io to multiple io pads in VPR?16:12
*** acomodi has joined #symbiflow16:15
sf-slack<acomodi> I think this is impossible. As far as I know the io blocks are assigned uniquely to one grid location16:19
*** kraiskil has quit IRC16:34
*** OmniMancer has quit IRC16:49
*** enriq has quit IRC16:51
*** kraiskil has joined #symbiflow16:54
sf-slack<benglines1> I've been having trouble getting bitread to work with Project U-Ray. Here's what I'm doing to run it: `../prjuray/third_party/prjuray-tools/build/tools/bitread --part_file ../prjuray/database/zynqusp/xczu3eg-sfvc784-1-e/part.yaml -o bitstream.bits -z -y ../prjuray/inverter_example_zu3eg/inverter_example.bit`   And this is what I'm getting for the output: `Bitstream size: 5865840 bytes` `Config size: 1466409 words`16:54
sf-slack`Part file not found or invalid`  To me it looks like the tool built correctly, and the path to the part seems to be correct to me. Does the path that I use to the part file seem correct? Does bitread expect the part.yaml file or something else?16:54
sf-slack<tmichalak> @benglines1 Yes, it requires part.yaml. What is missing in the command you pasted is --architecture UltraScalePlus17:08
sf-slack<tmichalak> This is because the tool supports Spartan6, Series7, US and US+ and Series7 is default for backward compatibility with prjxray17:10
*** xtro has joined #symbiflow17:15
sf-slack<benglines1> @tmichalak That seemed to work. Thanks!17:15
*** kraiskil has quit IRC17:19
*** enriq has joined #symbiflow17:24
*** proteus-guy has quit IRC17:25
*** FireFox317 has joined #symbiflow17:36
sf-slack<timo.callahan> Thanks @kgugala, so basically the serial boot mechanism, but for data.   The code on Arty would print the serialboot keyword to uart, then lxterm responds.18:13
*** acomodi has quit IRC18:25
*** FFY00 has quit IRC18:29
*** FFY00 has joined #symbiflow18:30
*** xtro has quit IRC19:47
*** FireFox317 has quit IRC20:58
*** FireFox317 has joined #symbiflow20:59
*** kraiskil has joined #symbiflow21:10
-_whitenotifier-b- [FPGA-Tool-Performance-Visualization-Library] TypingKoala opened issue #16: HydraFetcher unable to fetch meta.json of older builds - https://git.io/JJa2e21:19
*** kraiskil has quit IRC21:22
*** maartenBE has quit IRC22:58
*** maartenBE has joined #symbiflow22:58

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!