Schematic entry (4th generation) vs. VHDL/Verilog (3rd generation)

[Altera_Forum]

Over the past 30 years I've seen languages come and go. I started programming in assembler, and have since graduated to many 2nd and 3rd generation languages. I tend to shy away from 4th generation tools because I dislike graphical interfaces during programming. Meanwhile the world is going wild using ever more graphical tools to describe processes to make it easier to model/manipulate/program. 

 Enter the electronic design world. I've designed (mostly digital) circuits in the eighties, using schematic entry. Then I return to digital design these days and find that schematic entry is frowned upon, and using VHDL/Verilog is deemed "more professional".  Can someone explain to me why schematic entry (which, from a pure programming standpoint could be considered a 4th generation entry-tool) is considered inferior to VHDL/Verilog (which, from a pure programming standpoint, could be considered 3rd generation entry-tools)?  I've looked at VHDL/Verilog, and even though they work for me, I find that they make it more difficult for me to envision (gate)delay characteristics and clock domains than when I'd use schematic entry/building blocks. Schematic entry supports a fairly straightforward left-to-right/top-to-bottom processing workflow; VHDL/Verilog however tend to result in spaghetti-like codeflows (because of the parallel nature of the hardware description), which makes design errors more likely... Unless, someone is able to envision the schematic equivalent in his head while kranking out VHDL, but then using VHDL is more of a nuisance than an advantage.  VHDL has its place for complicated table driven logic which isn't easily described in functional blocks, but other than that, it makes it more difficult to envision the hardware equivalent than using schematic entry and thus hinders productivity.  Could anyone more proficient than I am in VHDL/Verilog, comment on my assertions above?

[Altera_Forum]

I have many boring reasons why that pie in the sky ain't gonna happen. Meanwhile, back in the real world: Aside from all the other engineering aspects of a design, I see the logic as control and data flow (so what?). There are not too many data flow functions, so the Wizard can pop out pretty much what is needed. 

 But the control logic has so many paths, it's random, has setup/hold times, fast paths, slow paths, needs optimization, Why it's Hopeless! But in the days of TTL, you could throw in a rom/eprom, whatever and every Boolean function was done in the access time of the module.  Happy days are here again, there are a lot of embedded memory blocks available, so we take a fairly simple program to parse the control logic expressed in Boolean format, load up the memories and go. If the HDLers can string a bunch of if/elses together, they must be trainable to string AND/OR/NOT to express the same logic.  The memories are so fast that they probably run at twice the data flow rate. All the concern about timing and routing of control logic kind of evaporates.

[Altera_Forum]

Well it seems that the religious war started ;) 

I do agree that schematic entry is nice, and can be used for simple designs with logic gates or megafunctions but it can become complicated very fast. Of course my example was an extreme one, and could have been split in several small modules, but I'm not sure that the end result would have been easier to maintain. I find it more difficult to understand what is happening in there.  I recently designed an Ethernet router in VHDL. It is complete with a routing table, automatic update and a fast look-up function. It also has a management interface for a NIOS processor. I can't begin to imagine how I would design such a system using schematics entry. It is split in about a dozen modules, thousands of lines of code, and almost 50% of the lines are comments. I use redefined types for almost all the signals and variables, and use records to regroup together what needs to be regrouped. I hope that I made the code readable and maintainable enough that when someone else will need to look into the code and change a few things in 6 months/1 year/2 years he'll be able to do it without my help (and without me having to remember what I did ;) )  Yes HDL has its flaws. I hate some of VHDL's "features" that require me to write more lines than I think I should. But I think that the graphical tools still need to evolve a lot before they could be called one generation above HDL. And standardization between manufacturers would be necessary before it would be accepted in the industry.

[Altera_Forum]

Schematics are not a replacement for HDL, but an augmentation! 

If you design the top levels in schematics you have documented the flow. 'An image is worth a thousand words'.  Of course one cannot design such a elaborate project as you describe schematically using low level components such as gates and muxes etc. That reminds us (at least me) of the days of TTL MSI components where it took months to design what we now do in days or even hours using HDL.  Using schematics may make us think more about re-usability as well as every HDL file represents a 'component'. I agree that the use of records is a nice feature and that this is a show-stopper severely limiting the BDE. Too bad Altera hasn't developed this tool further. Adding a 'record' port facility to the BDE should be very easy as a record signal can be treated as an 'opaque' signal and can be represented by a simple wire - no range checking needed?

[Altera_Forum]

I used schematics entry as the top level files in several projects, and liked it, but I dropped it for several reasons:[list][*]as you say, you are limited to standard types and can't use records[*]each time you change the interface on a component (and this can happen a lot with tools like SOPC builder) Quartus messes up the automatically generated symbol and you need to wire everything again. In an HDL top level file it's just a few lines to modify to reflect the change[/list] 

Besides, I don't like the convention to regroup all inputs on the left and outputs on the right. I prefer to regroup my ports by interface or function, not by direction. But I know that not anyone agrees on this, and this religious war can wait for another thread ;).  I agree that having a graphics top level file would be very good and easier to see than HDL, but the current tools aren't flexible enough for that IMHO, and lack the portability from one tool to another.

[Altera_Forum]

I don't see any religious war going on, yet :)  

 I personally also like my ports to resemble the flow from left to right as well. Fortunately (?) I'm not using SOPC Builder (yet) so I don't have to rearrange the pins that often. Schematic design isn't high on Altera's priority list, I presume. Because it is not 'cool' any more ?

[Altera_Forum]

--- Quote Start ---  I agree that having a graphics top level file would be very good and easier to see than HDL.  --- Quote End ---   Easy to see, yes. But what about a top entity port with hundred and more individual functional pins (not busses)? Do you want to place them manually? In a HDL design, you can copy them from a spreadsheet.

[Altera_Forum]

I have trouble visualising over a hundred individual pin names. 

You could place one pin (per io type), fill in a placeholder name that covers the longest name in your pin list and then copy/paste. You can then edit the saved .bdf as you would edit a HDL file. After that however you have to position the pins manually in the BDE.

[Altera_Forum]

I think there is more agreement than I expected. Also think it's time for me to go away, Thanks to all. Here are some things I will ponder. 

1. What is the first step in a design documentation? Block diagram? HDL code? 2. One complex design has thousands of LOCs .. half of which are comments to explain the verbose HDL. 3. HDL should be used because the vendors support it better. Why? The tools are built by software types that only understand if/else. 4. If I want to use Boolean for a control condition if(a==1 && b==0 || a==0 && b==1) then s = 1; ... if(a^b = 1) then s = 1; ... s = a^b ... ??? 5. How many times should I specify that the always block is triggered with the clock edge even if there is only a single clock and trigger type in the whole system? Naw ... I cannot even list the questions, Goodbye everyone!

[Altera_Forum]

--- Quote Start ---  I think there is more agreement than I expected. Also think it's time for me to go away, Thanks to all. Here are some things I will ponder. 1. What is the first step in a design documentation? Block diagram? HDL code?  --- Quote End ---    No need to despair. Your input is appreciated and you raise (very) valid points. As an experienced software programmer I can tell you that I think in block diagrams long before writing any code. So following that analogy it is not very strange to do the same when designing hardware.  The foremost reason to use HDL instead of schematics seems to be because the currently available schematic tools are lacking in scriptability/parameterisation/support of advanced datastructures/interchangability between vendors. All these things could be fixed, but progress in that direction has been fairly limited so far. It's just a matter of (collectively) pushing in the right direction.

[Altera_Forum]

I am happy to discover a lot of pragmatic comments in the discussion. 

