Does Nios II custom instruction need clk_enable?

[Altera_Forum]

Hi all!!! http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/rolleyes.gif  

 I have a Nios II project with 3 custom instructions that export the signals to a shared user logic, out of the Nios II core.  Have I to re-design the logic to support the clock enable pin of each custom instruction that come from the Nios II core??? http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/dry.gif   Are there cases in which the Nios II core decides to freeze my logic for some clock cycles??   Thanks, Matteo

[Altera_Forum]

If I understood the question correctly, yes you should be using seperate clk enables. That&#39;s how your custom instruction hardware knows that the data is for it (the ALU signals are not going to get masked from your hardware so other custom instructions or the ALU itself could cause your hardware to "start"). 

 If I misunderstood your question I apologize (I&#39;ll take another crack at it if I did).

[Altera_Forum]

I was not clear in explaining the situation, sorry... http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif  

 I have a Nios II project with 3 custom instructions. Each c.i. exports the signals to a single user logic, out of the Nios II core (but on the FPGA). Each c.i. performs a different operation on this logic. There is only one user logic, shared by the 3 custom instructions.  In the user logic, I used &#39;clock&#39; and &#39;reset&#39; from the top level entity of the project, not from each c.i.  Each c.i. is a fixed clock cycle operation and uses only &#39;start&#39;, &#39;dataa&#39; and &#39;result&#39;. I didn&#39;t use &#39;clock&#39;, &#39;clk_en&#39; and &#39;reset&#39;.  For the moment, the project seems to work correctly.  The question is:  Is there the possibility that the Nios II core want to use the clk_en of each c.i. for some reasons?  In this case it&#39;ll not work!!?!! http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/blink.gif    Bye

[Altera_Forum]

http://www.altera.com/literature/ug/ug_nio...instruction.pdf (http://www.altera.com/literature/ug/ug_nios2_custom_instruction.pdf) 

 Go to page 17 (1-9). In that example you see 3 custom instruction blocks plus the N port. If you are not structuring your hardware this way then I would. So keep your custom logic the way it is, but bring their results through a MUX using n[1..0] to select them (so CC1 goes to the first MUX input, CC2 goes to the second MUX input, CC3 goes to the third MUX input, and ground the fourth MUX input).  Why having the clock enable but not using it allows your design to work is beyond me, but if it is structure like in that pdf then you should have no problem. By the way, the external circuit that these custom instructions interface to, is it a combinational circuit too? (make sure that everything can be completed in a single clock cycle)  Cheers

[Altera_Forum]

Till now, I never saw the clockenable going low on my system. So I just ingnore the input. 

  I think if you provide different custom instructions (with a defined nr), Altera generates the Mux logic. If you use only one custom instruction, you provide the mux (using the (N[7:0] signals).  I can not see ignoring the clock enable can do any harm. The system (or you in the second case) will decide to use the result or not.   stefaan

[Altera_Forum]

I reviewed the documentation for the custom instructions and you are right about the muxing (I&#39;m used to NIOS I custom instructions). 

 Since you are combinational, you don&#39;t need that enable. However, if you look at page 1-6 (pg 14) it states that if you do a combinational custom instruction you can not have an optional interface. Whether that applies to your design or not I&#39;m not sure (not sure why this is not possible for combinational logic, probably keep the timing high I&#39;m guessing).