Hi, During 2004, a sub-group of the 1364 BTF had discussions about the various enhancement requests that were filed. I maintained a file summarizing the discussions on the issues filed by me. (BTW, sometimes I simply filed an issue on behalf of someone else.) In moving these issues to the SVDB, these comments may be helpful. This is the last summary I sent to the group. I might have had a private copy which was more up-to-date, but I have not found it yet. (Changing employers has caused accessing my old material to be much more difficult, since I used to work on a Unix system). Regards, Shalom ________________________________ priorities for my enhancement requests - updated From: Shalom.Bresticker@freescale.com <mailto:Shalom.Bresticker@freescale.com?Subject=Re:%20priorities%20for%2 0my%20enhancement%20requests%20-%20updated> Date: Mon Jul 19 2004 - 02:57:05 PDT * Next message: Shalom Bresticker: "datatypes call" <http://boydtechinc.com/btf/archive/btf_2004/2328.html> * Previous message: Stefen Boyd: "Re: Minutes of the July 13, 2004 IEEE-1364 Working Group" <http://boydtechinc.com/btf/archive/btf_2004/2326.html> * Messages sorted by: [ date ] <http://boydtechinc.com/btf/archive/btf_2004/date.html#2327> [ thread ] <http://boydtechinc.com/btf/archive/btf_2004/index.html#2327> [ subject ] <http://boydtechinc.com/btf/archive/btf_2004/subject.html#2327> [ author ] <http://boydtechinc.com/btf/archive/btf_2004/author.html#2327> [ attachment ] <http://boydtechinc.com/btf/archive/btf_2004/attachment.html> ________________________________ I have updated this based on the last meeting of the priorities sub-group on June 21. In truth, we should now take into account the developments in P1364 and P1800, and therefore remove/modify those issues which contradict or overlap SystemVerilog, but I have not gone back and revised the descriptions of those issues already discussed by the priorities group. In the last meeting, we discussed issues 419-427. I sent minutes separately. This is the updated list. Reminder: This is a list of only those enhancement requests filed by me. I assigned most of them a preliminary priority. I modified the comments and priorities of those issues discussed by the priorities sub-group according to the discussion. Shalom -- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Reuse Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary Summary: HIGH 4 , 55 , 61 , 62, 280, 404, 458, 481, 492, 502, 509, 514, 532, 547, 588, 590 MED-HI 405, 406, 409, 411, 419, 422, 447, 497, 537. 594 MEDIUM 58 , 183, 191, 378, 414, 427, 448, 451, 457, 498, 508, 519, 529, 545, 573, 577, 585, 589, 593, 595 MED-LO 414, 520, 572 LOW 201, 240, 400, 401, 421 ??? 482, 548, 558, 565, 571 4 Allow assignment to an array Today you can't do an assignment to more than one array element at a time. This enhancement request is to consider allowing assignments to an entire array or to a slice, maybe of a replicated value, maybe from one array to another. Both SV and the Cadence proposal have some provision for this. There is a difference between packed and unpacked arrays. Correspondence on the issue showed that the definition is not trivial, there are all sorts of corner cases. Probably related to operations on structs as well. Steven Sharp pointed out that passing arrays through ports is equivalent to a continuous assignment. Therefore #55 requires that assignments to arrays be defined and allowed. Since 55 is HIGH priority, then this must be HIGH also. This should go to the DataTypes subgroup. 55 Allow arrays and reals as ports Today you cannot pass arrays and real variables over ports. While we don't use reals much, there does not seem to be a good reason not to allow them. However, the restriction on arrays is painful. SV allows this, I think. There are two cases, one where you pass entire array, named simply by array identifier, and other case is where you pass part of any array, this requires syntax extension. HIGH priority. Also they need to be used as task and function I/O arguments. Also allow named event types as ports and arguments. 58 Allow force on memory word or bit-/part-select of vector variable This is a minor point, but there are some restrictions on force. There does not seem to be a good reason that the LHS of a force cannot be a select of an array or vector variable as long as the select is constant. It's weird that constant bit/part-selects of nets are allowed but not of variables. Steven Sharp says there were implementation reasons. Need to discuss whether these are good enough reasons today. Anyway, force needs to be extended to new data types. MEDIUM priority. 61 Add enumerated data type 62 Add record/structure data type These two will be dealt with in Datatype group, so no need to do anything special. HIGH priority. 183 Allow reverse part-select [lsb:msb] This request is to allow reverse-order part-selects. Steven Sharp objected that this is not efficient for simulation and people are liable to use it indiscriminately. While I think it is more useful than he thinks, I understand the inefficiency argument. It is also doable today, but inconveniently. It would also be easier if #409 were approved. To discourage doing it without justification, a solution might be to define a system function which does it, something like $bitswap(). MEDIUM priority. Since discussing this, I was pointed to the "bitstream" operator in SystemVerilog, where you can create an expression, and then get the bits in forward or reverse order. It would allow this reverse part-select inherently. It seems a very nice generalization. (It was also pointed out to me that this bitsream operator does not require a fixed bit-size of its result. 191 Add localparam to ANSI-type param list When parameters were added to ANSI-style module headers, localparameters were omitted. The justification for needing them there is that so they can be used within port definitions. The argument against is that "local" means local, inside, hidden. MEDIUM priority. 201 Module instance without parentheses There was a proposal to allow omitting the (empty) port list on an instantiation of a module which has no ports. The motivation is that you can define a module without a port list, but requiring a port list on the instantiation creates an inconsistency. Also sometimes you forget that it is needed and don't write it and then you get a cryptic error message from the compiler. SV decided against this. Nice to have, but does not add any functionality. LOW priority. 240 Allow initalizing declarations in named blocks, tasks, functions This is a spinoff from an errata issue. Variables can be declared in named blocks, tasks, and functions, as well as in modules. However, in modules, an initialization can be added to the variables, which is executed at time 0. Currently, such initializations are not allowed in declarations at the block/task/function levels. This proposal would allow them. There was a question as to whether they would be executed whenver the block is entered or only at time 0. At the time the related BNF errata was dealt with, there was not a concensus about adding this capability. There is not clearness about the benefit. On the other hand, there are also not clear reasons not to allow it. There might be confusion by users as to when the initialization is executed. LOW priority because benefit is not proven. 280 Turn xrefs blue and/or underlined This is an editorial issue. It requests to make cross-references in the text underlined bold blue, as in typical browser HTML displays. This serves to tell the user he can click on this (in the PDF file) and jump to the reference. Unfortunately, the hyperlinks only currently work for (sub-)clause references, not for table, syntax, or figure xrefs. But they are most needed for the section xrefs. HIGH priority because it is a significant enhancement to the LRM usability. Propose to turn it over to an Editorial Task Force/Group. Also no work needed. 378 Add Quick Reference The idea is that we have this 850-page LRM. It can take a great deal of time to find what you are looking for and understand it even if you know where to look. Maybe it behooves us to help the user and developer communities by producing a Quick Reference in an appendix. This might also be appropriate for the Editorial TF/G. MEDIUM priority, maybe MEDIUM-LOW. 400 Reduce arithmetic operators x-pessimism 401 Reduce relational operators x-pessimism These two proprosals come from the fact that arithmetic and relational operations in Verilog are "unreasonably" pessimistic. Basically, an X/Z anywhere in any of the operations causes the entire result to be X, even if the result or part of it can actually be shown to be deterministic. Too much X propagation often fouls up simulations and causes many troubles for users. Objections to changing are: it is more expensive in simulation time to be more realistic, some people might prefer the pessimistic evaluation, it is not clear that it is correct to simply treat each X as 0 or 1 and combine the results, and it is not back-compatible. The case for improving the relational operators is stronger. I personally have not found x-pessimism in arithmetic and relational operators to be a real problem. Due to that and the back-compatibility problem, we decided to classify this as LOW priority unless we get a request from a customer with a real need for it. An alternative proposal made during discussion of this topic was to INCREASE x-pessimism of other operators, such as bit-wise operators. However, this is not universally agreed to be a Good Thing. In addition, it would probably be a Bad Thing to do without discrimination. For example, it would be liable to cause problems in getting out of a reset state. 404 Add wildcards for equality operators 405 Add ranges for equality operators 406 Add lists for equality operators These 3 are all similar, ways to make easier multiple equality comparisons. 404: Wildcard equality comparisions exist in SV and Jeda also. Steven said implementation is not so hard, so we moved it to HIGH priority. Two issues are: 1) how to relate to x and z, and 2) whether it should be symmetric and/or asymmetric. We do not necessarily like the SV solution. 405 and 406 ask for the ability to test whether the value of an expression is within a certain set of values. Steven Sharp says the logical way to do this is to define a new "set" data type, and have an operation which asks whether the value of some expression is within the set, something like the "inside" operator of SystemVerilog. MEDIUM-HIGH priority. For Datatypes group. A spinoff of this is for a case item expression to be a range. That is, suppose you are testing the value of A. For a case item to be executed when the value of A is between 4 and 10, instead of writing "4,5,6,7,8,9,10:", you could write something which means "the range from 4 to 10". Steven Sharp said this should be easy syntactically, so we said it should be HIGH priority, but to file it as a new, separate issue. 409 Lists in part-selects This is another way to make life easier for users. Although some alternatives were suggested in the discussion, none were satisfactory replacements for this. Kurt Baty also liked this. I wrote above in 183 that if 409 is approved, then reverse order part-selects are less important. The two issues are orthogonal though. Steven Sharp said this should be simple to implement. MEDIUM-HIGH priority. A spinoff of this issue is the suggestion to redefine the [] subscript notation as an operator and generalize this. That is issue 474. 411 Extend operators to vectors and arrays I suggest considering to set up a group to deal with 'operator' issues. There seem to be a lot of them. This suggestion is general, proposing to extend and generalize the existing operators where the operands are vectors or arrays. In the discussion, two suggestions were made for generalization to vectors. For arrays, nothing exists today. Issue 4 proposed adding assignments to arrays. This is going to come up with new data types as well, of course, but this proposal relates to existing data types. It's important to maintain consistency. Steven Sharp said that Cadence had a set of extensions for datapaths. Some of this is publicly documented. MEDIUM-HIGH priority, maybe MEDIUM. 414 Rotate operator I originally wrote: I have not seen a lot of need for this, so MEDIUM-LOW priority. However, I just had a case where it would have been useful, so I would like to upgrade this to MEDIUM. Steven Sharp talked about a problem with respect to bit-extension. Also, with part-select lists, this would be less important. However, I don't think that would have helped in my case, where the number of bits positions to rotate was variable. 419 Reconsider for 1364-2005 proposals made for 1364-2001 Some of the proposals made for 1364-2001 were not accepted due to lack of time and resources, not necessarily because the proposals were problematic. The request here is to review the list and see whether there are some good things there which we should reconsider and which are not already on our list. In order to make the effort easy, I suggest simply to review the table of proposals and status which the BTF maintained for 2001, not to review every email in the archives. It should not take long to do this. MEDIUM-HIGH priority. We did this on June 21. The detailed discussion is in the minutes. Here is a summary: B10 - Behavioral assignment to wire - NO B12 - Continuous assignment case expressions - YES, MEDIUM B15 - Built-in sizeof(x) function - YES, but overlaps $bits in SV B16 - Access to last specified bit - YES, but overlaps $left and $right in SV B17 - Separate compilation capability - Already submitted B18 - Enumerated types - Already submitted B20 - Pullup/pulldown optional X-drive time - NO B21 - Automatic init of integers to 0 - NO B25 - Structs - Already submitted B28 - Bottom testing loop - YES, but already in SV B31 - Allowing parameters to define the length of a constant - YES, MEDIUM-HIGH at my request. B32 - Non-Blocking events - YES, but already in SV as ->> B40 - Trig functions - Already submitted Those suggestions we want to consider further and are not in SV, I file as new issues: B12 - Issue 593. B31 - Issue 594 421 17.9.3: Move to Annex This is for the Editorial Task Force. This simply says that 7 pages of C code should not be in the main text of the LRM, but rather belong in an Annex. LOW priority. 422 18: Extend $dumpvars to exclude a signal or module This request is to allow exclusion of specific signals or, more importantly, particular modules or module instances from $dumpvars. I believe this is very useful. (If memories become added by default, then exclusion of specific identifiers will also be important.) Generally, it is needed to rethink both what is dumped and what is not by $dumpvars, and also how one specifies what one wants to dump or not. We discussed various additional ways of extending $dumpvars as already implemented in various tools, currently and in the past. A good idea, but need more detailed proposals. MEDIUM-HIGH priority. 427 Combine 4.1.3 and 4.1.6 This is for the Editorial Task Force. These two sections overlap greatly and have the same examples, so it would be good to combine them. Also, I think the section(s) should be rewritten to be easier to understand. This discussion, of when an item is considered signed or unsigned, and how it works, is a key concept. A good idea, but need someone to do it, and it needs to be done carefully. Better to not do it than to do it wrong. MEDIUM priority. 447 `ifdef boolean combination of identifiers This is related to 481. The current preprocessing capabilities are quite limited and not satisfactory. I note that SV adds new possibilities to `defines. The boolean combination of `ifdef's is an example of how coding can be very awkward to do things which really should not be that hard. MEDIUM-HIGH priority. This would add new functionality. 448 Extend new file I/O to allow combinations of fd's One of the useful and elegant features of MCD's is the ability to output to several files at once by ORing the MCDs. In particular, it was useful for outputting simultaneously to both STDOUT, LOG FILE, and some other file. In new, FD method, it is not generally possible to output to multiple files at the same time, to the best of my knowledge. It should be possible, at least for STDOUT and LOG FILE as well. MEDIUM priority. If it turns out that today it is possible at least to print simultaneously to STDOUT and LOG as well as a regular file already today, then priority is LOW. 451 Review Annex C and D This relates to optional system tasks/functions and compiler directives in these annexes. Those which are more or less universal should be standardized and the others should be either deleted, or standardize them but as optional (i.e., you don't have to implement this, but if you do, you must do it this way.) MEDIUM. 457 Extend index to complete 1364-2001 For Editorial TF. This is needed to point to all the places where something important is said about a subject. The smaller part of this is adding items which are missing from the index, because most is already covered. The larger part is finding and adding the mising page references for subjects which are already listed. MEDIUM priority. 458 Extend index to cover 1364-2005 enhancements For Editorial TF. Since this largely means adding entry for completely new items, this is HIGH priority. We probably should think about this every time we had something. Maybe it should be on checklist. 481 Define standard preprocessor The preprocessing directives available in Verilog are very limited, basically `define and `ifdef. `define is extended in SystemVerilog. Extensions are badly needed. We could start by looking at CPP and M4. There are also VPP and a few others. Motorola also has an internal pre-processor. Priority HIGH. 482 Add standard way to define functional coverage points For code coverage, coverage points don't have to be defined by user, they are built in. However, for functional coverage, they need to be defined by user. The question is whether they should be defined within the HDL. The priority depends on the answer to this question. 492 Add lists of figures, tables, syntaxes This is for addition to the Table of Contents. It has two uses. One is when someone tells you to look in Figure XXX, it should not take you 15 minutes to find it. Second, if the document refers you to a table in another section, it should be easy to find. The latter case is most common in the PLI. HIGH priority, easy to do. 497 Add glossary section There is a big problem with inconsistency of terminology, and often users don't know what a term means. A glossary could help. MEDIUM-HIGH, for Editorial TF. 498 System function/tasks to extract timescale info to variables It seems to me, from conversations with integrators in mixed timescale environments, that it would be useful to be able to get timescale information into variables as well as to print it, but to get it in "unit numbers", i.e., power of 10 from 0 to -15 instead of as a string. This would enable to do manipulations in time data, but I would have to go back and figure out a real application for it. Doesn't seem difficult, anyway. MEDIUM. 502 Dynamic values on attributes This issue was extensively discussed but far from ended. The conclusions I see up to this point are: 'Dynamic values' is a misnomer. There is nothing special about attributes. The real issue is allowing certain system functions in constant_expressions. This is already covered in issue 387. Another need coming out of this issue is some sort of a string concatenation function. However, probably more generally useful would be a set of number <-> string conversion functions. Another issue that came up is whether it is possible to relax the requirement that the bit-width of a function result be known in advance as opposed to being a function of the function arguments. I believe that the number<->string conversion functions are very useful, so I call this MEDIUM-HIGH priority. Probably closer to HIGH. 508 Add arrays of `defines 509 Add arrays of parameters It occurred to me that it would be useful and logical to extend arrays to these entity types as well as to nets and variables, modules and scopes, etc. Especially for parameters, it seems natural and not too difficult. `defines may be a different story in terms of difficulty. By chance, I was brought code today where parameter arrays would have been the natural solution. I would rate param arrays as HIGH and `define arrays as MEDIUM. 514 Config file should support module and primitive arrays This could have been considered an erratum. Needed. HIGH priority. 519 System function to get signal strength This has uses in verification and testing environments, typically where you have a bidirectional pin and you need to know whether the chip is actually driving a value or there is just a pullup active. Typically in such cases, we would have to look at some internal output enable signal. But it's a problematic solution. MEDIUM. 520 3.3.2: Deprecate "scalared" and "vectored" keywords This is a personal gripe. These two keywords exist only due to some tool that wanted to allow you to specify to implement a vector so as to optimize some aspect of the simulation. However it does not rightfully belong to the Verilog language. The rest of the LRM assumes that these keywords are not used, similar to macromodules. Let's at least discourage their use. MEDIUM-LOW. Maybe we could delete them and allow them only in old, 1995/2001-compatible code? 529 Add "bidirectional skew" timing check The SDF standard includes a TIMINGCHECK construct called BIDIRECTSKEW, which is not mentioned in the 1364 standard. Ted Elkind wrote: Bidirectskew was intended to anticipate a potential enhancement to 1364. It was intended to address the situation where two signals have skew relative to one another, and either one could occur first. The only way the Verilog language can address this situation at present is with 2 $skew checks $skew(posedge clka, posedge clkb, 6); $skew(posedge clkb, posedge clka, 6); Even without bidirectskew being part of 1364, the SDF bidirectskew can still be used to annotate to $skew. For example (bidirectskew (posege clka) (posedge clkb) (6, 7)) This would annotate 6 to the first $skew and 7 to the second $skew. MEDIUM 532 New, binary dump format in addition to VCD We need a binary dump format in addition to VCD, because VCD is so big. And it needs to be portable between tools. And it needs to support all new constructs. After filing this issue, I saw that SV attacks it by defining a standard API. I am not sure that fully solves the problem, though. HIGH. 537 Allow unsized numbers and integer variables in concatenations I have seen places where this would have been convenient, assuming a standard definition of how many bits they occupy, say 32. I don't see a problem with this. MEDIUM-HIGH. 545 4.2.1, 4.2.2: Out of bounds addressing This is a seemingly minor point, but I would like to require that a simulator issue a run-time warning when an out-of-bounds address is given. There are precedents in the LRM for run-time warnings. MEDIUM. 547 Define size zero replication constant This is extremely useful for us. We run across this problem daily in parametric code. We need to have defined that a replication constant of zero is legal, but causes the contents to appear zero times, i.e., not at all, like a "repeat(0)". Steven Sharp had some reservations, but I believe I have answers to all of those. HIGH!! 548 Support SDF RETAIN? 558 Allow multidimensional arrays of modules 565 Find way to embed PSL (see 429) 571 Review explicit restrictions in LRM 572: multidimensional instance arrays Today, arrays of instances allow you to declare them only with a single dimension, whereas generates effectively allow you to create multidimensional arrays of module instances. A natural extension of arrays of instances, then, would be to consider multidimensional arrays. MEDIUM-LOW priority, because it is nevertheless doable via generates. 573: loops within concatenations? It occurred to me that it might be useful to be able to create concatenations with internal loops to create some sequence e.g., { a[0], a[1], a[2], ...} where a is an array. I remember that when creating gate-level equivalents of some rtl signal, we would often have to do such things. MEDIUM. 577: tables of BNF non-terminal references For working with the BNF, it would be useful we had a table which lists for each non-terminal in which productions it appears. MEDIUM. 585: Parameterized task/function extensions MEDIUM 588: Add ranges to case_item expressions This is a spinoff of #405. This should be easier to implement. HIGH. 589: Add x-pessimism for IF statements This would be very useful. Is it practical, though? Will not be easy to define. MEDIUM due to the difficulty. 590: vector version of ?: operator This is needed all the time. Should not be hard to define, just need to create an operator symbol instead of ?. HIGH 593: Continuous assignment case expressions It is nice and probably not hard to implement, but does not add new functionality, so we gave it priority MEDIUM 594: Allowing parameters to define the length of a constant. Shalom: This would be useful. Steven: There could be order dependencies, since parameter values are only determined at elaboration time. Need restrictions. If we did this as a conversion function instead of as part of the syntax for specifying a constant, it would be better. Shalom: OK MEDIUM-HIGH priority. 595: Ability to initialize variables to 0, 1, or random instead of X We discussed a new idea of compiler directives for initialization of variables to 0 or 1 or random. Some tools do this today by a command-line switch. Both methods have advantages and disadvantages. An advantage of compiler directives is that they can be selective, i.e., on part of the design. A disadvantage is that it involves touching the design files. We recommend this for further consideration with priority MEDIUM. ________________________________ * Next message: Shalom Bresticker: "datatypes call" <http://boydtechinc.com/btf/archive/btf_2004/2328.html> * Previous message: Stefen Boyd: "Re: Minutes of the July 13, 2004 IEEE-1364 Working Group" <http://boydtechinc.com/btf/archive/btf_2004/2326.html> * Messages sorted by: [ date ] <http://boydtechinc.com/btf/archive/btf_2004/date.html#2327> [ thread ] <http://boydtechinc.com/btf/archive/btf_2004/index.html#2327> [ subject ] <http://boydtechinc.com/btf/archive/btf_2004/subject.html#2327> [ author ] <http://boydtechinc.com/btf/archive/btf_2004/author.html#2327> [ attachment ] <http://boydtechinc.com/btf/archive/btf_2004/attachment.html> ________________________________ This archive was generated by hypermail 2.1.4 <http://www.hypermail.org/> : Mon Jul 19 2004 - 02:53:46 PDT and sponsored by Boyd Technology, Inc. <http://www.BoydTechInc.com>
This archive was generated by hypermail 2.1.8 : Mon Nov 21 2005 - 01:14:36 PST