13
\$\begingroup\$

I have absolutely no background in programmable logic, I use mostly microcontrollers in my projects but recently I needed to work with video and the microcontroller is just too slow for what I needed so I started playing with CPLDs.

I was able to get good results with the CPLD only using schematic design but when searching for info on CPLDs I came across many examples using VHDL and Verilog. I am curious about what could make me want to define my device in one of these languages. What can they do that schematic design cannot? Are they used mostly for functions?

Until now I have only used CPLDs, do FPGAs designs benefit more than CPLDs from using these languages?

\$\endgroup\$
  • 1
    \$\begingroup\$ You will probably find vendor supplied synthesis tools for both Verilog and VHDL for mainstream parts. Therefore the choice is purely opinion. I'd encourage you to look at both and decide which you prefer. Xilinx provides good examples in both languages, I suspect other vendors do too. \$\endgroup\$ – David Oct 23 '14 at 23:27
  • 3
    \$\begingroup\$ You should definitely step away from schematic capture for logic design. It feels easier at the start, but that's illusory. My $0.02 on languages: VHDL is an abomination, use Verilog. \$\endgroup\$ – markt Oct 24 '14 at 0:36
  • \$\begingroup\$ @markt, why do you think VHDL is that bad? \$\endgroup\$ – stanri Oct 24 '14 at 9:34
  • 2
    \$\begingroup\$ One could equally well say Verilog is an abomination, use VHDL. VHDL does expect you to say exactly what you want, while Verilog sort of guesses. But that's just my £0.02. \$\endgroup\$ – Brian Drummond Oct 24 '14 at 10:25
  • 1
    \$\begingroup\$ @markt, I started with VHDL so at one point I appreciated the strongly-typed-ness of it. It forced me to think about what I wanted and to create good habits when I was starting out. Now I'm way too far into the SystemVerilog camp to care too much either way, honestly. \$\endgroup\$ – stanri Oct 24 '14 at 10:52
14
\$\begingroup\$

Schematic design is only useful when you're only tying together a few off-the-shelf modules (counters, adders, memory, etc). But implementing an actual algorithm (say, a cryptography hashing algorithm) is nearly impossible to do without an HDL (like VHDL or Verilog), since there's no way to describe a system at a behavioral level with schematic symbols.

Most projects are done in behavioral-style HDL because they're too complex to be synthesized by hand and drawn using logic primitives schematically.

CPLDs are generally used for glue logic and less used for processing, and generally logic is easy to implement schematically, so I think you're right when you suggest that FPGA-based designs benefit more from using an HDL.

\$\endgroup\$
  • \$\begingroup\$ You can do very complex things in a symbolic schematic system. I would go so far as to say that anything that can be done in a HDL could be implemented in a schematic based system, albeit at the cost of maintainability. As long as the toolset can define blocks of symbols that act as a single symbol, you can do pretty much anything. \$\endgroup\$ – Connor Wolf Oct 24 '14 at 4:11
  • 1
    \$\begingroup\$ One good example here is labview. It's a symbolic programming interface where people have designed massively complex systems that automate whole factories. The end result is nigh-unmaintainable, but it's possible (note: I am not speaking to whether it's a good idea, just the basic viability). \$\endgroup\$ – Connor Wolf Oct 24 '14 at 4:12
  • \$\begingroup\$ "Most projects are done in behavioral-style HDL ..." is unsupportable and in fact is NOT how design flows work. \$\endgroup\$ – placeholder Oct 24 '14 at 15:01
  • \$\begingroup\$ @ConnorWolf Have to disagree about Labview code being that unmaintainable-- not that I'm a huge fan. There are some best practices that really help. For me, its usually the abandonment at any hope of forward or backward compatibility that causes maintenance problems, as opposed to anything inherent to the G-language ;) \$\endgroup\$ – Scott Seidman Oct 24 '14 at 16:02
4
\$\begingroup\$

A couple of practical aspects in addition to Jay's excellent answer:

  • Bugs. The schematic tools tend to be buggier* than the rest of the toolset. This is possibly due to the preference of Verilog/VHDL over schematics in the industry, and thus schematic entry is given less attention by the software developers.
  • Speed. The schematic needs to be first converted to a HDL before passing it to the synthesis tool. This can have a negative impact on build times. The generated HDL also might not be very readable if in case you need to inspect it for some reason.
  • Portability. Depending on the amount of vendor specific primitives used Verilog and VHDL are more or less portable between devices. Porting schematics you either have to redraw everything or rely on the provided import/export capabilities (if any).

*My favourite bug in Xilinx ISE was the inability to select vertical wires.

\$\endgroup\$
2
\$\begingroup\$

There are many advantages of a HDL (Hardware Description Languages) as a Design Entry standard.

The description of the functionality can be at a higher level, HDL based designs can be synthesised into a gate-level description of a chosen technology, A HDL design is more easily understood than a gate- level net-list or a schematic description and HDLs reduce errors because of strong type checking.

The hardware description languages VHDL and Verilog were designed for modelling hardware with the intention of modelling at a higher abstraction level which includes features like, concurrency, timing, hierarchy, reuse of components, state behaviour, synchronous behaviour, asynchronous behaviour, synchronization and inherent parallelism.

Issues arise during synthesis, mapping the design description to a specific process and gate implementation. This requires that you cannot use the high-level features of HDL - you must produce "synthesizable Verilog/VHDL"

So you have HDL for synthesis and HDL for Simulation and the subset that is synthesizable is tool specific.

You cannot go from a Behavioural design description to a net-list/ layout. But you can structure your design to have behavioural components that also have a synthesizable aspect that can be compared against each other. You start with the behavioural and then once that is working you rewrite for synthesis (which is a subset). You go from the general to the specific and build test-benches along the way.

\$\endgroup\$
1
\$\begingroup\$

One more advantage is that HDLs get all the same advantages as regular programming languages in that they can be used in standard version control systems, diff-ed to examine changes, etc.

\$\endgroup\$
0
\$\begingroup\$

In addition to what already have been said: text representation are simply much more more manageable, especially in large projects. You can (albeit with huge difficulties) convert any syntheizable HDL into into schematic, but hundreds of lines of plain text is easier to work with than hundreds of schematic elements.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.