Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 30 19:54
    tgingold commented #1827
  • Jul 30 19:49
    Paebbels commented #1827
  • Jul 30 17:20
    tgingold commented #1827
  • Jul 30 14:32
    umarcor commented #1826
  • Jul 30 14:31
    umarcor commented #1826
  • Jul 30 07:00
    Paebbels synchronize #1822
  • Jul 30 06:41
    Paebbels commented #1827
  • Jul 30 06:26
    Paebbels commented #1826
  • Jul 30 06:07
    tgingold commented #1827
  • Jul 30 05:54
    tgingold commented #1826
  • Jul 30 02:30
    umarcor opened #1827
  • Jul 30 00:46
    Paebbels labeled #1826
  • Jul 30 00:46
    Paebbels assigned #1826
  • Jul 30 00:46
    Paebbels commented #1826
  • Jul 30 00:41
    umarcor opened #1826
  • Jul 30 00:41
    umarcor labeled #1826
  • Jul 30 00:14
    Paebbels synchronize #1822
  • Jul 29 21:37
    Paebbels synchronize #1822
  • Jul 29 19:25

    github-actions[bot] on nightly

    libghw: add missing semicolon t… (compare)

  • Jul 29 19:21

    github-actions[bot] on nightly

    vhdl-parse: use if_generate_els… testsuite/gna: add a case for #… (compare)

Chips4Makers
@fatsiefs:matrix.org
[m]
@umarcor: I disagree on the 5-10 year timeframe for nmigen usability. I have used VHDL code in nmigen design, used cocotb with modelsim (proprietary I know) for mixed-signal sim. But I agree this is own development not general available. And with GHDL you can only simulate VHDL.
I would rather nmigen not be VHDL with a python syntax as I prefer the implementation of clock domain and synchronous logic over the VHDL one. Maybe you are more interested in MyHDL then as I see that as a reimplementation of VHDL/Verilog mistakes in python 🙂
Kaleb Barrett
@ktbarrett
@umarcor You would compare nMigen to VHDL? I think they pretty different in approach. nMigen is a Python metaprogramming framework on top of a functional RTL-oriented DSL. VHDL is a more traditional simulation language.
tgingold
@tgingold
@ktbarrett --vhpi-trace
Kaleb Barrett
@ktbarrett
@tgingold thanks. I'll add that to the docs.
Martin
@hackfin
@umarcor there are mature FP toolboxes for MyHDL I know of. But isn't this a bit off topic?
vblanco20-1
@vblanco20-1
Maybe you know about it. Ive been using a Basys3 board as its the university one, but im continuing development past university and need to get a new FPGA. Ive been thinking of the board that the MisTER project uses, which is a DE-10 Nano (intel). How is the ecosystem with that vs the xilinx based stuff of the basys3?
for the goal of creating a full reimplementation of a gameboy and other cpu-related projects
vblanco20-1
@vblanco20-1
the actual fpga is Artix7 (basys3) vs Cyclone5(Nano)
Kaleb Barrett
@ktbarrett
@vblanco20-1 By CPU projects do you mean softcore or SoC? A Zybo board would work if you want to stay in the Xilinx ecosystem. It's what we used in my undergrad (after upgrading from Nexys 3's) It has roughly the same amount of PL as the basys3 + an ARM processor. There are PMOD adapters for VGA. Oh there is a discount if you still have your .edu address.
vblanco20-1
@vblanco20-1
more about creating cpus
the de10nano is used in the mister project which is something i could contribute to or have fun tinkering with
absolute best would be an Analogue Pocket but seems those will be impossible to fund
portable fpga in the shape of a gameboy with fun features and stuff
Julian Kemmerer
@JulianKemmerer
Hi folks couldn't help but see yall were talking about alternative HDLs, comparing the 'domain specificness' of them - which i definitely hear the 'generate me a SoC' bias in some of those
And then of course that generating vhdl from these tools
So i just wanted to point everyone to yet another tool , PipelineC, generates vhdl and works with ghdl yosys next pnr flow https://github.com/JulianKemmerer/PipelineC/wiki
vblanco20-1
@vblanco20-1
@JulianKemmerer HLS?
well not so high level
that actually looks great,
like exactly what i would like for my project
Julian Kemmerer
@JulianKemmerer
Hey thanks eh - you can do hdl style or hls auto pipeline style , combine the two
More than happy to help you get going on something
@vblanco20-1
Unai Martinez-Corral
@umarcor

I disagree on the 5-10 year timeframe for nmigen usability. I have used VHDL code in nmigen design, used cocotb with modelsim (proprietary I know) for mixed-signal sim. But I agree this is own development not general available.

@fatsiefs:matrix.org I meant 5-10y since someone decides to (re)invent a language, not from now onward. nmigen has been 3y in development after 10y of migen and +10y of myHDL. It didn't come out of nowhere.
By the same token, 3y ago cocotb was dead, after a very successful start. FOSSi, Kaleb and others spent the last 2 years working so hard, and they still have at least 1y of development for starting to consider it mature.
Note that my reply was targeted at a person that suggested he would write his own HDL from scratch. I suggested him to better build on any of those existing projects/languages precisely so those can get to maturity faster.

You would compare nMigen to VHDL? I think they pretty different in approach. nMigen is a Python metaprogramming framework on top of a functional RTL-oriented DSL. VHDL is a more traditional simulation language.

@ktbarret, could you please elaborate? I'm thinking about a user who needs to learn both hardware design and a language for hardware description at the same time, as a tool for them to use in the following 1-2 decades. I don't think whether the implementation is a metaprogramming language or a traditional language is relevant. It's about what they can express and what they cannot. Entities/architectures/modules/components/bodies, structs/records/interfaces, FFs/memories, boolean logic/muxes, fixed-point and floating-point DSP...

there are mature FP toolboxes for MyHDL I know of. But isn't this a bit off topic?

@hackfin, would mind providing any reference?

We can continue in hdl/community, if you prefer.

Ive been thinking of the board that the MisTER project uses, which is a DE-10 Nano (intel). How is the ecosystem with that vs the xilinx based stuff of the basys3

@vblanco20-1 I suggest you ask in the symbiflow channel in IRC, and/or in project mistral. Support for intel/altera devices is less advanced than Lattice or Xilinx. For Xilinx, there are two PnR tools, nextpnr and VTR. For Intel, I think they are working with nextpnr only.

I would recommend an ECP5 device and a board with an Artix.

I would stay away from Zynq, unless you have any actual usage for the single or dual ARM cores. You cannot use the PL without understanding and initialising the PS.
I have a PYNQ-Z1 and some Arty, and there is no advantage in the first one for RTL only designs. However, Zynq is very interesting if you want to run Linux on ARM and accelerate things in the FPGA.

the de10nano is used in the mister project which is something i could contribute to or have fun tinkering with

I believe that the mister project might greatly benefit from being ported/adapted to an open board based on one of the largest ECP5. However, mister seems to be not only the FPGA board, but a whole stack of boards...

vblanco20-1
@vblanco20-1
the boards are basically addons
the main thing is on the de-10 nano, but the extras are to give it extra ram, more usb ports, and analog output (VGA)
Kaleb Barrett
@ktbarrett
@marlonjames Thanks. I figured those options would be with the other trace options in the debug section, which is what confused me.
Unai Martinez-Corral
@umarcor

the main thing is on the de-10 nano, but the extras are to give it extra ram, more usb ports, and analog output (VGA)

@vblanco20-1 With some ECP5 or Artix boards you would have some of those extras. For instance https://shop.lambdaconcept.com/home/46-2-ecpix-5.html#/2-ecpix_5_fpga-ecpix_5_85f, as direct alternative to Arty/Zybo.

@ktbarrett, feel free to propose moving --vpi-trace and --vhpi-trace into section Development/Debugging. That section is relatively new.
Kaleb Barrett
@ktbarrett

@umarcor

and they still have at least 1y of development for starting to consider it mature.

Probably a lot more than that, especially with how few contributors we have, how averse to large changes the project is, and how grindy the review process is. To meet some of the needs of users we need to do significant rewrites of many of the components, but I don't see that as possible... And there is a lot of related work that needs to be done:

  • integrate with other project management tools like VUnit and/or edalize/fusesoc
  • develop a verification framework on top of cocotb
  • write articles, case studies, develop more serious examples, tutorial videos, etc.

At the current pace I see it as 4 more years.

I don't think whether the implementation is a metaprogramming language or a traditional language is relevant.

Sure. I didn't know to what extent you were trying to make comparisons.

I suggested him to better build on any of those existing projects/languages precisely so those can get to maturity faster.

