Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 18:14
    tspyrou commented #46
  • 18:10
    tspyrou opened #46
  • Sep 20 13:48
    kamilrakoczy edited #132
  • Sep 20 13:47
    kamilrakoczy opened #132
  • Sep 20 13:46

    kamilrakoczy on uhdm-yosys-fix-libffi

    yosys-uhdm: fix missing libffi … WIP: build only yosys-uhdm Sig… (compare)

  • Sep 20 12:34
    PiotrZierhoffer commented #31
  • Sep 20 12:33
    PiotrZierhoffer opened #31
  • Sep 20 09:37

    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)

  • Sep 20 07:49
    avelure starred hdl/containers
  • Sep 19 07:33
    ptracton starred hdl/constraints
  • Sep 19 01:02
    themainframe starred hdl/constraints
  • Sep 18 23:50
    QuantamHD commented #51
  • Sep 18 00:53
    aolofsson starred hdl/constraints
  • Sep 17 18:39

    ajelinski on fix-symbiflow-plugins

    (compare)

  • Sep 17 18:39

    ajelinski on master

    yosys-plugins-symbiflow; symbif… Merge pull request #131 from hd… (compare)

  • Sep 17 18:39
    ajelinski closed #131
  • Sep 17 18:07
    swang203 starred hdl/bazel_rules_hdl
  • Sep 17 08:12
    kamilrakoczy review_requested #131
  • Sep 17 06:22
    kamilrakoczy edited #131
  • Sep 17 06:22
    kamilrakoczy synchronize #131
Karol Gugala
@kgugala
one comment to Litex - it uses migen
Unai Martinez-Corral
@umarcor
@kgugala, "exactly" migen, or a variant/fork of it?
Karol Gugala
@kgugala
mainline migen
Unai Martinez-Corral
@umarcor
:thumbsup:
Rodrigo A. Melo
@rodrigomelo9
Thanks @umarcor, but it is not for symbiflow_cli, it is to be introduced where I work . @kgugala can I use Litex for SV cores (our SoC is already build based on System Verilog/ Verilog IPs)? could you point me an example?
Karol Gugala
@kgugala
@rodrigomelo9 LiteX itself does not tie you to any specific HDL
you can wrap what you want
Rodrigo A. Melo
@rodrigomelo9
Sounds good :-D
Karol Gugala
@kgugala
it's more a tool issue
if your tool supports SV (and mixing it with Verilog genereted from migen) it should work
Rodrigo A. Melo
@rodrigomelo9
Got it, I will try LiteX :-D
Chips4Makers
@fatsiefs:matrix.org
[m]

@ktbarrett:

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 ?

