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]

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!

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

With structured data types, I mean user defined VHDL types. They are reduced to multi dimensional bit-vectors in schematic entry. Entities using record types in port can't be connected in schematic entry. Create symbol file fails with "unsupported type".

[Altera_Forum]

I see. The multi dimensional bit vectors are fine, and can be easily described with generics/parameters, although you have to be careful. I use the std_logic_2D type as defined in the 'lpm' library a lot. The record type indeed may present a problem. But a record could be 'flattened' to a std_logic_vector on output and 'rebuilt' on entry? Although this may be less straightforward, I recall having tried something with records and stumbled ...

[Altera_Forum]

I too go back a lot of years and feel that block diagrams are easier to visualize. 

I just don't get why looking at a list of ports in a text file is a good way to comprehend how a design ties together. Maps technology allows me to find how to get to any place in the country Therefore it should be possible to scroll a large schematic. It is not necessary to draw lines to connect blocks on a bdf. Design hierarchies exist so it should be possible to zoom to any level as easily as scrolling to an HDL module, and when I get there a shaped symbol could instantaneously give some indication of the function rather than focusing to read always, positive/negative edge and port names that go back to still other modules and it goes on and on. Last time I looked there wasn't even a qualified naming system to make it easy to find fan in and fan out. I do think SOPC builder is great for what it does. I was around when the "Description" language was conceived because the government could not keep up with the volume of paper. Then some people who were not designers heard the term "Language" but didn't know the difference between "Description" and "Design" decided to force feed HDL to designers. That took a long time, but at least some seem to swallow it. Boolean Algebra is the way to describe logic, not a bunch of if/else/semicolons.

[Altera_Forum]

@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

[Altera_Forum]

I've seen more "spaghetti" designs using schematics that VHDL ;) 

We have a few complex designs that were done several years ago entirely in schematics, spawning aver several A3 pages with connections everywhere, and no comments. You can write bad code in any language, including graphics entry (the same applies for good code, obviously). The choice usually ends up with what you are most comfortable with (or better, what the whole team is comfortable with) and more efficient. I think that for designs that use more than a few gates or primitives, HDL code is faster to write, easier to document/comment/organize, and easier to maintain.

[Altera_Forum]

Those (several A3 pages long schematic designs) sound like the equivalent of a program consisting of just one function of several thousand lines long. 

 The summary/consensus which I seem to hear here is that parameterisation support in schematics is bad to non-existent, and that there is no consistent schematic-fileformat with which to exchange designs between tools/vendors. Other than that, navigating and/or visualising a properly hierarchical/modular schematic design (possibly using HDL in some/all of the leaf-modules) would be better than using straight HDL only.  Overall, it helps me understand the (to some extent) sorry state of affairs around the available design tools currently.

[Altera_Forum]

The statement below is not generaly true. The hardware description will be more concise than the schematics. If written well it will also document the design well. 

   --- Quote Start ---  Those (several A3 pages long schematic designs) sound like the equivalent of a program consisting of just one function of several thousand lines long.  --- Quote End ---     Usually you will get a pile of A3 pages of schematics for "one function of several thousand lines long". I think you do not mean a "function" but a "module" or an "architecture".     --- Quote Start ---   The summary/consensus which I seem to hear here is that parameterisation support in schematics is bad to non-existent, and that there is no consistent schematic-fileformat with which to exchange designs between tools/vendors.   --- Quote End ---     This is true. There has however been work on defining schematics in iterative and recursive ways in academia. But only the simple busses have survived the real world of electronics design.     --- Quote Start ---   Other than that, navigating and/or visualising a properly hierarchical/modular schematic design (possibly using HDL in some/all of the leaf-modules) would be better than using straight HDL only.   --- Quote End ---     In the assumption of well written HDL I do disagree. Schematics get very complex at some time and can be hard to draw and update for complex systems. Well drawn schematics take much more time to make and maintain.   In any case you can always generate schematics from your HDL e.g. by Quartus II tools such as RTL-viewer

[Altera_Forum]

