kamilrakoczy on uhdm-yosys-fix-libffi
yosys-uhdm: fix missing libffi … WIP: build only yosys-uhdm Sig… (compare)
michalsieron on gcc-newlib-10.1
Bump GCC-newlib version Add C++ as supported language t… Bump nostdc GCC to 10.1 and 3 more (compare)
ajelinski on fix-symbiflow-plugins
ajelinski on master
yosys-plugins-symbiflow; symbif… Merge pull request #131 from hd… (compare)
I think the only feature I miss is being able to more intuitively define which tasks are executed/skipped, based on the nodes of the DAG. However, the functionality is there: https://github.com/umarcor/neorv32/blob/pydoit/dodo.py#L37 (see https://pydoit.org/dependencies.html#uptodate).
The next step I want to try is not using a
dodo.py file and the doit CLI, but wrapping it: https://pydoit.org/extending.html?highlight=import#example-pre-defined-task
@rodrigomelo9 I think Litex is the most used open source SoC composition tool. I know migen, litex and nmigen have some concepts in common, but none of them is compatible with others. I've seen nmigen used mostly for all Python designs and Litex for integrating existing HDL cores. There might be a reason for that, or I might just be biased. There are several Litex examples in https://github.com/antmicro. In the context of SymbiFlow (symbiflow_cli) I guess that Litex is the answer.
However, I want to recall that someone told me about a SoC tool based on FuseSoC. So, FuseSoC can download all the cores that belong to a project but AFAIK it cannot generate the top-level file connecting them, or the memory maps or registers. Someone did that on top of FuseSoC. I cannot remember who... (@m-kru? @kgugala?)
I will continue to use the "best" currently available tool.
And which tool is that ?
I agree that doit is still far from the ideal automation framework but it is currently the best fit for me. I moved to it from (GNU) make because I was stumbling on the need to use shell syntax for scripting which can be done in python for doit.
The question is can an ideal automation framework exists or will it always be task and user specific ?
@fatsiefs:matrix.org that is exactly my point of view. On both points you mentioned:
Therefore, the discussion with Kaleb and Patrick is relevant because we are trying to shape those reusable tasks.
I would probably debase VUnit's regression/runner interface. It's not currently reusable for cocotb (or other) tests. The regression/runner only really works for HDL tests and the test spec and result formats are not documented.
@ktbarrett, yes, I am aware of that. However, there were some relevant changes since we last talked about it 4 months ago:
*.corefiles, and let VUnit use those (instead of distributing the core of OSVVM only with VUnit). I'm not sure about OSVVM + FuseSoC making sense, but that would be just a useful outcome in case anyone needs it.
Those are my notes for layer 3. I hope to propose reshaping VUnit's runner for covering those use cases and hopefully running cocotb tests without a top-level testbench. But I need several months of knowledge yet, including learning more about pydoit, airflow and Patrick's layers 1-2.
*.profiles. However, I could also do it manually once. Using an editor with vertical/block selection is probably faster than reusing either the TCL or the pwsh scripts. Nevertheless, it didn't make much sense until those sources are usable. That is, until VUnit can execute OSVVM Configurations.
*.profiles explicitly, use wildcards and have it as a "cursed" example for implementing dependency scanning based on pyVHDLModel :smiley:. I like that idea because it's an exciting demo and it's also more idiomatic to feed wildcards into VUnit, rather than explicit filesets.
Do core files specify what to run in the simulator?
@JimLewis, it depends on which core files. In the ones currently supported by FuseSoc, I think it does. See, for instance, https://github.com/m-kru/fsva/blob/master/dummy_fusesoc_lib/osvvm/div_by_3.core#L21-L26. However, in https://github.com/umarcor/osvb/blob/main/AXI4Stream/AXI4Stream.core the "targets" are specified elsewhere.
*.corefile is used for synthesis and implementation with FuseSoC/edalize, but simulation is done with a Makefile, as well as implementation for some boards including Lattice devices.
I want to understand the similarities with regard to in-GUI commands that both OSVVM and VUnit provide. @GlenNicholls and nfranque (can't remember the specific nick) were working on that in the context of VUnit only. Does cocotb provide any feature in this regard?
If you want/need more info about the objective of that lmk
how is doit for python compared to rake for ruby regarding defining interdependence of tools and tasks in a workflow?
a make/rake-like build tool using Go. You write plain-old go functions, and Mage automatically uses them as Makefile-like runnable targets.
See the feature comparison I did back then between how I wanted
run to behave, and what was mage offering: https://github.com/dbhi/run#similar-projects. In hindsight, Golang was probably not the best choice for writing the prototype of run. So, my personal target is to achieve dbhi.github.io/concept/run using Python and without writing anything from scratch (not again). doit feels very similar to magefile, except it's Python instead of Go. Therefore, I blindly expect both of them to be very similar to rake.
Why separate W and AW?