BaudRateGen has non-constant asynchronous reset value

[cole-nelson]

Hello, I'm from the Purdue SoCET team, another university group focused on chip design and fabrication. We've been using this UART module for a few years now, courtesy of Vito.

Bug

This module is not always synthesizeable due to a non-constant in the asynchronous reset block. The following snippet seems to be the culprit:

  always @(posedge clk, negedge nReset) begin
    if (!nReset || syncReset || (txCount == 0)) begin
      rxCount <= rxRate - offset - 1;
    end else if (rxCount == 0) begin
      rxCount <= rxRate - 1;
    end else if (!inWait) begin
      rxCount <= rxCount - 1;
    end

    if (!nReset || syncReset || (txCount == 0)) begin
      txCount <= rate - 1;
    end else begin
      txCount <= txCount - 1;
    end
  end

It is synthesizeable on FPGA targets, and using some combinations of ASIC PDK & EDA tools.

The issue arises from common DFF cells not having an arbitrary reset value port; usually they have asynchronous reset (set-to-0) or set (set-to-1) functionality.

Additionally, as the asynchronous reset is meant to put the system into a known state after power-on, it is better to have a constant reset value for the asychronous reset path as the rate input may itself not be in a good state after power-on.

Suggested Fix

I would recommend just splitting up the cases, and using an always_ff block for synchronous logic.

  always_ff @(posedge clk, negedge nReset) begin
    if(!nReset) begin
      rxCount <= '0;
      txCount <= '0;
    end else begin // ugly indentation, but explicit that this block is the posedge clk condition
      /* Synchronous conditions here */
    end
  end

If you reset to 0, then on the first 'valid' cycle of execution, you will hit the txCount == 0 condition and reset yourself to the original rate - 1 value.

I would be glad to implement this and make a PR if you like, I would just need to know what you expect from a PR (fork vs. branch, code quality guidelines, etc.)