Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 05:08

    tgingold on master

    pyGHDL/lsp: ignore setTrace req… pyGHDL/lsp: remove diagnostics … testsuite/pyunit/lsp: add a tes… (compare)

  • 04:49

    tgingold on master

    pyGHDL/lsp/workspace.py: handle… testsuite/pyunit/lsp: add a tes… testsuite/pyunit/lsp: adjust RE… (compare)

  • Jun 25 23:04
    sudden6 opened #2110
  • Jun 25 09:23
    Paebbels commented on 3ee40c4
  • Jun 25 08:44
    Paebbels synchronize #2105
  • Jun 25 06:56

    github-actions[bot] on nightly

    errorout_memory.py: decode mess… testsuite/pyunit: add a test fo… Add a readme in testsuite/pyuni… (compare)

  • Jun 25 06:46
    tgingold commented on 3ee40c4
  • Jun 25 06:26
    Paebbels commented on 3ee40c4
  • Jun 25 06:18

    tgingold on master

    errorout_memory.py: decode mess… testsuite/pyunit: add a test fo… Add a readme in testsuite/pyuni… (compare)

  • Jun 25 05:33

    github-actions[bot] on nightly

    testsuite/gna: add a test for #… pyGHDL/lsp: load files as bytes… (compare)

  • Jun 25 04:59

    tgingold on master

    testsuite/gna: add a test for #… pyGHDL/lsp: load files as bytes… (compare)

  • Jun 24 21:59
    Paebbels synchronize #2105
  • Jun 24 12:50
    SalttownUser edited #2108
  • Jun 24 12:49
    SalttownUser commented #2107
  • Jun 24 12:45
    SalttownUser synchronize #2108
  • Jun 24 09:30
    umarcor labeled #2109
  • Jun 24 05:00
    bewimm commented #2109
  • Jun 24 04:15
    tgingold closed #2101
  • Jun 24 04:10
    tgingold commented #2109
  • Jun 23 14:40
    SalttownUser commented #2108
tgingold
@tgingold
No strong opinion. I prefer an open-source solution, but moving has also a cost.
nobodywasishere
@nobodywasishere:eowyn.net
[m]
It could also be that all gitter chatrooms are automatically converted into matrix rooms in the future, in which case no change would be necessary
T. Meissner
@tmeissner
We use an zulip with an internal instance at work. It’s okay, you can have a lot of streams, it supports threads, private communication etc. What I don’t like are their electron based „native“ apps. I use it only in the browser instead.
Unai Martinez-Corral
@umarcor
@nobodywasishere:eowyn.net matrix being a decentralized/federated solution, it can be used regardless of the preferred centralized entrypoint. I don't see the point of making matrix the main entrypoint, because it is an aggregator from a conceptual point of view. Am I misunderstanding it?
nobodywasishere
@nobodywasishere:eowyn.net
[m]
@umarcor I'm not sure what you mean
Unai Martinez-Corral
@umarcor
@nobodywasishere:eowyn.net I mean there is no "matrix client". Matrix is a thing. Clients are a different thing. Therefore, zulip cannot be compared to matrix. zulip/gitter need to be compared to some client of matrix. From the user interaction point of view, having matrix below is not relevant.
That is, regardless of using zulip, gitter or element, matrix can still be used and any user can pick a different client.
My concern with using matrix "only" is that I'm unsure about the matrix protocol supporting non-message events, such as the webhooks from github/gitlab repos. With gitter/zulip, we get those features and users of matrix get the filtered content according to the features in that network.
nobodywasishere
@nobodywasishere:eowyn.net
[m]
From a user point of view, that makes sense.
Unai Martinez-Corral
@umarcor
Nonetheless, I might be confusing matrix and IRC. Maybe matrix does support threads and events.
nobodywasishere
@nobodywasishere:eowyn.net
[m]
To be honest I have no idea
Not even sure what those are used for currently (here)
Unai Martinez-Corral
@umarcor
Maybe @xiretza:xiretza.xyz can tell us something :wink:

Not even sure what those are used for currently (here)

If you extend the sidebar on the right, there is a sequence of notifications about commits, issues, etc. Not all users pay attention to it, but it's useful for maintaining organisations, since activity can go unnoticed in very busy days.
The complement to that feature is the ability to reference issues or PRs through #. I know this one is a client side thing, so it can be implemented in Element or any other client. Yet, I'd like someone to point at any example on a matrix client.

