Talk:VHDL

"When" tag in History section

From multiple sources on the internet: The DoD commissioned Intermetrics, IBM, Texas Instruments in 1983 to develop VHDL. You can find that information by googling for "1983 DOD VHDL". But I don't know where to find a "reliable" source for that. I have put a citation of the MIL-STD-454N in the history section, but this Standard is from 1992 (when VHDL was already specified), so it does not tell you when VHDL was originally commissioned. Lundril (talk) 09:39, 15 November 2017 (UTC)

Please remove the Fibonacci example!

The Fibonacci example takes a lot of space and is of no real good. It is long, and boring, not very usefull VHDL and is almsot a copy of the counter example (which is also long and not very useful). It looks like someone was in love with the Fibonacci numbers and decided to add it to the VHDL page just because he could :(

If you guys really want to add something of value to the VHDL page, I suggest you add a picture of the generated hardware for each of the smaller examples. These can be obtained using, for example, the free version (Webpack) of Altera Quartus. I belive that showing the generated hardware would be of _MUCH_ more use to the people just browsing the VHDL pages trying to figure out what the heck it is... —Preceding unsigned comment added by 81.236.17.231 (talk) 09:24, 18 July 2008 (UTC)

I will remove the Fibonacci example in short if no one objects —Preceding unsigned comment added by 81.236.17.231 (talk) 19:30, 23 July 2008 (UTC)

Too many code examples

I think this article has way too many code examples. I know this is well intentioned, but this is an encyclopedia, not a software manual. The article should concentrate on verbally describing VHDL, its history, its differences (and similarities) to other HDL languages, and links to resources. p.s. I've noticed a similar problem on other software languages' pages. Peter Ballard (talk) 11:45, 11 August 2008 (UTC)

I agree and encourage you to WP:BEBOLD --Kvng (talk) 19:13, 16 November 2010 (UTC)

Agreed. One or two code example for each construct should be plenty. We do not even need a code example for every hardware block. This article is not an introduction to VHDL. It is an encyclopedic entry. Philippe (talk) 09:21, 20 February 2011 (UTC)

Removed weasel sentences

The weasel nonsense about VHDL being supposedly superior (or not or whatever) to Verilog has been around and tagged long enough so I just got rid of it. If someone can provide a NPOV comparison, then cool. And no, I'm not a Verilog fan. Jiri Svoboda (talk) 13:02, 21 February 2009 (UTC)

There is one big difference between VHDL and Verilog (NOT System Verilog) and that is that VHDL has a full type system, whereas Verilog has not. Why is this useful (for synthesis) ? Because in VHDL you can declare a "record" which groups together signals. You can then declare an entity, which just takes an input of this previously declared record type. By this technique you can modify the inputs/outputs of an entity by just changing the type declaration of the record type, but without touching the code describing the entity. There is no way to do something similar in Verilog (because you are missing a type system); and yes: This is a HUGE advantage for VHDL. As an example why this is useful: Have a look here http://gaisler.com/doc/structdesign.pdf 194.25.174.98 (talk) 08:55, 15 November 2017 (UTC)

Questionable Statement Regarding C/C++ As Prerequisite Knowledge

"Although background in a computer programming language (such as C and C++) is helpful, it is not essential."

As someone who has worked with students learning VHDL, this statement about C or C++ is somewhat misleading because these languages are inherently single threaded in nature, whereas VHDL has built-in support for parallel constructs inherent in the language itself. Its mentioned in the article that VHDL borrows heavily from Ada.

GHDL is a VHDL simulator and it is actually written in Ada, so it means that Ada is probably a good basis from which to get comfortable with VHDL because of their shared history, and similar support for parallelism, even if there are some differences. Certainly its a smoother transition than coming to VHDL from a traditional programming language which has different design goals. C is designed for (operating) systems programming, ie. software that does work for other software, and C++ is C with classes for larger projects and object oriented constructs. Neither support parallel task or process synchronization in the way Ada or VHDL do, without libraries external to the language.

Please feel free to comment on my notions, and let me know at once if I am in error. Thank you very much! —Preceding unsigned comment added by 99.236.37.188 (talk • contribs) 05:09, August 8, 2009

I agree, C/C++ is an odd example and Ada is a much better match. Ada has been added some time ago. I will remove the reference to C/C++. --EnOreg (talk) 11:03, 14 April 2010 (UTC)

Not the real 'long term'?

I think it should say 'Very high speed integrated circuit Hardware Description Language' —Preceding unsigned comment added by 130.225.243.80 (talk • contribs) 14:53, April 30, 2010

I agree. 63.139.250.163 (talk)

Make good examples (repect guideline coding style)

Synchronous reset must be renamed to RAZ (or equivalant for synchronous reset). "Reset" is top high priority asynchronous signal in design. Better is to use "Reset_n" (active low) because of voltage monitor, reset_n push button...

-- template for synchronous reset with clock enable:
process(CLK)
begin
  if rising_edge(CLK) then
    if RAZ = '1' then 
      Q <= '0';
    elsif Enable = '1' then  -- or '0' if Enable is active low...
      Q <= D;
    end if;
  end if;
end process;

Why warn against a "beginner's mistake" when we can avoid teaching beginners dangerous coding style altogether?

It's true that pretty much every VHDL textbook shows async-reset flop coding as shown in the article:

if reset_is_active then
  Q <= '0';
elsif rising_edge(clock) then
  Q <= D;
end if;

However, as the article goes on to explain, there is a gotcha with this style if you forget, or intentionally don't want, to assign to something under reset. In the article's example this is pretty obvious as the reset clause remains empty. However in real life this may be much more difficult to spot e.g. inside a larger state machine:

type state_type is (s_idle, s_some_state, s_another_state);
signal state : state_type;
signal A,B,C : std_ulogic_vector(99 downto 0);

process(clock, reset) is begin
  if reset='1' then
    state <= s_idle;
    -- let's assume there's no functional need to reset A,B,C as they have no effect in s_idle,
    -- and will get assigned upon transition out of s_idle. We want to save some area by using simple
    -- non-reset flops.
  elsif rising_edge(clock) then
    ...
    state <= calculate_next_state_using(stuff_not_shown_here);
    ...
    A <= something; ... B <= something_else; ... C <= yet_another_thing;
    ...
  end if;
end process;

If you synthesize the above, A,B and C will consist of hundreds of flops having clock enables (or feedback muxes). This can turn out to be much more expensive than the flops-with-reset we were trying to spare. It will also create a synchronous timing path on the reset signal. This can be easily and safely avoided if you describe your intention of async-reset more accurately:

if rising_edge(clock) then
  Q <= D;
end if;
if reset_is_active then
  Q <= '0';
end if;

The above uses position to determine priority. I do not agree with ever using position to determine priority. I would suggest the article change to the following:

if (reset_is_active) then
  Q <= '0';
elsif (rising_edge(clock)) then
  Q <= D;
end if;

Think of it - why are we being taught to use elsif? Is there really an "if-else" relationship between reset and clocking? The relationship has more "override" semantics than "if-else" semantics. Async reset is an unconditional override of everything else, where it applies (and only there!).

Apply the above template to the state machine example and you will get exactly what was intended.

I realize that generations of engineers have been raised on the "elsif rising_edge()" paradigm. Still it's no reason to teach that to new generations that come to learn at Wikipedia. Udibar (talk) 21:10, 10 August 2010 (UTC)

Why making ambiguous, difficult to read, sources of errors, heterogeneous code ? VHDL needs high rigour. It is a (very very) strong typed language. Engineers will be efficient by spending time designing that "reading and translating" VHDL. Moreover synthesis tools detect those if-else templates in process and interpret as D flip flop (some high quality tools detect gated clocks and rewrite this as a clock enable). Make life simple. — Preceding unsigned comment added by 194.250.203.171 (talk) 10:13, 7 October 2011 (UTC)

Best Practice with clocks

Although it is true that you can define a clock with

if CLK'Event and CLK='1' then

Best practice is to use

if rising_edge(CLK) then

The reason for this is rising_edge filters such that it will only trigger when rising from '0' to '1'. Whereas CLK'event will trigger when the clock glitches out of undefined. Although this will have no impact of synthesised circuits, it may have an effect on any simulations, as such I would like to suggest that we add a note to make this subtle difference clear in the clock example. --62.232.98.250 (talk) 15:46, 15 October 2012 (UTC)

Disadvantages are Unverifiable

I am removing some disadvantages that are unverifiable and seem biased. For example, the statement: "The abstractions used for modeling digital circuits in VHDL have different semantics than actual hardware, so it does not work well below the RTL abstraction. Specifically it has no built-in type that supports bidirectional components like "pass gates" sometimes used in MOS, and there is no (easy) way to describe such behavior in user code." can be easily disputed. VHDL provides facilities to design at various levels of abstraction, including high-level structural designs, behavioural modelling, and low-level structural (gate-level or switch-level) designs. Pass gates can easily be modelled behaviourally like this:

architecture behaviour of nmos is begin
    s<=d when g='1' or g='H' else 'Z';
end architecture behaviour;

and this can be used structurally in any switch-level or gate-level design, e.g.:

architecture structural of mux is begin
    i_nmos: entity work.nmos(behaviour) port map(g=>sel, d=>d(0), s=>s);
    i_pmos: entity work.pmos(behaviour) port map(g=>sel, s=>d(1), d=>s);
end architecture structural;

where d = drain, s = source, and g = gate of the transistors.

The statement "The signal abstraction also fails to separate strength, value and certainty which makes it inefficient when not using standard library types." is also confusing / misleading. You can always use standard library types when you declare a signal, and the 9-valued std_logic will be able to separate strength, value, and certainty. If you want to use non-standard library types, you may do so as well; just create a multi-valued logic custom type:

type yourOwn_std_logic is ('1', '0', 'H', 'L', 'Z');

This statement is also disputable: "The failure to implement inheritance means you have to type a lot of extra code. e.g. component and entity declarations often contain the same information, so inheriting one from the other would be useful."

We can always directly instantiate entities without using the 1987-style component declarations. I believe this has been around since 2002 (or earlier).

i_nmos: entity work.nmos(behaviour) port map(g=>sel, d=>d(0), s=>s);

I am removing this statement as well: "Strong typing destroys polymorphism and means you end up with multiple copies of the same structural code just to get wire types to match."

VHDL supports parametric polymorphism and subtype polymorphism. VHDL supports subtype/inclusion polymorphism where a subtype can be declared from another datatype, and this has been around since probably the beginning of VHDL. Parametric polymorphism is supported by the "generic" keyword. Traditionally, the "generic" keyword is used to pass values into subprograms and entity instances. The limitation with this is you can only pass values whose types have already been defined. VHDL-2008 improves this further by having facilities for generic types, subprograms, and packages. Here, you can pass a yet-to-be-defined type into an entity instance:

entity nmos is generic(type t);
    port(d,g:in t;
        s:out t
    );
end entity nmos;

Daniel.kho (talk) 02:02, 23 April 2013 (UTC)

Link to VHDL webpage is missing

The link in the info box (http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome) is no longer valid. We need to find a correct link to put here instead. — Preceding unsigned comment added by 198.182.12.70 (talk) 19:40, 1 August 2017 (UTC)

Suggest merge January 2018

IEEE 1164 makes little sense as a free standing article; this article, on the other hand, explains why IEEE 1164 was needed. Wouldn't it make sense to merge any significant content from that article to this one? --Wtshymanski (talk) 19:25, 21 January 2018 (UTC)

I think that both topics are worthy of their own page and would oppose this merge. On the other hand, that would suggest that IEEE 1076 should have its own article as well, though as it's the main standard for VHDL perhaps that would make less sense. Ultimately, I think the IEEE 1164 article could be cleaned up a bit to tell a bit more about why it was created and its relationship to 1076. - - mathmitch7 ^{(talk/contribs)} 19:02, 29 July 2018 (UTC)

Package Files should be part of the discussion

There should be mention of package files in this topic. Package files are a big advantage of VHDL and should be included here. I code in a modular fashion and every module I write has a package file included with the logic file to define constants and module specific types, usually records and arrays of records, for the given module. — Preceding unsigned comment added by 98.144.6.65 (talk) 07:10, 16 February 2018 (UTC)

Infinite vs Infinitesimal

Section §2 Design: Paragraph 2, sentence 2 ends with the phrase "... an infinitely small time step.". The tradition in Analysis is to use the adjective infinite for large and infinitesimal for small. To remove the apparent conflict I would suggest " ... infinitesimally small time step.", although neither is what discrete machines are capable of since their smallest possible size remains finite. However, if what was meant is conceptually the 'smallest possible time step', then infinitesimal would be more appropriate adverb. I'd leave it to the authors to decide.Mkhomo (talk) 21:28, 29 November 2018 (UTC)

citation needed in Early ADA Influences

On trying to track ADA influences I noticed most of ADA references lead to unavailable or obsolete sources such as gopher links which browsers no longer try resolving, and some sites are no longer in existence as I well know with my own from that time. But here (http://archive.adaic.com/pol-hist/policy/mandate.txt) is a citation found indirectly via an sgml floating index that led to an annotated live mausoleum copy which retains access to 'the 1990 ADA Mandate' of Congress for the US DoD Appropriations of 1991. It does not quite support the 'design goal' assertion but does provide the context that DoD military procurement at that time encouraged ADA over other choices for cost containment purposes. The citation also misleads in that the Mandate came long after ADA had proven itself a viable specifications standard for reducing procurement cost. As before I leave it to VHDL subject principals to add it and perhaps adjust the cited claim accordingly (Mkhomo (talk) 05:23, 6 January 2022 (UTC)).

"Simulation alters between two modes

Shouldn't this be "alternates"?

I think that the author is trying to convey the idea that there is a "statement execution (mode), where triggered statements are evaluated" followed by an "event processing (mode), where events in the queue are processed" and then it reverts to the statement execution mode etc. ad infinitum. However I'm not a specialist in this area so haven't done an edit. MarkMLl (talk) 09:08, 11 October 2019 (UTC)