<umarcor|2>
cr1901_modern: those segfaults you got, where them on MSYS2 or on Ubuntu 16.04?
<umarcor|2>
cr1901_modern: you need to disable synthesis features if you want to build GHDL on Ubuntu 16.04. Synthesis requires GNAT >=8.
<umarcor|2>
alternatively, you might try with AdaCore's GNAT.
<cr1901_modern>
umarcor|2: Got the segfaults on MSYS2. I can't build at all on Ubuntu. I could try w/ Adacore's GNAT, but it looks like it might interfere w/ the libc I already have installed on my system?
<umarcor|2>
cr1901_modern: the segfaults should be fixed. GHDL is now tested on MINGW32/MINGW64 and all the test suites are executed.
<umarcor|2>
cr1901_modern: WRT to AdaCore's GNAT, it should not conflict. You just get it, extract it, and add it to the PATH for building GHDL. If you generate an static build, then you don't need it.
<cr1901_modern>
Oh, I can link GHDL to the system libc (I assume GNAT's runtime transitively depends on it) even on Ubuntu 16.04?
<cr1901_modern>
Anyways, that's fine
<umarcor|2>
alternatively, just use the containers from hdl/containers. There you have latest GHDL, optionally together with Yosys (and ghdl-yosys-plugin).
<cr1901_modern>
Would prefer not to setup a container for various reasons. I can live w/ a static build.
<cr1901_modern>
Also, ignore my libc q... it doesn't make sense
<cr1901_modern>
The main reason I need GHDL is to start playing with j-core
<cr1901_modern>
AIUI, one of the reasons GHDL got yosys integration was that the j-core project requested it
<umarcor|2>
there were requests for synthesis with GHDL for many years, almost since it was created. the readme had some bold statements about it because of that.
<umarcor|2>
I believe the main driving factor was being able to use open source optimisation algorithms without implementing them in GHDL. That is, Yosys itself.
<umarcor|2>
similarly for VHDL-AMS, GHDL has complete support for parsing/analysis, but there is not continuous solver.
<cr1901_modern>
hmmm
<umarcor|2>
nevertheless, j-core, together with LEON, is one of Tristan preferred projects for testing, together with some other retroarcade projects.
<umarcor|2>
all those do typically contain valid (LRM compliant) VHDL code, so the bugs/missing features are to be fixed in GHDL. other projects have design issues which are misleading.
<cr1901_modern>
He seems to be pretty receptive to feedback and fixing/adding stuff
<umarcor|2>
he is. he is astonishing fast and responsive.
<umarcor|2>
if you find some bug/issue, just provide a reproducible MWE or a link to a repo and he will fix it before you can even understand what's going on.
<cr1901_modern>
Hah
<umarcor|2>
most of us understand problems post-morten XD
<umarcor|2>
we are lately thingking whether we can do anything in the VHDL community for finding some funding so he can devote some time to GHDL "officially"
<umarcor|2>
he works at CERN now, so it might be possible to handle it through his employer, similarly to KiCAD
<umarcor|2>
apart from the synthesis features, GHDL is the canonical implementation of the VHDL language
<cr1901_modern>
ahh hmmm
<cr1901_modern>
I don't know VHDL or Ada... all my code for my current project (MachXO2 RE) is either Verilog or nmigen
<cr1901_modern>
I'm sure VHDL works fine for MachXO2 in principle, but I don't have the ability to test rn
<cr1901_modern>
(I guess I'll pull and try again tonight)
<umarcor|2>
VHDL and Ada are very annoying for dynamic/prototyping design, but very robust for critical applications. they are frustrating for users willing to do things too fast.
<umarcor|2>
anyway, it should work for any target where you can use Verilog + Yosys already. In fact, you can do mixed-language synthesis with GHDL + Yosys. No need to use Verilog only or VHDL only.
<umarcor|2>
I contributed some examples to the fomu-workshop, based on makefiles.
<umarcor|2>
you should be able to pick those and change very few things for targeting the MachXO2
<umarcor|2>
you have the same blink example in Verilog only, VHDL only, and all four possible combinations between them.
<cr1901_modern>
I'll take a look once symbiflow pnr is working- that is a bit overdue on my end (especially since nextpnr is now working)
<umarcor|2>
let me know if you have any issue with adapting the VHDL to the MachXO2. I guess that the components/modules (RGBA, PLL) might be different.
<umarcor|2>
with "symbiflow pnr" you mean VTR?
<cr1901_modern>
yes
<cr1901_modern>
Lattice has VHDL primitive instantiations in its manual for MachXO2... only one I have working right now (besides the minimum to, you know, actually route signals) is OSCH
<umarcor|2>
VTR is the next tool in my list for hdl/containers and MSYS2, after I add iverilog and cocotb to containers.
<umarcor|2>
we asked Lattice about those primitives some months ago through twitter and linkedin. we didn't get any feedback :(
<cr1901_modern>
Oooooh, okay I think I know what you're referring to...
<umarcor|2>
I would like to add them to hdl/constraints.
<cr1901_modern>
Lattice deliberately doesn't give out the instantiations for some of the primitives
<cr1901_modern>
you have to use a GUI tool to generate them
<cr1901_modern>
I have a script that generates like 50 different instantiations of e.g. the PLL or EFB primitives to figure out how to instantiate them
<umarcor|2>
yes. but even the ones that are available in Verilog and VHDL are not "open source".
<cr1901_modern>
Making sim models for those are out of scope for me for now (though if mithro wants them, then I'll have to think about it lol)
<umarcor|2>
then, simulation models are also missing. I think that all of them are available in verilog, but we got multiple reports about simulation.
<umarcor|2>
note that mixed-language simulation with open source tools is possible but contrived
<cr1901_modern>
The simulation primitives exist, I'm guessing they're encrypted. There's probably a crack for them, but I don't know it if there are. Also, I would get in trouble if I used it
<umarcor|2>
dependencies other than the toolchain are automatically installed by makepkg-mingw
<umarcor|2>
when the build is finished, you get a *.zst package, but the content is also available in subdir pkg. You can set envvar GHDL or GHDL_PREFIX for executing the testsuite in-place, without installing the package.
<cr1901_modern>
ahhh cool
<cr1901_modern>
anyways apparently I need to pass --with-llvm-config to the configure script
<umarcor|2>
--with-llvm-config and --prefix and --enable-libghdl and --enable-synth
<cr1901_modern>
wait... does the test suite unconditionally try to test mcode backend, even on windows 64 bit?
<umarcor|2>
If you want to do synthesis, libghdl is required. ghdl-yosys-plugin (Yosys) depends on the shared lib, not on the CLI entrypoint.
<umarcor|2>
the testsuite does not try to test any specific version of GHDL. it uses the ghdl found through the PATH or the one you tell it through GHDL.
<cr1901_modern>
ls
<cr1901_modern>
whoops
<umarcor|2>
so, yes, if you execute the testsuite it will try regardless of the version/backend of GHDL
<umarcor|2>
I bet you don't have a clean repo, and configure is not reconfiguring
<cr1901_modern>
Yea something like that. Not a big deal, just thought it was funny
<umarcor|2>
I try to always build tools in a subdir, for preserving a clean root.
<cr1901_modern>
Oh this is a dedicated build dir
<cr1901_modern>
I just didn't follow your directions properly lol
<umarcor|2>
it's not necessary. Tristan builds it in the root typically. But I try to pick the packager's hat.
<cr1901_modern>
undefined reference to `__gnat_last_chance_handler'
<cr1901_modern>
that's a new error... progress :D
<cr1901_modern>
umarcor|2: Ever seen that one?
<umarcor|2>
hmmm
<cr1901_modern>
Hmmm I forgot the -static flags... let's see if that helps
<umarcor|2>
when is it producing that error?
<cr1901_modern>
"make test"
<umarcor|2>
yes, the static should fix it
FFY00 has joined #symbiflow
<cr1901_modern>
Doing a clean build w/ the static flags... if that doesn't work, I guess I'll file an issue
<cr1901_modern>
Okay, clean build w/ static flags fixed it
<cr1901_modern>
umarcor|2: Just for the record: "../ghdl/configure --prefix=/mingw64 --enable-libghdl --with-llvm-config" also works. But it needs to be a clean build. Looks like I was mixing the mcode and llvm build
<umarcor|2>
thanks for clarifying
<umarcor|2>
are you going to build Yosys with ghdl-yosys-plugin then?
<cr1901_modern>
yes, that's the next step
<cr1901_modern>
After I confirm that all works, I'm going to upgrade MSYS. And that should probably be the rest of my night :)
<umarcor|2>
that's slightly tricky because Yosys does not support dynamic modules on windows, you need to build the plugin as an embedded frontend
<cr1901_modern>
? Yosys supports plugins via libdl last I checked
<umarcor|2>
I suggest following the recipe in MSYS2's repo. let me find it for you
<cr1901_modern>
Uhhh, yea I'll supply VHDL components once the Verilog ones are finalized
<cr1901_modern>
(for MachXO2)
<umarcor|2>
Yes. Just as a general remainder: most of the things I talk about are rather simple, almost stupid, compared to the complexity of other projects/tasks. That's because I focus on the obvious issues for experienced users but hard to understand for newcomers.
<cr1901_modern>
Well, before tonight I didn't have a working VHDL toolchain. Thanks to you, I do now.
<cr1901_modern>
I'm guessing over time I can work my way up to making integration w/ yosys more seamless
<cr1901_modern>
esp on Windoze
<umarcor|2>
That's the role I took in the community :D It's reassuring to see it works :D
<umarcor|2>
I'll be glad to help with testing on Win/MSYS2, and with packaging/upstreaming any additional tools you might come up with.
citypw has joined #symbiflow
<cr1901_modern>
I have used a plugin w/ yosys before on Windoze. I'm going to see if I can remember how to do it before going the other route
<umarcor|2>
There is nextpnr-ice40 only for now. nextpnr-ecp5 works on 64 bits, but has issues for being built on 32 bits only. All other targets are to be added yet.
<cr1901_modern>
Build the bbas on another machine and rsync them (with compression _on_) to your build machine
<umarcor|2>
Let me find the issues/discussions about plugins on Windows. I was told that, not something I found.
<cr1901_modern>
this is what I do
<umarcor|2>
that works for "me" and "you", but not in MSYS2's CI
<umarcor|2>
the solution is to launch a 64 bit shell from the 32 bit build job, because the machine is 64 bit indeed
<umarcor|2>
but bbas are built with python, and there is a conflict between python dlls when doing that ugly call
<cr1901_modern>
Okay yea, I can't seem to build even the sample plugin. If worst comes to worst I'll compile it into yosys, but would rather play around a bit tonight
<cr1901_modern>
Besides, it gives me an excuse to hold off upgrading :P
<umarcor|2>
That sounds as some interesting plan!
<umarcor|2>
In fact, the only reason for ghdl-yosys-plugin to support being built as part of Yosys is because of Windows. Otherwise, we would only support using it as a shared lib.
<cr1901_modern>
umarcor|2: Ack. I'm going to be concentrating for a while, since this is stuff I haven't dealt w/ in a while lol
<cr1901_modern>
but I'll see what I can do
<umarcor|2>
I'll quit for today. Just ping me if I can help ;)
<cr1901_modern>
will do
join_subline has joined #symbiflow
ym has joined #symbiflow
Degi_ has joined #symbiflow
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
ym has quit [Ping timeout: 240 seconds]
craigo has joined #symbiflow
citypw has quit [Ping timeout: 268 seconds]
<cr1901_modern>
umarcor|2: So after playing w/ this for 2 hours and creating some samples, I've concluded that kvide's approach is the correct thing to do.
futarisIRCcloud has joined #symbiflow
cr1901_modern has quit [Quit: Leaving.]
yeti has quit [Quit: WeeChat 3.0]
yeti has joined #symbiflow
yeti has quit [Read error: Connection reset by peer]
yeti has joined #symbiflow
cr1901_modern has joined #symbiflow
FFY00 has quit [Ping timeout: 260 seconds]
citypw has joined #symbiflow
infinite_recursi has joined #symbiflow
infinite_recursi has quit [Client Quit]
ByteLawd has joined #symbiflow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
hansfbaier has joined #symbiflow
citypw has quit [Ping timeout: 268 seconds]
citypw has joined #symbiflow
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #symbiflow
craigo has quit [Quit: Leaving]
Amrit_Raj has joined #symbiflow
Amrit_Raj has quit [Client Quit]
hansfbaier has quit [Read error: Connection reset by peer]
citypw has quit [Ping timeout: 268 seconds]
infinite_recursi has joined #symbiflow
citypw has joined #symbiflow
<infinite_recursi>
There's following code in olimex demo files