But I also remark some religious belief popping up now and than. It is of course very good to believe in a brighter future and this will of course definitly happen.   The discussion of the search of a higher level GUI / schematics / HDL / you name it design entry system in this thread is interesting.   Because designing circuits at the basic schematics level is too complex, and there seems to be an impression that writing Verilog/VHDL (RTL Synthesis) is apparently too low level, there is a desire for something better.   @BuGless when I read your name: "bugless" I think of designs without bugs. This also reminds me of the large academic research community in formal methods (in software), but also in hardware. Your initial question in this thread gave me the impression reminded me of students searching for a good thesis topic in these areas to make the next quantum leap in design representation and methodology.   More than 30 years of research has been dedicated to the "holy grail" of the next level design representation and synthesis, beyond what is currently available in RTL Synthesis (like the standard Quartus II and comparable tools). The aim being to start simply form algorithms described in high level languages C, C++, Java, LISP, Java, or graphics representation ... and automatically generate the hardware. This has been termed by many different names like high-level synthesis, architectural synthesis, behavioral synthesis, ESL (Electronic System Level) etc...   For an overview of the state of the art of 22 years ago you could refer to the paper:   m.c. mcfarland, a.c. parker, r. camposano, tutorial on high-level synthesis, proc. 25th design automation conference, pp.330-336, june 1988, california (http://homepages.cae.wisc.edu/~ece734/references/tutorialhls.pdf)   which already included nice prototypes that make a next step in comparison to what is available in the current RTL synthesis tools like they are available in Quartus-II, Design Compiler, LeonardoSpectrum, Xilinx ISE etc...   The aim of these tools is to start from a high level algorithm described in a formal representation and to generate an architecture (not directly gates!). The architecture consist of data path operators (ALUs, multipliers, functional units, square root operators, register files etc etc...) interconnected with dedicated bus structures. So depending on the amount of arithmetic that you are requiring in your algorithm and the frequency at which they are expected to be used in your algorithm, given the capabilities of your hardware implementation technology, these tools aim to generate dedicated architectures for your application. This can be with optimization constraints such as cheapest, fastest, lowest power etc...   Given such dedicated data path architecture the algorithm has to be executed on this architecture by generating a schedule, a sequence in time how all of the processors/data path operators are sequencing and cooperating together. From the datapath and the schedule controllers can be generated. The output of such high level synthesis could be Verilog/VHDL code as input to regular RTL Synthesis (like e.g. Quartus).   Besides academic tools also several commercial tools have been made available. Synopys Behavioral Compiler being one of the most publicized. Although several companies have seriously investigated the use of such high level tools, I have not seen adoption in real industrial design flows.   Most of the examples where beautiful tradeoffs between hardware usage and thoughput are demonstrated are regular designs such as FFTs, DFTs, correllators, convolutions etc... But these things are, given insight in the problem, also not that difficult for designers to directly code in RTL. Directly translating algorithms from C into hardware require much more insight in the problem at hand to implement it in an efficient way, and up till now I have the impression that inteligen human beings, still do a lot better than tools in this respect. Design cleverness and design intention is not always easily discoverable from whatever C-code that is acceptable on every Von-Neumann machine.   Is all of this work of more than three decades useless? I would say no. Useful aspects of this research has found application in e.g. in Quartus tools such as C2H and also DSP-Builder. These tools allow you to make a tradeoff between hardware utilization and throughput. DSP-Builder also provides a Matlab Simulink design entry.    For those interested in experimenting with high-level / behavioral / architectural synthesis. The GAUT tool ( http://lab-sticc.fr/www-gaut/ ) from Université de Bretagne Sud is a free open-source high-level synthesis tool that starts from (a subset of C) and generated VHDL RTL level code, also for Altera FPGAs.   So far my 3 cents...

[Altera_Forum]

You mentioned 30 years, I wrote my first logic simulator about 1970. And would like to offer something more than rhetoric. First I refer to "a new processor" thread I started in about February. I used embedded memory clocks, an adder, comparator, a few counters all entered on a .bdf. A string parser generated memory loads for the microprogrammed engine that ran the C code. There is no intermediate or typical machine language because the if/else/for/while things are directly implemented. kaz, a guru, and I had some exchanges and he cried a lot about the plight of the designer being at the mercy of what is available, but that he would never consider using someone else's design. No other replies.  

I proposed a prototype Verilog simulator that parsed and evaluated code directly without the costly compile/synthesize/rtl process that takes so much time for function simulation. Vaughn, the head of Altera programming thought it was too much like System C. I have a working logic simulator that uses a clock definition for each clock domain in the design so that the registers following the clock def are controlled by that clock. Statements similar to C conditional assignment contain the Boolean control and the data flow operators for each register. This forum is probably nit the place, but I am willing to at least put up some demo/prototype code. Any interest/suggestions (including FUGGIT ABOUT IT) are welcome. PS There is a trend to use embedded processors when the complexity taxes the limits of HDL so I wonder if the thousands of lines of code and comments project could have used a processor? Of course that usually means programming in C and the pointer arithmetic and memory leak problems surface. Well Google has a new language, Go, that eliminated pointer arithmetic and has some other good features although it cannot handle memory mapped IO because it cannot access hardware. Sounds like a an opportunity to define a variation for use in embedded.

[Altera_Forum]

--- Quote Start ---  This forum is probably nit the place, but I am willing to at least put up some demo/prototype code. ... Well Google has a new language, Go,  ... Sounds like a an opportunity to define a variation for use in embedded.  --- Quote End ---    Alas, gone are the days of USENET where I could reply to this and redirect the followups to a different newsgroup. Anway, this is indeed starting to stray from the forum focus; I suggest you pick one of the more appropriate Altera Fora to start up this discussion instead.

[Altera_Forum]

http://mysite.verizon.net/vzeosqt4/embeddedcengine has demo/example downloads that I think will run and show at least the concept. The number of cycles and 200 Mhz clock are the key points. 

I see no appropriate forum to use for further discussion, and I am not a website designer so cannot take that route. Tried open source, but don't have skill to handle a repository. I would like to make one last point. Schematics have not gone away they are called rtl/netlists or whatever and the process of starting with HDL to compile and synthesize is really a slow process to draw a schematic. Programming in general is to solve a problem in sequential steps, which is not the way chips work. Therefore Verilog has the always block to pass the parallel function on to RTL, but it is a description language rather than an application language and that is why designers are using embedded processors to provide application function, it is not to implement complex hardware functions .. they are still combos of and, or and not. That has been the case until now and for the foreseeable future.

[Altera_Forum]

It sounds like a religious war, a lot has to do with tool support and the different vendors. 

But before we throw our hands up and surrender, I have a scenario based on things I have first hand knowledge about. In the 1980's IBM was the largest manufacturer and user of semiconductors. The mainframe design methodology had a logic design phase and a physical design phase. The hand drawn logic was manually translated to text so the automated logic diagrams could be printed on a line printer that had some special graphic characters used to draw lines. What's the point? Hardware used logic gates to do logic, programmers understood if/else kind of things, everyone knew that a series of if blocks could represent an and block, so there was a common way to communicate logic. The hardware was put into flow chart format that made sense to the programmers. An algorithm was invented for a simulation program that did cycle simulation, and the logic was in a form that could be stored on a computer. That format became the basis for VHDL. And yes, that was a big deal. Remember there was a logic design phase? I was overlooked when all the attention was focused on the new thing. Today the design is compiled to rtl in order to be simulated in the process it is analyzed, synthesized, placed, routed, timing analyzed, and then simulated(there may be some shortcuts, but not obvious) Logic design is an iterative process(it evolves) so this process is repeated over and over. And synthesis helps by throwing away logic that does not drive IO. IO assignment should be a part of physical design. I am getting to the point that there are HDL standards, but there should be tool standards, then you could switch vendors.

[Altera_Forum]

--- Quote Start ---  @SimKnutt,  You forget that one of the biggest reasons for creating VHDL/Verilog was ostensibly to get a bunch of S/W people coding H/W designs. That, at least, was the "pie in the sky" vision being pitched by Cadence 10+ years ago. The tools, especially synthesis, have evolved at a much less than stellar rate (being kind here).  With parallel software coding becoming a required skill, perhaps things will get better. I sure hope so!  Cheers,  --slacker  --- Quote End ---    Everything I have seen goes back to variable assignment which is a small subset of what needs to be done. The decision(control logic is what uses the most time but does not benefit. C2H is for optimizing computations. The high level synthesis (systemC?) stuff focuses on computation. Probably the classic boon-dogle was IBM's Stretch where pipelining and look-ahead was invented. It could not get out of its own way when someone fed it a program with conditional branches every few instructions. Of course many think that pipelining is great because of the high clock rate. Generally it uses a lot of power and extra registers that do not significantly increase overall performance. The kind of thing I focus on is getting the two operands necessary for a typical operation. The true dual port ram(3port) is my favorite. Only 2 are needed and they can be accessed very quickly in any combo. No routing, placement, wiring stuff, or timing. This is the kind of parallelism that works and has nothing to do with what the program is trying to do. Works for compares(decisions) as well as assignments.

[Altera_Forum]

--- Quote Start ---  I also forgot to mention the difficulty simulating schematic designs. Its fine just using the "convert to HDL" feature, but what about when I want to test a design in isolation using models for other design parts for extra speed of simulation?  and also what happens when a company drops support for some schemtic elements, or schematics altogether (like the LPM library in quartus schematics). You're stuck using an old version, or if a company goes bust - no software at all!  --- Quote End ---    An open core project may remove the dependence on vendors and provide a tool for the front end design. It would also be a cooperative effort where users could get involved in defining the tool, rather than sitting back and whining when vendors don't come through.  This site has a prototype/demo simulator and logic for a simple ring test case. As fast and simple as I can imagine. http://mysite.verizon.net/vzeosqt4/booleassignexpressions  I think getting some quick simulation is valuable to at least get waveforms for documentation.   Also it should be rather easy to text edit the input to run part of the design at high level and another part at detailed level which I think is your first question. I have not tried to do that, though.  The rest of this is some random thoughts and a sketchy explanation of the syntax.  We really do not need a .bdf, but some kind of block diagram is useful to show the functions in a thing. Things are made from other things in a hierarchy. Things have names and qualified names are used to navigate hierarchies. Things can store numbers, manipulate pairs of numbers, can be triggered, and the triggering can be conditional. The conditional input can come from a network of and/or/not blocks, a series of if/else statements. It could also be Boolean Logic. Boolean is text, concise and easily evaluated.   Chips are clocked and each clock has its domain. Organizing design input so that all the blocks triggered by the clock maybe enclosing in curly braces, is analogous to a block of code following an if statement is more concise than specifying the clock over and over for each always or block input. Here a '\' designates a clock def.   Arrays and bit fields use square bracket as hdl's do.  Suggested syntax is reg_name : value ? condition reg_name is a register, counter, array if reg_name[address], shift reg, or bus etc value is a number, reg_name, bus name condition is a Boolean combination of signals which may be reg bits, etc  Using block_name._reg_name for a hierarchical design seems useful.  Signals use a leading underscore in the name and are evaluated when used.  // comment clk.0 @ 0.2 // set to 0 at time 0 repeated at intervals of 2 clk.1 @ 1.2 // set to 1 at time 1 repeated at intervals of 2 == oscillator \c1?!clk c1 is a two phase clock with phase 1 driven by the clk oscillator. \c2?1 // c2 is phase two(hot, always true) so the din immediately appears at qout // Allows various clocking schemes, this example is a single phase, logically

[Altera_Forum]

What you are suggesting sounds a lot like AHDL.

[Altera_Forum]

Might I also add the use of source control(svn, vss, cvs,...) is a lot easier in text based designs rather than altera schematic files.

[Altera_Forum]

--- Quote Start ---  Might I also add the use of source control(svn, vss, cvs,...) is a lot easier in text based designs rather than altera schematic files.  --- Quote End ---   I do not have enough savvy about source control, think I fumbled with Tortoise Hg, Had trouble with svn. Welcome your help if we can get going on open source. Thanks.

[Altera_Forum]

--- Quote Start ---  What you are suggesting sounds a lot like AHDL.  --- Quote End ---   And, did Altera drop it for lack of interest? I don't know AHDL and cannot offer any worthwhile comment. Just a logic/systems guy that can put together some code and get it to run. Would like your comments, especially if the similarity is undesirable. Thanks.

[Altera_Forum]

--- Quote Start ---  Might I also add the use of source control(svn, vss, cvs,...) is a lot easier in text based designs rather than altera schematic files.  --- Quote End ---   .bdf and .bsf are text files too. Of course a diff of them will be a bit harder to read.