12:43 <sf-slack> <rodrigomelo9> Hi everybody, my name is Rodrigo, from Argentina (my mother tongue is Spanish). I am an Electronic Engineer and I have been working with FPGAs since 2006. I have more experience with Xilinx devices (starting from Spartan 2), but also I used devices from Intel/Altera (Cyclone IV, V, max X), Microchip/Microsemi/Actel (SmartaFusion2 and ProASCI 3) and Lattice (iCE40). Moreover, I am a Free Software user (I mainly

12:43 <sf-slack> use Debian GNU/Linux workstations). I have some opensource related projects in GitHub and GitLab (IP cores and tools) but I want to help with opensource FPGA flows. I could help with things related to VHDL, Verilog, Tcl, Python, Bash, Makefiles, FPGA EDA tools, testing things with hardware, etc. As I commented to @me1 here https://github.com/SymbiFlow/symbiflow-arch-defs/issues/1243#issuecomment-569256099, I am interested to

12:43 <sf-slack> start to work getting the Xilinx primitives. Well, it was my introduction for you to know me. Regards

12:43 <tpb> Title: parse_pdf_modules.py seems to be not working · Issue #1243 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

14:29 <Xiretza> daveshah: hey, do you happen to be at 36c3? I have a few questions regarding nextpnr-xilinx that would probably be easier and faster to talk about in person :)

15:27 <daveshah> Xiretza: no, I'm not

15:38 <Xiretza> daveshah: ah, alright. I may be doing something wrong, but following the Arty example in the readme, fasm2frames.py fails because it can't find a few *.OSERDESE.* keys, which are generated by xilinx/fasm.cc:124-127. Since I have no idea what I'm doing, I just tried changing OSERDESE to OSERDES there and don't get any warnings anymore - was that a horrible idea?

15:38 <daveshah> Xiretza: it might be a change in prjxray

15:39 <daveshah> I'm not even sure where they come from

15:39 <daveshah> I would need to have more of a look

15:39 <Xiretza> should I just open an issue on github?

15:41 <daveshah> Please do

15:41 <daveshah> Can you include the fasm output too?

15:43 <Xiretza> yeah, I'll do that. there's at least one more thing that broke due to prjxray changes that I managed to fix myself, I'll open a PR(s) for that.

15:44 <daveshah> Thanks

15:45 <daveshah> This is why I am not promoting nextpnr-xilinx too heavily btw (although I'm very glad of other devs testing/helping), it's still a very unstable environment

15:46 <Xiretza> yeah, that's the feeling I got too, the readme however is already a great resource :)

16:31 <Xiretza> daveshah: also, is the nextpnr_rw_usp yosys branch still required? everything seems to be working fine with mainline yosys, don't know if the bitstream is correct though.

16:32 <daveshah> No, mainline Yosys should be OK now

16:32 <daveshah> It hasn't been very well tested and it may occasionally infer distributed RAM primitives that aren't supported, but it would error out in that case

16:32 <Xiretza> daveshah: alright, I'll update the docs then

16:36 <daveshah> Due to some routeability issues, with upstream Yosys adding `-nowidelut` to `synth_xilinx` often results in much shorter route times (with a small timing penalty). This might be something worth adding too

16:36 <daveshah> abc9 would be better but I think it uses a carry primitive that nextpnr-xilinx doesn't support yet

18:20 <Xiretza> daveshah: I'm assuming `-nobram` is a leftover from when BRAMs weren't as developed yet? it seems to work without it now. also `-nowidelut` actually results in lower f_max with the attosoc example

18:21 <daveshah> Yeah, do note the Fmax numbers it produces are not correct for xc7 btw

18:26 <Xiretza> ah, is the slack histogram any better? it looks about the same as well, with -nowidelut maybe with a little better distribution on the lower end, but nothing major. I'll add it if you say it has a benefit though.

18:29 <davidthings> daveshah: I pulled and rebuilt prjtrellis this AM from master and after months of flawless performance, my Superconference badges do not do anything when flashed (dfu_utils). I have confirmed old .bit files still work. And even the simplist project (blink an LED) do not work. I'm trying a version of prjtrellis from a month ago to see if I can find a working version. Any hints? Any thoughts?

18:36 <daveshah> Do you mean just prjtrellis or the whole flow?

18:36 <daveshah> I can't think of any reason for this

18:36 <davidthings> I pulled and rebuilt the whole thing

18:36 <davidthings> OK. I'm going to do some binary searches to see if I can find something that works for me.

18:36 <davidthings> I will report back.

18:39 <davidthings> cd ..

20:04 <davidthings> daveshah: I'm a bit confused... are the authoritative versions of nextpnr and yosys in yosysHQ? And if so, where is the authoritative prjtrellis? IceStorm?

20:20 <daveshah> davidthings: Authoritative Yosys and nextpnr are YosysHQ. prjtrellis is SymbiFlow. icestorm is cliffordwolf

20:23 <davidthings> Thanks

21:46 <davidthings> Happy to report my code is all working on the latest tools. Somewhere along the way I had started adding the -abc9 flag to Yosys. Removing that makes everything work again.

21:55 <daveshah> davidthings: `-abc9` should definitely not be breaking things

21:56 <daveshah> can you share the simplest example that it breaks

22:29 <davidthings> Sure.

22:31 <davidthings> Gimme a sec to make something mininal, Dave.

22:40 <davidthings> Here's a fragment that shows the problem. https://pastebin.com/09VVPnsM

22:40 <tpb> Title: [VeriLog] /* Build with the following and no blink. Omit the -abc9 and blink. %.json - Pastebin.com (at pastebin.com)

22:42 <davidthings> Let me know if I can help any further. I'm just so happy that my code works again...