Verilog Always Block

Contains one or more statements (procedural assignments, task enables, if, case and loop statements), which are executed repeatedly throughout a simulation run, as directed by their timing controls.

Syntax
always
    Statement

Or

always
    begin
    Statements
    end

 

Where to use:
module-<HERE>-endmodule

Rules for Using always Statement:
Only registers (reg, integer, real, time, realtime) may be assigned in an
always.

Every always starts executing at the start of simulation, and continues executing throughout simulation; when the last statement in the always is reached, execution continues from the top of the always.

• An always containing more than one statement must enclose the statements in a begin-end or fork-join block.
• An always with no timing controls will loop forever.

Synthesis:
always is one of the most useful Verilog statements for synthesis, yet an always is often unsynthesizable. For best results, code should be restricted to one of the following templates:

always @(Inputs) // All the inputs
begin
... // Combinational logic
end

always @(Inputs) // All the inputs
if (Enable)
begin
... // Latched actions
end

always @(posedge Clock) // Clock only
begin
... // Synchronous actions
end

always @(posedge Clock or negedge Reset)
// Clock and Reset only
begin
if (!Reset) // Test active level of asynchronous reset
... // Asynchronous actions
else
... // Synchronous actions
end // Gives flipflops + logic

Cyclic Redundancy Checking (CRC)

Error detection is an important part of communication systems when there is a chance of data getting corrupted. Whether it’s a piece of stored code or a data transmission, you can add a piece of redundant information to validate the data and protect it against corruption. Cyclic redundancy checking is a robust error-checking algorithm, which is commonly used to detect errors either in data transmission or data storage. In this multipart article we explain a few basic principles.

Modulo two arithmetic is simple single-bit binary arithmetic with all carries or borrows ignored. Each digit is considered independently. This article talks about how modulo two addition is equivalent to modulo two subtraction, and can be performed using an exclusive OR operation followed by a brief on Polynomial division where remainder forms the CRC checksum.
For example, we can add two binary numbers X and Y as follows:

10101001 (X) + 00111010 (Y) = 10010011 (Z)

From this example the modulo two addition is equivalent to an exclusive OR operation. What is less obvious is that modulo two subtraction gives the same results as an addition.
From the previous example let’s add X and Z:

10101001 (X) + 10010011 (Z) = 00111010 (Y)

In our previous example we have seen how X + Y = Z therefore Y = Z – X, but the example above shows that Z+X = Y also, hence modulo two addition is equivalent to modulo two subtraction, and can be performed using an exclusive OR operation.

In integer division dividing A by B will result in a quotient Q, and a remainder R. Polynomial division is similar except that when A and B are polynomials, the remainder is a polynomial, whose degree is less than B.

The key point here is that any change to the polynomial A causes a change to the remainder R. This behavior forms the basis of the cyclic redundancy checking.
If we consider a polynomial, whose coefficients are zeros and ones (modulo two), this polynomial can be easily represented by its coefficients as binary powers of two.

In terms of cyclic redundancy calculations, the polynomial A would be the binary message string or data and polynomial B would be the generator polynomial. The remainder R would be the cyclic redundancy checksum. If the data changed or became corrupt, then a different remainder would be calculated.

Although the algorithm for cyclic redundancy calculations looks complicated, it only involves shifting and exclusive OR operations. Using modulo two arithmetic, division is just a shift operation and subtraction is an exclusive OR operation.

Cyclic redundancy calculations can therefore be efficiently implemented in hardware, using a shift register modified with XOR gates. The shift register should have the same number of bits as the degree of the generator polynomial and an XOR gate at each bit, where the generator polynomial coefficient is one.

Augmentation is a technique used to produce a null CRC result, while preserving both the original data and the CRC checksum. In communication systems using cyclic redundancy checking, it would be desirable to obtain a null CRC result for each transmission, as the simplified verification will help to speed up the data handling.

Traditionally, a null CRC result is generated by adding the cyclic redundancy checksum to the data, and calculating the CRC on the new data. While this simplifies the verification, it has the unfortunate side effect of changing the data. Any node receiving the data+CRC result will be able to verify that no corruption has occurred, but will be unable to extract the original data, because the checksum is not known. This can be overcome by transmitting the checksum along with the modified data, but any data-handling advantage gained in the verification process is offset by the additional steps needed to recover the original data.

