Electronic – VHDL testbench variable clock/wave generation

testingvhdl

A testbench for one sub-entity in my system currently defines a helper process to generate a clock-like waveform at the command of the main stimulus process. A simplified version of it is:

shared variable gen_period : time := 10 us;
signal gen_all : boolean := false;  -- wavegen enabled
signal gen_A : boolean := false;    -- run this signal
signal A_in : std_logic;            -- manual input (wavegen disabled)
signal A_gen : std_logic;           -- generated output (internal)
signal A_out : std_logic;           -- final output
...
A_generate: process
    if gen_A then
        A_gen <= '1';
        wait for gen_period/2;
        A_gen <= '0';
        wait for gen_period/2;
    else
        A_gen <= '0';
        wait for 1 ns;
    end if;
end process;

A_out <= A_gen when gen_all else A_in;

The full system has a few more signals, but this is the basic idea. gen_all applies to all signals and allows a manual signal pattern to be applied when disabled, while gen_A is basically a clock enable for that specific signal. The other important feature is that the period of the clock is variable.

Putting this all together it means that the main testbench stimulus process can either manually generate edges or can just request a pulse train at a specific interval and then wait for a longer time (typically gen_period * N) to generate multiple pulses. It works quite well.

Now though I'm interested in generalising this a bit, in particular to instantiate several such independent generators in the testbench for a higher-level design that contains multiple of the original component. However I'm having trouble finding the right way to do so.

My first attempt was to wrap the code above into its own entity, declaring all but A_gen as ports of the entity. Doing this required changing gen_period from a variable to a signal, since AFAIK ports must be signals.

Unfortunately, back in the original testbench stimulus process, whenever it tried to assign a new period it had to do this as a signal assignment, which didn't take effect until later. Additionally the wait for gen_period * 5 calls appeared to be using the original value for gen_period rather than one just assigned. (This is not surprising behaviour for signals, but in this case it's undesired.)

Is there a better way to encapsulate this functionality, and retain instant behaviour of the variable? The code is only going to be used in a testbench, so it does not need to be synthesisable. I'm using Xilinx ISim.

(I realise that I can do a for .. generate to instantiate multiple instances in the higher level testbench, but this doesn't allow me to share the code between separate testbenches, which is also desirable to avoid duplication.)

I can live with having only one instance of the gen_period variable shared between all generators in the high level testbench, but I would prefer to have one per generator instance.

Since the answers seem to be focusing on "clock" rather than "waveform", it seems that I need to clarify the usage a bit more. This is inside a testbench:

stim_proc : process
begin
    -- (reset and other setup instructions here)

    -- generate "slow" pulse train
    gen_all <= true;
    gen_period := 250 ns;
    gen_A <= true;
    wait for gen_period * 20;
    gen_A <= false;
    wait for gen_period;
    -- (perform tests on logic for slow pulses here)

    -- generate "fast" pulse train
    gen_period := 10 ns;
    gen_A <= true;
    wait for gen_period * 50;
    gen_A <= false;
    wait for gen_period;
    -- (perform tests on logic for fast pulses here)

    -- generate asymmetric pulses
    gen_all <= false;
    A_in <= '1';
    wait for 100 ns;
    A_in <= '0';
    wait for 200 ns;
    A_in <= '1';
    wait for 150 ns;
    A_in <= '0';
    wait for 50 ns;
    -- (perform tests on logic for asymmetric pulses here)

    -- etc
end process;

These are the simple ones; there are a few more complex ones involving multiple signals happening simultaneously, but that's not really important for this question. The important point is that this is all sequential code and both the pulse generation and the waiting need to act on the most recently set period, not any delayed value.

Best Answer

You could use a procedure with an out parameter. The procedure can be declared in a package and called with different parameters for different 'clock' signals.

Here is an example of a clock_gen procedure from VHDL-extras:

subtype duty_cycle is real range 0.0 to 1.0;

procedure clock_gen( signal Clock : out std_ulogic; signal Stop_clock : in boolean;
  constant Clock_period : in delay_length; constant Duty : duty_cycle := 0.5 ) is
  constant HIGH_TIME : delay_length := Clock_period * Duty;
  constant LOW_TIME  : delay_length := Clock_period - HIGH_TIME;
begin
  Clock <= '0';

  while not Stop_clock loop
    wait for LOW_TIME;
    Clock <= '1';
    wait for HIGH_TIME;
    Clock <= '0';
  end loop;
end procedure;

The constant input period can be exchanged with a variable for simulation environments.

Usage example:

architecture rtl of my_entity is
  signal SimStop      : boolean     := false;
  signal my_clock1    : std_ulogic;
  signal my_clock2    : std_ulogic;
begin

  clock_gen(my_clock1, SimStop, 10.000 ns);
  clock_gen(my_clock2, SimStop,  6.666 ns);

  -- ...

  process
  begin
    --
    -- some stimuli
    --

    wait for 10 ns;
    SimStop := true;
    wait;
  end process;
end architecture;

Example to generate a waveform with an generic waveform:

type T_TIME_VECTOR is array(NATURAL range <>) of TIME;

constant myWaveform : T_TIME_VECTOR  := (
  -- generate "slow" pulse train
  20 * 250 ns,
  250 ns,
  -- generate "fast" pulse train
  50 * 10 ns,
  10 ns
);

procedure generateWaveform(signal Wave : out BOOLEAN; Waveform: T_TIME_VECTOR; InitialValue : BOOLEAN) is
  variable State : BOOLEAN := InitialValue;
begin
  Wave <= State;
  for i in Waveform'range loop
    wait for Waveform(i);
    State := not State;
    Wave  <= State;
  end loop;
end procedure;

signal mySignal : BOOLEAN;

-- begin of architecture
generateWaveform(mySignal, myWaveform);

Related Solutions

Electronic – Generating pulse train of varying frequency on an FPGA

What you want to do is called a Numerically Controlled "Oscillator", or NCO. It works like this...

Create a counter that can increment by values other than 1. The inputs to this counter are the master clock, and a value to count by (din). For each clock edge, count <= count + din. The number of bits in din is the same as the number of bits in the counter. The actual count value can be used for many useful things, but what you want to do is super simple.

You want to detect every time the counter rolls over, and output a pulse to your motor when that happens. Do this by taking the most significant bit of the counter and running it through a single flip-flop to delay it by one clock. Now you have two signals that I'll call MSB, and MSB_Previous. You know if the counter has rolled over because MSB=0 and MSB_Prev=1. When that condition is true, send a pulse to the motor.

To set the pulse frequency, the formula is this: pulse_rate = main_clk_freq * inc_value/2^n_bits

Where inc_value is the value that the counter is being incremented by and n_bits is the number of bits in the counter.

An important thing to note is that adding bits to the counter does not change the range of the output frequency-- that is always 0 Hz to half of main_clk_freq. But it does change the accuracy that you can generate the desired frequency. Odds are high that you won't need 32-bits for this counter, and that maybe just 10 to 16 bits will be enough.

This method of generating pulses is nice because it is super easy, the logic is small and fast, and it can often generate frequencies more accurately and with better flexibility than the type of counter+comparator design that you have in your question.

The reason why the logic is smaller is not only because you can get by with a smaller counter, but you do not have to compare the entire output of the counter. You only need the top bit. Also, comparing two large numbers in an FPGA usually requires a lot of LUTs. Comparing two 32-bit numbers would require 21 4-Input LUTs and 3 logic levels, where as the NCO design requires 1 LUT, 2 Flip-Flops, and only 1 logic level. (I'm ignoring the counter, since it is basically the same for both designs.) The NCO approach is much smaller, much faster, much simpler, and yields better results.

Update: An alternative approach to making the rollover detector is to simply send out the MSB of the counter to the motor. If you do this, the signal going to the motor will always be a 50/50 duty cycle. Choosing the best approach depends on what kind of pulse your motor needs.

Update: Here is a VHDL code snippet for doing the NCO.

signal count :std_logic_vector (15 downto 0) := (others=>'0);
signal inc   :std_logic_vector (15 downto 0) := (others=>'0);
signal pulse :std_logic := '0';

. . .

process (clk)
begin
  if rising_edge(clk) then
    count <= count + inc;
  end if;
end process;

pulse <= count(count'high);

Generating a desired pulse train in Xilinx ISE software

I would use a shift register - use a constant to initialise it to your desired pulse train when reset is asserted and then just clock it out. Your top-level entity will only need three pins, clock, reset and the output.

Best Answer

Related Solutions

Electronic – Generating pulse train of varying frequency on an FPGA

Generating a desired pulse train in Xilinx ISE software

Related Topic