Unai Martinez-Corral
@umarcor
Also, permissions in gitter are inherited from GitHub. That's handy for having public and private rooms for coordination purposes.
2 replies
nobodywasishere
@nobodywasishere:eowyn.net
[m]
Since gitter is technically becoming a matrix client (soon), it would be gitter itself https://matrix.org/blog/2020/12/07/gitter-now-speaks-matrix
Unai Martinez-Corral
@umarcor
Anyway, I think we all agree that the main and most important feature is proper threads on desktop and smartphone clients.
Yeah. Gitter is good enough. That's why we are sticking to it. But the mobile client is really bad, and threads are not usable because of how notifications work.
Ed Bordin
@edbordin
@umarcor I was planning to keep fpga-toolchain going for a while but probably wanted to deprecate it eventually. The statically linked executables end up being something like 1GB when decompressed anyway iirc
can the hdl containers be run without root privileges?
Unai Martinez-Corral
@umarcor

@edbordin I guess that most users nowadays are expecting to use the tools more than once. Therefore, other packaging/distribution solutions are more desirable for them. However, fpga-toolchain is very interesting for workshops where you don't know which computers will people bring, or you cannot install much software on them. In those cases, fpga-toolchain can be provided in a pendrive, along with a development board. It's also interesting because the set of tools is not the minimal but it's neither too large. Hence, it allows workshops with multiple languages and also formal verification exercises. When you deprecate it, fomu-workshop will be affected. Yet, I'm adding documentation about how to use containers. 3-4 years ago, containers were not supported on any Windows, and gitpod did not exist. They are supported now. Hence, that's something that Sean and Tim will need to evaluate.

can the hdl containers be run without root privileges?

Yes. Those are OCI containers (https://opencontainers.org/). They should work with any compatible runtime (docker, podman, nerdctl/containerd, whatever k8s uses...). I use them with docker on Windows and with podman on Fedora.

Ed Bordin
@edbordin
@umarcor yes that's part of the motivation for leaving fpga-toolchain there for a while, will do my best to let people know that had linked to it from their docs and allow time to update them. I've tried the new package and it's a pretty similar experience to fpga-toolchain in terms of ease of use to get started - download, extract, run the included script to set up the shell
happy to move this discussion to hdl if it's more appropriate there
Miodrag Milanović
@mmicko

@umarcor

There is 1GB of Ubuntu system libs included in the tarball, and all the executables are wrapped in bash/perl scripts for overriding the linker and library paths.

Hi, sorry for late reply, well actually there is less then 200MB of libraries and other resources taken from Ubuntu 20.04, and plain docker for it is 134MB without any needed library, so docker image would probably be larger then distribution files. Also note that python2 and python3 distributed are not from taken from ubuntu but built so we can have same version for all OS-es and also some software links to python and that must be specific version, so yes that is about 200MB of various files but size would be same in docker image

Docker image would be good as well to be provided, but that would needed to be treated as new target OS, since it would require different build rules (due to python dependency), guess that docker would be nice to have at least for CI usage but to be honest in that case I would for example remove GUI tools which would lower deps and made it much smaller in size.
Miodrag Milanović
@mmicko
I would love to have GHDL plugin for yosys built and distributed, problem is that it is ADA based, and that is possible to cross compile to other linux variants , but have issue for darwin and windows targets
For sure I need to use LLVM based build, but problem in it is that it try to precompile VHDL libraries with created binaries which is not possible for all targets since no QEMU for macOS (darwin)
Would appreciate any help in making minimal ghdl plugin build that can work on all targets
Miodrag Milanović
@mmicko
Also apologize if it sounded for a time that I am not listening, it was more pressure to finish things and have it ready for customers, but keeping community in mind as well. Also testing all on various OSes and Linux distributions to see if GUI applications are running is not that fun :)
Unai Martinez-Corral
@umarcor

happy to move this discussion to hdl if it's more appropriate there

@edbordin, I believe that GHDL is the tricky piece. Most other projects are "typical" C/C++/Python tools, so the build and cross-compilation procedures are easier. Hence, it's up to you to discuss it here or in hdl/community. Most of the interested users do read both channels anyway.

actually there is less then 200MB of libraries and other resources taken from Ubuntu 20.04

@mmicko maybe the difference is because I looked at the size of the lib from oss-cad-suite-linux-x64-20210524 after extracting it? That's 1.06GB.

and plain docker for it is 134MB without any needed library, so docker image would probably be larger then distribution files.

I would say the size using containers would be the same, or the difference would be negligible. My concern is not the size, but the duplication of environment with a hand-made isolation procedure. In fpga-toolchain, most tools are compiled statically so that the environment is embedded in each tool. Containers do provide a proven isolation mechanism for system libraries (since that's their main purpose). In oss-cad-suite everything is handled as you would do in a container, an appimage, a flatpak, etc. but then no specific isolation tool is used. As commented in YosysHQ/oss-cad-suite-build#1, that is a lot of work! Containers/appimage/flatpak are non-trivial projects with many developers. oss-cad-suite is an almost single man project.

If you want a hierarchical and fixed development model, your approach is acceptable. You decide which tools to provide, you take care of preparing all of them, your clients stick to the use cases you explicitly support. If they want other use cases, they either improve your bundle or they hire you to do so. However, you will need to develop all the isolation related tweaks yourself, or you will need a significant effort for documenting all of it, so that potential contributors can help. Otherwise, it will be difficult for anyone to add their own additional system tools/libraries that interact with the ones in the bundle.

Moreover, if you wanted to introduce versioning of the tools, so that users could downgrade specific tools in the bundle, that would be something you would need to implement and document yourself. Doing so is already a huge effort even if existing package managers are used.

guess that docker would be nice to have at least for CI usage but to be honest in that case I would for example remove GUI tools which would lower deps and made it much smaller in size.

There are container images for CI usage, others for local usage and others with GUI tools. Size grows, respectively. CI images need to be small, specific and fast. Local images need to be complete and have handy tools. GUI tools need X11, Qt, Gtk... The advantage of containers is that all of those can be provided at the same time, and they can be composed. The outcome is that each user can pick the image that best fits. However, from a maintainer/development point of view, all the users
are using "the same" image. Conceptually, each "collection" in hdl/containers is a single several GB image that is presented in pieces of varying sizes.

See https://hdl.github.io/containers/#_tools_with_gui and https://github.com/ghdl/docker/blob/master/USE_CASES.md#environments-with-guis. Or any of the following gitpods: https://gitpod.io/#https://github.com/cocotb/cocotb, https://gitpod.io/#https://github.com/umarcor/msea.

Note that gitpod uses VSCode or Theia. That is, YosysHQ could provide a custom IDE that any user would launch either in the browser or locally. Moreover, it might be an specific flavour of TerosHDL. I very honestly think that would provide much market value to the product.


Please, do not take any of this as plain criticism. I do care about oss-cad-suite and I do believe it has some very relevant characteristics:

  • You are cross-compiling for 6 different architectures, including RISC-V.
  • You are providing some tools which are not packaged in other solutions yet. E.g. avy, sby-gui or project oxide.
  • The work you did for bringing up a working solution from scratch is impressive!
  • You have first-class access to the development of several very relevant tools in the ecosystem.

I would love to have GHDL plugin for yosys built and distributed, problem is that it is ADA based, and that is possible to cross compile to other linux variants , but have issue for darwin and windows targets

As commented in YosysHQ/oss-cad-suite-build#1, for distribution on Windows I very strongly recommend using MSYS2. If you don't want users to install MSYS2 explicitly, you can hide it from them with a wrapper. That is what projects Ruby or Qt do. GTKWave provides it too. You don't need to use the upstream recipes if you don't want to, but you can tweak those.

Recently, UCRT64 was added to MSYS2, which complements MINGW32, MINGW64 and CLANG64. UCRT64 should reduce possible corner cases when combining binaries with others built with VS.

For Linux, I avoid cross-compilation by using QEMU along with containers. See dbhi/qus and dbhi/docker. QEMU's user mode does not receive as much love as the system mode; hence, there might be issues with "weird" system signals. However, it works fairly well, and ARM support was improved significantly in these last 2 years. On the other hand, there are no official images for RISC-V yet. @carlosedp is pushing hard in that area: carlosedp/riscv-bringup.

For sure I need to use LLVM based build, but problem in it is that it try to precompile VHDL libraries with created binaries which is not possible for all targets since no QEMU for macOS (darwin)

You have issues for cross-building for macOS on ARM, from a Linux on x86-64?

Would appreciate any help in making minimal ghdl plugin build that can work on all targets

The plugin is not an issue. You can embed it into yosys. The plugin depends on the libghdl shared library. That is neither an issue, since you can build it. The problem is that almost all VHDL designs do depend on the standard and IEEE libraries. That's why, in practice, ghdl-yosys-plugin is said to depend on GHDL (on the installation, no the binary).

Theoretically, I'd say you could avoid building the libraries by providing an specific target to make. Then you would need to bundle GHDL, the shared libs, the headers, the includes and the VHDL sources of the libraries. Last, you would need to provide an script for building the libraries, similar to https://github.com/ghdl/ghdl/tree/master/scripts/vendors, which users would need to run once after extracting the bundle. However, I don't think anyone used that workflow in practice...

Also apologize if it sounded for a time that I am not listening, it was more pressure to finish things and have it ready for customers, but keeping community in mind as well.

It's ok. The pressure is very different since you want to provide an specific set of tools on some specific platforms for some specific users in a given timeframe. Conversely, in hdl/containers and hdl/MINGW-packages there is no specific set of tools, platforms, users or timeframe. That is the point: to use the canonical solutions, even if it takes longer to achieve a complete solution. That is because no one is explicitly funding those solutions, so the time that can be demanded is zero. Well, I must say that Google is donating a container registry with "unlimited" resources since a couple of days ago. I need to start using it, tho.

tgingold
@tgingold
@mmicko For the GHDL plugin: I am pretty sure there are cross-compilers for the windows targets. I am not sure for Darwin even if theorically that should be possible too.
For the standard libraries, there is no need to create the object files as they are used only for simulation. The standard libraries should be analyzed once, but the result is a text file that is portable (although I fear this hasn't been tested).
Miodrag Milanović
@mmicko
Thanks @umarcor for very detail answer, will check links you have provided regarding docker solutions, and have to think of best way of providing that. As you pointed out it is one-man-project so some things take time, and also there are other things I do. So will solve things like GHDL integration and docker environment , but some of that may take time due to proiorities
@tgingold will probably jump in here with more questions when time comes :)
Sammy Lin
@bkzshabbaz
Hello, I'm trying out an exercise where I'm generating a clock from within the FPGA and sending it out to a pin using the ODDRX1F primitive. I get this warning when I do so:
ERROR: cell type 'oddrx1f' is unsupported (instantiated as 'odd_inst.oddr_inst')
0 warnings, 1 error
Unai Martinez-Corral
@umarcor

I am pretty sure there are cross-compilers for the windows targets.

@tgingold maybe you mean https://github.com/hackfin/ghdl-cross.mk ? I think that is different. That generates a GHDL to be executed on Linux, which will produce simulation models for Windows. But GHDL itself is not cross-compiled.

@mmicko, absolutely no pressure or rush at all. Having a solid and stable open source EDA ecosystem is a mid-long term project that requires a lot of people to coordinate. We will get there, step by step.

@bkzshabbaz, please provide the full context of what you are trying to achieve. It seems that you are trying to use GHDL, ghdl-yosys-plugin and Yosys for synthesising a VHDL design targeting an ECP5 device?
Sammy Lin
@bkzshabbaz
That's correct.
Unai Martinez-Corral
@umarcor
@bkzshabbaz, then, I believe you are not including the "components", specifically the 'oddrx1f' component.
Those three examples are based on Makefiles. However, each of them uses an slightly different style and source organisation.
Sammy Lin
@bkzshabbaz
I am using the "components". I'm also using the EHXPLLL component, and it's not complaining about that.
I brought this up in the ulx3s gitter chat and they mentioned the oddrx1f component isn't capitalized.
@gatecat
It should be in capitals
I suspect there is some kind of GHDL issue going on here but don't know how to fix it
Unai Martinez-Corral
@umarcor
@bkzshabbaz if that is the case, please provide a MWE which we can execute and test. There have been some other issues related to lower/upper. Strictly, VHDL is not case sensitive, so it should not be relevant.
Sammy Lin
@bkzshabbaz
Will do. Does the rest of the toolchain's case sensitivity matter?
Unai Martinez-Corral
@umarcor
That might be the case. Maybe GHDL does not have a problem with it, but Yosys or nextpnr do.
Sammy Lin
@bkzshabbaz
Should I submit a Github issue?