0
\$\begingroup\$

Not sure if this is correct implementation, although it works so far. I output the data on the rising edge of the FETCH signal (this is not a clock). The data should only be out in the OUTP state. This also counts how many words were output so far, and the state machine (not shown) transitions to a different state if the word count reaches some value.

always @(posedge FETCH)
    case(state)
        OUTP:   begin
                OUT_DATA <= DATA[WordCounter];
                WordCounter <= WordCounter + 1 ;
                end
        default:WordCounter <= 6'd0;
    endcase

The problem is that to reset the WordCounter, I must pulse FETCH signal when not in the OUTP state. Is there a better way to rewrite this code, so I can fetch the data on the edge, but the WordCounter can be reset in any state other than OUTP not requiring a rising edge?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ When you say that FETCH is not the clock, is it not true that it is the clock for the state machine and counter? \$\endgroup\$
    – dave_59
    Commented Sep 12, 2018 at 15:42
  • \$\begingroup\$ @dave_59 FETCH is the asynchronous signal that is only used in the code above. OUT_DATA and WordCounter change only with this signal. The state machine runs from the actual system clock. \$\endgroup\$
    – Nazar
    Commented Sep 12, 2018 at 15:48

2 Answers 2

2
\$\begingroup\$

I output the data on the rising edge of the FETCH signal (this is not a clock).

You change OUT_DATA and WordCounter on the rising edge of FETCH (but not merely to reset or preset them). Therefore FETCH is a clock (at least for this subcircuit).

If you don't want to use FETCH as a clock, but still watch its rising edges, you need to have another clock signal to use, and it must be guaranteed to have at least one rising edge for each pulse of FETCH. Then you can do

reg FETCH2;
always @(posedge CLK) begin
    FETCH2 <= FETCH;
    if ( state == OUTP ) begin
        if (FETCH & ~FETCH2) begin // rising edge of FETCH
            OUT_DATA <= DATA[WordCounter];
            WordCounter <= WordCounter + 1;
        end
    end
    else begin
        WordCounter <= 0;
    end
end
\$\endgroup\$
1
  • \$\begingroup\$ This should do the trick. My data and counter are synchronous to the CLK now, and I just have an edge detector there instead. Since the CLK is several times faster than FETCH, I should be fine. Let me try it. \$\endgroup\$
    – Nazar
    Commented Sep 12, 2018 at 16:26
0
\$\begingroup\$

Strictly answering the question this code gives you a separate signal which will reset the variables:

always @(posedge FETCH or posedge clear)
begin
   if (clear)
   begin 
      OUT_DATA  <= out_data_reset_value;
      WordCounter  <= WordCounter _reset_value;
   end
   else
      case(state)
          OUTP:   begin
                  OUT_DATA <= DATA[WordCounter];
                  WordCounter <= WordCounter + 1 ;
                  end
          default:WordCounter <= 6'd0;
      endcase
end

But, as my text "Strictly ..." already suggests, that coding style is very much frowned upon. You should always try to make all your code synchronous to one clock and not introduce other 'clocks'. (Which FETCH is). Using my code with an asynchronous clear introduces a whole new, extra set of potential race conditions. I personally would never use it. caveat emptor!!

In the mean time I see The_Photon is already elaborating on this.

\$\endgroup\$
3
  • \$\begingroup\$ Your code still requires me to signal. In this case, I still have to pulse clear in stead of FETCH. \$\endgroup\$
    – Nazar
    Commented Sep 12, 2018 at 16:15
  • \$\begingroup\$ "...still requires me to signal." Thus you want a clear without signalling. I suggest you think a bit about what you are asking... \$\endgroup\$
    – Oldfart
    Commented Sep 12, 2018 at 16:26
  • \$\begingroup\$ Once the counter reaches a specified value, the state will change. Thus, I want the counter should reset in not OUTP state. But currently, it can only reset on the FETCH edge. \$\endgroup\$
    – Nazar
    Commented Sep 12, 2018 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.