O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
Creating your own
Dr. Ir. Philippe Faes
● What is coding style
● Purpose of a coding style
● Types of coding rules
● Quality criteria for coding rules
● Enforcing coding style
What is a coding style?
Programming style is a set of rules or guidelines used
when writing the source code for a computer program. It is
often claimed that following a particular programming style
will help programmers to read and understand source code
conforming to the style, and help to avoid introducing
Brought to attention in 1974 by Kernighan and Plauger
book: “The Elements of Programming Style”
[coding | programming | style] [style | conventions | rules]
What is its Purpose?
● Increase readability and maintainability
● Reduce risk of defects
Try to avoid this, but we won’t complain if you
break this rule.
Avoid this. You have to document when you
break this rule.
Don’t break this rule. No excuses.
Useful rules are rules that have important
implications, and there is a good reason for
having this rule, even if there may be
arguments against it.
Arbitrary rules don’t have large practical
implications. Sometimes arbitrary rules are
used for consistency.
Adverse rules don’t have any benefit. The
claimed benefit may be incorrect or outdated.
How to read rules
Useful rules: examples
● sensitivity lists
● rules for clock domain crossing
● recommended third-party or in-house libraries
● deprecated libraries
● style for Finite State Machines
● reset strategy, initial values of signals or
● allowed / disallowed preprocessor code
Arbitrary rules: examples
Usually rules that improve code consistency.
● Capitalisation: UPPER and lower case
● Indentation and whitespace
● Naming conventions like rst_n
● File structure, copyright headers
Formalise what you have.
Don’t overdo these rules.
Many rules that include “weasel terms” like:
○ “... may result in larger circuit”
○ “... may result in slower clock speed”
● Is this documented?
○ Can I verify this for my current synthesis tool?
○ Which code snippet and with which tool chain?
=> TEST it yourself
● Is it important?
○ error-free, on time, on budget
versus saving two LUTs or 5% of clock speed
=> use common sense
“Some synthesis tools may not support this.”
Ask youself: which synthesis tools?
(not AcmeSynth from 1994?)
If you sell IP cores, you may have to adhere to the
greatest common denominator of current (not historical!)
If you build your own design, you should only worry about
your current tool chain, or a few common and modern tool
Not supported for synthesis?
Do NOT start from somebody else’s style book!
● You are prone to copy their errors
● Instead: read a few style books and then put
them away for a week.
● Be critical of rules and validate their reason
How to start writing
your own style guide
Example stylebook structure
● file and directory structure and naming
● file headers, what to put in a file
● naming conventions