A Community of Verification Professionals

Create an Account	Home | Calendar | Downloads | FAQ | Links | Site Admin | Your Account
Login Nickname Password Security Code: Type Security Code BACKWARD Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name. Modules · Home · Downloads · FAQ · Feedback · Recommend Us · Web Links · Your Account Advertising Who's Online There are currently, 45 guest(s) and 0 member(s) that are online. You are Anonymous user. You can register for free by clicking here    Verification Guild: Forums  Forum FAQ   Search   Usergroups   Profile  Digest    Log in  Logical vs Bitwise operators in Verilog Goto page 1, 2  Next          Verification Guild Forum Index -> Design View previous topic :: View next topic   Author Message vhdlcohen Industry Expert Joined: Jan 05, 2004 Posts: 1237 Location: Los Angeles, CA Posted: Wed May 12, 2004 2:03 pm    Post subject: Logical vs Bitwise operators in Verilog Note from the moderator: this topic has been split from this topic I do have acomment about your coding style. Specifically, in your PSL and Verilog code you tend to use logical operators instead of Boolean operators. For example: Code: property not_b_or_c_until_a  =   1'b1 -> (~b & ~c) until_ a;  should be (assuming objects are bits: property not_b_or_c_until_a  =   1'b1 -> (!b && !c) until_ a; same thing for your Verilog Instead of assign valid_in = (active_s & (set | valid_s)); DO this: assign valid_in = (active_s && (set || valid_s)); Having done several code reviews, I am sensitive to style. Verilog is very forgiving! Ben _________________ Ben Cohen http://www.systemverilog.us/ * SystemVerilog Assertions Handbook, 3rd Edition, 2013 * A Pragmatic Approach to VMM Adoption * Using PSL/SUGAR ... 2nd Edition * Real Chip Design and Verification * Cmpt Design by Example * VHDL books Back to top romi Senior Joined: Feb 28, 2004 Posts: 88 Location: Minnesota Posted: Wed May 12, 2004 2:14 pm    Post subject: I never use the boolean operators. If the signals are 1 bit, it shouldn't matter. I know the difference between the two. Code: a[5:0] & b[5:0] // is not the same as a[5:0] && b[5:0] I've just never had a use for the boolean operators. I ALWAYS put the "[5:0]" on my signals if they are a vector, even if the entire vector is being assigned or referenced. It's much more clear to me. Back to top Janick Site Admin Joined: Nov 29, 2003 Posts: 1382 Location: Ottawa, ON Canada Posted: Wed May 12, 2004 2:47 pm    Post subject: Re: Logical vs Bitwise operators in Verilog Quote: I've just never had a use for the boolean operators. It's a question of intent. Are you bashing bits? or are you making a decision? Use bitwise operators for the former and logical operators for the latter. I also do like the implicit "zero is false" in verilog and go further than Ben and always do: Code: property not_b_or_c_until_a  =   1'b1 -> (b == 1'b0 && c == 1'b0) until_ a == 1'b1; Quote: I ALWAYS put the "[5:0]" on my signals if they are a vector, even if the entire vector is being assigned or referenced. Another thing I do not do. What if the size of the signal changes? You now have to change every reference to it. Plus there is also the issue of intent: Are you selecting just some bits out of a wider signals (which may happen to be all of them) or all of the signal (reguardless of how wide it is)? I prefer to use a linting tool to catch size mismatches. With these two style elements in mind, the following is now clear: Code: reg [5:0] a,b; a & b   // Bitwise-operation on all of a & b, reguardless of size a != 0 && b != 0  // Decision based on the value of a & b,                   // reguardless of their size Back to top romi Senior Joined: Feb 28, 2004 Posts: 88 Location: Minnesota Posted: Wed May 12, 2004 2:57 pm    Post subject: Quote: It's a question of intent. I read them all the same way. So to me the intent is the same in all of them. Code: // if a is not 1 and b is not 1 then the result is 1 ~a & ~b !a && !b a=1'b0 && b=1'b0 How would the intent be interpretted any differently? Back to top Janick Site Admin Joined: Nov 29, 2003 Posts: 1382 Location: Ottawa, ON Canada Posted: Wed May 12, 2004 3:01 pm    Post subject: Code: ~a & ~b This I would use in implementation, when I want to compute a combinatorial value based on a and b, as in: Code: assign c = ~a & ~b; Code: !a && !b a==1'b0 && b==1'b0 These two are equivalent and I would use them in conditional expressions, if statements or temporal expressions, as in: Code: assign c = (!a && !b) ? d : f; if (a==1'b0 && b==1'b0) o = 'bz; Last edited by Janick on Wed May 12, 2004 3:03 pm; edited 1 time in total Back to top romi Senior Joined: Feb 28, 2004 Posts: 88 Location: Minnesota Posted: Wed May 12, 2004 3:02 pm    Post subject: Quote: What if the size of the signal changes? You now have to change every reference to it. It's one replace all. Quote: I prefer to use a linting tool to catch size mismatches. It's not a matter of catching it, it's a matter of knowing the width when reading it. You have to go back to the definition if it's left off. Quote: Plus there is also the issue of intent: Are you selecting just some bits out of a wider signals (which may happen to be all of them) or all of the signal (reguardless of how wide it is)? I don't see why anyone would need to know if you are using all or some of the bits. If they did they could go back to the definition. I think this case is much less likely than all the times you need to go back to the definition when the vector range is not included. Last edited by romi on Wed May 12, 2004 3:11 pm; edited 2 times in total Back to top romi Senior Joined: Feb 28, 2004 Posts: 88 Location: Minnesota Posted: Wed May 12, 2004 3:04 pm    Post subject: I understand how people use them in different places. People do it in my group just as you explained. My problem is doing two different things that come out with the same answer. The hardware is the same. Are there cases where the answer is different that I'm missing. Maybe I just never hit them. Last edited by romi on Wed May 12, 2004 3:14 pm; edited 1 time in total Back to top Janick Site Admin Joined: Nov 29, 2003 Posts: 1382 Location: Ottawa, ON Canada Posted: Wed May 12, 2004 3:14 pm    Post subject: romi wrote: It's one replace all. Maybe. Maybe not. What if this signal implements configuration register whose format went from: Code: +---+---+---+---+ |      FOO      | +---+---+---+---+ to: Code: +---+---+---+---+---+ | X |      FOO      | +---+---+---+---+---+ The "foo" parameter is just a position within your register, independent of its size. It may have additional bits, it may not. A global replace may unintended consequences. Quote: It's not a matter of catching it, it's a matter of knowning the width when reading it . If your implementation does not depend on the number of bits, why specify it all the time? For example, the size of an FSM state register is functionally irrelevant. So why always do: Code: case (fsm_state[4:0]) ... The behavior of a counter is similarly independent of its size (except in VHDL where you have to use the modulus operator Code: always @ (posege clk) begin    count <= count + 1; end Back to top romi Senior Joined: Feb 28, 2004 Posts: 88 Location: Minnesota Posted: Wed May 12, 2004 3:19 pm    Post subject: Quote: The behavior of a counter is similarly independent of its size (except in VHDL where you have to use the modulus operator It sure would be nice to know how big the counter is. How close to full is it getting? I think this goes towards my argument. Maybe if I was using paramters as widths, I would see your point more. However, I never use them in my design (I would if I needed to). Back to top romi Senior Joined: Feb 28, 2004 Posts: 88 Location: Minnesota Posted: Wed May 12, 2004 3:28 pm    Post subject: My bottom line argument is that I debug a lot of code and get more frustrated with not seeing the vectors width than not knowing if it's the entire vector being represented. I probably can't come up with all the reasons why, but it's what my experience tells me. Maybe not using vectors is easier/better when writing the code, but using the vectors is better when debugging the code. If that's the case (which I'm sure people will argue is not), then you'd obviously want to make debuggin easier since that's a much longer part of a schedule than entry. Back to top Janick Site Admin Joined: Nov 29, 2003 Posts: 1382 Location: Ottawa, ON Canada Posted: Wed May 12, 2004 3:34 pm    Post subject: romi wrote: you'd obviously want to make debuggin easier since that's a much longer part of a schedule than entry. No argument there! I've personally spent 2 hours helping a designer figure out why his MSB was always cleared... thanks to Verilog's silent zero-extension of mismatched widths in assignments. But for this particular case, wouldn't a linting tool be more appropriate to ensure that (this particular aspect of) the code is written right the first time and not wait until debug time? The most important thing about guidelines is that they be consistently followed... whatever they may be. If your coding style works for you, stick with it! If anyone else join your team, make them stick to it, even if they do not like it. Back to top romi Senior Joined: Feb 28, 2004 Posts: 88 Location: Minnesota Posted: Wed May 12, 2004 3:40 pm    Post subject: Quote: The most important thing about guidelines is that they be consistently followed... whatever they may be. If your coding style works for you, stick with it! If anyone else join your team, make them stick to it, even if they do not like it. I agree. Fortunately, I kind of have a forcing function to make them want to adhere to some of my guidelines. I wrote a script that declares all regs and wires for the writer automatically if some simple rules are followed like always specifying a vector width on the assignment! At least this get's them half way there. We also have linting tools that get run prior to a release to catch width problems. Back to top vhdlcohen Industry Expert Joined: Jan 05, 2004 Posts: 1237 Location: Los Angeles, CA Posted: Fri May 14, 2004 12:28 am    Post subject: Quote: I also do like the implicit "zero is false" in verilog and go further than Ben and always do: Code: property not_b_or_c_until_a  =   1'b1 -> (b == 1'b0 && c == 1'b0) until_ a == 1'b1; The issue I have with Janick's explicit definition of the expression is readability and the level of definition. The whole purpose of a property specification language, be PSL or SVA, is that it expresses in a readble manner the intent, particularly when the level of defintion is at the higher level (i.e., not RTL), and signals are bilevel (i.e., bits). Thus, in English, to express this requirement: Code: "upon a bus request, the acknowledge shall be provided within 5 cycles after the request, provided there is no cancel or reset".  Notice that the English does NOT state: Code: "upon a bus request equal to 1'b1, the acknowledge shall be provided at a level of 1'b1 within 5 cycles after the request (set to 1'b1) , provided there is no cancel (set to 1'b1)  or reset set to 1'b0"." So why would would want to overburden the properties with all those 1'b1? Code: // Ben's style  always ({bus_req} |-> {[*0:5]; ack} abort (cancel || !reset_n)) The idea is to make the PSL or SVA readable, like English. If the signals have 'X's or 'Z's, then I'll buy the idea of being explicit. _________________ Ben Cohen http://www.systemverilog.us/ * SystemVerilog Assertions Handbook, 3rd Edition, 2013 * A Pragmatic Approach to VMM Adoption * Using PSL/SUGAR ... 2nd Edition * Real Chip Design and Verification * Cmpt Design by Example * VHDL books Back to top Janick Site Admin Joined: Nov 29, 2003 Posts: 1382 Location: Ottawa, ON Canada Posted: Fri May 14, 2004 7:11 am    Post subject: vhdlcohen wrote: Code: "upon a bus request, the acknowledge shall be provided within 5 cycles after the request, provided there is no cancel or reset".  Notice that the English does NOT state: Code: "upon a bus request equal to 1'b1, the acknowledge shall be provided at a level of 1'b1 within 5 cycles after the request (set to 1'b1) , provided there is no cancel (set to 1'b1)  or reset set to 1'b0"." So why would would want to overburden the properties with all those 1'b1? The first specification is ambiguous and lacks the following additional statement Code: All signals, except reset, use positive logic and are asserted high. The reset signal is asserted low. I think a better description would be to use events to abstract the "request", "grant", "cancel" and "reset" so the assertion can be expressed independently of their implementation (forgive my lack of knowledge of the PSL syntax - if someone cares to supply me with the correct syntax, I'll edit my message to correct it): Code: event request  = bus_req == 1'b1; event grant    = ack == 1'b1; event canceled = cancel == 1'b1; event reset    = reset_n == 1'b0; always (request |-> {[*0:5]; grant } abort (canceled || reset)); But as I said earlier, these are only guidelines. Even I don't follow them all the time Back to top vhdlcohen Industry Expert Joined: Jan 05, 2004 Posts: 1237 Location: Los Angeles, CA Posted: Fri May 14, 2004 10:13 am    Post subject: The event stuff is WAY TOO MUCH CODE!. Besides, VHDL does not support the Verilog event! Ok, so we seem to agree to disagree on style on this. Bernard or Srini, any opinions or rebuttal? Thanks, Ben _________________ Ben Cohen http://www.systemverilog.us/ * SystemVerilog Assertions Handbook, 3rd Edition, 2013 * A Pragmatic Approach to VMM Adoption * Using PSL/SUGAR ... 2nd Edition * Real Chip Design and Verification * Cmpt Design by Example * VHDL books Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         Verification Guild Forum Index -> Design All times are GMT - 5 Hours Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum Main----------------MainEDA NewsCommunity Services Networking----------------Looking for a jobLooking for candidates Archives----------------AssertionsCoverageFormalSimulationDesignMiscellaneous Test----------------Test  You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Forums ©

Verification Guild © 2006 Janick Bergeron
Web site engine's code is Copyright © 2003 by PHP-Nuke. All Rights Reserved. PHP-Nuke is Free Software released under the GNU/GPL license.
Page Generation: 0.803 Seconds