This is kind of what I am doing as a verification framework on top of cocotb. It keeps changing and it's looking more and more like an HDL... Processes, "modules" (probably need a better name since Python already has modules), channels and synchronous channels (blocking send returns after placement in queue vs recv by destination, which a generalization of a "signal"), accompanied by a set of HDL datatypes making their way into cocotb.

Unai Martinez-Corral
@umarcor

@ktbarrett, thanks so much for acknowledging that. I believe that VUnit, OSVVM and others are in a similar state. Even though their codebase is more mature (OSVVM +20y, VUnit almost 10y), the integration with others, writing articles, tutorials, etc. is a challenge we all need to address, because we are very few in each of the projects.

This is kind of what I am doing as a verification framework on top of cocotb. It keeps changing and it's looking more and more like an HDL... (...) accompanied by a set of HDL datatypes making their way into cocotb.

I don't know if I already told you about my conception of using cocotb's Python interface for driving the VHDL Verification Components of VUnit and/or OSVVM. Not something I will solve in the following weeks or months, but that is my target in say 5 years. Hence, there is lots of conceptual overlapping with what you are trying to achieve. Channels, message passing, queues, a virtual memory with permissions, etc. all those software tools for verification are already written in VHDL and customised for the standard interfaces. We should not reimplement that in Python nor do bit-banging through indirect cosimulation interfaces. Unfortunately, I'm not expert enough yet for proposing an specific implementation for achieving that. First things first, I need to solve the envvar management in VUnit, which that cocotb user asked, and which I'm finding I need for other use cases (customising LD_LIBRARY_PATH when doing cosimulation with VUnit and GHDL through VHPIDIRECT).

You might find interesting the work I'm doing with NEORV32 and fomu-workshop as a demo/tutorial of simulation, verification and implementation with open source tooling. I would love to see cocotb in fomu-workshop. However, I'm not familiar enough with cocotb+verilator or cocotb+iverilog yet.
Unai Martinez-Corral
@umarcor
People from 1bitsquared are about to put icebreaker-bitsy in the market (feather form factor compatible, 5K LUT, few DSP, RAM, dynamic reconfiguration) at ~35€. I believe that'd be an awesome complement to the Fomu for hardware (RTL) people, since it has actual I/O which students can use.
I know this is probably irrelevant for most of you, professional users of VHDL/GHDL, but I do believe it is very important with regard to articles, case studies, examples, tutorials, etc.
Unai Martinez-Corral
@umarcor
@tgingold, in the last meeting I was discussing with @marlonjames about the requirement of function bodies to exist at elaboration time. There are two constraints:
  • If a subprogram has a foreign attribute, the foreign body must exist. This was discussed in ghdl/ghdl#793 and we all agree that's something the tools might require.
  • A subprogram needs to have a VHDL body, even if a foreign attribute is declared. This is something we all agree not to make sense, and which might be an oversight. However, we could not find where in the LRM is that specified, nor did I find any issue in the ghdl repo where we discussed it explicitly. I know we have discussed it either there or in this chat, tho. Can you or anyone provide a hint?
tgingold
@tgingold
I don't think it was discussed in an issue, so probably in a forum.
According to the LRM, every subprogram must have a body. Foreign or not.
Unai Martinez-Corral
@umarcor
Thanks, so maybe it was in a private conversation and the search is not working there :laughing:
Kaleb Barrett
@ktbarrett

all those software tools for verification are already written in VHDL and customised for the standard interfaces. We should not reimplement that in Python nor do bit-banging through indirect cosimulation interfaces.

Well, this is kind of the entire point of cocotb. Write testbenches in Python instead of VHDL or (System)Verilog. I could see implementing drivers/monitors in VHDL or SystemVerilog and controlling them from a cocotb test as a (very) useful optimization and to cover cases where the VPI isn't sufficient (tri-state drivers), but that would require a lot of tooling because I would like something like that to be automated. One of the things people like about cocotb is not having to write any VHDL/(System)Verilog for the testbench, or even write a top at all. And I don't see how that precludes implementing the same functionality in cocotb to handle the cases where moving the implementation to HDL is not possible or just too time consuming to be useful.

You might be interested in pybfms which is similar to this. IIRC it uses VPI system tasks to enable communication between cocotb and Verilog BFMs.

I'm not familiar enough with cocotb+verilator or cocotb+iverilog yet

That reminds me of one more task to reach maturity: Mature the GHDL and Verilator VPI/VHPI interfaces so cocotb will work with them.

Unai Martinez-Corral
@umarcor

but that would require a lot of tooling because I would like something like that to be automated.

