[vhdl-200x] Strong Timing

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<mailto: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, and is
believed to be clean.