2 replies
Chips4Makers
@fatsiefs:matrix.org
[m]
@ktbarrett: thanks.
Unai Martinez-Corral
@umarcor
@fatsiefs:matrix.org I cannot remember whether I wrote it down explicitly, but your previous comments about switching from make to doit were the trigger for me to try pydoit in NEORV32.
I still need to have a better feel of airflow (and variants), but so far doit fits rather perfectly for the "an ideal automation framework with all ready to use workflows will never exist". We need to provide building blocks for users to compose their own custom workflows, because users are developers.
Oh, I did mention it in the Context of stnolting/neorv32#110.
Chips4Makers
@fatsiefs:matrix.org
[m]
@umarcor: I got github notification because you mentioned me in the commit I think. I am currently mainly using it as a Makefile replacement so I do use the file depenency feature because that's what a lot of tools do: generate files.
But I would love it that for example FuseSOC (ping @olofk (Olof Kindgren) would be a python module that can spit out doit tasks and not implement it's own task management.
Unai Martinez-Corral
@umarcor

@fatsiefs:matrix.org that is exactly my point of view. On both points you mentioned:

  • In NEORV32, I'm proposing to use doit as a replacement of Makefiles which allows scripting in Python instead of make/bash only.
  • In the mid term, I'm pushing so that edalize, pyfpga and others are "task and workflow providers". Ideally, "workflow providers" only because there would be a common source for tasks. That common source of tasks should not be for FPGA simulation/synthesis only, but bring in the tools used in openroad and libre-soc.

Therefore, the discussion with Kaleb and Patrick is relevant because we are trying to shape those reusable tasks.

They do have a Python and software background which I lack.
Unai Martinez-Corral
@umarcor

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:

  • The entrypoint to OSVVM tests are VHDL Configurations (which are not the same as the "configuration" term used in VUnit). Although OSVVM can also use entities, I want to be able to execute existing OSVVM entrypoints. @LarsAsplund is open to it if that implies that OSVVM will use/support VUnit's py plumbing.
    • I'm working with @JimLewis, for introducing him to CI by using his TCL plumbing on MSYS2 (OSVVM/OsvvmLibraries#2), which is the main workflow he uses and teaches. I added a Linux job too.
    • I want to convert OSVVM's *.pro files to *.core files, 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.
    • 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?
  • I need to support custom environment variables for each testbench/test in VUnit. That's something that a contributor of cocotb brought up (I remember his green avatar, the nick starts with 'j', and he reads several rooms frequently, but I cannot remember his nick now) in Feb. In May, I found I needed that feature myself in a different use case.
  • pyVHDLModel allows to generate a VHDL testbench programmatically after parsing an existing entity. The main stopper for VUnit to run cocotb testbenches as-is was the need to autogenerate that testbench (or to require the users to do it). Now that can be hidden from the users. It is arguable whether implementing this is faster/easier than adapting VUnit's runner for executing cocotb's testbenches (similarly to running OSVVM's Configurations). I'm not doing any claim in that regard.

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.

Jim Lewis
@JimLewis
@umarcor WRT generating *.core files or anything else, it would be possible to create an application layer in the OSVVM scripts that could do that. Look at the VendorScripts_GHDL.tcl for an idea. All it would have to do is instead of doing an action that executed something, it could do a tcl "puts" to output the appropriate .core file information.
Jim Lewis
@JimLewis
To understand what I mean, look at the log file for GHDL created by OSVVM .pro script - it contains a log of all the commands run - and for the simulations the output.
Unai Martinez-Corral
@umarcor
It's @jwprice100 the user whose nick I did not remember above.
Unai Martinez-Corral
@umarcor
@JimLewis I thought about using Patrick's powershell vendor scripts, which are equivalent to the TCL scripts in that regard. Both of them parse the *.pro files. 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.
There is another recent motivation for doing it: instead of converting the *.pro files 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.
Jim Lewis
@JimLewis
Ok. I noticed on the core file someone manually generated for osvvm that there is a problem. Osvvm.pro has a conditional in it.
Do core files specify what to run in the simulator?
BTW, .pro files are executable tcl. This is the difference between the .pro and our older formats.
Unai Martinez-Corral
@umarcor

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.

Unai Martinez-Corral
@umarcor
In https://github.com/antonblanchard/microwatt/blob/master/microwatt.core, a *.core file 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.
GlenNicholls
@GlenNicholls

@umarcor

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

Unai Martinez-Corral
@umarcor
:thumbsup: :heart:
Jim Lewis
@JimLewis
@GlenNicholls OSVVMs's in-GUI commands are documented in GitHub readme: https://github.com/OSVVM/OSVVM-Scripts/tree/master or in pdf: https://github.com/OSVVM/Documentation/blob/master/Script_user_guide.pdf
In either case it is short and simple.
svenn71
@svenn71
Where can I find the container for Cadence Xcelium? :smile:
ktbarrett
@ktbarrett:matrix.org
[m]
They call that one the garbage bin 😏
Unai Martinez-Corral
@umarcor
@svenn71 we cannot provide containers for non-open source software. We are not allowed. However, we can host dockerfiles for users to build containers themselves. I am not aware of anyone using Xcelium containers, tho. I've heard or used ModelSim/QuestaSim, Precision, Vivado and Radiant, but not Xcelium.
svenn71
@svenn71
I am very familiar with the licensing model of the big three
svenn71
@svenn71
I wish Netflix would read through John Cooleys Deep Chip and have somebody create a TV series like Mad Men for the EDA business throughout the 80s, 90s, 00s and 10s. I think it would be a fun thing to watch
Tim Ansell
@mithro
svenn71: I'm pretty sure nobody would believe it
svenn71
@svenn71
I didn't believe Mad Men either, but then I started googling .....
Unai Martinez-Corral
@umarcor

how is doit for python compared to rake for ruby regarding defining interdependence of tools and tasks in a workflow?

@svenn71 I'm not familiar with rake. However, some years ago I prototyped dbhi/run. One of the tools that I analysed was magefile, which is defined as:

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.

Kaleb Barrett
@ktbarrett
Does anyone have a document on the justifications for the design of AXI? Me and a colleague were discussing it earlier and we are both curious. Perhaps they are buried in implications in the spec, but I'd like some more easily readable, if that exists.
Patrick Lehmann
@Paebbels
you mean why AXI is built as it is built?
Kaleb Barrett
@ktbarrett
Yes. For example, "Why separate W and AW?", "Why separate, but required, read and write channel sets?", "Why are bursts decided by client instead of the bus arbitrator?", "Why master/slave instead of omnidirectional?", etc. Some of them become obvious if you think it through, others aren't, and I'd like to see how AXI became what it became.
Patrick Lehmann
@Paebbels
Why separate W and AW?
  • for read, address and data is separated.
  • in parity, write is following this
  • you can send address first, data first, or both at the same time
  • in case of bursts, buffering is different for addresses and data. Reduced FIFO size for max outstanding bursts vs. max data capacity
1 reply
Patrick Lehmann
@Paebbels
Why separate, but required, read and write channel sets?
  • you can have AXI-S to AXI-MM writers and an independent AXI-MM to AXI-S readers
  • you can have independent buffering on write and read paths

Why are bursts decided by client instead of the bus arbitrator?

Can you explain this?

1 reply

Why master/slave instead of omnidirectional?

Omnidirectional does not exists, it's
master => slave
slave <= master
just merged into one.

svenn71
@svenn71
no precharged buses anymore?