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?

Maybe we should try to avoid terminology like inferior and such, as the discussion may become 'religious' ... It is somewhat analogous to text base configuration files (as always available in Linux) and GUI programs (like the Registry under Windows). Both have their followers. If we look at e.g. Altium en Orcad ( I know a bit of both) you have the possibility to design FPGA code by schematic entry. (Altium claims this is the best thing since sliced bread ...) Back in 2000 when we started with Quartus I used the BDE but it was buggy, so I reverted to text entry (then in AHDL). Lately I regained interest in the BDE, mainly because of the hierarchical view it offers. We have developed a suite of building blocks which we can combine very intuitively in a schematic (following the left to right approach you mention). If we do this in e.g. VHDL we end up with a lot of text to describe essentially simple wires or buses. Eventually the lowest levels of the hierarchy will be HDL text files as this is the convenient way to describe complex logic, but that is the fun part!

BuGless: the question you are raising would best be answered if you would design a similar system using schematics or using a HDL (like Verilog or VHDL). The time that you would spend in the design would be much longer. Several high level constructs in a HDL are synthesized in hardware blocks for you. This would require a lot of work doing it each time in schematics. (You could make use of some predefined schematics or module generators, but these are far from being standardized over providers). In HDLs it is easy to parameterize modules. In schematics except for simple bus structures parameterization is nearly non-existent. Updating of a design made in schematics is much harder than in a HDL. In a HDL you only have to update a few lines of code. In schematics you have to update the placement and wiring in a drawing which can easily clutter your overview. This usually takes much more time. HDLs are definitly much higher level and more productive than the schematics that you used 20 or 30 years ago. HDLs like VHDL and Verilog can be used, and if carefully designed ported, over a wide range of design platforms such as Quartus, Xilinx ISE, Synopsys, Mentor Graphics, Cadence, LeonardoSpetrum etc... With schematics you are usually hooked up to one system. A higher level of productivity in designing bus-oriented oriented architectures can be obtained by using tools such as "SOPC Builder" in Quartus. This is a graphics GUI that enables you to design bus-based systems in a very efficient way. The efficiency is obtained by the provision of a extended library of IP modules. If you adhere to the Avalon bus standards, which is not that difficult, you can also add your own modules. The SOPC system implements for you the interconnect of the busses, the placement of components in the address spaces of the busses, the bus arbitrations etc... This tool is of course much higher level than schematics. It also provides a high productivity increase during design and is very useful. The drawback is that it is limited to one design environment and platform. There has been already a few decades of research effort in "further generation" languages/environments often called "high level synthesis, behavioral synthesis, system level synthesis...", some with schematics input or representation. Unfortunately, I do not know very much people or organizations that have actually used them. This is mainly because the underlying assumptions for such systems are too constraining. I invite other people on the forum to inform about real succes-stories here, that still live on today and outside an academic research environment For restricted application areas the above mentioned higher level design methods have found a practical way out. This is especially the case with DSP (digital signal processing). A number of succesful tools are coupled to a high level graphics interface. Systems making use of a high-level schematics for the design of DSP systems are: "DSP-Builder" of Altera and "System-Generator" of Xilinx. so far my 5 cents...

--- Quote Start --- BuGless: There has been already a few decades of research effort in "further generation" languages/environments often called "high level synthesis, behavioral synthesis, system level synthesis...", some with schematics input or representation. Unfortunately, I do not know very much people or organizations that have actually used them. This is mainly because the underlying assumptions for such systems are too constraining. I invite other people on the forum to inform about real succes-stories here, that still live on today and outside an academic research environment For restricted application areas the above mentioned higher level design methods have found a practical way out. This is especially the case with DSP (digital signal processing). A number of succesful tools are coupled to a high level graphics interface. Systems making use of a high-level schematics for the design of DSP systems are: "DSP-Builder" of Altera and "System-Generator" of Xilinx. --- Quote End --- The trend to market tools for automated hdl(design acceleration) indeed started a decade or so ago with claims that were proven to be false. In fact, xilinx initial blockset turned out to be a backward approach towards schematic ! Currently, the universities are flooded with cheap promotional design products while the industry remains on the watch. Few attempts at their industrial use have been made and the verdict is that it may work for some tasks but produces unmanagable code. The idea itself is still questionable. Can we really have a tool that will design from higher abstraction in a multitude of applications, variations, modifications, secondary costs ..etc. The other question is that if the produced code is unmanagable why not then just abandon hdl and design straight from software to fpga bypassing hdl. surely some tasks in hdl that may take days may be finished in few seconds in software. This is the major hdl drawback. At the moment, I believe some companies considered acceleration tools seriously for designs that were deemed to be impossible to be done by human. Let us not mix up between code created by these tools and code generated by "others" e.g. IPs or legacy work or your friend's module. In this second category the code is simply done by a designer or a specific tool subset that is well tailored for its purpose. Surely IPs are very useful in the industry.

According to my experience, graphic programming tools, that look intuitive and powerful at first sight turn out to be somewhat limited and long winded when using them for complex designs. I got basically the same impression with tools in different application fields, e.g. Agilent VI (test and measurement) LabVIEW (test and measurement) Matlab Simulink (system modelling and simulation) Quartus BDE I think, the most serious restriction is, that the schematics can be only viewn completely with the original software tool. The printouts (if you have sufficient free space around your workplace to place them) except being unwieldy are hiding important details. Small designs can be entered quickly, with growing complexety, the effort to copy, arrange and connect blocks increases enormously. And clearness fades. Regarding Quartus schematic entry, the missing support for structured data types is a sufficient reason not to use it for my designs. Finally. To deserve the name "4th generation language", schematic entry would need a portable and standarized file format (may be XML) that allow full exchange between vendor tools.

Exchange between vendor tools is and always will be problematic. They all claim to support exchange-ability but in essence they all want to lock the customer down. So that leaves the 'text' format as the common factor if you want portability. Anyway most of us have chosen to use (only?) Altera, and most of us have no real interest in portability towards other vendors, I presume. The BDE is a carry-over from the MAX-II software and it looks like it hasn't evolved much over time. But it looks very usable. In my work I am constantly drawing 'schematics' on paper interconnecting building blocks, which I translate in VHDL text later. Further on in the development cycle these handmade drawings have to be redone in electronic format to document what has been built. I gather the .bdf files could serve both purposes at once. FvM's remark on Quartus BDE missing support for structured data types may be truly valid. I looked on the web for "VHDL structured data types" but couldn't find much, can you give us an example on this? (we'll learn something ...)

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

69 Replies

Altera_Forum
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
--- 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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
--- 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
Honored Contributor
15 years ago
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...

Forum Discussion

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

69 Replies

Recent Discussions

Quartus 13.1 including Signal Tap License

how to reduce clock skew between synchronous clock

I do not get an eMail with the generated license file

Installer cannot establish connection with SSL error

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG