Hello Folks; Sorry for the typo the modified netlist should be reg function_temp; always @(posedge ck54 or negedge p_rst_x) begin if (~p_rst_x) dout <= 3'd0; else begin if (enable) function_temp = din; dout = function_temp; end end Thanks and regards Satyakam ________________________________ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Satyakam Sudershan Sent: Wednesday, December 10, 2008 5:26 PM To: Brad Pierce; sv-bc@eda.org Subject: RE: [sv-bc] RE: functional if statement Thanks All for the answers; So am I right in saying that the function call would be identical to the following (considering the static semantics) reg function_temp; always @(posedge ck54 or negedge p_rst_x) begin if (~p_rst_x) dout <= 3'd0; else begin if (enable) function_temp = din; dout = din; end end Where the original was always @(posedge ck54 or negedge p_rst_x) begin if (~p_rst_x) dout <= 3'd0; else dout <= func( enable, din); end function func; input enable; input din; reg temp; begin if (enable) temp = din; func = temp; // Latch inferred end endfunction Thanks and regards Satyakam ________________________________ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad Pierce Sent: Wednesday, December 10, 2008 1:01 AM To: sv-bc@eda.org Subject: RE: [sv-bc] RE: functional if statement > I wish no tool would allow a task/function to be declared with a static lifetime other than to support legacy Verilog code. I wish that SystemVerilog would just break backward compatibility and make the default subroutine lifetime 'automatic'. A compiler directive could be added for legacy purposes, such as `default_subroutine_lifetime static -- Brad From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rich, Dave Sent: Tuesday, December 09, 2008 9:30 AM To: Bresticker, Shalom; Satyakam Sudershan; Kapil Kaushik; sv-bc@eda.org Subject: RE: [sv-bc] RE: functional if statement I'm assuming that roots of this question have to do with the synthesizability of functions with static lifetimes. It's unfortunate that we're stuck with Verilog-1995 semantics that had no concept of a call stack. All local variables including arguments of tasks and functions are static variables. You would be doing people a favor by warning them when they reference a variable before writing to it in functions. Or make it a synthesizable error. Verilog-2001 added automatic lifetimes to individual tasks and functions, and SystemVerilog added automatic lifetimes to individual modules so that all embedded task and function definitions have an automatic lifetimes. Tasks and functions defined in classes have an automatic lifetime by default. I wish no tool would allow a task/function to be declared with a static lifetime other than to support legacy Verilog code. Of course, a tool could optimize a static lifetime to automatic if there would be no visible differences in functionality. Dave ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Tuesday, December 09, 2008 7:15 AM To: Satyakam Sudershan; Kapil Kaushik; sv-bc@server.eda.org Subject: [sv-bc] RE: functional if statement On the first call of the function, temp will have the value X. However, on subsequent calls, temp will retain its previous value. For example, if on the first call, enable is 1, then temp will be assigned din. On the second call, if enable is 0, then temp will have the value assigned on the first call. Shalom ________________________________ From: Satyakam Sudershan [mailto:satyakam@Magma-DA.COM] Sent: Tuesday, December 09, 2008 5:00 PM To: Bresticker, Shalom; Kapil Kaushik; sv-bc@server.eda.org Subject: RE: functional if statement Thanks Shalom; I agree that if we try and implement a flip-flop the way you suggest would be right; the question I am however asking you now (which is admittedly different) is that given the Verilog semantics; should the function call return in expression (enable ? din : X) Sorry for the bother and thanks in advance. Regards, Satyakam ________________________________ From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Tuesday, December 09, 2008 8:26 PM To: Satyakam Sudershan; Kapil Kaushik; sv-bc@server.eda.org Subject: RE: functional if statement The question asked was: Given the above description, can I replace the command "dout <= func(enable,din)" by "dout <= enable ? din : 1'bx"? The original code given was apparently intended to model a flip-flop. I interpreted the question as being how can "if (enable) dout = din;" be replaced by a one-line assignment that will give the same functionality. Since in "if (enable) dout = din;", if enable is false, no assignment is made to dout, then dout retains its previous value. "dout <= enable ? din : dout;" achieves that purpose. Shalom ________________________________ From: Satyakam Sudershan [mailto:satyakam@Magma-DA.COM] Sent: Tuesday, December 09, 2008 4:47 PM To: Kapil Kaushik; Bresticker, Shalom; sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org Subject: RE: functional if statement Hello Shalom; Sorry to bother you; but I have the following confusion on this and would greatly appreciate your help. Verilog states 1) That all reg have an initial value X; 2) A function returns a complete expression. With respect to the following function; does it mean that the return expression of the function should be independent of the calling context and hence should return the expression (enable ? din : X). Is that understanding correct? function func; input enable; input din; reg temp; begin if (enable) temp = din; func = temp; // Latch inferred end endfunction Thanks and regards Satyakam ________________________________ From: Kapil Kaushik Sent: Tuesday, December 09, 2008 7:32 PM To: Bresticker, Shalom; sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org Cc: Satyakam Sudershan Subject: RE: functional if statement Hi Shalom, Thanks for the clarification. Regards, Kapil ________________________________ From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Tuesday, December 09, 2008 7:28 PM To: Kapil Kaushik; sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org Cc: Satyakam Sudershan Subject: RE: functional if statement Should be. Shalom ________________________________ From: Kapil Kaushik [mailto:kkapil@Magma-DA.COM] Sent: Tuesday, December 09, 2008 3:51 PM To: Bresticker, Shalom; sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org Cc: Satyakam Sudershan Subject: RE: functional if statement Yes, sorry, a typo on my part. After correction, are the two equivalent? Thanks, Kapil ________________________________ From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Tuesday, December 09, 2008 4:45 PM To: Kapil Kaushik; sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org Cc: Satyakam Sudershan Subject: RE: functional if statement I don't see the connection between this and standards work, but I'll answer anyway. What you probably want is dout <= enable ? din : dout; Shalom ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Kapil Kaushik Sent: Tuesday, December 09, 2008 1:05 PM To: sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org Cc: Satyakam Sudershan Subject: [sv-bc] functional if statement Hi, I have the following piece of rtl: always @(posedge ck54 or negedge p_rst_x) begin if (~p_rst_x) dout <= 3'd0; else dout <= func( enable, din); // if (enable) // Works fine // dout = din; // Works fine end function func; input enable; input din; reg temp; begin if (enable) temp = din; func = temp; // Latch inferred end endfunction Given the above description, can I replace the command "dout <= func(enable,din)" by "dout <= enable ? din : 1'bx"? Kindly suggest. Thanks, Kapil -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Dec 10 04:09:49 2008
This archive was generated by hypermail 2.1.8 : Wed Dec 10 2008 - 04:10:03 PST