A verification component is a black-box with a software API on one side and a hardware interface on the other. Adding an VC between the HDL interface and the software procedure is the most automated and transparent solution for the users. They should not write any code in any case, just their application specific software procedure. The question is whether VCs need to be written in HDL only, in Python only, or half HDL half Python. I believe it needs to be the last one. We can request developers to know both languages, even though users won't. Currently, developers need to know VPI/VHPI although users do not.

I agree it would require tooling, but not more than it required to automate the usage of HDL only VCs or Python only VCs. That is a library management issue we have in the EDA industry, not specific in this case.

You might be interested in pybfms which is similar to this. IIRC it uses VPI system tasks to enable communication between cocotb and Verilog BFMs.

Yeah, that's kind of the idea. Anyway, we first need to solve how to call VHDL subprograms from a foreign language, which is not defined yet. That's part of the VHDPI discussion, but it might not get into the first revision.

In ghdl-cosim there is an example of the opposite: using a VHDL protected type with foreign attributes for exposing a C API in VHDL. The idea is the same: get a handle of the class/object from the other language and call the methods as the software API of the "standard interface".

Mature the GHDL and Verilator VPI/VHPI interfaces so cocotb will work with them.

This is my priority with GHDL. I need to get to implement some changes myself so I can actually start fixing things and not just annoying Tristan with bug reports and requests.

Patrick Lehmann
@Paebbels

In the last days, I did a lot of enhancements for pyVHDLModel which is used by pyVHDLParser and also GHDL. The VHDL language model is the basis for the dom namespace in pyGHDL.

I think until end of the week I can finalize a first pretty-printing demonstrator, which parses a VHDL file with GHDL's libghdl, uses GHDL's Python bindings and transforms GHDL's internal data structure (IIR) to a Python-based document object model (DOM) that represents a VHDL file with instances of classes and references (points) among them.

The pretty-printer example emits the translated object model to text. From there it should be easy to provide other output formats like JSON or YAML (if needed).
Of cause, users can use the object model in there own libraries or tools based on GHDL's Python API.

Even if my own project pyVHDLParser is not as advanced and working like GHDL, it's till planned to have a second source besides parsing via libghdl to create a object model using pyVHDLModel as a common interface.

What is it good for?
We can now think about generating documentation - especially in Python based tools like Sphinx - from VHDL code parsed by libghdl. What I can do so far is:

  • list entities, architectures, packages, package bodies, contexts and configurations
  • list generics (constants) for entities
  • list ports (signals) for entities
  • list declared items in architectures (packages will follow soon)
    • constants
    • signals
    • types
    • subtypes
    • functions (procedures will follow soon)
  • list constraints in e.g. port/generic declarations
  • parse expressions in e.g. range expressions like std_logic_vector(BITS - 1 downto 0)

Example output (pretty printed DOM):

Document 'testsuite\pyunit\SimpleEntity.vhdl':
  Entities:
  - entity1
    Generics:
      - bits : in positive
    Ports:
      - clock : in std_logic
      - reset : in std_logic
      - q : out std_logic_vector(bits - 1 downto 0)
  Architectures:
  - behav
  Packages:
  PackageBodies:
  Configurations:
  Contexts:
In an upcoming PR, I'll provide a cli/DOM.py which can be called with a VHDL file as parameter to call the pretty-printing example code.
xiretza
@xiretza:xiretza.xyz
[m]
is there a good reason why ghdl is only tested on windows, and thus GCC isn't tested at all?
Unai Martinez-Corral
@umarcor
@xiretza:xiretza.xyz that is not correct. Do you mean just the last test I added?
xiretza
@xiretza:xiretza.xyz
[m]
...actually, nevermind, the build jobs on linux also run tests, but for windows building and testing are separate jobs. intersting.
Unai Martinez-Corral
@umarcor
Yes. That is because of performance reasons.
xiretza
@xiretza:xiretza.xyz
[m]
ah, just the usual job setup overhead (fetching containers, fetching repo, etc) or is there something else?
Unai Martinez-Corral
@umarcor

When using containers, we do:

  1. Compile on a build container.
  2. Create a run container with the compiled artifacts.
  3. Run the full testsuite in the run container.
  4. If successful, push.

That's all in a single step (TASK=... ./scripts/ci-run.sh -c).

ah, just the usual job setup overhead (fetching containers, fetching repo, etc) or is there something else?

The opposite. Containers are fast. Windows is slow.