Jump to content

GalD101

Members
  • Posts

    107
  • Joined

  • Last visited

Posts posted by GalD101

  1. I looked up always_ff and it seems to be just like the regular always but with restrictions. A bit of an unrelated question: in our case, the good old reg (now logic) will be flipflops only (that is, we will only use ffs for memory (reg)? because I think I once saw that it's also possible to use LUTs instead?) It says that "A always_ff procedure adds a restriction that it can contain one and only one event control and no blocking timing controls" and that "Variables written on the left-hand side of assignments within always_ff... cannot be written by other processes". Why did you choose to use an "always_ff" block in line 44 of my_first_fsm.sv?
    Also, in line 44, why won't you add a negedge or posedge of the reset to the sensitivity list like so?

    always_ff @ (posedge CLK or negedge RESET) state <= next_state(state, RESET);

    I now read a bit about event control and it says on the quote above that always_ff can only use one - so is that the reason you didn't add another event (negedge RESET) to the sensitivity list? because always_ff doesn't allow to? I just want to make sure I understand what event control is.
    As for "blocking timing controls" is it that thing you mentioned before (blocking assignments (=) and nonblocking assignments (<=)?) so that is why you used a function that does these operations instead? Also, why did you use a blocking assignment inside the function? I thought we need it to happen simultaneously, or is it because the function is running sequentially but when you do the nonblocking assignment later on line 44 it runs the function and once it's finished you assign it with <= to "state" so it doesn't matter if you did blocking assignments (=) inside the body of the function because you "fix" it when you use non blocking assignment later on line 44?

  2. 4 minutes ago, reddish said:


    Good! That wasn't so hard was it. Periodicity is a pretty important concept in state machines. Good that we figured out this concept didn't come natural to you. We may need it in the future.

    Okay, so your assertion is that the second FSM has a period of 2 * 868 = 1736 clock cycles. I agree that's what it should do.

    Now back to the code you posted, with two bugs:
     

      wire [3:0] next_counter = (r_counter + 1) % (868*2 + 1);
      wire       next_fsm_out = (next_counter < 868) ? 1 : 0;


    What values does r_counter take on during a full cycle? And how many different values are that? Does that fit in 1736 cycles?


     

    it ranges from 0 to 1736 so 1737 different values.
    I still don't get the problem with this code:
     

      wire [10:0] next_counter = (r_counter + 1) % (11'd1738);
      wire       next_fsm_out = (next_counter < 10'd867) ? 1'b1 : 1'b0;

     

  3. @reddish what i wrote above (the long post) is it correct? Please correct me if i said something that isn't true
    can you please comment on this as well?:

    1 hour ago, GalD101 said:

    a small question, can't you just make your output (FSM_OUT) a reg and then you wont have to use another auxiliary variable(r_fsm_out)?

    EDIT: I think it's not possible to directly change the output but it is possible to use another variable that will be assigned to it like you did

  4. 5 minutes ago, reddish said:

    Hint: 1/115200.0 seconds is approximately equal to 868 times 10 ns (verify this, then think about the implications given that we have a 100 MHz clock available to us)

    so I need to change the code to look like this?:
     

      wire [3:0] next_counter = (r_counter + 1) % (868*2 + 1);
      wire       next_fsm_out = (next_counter < 868) ? 1 : 0;

     

×
×
  • Create New...