lordbubsy:

I have been following your progress on the forum. I noted EEyE putting me forward as a Verilog expert. That's flattering, but not entirely accurate. I have been using HDLs for 30+ years, and actively working in Verilog for the past 10+ years. I have a strong preference for ABEL, CUPL, and AHDL. (not A Hardware Description Language, but the Altera Hardware Description Language derivative.)

There are a number of reasons that I prefer these HDLs over Verilog and VHDL, but the primary reason is that they were specifically designed to implement logic designs. ABEL, CUPL, and AHDL specifically target logic implementation as their primary objective and provide clear, direct language structures for accomplishing this task. Simulation is a secondary objective, and for this task they can best be described as having limited capability.

Thus, the problem that newcomers need to avoid when attempting to learn Verilog, or VHDL, is becoming frustrated by the lack of clearly defined language structures for logic implementation and for simulation. That is, the same basic language features are applied to both situations, but the underlying HW can only support a small subset of the language. This subset is known as the synthesizable subset.

An unfortunate situation arises in virtually all tutorials related to the teaching of Verilog and VHDL, and it is that these languages are generally taught as a whole rather in two parts: (1) synthesizable subset, and (2) non-synthesizable subset. Since you seem to have some experience with ABEL, the approach I would recommend for you is to focus your efforts on reviewing examples of Verilog code put forward as synthesizable. This approach should allow you to bypass most of the frustration you may encounter in trying to separate the synthesizable and non-synthesizable subsets of these languages.

BigEd and EEyE will now probably roll their eyes as I continue. I have expounded (soap box style) on this particular point in other threads in Programmable Logic topic. Verilog and VHDL are HDLs. The operative word is Description not Design. This means that the primary objective of these languages is to describe the behavior of HW for the purpose of testing or simulation. To that end, they are very good. But to use them effectively for "Design" you are going to keep in mind their original intended purpose.

In Verilog the original purpose was satisfied by establishing two very important concepts that are referred to by two mnemonics with vastly differing connotations to practicing engineers. The first of these concepts is the concept of a signal that does not retain/hold its value. The second is the concept of a signal that does hold its value. In Verilog, the first concept is known as a "wire", and the second concept is known as a "reg".

For a practicing HW engineer/designer, these two concepts are easily grasped from a simulation perspective. But in general practice, "wire" is generally thought of as an means of conducting current from one node to another. In your mind you can use the Verilog "wire" concept for that purpose but that is not the language's concept of a "wire". Similarly, a practicing HW engineer/designer will associate the Verilog "reg" with a flip-flop. Again, you may make that association in your mind for that signal type, but it is not the language's concept for the term "wire".

I can tell you unequivocally that signals of type "wire" can be used represent combinatorial logic. I can also tell you that they must be sourced from a "reg" at some point. Unfortunately where signals of type "reg" are concerned, I can not provide that strong a statement regarding their implementation. In some language constructs, a signal of type "reg" is a combinatorial signal, and in others it will be implemented in a flip-flop or latch.

As I said above, I think for you to get a quick start, it would be best if you reviewed some of the common language elements, and then jumped right into reviewing code that is put forward as being synthesizable. Learning to simulate your code is also very important, but I think that once you are comfortable with the synthesizable subset of either language, picking up the simulation-only/non-synthesizable subset is easier.

There are several projects that members of the forum have put out on Github which provide prime examples of synthesizable Verilog and VHDL code. I suggest using ISim from Xilinx's ISE toolset for simulation. It can be used for free, and it can support mixed language situations. In many cases, synthesizers support only a single language. ISE's synthesizer and simulator support both languages for free, so regardless of their perceived quality, I recommend their use unless you have the resources to buy your own tools or use those of your employer on these types of projects.

I have attached an example of Verilog for a CPLD. I have not yet released that code on Github, because for the most part, my released projects on Github target FPGAs. You may use it in whatever manner you need. You may want to review Arlet's processor code on Github, or any of my projects on Github. Enso, EEyE, Rob Finch, Jens Gutschmidt, and others from this forum release open-source code on Github. Rob and Jens also release their code on Opencores.

Although there's still a special place for ABEL in my heart, its time has come and gone. The original HDLs of the 70's and 80's have not kept pace with programmable HW. They don't synthesize very economically on FPGAs, so it's time to adopt a newer, better supported HDL like Verilog or VHDL.

Good luck in your efforts, and if you need some help, send me a PM or post a request somewhere on this topic. I do check in on this forum several times a day, but I turned off email notifications because of the amount of activity on the topics of interest to me; couldn't handle the number of interruptions while at work.



PS: Unable to locate everyone's repository links to include them here for you. I'm sure they'll will be glad to provide you their links on request.

_________________
Michael A.

Thank you for this thorough perspective, the resources and your offer.
I might make use of it for some specific questions.

I’ve installed ISE 8.1i and today a few XC9572XL’s arrived for practicing.

_________________
Marco

Hello there! I'm one of the folks responsible for the Mercury FPGA dev board

Just in case anyone is looking to get one - the Mercury 50K FPGA module is actually $39.99 through Cyber Monday, using coupon code "FARADAY"


Mercury has a built-in USB programming circuit; no other programmer required.


The Spartan-3A has a recommended max Vin of 4.1V and an absolute max Vin of 4.6V.

The Mercury board includes buffers to provide 5V tolerance: 5V inputs are brought down to a safe 3.3V for the FPGA. 3.3V outputs from the FPGA pass-through the buffers at 3.3V (works with 5V TTL inputs, whose Vih threshold is 2V), but can be pulled up to the full 5V via external resistor (for use with 5V CMOS inputs, whose Vih threshold is 3.5V).