Tuesday, 2020-07-07

*** tpb has joined #symbiflow00:00
*** Degi has quit IRC00:17
*** Degi has joined #symbiflow00:18
FFY00litghost, are you talking to me?01:16
FFY00that repo build nightly packages every day01:17
FFY00what I am proposing is to notify the channel if for some reason any of them happens to fail01:18
FFY00if one fails, the build is stopped01:18
FFY00so you would get a max of one notification per day01:18
HackerFooFFY00: Do you just use the latest commit for everything? That's going to break on anything that requires a coordinated update.01:36
FFY00yes01:36
FFY00there is no way around it01:37
FFY00if it happens in the same day then there is no issue01:37
HackerFooWhy? Can't you specify the revision?01:37
FFY00yes, but I won't be updating the revisions manually01:37
*** Degi has quit IRC01:37
*** Degi has joined #symbiflow01:40
HackerFooThis might not produce a useful set of packages as often as you'd hope. At least in my experience.01:43
*** az0re has quit IRC02:11
FFY00well, yes02:29
FFY00the that have releases are in the official repos02:30
FFY00the others are just provided as is02:30
FFY00I don't have time to be frequently updating the packages02:31
FFY00and that would force me to keep track of what is happening in the upstream02:32
*** epony has quit IRC03:15
*** eponym has joined #symbiflow03:16
*** craigo has quit IRC03:23
*** eponym has quit IRC03:49
*** epony has joined #symbiflow03:50
*** andrewb1999 has quit IRC03:52
*** kgugala_ has joined #symbiflow05:10
*** kgugala has quit IRC05:14
*** citypw has joined #symbiflow05:21
*** kgugala_ has quit IRC05:32
*** kgugala has joined #symbiflow05:32
*** enriq has joined #symbiflow06:32
*** epony has quit IRC06:42
*** epony has joined #symbiflow06:43
*** kgugala_ has joined #symbiflow07:10
*** kgugala has quit IRC07:12
*** enriq has quit IRC07:21
*** OmniMancer has joined #symbiflow07:27
*** andrewb1999 has joined #symbiflow07:35
*** enriq has joined #symbiflow08:25
*** kgugala_ has quit IRC09:23
*** kgugala has joined #symbiflow09:24
*** mangelis has quit IRC09:25
*** mangelis has joined #symbiflow09:25
*** enriq has quit IRC09:29
*** enriq has joined #symbiflow09:54
*** enriq has quit IRC10:35
*** enriq has joined #symbiflow10:40
*** enriq has quit IRC10:56
*** enriq has joined #symbiflow11:00
*** enriq has quit IRC11:10
*** enriq has joined #symbiflow11:52
*** enriq has quit IRC12:10
*** sky36 has joined #symbiflow12:20
*** craigo has joined #symbiflow12:21
sky36Hey! struggling to get the symbiflow-examples running on my arty7_100t. The tests in symbiflow-arch-defs do have support. I presume there are problems in my environment. Unsure how to move over the built files for the arch-defs into the /opt/symbiflow/xc7/... directory in an appropriate manner to add support.12:23
*** enriq has joined #symbiflow12:26
sf-slack<acomodi> Hi @sky36. Currently 100T is not yet supported in the symbiflow-examples. However, if you have built the 100T in arch-defs already, you could create a new directory under `/opt/symbiflow/.../share/symbiflow/arch/`. The files you would need to copy there are the following12:27
sf-slack<acomodi> arch.timing.xml  rr_graph_xc7a100t_test.lookahead.bin  rr_graph_xc7a100t_test.place_delay.bin  rr_graph_xc7a100t_test.rr_graph.real.bin  vpr_grid_map.csv12:27
sf-slack<acomodi> as well as the package-related directory containing the pinmap.csv file12:28
sf-slack<acomodi> Actually, this tar would contain the data necessary to have the 100T running12:29
sf-slack<acomodi> https://storage.googleapis.com/symbiflow-arch-defs/artifacts/prod/foss-fpga-tools/symbiflow-arch-defs/continuous/install/31/20200706-205356/symbiflow-arch-defs-install-6f9c6918.tar.xz12:29
*** andrewb1999 has quit IRC12:36
sky36@acomodi - the typical format from the github instructions produces /share/arch/ rather than /share/symbiflow/arch/13:07
sky36Also, the github tar comes with the xray database13:07
sky36I am attempting to move the files from the tar you provided into the older structure13:08
sky36(I attempted to start fresh, and suffered errors with the 'pack' command13:08
sf-slack<acomodi> Yeah, there have been some changes in the install package which need to be integrated. This is a current work in progress. At the moment, it would be required to just move the files in the old structure as you did13:09
sf-slack<acomodi> what kind of errors are you seeing?13:09
*** kgugala_ has joined #symbiflow13:10
*** kgugala has quit IRC13:13
*** enriq has quit IRC13:18
sky36Currently yosys is telling me that it cannot load the xdc.so plugin13:21
sky36when I attempt to build the counter example13:21
sky36ERROR: Can't load module `./xdc': /opt/symbiflow/xc7/conda/envs/xc7/bin/../share/plugins/xdc.so: cannot open shared object file: No such file or directory13:21
*** enriq has joined #symbiflow13:22
sf-slack<acomodi> Ok, there have been an update with the SymbiFlow/yosys version. I am experiencing the same issue with the latest conda package right now. To overcome this, you could set a specific yosys version which work (this needs to be done also for yosys-plugins.13:23
sf-slack<acomodi> GIve me a second to retrieve the correct versions13:23
sky36more specifically: https://privatebin.net/?4781cfa6cec19953#5kFd7Qb7dbtZEqCKGYFgWSUZbL9HUaJMzbBwBenzvZF2 - thanks a lot!13:24
tpbTitle: PrivateBin (at privatebin.net)13:24
sf-slack<acomodi> All right, so the conda package version of yosys would be `0.8_3925_g6bccd35a` . I see that the yosys-plugins already have pinned version, so no need to update that13:26
sf-slack<acomodi> The version needs to be added to the environment.yml file under `examples/xc7`13:26
sky36excellent! - it seems to have gone further this time. Now I am suffering problems with vpr13:36
*** andrewb1999 has joined #symbiflow13:36
sky36https://privatebin.net/?547146b57c917085#4ATtmAR3GRPRSCWGftKpWunkgtGnhiLjNdsQjxgscfAV13:37
tpbTitle: PrivateBin (at privatebin.net)13:37
sky36Unsure whether I should use gdb to find the source of the segmentation fault13:37
*** kgugala_ has quit IRC13:39
sf-slack<acomodi> Ah, right... forgot about that. The VPR version used in the current symbiflow-examples is out of date and compatible with the "old" install package. If you wish to use the newer architecture (100T) You would need to update also VTR (this will generate issues with the other devices though)13:39
*** kgugala has joined #symbiflow13:39
sf-slack<acomodi> `8.0.0.rc2_4003_g8980e4621` this version should work fine13:40
sky36Ah - my next problem is unexpected arguments to the vpr command13:43
sky36cd build && pack -e top.eblif -d xc7a100t_test -s /home/timothy/FPGA/SymbiFlow/symbiflow-examples/examples/xc7/counter_test/counter.sdcVPR FPGA Placement and Routing.Version: 8.1.0-dev+8980e4621Revision: v8.0.0.rc2-4003-g8980e4621Compiled: 2020-07-06T22:51:58Compiler: GNU 7.3.0 on Linux-4.15.0-1028-gcp x86_64Build Info: Release IPO13:43
sky36VTR_ASSERT_LEVEL=2University of [email protected] is free open source code under MIT license.Unexpected command-line argument '--quick_check_route'usage: vpr architecture circuit [--pack] [--place] [--route] [--analysis]        [--disp {on, off}] [--save_graphics {on, off}]        [--graphics_commands13:43
sky36GRAPHICS_COMMANDS] [-h] [--version]        [--device DEVICE_NAME] [-j NUM_WORKERS] [--timing_analysis {on, off}]        [--disable_errors DISABLE_ERRORS] [--suppress_warnings SUPPRESS_WARNINGS]        [--route_chan_width CHANNEL_WIDTH] [OTHER_OPTIONS ...]make: *** [Makefile:23: build/top.net] Error 113:43
sky36hm - there should be a nicer way to paste this13:44
*** TMM has joined #symbiflow13:44
sky36anyway, I've updated the bin folder to the one within the tar and am getting a Segfault again13:44
sf-slack<acomodi> That agument would need to be `--check_route quick`13:44
sky36excellent, now place seems to be failing.13:46
sky36Went into the bin folder and corrected the VPR options13:46
sky36https://privatebin.net/?50c95939707d0daa#4rj7Dd5E9bTwrj49cwa8527jcG2yD1QPHa4h6Qq61JH313:47
tpbTitle: PrivateBin (at privatebin.net)13:47
sky36something is missing somewhere13:47
TMMhi all, I've been looking at the symbiflow-litex-linux example, but I can't actually get Linux to build. I'm trying to generate a new SoC with litex using their linux-on-litex repository but it doesn't really seem to have support for symbiflow, and a naive attempt to get it to use symbiflow (by changing how the board gets initialized) doesn't really work as there's a dependency on vivado hardcoded in one of the build scripts. This is my first13:47
TMMforay into anything symbiflow or FPGA to begin with so I'm kind of unsure where to start unraveling this. I'm getting some help on #litex also which I'm trying to use. I was kind of hoping that someone here maybe documented some of the steps they took?13:47
sky36@acomodi I updated the prjxray folder to the latest version in the github, I get the ame error with the old and new versions13:48
sf-slack<acomodi> Ya, from the tarball linked you would need take the `prjxray_create_place_constraints`  script and replace the one in the "old" install tar13:48
*** enriq has quit IRC13:54
sky36Slowly making progress! had to also move over generate_constraints and edit the grid and pinmap paths to point to the right directories13:55
sky36placing worked, now we're routing13:55
sf-slack<acomodi> Great, hopefully the installation step is going to be updated soon, so all these manual steps you have performed will not be required anymore to be able to build for the 100T devices as well13:56
sky36I certainly hope so! - on the very last step right now13:57
sky36bitstream is suiciding13:57
sky36prjxray.fasm_assembler.FasmLookupError: Segment DB LIOB33, key LIOB33.IOB_Y0.LVCMOS12_LVCMOS15_LVCMOS18_LVCMOS25_LVCMOS33_LVTTL_SSTL135.IN_ONLY not found from line 'LIOB33_X0Y93.IOB_Y0.LVCMOS12_LVCMOS15_LVCMOS18_LVCMOS25_LVCMOS33_LVTTL_SSTL135.IN_ONLY'13:57
sf-slack<acomodi> Ok, one last step, you would need to update the database with the most recent one13:58
sky36Yep - I cloned the pjxray from github13:58
*** enriq has joined #symbiflow14:01
sf-slack<acomodi> Ok, so from the `prjxray/database` dir grab the artix7 directory and replace the one under `symbiflow/xc7/install/share/prjxray/prjxray-db`14:02
-_whitenotifier-b- [symbiflow-arch-defs] acomodi opened issue #1578: Remove `test` from full-devices that are packed in the install tarball - https://git.io/JJtCp14:05
sky36yep - cd build && write_bitstream -d artix7 -f top.fasm -p xc7a100tcsg324-1 -b top.bitWriting bitstream ...Traceback (most recent call last):  File "/opt/symbiflow/xc7/install/bin/python/prjxray/utils/fasm2frames.py", line 306, in <module>    main()  File "/opt/symbiflow/xc7/install/bin/python/prjxray/utils/fasm2frames.py", line 294, in main14:06
sky36run(  File "/opt/symbiflow/xc7/install/bin/python/prjxray/utils/fasm2frames.py", line 199, in run    raise fasm_assembler.FasmLookupError('\n'.join(missing_features))prjxray.fasm_assembler.FasmLookupError: Segment DB LIOB33, key LIOB33.IOB_Y0.LVCMOS12_LVCMOS15_LVCMOS18_LVCMOS25_LVCMOS33_LVTTL_SSTL135.IN_ONLY not found from line14:06
sky36'LIOB33_X0Y93.IOB_Y0.LVCMOS12_LVCMOS15_LVCMOS18_LVCMOS25_LVCMOS33_LVTTL_SSTL135.IN_ONLY'make: *** [Makefile:35: build/top.bit] Error 1```14:06
sky36oh dear - how do I paste code?14:06
sky36same issue14:06
sky36pjxray-db is correctly updated, with the old version it doesnt see "xc7a100tcsg324" at all14:06
sf-slack<acomodi> Hmmm, probably then is the other way around, Try to get the older version of the db (the one found in the original install tarball) and grab the xc7a100tcsg324 from the new one14:10
sky36https://privatebin.net/?99c696215ce8376a#Fu7uEBeC2HqeG3QE6xC4pcC5cHQAXuFye4YfcRbpNGSr14:12
tpbTitle: PrivateBin (at privatebin.net)14:12
sky36its caught on fire :D14:13
sky36even more lookup errors - hmmm14:13
sf-slack<acomodi> Aha, got it, it is actually a fasm2frames issue. I was wrong. The updated version of the db was all right14:14
sf-slack<acomodi> You would need to replace the fasm2frames script from the prjxray updated repo (prjxray/utils/fasm2frames.py) to the /bin/python/ dir14:15
sky36hmm interesting...14:17
sky36cool! got the bitstream file14:21
sf-slack<acomodi> Nice!14:21
sky36Does symbiflow have a tool to flash it - or14:21
sf-slack<acomodi> You can use `xc3sprog`14:22
sf-slack<acomodi> xc3sprog -c nexys4 <bitstream-name>.bit14:23
*** enriq has quit IRC14:23
sf-slack<acomodi> http://xc3sprog.sourceforge.net/14:24
tpbTitle: xc3sprog (at xc3sprog.sourceforge.net)14:24
sky36Acomodi - thank you very much14:36
sky36really appreciate it - it would've taken me days to figure this out on my own14:36
sky36can finally have a better, more streamlined workflow without using the nasty vivado cringe suite14:37
sky36Do you have any idea of timescale of when the 100t will be added to the examples?14:51
sf-slack<acomodi> @sky36 No problem ;) Regarding the timescale, there are a couple of things to get fixed. Probably it is in the order of days, worst case a few weeks.15:06
*** enriq has joined #symbiflow15:07
*** OmniMancer has quit IRC15:20
sky36Amazing, i'm very optimistic. Thanks to everyone for a lot of the hard work that's gone into this - I didn't believe an open source toolchain existed when I first heard about it!15:27
*** enriq has quit IRC15:28
*** enriq has joined #symbiflow15:36
litghostTMM: Which instructions were you following?15:49
litghostTMM: There is a A50T LiteX linux example in https://github.com/SymbiFlow/symbiflow-examples/tree/master/examples/xc7/linux_litex_demo15:49
tpbTitle: symbiflow-examples/examples/xc7/linux_litex_demo at master · SymbiFlow/symbiflow-examples · GitHub (at github.com)15:49
TMMlitghost: it doesn't actually use litex but has a prebuild verilog output generated by litex16:57
litghostTMM: There are some outstanding issues around consuming the output of LiteX directly that we are working on.  Some have open PR's, and some are in active development16:59
litghostTMM: I can see if I can find the notes about the outstanding changes between the LiteX output and something that works16:59
TMMlitghost: ok, that would be great because the example isn't entirely complete either. The json file to describe the images is missing, and lxterm only runs at 115200 at most. So there's some issues with the example even. Or I did something incredibly dumb. I have to admit that this is the first thing I've ever done with an FPGA at all. I'm trying to work out how all of this fits together, it's a little daunting at first.17:00
litghostTMM: Absolutely.  We are actively trying to burn down issues that prevent the LiteX output from working directly with the toolchain.17:01
*** adjtm has joined #symbiflow17:03
litghostTMM: We actually have an issue tracking what you are describing here: https://github.com/SymbiFlow/symbiflow-examples/issues/12 Work to support that issue is on going17:04
sf-slack<acomodi> TMM: FYI, there is the possiblity to load the Linux images also with ethernet. (There is a wiki describing how to setup the net interface https://github.com/timvideos/litex-buildenv/wiki/Networking). One thing to notice is that the UDP port would need to be set to 69 instead of 6069. Using ethernet is much faster than the 115200 baud rate with lxterm17:06
tpbTitle: Networking · timvideos/litex-buildenv Wiki · GitHub (at github.com)17:06
*** enriq has quit IRC17:21
*** enriq has joined #symbiflow17:24
TMMsf-slack: right, to see it working that would be nice! But I kind of need to be able to generate my own socs :) What I'm planning to do requires me to add some opcodes to the cpu :)17:30
andrewb1999kgugala / acomodi: I've been talking to mitho about instability in the prjxray-db sdf generation and was wondering if you could take a look at fixing this.  I needed to make changes to prjxray-db to get some of my work merged, but now the new database generated runs into sdf issues in arch-defs CI.  Not being able to get a new database merged into arch-defs is holding back merging a lot of my other work.18:13
sf-slack<kgugala> andrewb1999: can you link a PR with unstable sdf?18:18
andrewb1999kgugala: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/157118:30
tpbTitle: build(deps): bump third_party/prjxray-db from `20adf09` to `e45604d` by dependabot-preview · Pull Request #1571 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)18:30
andrewb1999kgugala: And here are the changes in the db generation https://github.com/SymbiFlow/prjxray-db/commit/e45604d941615d6eef722f61fe857b6688088b6b18:31
HackerFoolitghost: Does this make sense? https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/1205#issuecomment-65504893618:39
tpbTitle: A New Simulated Annealing Schedule by HackerFoo · Pull Request #1205 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)18:39
litghostHackerFoo: I don't think I disagree at a high level.  It would be good to get a rational from the VTR devs for why QoR improvements are flagged.  Do you remember if we directly resolved that question?18:41
HackerFooI don't think it has been resolved, but I can see why they would want to know if e.g. CPD went down to something physically impossible.18:44
HackerFooSo it probably makes sense to just adjust the lower limits.18:44
*** sky36 has quit IRC18:51
TMMlitghost: is there anything someone who's main claim to fpga fame is some blinking leds can do to help with this?19:17
litghostTMM: Sorry, can rephrase your question?  I'm not certain I understood you.19:22
*** enriq has quit IRC19:24
TMMlitghost: you said there were a bunch of things still being worked on. I just wondered if someone with very limited experience can do anything useful there.19:27
litghostTMM: Absolutely.  Do you have experience with C++ or python?  If not, simply updating the documentation for the symbiflow-example could be useful right now.  Give me a minute while I look over our burndown list19:30
*** enriq has joined #symbiflow19:31
*** az0re has joined #symbiflow19:42
TMMlitghost: yeah, I write C++ for the Godot game engine, it's my job now. :)19:45
HackerFooTMM: Nice19:45
TMMHackerFoo: thanks! :D19:47
litghostTMM: So something we want to do is propagate clocking constraints through yosys transformations.  In particular, yosys adds IBUF and BUFG's as part of it's passes.  So an inpad named "clk" is still "clk" before the IBUF, but after the IBUF is named something like "\$iopadmap.clk", etc.  I believe LiteX relies on simply constraining the inpad "clk" in it's xdc19:49
litghostTMM: We want something to propigate input clock constraints from the xdc to follow yosys transformations where the relevant net is split, so that when it comes time to run the design into VPR, the constraints are supplied on the new nets19:50
litghostTMM: We've handled this to date by modifying LiteX's clock constraints to match any transformed net names19:51
litghostTMM: We have an initial xdc plugin here: https://github.com/SymbiFlow/yosys-symbiflow-plugins/blob/master/xdc-plugin/xdc.cc, but right now it is only annotating IO directives onto cells, not anything wr.t. create clocks19:52
litghostTMM: We have an initial issue about this here: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/135219:53
tpbTitle: Clock propagation story · Issue #1352 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)19:53
litghostTMM: There is also a need to have something propigate clock constraints from the input of the PLL/MMCM to the output of the PLL/MMCM19:54
TMMOK, this is a little over my head but it feels maybe not too far over my head. Parsers and compilers are a hobby of mine so I think once I understand the problem a bit better I can probably fix it. I'll try to understand what some of the terms mean and go through the yosys code. Also: TCL gross ;)19:55
litghostTMM: TCL is super gross, but it is what we got :(19:56
TMMIs there a minimal problem verilog file that should synthesize but doesn't due to this?19:57
litghostTMM: Any design that leaves off the IBUF and BUFG when synthesized with yosys will have the new nets19:58
TMMRight, but so far all I've done is blink some LEDs :) I'll first learn enough verilog to encounter the problem then19:59
litghostTMM: So blinking some LEDs will manifest this issue, if you tried to constrain the clock19:59
litghostTMM:  However blinky is typically simple enough that clock constraints are not required20:00
litghostTMM:  However designs like LiteX have tighter (and weirder) timing constraints than something like blinky20:00
TMMImagine that! :D20:01
litghostTMM: As an example, take https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc/xc7/tests/counter/counter_basys3.v (which is a blinky).  In this case the design has an explict BUFG, but an implicit IBUF20:01
tpbTitle: symbiflow-arch-defs/counter_basys3.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)20:01
litghostTMM: Post-synthesis, yosys will insert a IBUF between the input "clk" and create a new net after the IBUF20:02
litghostTMM: In designs without the explicit BUFG, there will be a similar insertion between the net from the IBUF and the output for the BUFG20:02
TMMOK, I think I see. So this problem would manifest itself in the yosys json files, right?20:04
litghostTMM: Sort of.  To be clear, the issue is communicating the constraints from the input XDC/SDC file down to VPR20:05
litghostTMM:  VPR sees 3 clock nets (the pad net, the net that is the output of the IBUF, and the net that is the output of the BUFG)20:05
litghostTMM: By default, none of these nets will be constrained20:06
litghostTMM: If the input SDC is passed directly to VPR, only that first net (the pad to the IBUF input) will be constrained20:06
litghostTMM: However the "right" behavior is to have a clock tree that originates at the IBUF, propigates through the IBUF, through the BUFG, etc20:07
litghostTMM: MMCM/PLL propigation is also highly valuable, as ideally for static MMCM/PLL configuration, the tooling would be able to generate the correct constraints on both the input to the PLL, and the output20:08
TMMOK, so, I maybe got this entirely wrong but: Yosys generates a new wire between the bufg and whatever comes after it. Instead this wire shouldn't be there but be connected to the input clock pad?20:10
litghostTMM: Yosys's behavior is correct, we want that BUFG.  It is actually very important that it be there.20:11
TMMI'm trying! Thanks for your patience.20:12
litghostTMM: What we need to do is take the initial SDC (constraint the input pad), and have it accurately reflect the final clock tree going into place and route20:12
TMMIs it OK if I type out my current understanding? Because I don't see how these constraints fit in20:18
litghostSure20:26
TMMOK, so, the sdc file in the case of the counter describes says that the maximum clock propagation delay is 10ns. So this means that no set of gates as a whole can take longer than 10ns to propagate the clock and do whatever logic they were going to do. Correct?20:35
TMMI'm talking about `create_clock -period 10 bufg`20:35
TMMWhat yosys does is generate a gate-level description of the circuit described in the verilog file. but it can't know about these physical delays, right?20:38
TMMThat would be up to the routing and placement tool, to fit the gates that yosys generated into the actual physical gates of the chip.20:38
TMMAnd whether or not that 10ns clock propagation can be achieved can't be known until then, right?20:39
litghostTMM: More specifically, yosys is working at a different abstration level than the P&R tool, and cannot do precise clock constraining.  Some physical synthesis is done, but I don't believe it is constraint driven today20:39
litghostTMM: Adding more physical synthesis is future work20:39
TMMI'm not arguing :) I'm trying to put to words the way I think this is supposed to work20:40
litghostTMM: But it is correct that the P&R tool has a more complete and precise model of the underlying hardware.20:40
litghostTMM: This is a little tangent to the actually need.  The need to is express the clocking constraints on the nets downstream of the buffering clock objects (e.g. the IBUF and the BUFG, and/or PLL/MMCM).20:41
TMMBecause I'm not entirely sure what yosys can do with the clock contraint information, so I guess I'm not sure what exactly should happen. Is the constraint encoded as a sort of metadata in the RTL? If so is what needs to happen that the clock constraint 'simply' (I'm assuming it's not that simple) needs to be tracked so that the RTL contains the whole chain up from clk to bufg (and the implicint IBUF)? So that the R&P tool can know that all20:42
TMMthose components share that 10ns constraint20:42
litghostTMM: The P&R tool uses the input clock constraints to drive the optimization to meet the constraint.  If the constraint is absent or missing, then the optimization will focus on the wrong parts20:42
litghostTMM: The goal is to take a clock constraint on the pad (e.g. "input clk") and propigate those constraints to the downstream nets, so that the P&R tool does the right thing20:43
TMMright, and the P&R tool (in the case of counter) needs to know that the clk and bufg wires should be counted together to meet the 10ns constraint? So if bufg takes 1ns, it should be able to know that the implicit ibuf now has 9ns left?20:44
litghostTMM: > So if bufg takes 1ns, it should be able to know that the implicit ibuf now has 9ns left?20:44
litghostTMM: That's not quiet right20:44
litghostTMM: The IBUF or BUFG actually create a relationship between the input and the output20:44
litghostTMM: So it isn't a direct subtraction20:44
litghostTMM: However as a first cut, the relationship can be assumed to be 0 delay, as a first cut20:45
litghostTMM: The reality is more complicated, but that is something that can be added later20:45
litghostTMM: The precise description of the BUFG input to output relationship is that the BUFG adds some delay and some jitter/variance20:45
litghostTMM: However most clocked elements in the design should be downstream of the BUFG, so the delay through the BUFG is immaterial20:46
litghostTMM: Only in the case where a piece of logic is capturing an edge that was launched from the other side of a buffer would the delay through the buffer factor in20:47
litghostTMM: For now, simply propigating the relationship as 0 delay and 0 jitter through the IBUF and BUFG is a good first approximation, with TBD constants to factor in the true pre- post- buffer delays20:48
TMMI guess maybe I'm not 100% clear on what 'propagating through' means exactly. Is that metadata for P&R? Or does it actually change the netlist from yosys?20:49
litghostTMM: The netlist does not change.  The constraints should change, and/or be added too20:49
litghostTMM: So a constraint on just the input pad, becomes the input pad, the IBUF output and the BUFG output.  In the case of a clock generation element, there is a relationship between the PLL input and output (e.g. phase shift and/or frequency change)20:50
litghostTMM: So as an example, the user says "create_clock -period 10 clk", which is then propigated to a net "clk_bufg".  In that case, a new constraint can be added simply as "create_clock -period 10 clk_bufg"20:53
litghostTMM: If there is a delay though the element, then the propigated constraint would something like "create_clock -waveform {1 6} clk_bufg" (for a 1 ns delay through the element)20:54
TMMoh, so the work should generate a new sdc file?20:55
litghostTMM: Yes20:55
litghostTMM: VPR SDC also supports clock uncertainity (e.g. jitter) via "set_clock_uncertainty"20:55
litghostTMM: The SDC input format to VPR supports expressing both delay through clocking elements and jitter through elements, but we don't have something that takes a fully elaborated netlist from yosys and just an input pad constraint, and creating the "full" constraint description for the clock network20:56
TMMah, ok, that part I really didn't understand. So should this be a tool that runs separately from yosys that takes the json file and does this analysis or should yosys spit out an sdc file as well as the various other files?20:57
TMMAnd I guess I don't fully understand how something at that level can know how much delay and jitter there is going to be. Isn't that dependent on the actual silicon?20:58
TMMAnd I presume the clock integrity related to the speed?20:58
litghostTMM: It is dependent on the silicon.  The initial tool though can just propigate assuming 0 delay / 0 jitter as a first step20:59
litghostTMM: As for whether this lives outside of yosys or inside as a plugin or yosys script is part of the work21:01
*** enriq has quit IRC21:01
litghostTMM: We have an XDC plugin that we were thinking could be used to capture the clock constraints from the XDC input, but that is not currently wired to create even a simple XDC -> SDC passthrough21:02
TMMOK, not knowing any of the workings of yosys, on the face of it it seems that just a verilog parser should be able to figure this out, but I guess you'd have to know what names yosys is going to use to generate the sdc file21:02
zypso to put it simply, yosys is transforming the nets so that the constraints for the input doesn't match the names in the output, so the constraints also needs to be transformed to match?21:02
litghostzyp: It isn't always just a name transformation, somethings it is a duplicate and rename.  That is what I've been meaning by "propigate"21:03
litghostzyp: But your gist is pretty close21:04
TMMOK, I guess I have some idea on what needs to happen. I'll take a stab at understanding what yosys does exactly and if there's some output formats or logs I can use to understand what's happening21:05
litghostTMM: After yosys is done with synthesis, the netlist can be described in any number of formats, e.g. json, eblif, edif, verilog21:05
TMMOK, I will do my best! Thanks a lot for your time. I think I have enough to at least come back with more clever questions later :)21:08
TMMAnd, thanks for working on this. I have been interested in working on fpgas forever but I've never had any interest in using a non-free tool to do it21:09
*** maartenBE has quit IRC21:10
litghostTMM: Have a fun time, this stuff is pretty cool.  I believe trying to figure this out is actually a good entry point21:10
zypTMM, absolutely agree on that last point :)21:10
zypI bought my first fpga devboard 13 years ago, and I'm still a FPGA novice, since the tools have been putting me off every time I've tried doing anything21:11
*** maartenBE has joined #symbiflow21:13
*** emilazy has quit IRC22:43
*** emilazy has joined #symbiflow22:46
*** mithro has quit IRC22:47
*** brent has quit IRC22:47
*** guan has quit IRC22:47
*** y2kbugger has quit IRC22:49
*** elms has quit IRC22:50
*** tucanae47 has quit IRC22:50
*** benreynwar has quit IRC22:50
*** diamondman has quit IRC22:50
*** futarisIRCcloud has quit IRC22:50
*** daveshah has quit IRC22:50
*** ric96 has quit IRC22:51
*** ovf has quit IRC22:51
*** pdp7 has quit IRC22:51
*** _florent_ has quit IRC22:51
*** sorear has quit IRC22:51
*** ktemkin has quit IRC22:52
*** nickray has quit IRC22:52
*** perillamint has quit IRC22:52
*** bubble_buster has quit IRC22:52
*** mats has quit IRC22:52
*** litghost has quit IRC22:52
*** emilazy has quit IRC22:52
*** flammit has quit IRC22:53

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