[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ethmac] operator precedence



The problem should not be very serious. It is less serious if we know what simulation/synthesis tools interpret these 
expressions as intended.

Most tools should agree with the future Verilog LRM because it also agrees with the old Verilog LRM from OVI. The LRM from 
OVI does not show "~|" in the precedence table, and it also says the precedence order is the same as in C. In C, unary 
operators always have higher precedence than binary operators. So, only new tools developed after 1995 might be different.

It is still good to know the possibility that this MAC core might behave differently if you use different tools.

At least, we should add parentheses when we accidentally see these problems. When we debug problems, it might help to 
remember this issue.

Thanks,
Jeff

----- Original Message ----- 
From: "Igor Mohor" <igorm@o... > 
To: <ethmac@o... > 
Date: Fri, 11 Oct 2002 18:46:31 +0200 
Subject: RE: [ethmac] operator precedence 

> 
> 
> Sorry, 
> 
> but at the moment I don't have time to go through all files and add 
> parentheses as you suggested. 
> 
> Regards, 
> 	Igor 
> 
> 
> 
> > -----Original Message----- 
> > From: owner-ethmac@o...  
> [mailto:owner-ethmac@o... ]On 
> > Behalf Of zjli@t...  
> > Sent: 11. oktober 2002 21:28 
> > To: zjli@t... ; ethmac@o...  
> > Subject: Re: [ethmac] operator precedence 
> > 
> > 
> > The precedence of unary "|" is not completely clear in IEEE 
> 1364-1995 
> > and IEEE 1364-2001. Under the section title "Binary operator 
> > precedence", "|" is listed only once while "+" and "-" are 
> listed 
> > as binary 
> > and unary separately. I took this "|" as both unary and binary 
> > because "|" and "~|" are listed as having the same precedence, 
> > and "~|" is always unary. 
> > 
> > The draft LRM for the future Verilog standard clearly listed 
> that 
> > all unary 
> > operators have higher precedence than all binary operators. 
> > 
> > It is a good idea to add parentheses in such cases. 
> > 
> > ----- Original Message ----- 
> > From: zjli@t... 
> > To: ethmac@o... 
> > Date: Wed, 9 Oct 2002 22:40:41 -0100 
> > Subject: [ethmac] operator precedence 
> > 
> > > 
> > > 
> > > In eth_receivecontrol.v, "if(|PauseTimer[15:0] & 
> RxFlow)" is 
> > > currently 
> > > used for computing Divider2. Apparently, it meant 
> "if((|PauseTimer 
> > > [15:0]) & RxFlow)" but it could mean 
> "if(|(PauseTimer[15:0] 
> > > & RxFlow))" 
> > > according to both IEEE 1364-1995 and IEEE 1364-2001. 
> > > 
> > > I am curious what tools did not agree with my 
> interpretation of 
> > > IEEE 
> > > standards. 
> > > 
> > > Thanks, 
> > > Jeff 
> > > 
> > 
> > 
> 
--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml