Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 03 02:13

    umarcor on keep-compiling

    ci: use the built-in '--keep-co… (compare)

  • Feb 03 02:12

    umarcor on cosim

    cosim/dpi-ffi: add 'vhdpi_ghdl.… cosim/dpi-ffi: add VHDPI_Test (compare)

  • Feb 03 01:56

    umarcor on cosim

    WIP setenv (compare)

  • Feb 03 01:55

    umarcor on main

    cosim/dpi-ffi/ghdl-vffi/test: a… (compare)

  • Feb 03 01:54

    umarcor on cosim

    (compare)

  • Feb 03 01:52

    umarcor on main

    WIP envvars (compare)

  • Feb 03 01:50

    umarcor on cosim

    WIP envvars (compare)

  • Feb 02 23:13

    umarcor on master

    (compare)

  • Feb 02 23:13

    umarcor on main

    (compare)

  • Feb 02 23:13

    umarcor on cosim

    (compare)

  • Feb 02 23:10

    umarcor on master

    cosim/dpi-ffi: create subdir 'g… cosim/dpi-ffi: fix compilation … cosim/dpi-ffi/ghd-vffi: use VUn… and 2 more (compare)

  • Feb 02 22:58

    umarcor on cosim

    ci: add workflow CoSim cosim/dpi-ffi: add README (compare)

  • Feb 02 22:45

    umarcor on cosim

    ci: add workflow CoSim cosim/dpi-ffi: add README (compare)

  • Feb 02 22:43

    umarcor on cosim

    cosim/dpi-ffi: create subdir 'g… cosim/dpi-ffi: fix compilation … cosim/dpi-ffi/ghd-vffi: use VUn… and 2 more (compare)

  • Oct 05 2021 13:29

    umarcor on top-subtype

    (compare)

  • Oct 05 2021 13:28

    umarcor on master

    2008: ad tb_top_generic_subtype cosim: add ref to aguinet/drago… (compare)

  • Sep 24 2021 20:07

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 2021 19:59

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 2021 19:54

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 23 2021 01:45

    umarcor on style

    (compare)

Jim Lewis
@JimLewis
Since the call_path parameter is an access type, I think the parameter needs to be a variable. Going further if it has to be a variable, I think we want to delete this function. See IEEE-P1076/VHDL-Issues#229 for my write up on the issue.
Can someone double check please.
Richard Head
@trickyhead_gitlab
@JimLewis I was doing something very similar today. Access types need to be variables, hence call_path needs to be a variable. Whats the problem with it being mode "in" ? ActiveHDL will allow compilation of a function with variable access type of mode in. It should make sense as you're not allowed to write/modify parameters of mode in.
Jim Lewis
@JimLewis
@trickyhead_gitlab Since I have not found anything to the contrary in either 2019 or 2008, I cannot disagree. I was last looking to see if variable is allowed to be mode in as this only makes sense for access types. Other than in, if an object is mode in, then one could use mode constant.
Richard Head
@trickyhead_gitlab
@JimLewis in 2008 functions cannot have variable parameters. So this is purely a 2019 issue.
Jim Lewis
@JimLewis
@trickyhead_gitlab Yes, but it uses the same rules as procedures.
Patrick Lehmann
@Paebbels
Is Coday now happier?
Jim Lewis
@JimLewis
For my VHDL-2019: Just the New Stuff presentations, I created a VHDL-2019 code archive at:
https://gitlab.com/synthworks/VHDL_2019
Kaleb Barrett
@ktbarrett
@JimLewis Were those presentations recorded anywhere? YT videos perhaps?
Jim Lewis
@JimLewis
See Aldec.com and go to events / recorded
Richard Head
@trickyhead_gitlab

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 )

Patrick Lehmann
@Paebbels
In the process you can use pkg.CONST. pkg is refering to the package instantiation in the process as it shadows the pkg from architecture.
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.
Richard Head
@trickyhead_gitlab
yes. Im not complaining about the fact its ambigious (its understandable). Just I wondered if it was possible to directly reference the one in the architecture
Patrick Lehmann
@Paebbels
I think it shouldn't be ambiguous at all. What tool is complaining here?
Richard Head
@trickyhead_gitlab
Aldec
Patrick Lehmann
@Paebbels
Can you test with GHDL too?
Either there is a bug in the LRM or in Aldec
Richard Head
@trickyhead_gitlab
I dont have GHDL installed (or experience with)
Patrick Lehmann
@Paebbels
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 error
entity 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 -Whide warning, but no error.
So constants made visible via Use behave differently.
Patrick Lehmann
@Paebbels
It feels like Use loads the references into the parent scope.
Richard Head
@trickyhead_gitlab
Feeling is maybe LRM ambiguity. Looking through LRM 2019 on use clauses, there is no overloading of use clauses. In fact, it pretty much specifies the behaviour I have.
Patrick Lehmann
@Paebbels
It's not an overloading of use, it's into what scope it puts the symbols.
Richard Head
@trickyhead_gitlab
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."
Patrick Lehmann
@Paebbels
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;
If the LRM states the above written text, then this code should work.
But luckily it doesn't!
Richard Head
@trickyhead_gitlab
but you have no visible package to get CONST in the 2nd process?
Patrick Lehmann
@Paebbels
Conclusion:
  • Aldec and GHDL are correct with respect to the LRM
  • The LRM has a bug as it not behaving as languages should work.

but you have no visible package to get CONST in 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 CONST2
Richard Head
@trickyhead_gitlab
So actally, are both GHDL and Aldec doing the same?
Patrick Lehmann
@Paebbels
yes
Richard Head
@trickyhead_gitlab
Ok
But its that NOTE thats wrong
I just raise an issue on Issues, but might have missunderstood
Patrick Lehmann
@Paebbels
from a technically side, I see no reason why this is there. Moreover, the note it not normative it must be somewhere in the text too.
Richard Head
@trickyhead_gitlab
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?
d3jones
@d3jones
I have the same question. There is at least one place where 87 is not compatible with 93:
  • In 87, character is defined over USASCII, so character'pos(character'right) is 127.
  • In 93: character is defined over ISO8859-1 so character'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
@d3jones
(It also means that 87 users cannot read raw binary files by treating them as file of character.)
Richard Head
@trickyhead_gitlab
@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.
d3jones
@d3jones
True, it 's a hack. It is unfortunate that neither Verilog nor VHDL provides a way to read binary files.
Patrick Lehmann
@Paebbels
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 ...)
1 reply
Richard Head
@trickyhead_gitlab
So any failure or erroneous error is a tool problem and not something that needs to be questioned of the LRM
Patrick Lehmann
@Paebbels
The LRM doesn't consider compatibility issues between versions.
Jim Lewis
@JimLewis
@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
@d3jones
Commercial users often have design/verification IP from multiple vendors. If the IP is encrypted then customer cannot modify it. I may not actually have a choice as to which language version(s) I need to use.
Jim Lewis
@JimLewis
@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.