For my VHDL-2019: Just the New Stuff presentations, I created a VHDL-2019 code archive at:
https://gitlab.com/synthworks/VHDL_2019
https://gitlab.com/synthworks/VHDL_2019
I came across this oddity compiling my testbench today.
package gen_pkg is
generic ( W : natural );
constant CONST : natural := W;
end package gen_pkg;
entity name_clash is
end entity name_clash;
architecture clash of name_clash is
package pkg is new work.gen_pkg generic map( 8 );
use pkg.all;
begin
p: process
package pkg is new work.gen_pkg generic map( 9 );
use pkg.all;
begin
report to_string(CONST);
wait;
end process;
end architecture;With this code, I get the error that the reference to CONST is ambiguous as it can I see two packages where it is visible. The question is, I know I can get to pkg.CONST local to the process, but how could I get the reference to CONST in the package in the architecture?
( The double declaration in my code was an error, but it got me wondering )
I think there should be also a variant of a selected name, where you start from label
p. but I'm not sure if it is p.pkg.CONST or just p.CONST because you used all.
OTOH, it should be ambiguous in the first place, because the one in the process should shadow the one from architecture. It's a new scope.
PS C:\Temp> ghdl.exe -a --std=08 "C:\msys64\home\Patrick Lehmann\temp\trickyhead.vhdl"
C:\msys64\home\Patrick Lehmann\temp\trickyhead.vhdl:19:13:warning: declaration of "pkg" hides instantiation package "pkg" [-Whide]
package pkg is new work.gen_pkg generic map( 9 );
^
C:\msys64\home\Patrick Lehmann\temp\trickyhead.vhdl:22:22: no declaration for "const" (due to conflicts)
report to_string(CONST);
^
C:\msys64\mingw64\bin\ghdl.exe: compilation errorentity name_clash is
end entity name_clash;
architecture clash of name_clash is
constant CONST2 : bit := '0';
begin
p: process
constant CONST2 : bit := '0';
begin
report to_string(CONST2);
wait;
end process;
end architecture;
Maybe it's worth reporting a problem to the LRM.
The example above doesn't fail, because here, both constants have no conflict. The one in the process hides the other one.
GHDL reports a
The example above doesn't fail, because here, both constants have no conflict. The one in the process hides the other one.
GHDL reports a
-Whide warning, but no error.
So constants made visible via
Use behave differently.
Under 12.4:
"NOTE 1—These rules require that a declaration that is made directly visible by a use clause cannot hide an otherwise
directly visible declaration. Moreover, an explicitly declared operation has priority over an implicitly declared
homograph of that operation if both are made potentially visible by use clauses."
"NOTE 1—These rules require that a declaration that is made directly visible by a use clause cannot hide an otherwise
directly visible declaration. Moreover, an explicitly declared operation has priority over an implicitly declared
homograph of that operation if both are made potentially visible by use clauses."
entity name_clash is
end entity name_clash;
architecture clash of name_clash is
begin
p: process
package pkg is new work.gen_pkg generic map( 9 );
use pkg.all;
begin
# report to_string(CONST);
wait;
end process;
process
begin
report to_string(CONST);
wait;
end process;
end architecture;But luckily it doesn't!
but you have no visible package to get
CONSTin the 2nd process?
I did an inverse proof. When the LRM says both Use Clauses can not hide each other, they must be in the same scope.
This means, the Use Clause is applied to the parent layer (here architecture). If it's applied to the Process, it would be a new scope and thus can not collide.
So if it's in the architecture layer, it should be visible in the 2nd process, right?
But it's not.
So someone wrote a text into the LRM that things collide, but technically they don't.
As you can see with normal constants above, the tools solves the problem for
As you can see with normal constants above, the tools solves the problem for
CONST2
But its that NOTE thats wrong
I just raise an issue on Issues, but might have missunderstood
Heres another Question - does the LRM require that code compiled to different LRM standards work together (barring explicit non-backwards compatible elements - '87 files, '93 shared variables etc). For example, should a package compiled in 2002 or 2008 be fully compatible with a file compiled in 2019? Or is that a tool question? Is it a case that the only guaranteee is that if all files are compiled to the same LRM standard?
I have the same question. There is at least one place where 87 is not compatible with 93:
- In 87,
characteris defined over USASCII, socharacter'pos(character'right)is 127. - In 93:
characteris defined over ISO8859-1 socharacter'pos(character'right)is 255.
If we separately compile two architectures, one in 87 and one in 93 and elaborate them into a single design, what is expected?
@d3jones Reading a file of char is a hack that vendors allow to work. IIRC, Xilinx simulator used to put some arbitrary header on any file that wasnt a text file. Im not sure theres any guarantees that writing a file of arbitrary type in one tool can be read in another tool.
From IEEE perspective there is only one Standard and that's the currently active standard.
In GHDL, you can't mix different versions.
Aldec, Siemens and Xilinx support mixing language versions.
Some even allow forbidden syntax and features in newer language revisions ...)
In GHDL, you can't mix different versions.
Aldec, Siemens and Xilinx support mixing language versions.
Some even allow forbidden syntax and features in newer language revisions ...)
1 reply
@d3jones I would say for all things that are manipulating characters, there is no reason not to be using VHDL-2008. WRT VHDL-87 to VHDL-93, shouldn't they read the same if the characters represent a position number less than 128? If they require reading of a character > 128, VHDL-87 would neither be able to write it nor read it, so a later version is their only option.
@d3jones The 1076 WG would welcome your proposal for reading and writing binary files the correct way. We use gitlab issues for proposals. See: https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues
@d3jones There was a standard 1076.6-1999 and 1076.6-2004 for RTL coding styles. 1999 was written for IP developers. If you are compliant to the standard, then your model will synthesize on all tools ( Since the standard was written to be what tools currently supported). I think VHDL-93 is one of those expectations for Synthesis. So I would say that any design/verification IP that is not at least VHDL-93 is not worth using.
I think the big backward compatibility issue with VHDL-87 to 93 is textio - not just character but also how file identifiers were created.
@d3jones Have you seen any vendors distributing IP that is only supported by VHDL-87?
@trickyhead_gitlab Yes and no. No because 1999 documented the current state of what synthesis tools did support. Hence, if a model were compliant, then it would work. OTOH, 2004 is irrelevant as it tried to push vendors in a direction and they did not do it. Sad state synthesis tools are in as a result - attributes that are annoyingly similar, yet different - making you think you are correct when you are not.
Doesnt it also require a vendor to sign up to compliance to those standards?
For VHDL, there is no compliance enforced as for e.g. USB. So vendors can call their tools to support VHDL with whatever they implement. If we had a compliance rule, all tools would now support VHDL-2019 !