<nats`>
if someone is interested I have a Genesys 2 to sell, barely used but vivado voucher not available since used a long time ago. PM for details
<mithro>
tnt: You are one of the first people to try the quick logic stuff, so its going to be a bit bumpy
<mithro>
tnt: The EOS S3 FPGA is fairly slow
<tnt>
mithro: Yeah, I was hoping to port my USB core to it since that core is faster than the tinyusb-bootloader core, I had good hope to get it running ... but with the timing number I got that's not going to happen ...
<tnt>
I have no idea how they got the tinyusb-bootloader code to meet timing at 48 MHz
<mithro>
tnt: They used hand placement
<mithro>
And a lot of pipelining
andrewb1999 has quit [Ping timeout: 260 seconds]
<mithro>
mkurc / kgugala: See tnt's question above
kraiskil has quit [Ping timeout: 265 seconds]
<sf-slack>
<kgugala> tnt: no you cannot initialize the RAM - this is not real blockram, but rather a hard RAM block (like SB_SPRAM in ice40)
kraiskil has joined #symbiflow
<sf-slack>
<kgugala> tnt: PART and DEVICE were introduced for xc7 flow where some chips are in fact the same devices, but named differently. In QL this is not really the case (at least for now).
<ryancj14>
Hello I am a BYU student learning the fpga-tool-perf repository. Is there someone experienced with that tool who could help answer some of my questions about it?
<sf-slack>
<acomodi> @ryancj14 Hi, sure
<ryancj14>
Awesome thanks. So far, I've been able to run fpgaperf.py with the vivado, vpr, and vivado-yosys toolchains. One error I encountered when trying to run the --check-env option is that it ran until it reached a have_exec() function that it says is undefined. Was that defined previously and then removed. Is there any way to get this to run properly, as it seems useful.
<ryancj14>
File "/home/student/fpga-tool-perf/symbiflow.py", line 408, in check_env
<ryancj14>
'yosys': have_exec('yosys'),
<ryancj14>
NameError: name 'have_exec' is not defined
gsmecher has joined #symbiflow
<sf-slack>
<acomodi> @ryancij14 So, looking at it now. have_exec is defined in fpgaperf.py. And it is not imported in symbiflow.py, hence the error. Thanks for spotting this, because it is not tested on CI. I am opening a PR soon with a fix
<ryancj14>
It looks like similar changes may need to be made for the vivado.py file for running --check-env on the vivado or vivado-yosys toolchains.
<sf-slack>
<acomodi> Sure, will update the PR, thanks
<ryancj14>
I've made the changes on my own, but it still says false for vivado even though I can run the vivado toolchain just fine otherwise.
<sf-slack>
<acomodi> Right, this because the vivado settings.sh file is sourced just before running it (you can see this in the Makefile generated by edalize). If --check-env if called, the settngs.sh has not been sourced, hence vivado cannot be found
<ryancj14>
oh ok got it
citypw has quit [Ping timeout: 240 seconds]
<HackerFoo>
I have symbiflow-arch-defs, VPR, nextpnr-xilinx, fpga-tool-perf, etc. working on MacOS, if anyone is interested: https://github.com/HackerFoo/nix-symbiflow.
alexhw has joined #symbiflow
<tnt>
kgugala: the PART / DEVICE thing is because the scripts that are installed from the sources of arch-defs still use/require those to be set ... (as opposed to the scripts in the binary distribution that use DEVICE / PKG).
<tnt>
kgugala: as for the BRAM ok. I could work around the non-init. But it would be nice if the packer was smart enough so that you can instanciate a 8kbit block on its own and the packer/placer just packs 2 of them together. Because when you need a few 8kbit RAM at _completely_ different places of the design, having a single hard-ip that contain 2 of them is basically un-usable.
<tnt>
A bit like Xilinx has RAMB18 and RAMB36 ...
<mithro>
@tnt That feels pretty doable
<tnt>
Yeah. I mean worse case, I'll just invent my own blackbox and do a post processing on the json to merge 2 of them into a single ram but that seems like something that would be generally useful.
<tnt>
Also, does that FPGA have global clock buffer? Some example show "gclkbuff" cell. Which I tried to use to distribute my clock and reset and although there was no error, the timing report still seems to show the clock is distributed around using normal routing (and creates giant clock skews ...)
OmniMancer1 has quit [Quit: Leaving.]
az0re has joined #symbiflow
kraiskil has quit [Ping timeout: 260 seconds]
kraiskil has joined #symbiflow
craigo has quit [Ping timeout: 260 seconds]
<tnt>
Lofty: I think you're right about the "abc -lut 1:4" comment. Looking at synth result, it seems it likes a lot to put a LUT2 whoes output is only used by a following LUT3 ... which really should just be a LUT4.
<Lofty>
ABC9~
<Lofty>
But yeah, give it a try with abc -lut 4
<Lofty>
> it seems it likes a lot to put a LUT2 whoes output is only used by a following LUT3
<Lofty>
If you consider LUT2/3/4 to have 2/4/8 units of area, then a LUT2 into a LUT3 is 6 units, whereas a LUT4 is 8
<tnt>
yeah exactly, but I think that just makes the packer/placer job harder for no reason.
<Lofty>
Here's one of the things which comes to mind though
<Lofty>
Imagine you take the LUT3 as 1 unit of area
<Lofty>
Then a LUT2 into a LUT3 has 2 units of area, and a LUT4 has 2 units of area
<Lofty>
ABC9 could work out that the LUT4 has *much* less delay
<Lofty>
ABC by itself can't
<Lofty>
(ABC uses unit delay; ABC9 uses generalised delay)
OmniMancer has joined #symbiflow
kraiskil has quit [Ping timeout: 246 seconds]
<Lofty>
If you're using a SlowLogic chip, it's best not to shoot yourself in the foot before you even begin
<tnt>
Yeah, I'm sure abc9 could help, but changing the flow to use that is above my head.
<Lofty>
I have apparently become the ABC9 abyss domain expert :P
<Lofty>
And I have a PR outstanding to add Gowin ABC9
<Lofty>
The latter I did as a favour to Pepijn
* Lofty
needs to remember 'free software isn't free to make' more often
<_whitenotifier-f>
[symbiflow-examples] mithro opened issue #11: Why is counter_test/counter_basys3.v? - https://git.io/JfDhs
<sf-slack>
<timo.callahan> Hi @kgugala, with the Edalize flow with Yosys->Vivado, are there any known unsupported features or "gotchas"? I am trying to get a scalable proc example to work on the Arty 100t board. It works with Vivado and with Symbiflow, but has bad output when built using the yosys_vivado.py script.
<sf-slack>
<timo.callahan> @pgielda, instead of the seeming random stream of 32b hex values, N per line, I see all zeros (but the correct number of values per line). When I get time, I can try to simulate it post-Yosys, but I need to make a new top module w/o the UART interface.
<sf-slack>
<pgielda> oh, I thought it fails
<sf-slack>
<pgielda> but it generates something that does not work you mean?
<tpb>
Title: GitHub - SymbiFlow/symbiflow-examples: Examples designs for showing different ways to use SymbiFlow toolchains. (at github.com)
<sf-slack>
<pgielda> this tutorial will be shorter ... and download less stuff once we finish working on a vtr package that is console only
<_whitenotifier-f>
[symbiflow-examples] mithro opened issue #12: The linux_litex_demo doesn't make much sense - https://git.io/Jfye9
<sf-slack>
<pgielda> btw @mithro this repo was originally a travis CI testing the binary flow, then it morphed into what it is now
<mithro>
pgielda: Ahh
<sf-slack>
<pgielda> but I do think we should keep it simple, and maybe have a LiteX+Symbiflow tools somewhere else? Especially that LiteX hides the tools? And this one is Makefile based
<mithro>
pgielda: I think we want a couple of different examples in that repo
<sf-slack>
<pgielda> Yes, I just think they escalate from a counter to Linux to quickly :)
<_whitenotifier-f>
[symbiflow-examples] mithro opened issue #13: Add a FuseSoC based demo - https://git.io/JfyeF
<sf-slack>
<pgielda> maybe apart from this _test in the DEVICE name, we have to fix that
<sf-slack>
<pgielda> and maybe apart from this abspath lastword pathsubst whatever stuff at the top
<sf-slack>
<pgielda> But in general this looks like Unix stuff not like EDA tcl stuff which is good
<sf-slack>
<pgielda> LiteX is different that it actually does everything inside so you do not have to think about it at all. But maybe not the good starting point if you want to see how the toolchain works
<sf-slack>
<pgielda> (my opinions of course)
<mithro>
pgielda: The symbiflow-examples repo is suppose to show a bunch of different ways you can use the tooling
<sf-slack>
<pgielda> The cool thing is I was able to reproduce this using more or less clean debian:buster in a container, I had to install wget and that was all
<sf-slack>
<pgielda> sure.
<mithro>
I also wonder if it should be symbiflow-xray-examples ?
<sf-slack>
<pgielda> well there is an idea to add quicklogic to it
<sf-slack>
<pgielda> and then move examples to something like
<sf-slack>
<pgielda> examples/xilinx/...
<sf-slack>
<pgielda> and examples/quicklogic/...
<sf-slack>
<pgielda> or something similar
<sf-slack>
<pgielda> the flow is almost the same, the difference is that there is a different arch-defs tarball and different channels
<sf-slack>
<pgielda> because yosys, yosys-plugins and vtr is different
<sf-slack>
<pgielda> and then different fasm stuff installed with pip
<sf-slack>
<pgielda> otherwise its the same stuff
<sf-slack>
<pgielda> it would also be great to somehow not have the same code twice, once in README once in the travis ci yaml but at the same time not hide it in a "install.sh" scirpt or anything like that
<sf-slack>
<pgielda> maybe we need this tutorial testing stuff Michael was showing and test the README directly
<sf-slack>
<pgielda> (now travis has this "almost the same but slightly different" code)
<sf-slack>
<pgielda> (which annoys me because it will surely lead to bugs)
<sf-slack>
<pgielda> (but hiding things in a script or a makefile targets actually makes it less clear that its not that complicated after all)
<sf-slack>
<pgielda> (to use the toolchain I mean)