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, 51 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  Resources for writing good natural language requirements.          Verification Guild Forum Index -> Miscellaneous View previous topic :: View next topic   Author Message rpaley_yid Senior Joined: Jan 14, 2004 Posts: 30 Posted: Thu Nov 18, 2004 8:41 am    Post subject: Resources for writing good natural language requirements. Hello all, Where can I find articles specifying how to write good requirements? My definition of "good" is * bounded * not vague i realise that there will always be some vagueness with natural language requirements but there must be some techniques developed to minimize this vagueness thanks in advance Back to top vhdlcohen Industry Expert Joined: Jan 05, 2004 Posts: 1240 Location: Los Angeles, CA Posted: Thu Nov 18, 2004 11:10 am    Post subject: Quote: Where can I find articles specifying how to write good requirements? In my book "Component Design by Example " I addressed that issue with a UART as a model. In our upcoming book "SystemVerilog Assertions Handbook" I borrowed the style of the first book, but also added assertions to remove ambiguities. For the SVA book, we used a FIFO model. On a personal basis, I prefer the method tha we used in the SVA Handbook because if combines English with SVA code to created a "bounded, not vague" spec that is also executable. Today, there are even tools that will take a PSL or SVA spec and will allow you to visualize those assertions with waveforms displays of cases that meet that spec. Interesting technology! For more info on that technology, see slides from http://www.systemverilog.org/pdf/AT_HDL_Symposium.pdf Ben Cohen _________________ 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 alexg Senior Joined: Jan 07, 2004 Posts: 586 Location: Ottawa Posted: Thu Nov 18, 2004 4:33 pm    Post subject: Main properties of the natural language are: -It provides an immediate vocabulary for talking about the contents of the computer. -It provides a means of accessing information in the computer independently of its structure and encodings. -It shields the user from the formal access language of the underlying system. -It is available with a minimum of training. It looks like PSL and SVA cannot be classified as a natural languages. Waveform-like specification is more natural, but can be uniquely converted only for simplistic assertions. In general, it looks like assertion-to-waveform is one-to-many relationship. For example, I don't think single waveform can visualize recent PSL example from Romi. Then, if the number of waveforms are describing single assertion, it becomes less natural than the actual assertion code. That's why @HDL took "extraction" approach: first, write PSL or SVA code and then check whether it looks "natural enough" with the waveform. Regards, Alexander Gnusin Back to top vhdlcohen Industry Expert Joined: Jan 05, 2004 Posts: 1240 Location: Los Angeles, CA Posted: Thu Nov 18, 2004 5:21 pm    Post subject: Quote: Main properties of the natural language are: -It provides an immediate vocabulary for talking about the contents of the computer. -It provides a means of accessing information in the computer independently of its structure and encodings. -It shields the user from the formal access language of the underlying system. -It is available with a minimum of training. It looks like PSL and SVA cannot be classified as a natural languages. I am not saying "use SVA or PSL instead of a natural language". However, what I am saying is "add to the natural language PSL or SVA properties to clarify the requirements, and to remove ambiguities. Examples of things that can be added are: - Interfaces, which if not fully defined can be at the abstract data type level, such as structures, integers, event. - Tasks that support the design, but do not necessarily represent the design. FOr the FIFO example, we use a SystemVerilog Queue, and used the methods that support the queues to read size, push_front(data), pop_back(), etc. - Functions, such as transformation algorithms on the data. - latencies The point is that English has a lot of ambiguities. To make my point, consider the following, extracted from what was considered a "model" requirement (i.e., A++ in documentation) Quote: At startup, the TAP is forced to the Test-Logic-Reset state by asserting TRST_f low (note that holding TMS high for five TCK cycles also reaches Test-Logic-Reset from any state). It was interesting to me that a requirement about holding the clock for 5 cycles for getting into a reset mode was mentioned as "note" .. not really important, but a just a "note" that could be skipped, I guess!!! In PSL, that could have been written as: Code: property StateAfterReset =       always TRST_f -> tap.tap_fsm== 0; property StateAfter5TMS =       always {rose(TMS); [*4]TMS} |=> {tap.tap_fsm== 0}; Another example from this "model" spec: Quote: “The Instruction Register partition includes the instruction register, bypass register, and associated control and decode logic.” Later on the function of the bypass mode is explained in a table where when in bypass mode “it set TDI/TDO path to single register for shifting instructions to other components while ASIC remains in tactical mode.” Quite a breath of explanations!!! In PSL: Code:  property InByPASS =       always {ir_mode==BYPASS} |=> {td0 == prev(tdi)}; Again, the point I am making is that the English requirements should be supplemented by properties expressed in a property spec languaguage, like PSL or SVA because, IMHO, it removes a lot of ambiguities. I am not saying to eliminate the natural language, just supplement it with properties. The exercise not only clarifies the requirements, but it helps in the understanding of the requirements, the design and verification process. Ben Cohen _________________ 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 Darren Senior Joined: Jan 06, 2004 Posts: 32 Location: Bristol, England Posted: Fri Nov 19, 2004 8:16 am    Post subject: This is an interesting area, and one that has caused me multiple problems due to a natural English spec being read by people whose first language is not English. Take the following example: "Signal X shall be asserted at the same time as Signal Y". In English, shall is imperative, which means it must happen. However, when translated into other languages such as German, it loses the imperative and becomes optional. This has caused inordinate amounts of grief in the past, with designs expecting different things. Backing this up with a more formal description would make it clearer to everyone. I would like to see something like: When Signal X must be asserted when Signal Y is asserted. if Y => X. (I don't know PSL, so the above is "pseudo-code" of my own invention). The formal part clarifies the English part. It might also be an idea to follow aerospace practice, where in one of their standards they include a glossary which defines what keywords mean. Back to top vhdlcohen Industry Expert Joined: Jan 05, 2004 Posts: 1240 Location: Los Angeles, CA Posted: Fri Nov 19, 2004 12:11 pm    Post subject: Darren, Thanks for your inputs about translation into other languages. Interestingly enough, I believe that there currently IS a problem in translating from English to English, as English is ambiguous, and specs tend to be so verbal that it becomes difficult to understand. On your suggestion: Quote: When Signal X must be asserted when Signal Y is asserted. if Y => X. This can be coded as (using signal names): Code:  // SVA property pAckBusEnable;   @(posedge clk)          ack |=> bus_enable;   // if ack, then bus_enable at next cycle                                              // Use |-> if in  same cycle endproperty : pAckBusEnable That property can then trigger other requirements during review time. For example: Code: sequence qFsmRequestAck;     fsm_req ##[1:5] fsm_ack ##1; endsequence qRequestAck property pAckBusEnable;   @(posedge clk)          ack |=> bus_enable && qFsmRequestAck.ended     // if ack, then bus_enable at next cycle and     // the FSM just completed its request and acknowledge states. endproperty : pAckBusEnable As you mentioned, having an executable set of requirements, along with some natural language descriptions / tables / figures is very beneficial. There is a misconception that PSL and SVA are only for verification of RTL. Those ABV languages can be used for adding more information to (and formalizing) requirements. They can also be used in the testbnech. Ben Cohen _________________ 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 alexg Senior Joined: Jan 07, 2004 Posts: 586 Location: Ottawa Posted: Fri Nov 19, 2004 11:47 pm    Post subject: vhdlcohen wrote: I am not saying "use SVA or PSL instead of a natural language". However, what I am saying is "add to the natural language PSL or SVA properties to clarify the requirements, and to remove ambiguities. I am not against the usage SVA or PSL in specifications. It is a good idea, especially for those who are fluent in formal languages. And even if not, we can rely on tools that will still understand them properly. The topic of discussion is slightly different though. The question, as I understand it, is: is it possible to define good (bounded, not vague) requirements for the verification natural language? So, we have bounded, not vague but also not natural PSL and SVA on one side, and natural but not bounded and vague English on another side. I am not sure whether it is possible to develop something similar to the natural language such as SQL for verification purposes. Regards, Alexander Gnusin Back to top vhdlcohen Industry Expert Joined: Jan 05, 2004 Posts: 1240 Location: Los Angeles, CA Posted: Sat Nov 20, 2004 1:25 pm    Post subject: Quote: The topic of discussion is slightly different though. The question, as I understand it, is: is it possible to define good (bounded, not vague) requirements for the verification natural language? Defining a good specification is indeed difficult. I do believe that it is possible to define a spec that is more bounded than current methods using both a natural language with graphics, table, diagram and descriptions along with a property specification language like PSL or SVA. I was a designer for many years, wrote several specs, and experienced the traditional methodologies. On specs, I have the following observations: 1. Every engineer hates writing specs! Specs are the pits!!! 2. Specs seem to be dynamic, and can (and do) change during the design processs. 3. Natural language specs are ambiguous. When a design error is detected, it is often related to misunderstandings in the spec, and either the design or the spec need to be changed. 4. Managers hate all that "wasted time" on specs because that slows the design cycle. Thus, there is a tendency to more quickly approve a spec, as it puts a "dot" on the progress schedule. 5. Wen I wrote the PSL book, I wanted to use the AMBA AHB spec, thinking that ARM would write a "good" spec. If anyone has seen that spec, they would understand that it is almost impossible to create a good design solely from that spec. You don't need a dog's nose to know that it stinks! (I have no NDA with ARM) . It looks good, but that's all I can about the natural language description of that interface. I was about to abandon the idea of using that as a model for the PSL book until Cadence gave me a PSL interface descriptoion of the AHB bus. All the sudden things became much clearer, and many ambiguities were resolved. I was able to then succcessfully proceed with the design of a memory interface unsing the AHB bus (it's in the book). I used the PSL interface code during the architectural and the RTL design process so that I could understand the requirements. The ARM timing waveforms helped a bit also. 6. Today, if I were asked to write a spec, I would use PSL or SVA along with the natural language. We demonstrate that in the upcoming book "SystemVerilog Assertions Handbook", 1st week Dec 04 release. Quote: So, we have bounded, not vague but also not natural PSL and SVA on one side, and natural but not bounded and vague English on another side. I am not sure whether it is possible to develop something similar to the natural language such as SQL for verification purposes. Technology has changed, and I definitely am a firm believer of mixing natural languages with PSL or SVA, and C for the definition of requirements and algorithms. Your above statement is correct, and if bounded is a requirement, then other techniques, besides natural languages are needed. Ben Cohen _________________ 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 alexg Senior Joined: Jan 07, 2004 Posts: 586 Location: Ottawa Posted: Sun Nov 21, 2004 9:18 pm    Post subject: vhdlcohen wrote: 5. When I wrote the PSL book, I wanted to use the AMBA AHB spec, thinking that ARM would write a "good" spec. If anyone has seen that spec, they would understand that it is almost impossible to create a good design solely from that spec. You don't need a dog's nose to know that it stinks! (I have no NDA with ARM) . It looks good, but that's all I can about the natural language description of that interface. I was about to abandon the idea of using that as a model for the PSL book until Cadence gave me a PSL interface descriptoion of the AHB bus. All the sudden things became much clearer, and many ambiguities were resolved. I was able to then succcessfully proceed with the design of a memory interface unsing the AHB bus (it's in the book). I used the PSL interface code during the architectural and the RTL design process so that I could understand the requirements. The ARM timing waveforms helped a bit also. I agree that usage of PSL or SVA is important during Specification phase. However, I still see one problem with your example. How do you guarantee, that PSL interface description provided by Cadence correctly implements requirements written in plain English in ARM AMBA Spec? What if PSL developers fail to understand Specification in the right way, thinking that they DO understand it correctly? In other words, how to make sure, that PSL code written AFTER Specification is as robust as Specification itself? In ideal world, chip architects and designers have to use as more formalization as possible writing Specification documents. It implies that they have to know and use PSL or SVA constructs in addition to waveform diagams and FSM drawings. Regards, Alexander Gnusin Back to top vhdlcohen Industry Expert Joined: Jan 05, 2004 Posts: 1240 Location: Los Angeles, CA Posted: Sun Nov 21, 2004 10:12 pm    Post subject: Alexander Gnusin wrote: Quote: I agree that usage of PSL or SVA is important during Specification phase. However, I still see one problem with your example. How do you guarantee, that PSL interface description provided by Cadence correctly implements requirements written in plain English in ARM AMBA Spec? What if PSL developers fail to understand Specification in the right way, thinking that they DO understand it correctly? In other words, how to make sure, that PSL code written AFTER Specification is as robust as Specification itself? In ideal world, chip architects and designers have to use as more formalization as possible writing Specification documents. It implies that they have to know and use PSL or SVA constructs in addition to waveform diagams and FSM drawings. Alex, does this get back to the issue of communication? I am glad that you agree that usage of PSL or SVA is important during Specification phase. A specification is a set of requirements that characterize what the design should do. That information transfer can be expressed correctly, or incorrectly via many methods: - The tradional style: Natural language, waveforms, tables, photos, etc.. - More formal methods with a property specification language. The specification is not the design, and should not represent the implementation. A functional specification reqpresents the requirements, such as latencies, timing relationships (e.g., in an interface), transformations (e.g., parallel to serial), protocols, algorithms, etc. Getting back to your interesting question: "How do you guarantee, that PSL interface description provided by Cadence correctly implements requirements written in plain English in ARM AMBA Spec?" Or the more generic question "How do you guarantee, that PSL or SystemVerilog Assertions interface description implements the desired requirements ? The simple answer is "with work". The more extensive answer is here's how: 1. Through lots of reviews and PSL / SVA comparisons to natural language description. That means addressing the requirements described in the traditional methods, and the PSL / SVA properties. When you do that, you'll quickly notice that people who undestand theose ABV languages will focus on that because they tend to be more expressive with less words to describe the requirements. Also, because of the brievity in code, more issues will surface, such as "have you considered what would happen if an enable is set but the xyz unit is not ready yet? " 2. behavioral modeling with assertions This would be a high level model of the design. It's a kind of mock-up, but it would validate the understanding of the requirements. 3. Assertion viewing tools I never tried that, but it is an intriguing concept. Getting back to the AMBA AHB PSL and ARM spec, my methodology in validating the PSL was to compare each PSL statement to the ARM spec. In many cases, I found no direct correspondence (the ARM spec unfortunaltely lacks important details). When I saw no correspondence, I questioned the author of the PSL code who was able to provide explanations. Basically, this brings back to method 1 above, and as I mentioned, the ABV descriptions do trigger more issues, and do iron out holes in the spec. Question for you: "How do you validate thata natural language description, with tables, waveforms, and diagrams correctly define the requirements? Anyway, we at least both agree that ABV is useful in specifications. And, yes, chip architects and designers would have to know and use PSL or SVA constructs in addition to waveform diagams and FSM drawings. Know of any good books? _________________ 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 hemanth Senior Joined: Aug 16, 2004 Posts: 93 Location: Bangalore Posted: Mon Nov 22, 2004 12:36 am    Post subject: I agree with Ben on this, Alex when we speak of natural language we should remember that the natural language came into existence and prevails as an aid for exchange of information between individuals. It was driven by the necessity to convey the breadth of information experienced by individuals in their lifetimes and hence it largely serves that purpose. But when we delve in to domains that are not inherently natural it still can be done by explaining it away in terms of our natural language but we cannot convey the precision intended because the natural languages are inadequate to handle this, and thats because we precisely do not need that precision in living our lives. The natural language has sacrificed precision and depth for breadth and variety. This shortcoming will always exist. So when we want to describe things which require extra-ordinary precision and clarity we have to resort to abstract methods created by us. but when there is a domain like hardware/software verification this tends to be a place where we are describing what we want to happen in a language but the issue here is as alex rightly highlighted it should mirror natural laguage understadability but with clarity and depth only provided by an abstract construct which is not natural as pointed out by Ben. So the success of a methodology depends on how well this marriage gels and how much it can accomplish comparitively. hemanth Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         Verification Guild Forum Index -> Miscellaneous All times are GMT - 5 Hours Page 1 of 1   Jump to: Select a forum Main----------------MainEDA NewsCommunity Services Networking----------------Looking for a jobLooking for candidates Archives----------------AssertionsCoverageFormalSimulationDesignMiscellaneous Test----------------Test  You cannot post new topics in this forum You cannot 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.325 Seconds