VHDL-200x update?

I have not seen any more activity recently on this. Nothing after DAC
approval?

I tried to register here:
http://www.accellera.org/activities/vhdl/
as a non-member a while ago, but no response! I will try to re-
register again.

An update would be appreciated from the people involved.
-- Amal

Amal,
More recent information is in the public Accellera web docuemnts:
http://www.accellera.org/apps/group_...wg_abbrev=vhdl

As an Accellera approved document, vendors are working on supporting
it now. To further motivate them, please request that they support
the features (they are user/market driven).

WRT becoming an IEEE standard, we are waiting on it being implemented
and used some before we push it into IEEE standardization. This way
allowing updates to happen before it is cast in stone as an IEEE
standard. On the IEEE side, the ballot group has been formed and we
will be ready to go into ballot shortly after we receive an approved
document from the Accellera TSC.

WRT the next stuff. Work is continuing on the next set of
revisions - adding verification features, classes, randomization
(ala SystemVerilog), functional coverage, ... Some of this is in
the DATE presentation.

WRT joining working groups. Accounts other than your company email
address require additional scrutiny. We would not want a SPAMMER
signing up in a working group. As a result, if you use a non-corporate
address, you can expedite the process by identifying the company you
are with and/or somehow demonstrate that you are an engineer,
that you have a vested interest in VHDL, and your nationality
(my appologies, but big brother does not people who are waring
with us to play in the sandbox).

Cheers,
Jim Lewis

SynthWork VHDL Training,
IEEE VASG Chair,
Accellera VHDL TSC participant
VHDL Evangelist


> I have not seen any more activity recently on this. Nothing after DAC
> approval?
>
> I tried to register here:
> http://www.accellera.org/activities/vhdl/
> as a non-member a while ago, but no response! I will try to re-
> register again.
>
> An update would be appreciated from the people involved.
> -- Amal
>

On Aug 22, 5:36 pm, Jim Lewis <j...@synthworks.com> wrote:
> Amal,
> More recent information is in the public Accellera web docuemnts:http://www.accellera.org/apps/group_...wg_abbrev=vhdl
>
> As an Accellera approved document, vendors are working on supporting
> it now. To further motivate them, please request that they support
> the features (they are user/market driven).
>
> WRT becoming an IEEE standard, we are waiting on it being implemented
> and used some before we push it into IEEE standardization. This way
> allowing updates to happen before it is cast in stone as an IEEE
> standard. On the IEEE side, the ballot group has been formed and we
> will be ready to go into ballot shortly after we receive an approved
> document from the Accellera TSC.
>
> WRT the next stuff. Work is continuing on the next set of
> revisions - adding verification features, classes, randomization
> (ala SystemVerilog), functional coverage, ... Some of this is in
> the DATE presentation.
>
> WRT joining working groups. Accounts other than your company email
> address require additional scrutiny. We would not want a SPAMMER
> signing up in a working group. As a result, if you use a non-corporate
> address, you can expedite the process by identifying the company you
> are with and/or somehow demonstrate that you are an engineer,
> that you have a vested interest in VHDL, and your nationality
> (my appologies, but big brother does not people who are waring
> with us to play in the sandbox).
>
> Cheers,
> Jim Lewis
>
> SynthWork VHDL Training,
> IEEE VASG Chair,
> Accellera VHDL TSC participant
> VHDL Evangelist
>
> > I have not seen any more activity recently on this. Nothing after DAC
> > approval?
>
> > I tried to register here:
> > http://www.accellera.org/activities/vhdl/
> > as a non-member a while ago, but no response! I will try to re-
> > register again.
>
> > An update would be appreciated from the people involved.
> > -- Amal

While the new additions are in the pipe, I came up with questions if I
can do the following with the new language. If not, it would be great
If I could.

1. Is it possible to include compiler/simulator/synthesis pragmas or a
method to know what environment the code is being used (simulation/
synthesis, compiler vendor information, ...)
2. Is there any preprocessor being suggested? The generate statement
can not be used everywhere. Say one wants to include a library and
package depending on what simulator/compiler vendor the code is being
used.
3. This is from my past question, regarding allowing file input for
synthesis to be used for ROMs.
4. Nothing else at this time, but what is the process for sending
suggestions to Accellera other than becoming a member?

-- Amal

On Aug 23, 9:50 am, Amal <akhailt...@gmail.com> wrote:

