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

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

KJ

Ever heard of verilog ?

It's a bit more like c - you can write very concise code, or you can make a real mess...

Ok, in that case start writing your VGA controller in Python, then go to

synthesize it, download it on an FPGA prototype board and report back to us how incredible simple and quick it was.... :-)

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

Hans

A reminder : VHDL is not a programming language, thus implying you do not write a program with VHDL.

In news: snipped-for-privacy@b32g2000hsa.googlegroups.com timestamped Fri, 16 Nov 2007 10:27:59 -0800 (PST), " snipped-for-privacy@googlemail.com" 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?

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

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

f

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

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)

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 If you like dynamic languages (not everybody does), you'll enjoy

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.

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

Hmm... It is very serious restriction. I did imagine MyHDL to be more powerful. MyHDL is just a wrapper?

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.

Try putting Python and MyHDL on your CV/resume instead of VHDL o (System)Verilog and see how many job offers you get... ;-)

As and when (potential) employers adopt more modern developmen methodologies, then so do/will I.

you should learn Rossetta as Well. pretty cool attempt. I am looking to hire MyHDL designers:P:P:P ..hehehe

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" (

) 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?

Well refuted sir!

A great advantage of VHDL's strong (compile-time) type checking is that i much reduces the need for a linting-type tool. Reading some styles of code however, indicates that it does not eliminate it, however! ;-)

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.

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 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.

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.

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.

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.

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.

Of course there will come something, no doubt. Hopefully it will be better...

Regards

Wolfgang Grafen