An idea I have likely matches exactly what you said - if the user provides the access type, they can return a value in a known type. If they do not care about the access type, it remains a unique type, used internally only
I requested generic array types and generic access types. I actually want a generic access type of a generic array type (with the base type discoverable via 'element)
In most of my imagined use cases, the access type is not required externally, but its nice to have for completness
@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.
Thus you need to handover the access type to the protected type, entity or package as a generic type, so you can use it internally as access type or extract from it it's designated type.
To simplify your code, you can remove the
designated_type generic, because the access_type holds all needed information.
See the example given in
P2 in the LRM.
architecture A of E is
package I2 is new P2
generic map (
access_type => line
);
begin
end architecture;
but why cant the type be formed in the generic region, if a type is left "open" . There is no object created yet, hence is doesnt have to have a value like a normal generic. Also, simply writing
type t; is legal as a forward type declaration, but it requires the complete type at a later point in the same unit
I am aware that no connecting the access type makes a brand new type and its not compatable, and thats my point - why shouldnt you be able to do this? inside the package (or other region) you have no care or knowledge of what the type actually is. You cannot have code that is conditional based on type.
package P2 is
generic (
type designated_subtype
);
type fred is access designated_subtype ;
I think you have a choice, either the access type is a type externally defined and you need to create a package that uses it - or - the type is an internally defined type that is unique.
I don't think you can have either depending on how you use it.
type tricky_pt is new protected pt
generic map (
....
);
Hi everyone, is there an example for using the GHDL plugin in Yosys with multiple files? So far, I found a couple of examples but all use a single VHDL file. If I try to add multiple files the usual way (first analyse them via ‘-a’, then elaborate via ‘-e’), I get an error message that option ‘-a’ is not supported.
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'
Furthermore, we have discussed about supporting a single line syntax which allows defining multiple libraries at once. That would work for both synthesis and elab-run.
So maybe (NOT SUPPORTED YET):
# 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
Is this legal?
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;
function f return real;
function f return integer is
begin
return integer(real'(f));
end f;
A bit of history. Had a discussion on LinkedIn today with Cliff Berg who is a co-founder of https://www.agile2academy.com, an author of books about Agile and generally involved in the topic. Turns out that he has a background in VHDL.
I was on the team that created VHDL. I was probably the first person to actually write VHDL, since my task on the team was to write VHDL and see how usable it was.
Obviously he thought it was useful enough so here we are....
@d3jones - :point_up: July 20, 2021 7:48 AM - Your nested F-function looks to me like it would be an ambiguous call and, if it is, should be illegal.
Which is why I was having so much trouble with that rule. It is not clear what "Within the specification of a subprogram" modifies. I may very well file a PR on this.