> While the new additions are in the pipe, I came up with questions if I
> can do the following with the new language. If not, it would be great
> If I could.
>
> 1. Is it possible to include compiler/simulator/synthesis pragmas or a
> method to know what environment the code is being used (simulation/
> synthesis, compiler vendor information, ...)

Most tools allow you to override the top-level generic default
assignments via a compilation option. You could set a generic one way
for synthesis, another for simulation. OTOH, since simulation almost
always involves a test bench that instantiates the synthesizable top
level module, those generics can be assigned in the instantiation for
simulation, and defaulted for synthesis.

> 2. Is there any preprocessor being suggested? The generate statement
> can not be used everywhere. Say one wants to include a library and
> package depending on what simulator/compiler vendor the code is being
> used.

Ugh... Please, no preprocessors! Since separate tools are used for
synthesis and simulation, different files for each tool could be
easily compiled under the same package names, allowing the source code
to remain unchanged. Otherwise, within generate statements, I think
you can now have a context clause with specific library/use
statements.

> 3. This is from my past question, regarding allowing file input for
> synthesis to be used for ROMs.

This is not so much a standards issue as it is a synthesis tool vendor
issue. Request it from your synthesis vendor. If enough people want
it, they will do it.

Andy

On 22 Aug., 18:39, Amal <akhailt...@gmail.com> wrote:
> I have not seen any more activity recently on this. Nothing after DAC
> approval?
>
> I tried to register here:
> http://www.accellera.org/activities/vhdl/
> as a non-member a while ago, but no response!

Same here...

Greetings, Torsten

On Aug 22, 5:36 pm, Jim Lewis <j...@synthworks.com> wrote:
> WRT the next stuff. Work is continuing on the next set of
> revisions - adding verification features, classes, randomization
> (ala SystemVerilog), functional coverage, ... Some of this is in
> the DATE presentation.
>
> Cheers,
> Jim Lewis
>
> SynthWork VHDL Training,
> IEEE VASG Chair,
> Accellera VHDL TSC participant
> VHDL Evangelist
>
Any chance of changing the rule that requires an entire vector to be
assigned in a port map instead of being able to leave some of them
open? Something like the following....

U1 : Some_Device port map(
Some_Bus(15 downto 0) => Some_Signal,
Some_Bus(31 downto 16) => open);

Where I run into this as an issue is generally when I use a VHDL
netlist produced by a CAD program as part of a simulation model. If
the spec for the physical part indicates that unused pins can (or
sometimes 'should be') left open and the PCBA design is not using the
entire bus than those unused pins on the physical part will be left
with no connection (which is correct per design) but the resulting
VHDL model complains when compiled because the 'Some_Bus' pins must
either all be assigned or all left open.

In certain situations, there are some simple work arounds (mentioned
below) but if the language handled the above mentioned port map (which
reflects the reality of the desired PCBA design) things would be much
cleaner. The model would also not have the situation dependent
drawbacks associated with each of the work arounds.

- Work around #1: If the PCBA design itself is stable and not
changing, then simply edit the VHDL model for the offending schematic
pages and move on.

- Work around #2: If the PCBA design is still evolving then see if
it's possible to get a resistor on to the schematic to drive the
'unused' pins.

KJ

On Aug 22, 2:36 pm, Jim Lewis <j...@synthworks.com> wrote:
> Amal,
> More recent information is in the public Accellera web docuemnts:http://www.accellera.org/apps/group_...wg_abbrev=vhdl
>
> As an Accellera approved document, vendors are working on supporting
> it now. To further motivate them, please request that they support
> the features (they are user/market driven).
>
> WRT becoming an IEEE standard, we are waiting on it being implemented
> and used some before we push it into IEEE standardization. This way
> allowing updates to happen before it is cast in stone as an IEEE
> standard. On the IEEE side, the ballot group has been formed and we
> will be ready to go into ballot shortly after we receive an approved
> document from the Accellera TSC.
>
> WRT the next stuff. Work is continuing on the next set of
> revisions - adding verification features, classes, randomization
> (ala SystemVerilog), functional coverage, ... Some of this is in
> the DATE presentation.
>
> WRT joining working groups. Accounts other than your company email
> address require additional scrutiny. We would not want a SPAMMER
> signing up in a working group. As a result, if you use a non-corporate
> address, you can expedite the process by identifying the company you
> are with and/or somehow demonstrate that you are an engineer,
> that you have a vested interest in VHDL, and your nationality
> (my appologies, but big brother does not people who are waring
> with us to play in the sandbox).


