Re: [vhdl-200x] Strong Timing

Hi all,
I agree with Jonathan that a lot of our time is spent on trying to meet
timing. Probably working on this is a good move in the right direction too,
as much of the verification of designs can already be handled by the core
VHDL language. However, the language does not have enough constructs on
imposing timing constraints.

Currently vendors have separate tools to perform functional simulations and
timing simulations (static timing analysis). Also, timing analysis tools
currently use their own de facto language (Synopsys Design Constraints -
SDC). Perhaps it is good that VHDL has some kind of interface to SDC, or
even better, have those constrained timing capabilities built into the
language.

Just my two cents worth.

Regards,
Daniel Kho
On Mon, Dec 20, 2010 at 2:26 PM, Sudeep Kumar <sudeepts@gmail.com> wrote:

> Hi all,
>
> I Agree with Jonathan Ross, Ben Cohen,
>
> That we should work towards keeping Vhdl Alive, and make it competative,
> as Jonathan mentioned, we need to have all the system verilog
> capabilities,
> Along with the features what he mentioned, we need to include some others
> as well like
>
> 1. Mailboxes,
> 2. Semaphores,
> 3. Fork join statements.
> 4. Assertions,
>
> and Etc, and and keeping the vhdl advantages and can think of some more
> other features,
> which can Give Vhdl an Edge over System Verilog.
>
>
> With Regards
> Sudeep
>
> On Mon, Dec 20, 2010 at 11:26 AM, Jonathan Ross <Jonathan.Ross@pacmid.com>wrote:
>
>> It is important to learn from SV as well as to go beyond it. I agree
>> that strong typing is a key benefit of VHDL, it is why my team chose it a
>> year or so ago when we began with HDL work. To that end a colleague and I
>> have been studying the concept of strong timing. The idea is to specify
>> timing relationships between processes so that errors can be caught before
>> simulation. So far we've confined ourselves to observation:
>>
>> 1. Output is related to input.
>> 2. One or many inputs may relate to one or many outputs.
>> 3. Inputs may arrive at differing "times." I.E., data may be transmitted
>> serially, or it may come in batches with unfixed timing.
>> 4. Output may be dispatched at different "times". I.E., an acknowledge is
>> related to input, but may occur at any interval, even non-fixed intervals,
>> with respect to other output related to the input.
>> 5. Variables may have different relationships to inputs and outputs during
>> different phases of pipelining.
>> 6. Timing is determined as coming before or after other events, where
>> events may be a clock.
>>
>> Currently validating timing tends to take up most of our time. Worse yet
>> is that timing is what we must most often change. Often when the type of a
>> variable (such as the width of an array) must change then any failure to
>> adapt fully in code results in an error; this is not currently the case with
>> respect to timing. The hope is to come up with a minimal yet universal
>> syntax to extend timing, likely transactional, but we hope to eventually go
>> further. We use a 5 level hierarchy to describe the difficulty of a project:
>>
>> 1. Any programming, including simple scripting.
>> 2. Programming requiring pointers. A number of developers find multiple
>> levels of indirection difficult to work with.
>> 3. Programming requiring parallelism. Similar, but to a much greater
>> extent.
>> 4. Real time development. This requires a working knowledge of the
>> hardware for code to be properly refactored, and again requires more time.
>> 5. Formal verification. Often requires a very high level of education and
>> significantly more man hours.
>>
>> FPGA use spares HDL developers from some burdens of formal verification,
>> and a lot of these high level to low level language converters attempt to
>> relieve developers from the real time development issues by allowing
>> variable timing. The problem with these languages is that they tend to be
>> ill-suited for electrical engineering and parallelism.
>>
>> If time were strongly defined the next logical step would be to unfix it.
>> Not all FPGA development has strict timing requirements, and sometimes it
>> would be suitable to specify exactly that and let the tools handle register
>> placement automatically. By simplifying development for those who do not
>> need real time constraints it would greatly broaden the appeal of VHDL.
>>
>> Though my colleague and I had originally intended to work on this until we
>> had a much better developed idea , our lack of experience plus the magnitude
>> of the task has led us to believe it might be best to hand the idea over to
>> the community. Any comments?
>>
>> Best Regards,
>> Jonathan Ross
>>
>> On Dec 19, 2010, at 8:54 PM, Daniel Kho wrote:
>>
>> Hi Stephen and all,
>> I have been waiting for this sort of discussion in the SG, and thanks to
>> Steve, we can finally discuss our direction.
>>
>> I have to agree with some of Steve's points, including the declining use
>> of VHDL. However, I think that we can do something to stop this trend (of
>> people using non-VHDL design and verification languages). Perhaps instead of
>> doing the same things that SV has been doing over these years, we could
>> think of other things that could make VHDL more appealing.
>>
>> My belief is that VHDL usage in Europe, Australia (and probably most of
>> the Commonwealth) remains strong. I don't have statistics though, but I am
>> one example of a VHDL-only user designing for a European application. One of
>> the really good thing about VHDL is that we don't really need such a
>> comprehensive verification package (like that used by Verilog / SV), the
>> reason being that VHDL is already very strongly typed - this means less
>> verification.
>>
>> I hear VHDL designers say "If it works in simulation, it works on
>> silicon", but I don't hear the same from Verilog/SV designers. Instead they
>> would talk a lot about verifying their designs. The rationale is clear,
>> Verilog/SV needs very comprehensive verification (I even hear of great
>> emphasis on lab bench verification and FPGA emulation - for ASIC designers)
>> to counter for their weak typing, while VHDL being strongly-typed, does not
>> require such comprehensive verification capabilities.
>>
>> I currently write everything in plain old VHDL - from the core designs to
>> even the testbenches. And I feel the language is sufficient for both
>> purposes (this perhaps is because my designs aren't as complex as some of
>> yours).
>>
>> My humble opinion is that we should not try to do the same things those SV
>> guys have been doing (I agree with Steve on this), but instead focus our
>> energy on things that make VHDL easier to use, such as simplifying type
>> conversions, and friendlier packages.
>>
>> I would propose that we make some of VHDL's core packages to easily work
>> together with one another. One simple example I can think of is in the use
>> of literals:
>>
>> signal i: integer := x"ab";
>>
>> where in this case, I can use the hex notation to express an integer
>> instead of writing out 16#ab#.
>>
>> I further propose for certain packages to be synthesisable, such as the
>> math_real package (this would ease designers from having to write their own
>> fixed-point or floating-point packages).
>>
>> Also, for certain constructs in the core language to be synthesisable,
>> such as "assert" or "report", which currently is exclusively used only in
>> simulation. I can think of something like a generic "debug interface" or
>> "verification interface", which can be synthesised to a real interface
>> reserved for debugging/verification purposes. And this interface allows for
>> the use of constructs such as "report" and "assert", while having
>> capabilities such as queuing of "reports" (or logs), and bus arbitration
>> (for multiple verification interfaces).
>>
>> I am positive that with great minds as all of you, the SG/WG will be able
>> to brainstorm such great ideas to set the direction for the next revision of
>> VHDL.
>>
>> Regards,
>> Daniel
>>
>>
>> On Mon, Dec 20, 2010 at 4:35 AM, Bailey, Stephen <
>> stephen_bailey@mentor.com> wrote:
>>
>>> I have submitted my negative vote on the PAR to Jim. I am now
>>> forwarding the comments that document why I am voting Negative.
>>>
>>> -Steve Bailey
>>>
>>> The SG has spent all of its time discussing the organization of the WG
>>> as individual or entity/Corporate. I don't see anything in the minutes
>>> identifying the requirements for this revision. The recent flurry of
>>> emails has me concerned that the WG will duplicate significant work that
>>> has gone into SV by putting similar functionality into VHDL. I cannot
>>> support the waste of tens to hundreds of man-years to achieve that
>>> output with the only outcome being that people can do what they can do
>>> today only in 2 different languages instead of 1 (actually 4 different
>>> languages instead of 3 when you include e and Vera).
>>>
>>> VHDL usage was on the decline prior to SV. SV has accelerated that
>>> decline. I don't see a way to change the current course of the
>>> EDA/language trends. They are too strong and the cost to change them
>>> are prohibitive.
>>>
>>> Data which the SG may find useful. The data is from a recent blind
>>> survey commissioned by Mentor and conducted by Wilson Research Group.
>>> This data is from North America. The rest of the world portion of the
>>> survey was recently completed and the combined results not yet
>>> available.
>>>
>>> VHDL design usage declined from 37% in 2007 to 27% in 2010 with
>>> respondents projected a further decline to 23% in the next 12 months.
>>> That's a loss of nearly 40% of the design user base for VHDL.
>>>
>>> Verilog usage has declined from 81% to 78% and projected to go to 71%.
>>> SystemC, C/C++ and other design languages have also declined from 2007
>>> to 2010.
>>>
>>> SV has increased from 10% to 34% today and projected to reach 47% in the
>>> next year. That's a nearly 5x increase in usage.
>>>
>>> In verification, VHDL usage is down to 21%, from 27%, and projected to
>>> fall further. In fact, there are only two languages that have increased
>>> usage in verification: SystemVerilog usage in verification more than
>>> doubled to 50% and is projected to increase significantly in the next
>>> year. C/C++ has seen a respectable increase from 2007 but is projected
>>> to decline slightly in the next year. Even SystemC usage in
>>> verification is down slightly from 2007 -- call it steady at about 17%.
>>>
>>> The survey included FPGA and ASIC designs and respondents from all
>>> industries/markets. Although data from the rest of the world might
>>> soften a bit what is being reported in NA, based on my personal
>>> experience, I don't expect it to be meaningful in any area except maybe
>>> SystemC, which has historically higher use in Europe and Japan than in
>>> the U.S.
>>>
>>> In the next year, 80% (4 of every 5) of designers and verification
>>> engineers will use a language that is not VHDL. Most of them will be
>>> using SV or Verilog.
>>>
>>> The SG needs to ask itself these questions: Can you stop a tsunami?
>>> What can you offer that would overcome a projected 3x+ advantage that SV
>>> will have over VHDL in verification usage within the next year; and
>>> surely greater than that 2 or 3 years from now. If the plan is to
>>> survive the tsunami, what will you do to survive it when EDA vendors
>>> clearly know where the market is going? Until these questions are
>>> addressed in a manner that reflects reality, my vote will remain No on
>>> another VHDL language revision.
>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
>> is
>> believed to be clean.
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>>
>> believed to be clean.
>>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.