<sf-slack>
<pgielda> it servant micro an even smaller SoC than servant
<sf-slack>
<pgielda> *its
<sf-slack>
<olof.kindgren> Yeah, just need to figure out how to make it smaller, which isn't trivial at this point. Could also be the servant port for Microsemi's device
<tpb>
Title: Add Mixed HDL Blink example by umarcor · Pull Request #338 · im-tomu/fomu-workshop · GitHub (at github.com)
citypw has quit [Remote host closed the connection]
citypw has joined #symbiflow
<sf-slack>
<olof.kindgren> @mithro Nothing wrong with the VHDL itself (except maybe using std_ulogic instead of std_logic would be a reasonable choice). The bigger changes I could see were more concerning the language to give VHDL a morr prominent position in the FOSSi landscape and CI/make stuff that I can't comment on
<sf-slack>
<olof.kindgren> Speaking of makefiles, have you considered using some kind of core description format instead of a gazillion makefiles? :)
<Lofty>
olof: You can use GHDL as a plugin module for Yosys
<sf-slack>
<olof.kindgren> @lofty: Yes, I have been meaning to add support for that in edalize
<sf-slack>
<olof.kindgren> But I haven't had time to look into it properly and wasn't sure how upstreamed it all was
<Lofty>
It's not upstreamed and won't be
<sf-slack>
<olof.kindgren> aha
<Lofty>
Yosys core is ISC
<Lofty>
GHDL is GPLv2
<Lofty>
Yosys is maintained by Symbiotic EDA who sell a version of Yosys with Verific
<sf-slack>
<olof.kindgren> But does it require a fork of yosys, or can I use upstream yosys and just load the ghdlsynth plugin ?
<Lofty>
You can use upstream yosys, yes
<Lofty>
VHDL upstream would require a different frontend with a more permissive license
<sf-slack>
<olof.kindgren> Then it's good enough for me I think. Just need some time and/or help to get it hooked up properly. Should be pretty straightforward to extend the yosys module in Edalize to do vhdl too
<Lofty>
yosys -m ghdl :P
<sf-slack>
<olof.kindgren> ah ok, and then I can just, I don't know, read_vhdl <file.vhd> ?
<sf-slack>
<olof.kindgren> Looks like I need to compile the ghdlsynth module and find out. I'm just terribly bad at compiling ghdl. Always hit some problem
<sf-slack>
<olof.kindgren> Pushed the servant quickfeather support to a branch. It builds fine after the min efficiency change in symbiflow. Now I just need to wait for my actual board to arrive and finish reviewing the PR for Edalize
<mithro>
FYI - The pull request above is an example of using GHDL + Yosys on the Fomu...
<mithro>
Including mixing it with Verilog
<sf-slack>
<olof.kindgren> Ah of course. I didn't look close enough at how it was called
<sf-slack>
<kgugala> @olof.kindgren we also use it in embench-tester for converting microwatt to Verilog (so it can be simulated in Verilator)
<sf-slack>
<olof.kindgren> Got the feeling it was using docker and some extra toolchain
<sf-slack>
<olof.kindgren> @kgugala Ah, sneaky
bluecmd[m] has joined #symbiflow
<sf-slack>
<olof.kindgren> Where do I get nextpnr-xilinx btw?
<sf-slack>
<olof.kindgren> Is it worth adding now, or should it wait? It's very close to being merged now
<mithro>
olof: It is worth adding now
mkru has quit [Quit: Leaving]
<sf-slack>
<olof.kindgren> @mithro : Cool, I'llt take your word for it
<sf-slack>
<olof.kindgren> I'lll try compiling and using it myself before making a decision though
<sf-slack>
<blue> Hello :-). I was browsing around and trying to fit SymbiFlow in my mental model on what the project/collection of projects wants to be. It seems to want to be a tool flow for open FPGA design, is that about correct?
<sf-slack>
<blue> The thing that throws me off a bit is https://github.com/SymbiFlow says "Open source flow for generating bitstreams from Verilog." which seems to limit the mission to synthesis only and specifically Verilog
<tpb>
Title: SymbiFlow · GitHub (at github.com)
<sf-slack>
<blue> https://symbiflow.github.io paints a much grander vision, so I'd suspect the GitHub mission is just outdated?
<tpb>
Title: SymbiFlow - the GCC of FPGAs (at symbiflow.github.io)
<Lofty>
Well, the problem is that Symbiflow isn't really "the GCC of FPGAs". What it *is* is... pretty tricky to define honestly
<Lofty>
Maybe I'd describe it more as "the binutils of FPGAs"
<Lofty>
The GitHub description fits what it does right now much better
<sf-slack>
<olof.kindgren> I'd call it the GNU toolchain of FPGA. It pulls together a bunch of tools + glue to make a fulll end-to-end flow
<sf-slack>
<blue> Right, but does that flow include e.g. simulation and VHDL? Maybe this is all too vauge, but what I'm looking for is a place to discuss interactions between tools, a place to file issues to track when two tools have friction, or when a tool simply doesn't exist yet.
<sf-slack>
<blue> And maybe SymbiFlow is that place, or maybe that place is FOSSi Foundation somehow, or maybe it's a place that doesn't exist yet :-).
kraiskil has joined #symbiflow
OmniMancer has joined #symbiflow
citypw has quit [Ping timeout: 240 seconds]
OmniMancer has quit [Read error: Connection reset by peer]
OmniMancer has joined #symbiflow
OmniMancer has quit [Client Quit]
<litghost>
blue: Our initial language targets are Verilog and SystemVerilog, and simulation support is included in scope
<litghost>
blue: I'd say what you are asking about fits in the scope, all though it might not be something we are actively working on
<litghost>
blue: As a concrete example, as part of the Xilinx Unisim open sourcing, we are working to verify that simulation tools can parse and use those models
<litghost>
blue: We have https://github.com/SymbiFlow/ideas which is a grab bag where friction issues belong so they can be tracked and not forgotten
<tpb>
Title: GitHub - SymbiFlow/ideas: Random ideas and interesting ideas for things we hope to eventually do. (at github.com)
kgugala has quit [Ping timeout: 258 seconds]
kgugala has joined #symbiflow
kraiskil has quit [Ping timeout: 260 seconds]
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 265 seconds]
<sf-slack>
<blue> litghost: thanks, that's interesting. what is the process to get something into the ideas repository?
<sf-slack>
<blue> the template looks a bit scary, so I don't want to just file something straight from my mind
<litghost>
blue: It's just a github issue. The template is just a suggestion, but I do think you should take the time to fill out the sections you can.
<litghost>
blue: But it is editable, so you could start a stub and fill it out, if that helps you
unrznbl[m] has quit [Quit: killed]
promach3 has quit [Quit: killed]
xobs has quit [Quit: killed]
bluecmd[m] has quit [Quit: killed]
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined #symbiflow
xobs has joined #symbiflow
unrznbl[m] has joined #symbiflow
bluecmd[m] has joined #symbiflow
promach3 has joined #symbiflow
kraiskil has joined #symbiflow
<sf-slack>
<blue> good to know, thanks
<sf-slack>
<blue> you say "it's just a github issue" but I have been yelled at for not filling in templates correctly before, so :)
<Lofty>
The template is for like the 80% of things
<litghost>
blue: There is a difference between being yelled at, and respectly asking for clarification. The template is there to ask the questions that will likely be asked if you don't answer them first!
OmniMancer has joined #symbiflow
OmniMancer has quit [Client Quit]
<litghost>
blue: I'm sorry that you've had bad situations with github issues in the past. I'd like to believe if you raise an issue in one of the symbiflow projects in good faith, it would be responded to in good faith as well.
OmniMancer has joined #symbiflow
<sf-slack>
<blue> Sounds good to me :)
<_whitenotifier-f>
[ideas] bluecmd opened issue #58: Community issue / bounty tracker - https://git.io/JTLrV
<sf-slack>
<olof.kindgren> @blue Perhaps you are thinking about the FuseSoC issue tracker, where I demand a sacrifice before you are deemed worthy to submit an issue
<sf-slack>
<olof.kindgren> Not sure it worked out that well in the end though. Now I have a ton of goats and firstborn children I'm not sure what to do with
<sf-slack>
<olof.kindgren> @mithro FYI, I got three SERV cores into the Quickfeather now. Boards haven't arrived yet but they build fine and pass timing
<Lofty>
olof: I suppose you could feed the goats to the firstborn children
<Lofty>
That's half your problems solved
<sf-slack>
<olof.kindgren> @lofty: That would solve some issues
<sf-slack>
<olof.kindgren> Four SERV cores would require an additional 100 PB-LOGIC to fit. Maybe doable, but probably hard so I'll settle with three