Jim,

Given VHDL's IEEE roots and the Accellera/IEEE collaboration being
sanctioned by the IEEE, it would be good to understand more about what
the IEEE and the US Department of Treasury's Office of Foreign Assets
Control (OFAC) permits.

Your statement on exclusions based on countries the United States is
"waring with" is overly simplified and inaccurate. The United States
has sanctions on interactions with certain countries, but these
sanctions are not necessarily based on a state of war. Further, the
IEEE has a license from OFAC for the development of standards and
joint works. People and entities in sanctioned countries may
participate in standards development.

In a letter to the IEEE, I call your attention to the following
section that highlights the IEEE's ability to collaborate on
standards.

-----------------------------------------------------------------------
New General License Applicable to Standards Development and Joint
Works
-----------------------------------------------------------------------
With respect to your request for guidance on matters relating to
standards development and collaboration on joint works, please be
advised that the activities that you describe in your letter
appear
to fall within the scope of those activities authorized under the
General Licenses issues by OFAC on December 17, 2004. Please
contact us with any questions that you may with respect to how
the General Licenses might apply to IEEE's activities.
-----------------------------------------------------------------------
http://www.ieee.org/portal/cms_docs/...EEE_050905.pdf
-----------------------------------------------------------------------

The IEEE has online information that you can review to understand this
in more detail as well. The summary this information

-----------------------------------------------------------------------
IEEE & OFAC - Information Update
Summary:
-----------------------------------------------------------------------
In January 2002, IEEE informed members residing in Cuba, Iran,
Libya
and Sudan -- countries sanctioned by OFAC -- that, because of OFAC
regulations, those members would not be able to take advantage of
member benefits and services except for print subscriptions to
IEEE
publications. Certain aspects of publishing manuscripts submitted
to IEEE publications also were affected by these regulations.
After
many months of discussions and providing information to OFAC,
on 30 Sept. 2003, OFAC informed IEEE that most of the publishing
activities are entirely "exempt" from the Iranian embargo rules
but that IEEE could need a license for editing. On 6 Oct. 2003,
IEEE appealed to OFAC to concur with our reasons for an exemption
or to grant a license to enable IEEE to resume the normal
publication
process, including copy and style editing. IEEE's efforts were
rewarded on 2 April 2004, when we received the decision that the
entire scholarly publishing process was exempt from restrictions.
IEEE gained additional ground in its ongoing mission to resolve
embargo-related membership issues when OFAC agreed in May 2005
that IEEE could recognize its section in Iran -- which was formed
in 1970 before embargoes were enacted -- as an official geographic
unit of the IEEE, as long as IEEE did not provide funds or
services.
-----------------------------------------------------------------------
http://www.ieee.org/portal/pages/about/ofac.html
-----------------------------------------------------------------------

Since OFAC's license it general in that it does not apply to the IEEE
only, ALL scientific, technical and medical publishers, such as
Accellera, are covered.

-Dennis

>
> Cheers,JimLewis
>
> SynthWork VHDL Training,
> IEEE VASG Chair,
> Accellera VHDL TSC participant
> VHDL Evangelist
>
> > I have not seen any more activity recently on this. Nothing after DAC
> > approval?
>
> > I tried to register here:
> > http://www.accellera.org/activities/vhdl/
> > as a non-member a while ago, but no response! I will try to re-
> > register again.
>
> > An update would be appreciated from the people involved.
> >
-- Amal

KJ
Have you submitted it? If not, you should.

Jim

