How to design an abitration cicuit related to interrupt controller

Hello everybody,

I'm Quang Anh. I'm living in Vietnam, a small and nice country in South Asian. This is the first time I've posted a topic in this group for help.

I has been working in a hadware company for about one year. Now, I'm in charge of designing an interrupt controller (INTC) for a CPU. This module is expected to work at high speed. Therefore, it's very hard for such a beginner like me to design. One of my concerns is how to design a fix-prority arbitration circuit whose specification is as belows: 1. There are 27 interrupt requests, int_req[26:0] 2. Assume that int_req[0] always has higher priority than int_req[1], int_req[1] has higher prority than int_req[2], and so on, ...int_req[26] has lowest priority 3. The circuit must be designed by using only combinational logics to get quick respone latency

My first idea to design this circuit can be explained by using Verilog as follows:

input [26:0] int_req; //Request output [26:0] int_gnt; //Grant

assign int_gnt[0] = int_req[0]; //Always accepted assign int_gnt[1] = ~int_req[0] & int_req[1]; assing int_gnt[2] = ! (int_req[0] & int_req[1]) & int_req[2]; ...... assign int_gnt[26] = ! (int_req[0] & ... & int_req[25]) & int_req[26];

However, when I synthesized my design, the timing constraint could not be met due to high speed (high clock frequency).

Anyone who knows how to desing this kind of circuit well, would you kindly teach me ?

In addition, could you please tell me some books or website on internet where I can learn how to design an arbitration circuit effectively ?

Thank you very much,

Best regards, Quang Anh

Reply to
Quang Anh
Loading thread data ...

If the interrupts can arrive at any time, this won't work with combinational logic... you'll get occasional erroneous codes as int requests arrive in arbitrary time sequences. The best bet would be to latch all the int requests in a big clocked register, run that through a priority encoder, and re-register the output of that. The clock period needs to be long enough to resolve the metastability settling time of the input latches plus the prop delay time of the encoder.

How fast would you like to do this?

John

Reply to
John Larkin

On Wed, 25 Apr 2007 07:19:37 -0700, Quang Anh wrote: ...

I've heard of it. ;-)

Welcome to the nuthouse! ;-)

You're getting too deep - you need more parallel power. You might take a look at the schematic of the 74148 for ideas on how to get it more parallel:

formatting link

Nah, that link is pretty much all I've got.

formatting link

Good Luck! Rich

Reply to
Rich Grise

Cascade some smaller encoders, say 6X 1 of 5, which then go to a 1 of 6, or 5X 1 of 6, which go to a 1 of 5. That'll give you 30 inputs, which you don't have to use all of, and will eliminate a whole bunch of gate delays from the data path.

Good Luck! Rich

Reply to
Rich Grise

Since he has so many inputs, I think he may be better off putting the first flip-flops part way down the encoding chain. For performance, it would likely be best to make the flip-flops as two sections of transparent latches (clocked from opposite edges) with an encoding stage between them.

Reply to
MooseFET

I'm sorry that I do not understand your instruction well. Would you kindly explain again ?

Thanks a lots. Quang Anh

Reply to
Quang Anh

Hi John,

I do not have to care about metastability. All I have to do is to return the reponse to module sent requests to tell it whether it wins the arbitration or not. I have to do it within on clock cycle. I do not allow to use register, only combinational gates are allowed to use. Could you please give me other advices ?

Reply to
Quang Anh

No advice, because it's impossible.

But you could latch the irq's on the falling edge of the clock (a transparent latch would be good) and have everything unambiguously resolved by the next rising edge.

How fast is "one clock cycle"? Who is making these rules? Is this real or an academic problem?

John

Reply to
John Larkin

Dear,

For performance,

Again, I'm so sorry that I do not understand the technique you mentioned above. Would you kindly explain me one more time ?

Reply to
Quang Anh

I had assumed that you could stand a clock cycle delay on the low priority inputs. If not the flip-flop idea can't be used.

Reply to
MooseFET

Hi John,

I've not checked mails these recent days. I've been in my hometown to enjoy 4-day holiday. Thank you so much for your reply.

In my current prj, we do not use falling-edge trigger flip flop, as well as latch. We only use rising-edge trigger flip flop. The reason is that those cells make STA (Static Timing Analysis) become very difficult, or even impossible. You know, we perform STA, mainly by EDA tool.

One clock cyle fast means the arbittraion should be done within one clock cycle. Let's me clarify it. + At a certain rising edge of clock signal, the request is sent to the arbitraion module (there may be more than 1 request) + The arbitration module must arbitrate, and inform the requester whether it has won the right. This work must be done within on clock cyle so that at the next rising edge of clock, the requester will know that.

My project manager :). He told me that he defined so because the latency of interrupt controller had significant effect on the overall performance of the system.

It's a real work. As I said before, I'm working for a hardware company.

I hope my answers above can clarify my problem. If you have any other idea to help me, kindly let me know. I've still not solved the problem by myself. I also wrote a mail to my project manager, but he's very busy. He just told me that "let's try your best" :(

Sincerely, Quang Anh

Reply to
Quang Anh

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.