Add Proposal | Add Analysis | Edit Class, Environment, or Release |
Number | 502
|
Category | enhancement
|
Synopsis | Dynamic Values on attributes
|
State | open
|
Class | enhancement
|
Arrival-Date | Nov 05 2003
|
Originator | Shalom.Bresticker@motorola.com
|
Release | 2001b
|
Description |
This mail is to enter this enhancement request into the database. ---------- Forwarded message ---------- Date: Thu, 30 Oct 2003 14:25:33 -0800 From: Krishna Garlapati <krishna@synplicity.com> To: btf@boyd.com Subject: Enhancement: Dynamic Values on attributes. Frequently, our users ask for a method by which attributes can be created dynamically. Basically they want a convenient way to associate new values to attributes that are a combination of strings and compile time constants. This usage is typically associated with generate statements and I have an example in the end. The existing $swrite can be used, but is not very intuitive. To achieve this we have implemented a system function called $strcat in our Verilog Compiler and would like it to make into the 1364 standard. The format of this function is as follows: * Format* $strcat(string (or) const [, string (or) const]); returns a string *Parameters* string -> any compile time string const -> any compile time constant *Return value* a concatenated string that consists of all the evaluated parameters *Example:* generate for(i=0; i <= 7; i = i+1) begin: my_reg (* xc_rloc=$strcat("R",i,"C0.S0"),xc_uset="SET1" *) FDE flip_flop (.D(d[i]), .CE(ce),.C(clk),.Q(qb[i])); // myreg0.flip_flop gets an attribute xc_rloc = "R0C0.S0" // myreg0.flip_flop gets xc_rloc = "R1C0.S0" // and so on... end endgenerate Thanks, -- - Krishna Garlapati, Synplicity Inc. (408)215-6152 |
Fix |
Unknown |
Audit-Trail |
From: Shalom.Bresticker@motorola.com To: btf-bugs@boyd.com Cc: Subject: Re: enhancement/502: Dynamic Values on attributes Date: Wed, 5 Nov 2003 12:40:28 +0200 (IST) This mail is to enter the entire dicussion on this issue into the database. Please send further discussion to btf-bugs@boyd.com with subject "enhancement/502". Thanks, Shalom Date: Thu, 30 Oct 2003 14:25:33 -0800 From: Krishna Garlapati <krishna@synplicity.com> Subject: Enhancement: Dynamic Values on attributes. Frequently, our users ask for a method by which attributes can be created dynamically. Basically they want a convenient way to associate new values to attributes that are a combination of strings and compile time constants. This usage is typically associated with generate statements and I have an example in the end. The existing $swrite can be used, but is not very intuitive. To achieve this we have implemented a system function called $strcat in our Verilog Compiler and would like it to make into the 1364 standard. The format of this function is as follows: *Format* $strcat(string (or) const [, string (or) const]); returns a string *Parameters* string -> any compile time string const -> any compile time constant *Return value* a concatenated string that consists of all the evaluated parameters *Example:* generate for(i=0; i <= 7; i = i+1) begin: my_reg (* xc_rloc=$strcat("R",i,"C0.S0"),xc_uset="SET1" *) FDE flip_flop (.D(d[i]), .CE(ce),.C(clk),.Q(qb[i])); // myreg0.flip_flop gets an attribute xc_rloc = "R0C0.S0" // myreg0.flip_flop gets xc_rloc = "R1C0.S0" // and so on... end endgenerate Date: Thu, 30 Oct 2003 18:31:18 -0500 (EST) From: Steven Sharp <sharp@cadence.com> In Verilog-2001, attribute values can already be set using constant expressions. This allows them to be defined in terms of compile time constants such as parameters and genvars. They can even use constant functions to compute things that are not easily done with expressions. This would appear to provide the basic functionality that you are talking about. I am not aware of any tools that support anything but simple constants for attribute values (and some apparently only accept strings), but that is not the fault of the 2001 standard. Beyond this, what you are proposing effectively involves two extensions. The first is to allow certain system functions to be used in constant expressions. This is already mentioned in a couple of the proposals that I have made. This seems reasonable for system functions that are "pure" functions. The second is a new standard system function called $strcat, which works much like $swrite but is a function instead of a task (so it could be used in constant expressions). While neither of these is unreasonable, I don't think that the solution to your particular problem requires them. The reason it appears to be needed is that the genvars or parameters that you want to use to set the values are numerical values. But your tool has defined a set of attributes that it expects to be set using string values, with numbers encoded as sequences of characters. "Printing" a numerical value into a string form is a complex operation, and your proposal is to do this with a system function. But there is a simpler solution to this. The only reason for this complex operation is that you chose to define the attributes for your tool to expect strings instead of numerical values. It just isn't a very convenient format for values you want to compute numerically. If you redefined the attributes to be numerical values instead, then this would all become simple to do in Verilog-2001. If you need to maintain backward compatibility, you could accept either the old attribute values which are strings, or the new ones which are numbers. From your example, it appears that "xc_rloc" takes a string that holds a row and column position encoded by strings of digits after "R" and "C" (I'll ignore the ".S" part, since I didn't understand what it was). You could do the same thing easily in Verilog-2001 by changing this to two attributes, "xc_rloc_R" and "xc_rloc_C", which take the row and column directly as numerical values instead of converted to strings. Then your example would become generate for(i=0; i <= 7; i = i+1) begin: my_reg (* xc_rloc_R=i, xc_rloc_C=0, xc_uset="SET1" *) FDE flip_flop (.D(d[i]), .CE(ce),.C(clk),.Q(qb[i])); // myreg0.flip_flop gets an attribute xc_rloc_R = 0 // myreg0.flip_flop gets xc_rloc_R = 1 // and so on... end endgenerate This works fine with the existing Verilog-2001 language. You just have to implement attributes fully as defined, and then change the attributes that your tool uses. It is possible that I am missing something here. Someone recently posted a question of how to do something like this in comp.lang.verilog. I answered with a description of 2001 attributes, and how the tool vendor could redefine their attributes to make this work, and I got flamed for my efforts. Date: Thu, 30 Oct 2003 16:36:09 -0800 From: Krishna Garlapati <krishna@synplicity.com> I guess my explanation for this request was not very clear. FPGA designers use these attributes primarily to pass custom information (like location, mapping methods, types etc) to the vendor backend. The vendor's backend tool expects a single attribute in a string form and ignores everything else. I agree with you that using multiple Vlog-2001 style attributes can achieve the requested functionality but it does not fulfill the purpose. My request is to simply provide a function that can take in a bunch of strings and constant expressions as parameters and return a string, which is the concatenated version that contains all the string parameters (as is) and evaluated constant expressions. I also think implementing this is pretty very straightforward. We have implemented attributes for VLog-2001 and I don't think there is a single system function that can realize this. A good percentage of our users are already using the $strcat and we think it would be a good idea to make it into the standard for compatibility issues. "From your example, it appears that "xc_rloc" takes a string that holds a row and column position encoded by strings of digits after "R" and "C" (I'll ignore the ".S" part, since I didn't understand what it was). You could do the same thing easily in Verilog-2001 by changing this to two attributes, "xc_rloc_R" and "xc_rloc_C", which take the row and column directly as numerical values instead of converted to strings." This is not acceptable to the users for the reasons I listed above. ""Printing" a numerical value into a string form is a complex operation," I am wondering why?? I dont see a big problem here or may be I am missing something. Date: Fri, 31 Oct 2003 10:46:31 -0800 From: Michael McNamara <mac@verisity.com> So it seems that $swrite almost fits the bill, but because it is a task rather than a function, one is stuck. However you say that the vendors tool wants a single attribute in a string; so this leads be to believer if there was a $strcat, it would not work: dff ff1 (q,d,clk) (* placement=$strcat(xloc,yloc,size) *) Note of course, that you don't need it to be a system function, however it may make it easier, as one could define scat_loc as a user constant function, which calls $swrite to do the work: function [80*8:1] scat_loc( input [31:0] xloc, yloc, size) begin $swrite(scat,"%d_%d_%s",xloc,yloc,size); end endfunction and then give the parameters: parameter [31:0] xloc = 1, [31:0] yloc = 1, [10*8:1] size = "small"; and the instantiation: dff ff1 (q,d,clk) (* placement=scat_loc(xloc,yloc,size) *) Or does the tool instead parse the verilog, and hence these constant functions will not be called? Date: Thu, 30 Oct 2003 18:54:24 -0800 From: Krishna Garlapati <krishna@synplicity.com> Apart from being stuck since $swrite is a task, there is another issue. The syntax for $swrite needs to provide an output register of proper size to which the resultant string is written. Our proposal does not need this since the output string "variable" is generated internally of appropriate size. >However you say that the vendors tool wants a single attribute in a >string; so this leads be to believer if there was a $strcat, it would >not work: I am not sure why. For, parameter [31:0] xloc = 1, [31:0] yloc = 1, [10*8:1] size = "small"; (* placement=$strcat(xloc,yloc,size) *) dff ff1 (q,d,clk) $strcat returns the string "11small" that gets assigned to placement and is carried on the instance ff1. I think the constant function example you cited will work. $strcat is very flexible since the users don't need to write a seperate constant function and allocate appropriate sizes for output strings. It's also pretty easy for the Verilog tool to do this since all the parameter sizes can (should) be determined at compile time. Date: Fri, 31 Oct 2003 09:51:48 -0600 From: Adam Krolnik <krolnik@lsil.com> It's too bad one can't write (* xc_rloc={"R",i,"C0.S0"}, xc_uset="SET1" *) and get the desired behavior. Though, it seems that SystemVerilog, with their string type, can do this. [* Table 3-2 that describes string concatenation is not very clear on cases like this.] If "i" was only expected to be a single character, one can today write: parameter astr = {"R",8'h30 + i,"C0.S0"}; // i=2 => astr=R2C0.S0 I.e. module test; parameter astr = {"R",8'h30 + 8'd2,"C0.S0"}; //(* astr = {"R",8'h30 + 8'd2,"C0.S0"} *) (* astr = astr *) reg adam; initial $display("astr parameter is %s.\n", astr); endmodule Date: Fri, 31 Oct 2003 11:04:03 -0800 From: Krishna Garlapati <krishna@synplicity.com> Looks like System Verilog does it nicely. But how does the tool figure out that you are dealing with strings in parameter unless the declaration was : parameter string astr = {"R",8'h30 + i,"C0.S0"}; // i=2 => astr=R2C0.S0 Date: Fri, 31 Oct 2003 13:11:35 -0600 From: Adam Krolnik <krolnik@lsil.com> >Looks like System Verilog does it nicely. But how does the tool >figure out that you are dealing with strings in parameter unless It's not clear as to what is supposed to happen. I will ask... Date: Fri, 31 Oct 2003 16:47:32 -0500 (EST) From: Steven Sharp <sharp@cadence.com> >The vendor's backend tool expects a single attribute in a string form and >ignores everything else. I agree with you that using multiple Vlog-2001 >style attributes can achieve the requested functionality but it does not >fulfill the purpose. As I understand it now, the problem is still due to a poor choice of attributes in the backend tool. But since it is not your tool you can't do anything about it, and you need a way to work around the problem. So I will accept that there is a real problem that needs to be solved here. I have some further comments on the proposed solution. I don't think that $strcat is a good choice for a name for this functionality. The name matches the standard C library function strcat(), but the functionality is significantly different. The strcat() function concatenates strings together. Your proposed $strcat concatenates string literals, but "prints" other values in (apparently) decimal format into a string and concatenates those strings. This is not the same, which could be very misleading. If someone set a parameter to a string value, and then used the parameter in your $strcat, they would not get that string value concatenated. Instead they would get the numerical equivalent of that string converted into a string of decimal digits, which look nothing like the original string value. For example: parameter p = "a"; parameter q = $strcat(p,"b"); This would not set q to "ab" as you would expect for a function with the same name as a C routine that concatenates strings. Instead it would set q to "97b", because the ASCII for "a" is 97, so the numerical value of p is 97. The proposed function is also not very general. You have arbitrarily decided that non-string-literal values should be converted to strings using a decimal format. This may serve your immediate need, but may not cover other similar situations. What happens when someone wants to pass in a mix of strings and numbers in parameters, and get the numbers converted into strings, but the strings kept intact? This really calls for a format argument, instead of converting all values using a decimal format. Then you could use %s to keep a value as a string, and %d to convert numerical values to decimal, and so forth. In addition to these issues, I see a fundamental problem here. What is the width of the expression containing the $strcat call? All expressions in Verilog must have a width that can be determined at compile time, and all existing constructs are designed to satisfy that requirement. You won't find this documented in the LRM because the user doesn't need to know it. The language has been designed so that it is always true. But any new constructs need to maintain this requirement. With this $strcat call, you presumably wanted the width to be exactly the minimum number of bits required to represent the resulting string. If all of the arguments are compile-time constants, then this is possible. The width can be determined (rather inconveniently) by actually evaluating the function and seeing what width was needed. But surely this new system function would not be restricted to constant values as arguments? And if it isn't, then how do you determine what the width of the result will be at compile time? The best suggestion I can come up with is to determine the maximum width that could be required for the result, based on the widths of the arguments (the same way that $display determines how much space to print a number in). Then you would have to produce a string of that width regardless of the actual values, padding the upper bytes with zero bytes as usual for extension to greater width. >""Printing" a numerical value into a string form is a complex operation," > >I am wondering why?? I dont see a big problem here or may be I am >missing something. I'm not saying that it can't be done. I am saying that it is complex enough that you can't do it easily in an expression. Nor would most users want to have to write a Verilog function capable of doing it. That is exactly why you are suggesting that it be done by a built-in system function. Date: Fri, 31 Oct 2003 16:49:17 -0500 (EST) From: Steven Sharp <sharp@cadence.com> >Note of course, that you don't need it to be a system function, >however it may make it easier, as one could define scat_loc as a user >constant function, which calls $swrite to do the work: Constant functions are not allowed to call system tasks (or if they do, the task is ignored). Date: Fri, 31 Oct 2003 16:53:33 -0500 (EST) From: Steven Sharp <sharp@cadence.com> >However you say that the vendors tool wants a single attribute in a >string; so this leads be to believer if there was a $strcat, it would >not work: Presumably Krishna means that their tool evaluates the attribute and prints out the value in its output, not the original expression. So the output would be the string, not the $strcat expression. Note that their tool is assuming that these things are strings. There is no real distinction between a string and a number in Verilog. They are both just vector values. Date: Fri, 31 Oct 2003 15:13:20 -0800 From: Krishna Garlapati <krishna@synplicity.com> You raise some valid points. I agree that the naming for $strcat is confusing and it can be discussed and agreed upon to which I have not any issue. The issue here is to provide functionality to something that is very commonly used in FPGA tools to send "messages" to the backend tools for which there exists no easy solution. As I indicated in my earlier email, the arguments to $strcat should be compile time constants (and hence a built-in constant function). So I think you will agree with me that determining the size is not a big issue. As far as the functionality of $strcat goes, currently our tools allow the usage of it only within attributes. I think it is perfectly if the LRM imposes the same restriction. The current implementation is something the users need now and Verilog lacked. We provided a workable solution that gets the job done. I think it would be great if Verilog can provide the support natively. Date: Mon, 03 Nov 2003 08:29:33 -0600 From: Adam Krolnik <krolnik@lsil.com> >But how does the tool figure out that you are dealing with strings in >parameter unless the declaration was : >parameter string astr = {"R",8'h30 + i,"C0.S0"}; // i=2 => astr=R2C0.S0 Each element is sized and then concatenated, just like verilog 1995. This line (below) is verilog-1995. You can do this today in VCS. The program I included compiles in VCS with the +v2k option for attributes. parameter astr = {"R",8'h30 + i,"C0.S0"}; // i=2 => astr=R2C0.S0 module test; parameter astr = {"R",8'h30 + 8'd2,"C0.S0"}; //(* astr = {"R",8'h30 + 8'd2,"C0.S0"} *) (* astr = astr *) reg adam; initial $display("astr parameter is %s.\n", astr); endmodule % vcs catstr.v ... Parsing design file '/tmp/catstr.v' Top Level Modules: test No TimeScale specified 1 unique modules to generate Invoking loader... Chronologic VCS simulator copyright 1991-2003 Contains Synopsys proprietary information. Compiler version 7.0.1; Runtime version 7.0.1; Nov 3 08:27 2003 astr parameter is R2C0.S0. Date: Mon, 03 Nov 2003 11:02:11 -0800 From: Krishna Garlapati <krishna@synplicity.com> Your example works for direct connstants (like 1+2) within parameters. But I don't think it will, when used in conjunction with variables that are constants at compile time (like genvars). genvar i; generate for(i=0; i<=7; i = i + 1)... parameter xc_rloc = {"R", i, "C0.S0"}; (* xc_rloc = xc_rloc *) foo bar(..port connections..) .. .. endgenerate In this example it is not clear which value of i would be binded to the the parameter declaration for xc_rloc. Moreover, I think parameter declarations are illegal within generates, they can only be overrided. I still think there is a need for a builtin constant function in Verilog that produces a concatenated string output on compile time constant values. Date: Mon, 03 Nov 2003 13:39:28 -0600 From: Adam Krolnik <krolnik@lsil.com> You don't need to parameter - I used it to view/test the results. You should be able to say: generate for(i=0; i<=7; i = i + 1)... (* xc_rloc = {"R", i, "C0.S0"} *) foo bar(..port connections..) As an attribute accepts a constant expression. I don't have a way to read attributes from the PLI yet... I do see a usefulness in creating a string of multiple arguments. Date: Mon, 3 Nov 2003 20:56:25 -0500 (EST) From: Steven Sharp <sharp@cadence.com> While you only need this functionality for this one particular use, it is easy to imagine that it might be useful in other situations as well. If we are going to add something like this, it makes sense to try to make it as useful as possible in return for the effort. While this could just be restricted to attribute values, it could also be useful to allow it for parameter values as well. Even in your attribute situation, someone might want to construct one of these attribute strings with $strcat and pass the value into a parameter using a parameter override on the instantiation, so that they can use that parameter value in setting an attribute inside the module. The main reason I originally proposed allowing constant expressions to be used for attributes (instead of just simple constant literals) is so that users could use parameters in attribute values. This allows them to use the existing mechanisms for parameter propagation to propagate values to be used for attributes. The fact that this also allows genvars to be used to set different attribute values for each instance was an unforeseen benefit of using good design principles. Both parameters and genvars can be used in constant expressions, and this is orthogonal to whether the constant expression is being used to set a parameter or attribute value. In the same way, if this new functionality is allowed in constant expressions for attribute values, it should be allowed for parameter values as well (and in any other situation where constant expressions are allowed). There might be unforeseen uses for this in the future. Orthogonality is generally good. The next question is whether it should be usable in non-constant expressions. Constant expressions are currently a subset of normal expressions, and it would be hard to justify changing that. Nor is it necessary. Avoiding the problems with determining the width of the result does not require that it appear only in constant expressions. It only requires that the arguments to the system function be constants, which is less restrictive. Users may still find it too restrictive. They may want to have this same functionality with variables, and be upset if it isn't available. But once you define it in a way that works only with constants, you can't easily change it to work with variables. It may be better to define it so that it works reasonably with variables from the start. This is a tradeoff that needs to be considered. How picky are the back-end tools you are producing these values for? Will they accept leading spaces or zeroes on the numbers in the strings? While I suggested that NUL characters would be used to pad the results up to the maximum width (determined at compile time), that is not the only option. If we think about printing values into strings, leading spaces or "0" characters naturally come to mind for padding up to the field width. The back-end tools may be able to parse such strings easily. If they use sscanf() or something similar, they will still extract the same numerical value. Date: Mon, 3 Nov 2003 21:24:15 -0500 (EST) From: Steven Sharp <sharp@cadence.com> I had another thought on the form of the system function. While trying to explain why $strcat was different from the C strcat, I was thinking that it was sort of like a combination of the C strcat with a C itoa function. Except that there isn't actually a C itoa function (integer to ASCII), only a C atoi function (ASCII to integer), which does the reverse. Then Adam started discussing the use of Verilog vector concatenation to do the string concatenation part, with a 1-character-long conversion to string that only handles values between 0 and 9. Again, it is the conversion function that is missing, not the concatenation capability. So instead of a $strcat that does the conversion and concatenation both, perhaps it would be better to have a $itoa or $itos (integer to string) function, and use the existing concatenation operator for the concatenation part. This would fit in with the existing $itor and $rtoi conversion functions. The naming convention could be extended by having a family of functions with a base specifier at the end of the name, like the $display family of tasks (and $readmemb and $readmemh). I must admit that a name like $itosb is pretty ugly though. One reason I find this attractive is that the existing system functions that could be allowed in constant expressions are all classified as conversion functions. Having this new system function be a conversion function also would keep things neat and make it easy to describe what system functions were allowed in constant expressions. Note that this does not help with the width problem at all. This new system function would still need to be defined in a way that ensured that the result had a constant width known at compile time. It would still require some kind of padding. And if the padding were with NUL characters, and the result were used in a concatenation, the NULs would end up in the middle of the resulting vector. This might be even less convenient to deal with. Date: Tue, 04 Nov 2003 07:35:17 +0200 From: Shalom Bresticker <Shalom.Bresticker@motorola.com> $itos and $stoi would be very useful. We have often had need for such. Date: Tue, 4 Nov 2003 16:11:04 -0500 (EST) From: Steven Sharp <sharp@cadence.com> >$itos and $stoi would be very useful. >We have often had need for such. I assume that most of the need for $itos and $stoi can be met by the Verilog-2001 system tasks $swrite and $sscanf with %d formats, though they may not be as convenient as function versions in some situations. I don't know if you were reading the details of the earlier discussion, but there are some issues with function versions. All operands in Verilog expressions must have known widths at compile time, including system functions. This width can depend on things known at compile time (such as the width of the arguments), but not on things that are not known at compile time (such as the values of variables). So if you want $itos to accept variable arguments and be able to produce the correct string for the maximum possible value of the arguments, the result must be as wide as that maximum possible value needs. And that means that it will be that wide even for smaller values. For example, a 32-bit signed integer requires 10 decimal digits to represent the maximum value, 11 if you allow for a negative sign. That means an 80 or 88 bit wide vector result. Even if the argument turns out to be 1, the result would still be 88 bits wide. The lowest byte would presumably be the ASCII character "1", but what should be used for the upper bytes? The obvious candidates are: - zero-extend the value with zero bits (creating NUL bytes). This is what you would get if you assigned the shorter string "1" to the larger 80 or 88 bit wide vector. - zero-pad the numeric field with "0" characters (e.g. "00000000001" or maybe " 00000000001" or "+00000000001" if we had to leave space for a negative sign). The first is how binary or hex values get printed by $display. There is no example of the signed situations since binary and hex formats print as unsigned and decimal format can print a sign but doesn't print leading zeros. Some version of this might work for Krishna's back-end tools, since they may be able to parse numbers with leading zeros. - pad with spaces (e.g. " 1"). This is how decimal values are printed by $display. Date: Tue, 04 Nov 2003 14:17:11 -0800 From: Krishna Garlapati <krishna@synplicity.com> I agree with you that $strcat can does both concatenation and conversion and can be split into 2 functions. We can start with $itos and $itoa and extend the functionality to include $itosb, $itosh, itoso and anything else to make it fully specified. But I still do think that Verilog should provide a function that performs concatenation and conversion instead of asking the user to write one using these. This functionality is too often used, and is much better if Verilog provides a solution natively. Using the $itos approach, $strcat can be represented as: (* some_name = $strcat("Hello", "World", $itos(i), $itosb(15) *) // assume i is 1 resulting in some_name = "HelloWorld14'b1111" There are a couple of issues here though. Will the proposed $itosb write the output as 4'b1111 or 1111 or {7{0000}, 1111} ?? You can see that the size of the output string can vary greatly depending on the approach. A possible solution is to explicitly specify in the LRM that the size of the output string of $itos will always be the least possible size size. Extending these functions to variables is generally a good idea. The sizing issues that popup can again be addressed pretty easily if the LRM can impose restrictions on the maximum size of string buffers that can be generated. (for unknown sizes only at compile time) I found out that the backend tools are very picky if we any chars are padded to the output string. I think we should concatenate the resutant string without any spaces or delimeters. If the user wants to add leading spaces (or any delimeters) it can always be done by adding a NULL string within the parameters to $stract. From: Shalom.Bresticker@motorola.com To: btf-bugs@boyd.com Cc: Subject: enhancement/502: Dynamic Values on attributes Date: Thu, 13 Nov 2003 12:38:16 +0200 (IST) With respect to the $itos and similar functions, I just received the following, showing that others also see need for such types of functions. Slightly edited. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 ---------- Forwarded message ---------- Date: Wed, 12 Nov 2003 14:04:14 -0600 From: Tom Hawkins <tom@launchbird.com> To: cf-user@launchbird.com Subject: [cf-user] Repost: Vector Printing Since cf-announce is going away, I am going to repost a few important release announcements so they make it into the cf-user archives. -Tom ---------- Forwarded Message ---------- Subject: [cf-announce] Confluence 0.6.4 -- Vector Printing, MFPUG Date: Mon, 8 Sep 2003 17:25:56 -0500 From: Tom Hawkins <tom@launchbird.com> To: cf-announce@launchbird.com Cc: bhurt@spnz.org Confluence 0.6.4 located at: http://www.launchbird.com/cfrl/ --------------- Vector Printing --------------- A new logic primitive has been introduced with 0.6.4: {VectorPrint, Enable Message} VectorPrint prints a vector assumed to be ASCII encoded to standard output. All language targets support the new primitive, though the functionality differs slightly between HDL and C/Python. In HDL, the print statement is embedded in an always/process block and will only print when the enable is high and either the enable or message has changed state. In C/Python, the message will print on every combinatorial calculation, provided enable is true. Base.cf also includes a few helper functions for vector/string manipulation: StringToVector : Converts a string into an ASCII vector constant. VectorToBin : Converts a vector into an ASCII vector of 1s and 0s. VectorToHex : Converts a vector into an ASCII vector of hex digits. Given these functions, it is straight forward to implement the Display as discussed on the user group. Display variants may be added to Base.cf in a later release. Who needs Perl for string manipulation when you've got Confluence generated Verilog? ;-) -- Tom Hawkins Launchbird Design Systems, Inc. 952-200-3790 http://www.launchbird.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: cf-user-unsubscribe@launchbird.com For additional commands, e-mail: cf-user-help@launchbird.com |
Unformatted |
|
Hosted by Boyd Technology