Learning AMD Zynq: a project to generate a set of PWM signals. 1 - problem statement and possible approach

To check if things worked, I created a constant for the duty cycle (set to 50%), and a register for the deadband. Now that I got this working, and refreshed my Pynq brain, I made both duty cycle and band a register. You recognise them as the two AXI_GPIO blocks

In the Jupyter testbed that I created, I can control both values:

I have set the resolution back to 6 bits for my tests. Because I turned the resolution into a generic in the VHDL code, I can adapt it in the block diagram.

With the VHDL PWM from my previous blogs, I can get a 5 MHz differential from a 20MHz clock, if I reduce the resolution to 2 bits.
There's virtually no wiggle room for deadband then. There are 1 clock pulse left to deal with it.

To support that, I made the resolution bit width generic:

--**********************************************************************
-- Copyright (c) 2011-2014 by XESS Corp <http://www.xess.com>.
-- All rights reserved.
--
-- This library is free software; you can redistribute it and/or
-- modify it under the terms of the GNU Lesser General Public
-- License as published by the Free Software Foundation; either
-- version 3.0 of the License, or (at your option) any later version.
-- 
-- This library is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-- Lesser General Public License for more details.
-- 
-- You should have received a copy of the GNU Lesser General Public
-- License along with this library.  If not, see 
-- <http://www.gnu.org/licenses/>.
--**********************************************************************

--*********************************************************************
-- Module for generating repetitive pulses.
--*********************************************************************

library IEEE;
use IEEE.std_logic_1164.all;

package PulsePckg is

  constant HI   : std_logic := '1';
  constant LO   : std_logic := '0';
  constant ONE  : std_logic := '1';
  
component Pwm is
  generic (
    resolution : integer := 6; -- bit width of the counter used for duty cycle
    duty_bits : integer := 4   -- bit width of the variable that holds the desired deadband 
  );
  port (
    n_reset_i : in  std_logic;          -- async reset
    clk_i  : in  std_logic;             -- Input clock.
    duty_i : in  std_logic_vector (resolution - 1 downto 0);      -- Duty-cycle input.
    band_i : in  std_logic_vector (duty_bits - 1  downto 0);      -- number of clock-ticks to keep both signals low before rising edge
    pwmA_o  : out std_logic;            -- PWM output.
    pwmB_o  : out std_logic             -- PWM output inverse.
    );
end component;  

end package;

--*********************************************************************
-- PWM module.
--*********************************************************************

library IEEE;
use IEEE.MATH_REAL.all;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use WORK.PulsePckg.all;

entity Pwm is
  generic (
    resolution : integer := 6;
    duty_bits : integer := 4
  );
  port (
    n_reset_i : in  std_logic;          -- async reset
    clk_i  : in  std_logic;             -- Input clock.
    duty_i : in  std_logic_vector (resolution - 1 downto 0);      -- Duty-cycle input.
    band_i : in  std_logic_vector (duty_bits - 1 downto 0);      -- number of clock-ticks to keep both signals low before rising edge
    pwmA_o  : out std_logic;            -- PWM output.
    pwmB_o  : out std_logic             -- PWM output inverse.
    );
end entity;

architecture arch of Pwm is
  signal timer_r       : natural range 0 to 2**duty_i'length-1;
begin

  clocked: process(clk_i, n_reset_i)
  begin
    pwmA_o   <= LO;
    pwmB_o   <= LO;
    
    -- async reset
    if n_reset_i = '0' then
        timer_r <= 0;
        
    elsif rising_edge(clk_i) then
      -- timer
      timer_r <= timer_r + 1;
      -- output a
      if timer_r <= unsigned(duty_i) and timer_r >= unsigned(band_i)  then
        pwmA_o <= HI;
      end if;
      -- output b
      if timer_r > to_integer(unsigned(band_i)) + to_integer(unsigned(duty_i)) then 		
        pwmB_o <= HI;
      end if;
    end if; -- rising_edge
  end process clocked;
  
  
end architecture;

I used a clock wizard to generate the 5 MHz:

I set the resolution to 2 bits in the block diagram:

Block design:

Output:

> This doesn't sound like PWM at all.

I also don't see a dead time in the complimentary signals. They ramp up and down at the same time.
I hope that by separating the requirements (and the thinking process), each signal's definition could become clearer.

I'm a bit puzzled by the statement:

"The PWM pulse-train should be 5 MHz."

And the more I look the more puzzled I am:

"First off, I need to simplify that I only need 50% duty cycle and no other duty cycles needed"

This doesn't sound like PWM at all.

I think it's more that yepe wants to drive a half bridge at 5MHz, but his diagram shows all the "PWM" pulses driving in the same direction.

At this point I'm feeling I want to look at the whole menu again before I order the elephant sandwich.

Or, rather, see a schematic of the half bridge and its load.

MK

The PRF signal sounded interesting, I couldn't tell if it is internally generated, or externally generated since they mention having to sync to it. If it's external then that might need a PLL. A block diagram showing all signals would also helps that they can implement it in chunks as you recommended. Maybe this is a uni project, in which case if it is a team project and they must have worked on some sort of diagrams of the system to share the work, but hasn't been shared.