However, that is mostly meant to avoid spam and (ro)bots. Being a member of the workgroup is free, and we want both experienced users and newcomers to participate. VHDL is a pilot project for applying Open Source development practices in IEEE projects. We are pushing in that direction as hard as we can.
All you need is be willing to help with the language somehow: providing use cases, asking for capabilities, replying to other members' suggestions, converting the LRM to LaTeX, reviewing the conversion, helping keep the website updated...
I felt this rant was slightly off-topic so I'm posting it here instead.
Responding to https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/69#note_617375903
VHDL does have something that resembles a class, protected types.
If you want my opinion, I don't really like the implementation of protected types. I don't think there was a good reason to add another incompatible set of call semantics just to achieve data encapsulation. Protected types could have simply been regular old types (and any type, not just record types) that with the keyword protected made the existing interfaces package-private. Functions ("methods") on those types could be defined in the package that could access the implementation's interface, and users would only have access to those "public" functions. However, users could extend the interface by providing overloads for those protected types in other scopes, like they could for regular types. Class-based OO and method dispatching is old-school, has an inherent expression problem, and doesn't really jive with the Ada-derived type system that VHDL has.
VUnit does have two variants of some APIs, implemented both as you commented (for <2008) and using protected types (for >=2008).
I think this proves my point about the multiple types of call semantics. Imagine instead having something akin to an ifdef "turn on" encapsulation by conditionally adding the protected keyword if the language version is >= 2008.
VHDLproc, which I'm still working on.
Repost from @LarsAsplund
Let's see if we can have a LinkedIn survey with any statistical significance https://www.linkedin.com/posts/plc2-gmbh_vhdl-osvvm-fpga-ugcPost-6817744189200076800-OUeX
Question re: VHDL 2019. With the following generic specification:
generic (
type designated_subtype; -- any type
type access_type is access designated_subtype -- an access type
);Would it be required that both types here be mapped to existing types, or can the access type here be left "open" as it is a fully defined type once designated_subtype is assigned? for example, this is effectively the example given in 6.5.3.3
generic map (
designated_subtype => string,
access_type => line
);Would it also be legal to do the following:
generic map (
designated_subtype => string
);Now access_type is a fully defined type that exists only within the same region as the generic. It is NOT type lineas this was not mapped.
I cannot find anything in 6.5.7.2 that appears to require the type be assigned an actual type.
@trickyhead_gitlab I think maybe the other way around may be allowed. From type line, you can find its designated_subtype using attributes.
However, without mapping type line, access_type would then have to be a unique type and if you wanted anything in the package to have a parameter or return value that is type access_type, then its type will not be known outside the package.
@JimLewis Actually, LRM says this:
It is an error if no such actual is specified for a given formal generic type (either because the formal generic is unassociated or because the actual is open).
So I guess they cannot be left unconnected (and maybe its worth filing a ticket)
When you define this:
type line1 is access string;
type line2 is access string;you get 2 incompatible types.
designated_type generic, because the access_type holds all needed information.
P2 in the LRM.
architecture A of E is
package I2 is new P2
generic map (
access_type => line
);
begin
end architecture;type t; is legal as a forward type declaration, but it requires the complete type at a later point in the same unit
package P2 is
generic (
type designated_subtype
);
type fred is access designated_subtype ;type tricky_pt is new protected pt
generic map (
....
);
either create a library file first, then run ghdl-yosys-plugin on that:
ghdl analyze file1.vhdl file2.vhdl subdir/file3.vhdl
ghdl elaborate topentity
yosys -m ghdl -p 'ghdl topentity'or run ghdl-yosys-plugin directly on the files, without creating a library file:
yosys -m ghdl -p 'ghdl file1.vhdl file2.vhdl subdir/file3.vhdl -e topentity'in general, the yosys ghdl command is equivalent to invoking the ghdl binary as ghdl --synth.
Actually, there is another solution in-between:
ghdl analyze file1.vhdl file2.vhdl subdir/file3.vhdl
yosys -m ghdl -p 'ghdl -e topentity'That is useful if the files are analysed in a library different to the top-level, but you don't care about the logical lib name of the top-level:
ghdl analyze --work=designlib file1.vhdl file2.vhdl subdir/file3.vhdl
yosys -m ghdl -p 'ghdl toplevel.vhd -e topentity'# Synthesis
yosys -m ghdl -p 'ghdl --work=designlib file1.vhdl file2.vhdl subdir/file3.vhdl --work=anyother toplevel.vhd -e topentity'
# Analysis and Elaboration
ghdl -a \
--work=designlib file1.vhdl file2.vhdl subdir/file3.vhdl \
--work=anyother toplevel.vhd testbench.vhd \
-e topentity
# elab-run
ghdl elab-run \
--work=designlib file1.vhdl file2.vhdl subdir/file3.vhdl \
--work=anyother toplevel.vhd testbench.vhd \
-e topentity \
--wave=mywave.ghw
entity test is
end test;
architecture rtl of test is
function f return real is
function f return real is
begin
return 3.14;
end f;
begin
return f;
end f;
begin
process
begin
report real'image(f);
wait;
end process;
end rtl;