I used a bdf and Megawizard for a design and got the benefits of the libraries without writing HDL at all. Then after compiling/synthesizing found that the netlist viewer showed the gory details in a giant "schematic". So the concerns about the volume of paper are greatly exagerated, just think of e-paper and netlist viewer. I never completed the design for other reasons, but I am convinced that schematic entry worked on I think Quartus 9.1. Since the lpm blocks seem to have disappeared in the last release, I am no longer a customer. 

HDL is a force fit and I am thankful not to have been brainwashed into believing in it.

[Altera_Forum]

--- Quote Start ---   HDL is a force fit and I am thankful not to have been brainwashed into believing in it.  --- Quote End ---     HDL's can NOT replace a designers insight into what circuits he/she intends to generate. HDL is "bull**** in bull**** out". You have to know what you are doing when writing VHDL or Verilog, you have to know what kind of circuit the synthesis tool will generate for you. If you do not know that by any approximation, then most often the circuits that you generate will be very complex and inefficient.    The Quartus manual helps to introduce this insight.   An other way to learn this insight is by regularly looking at the RTL Viewer to see what circuits are being generated.

[Altera_Forum]

--- Quote Start ---  Usually you will get a pile of A3 pages of schematics for "one function of several thousand lines long". I think you do not mean a "function" but a "module" or an "architecture".  --- Quote End ---    What I was referring to was in terms of regular software(programs).

[Altera_Forum]

--- Quote Start ---  What I was referring to was in terms of regular software(programs).  --- Quote End ---     In that respect you are perfectly right!

[Altera_Forum]

I am somneone new to this game. I started VHDL 6 years ago during my degree course as part of my final year project. Now in industry, we use simulink, and there is pressure from above to use simulink for all new designs. 

 I have spent a year trying to use simulink's HDL coder, and finding it has many limitations over hand coded VHDL. It appears to be good if you dont mind it sprawling itself all over some big FPGA, but when you are limited to a specific FPGA from the start, where 90%+ is going to be used up from an efficient design, code-generationg isnt really suited to the job. Simulink is great as a verification environment, but hasnt proved itself to me as an efficient implemenation tool.  I have also battled through some more legacy designes done here with a mix of AHDL and Quartus scematic entry. These are probably examples of bad coding in any language, but having to follow signals around to see what they actually do, with little documentation, is not much fun. Then you have bits tacked on the design with comments like "equalises pipeline delay", without refering to what it is equalising with.   One strength in VHDL I have loved recently is it's ability to cope with complex types and ports to minimise the port connections.  I have the following record type:   type subband_t is record data : sfixed(12 downto -4); valid : std_logic; pos : pos_track_t; end record subband_t; type subband_array_t is array(0 to 31) of subband_t; signal subbands : subband_array_t; .....then in the port mappings: port map ( subbands => subbands, ... ); Is about as clean as it gets, inside VHDL or schematic.    And to top it all off - at the end of the day, I dont need a $2k/5k/10k licence to edit my text files!

[Altera_Forum]

Stephen, 

 I wouldn't let me scare off too much by Daixiwen's experience. If you plan carefully (as anyone should do whatever design method used) you can develop a nice top-down viewable bottoms-up designed system.  The only restriction on ports in the BDE is that they must be either std_logic, std_logic_vector or std_logic_2D. And I haven't managed yet to pass an array of integers in the generic/parameter section. Connecting record ports like Tricky (and FvM) want is not possible, A workaround is to 'flatten' the record into a std_logic_vector and std_logic_2D in the case of an array of records. I can understand why one wants to use records, saving time typing in all those intermediate signal names. Where in a schematic all you have to do is to draw a wire or a bus.  If you really need to 'switch' between vendors you should look into Altium. Their schematic editor seamlessly transitions into FPGA-design, and they support Altera and Xilinx (possibly others too).

[Altera_Forum]

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!

[Altera_Forum]

Basically Daixiwen perfectly summarized by point of view, so I don't feel a need to contribute more detail arguments. I just wanted to add comments to two points I mentioned before.  

- Data structures. I don't think it's a good argument for a "4th generation" language, that everything can be flattened. Yes it can. It's the same in Verilog. Fortunately System Verilog also supports structures. - Vendor tool dependency of schematic entry. Even if you are effectively bound to a single vendor, you'll feel uncomfortable with this situation, I think. You can't navigate a hierarchical design without installing the schematic editor, you can't give it to a customer who is not sharing the tools.