Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interrupt enable definitions are not obeyed #67

Closed
sjalloq opened this issue Jun 13, 2019 · 5 comments
Closed

Interrupt enable definitions are not obeyed #67

sjalloq opened this issue Jun 13, 2019 · 5 comments

Comments

@sjalloq
Copy link

sjalloq commented Jun 13, 2019

I've followed the example in the RDL spec on how to generate hierarchical interrupts. At the top level I have two registers with a single bit in each, one a global interrupt and one a global enable. I've tried using both the 'intr' and 'nonsticky intr' properties on the interrupt and it behaves the same way. How am I supposed to mask this top level interrupt?

reg ctrl_reg {
    regwidth = 16 ;
    name = "Global Control Register" ;
    
    default hw=r ;
    default sw=rw ;
    default reset = 1'b0 ;
    
    field {
      desc = "Global enable for all interrupts" ;
      hw=na;
    } global_irq_en ;
};


reg status_reg {
    regwidth = 16 ;
    name = "Global Status Register" ;

    default hw=w ;
    default sw=r ;
    default reset = 1'b0 ;

    field {
      desc = "Global interrupt flag" ;
      hw=na ;
      intr;
    } global_irq ;
};

addrmap address_map {
	// Instantiate the generic control and status regs
	ctrl_reg    _control  @0x000 ;
	status_reg  _status   @0x002 ;

	// Mask the global interrupt enable
	_status.global_irq->enable = _control.global_irq_en ;
	// Hook up the status intr output to the global reg
	_status.global_irq->next = _sff_irq_status->intr;
};

That results in:

  //------- combinatorial assigns for _status
  always @ (*) begin
    reg__status_global_irq_next = rg__status_global_irq;
    l2h__status_intr_o = 1'b0;
    l2h__status_intr_o = l2h__status_intr_o | (rg__status_global_irq);
    reg__status_global_irq_next = l2h__sff_irq_status_intr_o;
  end
  
  //------- reg assigns for _status
  always @ (posedge clk) begin
    if (! sig_reset_n) begin
      rg__status_global_irq <= #1 1'b0;
    end
    else begin
      rg__status_global_irq <= #1  reg__status_global_irq_next;
    end
  end
@sjalloq
Copy link
Author

sjalloq commented Jun 13, 2019

And is that another typo in your output generator? Shouldn't the register name and the _next term be the same? Looks like you missed the 'e' from 'reg' in rg__status_global_irq.

@sdnellen
Copy link
Contributor

Not able to recreate this issue - directly copied your code (older version i think that didnt have the ->next assign) and see the following for _status assigns:

    //------- combinatorial assigns for _status
      always @ (*) begin
        reg__status_global_irq_next = rg__status_global_irq;
        l2h__status_intr_o = 1'b0;
        reg__status_global_irq_next = (h2l__status_global_irq_intr | rg__status_global_irq);
        l2h__status_intr_o = l2h__status_intr_o | (rg__status_global_irq & rg__control_global_irq_en);
      end

Assume you see no errors/warnings when running? If not, might try removing the comment prior to the ->enable assign (just a guess)

Register name starting with "rg_" is no typo - just a way to allow easy identification of actual field registers by name.

@sjalloq
Copy link
Author

sjalloq commented Jun 14, 2019

OK, I've attached a testcase with my full RDL. Untar it and run 'make'. The archive has the jar file and the preprocessor.

Thanks.
testcase.tar.gz

sdnellen pushed a commit that referenced this issue Jun 16, 2019
@sjalloq
Copy link
Author

sjalloq commented Jun 17, 2019

Thanks a lot. If you could fire off a build that would be useful as I can't currently build from source. See #63

@sjalloq
Copy link
Author

sjalloq commented Jun 18, 2019

Confirmed fixed. Thanks a lot.

@sjalloq sjalloq closed this as completed Jun 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants