VHDL Standards Progress Report

Discussion in 'VHDL' started by Jim Lewis, Sep 14, 2006.

  1. Jim Lewis

    Jim Lewis Guest

    IEEE VHDL Analysis and Standardization Group (VASG) is the
    IEEE working group responsible for maintaining and extending
    the VHDL standard (IEEE 1076). Currently VASG is collaborating
    with the Accellera VHDL Technical Subcommittee (VHDL TSC) to
    accomplish this task.

    I have just updated the VASG webpage updates regarding
    status of VHDL standards revisions (both within Accellera
    and IEEE). For details see: http://www.eda-stds.org/vasg
    The older page, http://www.eda-stds.org/vhdl-200x/
    has been merged with the vasg page.
    Note also that any of the following domains are aliases to
    the same information: eda.org, eda-stds.org, vhdl.org


    I will also summarize (or restate) the status below:


    _VHDL + VHPI_
    On June 28, 2006 Accellera board approved a revision of
    1076 that includes VHDL + VHPI (VHDL Procedural Language
    Application Interface) + minor LRM maintence. Currently
    this draft is working its way through IEEE standardization.


    _VHDL + VHPI + VHDL-200X/VHDL-200X-FT + additional enhancements_
    At DAC 2006 the Accellera board approved an enhanced
    revision of 1076 that is VHDL + VHPI + enhancements.
    The IEEE VASG started the work in early 2003 as VHDL-200X.
    The Accellera VHDL Technical Subcommittee took over the
    work in 2005, funded its technical editing, and did
    super-human work to finalize it. In the near future
    an Accellera press release will announce this
    accomplishment.

    As an Accellera standard, this version is available
    for industry adoption - so let your vendors know you
    want it. In fact, the claim is that since Accellera
    standards are user driven, vendors are more willing to
    implement the standard features since they know the
    features are things desired and requested by users.
    This was demonstrated in the implementation of
    SystemVerilog (which started as an Accellera
    standard).

    I will be presenting a paper at Mentor's MARLUG on
    October 12th that details the changes. After that
    date the slides will be available at:
    http://www.synthworks.com/papers/

    Currently there are some older papers on that webpage
    that reflect the intent at the time they were written.


    _Accellera VHDL 2007_
    The Accellera VHDL TSC is continuing its work to
    enhance VHDL. Current items being worked on include
    constrained random, coverage, OO, interfaces, and
    verification data structures (associative arrays,
    memories, ...). When this work is completed, it
    will give VHDL similar verification capability to
    SystemVerilog.


    Join us and help create the next VHDL standards.
    Your support (either financial or participation or both)
    is greatly appreciated. For details see:
    http://www.eda-stds.org/vasg/#Participation


    By the way, if you have not checked the Accellera webpage
    recently, you will notice that VHDL is also listed
    prominently on the home page. See:
    http://www.accellera.org/home


    Best Regards,
    Jim Lewis
    IEEE VASG Chair
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Sep 14, 2006
    #1
    1. Advertising

  2. Jim Lewis

    Hans Guest

    Thanks Jim,

    It is good to see that VHDL is still actively being worked on,

    Regards,
    Hans.
    www.ht-lab.com


    "Jim Lewis" <> wrote in message
    news:...
    > IEEE VHDL Analysis and Standardization Group (VASG) is the
    > IEEE working group responsible for maintaining and extending
    > the VHDL standard (IEEE 1076). Currently VASG is collaborating
    > with the Accellera VHDL Technical Subcommittee (VHDL TSC) to
    > accomplish this task.
    >
    > I have just updated the VASG webpage updates regarding
    > status of VHDL standards revisions (both within Accellera
    > and IEEE). For details see: http://www.eda-stds.org/vasg
    > The older page, http://www.eda-stds.org/vhdl-200x/
    > has been merged with the vasg page.
    > Note also that any of the following domains are aliases to
    > the same information: eda.org, eda-stds.org, vhdl.org
    >
    >
    > I will also summarize (or restate) the status below:
    >
    >
    > _VHDL + VHPI_
    > On June 28, 2006 Accellera board approved a revision of
    > 1076 that includes VHDL + VHPI (VHDL Procedural Language
    > Application Interface) + minor LRM maintence. Currently
    > this draft is working its way through IEEE standardization.
    >
    >
    > _VHDL + VHPI + VHDL-200X/VHDL-200X-FT + additional enhancements_
    > At DAC 2006 the Accellera board approved an enhanced
    > revision of 1076 that is VHDL + VHPI + enhancements.
    > The IEEE VASG started the work in early 2003 as VHDL-200X.
    > The Accellera VHDL Technical Subcommittee took over the
    > work in 2005, funded its technical editing, and did
    > super-human work to finalize it. In the near future
    > an Accellera press release will announce this
    > accomplishment.
    >
    > As an Accellera standard, this version is available
    > for industry adoption - so let your vendors know you
    > want it. In fact, the claim is that since Accellera
    > standards are user driven, vendors are more willing to
    > implement the standard features since they know the
    > features are things desired and requested by users.
    > This was demonstrated in the implementation of
    > SystemVerilog (which started as an Accellera
    > standard).
    >
    > I will be presenting a paper at Mentor's MARLUG on
    > October 12th that details the changes. After that
    > date the slides will be available at:
    > http://www.synthworks.com/papers/
    >
    > Currently there are some older papers on that webpage
    > that reflect the intent at the time they were written.
    >
    >
    > _Accellera VHDL 2007_
    > The Accellera VHDL TSC is continuing its work to
    > enhance VHDL. Current items being worked on include
    > constrained random, coverage, OO, interfaces, and
    > verification data structures (associative arrays,
    > memories, ...). When this work is completed, it
    > will give VHDL similar verification capability to
    > SystemVerilog.
    >
    >
    > Join us and help create the next VHDL standards.
    > Your support (either financial or participation or both)
    > is greatly appreciated. For details see:
    > http://www.eda-stds.org/vasg/#Participation
    >
    >
    > By the way, if you have not checked the Accellera webpage
    > recently, you will notice that VHDL is also listed
    > prominently on the home page. See:
    > http://www.accellera.org/home
    >
    >
    > Best Regards,
    > Jim Lewis
    > IEEE VASG Chair
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Hans, Sep 14, 2006
    #2
    1. Advertising

  3. Jim Lewis wrote:
    > IEEE VHDL Analysis and Standardization Group (VASG) is the
    > IEEE working group responsible for maintaining and extending
    > the VHDL standard (IEEE 1076). Currently VASG is collaborating
    > with the Accellera VHDL Technical Subcommittee (VHDL TSC) to
    > accomplish this task.
    >
    > I have just updated the VASG webpage updates regarding
    > status of VHDL standards revisions (both within Accellera
    > and IEEE). For details see: http://www.eda-stds.org/vasg
    > The older page, http://www.eda-stds.org/vhdl-200x/
    > has been merged with the vasg page.
    > Note also that any of the following domains are aliases to
    > the same information: eda.org, eda-stds.org, vhdl.org
    >
    >
    > I will also summarize (or restate) the status below:
    >
    >
    > _VHDL + VHPI_
    > On June 28, 2006 Accellera board approved a revision of
    > 1076 that includes VHDL + VHPI (VHDL Procedural Language
    > Application Interface) + minor LRM maintence. Currently
    > this draft is working its way through IEEE standardization.
    >
    >
    > _VHDL + VHPI + VHDL-200X/VHDL-200X-FT + additional enhancements_
    > At DAC 2006 the Accellera board approved an enhanced
    > revision of 1076 that is VHDL + VHPI + enhancements.
    > The IEEE VASG started the work in early 2003 as VHDL-200X.
    > The Accellera VHDL Technical Subcommittee took over the
    > work in 2005, funded its technical editing, and did
    > super-human work to finalize it. In the near future
    > an Accellera press release will announce this
    > accomplishment.
    >
    > As an Accellera standard, this version is available
    > for industry adoption - so let your vendors know you
    > want it. In fact, the claim is that since Accellera
    > standards are user driven, vendors are more willing to
    > implement the standard features since they know the
    > features are things desired and requested by users.
    > This was demonstrated in the implementation of
    > SystemVerilog (which started as an Accellera
    > standard).
    >
    > I will be presenting a paper at Mentor's MARLUG on
    > October 12th that details the changes. After that
    > date the slides will be available at:
    > http://www.synthworks.com/papers/
    >
    > Currently there are some older papers on that webpage
    > that reflect the intent at the time they were written.
    >
    >
    > _Accellera VHDL 2007_
    > The Accellera VHDL TSC is continuing its work to
    > enhance VHDL. Current items being worked on include
    > constrained random, coverage, OO, interfaces, and
    > verification data structures (associative arrays,
    > memories, ...). When this work is completed, it
    > will give VHDL similar verification capability to
    > SystemVerilog.
    >
    >
    > Join us and help create the next VHDL standards.
    > Your support (either financial or participation or both)
    > is greatly appreciated. For details see:
    > http://www.eda-stds.org/vasg/#Participation
    >
    >
    > By the way, if you have not checked the Accellera webpage
    > recently, you will notice that VHDL is also listed
    > prominently on the home page. See:
    > http://www.accellera.org/home
    >
    >
    > Best Regards,
    > Jim Lewis
    > IEEE VASG Chair
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    Hi Jim,
    Congraduation! Now you are chairman of the committee.

    How about keyword "elsor" keyword?

    At that time, you recommended me to contact a person who had the power
    to do that while you were not in the committee. I didn't contacted the
    person because I didn't like to do that: it would be beneficial to
    every engineer in VHDL and Verilog circuit.

    And last time we talked through the google about the introduction and
    you nad many new ideas and we agured a lot, finally you asked me to
    post most daunting design that used the technology and I posed the
    design and after that I never heared your answer.

    Thank you.

    Weng
    Weng Tianxiang, Sep 14, 2006
    #3
  4. Jim Lewis

    David Ashley Guest

    Weng Tianxiang wrote:
    > How about keyword "elsor" keyword?


    How would you use it? I'm reminded of perl's "unless"
    keyword :).

    -Dave

    --
    David Ashley http://www.xdr.com/dash
    Embedded linux, device drivers, system architecture
    David Ashley, Sep 14, 2006
    #4
  5. Jim Lewis

    Jim Lewis Guest

    Weng,
    What I remember is that for simple examples, elsor
    works fine, however, for examples of the complexity
    for which you posted it is very difficult if not
    impossible to extract enough information to address your
    issue.

    On the other hand, an alternate consideration is to
    have assertions that express mutual exclusion. For
    example:

    assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
    report "%%%BUG: Mutual exclusion failed in design ..."
    severity error ;


    -- Looking forward and using new syntax introduced by
    -- the Accellera VHDL 2006 revision
    Reg4LeProc : process(Clk)
    begin
    if rising_edge(Clk) then
    if A_LE then
    Reg4Le <= A ;

    elsif B_LE and AddrB ?= 15 then
    Reg4LE <= B ;

    elsif C_LE and AddrC ?= 14 then
    Reg4LE <= C;

    elsif D_LE then
    Reg4Le <= D ;
    end if ;
    end if ;
    end process ;


    The alternate solution simplifies the expression of
    the relationship between A_LE, B_LE, C_LE and D_LE.
    It only requires a standardized function zero_one_hot
    that is visible in the VHDL context. I will have to
    do some searchin, but I think there is already something
    like this in PSL (which was incorporated by reference -
    however - I don't think the function is visible outside
    of a PSL statement - yet).


    So the steps to finializing the alternate solution are to
    standardize a version of zero_one_hot (hopefully one that
    is compatible with PSL) and revise 1076.6 to say vendors
    should support this style of coding.


    > Congratulation! Now you are chairman of the committee.

    Yes, but I am chair of the group doing the administrative
    work of making the revision a standard. The Accellera
    VHDL TSC is doing all of the heavy lifting the next
    revision (and perhaps more). In the Accellera group,
    I am just an active member.


    Cheers,
    Jim


    >
    > Hi Jim,
    > Congraduation! Now you are chairman of the committee.
    >
    > How about keyword "elsor" keyword?
    >
    > At that time, you recommended me to contact a person who had the power
    > to do that while you were not in the committee. I didn't contacted the
    > person because I didn't like to do that: it would be beneficial to
    > every engineer in VHDL and Verilog circuit.
    >
    > And last time we talked through the google about the introduction and
    > you nad many new ideas and we agured a lot, finally you asked me to
    > post most daunting design that used the technology and I posed the
    > design and after that I never heared your answer.
    >
    > Thank you.
    >
    > Weng
    >



    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Sep 14, 2006
    #5
  6. Jim Lewis

    Amal Guest

    Jim Lewis wrote:
    > As an Accellera standard, this version is available
    > for industry adoption - so let your vendors know you
    > want it.


    I am already anxious for vendors to start implementing it. I just feel
    that there has been a lot of support on the SystemVerilog side and
    pushing it faster than VHDL.

    Jim Lewis wrote:
    > _Accellera VHDL 2007_
    > The Accellera VHDL TSC is continuing its work to
    > enhance VHDL. Current items being worked on include
    > constrained random, coverage, OO, interfaces, and
    > verification data structures (associative arrays,
    > memories, ...). When this work is completed, it
    > will give VHDL similar verification capability to
    > SystemVerilog.
    >


    SystemVerilog brought most features already available to VHDL to
    Verilog users and a lot more with support of vendors and the industry.
    As a VHDL user, I just feel left behind and overwhelmed with the amount
    of support for SystemVerilog and I feel that the activities on the VHDL
    front have been very slow compared to SystemVerilog.

    Although I thank everyone involved for completing the standard and I
    hope that vendor support is coming sooner than later.
    -- Amal
    Amal, Sep 15, 2006
    #6
  7. Jim Lewis

    Jim Lewis Guest

    Amal,
    >>As an Accellera standard, this version is available
    >>for industry adoption - so let your vendors know you
    >>want it.

    >
    >
    > I am already anxious for vendors to start implementing it. I just feel
    > that there has been a lot of support on the SystemVerilog side and
    > pushing it faster than VHDL.


    For a vendor, implementing anything is a business investment.
    The more interest they get from their users, the more quickly
    they will implement it.

    The claim for rapid implementation of SystemVerilog is that
    it was a user driven standard. This VHDL effort followed the
    same process, so it should enjoy the same rapid implementation.


    >>_Accellera VHDL 2007_
    >>The Accellera VHDL TSC is continuing its work to
    >>enhance VHDL. Current items being worked on include
    >>constrained random, coverage, OO, interfaces, and
    >>verification data structures (associative arrays,
    >>memories, ...). When this work is completed, it
    >>will give VHDL similar verification capability to
    >>SystemVerilog.
    >>

    >
    >
    > SystemVerilog brought most features already available to VHDL to
    > Verilog users and a lot more with support of vendors and the industry.
    > As a VHDL user, I just feel left behind and overwhelmed with the amount
    > of support for SystemVerilog and I feel that the activities on the VHDL
    > front have been very slow compared to SystemVerilog.


    Some of that is marketing propaganda. Some vendors just recently
    implemented the OO features of SystemVerilog. The challenge for
    the Accellera VHDL TSC will be to have the OO, constrained random,
    interfaces, ... features for DAC 07.

    > Although I thank everyone involved for completing the standard and I
    > hope that vendor support is coming sooner than later.

    Me too. Given that it is Accellera uses user driven process,
    there is no reason why vendors would not already be working on it.
    However, compell them further by letting them know your interest
    in the standard.

    Going further, it would also be helpful to get additional
    organizations to join Accellera and help fund the effort.
    See http://www.accellera.org/activities/vhdl/

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Sep 15, 2006
    #7
  8. Jim Lewis

    Amal Guest

    Jim Lewis wrote:
    >
    > The challenge for the Accellera VHDL TSC will be to
    > have the OO, constrained random, interfaces, ...
    > features for DAC 07.
    >


    Do you have any insight or documents for public view on these subjects,
    especially OO?

    Jim Lewis wrote:
    > Going further, it would also be helpful to get additional
    > organizations to join Accellera and help fund the effort.
    > See http://www.accellera.org/activities/vhdl/
    >


    How can individual VHDL users help?

    -- Amal
    Amal, Sep 15, 2006
    #8
  9. Jim Lewis

    Jim Lewis Guest

    Amal


    >>The challenge for the Accellera VHDL TSC will be to
    >>have the OO, constrained random, interfaces, ...
    >>features for DAC 07.
    >>

    >
    >
    > Do you have any insight or documents for public view on these subjects,
    > especially OO?

    Too soon yet.


    >>Going further, it would also be helpful to get additional
    >>organizations to join Accellera and help fund the effort.
    >>See http://www.accellera.org/activities/vhdl/
    >>

    >
    >
    > How can individual VHDL users help?

    Join Accellera - even as a non-member. Participate
    in the VHDL subgroups - particularly the requirements
    group. This helps determine what is important to users.

    The other groups require more experience, but if you have
    it and you can contribute to writing details of enhancements or
    LRM modifications. Generally things go best when someone
    with a vested interest in a proposal works on it.

    Best Regards,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Sep 16, 2006
    #9
  10. Jim Lewis

    Hans Guest

    "Amal" <> wrote in message
    news:...
    > Jim Lewis wrote:
    >> As an Accellera standard, this version is available
    >> for industry adoption - so let your vendors know you
    >> want it.

    >
    > I am already anxious for vendors to start implementing it. I just feel
    > that there has been a lot of support on the SystemVerilog side and
    > pushing it faster than VHDL.


    That is not because of the language itself but simply because
    SystemVerilog/SystemC support essential verification methodologies like
    Transaction Level Modelling, Constraint Random Verification and Functional
    Coverage. There is absolutely no reason to abandon VHDL since it is still a
    very capable RTL language. However, if you have to develop an all singing
    all dancing testbench or you want to do some behaviour modelling of your
    system you definitely don't want to use VHDL/Verilog but instead use a
    language that support the above techniques.

    It is also true that most EDA tools (at least Modelsim) can mix these
    languages at any level of the hierarchy seamlessly without you having to
    worry about any interface issues. Thus you can use VHDL for your DUT and say
    SystemC for your testbench and SVA for your assertions.

    It is questionable if the EDA industry needs an OO-VHDL given that
    SystemC/SystemVerilog can be used so effectively with VHDL and have already
    such a headstart. However, what is very cool of the VHDL-2006 standard is
    the inclusion of PSL. This is IMHO the best addition to the language and can
    make a serious impact on the quality of your verification (assuming you use
    it properly :), the only stumble block which is seriously hampering the
    uptake of this language is the high price EDA vendors are charging for it.

    Hans
    www.ht-lab.com


    >
    > Jim Lewis wrote:
    >> _Accellera VHDL 2007_
    >> The Accellera VHDL TSC is continuing its work to
    >> enhance VHDL. Current items being worked on include
    >> constrained random, coverage, OO, interfaces, and
    >> verification data structures (associative arrays,
    >> memories, ...). When this work is completed, it
    >> will give VHDL similar verification capability to
    >> SystemVerilog.
    >>

    >
    > SystemVerilog brought most features already available to VHDL to
    > Verilog users and a lot more with support of vendors and the industry.
    > As a VHDL user, I just feel left behind and overwhelmed with the amount
    > of support for SystemVerilog and I feel that the activities on the VHDL
    > front have been very slow compared to SystemVerilog.
    >
    > Although I thank everyone involved for completing the standard and I
    > hope that vendor support is coming sooner than later.
    > -- Amal
    >
    Hans, Sep 17, 2006
    #10
  11. David Ashley wrote:
    > Weng Tianxiang wrote:
    > > How about keyword "elsor" keyword?

    >
    > How would you use it? I'm reminded of perl's "unless"
    > keyword :).
    >
    > -Dave
    >
    > --
    > David Ashley http://www.xdr.com/dash
    > Embedded linux, device drivers, system architecture


    Hi David,
    Please leave your email address, I would like to send the paper to you
    through an email.

    Weng
    Weng Tianxiang, Sep 18, 2006
    #11
  12. Jim Lewis wrote:
    > Weng,
    > What I remember is that for simple examples, elsor
    > works fine, however, for examples of the complexity
    > for which you posted it is very difficult if not
    > impossible to extract enough information to address your
    > issue.
    >
    > On the other hand, an alternate consideration is to
    > have assertions that express mutual exclusion. For
    > example:
    >
    > assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
    > report "%%%BUG: Mutual exclusion failed in design ..."
    > severity error ;
    >
    >
    > -- Looking forward and using new syntax introduced by
    > -- the Accellera VHDL 2006 revision
    > Reg4LeProc : process(Clk)
    > begin
    > if rising_edge(Clk) then
    > if A_LE then
    > Reg4Le <= A ;
    >
    > elsif B_LE and AddrB ?= 15 then
    > Reg4LE <= B ;
    >
    > elsif C_LE and AddrC ?= 14 then
    > Reg4LE <= C;
    >
    > elsif D_LE then
    > Reg4Le <= D ;
    > end if ;
    > end if ;
    > end process ;
    >
    >
    > The alternate solution simplifies the expression of
    > the relationship between A_LE, B_LE, C_LE and D_LE.
    > It only requires a standardized function zero_one_hot
    > that is visible in the VHDL context. I will have to
    > do some searchin, but I think there is already something
    > like this in PSL (which was incorporated by reference -
    > however - I don't think the function is visible outside
    > of a PSL statement - yet).
    >
    >
    > So the steps to finializing the alternate solution are to
    > standardize a version of zero_one_hot (hopefully one that
    > is compatible with PSL) and revise 1076.6 to say vendors
    > should support this style of coding.
    >
    >
    > > Congratulation! Now you are chairman of the committee.

    > Yes, but I am chair of the group doing the administrative
    > work of making the revision a standard. The Accellera
    > VHDL TSC is doing all of the heavy lifting the next
    > revision (and perhaps more). In the Accellera group,
    > I am just an active member.
    >
    >
    > Cheers,
    > Jim
    >
    >
    > >
    > > Hi Jim,
    > > Congraduation! Now you are chairman of the committee.
    > >
    > > How about keyword "elsor" keyword?
    > >
    > > At that time, you recommended me to contact a person who had the power
    > > to do that while you were not in the committee. I didn't contacted the
    > > person because I didn't like to do that: it would be beneficial to
    > > every engineer in VHDL and Verilog circuit.
    > >
    > > And last time we talked through the google about the introduction and
    > > you nad many new ideas and we agured a lot, finally you asked me to
    > > post most daunting design that used the technology and I posed the
    > > design and after that I never heared your answer.
    > >
    > > Thank you.
    > >
    > > Weng
    > >

    >
    >
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    Hi Jim,
    We had argured a lot 2 years ago and you mentioned several
    modifications and I indicated all shortcomings with each of your
    modifications.

    assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
    report "%%%BUG: Mutual exclusion failed in design ..."
    severity error ;

    Reg4LeProc : process(Clk)
    begin
    if rising_edge(Clk) then
    if A_LE then
    Reg4Le <= A ;

    elsif B_LE and AddrB ?= 15 then
    Reg4LE <= B ;

    elsif C_LE and AddrC ?= 14 then
    Reg4LE <= C;

    elsif D_LE then
    Reg4Le <= D ;
    end if ;
    end if ;
    end process ;

    My version of equation will look like this way:
    Reg4LeProc : process(Clk)
    begin
    if rising_edge(Clk) then
    if A_LE then
    Reg4Le <= A ;

    -- this condition, no matter how complex it is, is mutually exclusive
    with A_LE
    ORIF( B_LE ... ) then
    Reg4LE <= B ;

    -- this condition is mutually exclusive with above two conditions
    ORIF( C_LE ... ) then
    Reg4LE <= C;

    -- this conditions are as normal in grammar
    elsif D_LE then
    Reg4Le <= D ;
    end if ;
    end if ;
    end process ;

    As a vhdl programmer, we know well which conditions are mutually
    exclusive and ORIF keyword will give a concise keyword to express the
    mutually exclusive conditions.

    As a rule in my paper, I indicate that all data registers or counters,
    if there are more than 1 enable conditions, all those conditions are
    mutually exclusive if they are programmed correctly. Do you agree with
    me?

    One may see how many situations will refer to mutually exclusive
    situations!!!

    How important it is to have a very concise keyword to express the
    situations!!!

    Weng
    Weng Tianxiang, Sep 18, 2006
    #12
  13. Jim Lewis

    David Ashley Guest

    Weng Tianxiang wrote:
    > Please leave your email address, I would like to send the paper to you
    > through an email.
    >
    > Weng


    1 is dash
    Well it's not exactly a secret since visiting my site would uncover
    it pretty quickly. I'm 1@2.
    2 is xdr.com

    -Dave


    --
    David Ashley http://www.xdr.com/dash
    Embedded linux, device drivers, system architecture
    David Ashley, Sep 18, 2006
    #13
  14. Jim Lewis

    Jim Lewis Guest

    Hans,
    > That is not because of the language itself but simply because
    > SystemVerilog/SystemC support essential verification methodologies like
    > Transaction Level Modelling, ...


    Ironically VHDL already has Transaction Level Modeling capability.
    I have done a paper on this (see http://www.synthworks.com/papers)
    and a conference tutorial. We also teach a 3 day class based on
    transaction based testbenches.

    VHDL doesn't yet have OO, Constraint Random (CR) and Functional
    Coverage (FC). The inclusion of PSL gives VHDL some coverage
    capability. The plan is to have these ASAP. Probably by DAC 2007.

    > However, if you have to develop an all singing
    > all dancing testbench


    What is a "all singing all dancing testbench"?
    My point is can you enumerate what problems CR + FC is
    going to solve better than other methods?
    The answer is definitely not everything. For example
    I would not expect to use CR + FC to test arithmetic
    circuits. Algorithmic transaction based tests can generate
    more useful cases faster than CR. With CR there is no
    guarantee that you will every hit the interesting cases.
    Going further generating the FC for arithmetic is going to
    be as hard or harder than actually generating the algorithmic
    test vectors.

    Another example, for many bus interface chips that have a number
    of control registers each with their own particular format, it
    is going to be much easier to exercise the chip with a directed
    transaction based testbench than constraining a CR testbench
    to be able to understand it.

    Many of the marketing claims compare a CR + FC + transaction
    based testbench to a directed, non-transaction based testbench.
    Not a very realistic comparison. Many of the actual benefits
    to these approaches also comes from the transaction based
    testbench.

    So this comes back to my question, "Assuming that we are all
    using transaction based testbenches, can you enumerate what
    problems CR + FC is going to solve better than a other methods
    (algorithmic or directed)?"

    > However ... or you want to do some behaviour modelling of your
    > system ...

    VHDL has always been a good language for behavior modeling.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Sep 18, 2006
    #14
  15. Jim Lewis

    Jim Lewis Guest

    Weng,
    > As a vhdl programmer, we know well which conditions are mutually
    > exclusive and ORIF keyword will give a concise keyword to express the
    > mutually exclusive conditions.


    You are missing something important. With ORIF the following can
    be determined to be mutually exclusive:
    A_LE, (B_LE and AddrB ?= 15), (C_LE and AddrC ?= 14), D_LE

    Which is ok, but not as powerful as saying that the following
    are mutually exclusive:
    A_LE, B_LE, C_LE, D_LE


    Some of your examples nested if statements within case
    statements. It is far eaiser for a designer to express
    exactly what is mutually exclusive with an assertion than
    it is with orif. It is also easier to read and maintain.
    All I have to do is analyze the assert statement and make
    sure I believe it correct. With ORIF a reviewer will have
    to scrutinize every orif to make sure they understand the
    relationships.

    Repeating or rehashing the same argument is not going
    to help.

    Cheers,
    Jim

    >>assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
    >> report "%%%BUG: Mutual exclusion failed in design ..."
    >> severity error ;
    >>
    >>
    >>-- Looking forward and using new syntax introduced by
    >>-- the Accellera VHDL 2006 revision
    >>Reg4LeProc : process(Clk)
    >>begin
    >> if rising_edge(Clk) then
    >> if A_LE then
    >> Reg4Le <= A ;
    >>
    >> elsif B_LE and AddrB ?= 15 then
    >> Reg4LE <= B ;
    >>
    >> elsif C_LE and AddrC ?= 14 then
    >> Reg4LE <= C;
    >>
    >> elsif D_LE then
    >> Reg4Le <= D ;
    >> end if ;
    >> end if ;
    >>end process ;
    >>


    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Sep 18, 2006
    #15
  16. Jim Lewis wrote:
    > Weng,
    > > As a vhdl programmer, we know well which conditions are mutually
    > > exclusive and ORIF keyword will give a concise keyword to express the
    > > mutually exclusive conditions.

    >
    > You are missing something important. With ORIF the following can
    > be determined to be mutually exclusive:
    > A_LE, (B_LE and AddrB ?= 15), (C_LE and AddrC ?= 14), D_LE
    >
    > Which is ok, but not as powerful as saying that the following
    > are mutually exclusive:
    > A_LE, B_LE, C_LE, D_LE
    >
    >
    > Some of your examples nested if statements within case
    > statements. It is far eaiser for a designer to express
    > exactly what is mutually exclusive with an assertion than
    > it is with orif. It is also easier to read and maintain.
    > All I have to do is analyze the assert statement and make
    > sure I believe it correct. With ORIF a reviewer will have
    > to scrutinize every orif to make sure they understand the
    > relationships.
    >
    > Repeating or rehashing the same argument is not going
    > to help.
    >
    > Cheers,
    > Jim
    >
    > >>assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
    > >> report "%%%BUG: Mutual exclusion failed in design ..."
    > >> severity error ;
    > >>
    > >>
    > >>-- Looking forward and using new syntax introduced by
    > >>-- the Accellera VHDL 2006 revision
    > >>Reg4LeProc : process(Clk)
    > >>begin
    > >> if rising_edge(Clk) then
    > >> if A_LE then
    > >> Reg4Le <= A ;
    > >>
    > >> elsif B_LE and AddrB ?= 15 then
    > >> Reg4LE <= B ;
    > >>
    > >> elsif C_LE and AddrC ?= 14 then
    > >> Reg4LE <= C;
    > >>
    > >> elsif D_LE then
    > >> Reg4Le <= D ;
    > >> end if ;
    > >> end if ;
    > >>end process ;
    > >>

    >
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    Hi Jim,
    I strongly disagree with your opinion again.

    1. assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
    report "%%%BUG: Mutual exclusion failed in design ..."
    severity error ;
    (I really don't know what library includes zero_one_hot().)

    Can you guarantee that after the above assert statement a VHDL compiler
    will use the mutually exclusive knowledge to generate shorter coding?
    Try it with Xilinx VHDL compiler and see what logic is generated,
    please. If you succeed, I will quit the argument and I will admit
    losing the battle, otherwise, the fight will continue.

    I expect that your assert statement claims nothing to any VHDL compiler
    and VHDL compiler knows nothing to the assert statement and the same
    logic as "if..elsif...elsif...end if" will be generated as usual.

    Let fact teach me if I am wrong!!!

    2. For VHDL compiler current status, all of them IGNORE assert()
    statement during synthesizing period because it is really a debugging
    statement used only in simulations, and VHDL compilers do not generate
    any logic or retrieve any information from it at all. In other word,
    your method introduces nothing to a VHLD compiler of latest version:
    they are still generating "if...elsif...end if" logic even though you
    introduce your method to tell them the mutually exclusive information.

    3. You are introducing extra statements to generate mutually exclusive
    information to a VHDL compiler and an extra burden to writing code. You
    say your method is better than mine. I really don't understand why your
    extra 3 statements are simpler and better than mine: When you write
    assert() statement, you must weight which signals are mutually
    exclusive, but in my opinion, my method in most cases never pays
    attention to which signals are mutually exclusive, but knows well that
    for any data, counter, not control signals, if there are more than 1
    enable conditions, all of those enable conditions are mutually
    exclusive and even there are many examples you really don't clear know
    well which signals are mutually exclusive, but their conditions must be
    mutually exclusive.

    4. Here is the huge differences between your suggestion and mine:
    if we introduce "ORIF" keyword, what will a VHDL compiler do?

    A VHDL compiler must use the mutual exclusive knowledge to generate the
    simplest code, no other more complex logic like
    "if...elsif..elsif...end if" is generated.

    5. With ORIF keyword introduced, we can enforce simulator to check if
    any mutually exclusive statements are violated in VHDL language grammar
    without needing an explicit declaration of any statements. This is the
    right of your VHDL committee and use it!!!

    6. Mutually exclusive logic are ubiquitous, inherent in hardware design
    and it is a specific feather that is absent with any software
    situations. VHDL doesn't include an explain keyword 'ORIF' to let VHDL
    programmer to widely use it, it is not only a pity, but really a shame!

    7. For Xilinx VHDL compiler, the related manual strongly recommends
    that "DON'T USE 'IF...ELSIF...ELSIF...END IF' statement too deep,
    otherwise it will have serious consequences in design performance. Why?
    because of the loop, the accumulated delay caused by ELSIF keyword.
    'ORIF' will certainly resolve the problem as my 8 projects successfully
    prove that 'ORIF' should be introduced and widely used to get higher
    performance with Xilinx VHDL compiler.

    8. You said that my keyword is an extra thing, but in math, you must
    know well the power operation: 2**5 = 2*2*2*2*2. Is the power operator
    an extra operator? NO!!!
    sin() and cosin(), tan() and cotan(), there are a lot of examples that
    something must be repeated for easy usage.

    Conclusion: your method adds nothing to improve efficiency, but extra
    burden not only adding 3 statements that are ignored by any VHDL
    compiler, but having to isolate the mutually exclusive signals!!!

    Weng
    Weng Tianxiang, Sep 18, 2006
    #16
  17. Jim Lewis

    Jim Lewis Guest

    Weng,
    > 1. assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
    > report "%%%BUG: Mutual exclusion failed in design ..."
    > severity error ;
    > (I really don't know what library includes zero_one_hot().)
    >
    > Can you guarantee that after the above assert statement a VHDL compiler
    > will use the mutually exclusive knowledge to generate shorter coding?
    > Try it with Xilinx VHDL compiler and see what logic is generated,
    > please. If you succeed, I will quit the argument and I will admit
    > losing the battle, otherwise, the fight will continue.
    >
    > I expect that your assert statement claims nothing to any VHDL compiler
    > and VHDL compiler knows nothing to the assert statement and the same
    > logic as "if..elsif...elsif...end if" will be generated as usual.
    >
    > Let fact teach me if I am wrong!!!
    >
    > 2. For VHDL compiler current status, all of them IGNORE assert()
    > statement during synthesizing period because it is really a debugging
    > statement used only in simulations, and VHDL compilers do not generate
    > any logic or retrieve any information from it at all. In other word,
    > your method introduces nothing to a VHLD compiler of latest version:
    > they are still generating "if...elsif...end if" logic even though you
    > introduce your method to tell them the mutually exclusive information.


    Both proposals extend current capability.

    This is not the place for debating this feature.
    You can join Accellera and discuss this in the
    VHDL TSC requirements group. Note it does not
    reqiure money to join the VHDL TSC. Just follow
    the directions in my previous email.

    Regards,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Sep 18, 2006
    #17
  18. Jim Lewis wrote:
    > Weng,
    > > 1. assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
    > > report "%%%BUG: Mutual exclusion failed in design ..."
    > > severity error ;
    > > (I really don't know what library includes zero_one_hot().)
    > >
    > > Can you guarantee that after the above assert statement a VHDL compiler
    > > will use the mutually exclusive knowledge to generate shorter coding?
    > > Try it with Xilinx VHDL compiler and see what logic is generated,
    > > please. If you succeed, I will quit the argument and I will admit
    > > losing the battle, otherwise, the fight will continue.
    > >
    > > I expect that your assert statement claims nothing to any VHDL compiler
    > > and VHDL compiler knows nothing to the assert statement and the same
    > > logic as "if..elsif...elsif...end if" will be generated as usual.
    > >
    > > Let fact teach me if I am wrong!!!
    > >
    > > 2. For VHDL compiler current status, all of them IGNORE assert()
    > > statement during synthesizing period because it is really a debugging
    > > statement used only in simulations, and VHDL compilers do not generate
    > > any logic or retrieve any information from it at all. In other word,
    > > your method introduces nothing to a VHLD compiler of latest version:
    > > they are still generating "if...elsif...end if" logic even though you
    > > introduce your method to tell them the mutually exclusive information.

    >
    > Both proposals extend current capability.
    >
    > This is not the place for debating this feature.
    > You can join Accellera and discuss this in the
    > VHDL TSC requirements group. Note it does not
    > reqiure money to join the VHDL TSC. Just follow
    > the directions in my previous email.
    >
    > Regards,
    > Jim
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    Hi Jim,
    I have written an email to VHDL TSC to show my interest in pushing the
    keyword "ORIF" into VHDL specification.

    Thank you.

    Weng
    Weng Tianxiang, Sep 19, 2006
    #18
  19. Jim Lewis

    Hans Guest

    Hi Jim,

    "Jim Lewis" <> wrote in message
    news:...
    > Hans,
    >> That is not because of the language itself but simply because
    >> SystemVerilog/SystemC support essential verification methodologies like
    >> Transaction Level Modelling, ...

    >
    > Ironically VHDL already has Transaction Level Modeling capability.
    > I have done a paper on this (see http://www.synthworks.com/papers)
    > and a conference tutorial. We also teach a 3 day class based on
    > transaction based testbenches.
    >
    > VHDL doesn't yet have OO, Constraint Random (CR) and Functional
    > Coverage (FC). The inclusion of PSL gives VHDL some coverage
    > capability.


    I would change the some to "some very powerful"!!

    Have a look at OVL and see what this has meant (means) for the verification
    community. Now scale that capability up by a few factors and you have
    PSL/SVA. These languages are very powerful but do have a steep learning
    curve and unfortunately the associate price tag.

    > The plan is to have these ASAP. Probably by DAC 2007.
    >
    > > However, if you have to develop an all singing
    > > all dancing testbench

    >
    > What is a "all singing all dancing testbench"?


    A testbench that answers an additional question, "are we done verifying"?

    > My point is can you enumerate what problems CR + FC is
    > going to solve better than other methods?
    > The answer is definitely not everything.


    Obviously otherwise we would have the perfect verification methodology :)

    > For example
    > I would not expect to use CR + FC to test arithmetic
    > circuits. Algorithmic transaction based tests can generate
    > more useful cases faster than CR. With CR there is no
    > guarantee that you will every hit the interesting cases.
    > Going further generating the FC for arithmetic is going to
    > be as hard or harder than actually generating the algorithmic
    > test vectors.


    We are talking about different things, CR+FC is used extensively for complex
    SoC based systems, I don't believe that anybody is using this methodology on
    a simple arithmetic circuit for which a directed or algorithmic test might
    be better. You probably also know that companies do not use CR+FC in pure
    isolation, they combine it with many other types of test including directed
    tests.

    >
    > Another example, for many bus interface chips that have a number
    > of control registers each with their own particular format, it
    > is going to be much easier to exercise the chip with a directed
    > transaction based testbench than constraining a CR testbench
    > to be able to understand it.


    Again as we say horses for courses, if the circuit can be tested using a
    directed test then use that method. If the circuit becomes to complex then
    CR+FC might find additional bugs. CR will enable you to randomise not just
    the data and control but also time and injected errors. CR+FC is a proven
    technology and I have been told that these techniques have been used long
    before the big EDA companies started to support it.

    >
    > Many of the marketing claims compare a CR + FC + transaction
    > based testbench to a directed, non-transaction based testbench.
    > Not a very realistic comparison.


    Does anybody believes marketing :)

    > Many of the actual benefits
    > to these approaches also comes from the transaction based
    > testbench.
    >
    > So this comes back to my question, "Assuming that we are all
    > using transaction based testbenches, can you enumerate what
    > problems CR + FC is going to solve better than a other methods
    > (algorithmic or directed)?"


    System were you have a complex interaction for which a directed test is
    simply to complex to write. In these cases it is easier to write a set of
    constraints and let the tool generate the stimulus. You then use FC to
    collect the coverage data to make sure you are addressing the specification
    requirements. I believe that on most SoC systems nowadays the number of
    testvectors is so large that even CR running a large computer farm needs to
    be steered in the right direction (changing the seed/distributions). Just to
    iterate the point, CR+FC is only part of the verification arsenal that large
    companies are using. Directed and algorithmic test together with
    assertions, TLM, formal, prototyping, hardware emulation, equivalence
    checking, black magic, voodoo are all part of that arsenal.

    >
    > > However ... or you want to do some behaviour modelling of your
    > > system ...

    > VHDL has always been a good language for behavior modeling.


    Yes, my mistake, I am not saying that VHDL is not capable of handling this
    task. What I am saying is that for a complex modelling job you might be
    better off with a modern language which was specifically developed for this
    purpose.

    Regards,
    Hans

    www.ht-lab.com


    >
    > Cheers,
    > Jim
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Hans, Sep 21, 2006
    #19
  20. Jim Lewis

    Eric Smith Guest

    Weng Tianxiang wrote:
    > I have written an email to VHDL TSC to show my interest in pushing the
    > keyword "ORIF" into VHDL specification.


    I respectfully suggest instead using the Ada shortcut logical operators
    "or else" and "and then", since VHDL syntax was originally derived
    from Ada. This avoids any need to introduce new reserved words.

    Eric
    Eric Smith, Apr 14, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charlie Zhang
    Replies:
    3
    Views:
    1,241
    Paul Lutus
    Aug 16, 2004
  2. Terrence Brannon

    Incremental Progress Report object/closure?

    Terrence Brannon, Sep 1, 2006, in forum: Python
    Replies:
    3
    Views:
    279
    Fredrik Lundh
    Sep 2, 2006
  3. Jim Lewis
    Replies:
    0
    Views:
    859
    Jim Lewis
    Oct 13, 2006
  4. Michael S

    report progress from C function

    Michael S, Oct 31, 2006, in forum: Python
    Replies:
    3
    Views:
    243
    Hendrik van Rooyen
    Nov 2, 2006
  5. afd
    Replies:
    1
    Views:
    8,267
    Colin Paul Gloster
    Mar 23, 2007
Loading...

Share This Page