> On Aug 22, 5:36 pm, Jim Lewis <j...@synthworks.com> wrote:
>> WRT the next stuff. Work is continuing on the next set of
>> revisions - adding verification features, classes, randomization
>> (ala SystemVerilog), functional coverage, ... Some of this is in
>> the DATE presentation.
>>
>> Cheers,
>> Jim Lewis
>>
>> SynthWork VHDL Training,
>> IEEE VASG Chair,
>> Accellera VHDL TSC participant
>> VHDL Evangelist
>>
> Any chance of changing the rule that requires an entire vector to be
> assigned in a port map instead of being able to leave some of them
> open? Something like the following....
>
> U1 : Some_Device port map(
> Some_Bus(15 downto 0) => Some_Signal,
> Some_Bus(31 downto 16) => open);
>
> Where I run into this as an issue is generally when I use a VHDL
> netlist produced by a CAD program as part of a simulation model. If
> the spec for the physical part indicates that unused pins can (or
> sometimes 'should be') left open and the PCBA design is not using the
> entire bus than those unused pins on the physical part will be left
> with no connection (which is correct per design) but the resulting
> VHDL model complains when compiled because the 'Some_Bus' pins must
> either all be assigned or all left open.
>
> In certain situations, there are some simple work arounds (mentioned
> below) but if the language handled the above mentioned port map (which
> reflects the reality of the desired PCBA design) things would be much
> cleaner. The model would also not have the situation dependent
> drawbacks associated with each of the work arounds.
>
> - Work around #1: If the PCBA design itself is stable and not
> changing, then simply edit the VHDL model for the offending schematic
> pages and move on.
>
> - Work around #2: If the PCBA design is still evolving then see if
> it's possible to get a resistor on to the schematic to drive the
> 'unused' pins.
>
> KJ
>

On Aug 26, 6:37 pm, Jim Lewis <j...@synthworks.com> wrote:
> KJ
> Have you submitted it? If not, you should.
>
> Jim
>
>
>
> > On Aug 22, 5:36 pm, Jim Lewis <j...@synthworks.com> wrote:
> >> WRT the next stuff. Work is continuing on the next set of
> >> revisions - adding verification features, classes, randomization
> >> (ala SystemVerilog), functional coverage, ... Some of this is in
> >> the DATE presentation.
>
> >> Cheers,
> >> Jim Lewis
>
> >> SynthWork VHDL Training,
> >> IEEE VASG Chair,
> >> Accellera VHDL TSC participant
> >> VHDL Evangelist
>
> > Any chance of changing the rule that requires an entire vector to be
> > assigned in a port map instead of being able to leave some of them
> > open? Something like the following....
>
> > U1 : Some_Device port map(
> > Some_Bus(15 downto 0) => Some_Signal,
> > Some_Bus(31 downto 16) => open);
>
> > Where I run into this as an issue is generally when I use a VHDL
> > netlist produced by a CAD program as part of a simulation model. If
> > the spec for the physical part indicates that unused pins can (or
> > sometimes 'should be') left open and the PCBA design is not using the
> > entire bus than those unused pins on the physical part will be left
> > with no connection (which is correct per design) but the resulting
> > VHDL model complains when compiled because the 'Some_Bus' pins must
> > either all be assigned or all left open.
>
> > In certain situations, there are some simple work arounds (mentioned
> > below) but if the language handled the above mentioned port map (which
> > reflects the reality of the desired PCBA design) things would be much
> > cleaner. The model would also not have the situation dependent
> > drawbacks associated with each of the work arounds.
>
> > - Work around #1: If the PCBA design itself is stable and not
> > changing, then simply edit the VHDL model for the offending schematic
> > pages and move on.
>
> > - Work around #2: If the PCBA design is still evolving then see if
> > it's possible to get a resistor on to the schematic to drive the
> > 'unused' pins.
>
> > KJ- Hide quoted text -
>
> - Show quoted text -

Jim,

No I haven't submitted it but for the life of me I can't figure out
how to do so either. I poked around again at Accellera.org and
couldn't really find how an outsider can submit any suggestions. If
you could provide the instructions to do so I'll submit it...but you
might also consider having the webbies at Accellera add some links on
how to do so, I couldn't find it.

I'm assuming that members have access to such links but it looks like
membership commences with receipt of $$ unless you work for a member
company. I don't work at such a company (per the Accellera posted
list) and have other things to do with my $$.

Thanks.

Kevin Jennings

In news: ups.com
timestamped Fri, 31 Aug 2007 05:51:31 -0700,
KJ <> posted:
|--------------------------------------------------------------------------|
|"[..] |
| |
|I'm assuming that members have access to such links but it looks like |
|membership commences with receipt of $$ unless you work for a member |
|company. I don't work at such a company (per the Accellera posted |
|list) and have other things to do with my $$. |
| |
|Thanks. |
| |
|Kevin Jennings" |
|--------------------------------------------------------------------------|

It is possible to join for gratis, as I have done, without using a
member company.

Access
WWW.Accellera.org/contact_us/contact_us
Request to join Accellera VHDL TSC and VHDL-Extensions.


You may also request to join other items listed on
WWW.Accellera.org/activities/vhdl


Send the form to Lynn Horobin, Administration & Marketing.

Regards,
Colin Paul Gloster