Coding Standard 
Author Message
 Coding Standard

My company wants to generate a verilog coding standard. I would like to
see it be as unrestrictive as possible and only add rules that have a
good reason for being there.

I'd like to hear about other's experiences with coding standards. I've
seen some that say only lower case signal names for instance. Is there a
good reason for this, or is it just someone's personal preference.

Any other good suggestions for a standard?

Things to avoid in a standard?

Any help would be appreciated.

Thanks,
Steve

--== Sent via Deja.com http://www.*-*-*.com/
---Share what you know. Learn what you don't.---



Tue, 30 Oct 2001 03:00:00 GMT  
 Coding Standard
Our group has simple FSM coding style, you can find the
ciscofsm paper in  http://www.employees.org/~ciscofsm.

Of course, you'll get added benifit as shown in the web.

--------------------
                                        |           |      
Tsu-Hua Wang                            |           |      
170 West Tasman Drive, SJ-G1           |||         |||    
San Jose, CA 95134-1706               |||||       |||||    

http://www.cisco.com              c i s c o   S y s t e m s

http://www.employees.org/~ciscofsm      get your free FSM tool

Quote:

> My company wants to generate a verilog coding standard. I would like to
> see it be as unrestrictive as possible and only add rules that have a
> good reason for being there.

> I'd like to hear about other's experiences with coding standards. I've
> seen some that say only lower case signal names for instance. Is there a
> good reason for this, or is it just someone's personal preference.

> Any other good suggestions for a standard?

> Things to avoid in a standard?

> Any help would be appreciated.

> Thanks,
> Steve

> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---



Tue, 30 Oct 2001 03:00:00 GMT  
 Coding Standard
Greetings
Visit Verilog & EDA Page
http://www.*-*-*.com/

I kept my paper on Coding guidelines. It is still evolving
but should serve the purpose.

Exact URL is
http://www.*-*-*.com/

You may face the problem. Download the file using right
mouse botton and then see offline.

Rajesh Ba{*filter*}ule


Quote:

> My company wants to generate a verilog coding standard. I would like
to
> see it be as unrestrictive as possible and only add rules that have a
> good reason for being there.

> I'd like to hear about other's experiences with coding standards.
I've
> seen some that say only lower case signal names for instance. Is
there a
> good reason for this, or is it just someone's personal preference.

> Any other good suggestions for a standard?

> Things to avoid in a standard?

> Any help would be appreciated.

> Thanks,
> Steve

> --== Sent via Deja.com http://www.*-*-*.com/
> ---Share what you know. Learn what you don't.---

--== Sent via Deja.com http://www.*-*-*.com/
---Share what you know. Learn what you don't.---


Fri, 02 Nov 2001 03:00:00 GMT  
 Coding Standard
Steve,

I do all my coding in VHDL, and we have a VHDL Coding Guidelines document in
place. Since it's VHDL, it doesn't pertain directly to Verilog, but the
concepts are similar. Synopsys has generated a coding guidelines document,
which they distribute through their web site - but you may have to have a
Synopsys license (ie: be a registered user) to gain access.

In any event, here are some general comments:

The main purposes of coding standards are to provide a similar look and feel
to code produced by multiple designers, eliminate problems due to bad coding
methodologies, and to minimize problems when assembling blocks from
different designers into a final product. Management often wants coding
standards to guarantee design quality. Coding standards that try to
guarantee design quality are usually focused on how muxes, flops, and state
machines are implemented in code - the idea being that if those are coded
correctly, then everything is guaranteed to work. If that's your goal, I
think your efforts are ultimately doomed to failure. On the other hand,
there are some "worst practices" - ways to write code that make it difficult
to read, or that generally synthesize poorly. It's helpful to have examples
of bad practice (in parallel with examples of good practice) in the coding
standards. Those examples aren't really part of the standard you're trying
to implement, but the standard becomes more of a reference point if those
examples are included.

Here are my thoughts on a few topics that may end up in your spec.

1. Your coding guidelines will ultimately fail if they try to specify too
much detail. Don't try to specify all the details of code structure; you
can't, and the resulting code will be worse if you do.

2. Having common formats is extremely helpful. At some point, someone
working on your project is going to have to pick up where someone else left
off. Toward that end, having file templates, with comment blocks already in
place (though, of course, not filled in), are very helpful. See 3.

3. File headers and comment headers on major blocks are extremely helpful.
File headers can include fields that are filled in by revision control
tools, but should also include description blocks. Same thing with headers
on major blocks. A comment header on a block that explains the function of
the block, inputs, outputs, and internal signals is very helpful when trying
to read someone else's code.

4. This may seem trivial, but it's not. Use spaces, not tabs, specify the
number of spaces to be used for each level of indentation, and limit line
lengths to 80. If you use tab characters, they come out different on every
editor, and on every printer. Our PC users rebel against the 80 column
limit, but the poor xemacs guys die when they have to open files with more
than 80 columns. Even if that wasn't a problem, if we use our generic print
commands, lines longer than 80 chcaracters get truncated. It's not worth the
trouble it causes to use lines longer than 80 characters.

5. Signal names, especially those that go out of the block that a person is
responsible for, should be either upper or lower case (we use lower case).
There are two reasons for this: a) if everyone uses the same case, you don't
spend time trying to track down case mismatches when you're trying to
assemble the chip, and b) other tools (in our case, the APR tools) can't
deal with upper case names.

6. A general naming convention for signal names can be very useful. Reading
code is MUCH easier when clocks, reset lines, and so on are easily
identifiable. If you get carried away, nobody will be able to remember (much
less implement) the rules, so be careful. On the other hand, if you enforce
a simple naming convention, it will be much easier to read someone else's
code later.

-- Mike --

Quote:

> My company wants to generate a verilog coding standard. I would like to
> see it be as unrestrictive as possible and only add rules that have a
> good reason for being there.

> I'd like to hear about other's experiences with coding standards. I've
> seen some that say only lower case signal names for instance. Is there a
> good reason for this, or is it just someone's personal preference.

> Any other good suggestions for a standard?

> Things to avoid in a standard?

> Any help would be appreciated.

> Thanks,
> Steve

> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---



Mon, 05 Nov 2001 03:00:00 GMT  
 Coding Standard

Quote:

>Steve,

>4. This may seem trivial, but it's not. Use spaces, not tabs, specify the
>number of spaces to be used for each level of indentation, and limit line
>lengths to 80. If you use tab characters, they come out different on every
>editor, and on every printer. Our PC users rebel against the 80 column
>limit, but the poor xemacs guys die when they have to open files with more
>than 80 columns. Even if that wasn't a problem, if we use our generic print

Mike,

I agree with most of your post but I have no clue why long lines would
bother xemacs users.  I live in xemacs and don't understand this.  Don't the
people at your company know how to resize a window and/or toggle truncate line
mode?

 David



Tue, 06 Nov 2001 03:00:00 GMT  
 Coding Standard
Hi Steve,
              It's probably worth deciding on why you want a coding
standard. Is it for uniformity so that if code is passed from engineer to
engineer, the learning curve is lessened; is it for efficient simulation or
is it for optimal synthesis results?  The latter two often used to be
mutually exclusive, but most up-to-date tools will happily handle simulation
or synthesis slanted code.  As regards coding guidelines, each vendor
probably has their own tricks and preferences.  It is worth noting that we,
Synopsys, are the de-facto standard for coding simply due to market share in
synthesis (~90%) and that if code portability is an issue, then code which
our parsers will accept is likely to be usable by most other tools on the
market.  We also have documented "style guidelines" which can be used as the
basis for training.

Note also, that as a Synopsys employee, I am not necessarily unbiased!!!

Paul

--
***********************************************************************
** Paul Hands,                                 Tel: +44 (0)118 931 3822
** Regional Technical Manager,                 Fax: +44 (0)118 975 0081
** Synopsys (Northern Europe) Ltd.,          Mobile: +44 (0)7050 095680
** Imperium, Imperial Way,
** Worton Grange,

** England
***********************************************************************



Tue, 06 Nov 2001 03:00:00 GMT  
 Coding Standard
Thanks for your reply Mike.

I also live in xemacs and don't have any problems with long lines.

Quote:

> I agree with most of your post but I have no clue why long lines would
> bother xemacs users.  I live in xemacs and don't understand this.
Don't the
> people at your company know how to resize a window and/or toggle
truncate line
> mode?

>  David

--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


Tue, 06 Nov 2001 03:00:00 GMT  
 Coding Standard

Quote:

>Steve,

>4. This may seem trivial, but it's not. Use spaces, not tabs, specify the
>number of spaces to be used for each level of indentation, and limit line
>lengths to 80.

I agree, it's not trivial.

Minor addition; limit your font to non-proportional, eg Courier

    ...and I don't understand the problems with long lines either?

--

Regards,

        Brent Hayhoe.

Nortel Networks plc,                      Tel: +44 (0)1279-402937
Harlow Laboratories,  London Road,        Fax: +44 (0)1279-403930



Tue, 06 Nov 2001 03:00:00 GMT  
 Coding Standard
To all the xemacs users who responded:

I have no idea what the problem with 80 column lines in xemacs was. They
complained about lines in excess of 80 columns, and said it caused problems
in xemacs, and I never did ask why. You're all right - it makes no sense (it
could also be that I misunderstood what they were saying).

In any event, retaining 80 column widths so that things print under almost
all circumstances and on almost all printers is still an overriding factor.

All of our editors use non-proportional fonts, but your point is well taken.
If anyone edits with a proportional font, then their code will lose
readability when transferred to any other editor.

-- Mike --



Quote:



> >Steve,

> >4. This may seem trivial, but it's not. Use spaces, not tabs, specify the
> >number of spaces to be used for each level of indentation, and limit line
> >lengths to 80.

> I agree, it's not trivial.

> Minor addition; limit your font to non-proportional, eg Courier

>     ...and I don't understand the problems with long lines either?

> --

> Regards,

>   Brent Hayhoe.

> Nortel Networks plc,                      Tel: +44 (0)1279-402937
> Harlow Laboratories,  London Road,        Fax: +44 (0)1279-403930




Tue, 06 Nov 2001 03:00:00 GMT  
 Coding Standard
I mentioned your guidelines in my post. It's worth mentioning them again,
and it's also worth suggesting to the original poster that Synopsys
guidelines are, in my opinion, well thought out and well written. Even if
they don't decide to adopt your guidelines verbatim (or if they are using
~~shudder~~ a competitor's tool), it's worth looking at your guidelines to
get ideas for their own.

-- Mike --


Quote:
> Hi Steve,
>               It's probably worth deciding on why you want a coding
> standard. Is it for uniformity so that if code is passed from engineer to
> engineer, the learning curve is lessened; is it for efficient simulation
or
> is it for optimal synthesis results?  The latter two often used to be
> mutually exclusive, but most up-to-date tools will happily handle
simulation
> or synthesis slanted code.  As regards coding guidelines, each vendor
> probably has their own tricks and preferences.  It is worth noting that
we,
> Synopsys, are the de-facto standard for coding simply due to market share
in
> synthesis (~90%) and that if code portability is an issue, then code which
> our parsers will accept is likely to be usable by most other tools on the
> market.  We also have documented "style guidelines" which can be used as
the
> basis for training.

> Note also, that as a Synopsys employee, I am not necessarily unbiased!!!

> Paul

> --
> ***********************************************************************
> ** Paul Hands,                                 Tel: +44 (0)118 931 3822
> ** Regional Technical Manager,                 Fax: +44 (0)118 975 0081
> ** Synopsys (Northern Europe) Ltd.,          Mobile: +44 (0)7050 095680
> ** Imperium, Imperial Way,
> ** Worton Grange,

> ** England
> ***********************************************************************



Tue, 06 Nov 2001 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Language Standard - Coding Standard

2. C/C++ Code Reviews and Automatic Coding Standards and Metrics Tool

3. Coding Standards

4. Coding Standards

5. Coding Standards/Style Guides Wanted

6. Coding Standards/Style Guide Wanted

7. coding standards for SmallTalk

8. Coding Standards

9. Coding Standards

10. [VAST 4.02 Coding Standards]

11. Smalltalk Coding Standard?

12. Clipper coding standard

 

 
Powered by phpBB® Forum Software