VHDL language is out of date! Why? I will explain.

Discussion in 'VHDL' started by psihodelia@googlemail.com, Nov 16, 2007.

  1. Guest

    Just look at its syntax. It is so archaic that anyone who had any deal
    with Python will just laugh. Try, say, to create a simple VGA
    controller, which is simply readable.

    VHDL's Ada syntax is also very error prone. Instead of having all this
    archaic constructions and surplus operators, it would be much more
    productive just to start thinking about to create another hi-level HDL
    that has absolutely another conceptual design and simple syntax.

    Any good language should be so simple as possible and any program in
    this language should be short and clear. Such language should support
    associative arrays, that should help designing large FSMs; should
    support simple mechanism of type conversions and so on...

    Conceptually VHDL is not bad at all, it supports a lot of things, well
    in theory. But in praxis ...

    And don't forget about future FPGAs, about future SoCs, which will
    have integrated MEMS arrays, and other stuff. Try to understand how
    much complexer they are to be designed in so unproductive way using so
    primitive languages.
     
    , Nov 16, 2007
    #1
    1. Advertising

  2. KJ Guest

    On Nov 16, 1:27 pm, ""
    <> wrote:
    > Just look at its syntax. It is so archaic that anyone who had any deal
    > with Python will just laugh. Try, say, to create a simple VGA
    > controller, which is simply readable.
    >
    > VHDL's Ada syntax is also very error prone. Instead of having all this
    > archaic constructions and surplus operators, it would be much more
    > productive just to start thinking about to create another hi-level HDL
    > that has absolutely another conceptual design and simple syntax.
    >
    > Any good language should be so simple as possible and any program in
    > this language should be short and clear. Such language should support
    > associative arrays, that should help designing large FSMs; should
    > support simple mechanism of type conversions and so on...
    >
    > Conceptually VHDL is not bad at all, it supports a lot of things, well
    > in theory. But in praxis ...
    >
    > And don't forget about future FPGAs, about future SoCs, which will
    > have integrated MEMS arrays, and other stuff. Try to understand how
    > much complexer they are to be designed in so unproductive way using so
    > primitive languages.


    So I guess you'll be designing all your stuff in another language and
    dropping out of this newsgroup...

    KJ
     
    KJ, Nov 16, 2007
    #2
    1. Advertising

  3. Guest

    On Nov 16, 1:27 pm, ""
    <> wrote:

    > VHDL's Ada syntax is also very error prone. Instead of having all this
    > archaic constructions and surplus operators, it would be much more
    > productive just to start thinking about to create another hi-level HDL
    > that has absolutely another conceptual design and simple syntax.


    Ever heard of verilog ?

    It's a bit more like c - you can write very concise code, or you can
    make a real mess...
     
    , Nov 16, 2007
    #3
  4. HT-Lab Guest

    <> wrote in message
    news:...
    > Just look at its syntax. It is so archaic that anyone who had any deal
    > with Python will just laugh. Try, say, to create a simple VGA
    > controller, which is simply readable.


    Ok, in that case start writing your VGA controller in Python, then go to
    http://myhdl.jandecaluwe.com/doku.php/start synthesize it, download it on an
    FPGA prototype board and report back to us how incredible simple and quick
    it was.... :)

    > Conceptually VHDL is not bad at all, it supports a lot of things, well
    > in theory. But in praxis ...


    Praxis....isn't that a DIY store in Holland?

    Hans
    www.ht-lab.com



    >
    > VHDL's Ada syntax is also very error prone. Instead of having all this
    > archaic constructions and surplus operators, it would be much more
    > productive just to start thinking about to create another hi-level HDL
    > that has absolutely another conceptual design and simple syntax.
    >
    > Any good language should be so simple as possible and any program in
    > this language should be short and clear. Such language should support
    > associative arrays, that should help designing large FSMs; should
    > support simple mechanism of type conversions and so on...
    >
    > Conceptually VHDL is not bad at all, it supports a lot of things, well
    > in theory. But in praxis ...
    >
    > And don't forget about future FPGAs, about future SoCs, which will
    > have integrated MEMS arrays, and other stuff. Try to understand how
    > much complexer they are to be designed in so unproductive way using so
    > primitive languages.
     
    HT-Lab, Nov 17, 2007
    #4
  5. Thomas Rouam Guest

    > Any good language should be so simple as possible and any program in
    > this language should be short and clear.


    A reminder : VHDL is not a programming language, thus implying you do
    not write a program with VHDL.
     
    Thomas Rouam, Nov 17, 2007
    #5
  6. In
    news:
    timestamped Fri, 16 Nov 2007 10:27:59 -0800 (PST),
    "" <> posted:
    |-----------------------------------------------------------------------|
    |"Just look at its syntax. It is so archaic that anyone who had any deal|
    |with Python will just laugh. [..]" |
    |-----------------------------------------------------------------------|

    Nonsense.

    |-----------------------------------------------------------------------|
    |VHDL's Ada syntax is also very error prone. Instead of having all this |
    |archaic constructions and surplus operators," |
    |-----------------------------------------------------------------------|

    I disagree that any of VHDL and Ada has error-prone syntax. Please
    provide examples.

    |-----------------------------------------------------------------------|
    |" it would be much more |
    |productive just to start thinking about to create another hi-level HDL |
    |that has absolutely another conceptual design and simple syntax." |
    |-----------------------------------------------------------------------|

    Does reFLect not fit your needs. What about Lava or Hawk or APL or
    Confluence or Verischemelog or any of the other supposedly high-level
    terse languages which have been proposed for hardware (not that APL
    had originally been proposed for hardware, but at least one paper for
    hardware with APL had been published).


    |---------------------------------------------------------------------|
    |"Any good language should be so simple as possible and any program in|
    |this language should be short and clear. Such language should [..] |
    |should help designing large FSMs; [..] |
    | |
    |[..]" |
    |---------------------------------------------------------------------|

    So despite your claim that VHDL is out of date and your mention of
    Python earlier, should your advocacy of state machines be construed as
    evidence that you oppose object orientation?
     
    Colin Paul Gloster, Nov 17, 2007
    #6
  7. wrote:

    > Conceptually VHDL is not bad at all, it supports a lot of things, well
    > in theory. But in praxis ...


    Here's my workaround using the thunderbird news reader:
    1. Click on the OP's posting.
    2. Message, Create Filter from Message, OK, Close.

    -- Mike Treseler
     
    Mike Treseler, Nov 17, 2007
    #7
  8. Mike Treseler wrote:
    > Here's my workaround using the thunderbird news reader:
    > 1. Click on the OP's posting.
    > 2. Message, Create Filter from Message, OK, Close.


    Oh, that's how it is done! *plonk*
    To the rest: please don't feed the trolls.

    f
     
    Filip Miletic, Nov 17, 2007
    #8
  9. Jan Decaluwe Guest

    HT-Lab wrote:
    > <> wrote in message
    > news:...
    >
    >>Just look at its syntax. It is so archaic that anyone who had any deal
    >>with Python will just laugh. Try, say, to create a simple VGA
    >>controller, which is simply readable.

    >
    >
    > Ok, in that case start writing your VGA controller in Python, then go to
    > http://myhdl.jandecaluwe.com/doku.php/start synthesize it, download it on an
    > FPGA prototype board and report back to us how incredible simple and quick
    > it was.... :)


    I hope some one will take the project :) (You'll need a development
    version for VHDL conversion.) Here's what to expect.

    The synthesizable RTL subset is what it is. Conceptually, there's little
    to be gained from using MyHDL or whatever instead of VHDL for this.
    There are good and bad ways to do it, but it will all be fairly "low level".
    I'm not sure the OP understands that. It's not a syntax issue.

    Having said that, MyHDL RTL has interesting features. In particular,
    it has a "hardware designer's dream type" (or at least my dream):
    a constrainable integer type like in VHDL (but not restricted to
    32 bits ...), with an indexing and slicing interface for bit access.
    All issues with signed/unsigned, resizing, casting, std_logic_arith
    versus numeric_std, ... simply go away. The integer-like MyHDL type
    simply works as integers do, and the convertor takes care of all
    those low-level issues.

    I'm still puzzled why nobody had this idea before (and why I'm not
    getting more praise :)), but in any case, it's not a matter
    of syntax. I put it in, and I could specify how to do it in any
    other language.

    If you like dynamic languages (not everybody does), you'll enjoy
    using MyHDL/python especially during verification. There you can
    use the full power of python, which is in my opinion invariably
    useful. Combined with a unit test framework such as py.test,
    verification almost becomes fun :)

    Jan

    --
    Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Kaboutermansstraat 97, B-3000 Leuven, Belgium
    From Python to silicon:
    http://myhdl.jandecaluwe.com
     
    Jan Decaluwe, Nov 17, 2007
    #9
  10. Guest

    MyHDL looks really nice!
    Is it possible to have in a FSM one procedure-or-function for each
    state? It should make the program code easy to read. It will be also
    better to have an array of functions and call them according FSM state
    number. Do you have any idea how to implement this in MyHDL?
    Here is a vivid wishful pseudo-Python example of what I mean:

    def read(args):
    do smth.
    def write(args):
    do smth.
    ...
    function = [1:read, 2:write, 3:sleep, 4:wake]
    next_state = [1:3, 2:3, 3:3, 4:1]
    def FSM_states_switch:
    state = next_state[state]
    def FSM_output_function:
    function[state](args)
     
    , Nov 18, 2007
    #10
  11. Paul Taylor Guest

    On Sat, 17 Nov 2007 20:52:59 +0100, Jan Decaluwe wrote:

    > The synthesizable RTL subset is what it is. Conceptually, there's little
    > to be gained from using MyHDL or whatever instead of VHDL for this.


    I think that there is something to be gained from using 'whatever', but it
    depends - if you are full-time vhdler working on small or large FPGA
    designs then fine; if you are an electronics engineer who on a reasonably
    regular basis has an FPGA that needs to be designed/verified then vhdl is
    (IMO of course) too complex, and, for test benches in particular, too
    cumbersome.

    Here is an example of my solution:

    # @title Dual UART Tx FPGA
    # @description FPGA design with two UART tranamitters that
    # continuously transmit data taken from one-hot counters
    # @port clk 10MHz clock
    # @port nARst Active low reset
    # @port txA UART transmit channel A
    # @port txB UART transmit channel B
    # @marked nARst Use aRst
    use berry.if.serial.*;
    use berry.util.*;

    module DualUartTx() {
    inport clk, marked nARst;
    outport txA, txB;

    reg stateMachine[] = {
    async 0 when aRst;
    : uartA.wr = 1; uartB.wr = 1; next;
    : 0 when uartA.ready & uartB.ready;
    }

    UartTransmitter uartA(), uartB();
    connect uartA aRst, baudClk(clk115.out), data(cntA), tx(txA);
    connect uartB aRst, baudClk(clk96.out), data(cntB), tx(txB);
    PulseGen clk115(DIV = 10e6 / 115200), clk96(DIV = 10e6 / 9600);

    onehot reg cntA[%8] = {async 0 when aRst; next when uartA.wr;}
    onehot reg cntB[%8] = {async 7 when aRst; prev when uartB.wr;}

    connect SyncARst() in(! marked nARst), out(node aRst);
    DualUartTxConstraints();
    }



    and here is another example:

    # @title Stopwatch
    # @description A stopwatch with tenths, seconds, and tens of seconds.
    # @port tenths Tenths of seconds, inverted one-hot encoded
    # @port ones Seconds encoded to drive a seven segment display
    # @port tens Tens of seconds encoded to drive a seven segment display

    module StopWatch() {
    inport clk, aRst, clk100ms; startStop;
    outport tens[%7], ones[%7], tenths[%10];

    reg stateMachine[] = {
    async 0 when aRst;
    : next when startStop;
    : tenthsCnt.inc = 1 when clk100ms; next when !startStop;
    : tenthsCnt.inc = 1 when clk100ms; next when startStop;
    : 0 when !startStop;
    }

    onesCnt.inc = tenthsCnt.rollover = 1 when tenthsCnt.inc & tenthsCnt == 9;
    tensCnt.inc = onesCnt.rollover = 1 when onesCnt.inc & onesCnt == 9;
    tensCnt.rollover = 1 when tensCnt.inc & onesCnt == 5;

    reg tenthsCnt[%4], onesCnt[%4], tensCnt[%3] = {
    node rollover, inc; async 0 when aRst; 0 when rollover; next when inc;
    }

    const SEVEN_SEG_DECODE[10] = { 0x79, 0x24, 0x30, 0x19, 0x12, 0x02, 0x78,
    0x00, 0x10, 0x08 };
    tens = SEVEN_SEG_DECODE[0 .. 5] when tenthsCnt == 0 .. 5; ones =
    SEVEN_SEG_DECODE[0 .. 9] when onesCnt == 0 .. 9;
    node tenthsDec[%10] = 1 << 0 .. 9 when tenthsCnt == 0 .. 9;
    tenths = !tenthsDec;
    }


    > If you like dynamic languages (not everybody does), you'll enjoy
    > using MyHDL/python especially during verification. There you can
    > use the full power of python, which is in my opinion invariably
    > useful. Combined with a unit test framework such as py.test,
    > verification almost becomes fun :)


    I would agree with that idea - unit testing + general purpose scripting
    language as a basis for verification. I would also like a nice editor
    with auto compile (as in eclipse), oh, and with auto-completion too :)

    Regards,

    Paul.
     
    Paul Taylor, Nov 18, 2007
    #11
  12. Jan Decaluwe Guest

    wrote:
    > MyHDL looks really nice!
    > Is it possible to have in a FSM one procedure-or-function for each
    > state? It should make the program code easy to read. It will be also
    > better to have an array of functions and call them according FSM state
    > number. Do you have any idea how to implement this in MyHDL?


    Depends on what "implement" means.

    For pure modelling with MyHDL, you can use python's full power.

    For code intended for conversion to Verilog/VHDL, there are very
    severe restrictions, similar to those for synthesizable RTL code.
    (Conversion support is intended to provide a path to hardware
    implementation.) Such code will look similar to RTL code in other
    languages.

    Jan

    --
    Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Kaboutermansstraat 97, B-3000 Leuven, Belgium
    From Python to silicon:
    http://myhdl.jandecaluwe.com
     
    Jan Decaluwe, Nov 18, 2007
    #12
  13. Guest

    > For pure modelling with MyHDL, you can use python's full power.
    >
    > For code intended for conversion to Verilog/VHDL, there are very
    > severe restrictions, similar to those for synthesizable RTL code.
    > (Conversion support is intended to provide a path to hardware
    > implementation.) Such code will look similar to RTL code in other
    > languages.
    >
    > Jan
    >


    Hmm... It is very serious restriction. I did imagine MyHDL to be more
    powerful. MyHDL is just a wrapper?
     
    , Nov 18, 2007
    #13
  14. mk Guest

    On Sun, 18 Nov 2007 11:54:41 -0800 (PST), ""
    <> wrote:

    >> For pure modelling with MyHDL, you can use python's full power.
    >>
    >> For code intended for conversion to Verilog/VHDL, there are very
    >> severe restrictions, similar to those for synthesizable RTL code.
    >> (Conversion support is intended to provide a path to hardware
    >> implementation.) Such code will look similar to RTL code in other
    >> languages.
    >>
    >> Jan
    >>

    >
    >I did imagine MyHDL to be more powerful.


    That's exactly the problem. The difficulty is with converting those
    powerful semantics to RTL which is called behavioral synthesis which
    is still an open research topic in most instances. Some top eda
    companies have tried and failed in the past and now C synthesis is
    being tried again with limited success. You can't expect myhdl to
    include a top notch behavioral synthesis feature; yet hopefully.
     
    mk, Nov 18, 2007
    #14
  15. xenix Guest

    you should learn Rossetta as Well. pretty cool attempt. I am looking
    to hire MyHDL designers:p:p:p ..hehehe
     
    xenix, Nov 19, 2007
    #15
  16. On Sat, 17 Nov 2007, Filip Miletic wrote:

    |--------------------------------------------|
    |"To the rest: please don't feed the trolls."|
    |--------------------------------------------|

    Refuting can be useful.

    I apologize for provoking the original poster of this thread without
    being able to remain to participate in future parts of the thread. Some
    contributors to these newsgroups who had emailed me before this season
    had been aware of circumstances which deprive me of much opportunity
    to contribute to Usenet often. Hopefully I will be more active on Usenet
    late in Spring 2008, but I can not be sure now what the circumstances
    shall be at that time.

    I quote from an article of the ACCU UK Python Users Group entitled
    ""The sound of one coconut shell clopping"" by Paul Brian in the
    August 2002, Volume 14, Number 4 issue of "CVu" ( WWW.ACCU.org ) on
    Page 28:
    "[..]
    Where are the type declarations? Well, Python discovers type at run-time,
    [..]
    [..]"

    I quote from "Using Python's Dynamic Features to Encapsulate Relational
    Database Queries" by Richard Taylor in the December 2002 issue of "CVu"
    from Page 27:
    "[..]
    [..] Python's dynamic type system means that you can be unsure of the type
    of the variable [..]
    [..]"

    One of the main goals of static strong typing such as in VHDL and Ada
    is to detect mistakes early, especially when attempting to compile
    instead of when running (and hence crashing). Instead, in a dynamic,
    object-oriented language such as Lisp, mistakes which are trivial for
    a VHDL compiler to find crash a program at runtime. E.g. perform the
    following experiment: compile the Common Lisp program for theorem
    proving called Prototype Verification System (PVS) (e.g. if I recall
    correctly, in 2007 it took a CMU CL compiler approximately 40 minutes).
    To satisfy yourself that it is how it should be, run PVS and invoke one of
    the functions for pretty printing. Quit PVS and change only one lexical
    token in PVS's source code: change something in one of the functions for
    pretty printing such that a typing error occurs. Recompile (if I recall
    correctly, it took approximately 10 minutes for me). Run your modified
    PVS and do some things with it. Note how the error has not been detected
    yet. Invoke the function you changed, then it crashes. This is an extremely
    good advertisement against dynamic typing. I remember someone boasted
    on news:comp.lang.lisp that the advanced debugging features provided
    by a Lisp implementation in a fielded application were retained which
    made on-site debugging easy. For work of interest to me, being able
    to maintain a deployed system is of importance, but that is not a
    valid excuse for allowing errors to be present when launching
    a system into the field. I quote from "Using Python's Dynamic Features
    to Encapsulate Relational Database Queries" by Richard Taylor in the
    December 2002 issue of "CVu" from Page 29:
    "[..]
    This article has demonstrated how features such as dynamic attribute
    lookup and class definitions as first class objects can be used to build
    flexible abstractions in Python. I have used such techniques extensively in
    the applications on which I have worked. However, I have also learned
    through bitter experience that such techniques can cause faults that, because
    Python has little compile time checking, only become apparent at run time
    and can prove very hard to find. These problems can be alleviated with
    judicious use of pre- and post-conditions on methods along with careful
    use of exception handlers to recover from runtime errors.
    [..] tripped
    up by a built-in method that you have overloaded by accident. [..]"

    For Python; Eiffel; and Lisp, whitespace is significant which can
    cause trouble if a text editor which forces a particular layout (e.g.
    Pico; Nano; some of the modes of Emacs; Microsoft Edit.com; Vim if
    ai (autoindent) is set; and a text editor for VMS Notes) is used and
    a change forced by a text editor goes unnoticed.

    Python with the Stratus hardware description language has not
    displaced VHDL yet. Nor has Python with MyHDL.

    The following have been claimed to be terser than VHDL for a
    number of hardware uses: C++; Verilog; Verischemelog (I may
    have misspelt that name earlier in this thread); APL; Lava;
    Confluence; and HDCaml. How could Python even possibly
    compete with APL for terseness?

    I do not agree that conciseness is a good thing. If one sees
    an asterisk, which of Kleene closure; multiplication;
    convolution; footnote; and adjoint is denoted by the * in
    this instance? How would one check? Adobe Acrobat's search
    function can be extraordinarily slow when searching through
    a strict subset of Synopsys's documentation on a quadcore
    workstation; grep can also accept an asterisk but many
    search engines will ignore an asterisk (and just about
    every other character which is not alphanumeric). Can you
    remember which of the intervals [1,5) and (1,5] includes the
    number five? The command
    Copy Source.txt Dest.txt
    will behave differently on VMS if a file named Dest.txt
    already exists than the lexically identical command on
    MS DOS. Please find someone who knows neither MS DOS nor
    VMS and tell me if this person will correctly say without
    prompting all the possible outcomes of entering
    Copy Source.txt Dest.txt. Are you fond of the way numbers
    instead of words spelt with letters are used to select
    different integration methods in SPICE? Would you risk
    adjusting this setting without checking which numbers
    correspond to which methods?

    Please search for an old post by myself in news:comp.arch.embedded
    in which I asked a Lint user how he would prevent accidentally
    adding a value of a datatype for counting apples to a value of a
    datatype for counting oranges. How should these situations be
    handled in a better HDL to replace VHDL?
     
    Colin Paul Gloster, Nov 21, 2007
    #16
  17. Guest


    >To the rest: please don't feed the trolls.


    Yes, I think I preferred reading about MI5 persecution.
     
    , Nov 21, 2007
    #17
  18. Paul Taylor Guest

    On Wed, 21 Nov 2007 15:55:46 +0100, Colin Paul Gloster wrote:

    > One of the main goals of static strong typing such as in VHDL and Ada
    > is to detect mistakes early... <snip>


    Compiling a small program that you want to change/run is a pain, so
    dynamic/scripting languages are great here. But then for larger programs,
    scripting languages are a pain for the reasons you state. Others
    like/advocate them for writing large programs but I can't understand that.
    So I'm with you here.

    > Python with the Stratus hardware description language has not
    > displaced VHDL yet. Nor has Python with MyHDL.


    Probably nothing will displace vhdl/verilog. Just like nothing has
    and probably won't replace C for embedded programming, for example. That's
    been around for years as well.

    > I do not agree that conciseness is a good thing ... <snip>


    Of course clarity is more important than terseness - e.g some perl, yuk. A
    state machine in my other post in this thread I like - it's terse and it's
    clear and it's easy to maintain. Lets say I want to change it by adding a
    state or two, I don't need to mess around adding constants to an
    enumeration type, and changing constants around in a case statement.

    Also I don't explicitly connect clocks to registers/modules - that's done
    automatically for me, if there is a clk node in the module. I can override
    this but mostly that's what I want.

    Conciseness can be very good (if clarity and the ability to scale are not
    compromised), the language can be easier to use, and so allowing you to
    concentrate more on the problem you're trying to solve.

    > Please search for an old post by myself in news:comp.arch.embedded
    > in which I asked a Lint user how he would prevent accidentally
    > adding a value of a datatype for counting apples to a value of a
    > datatype for counting oranges.


    orangesDb.add(anApple) ?

    Ok, I know that's a contrived example, and nobody would write a line of
    code like that. But Java didn't have generics until version 5. Before
    version 5 I don't recall having an issue with the sort of problem you are
    describing. I now use generics, but not because I'm particularly concerned
    about storing the wrong type (I use sensible variable names :)), it's
    just that it's easier to use generics than not because otherwise you end
    up doing a lot of casting.

    I'm not against putting safeguards in a language. You have to ask what it
    is you are protecting yourself against, and consider what the cost is (too
    much red tape is bad). When writing vhdl I find the most common error I
    make is that when assigning to a bit vector, I sometimes get the length
    wrong, especially when slices and concatenations are involved. VHDL finds
    that problem of coarse, which is great. The language that I am developing
    has that safeguard too. I also have a marked keyword, which is a safeguard
    because sometimes I stupidly use the wrong variable, e.g. an
    unsynchronised signal instead of one that I have synchronised for use
    (especially when I come back to change some code). I also have asserts on
    compile-time config, so when I instantiate a module I find config
    parameter errors too. A contrived example:

    module ACounter(DIR = UP; SIZE = 16) {
    assert DIR {UP, DOWN, UPDOWN};
    assert SIZE > 0;

    inport clk, rst;
    outport count[%SIZE];

    reg cnt[%SIZE];
    count = cnt;

    config DIR == UP {
    inport inc;
    cnt = {0 when rst; next when inc;}
    }
    config DIR == DOWN {
    inport dec;
    cnt = {0 when rst; prev when dec;}
    }
    config DIR == UPDOWN {
    inport inc, dec;
    cnt = {0 when rst; next when inc; prev when dec;}
    }
    }

    I would be interested to know what mistakes others commonly make, that are
    found by the VHDL compiler.

    Regards,

    Paul Taylor.
     
    Paul Taylor, Nov 21, 2007
    #18
  19. In <47449ab1$> Paul Taylor wrote:
    > On Wed, 21 Nov 2007 15:55:46 +0100, Colin Paul Gloster wrote:
    >
    >> One of the main goals of static strong typing such as in VHDL and Ada
    >> is to detect mistakes early... <snip>

    >
    > Compiling a small program that you want to change/run is a pain, so
    > dynamic/scripting languages are great here.

    Think about that producing code means 80% or more testing effort. Compiling
    VHDL is really not the problem for a simulation but testing. A dynamic language
    allows you also a kind of "dynamic testing" which would speed up the overall
    process dramatically.

    You could test a function or process written in the architecture from one or
    more separate test programs with a Python like HDL language, with life inspection!
    There is nothing close to that useability in VHDL. And the code would be at
    least as readable as VHDL.

    > But then for larger programs,
    > scripting languages are a pain for the reasons you state. Others
    > like/advocate them for writing large programs but I can't understand that.
    > So I'm with you here.

    Large programs mainly benefit from a clean concept. If you don't have a clean
    concept you will fail both in a dynamic and static programming language. This
    is the main difference between small and large programs.

    If we neglect peformance issues a modern scripting language is as least as good
    as a static language. If you did all the regression tests properly you will not
    experience any surprises with e.g. Python.
    >
    >> Python with the Stratus hardware description language has not
    >> displaced VHDL yet. Nor has Python with MyHDL.

    MyHDL is a one man show. I doubt that Python is the ideal language based for
    hardware description. I believe it is possible to design a very concise dynamic
    language for hardware design. But this will significantly more than one person
    to bring it up. My impression is MyHDL is not very suitable for large projects now.
    >
    > Probably nothing will displace vhdl/verilog. Just like nothing has
    > and probably won't replace C for embedded programming, for example. That's
    > been around for years as well.

    Of course there will come something, no doubt. Hopefully it will be better...
    >
    >SNIP>
    > Paul Taylor.
    >

    Regards

    Wolfgang Grafen
     
    Wolfgang Grafen, Nov 22, 2007
    #19
  20. Paul Taylor wrote:
    > ...
    > I also have a marked keyword, which is a safeguard
    > because sometimes I stupidly use the wrong variable, e.g. an
    > unsynchronised signal instead of one that I have synchronised for use
    > (especially when I come back to change some code).


    Interesting.
    I now handle this manually by using annoying
    identifiers for the unsynch nodes.
    Maybe "run_glitchy" vs "run".

    > I would be interested to know what mistakes others commonly make, that are
    > found by the VHDL compiler.


    OK here's mine.
    I get automated mistake-finding at the
    editor, analysis, and elaboration level
    of each library unit.

    1. Emacs vhdl-mode completes keywords
    and identifiers, matches most parens
    and prompts for clauses in a keyword statement.
    This prevents most syntax errors from happening.

    2. I run simulation analysis
    vcom -c mydesign.vhd
    from an editor function key every few lines of code.
    This step finds the most errors
    but puts the cursor right on each one
    and tells me what's wrong.

    I would estimate:
    90% syntax punctuation: missing or excess : ; ) etc.
    10% static mismatch of code with local or library subtypes.
    Length, range etc.
    10% signature mismatch of code and local or library subprograms

    At the top level, Emacs vhdl-make automatically finds
    units with multiple declarations in the project path, like this:
    WARNING: Architecture declared twice (used 1.): "synth" of "cnt_decode"
    1. in "~/vhdl/play/cnt__decode.vhd" (line 18)
    2. in "~/vhdl/play/cnt_decode.vhd" (line 18)

    3. elaboration:
    vsim -c mydesign
    will find most runtime mismatches
    and give a pretty good description of what's wrong.
    Some messages are more cryptic hints at infinite loops,like
    ** Fatal: Write failure in vlm process (32,-1)

    That leaves the functional errors to simulation
    viewers and assertions, but I have no automated
    method for this.

    -- Mike Treseler
     
    Mike Treseler, Nov 22, 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. Peter Grison

    Date, date date date....

    Peter Grison, May 28, 2004, in forum: Java
    Replies:
    10
    Views:
    3,373
    Michael Borgwardt
    May 30, 2004
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    989
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,253
    Smokey Grindel
    Dec 2, 2006
  4. Replies:
    13
    Views:
    471
    Keith Thompson
    Feb 18, 2006
  5. afd
    Replies:
    1
    Views:
    8,562
    Colin Paul Gloster
    Mar 23, 2007
Loading...

Share This Page