Augmentation allows the data to be transmitted along with its checksum, and still obtain a null CRC result. As explained before when obtain a null CRC result, the data changes, when the checksum is added. Augmentation avoids this by shifting the data left or augmenting it with a number of zeros, equivalent to the degree of the generator polynomial. When the CRC result for the shifted data is added, both the original data and the checksum are preserved.

In this example, our generator polynomial (x3 + x2 + 1 or 1101) is of degree 3, so the data (0xD6B5) is shifted to the left by three places or augmented by three zeros.

0xD6B5 = 1101011010110101 becomes 0x6B5A8 = 1101011010110101000.

Note that the original data is still present within the augmented data.
0x6B5A8 = 1101011010110101000
Data = D6B5 Augmentation = 000

Calculating the CRC result for the augmented data (0x6B5A8) using our generator polynomial (1101), gives a remainder of 101 (degree 2). If we add this to the augmented data, we get:

0x6B5A8 + 0b101 = 1101011010110101000 + 101
= 1101011010110101101
= 0x6B5AD

As discussed before, calculating the cyclic redundancy checksum for 0x6B5AD will result in a null checksum, simplifying the verification. What is less apparent is that the original data is still preserved intact.

0x6B5AD = 1101011010110101101
Data = D6B5 CRC = 101

The degree of the remainder or cyclic redundancy checksum is always less than the degree of the generator polynomial. By augmenting the data with a number of zeros equivalent to the degree of the generator polynomial, we ensure that the addition of the checksum does not affect the augmented data.

In any communications system using cyclic redundancy checking, the same generator polynomial will be used by both transmitting and receiving nodes to generate checksums and verify data. As the receiving node knows the degree of the generator polynomial, it is a simple task for it to verify the transmission by calculating the checksum and testing for zero, and then extract the data by discarding the last three bits.

Thus augmentation preserves the data, while allowing a null cyclic redundancy checksum for faster verification and data handling.

Edge triggered D Flip Flop

Below figure shows the Diagram of Edge triggered d flip flop

What is Synthesis?

Synthesis is the stage in the design flow which is concerned with translating your VHDL code into gates - and that's putting it very simply! First of all, the VHDL must be written in a particular way for the target technology that you are using. Of course, a synthesis tool doesn't actually produce gates - it will output a netlist of the design that you have synthesised that represents the chip which can be fabricated through an ASIC or FPGA vendor.

Are there any VHDL source code libraries available to save me having to re-invent common code fragments and functions?

There are a few libraries available for most levels of VHDL design. The IEEE library contains very low-level type-and-function packages. The std_logic_1164 package is an industry standard, and practically every piece of VHDL you ever write will use this package; the types std_logic and std_logic_vector are the overwhelmingly dominant types for anything related to digital design. For arithmetic, numeric_std (from the same IEEE library) is a collection of functions that work on std_logic and its derivatives. For other libraries of components, have a look in the comp.lang.vhdl FAQ.

I've heard that VHDL is very inefficient for FPGAs. Is that true?

It might be. If the code in question was written with no thought for how the FPGA would implement the circuit, then it's entirely possible that it was inefficient. If the code is written with consideration of the FPGA resources available and the synthesis tool being used, then no, it's not inefficient.

I can see how to write abstract behavioural descriptions in VHDL, but how do you describe and simulate the actual hardware?

This is probably the biggest hurdle that many hardware engineers face when moving to VHDL. After all, sometimes we need to be able to describe actual implementation as well as abstract functionality. The way to describe "physical" hardware in VHDL is to write VHDL models of those components. This is supported in VHDL through the use of instantiation. VHDL does not allow you to physically simulate your hardware. You can only simulate a model of that component in a VHDL simulation.

Historically, gate-level simulation using VHDL has been notoriously slow. This led to the creation of the 1076.4 working group to provide a mechanism to allow faster gate-level simulation using VHDL. Their effort became known as the VITAL standard. VITAL is not a VHDL issue for you, but an EDA vendor/ASIC supplier issue. A simulator is VITAL compliant if it implements the VITAL package in its kernel (this is faster than simulating the VITAL primitives in the VITAL package). You don't need to change your VHDL netlist; your ASIC vendor needs to have a VITAL compliant library though, in order for you to take advantage of the simulation speed up. Thus the ASIC vendor's library elements need to be implemented entirely in VITAL primitives. Note that many companies use Verilog for gate-level simulations as it is still faster than VHDL, even with the improvements from VITAL. The reason is that Verilog was designed from the start as a gate-level simulation language.