It depends on the ISE synthesis settings. By default, ISE will generate an error in this situation because it expects multipliers to be implemented using the dedicated hardware multiplier resources available in the FPGA.

However, you can change the synthesis settings to allow the tool to implement the multipliers using LUTs and flip-flops instead. Keep in mind that this will typically consume more FPGA resources and may result in lower performance compared to using the dedicated multiplier blocks.

The two uses of the keyword “others” that you mentioned are actually two different concepts.

In a case statement, others refers to all remaining values that have not been explicitly handled. In that context, others is dealing with possible values of a signal.

However, in a statement such as:

signal Counter_Out_Int : unsigned(3 downto 0) := (others => ‘0’);

the keyword others has a different meaning. Here, it refers to all remaining elements of the vector.

Let me explain it this way. You could initialize the signal like this:

signal Counter_Out_Int : unsigned(3 downto 0) := (3 => ‘0’, 2 => ‘1’, others => ‘0’);

This means:

Counter_Out_Int(3) = ‘0’
Counter_Out_Int(2) = ‘1’
Counter_Out_Int(1) = ‘0’
Counter_Out_Int(0) = ‘0’

In other words, you explicitly assigned values to some bits, and then used others => ‘0’ to assign a value to all the remaining bits.

Now, if you remove the individual bit assignments and write:

signal Counter_Out_Int : unsigned(3 downto 0) := (others => ‘0’);

then every bit in the vector is initialized to ‘0’.

So in this case, others is not referring to values and it is not referring to additional wires outside the vector. It simply means all remaining elements of the array (vector) that have not been explicitly assigned a value.

This is nothing more than a convenient way to initialize all bits of a vector to the same value, usually ‘0’ or ‘1’, without having to write each bit individually.

You receive the input data one bit at a time on each rising edge of the clock. Each received bit is fed into a shift register. At the same time, you compare the contents of the shift register with the desired sequence pattern.

When the contents of the shift register match the target sequence (for example, 10011), you should assert the alarm for one clock cycle.

One thing to keep in mind is that, because you are following the Standard Coding Template for FPGA, both the input and output ports are registered. This introduces one clock cycle of delay at the input and one clock cycle of delay at the output.

As a result, if you compare the actual external input signal with the actual external alarm output, you’ll see a two-clock-cycle delay between the moment the complete sequence is received and the moment the alarm is asserted. This is completely normal and expected.

Also note that if, in a future project, the next stage of the design requires the input data and the alarm signal to be aligned in time, this is very easy to achieve. Since everything is synchronous, you can simply delay the input signal by two clock cycles using a pair of registers. This will align the delayed input signal with the alarm output. In FPGA design, adding or removing a few clock cycles of delay to align signals is a very common technique and is generally not considered a problem.

No, unfortunately VHDL does not allow one generic’s default value to be defined using another generic in the same generic declaration list.

In practice, the second approach is the correct way to declare the generics:

generic (
Freq : integer := 30000000;
Divisor: integer := 30000000
);

However, if this module is eventually instantiated as a submodule inside another VHDL file, you can achieve the same effect through generic mapping. In the instantiating module, you can define a single constant or generic and then use it to initialize both generics:

generic map (
Freq => SystemFreq,
Divisor => SystemFreq
)

This way, you only need to change the value in one place, and both generics will automatically receive the same value.

You’ll see examples of generic mapping later in the course, and it becomes a very useful technique for managing configuration values across larger designs.

Great questions, Stuart.

When it comes to FPGA design, we have two different hardware elements: wires and registers. In VHDL, both are typically represented using the signal keyword. The difference is not in how the signal is declared, but in how and where it is assigned.

If you assign a signal in the concurrent section of the architecture, the synthesis tool will implement that signal as a wire (combinational logic).

If you assign a signal inside a process statement and specifically under a clock condition such as:

if rising_edge(Clk) then

then the synthesis tool will implement that signal as a register.

A register is simply a collection of flip-flops that all share the same clock signal. While storage elements can also be implemented using latches, we generally avoid latches in FPGA design because they are asynchronous elements. As you’ve seen throughout the course, we try to keep our designs fully synchronous whenever possible, as this results in more predictable and reliable hardware.

Regarding propagation delay, it’s important to note that both wires and registers introduce delays. A wire is not instantaneous. Signals must still propagate through routing resources and combinational logic, which creates delay. Registers introduce an additional clock-to-output delay, while wires introduce routing and logic delays. These effects can be observed in timing simulations and are analyzed by the FPGA timing tools.