FPGA Central

Hi,
I have a question, does this code means that when I 'm in the IDLE
state , first the arbiter checks if req0_ == ON and THEN req1_ ==
ON ?!
or they take place in the same time ?!

The Code :

always @(curr_state or req0_ or req1_ or req2_ or req3_ or req4_ or
req5_ or req6_ or req7_)
begin
next_state = 0;

case(curr_state)

IDLE:

begin
if(req0_ == ON)
begin
next_state = GNT0;
end
else
if(req1_ == ON)
begin
next_state = GNT1;
end
...
. ...

thanks in advance
-Amir

On Aug 31, 5:56 am, Amir <sting...@gmail.com> wrote:
> Hi,
> I have a question, does this code means that when I 'm in the IDLE
> state , first the arbiter checks if req0_ == ON and THEN req1_ ==
> ON ?!
> or they take place in the same time ?!
>
> The Code :
>
> always @(curr_state or req0_ or req1_ or req2_ or req3_ or req4_ or
> req5_ or req6_ or req7_)
> begin
> next_state = 0;
>
> case(curr_state)
>
> IDLE:
>
> begin
> if(req0_ == ON)
> begin
> next_state = GNT0;
> end
> else
> if(req1_ == ON)
> begin
> next_state = GNT1;
> end
> ...
> . ...
>
> thanks in advance
> -Amir


It's not a matter of time, but of priority. The "else"
clause ensures that next_state only goes to GNT1 if
(req1_ == ON) _AND_ _NOT_ (req0_ == ON)

In other words req0_ has higher priority than req1_
in the case where they are both "ON".

By the way, if you leave out the "else" in the above code
exacly the opposite is true. In this case req1_ would
have higher priority as it is evaluated last. You
could think of this as a sequential (time) issue, and
in fact this is how simulators work, but the synthesized
logic is still just AND and OR gates that must evaluate
the inputs in parallel.

HTH,
Gabor

So does the synthesized logic have chances of races if there are two
separate if as mentioned by Gabor in the end of the last mail

It is extremely likely that they will be checked simultaneously in
synthesized hardware. However, it is possible that you can get
artifacts in your simulation, because they may be tested sequentially
in the simulator (and potentially the values could change in between
the tests). I'm not certain you could find text in the standard that
would require them to be tested sequentially and would allow one to
construct a test that would only work if they were tested
sequentially.

On Aug 31, 3:27 pm, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
wrote:
> So does the synthesized logic have chances of races if there are two
> separate if as mentioned by Gabor in the end of the last mail

In order to avoid simulation/synthesis mismatches, it is better to
code it in another way:

case (curr_sate)
IDLE:
case ({req0_,req1})
...

considering all possible req0, req1_ combinations.


-Alex

thanks for the replies.
I wrote a round robin arbiter, using the method in the first message,
but it doesn't seem to work, I mean all the 'priority' that Gabor
talked about.
the arbiter should give grant to the requests, and the requests should
be "ON" as long as the client needs the bus.
I used also idle states between the grants, but nothing seems to
work ..
you have any advice ?

thanks
-Amir

Two questions here:

1. Is it okay to set the next_state to 0 before the
case(current_state)? I thought this would cause a glitch if the next
state changes in the case statement.

2. Shouldn't we use <= and not = since we're putting these statements
in an always @ block?




On Aug 31, 2:56 am, Amir <sting...@gmail.com> wrote:
> Hi,
> I have a question, does this code means that when I 'm in the IDLE
> state , first the arbiter checks if req0_ == ON and THEN req1_ ==
> ON ?!
> or they take place in the same time ?!
>
> The Code :
>
> always @(curr_state or req0_ or req1_ or req2_ or req3_ or req4_ or
> req5_ or req6_ or req7_)
> begin
> next_state = 0;
>
> case(curr_state)
>
> IDLE:
>
> begin
> if(req0_ == ON)
> begin
> next_state = GNT0;
> end
> else
> if(req1_ == ON)
> begin
> next_state = GNT1;
> end
> ...
> . ...
>
> thanks in advance
> -Amir

On Sep 3, 11:29 pm, Mahurshi Akilla <mahur...@gmail.com> wrote:
> Two questions here:
>
> 1. Is it okay to set the next_state to 0 before the
> case(current_state)? I thought this would cause a glitch if the next
> state changes in the case statement.
>

This is fine. It would create a glitch in simulation with
zero width, but for synthesis just gives a default assignment
if there is no other assignment below. Assuming no logic
uses the output of the assignment (next_state) as a clock
source there should be no problems.

> 2. Shouldn't we use <= and not = since we're putting these statements
> in an always @ block?
>

This is a combinatorial always block, so the blocking assignment
is correct here. Use non-blocking <= assignments for registered
always @ (posedge clk) style blocks for synthesis.

Presumably there is another block like:

always @(posedge clock or posedge reset)
if (reset)
curr_state <= 0;
else
curr_state <= next_state;

so the sequential logic is not in the always block originally
posted.

> On Aug 31, 2:56 am, Amir <sting...@gmail.com> wrote:
>
> > Hi,
> > I have a question, does this code means that when I 'm in the IDLE
> > state , first the arbiter checks if req0_ == ON and THEN req1_ ==
> > ON ?!
> > or they take place in the same time ?!
>
> > The Code :
>
> > always @(curr_state or req0_ or req1_ or req2_ or req3_ or req4_ or
> > req5_ or req6_ or req7_)
> > begin
> > next_state = 0;
>
> > case(curr_state)
>
> > IDLE:
>
> > begin
> > if(req0_ == ON)
> > begin
> > next_state = GNT0;
> > end
> > else
> > if(req1_ == ON)
> > begin
> > next_state = GNT1;
> > end
> > ...
> > . ...
>
> > thanks in advance
> > -Amir