*** tpb <[email protected]> has joined #symbiflow | 00:00 | |
tpb | tpb has joined on freenode | 00:01 |
---|---|---|
tpb | gsmecher has quit freenode (Ping timeout: 252 seconds) | 00:31 |
tpb | FFY00_ has quit freenode (Ping timeout: 245 seconds) | 00:48 |
tpb | FFY00_ has joined on freenode | 00:49 |
tpb | <sf-slack> <kd2cca> I've been reading about register mapping and standards such as IP-XACT and SystemRDL. Can someone recommend any good open source tools to support something like this? | 00:52 |
tpb | <sf-slack> <kd2cca> Also quite enjoyed @olof.kindgren’s article : https://olofkindgren.blogspot.com/2016/11/ip-xact-good-bad-and-outright-madness.html | 00:53 |
tpb | <tpb> <https://x0.no/4uwq9> (at olofkindgren.blogspot.com) | 00:53 |
*** adjtm <adjtm!~adjtm@2a0c:5a80:3d0c:7700:49ef:d0f0:57d6:3082> has joined #symbiflow | 01:31 | |
*** rvalles <rvalles!~rvalles@user/rvalles> has quit IRC (Read error: Connection reset by peer) | 04:23 | |
*** rvalles <rvalles!~rvalles@user/rvalles> has joined #symbiflow | 04:23 | |
*** rvalles <rvalles!~rvalles@user/rvalles> has quit IRC (Read error: Connection reset by peer) | 05:23 | |
*** rvalles <rvalles!~rvalles@user/rvalles> has joined #symbiflow | 05:23 | |
tpb | ByteLawd has joined on freenode | 06:40 |
*** adjtm <adjtm!~adjtm@2a0c:5a80:3d0c:7700:49ef:d0f0:57d6:3082> has quit IRC (Ping timeout: 272 seconds) | 07:53 | |
tpb | <sf-slack> <hadirkhan10> Thanks @kgugala using the PLLE2_ADV instance solved the synthesis issue. Which means Symbiflow does not yet support the MMCME2_ADV instance if I am correct.. | 07:54 |
tpb | <sf-slack> <kgugala> yep, it turned out the PR adding MMCME never landed | 07:54 |
tpb | <sf-slack> <kgugala> @mkurc is fixing this as we speak :) | 07:54 |
tpb | <sf-slack> <hadirkhan10> Anyways I am noticing one change between the Vivado vs Symbiflow bitstream generation. I mapped my IOBUF's `IO` instances as `inout` ports of the top and onto the LEDs on the board.. Initially when I program the bitstream (generated by Vivado) the LEDs remain off (correct behavior) however the LEDs get on by the bitstream generated by Symbiflow. After pressing the reset everything works as expected | 07:57 |
tpb | <sf-slack> <kgugala> can you prepare a minimal example and file an issue about it? | 07:58 |
tpb | <sf-slack> <mkurc> @hadirkhan10 As for the MMCM support, you may try SymbiFlow from this branch https://github.com/antmicro/symbiflow-arch-defs/tree/mmcm_support. The support is there however bitstream to verilog (via xc7 fasm2bels) won't work yet. I'm working on integrating it. | 07:59 |
tpb | <tpb> <https://x0.no/4uwrd> (at github.com) | 07:59 |
tpb | <sf-slack> <hadirkhan10> Umm.. I will have to look into producing a minimal example. Right now, I was synthesizing the complete SoC whose GPIO pads were mapped to LEDs | 08:01 |
tpb | <sf-slack> <kgugala> I suppose after reset software running on the SoC sets the pins to their initial state | 08:09 |
tpb | epony has quit freenode (Ping timeout: 260 seconds) | 08:09 |
tpb | <sf-slack> <kgugala> the discrepancy you see can be related to handling initial state of the FFs in the bistream | 08:10 |
tpb | <sf-slack> <hadirkhan10> Yes when the reset is asserted the gpio registers are in the known state. The above happens initially when the board is programmed and reset is not yet asserted. Maybe Symbiflow maps the I/Os during XXX stage to a high voltage and Vivado does not. | 08:12 |
tpb | <sf-slack> <kgugala> could be - Vivado, by default, drives everything to zero even if there is no initial value assigned | 08:14 |
tpb | <sf-slack> <kgugala> I suppose in this case it's not the IO itself, but rather FF driving it | 08:14 |
tpb | <sf-slack> <hadirkhan10> Yes the IOs are driven by the FFs | 08:15 |
tpb | <sf-slack> <kgugala> do you set initial value for the FFs? | 08:15 |
tpb | <sf-slack> <kgugala> I mean initial values in Verilog | 08:15 |
tpb | <sf-slack> <mkurc> @hadirkhan10 I think Yosys will not set a FF init to 0 unless there is explicit statement like `initial my_reg <= 1'b0` in code. | 08:31 |
gatecat | yes, this isn't just a Yosys thing but just general Verilog semantics | 08:31 |
gatecat | an FF that isn't explicitly initialised has an undefined initial state, and will do in simulation too | 08:31 |
tpb | <sf-slack> <kgugala> yep | 08:32 |
tpb | <sf-slack> <kgugala> in such cases Vivado forces 0 init | 08:32 |
tpb | <sf-slack> <kgugala> (in synthesis) | 08:33 |
tpb | epony has joined on freenode | 08:47 |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 09:17 | |
*** TMM_ <[email protected]> has joined #symbiflow | 09:18 | |
tpb | <sf-slack> <hadirkhan10> Guys I am not a Verilog expert :( I wrote the SoC in Chisel3. Though I know that all my registers are initialized to 0 once reset is asserted (looking at the `always @posedge` blocks) | 09:48 |
tpb | <sf-slack> <hadirkhan10> ```always @(posedge clock) begin if (reset) begin // @[SubReg.scala 24:22] q_reg <= 32'h0; // @[SubReg.scala 24:22] end else if (wr_en) begin // @[SubReg.scala 47:15] q_reg <= wr_data; // @[SubReg.scala 48:11] end end``` | 09:50 |
tpb | <sf-slack> <hadirkhan10> Upon looking at the generated verilog. This is how the verilog for the FFs are emitted | 09:50 |
tpb | <sf-slack> <mkurc> I'm not a Chisel3 expert :( but if you want to initialize the register you need the `initial q_reg <= 32'h0;` statement before (or after) the `always` block in the output Verilog. Otherwise before the first rising clock edge with reset=1 the register state is unknown. | 09:55 |
tpb | <sf-slack> <mkurc> (before the first rising clock edge with reset=1 or wr_en=1) | 09:57 |
tpb | <sf-slack> <hadirkhan10> Oh okay thanks @mkurc :) | 10:59 |
tpb | <sf-slack> <mkurc> no problem | 11:03 |
tpb | <sf-slack> <hadirkhan10> Finally I am able to synthesize, place and route, generate bitstream and upload it to the board without using Vivado. Kudos to you guys. I made it to the "fully" open source route :pray::-) | 11:16 |
tpb | C-Man has joined on freenode | 13:43 |
tpb | <sf-slack> <vastarparaakshar> I am still having a problem with primitives and post timing simulation | 15:06 |
mithro | https://www.youtube.com/watch?v=_1yrxrl61o4 | 15:46 |
tpb | gsmecher has joined on freenode | 16:05 |
*** emilazy <emilazy!~emilazy@user/emilazy> has quit IRC (Quit: node-irc says goodbye) | 16:36 | |
*** jophish <jophish!~jophish@2001:470:69fc:105::670> has quit IRC (Quit: node-irc says goodbye) | 16:36 | |
*** emilazy <emilazy!~emilazy@user/emilazy> has joined #symbiflow | 16:38 | |
*** jophish <jophish!~jophish@2001:470:69fc:105::670> has joined #symbiflow | 16:42 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 17:27 | |
*** TMM_ <[email protected]> has joined #symbiflow | 17:28 | |
tpb | bjorkintosh has joined on freenode | 18:25 |
tpb | FFY00_ has quit freenode (Ping timeout: 245 seconds) | 19:58 |
tpb | FFY00_ has joined on freenode | 20:01 |
*** tcal <[email protected]> has joined #symbiflow | 20:07 | |
tpb | FFY00_ has quit freenode (Remote host closed the connection) | 20:08 |
tpb | FFY00_ has joined on freenode | 20:12 |
tcal | I'm hitting the BSCANE2 issue using SymbiFlow with Litex for ArtyA7 35T. I found @kgugala's comments from 4/3, but I'm not entirely clear, since I thought the Symbiflow build used to work. Did LiteX change? I am using default VexRiscv, not the SMP, and not the stuff from the Linux-on-Litex-VexRiscv repo. I'm getting my Symbiflow from the symbiflow-examples packages. | 20:13 |
tcal | Nevermind...I started a new shell and now it works. | 23:16 |
tcal | Actually the issue is still there, BUT I'm able to work around it by setting "with_jtagbone = False".... | 23:32 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!