... | ... | @@ -50,6 +50,8 @@ complex modules. |
|
|
needed (e.g. gc\_sync\_ffs in modules/common of
|
|
|
[general-cores](https://www.ohwr.org/project/general-cores))
|
|
|
- Replace deep if-then statements by state machine
|
|
|
- Initialize in reset all signals for which you assign value in a
|
|
|
process
|
|
|
- State machine recover from illegal states, i.e. always define the
|
|
|
"others" state, preferably to go to IDLE state of your state
|
|
|
machine, if happens.
|
... | ... | @@ -67,28 +69,32 @@ complex modules. |
|
|
- the names of clock signals, whenever it is known/fixed, indicate
|
|
|
the frequency, e.g..: clk\_125m\_pllref, clk\_80m\_ADC,
|
|
|
clk\_20m\_vcxo\_i
|
|
|
- make sure that only needed signals are in sensitivity list of a
|
|
|
- Make sure that only needed signals are in sensitivity list of a
|
|
|
process (e.g. if you use process with synchronous reset, make sure
|
|
|
reset is not in sensitivity list)
|
|
|
- do not use "new" and "old" in the names (the new will become old
|
|
|
- Do not use "new" and "old" in the names (the new will become old
|
|
|
very fast and the name will mean nothing)
|
|
|
- before starting to implement a module/function that is not specific
|
|
|
to your project (say, it deals with Endianess or calculate CRC,
|
|
|
check whether such a function is already in general-cores)
|
|
|
- examples of non-clear code
|
|
|
- before using asynchronous input signals (e.g. from DIO) in your
|
|
|
- Check whether the module or function that you want to develop and
|
|
|
that is not specific to your project (say, it deals with Endianess
|
|
|
or calculate CRC) exists already in
|
|
|
[general-cores](https://www.ohwr.org/project/general-cores) or
|
|
|
[wr-cores](https://www.ohwr.org/project/wr-cores)
|
|
|
- Before using a asynchronous input signal (e.g. from DIO) in your
|
|
|
synchronous design, first synchronise it with your clock domain and
|
|
|
then deglitch the signal, preferably use
|
|
|
gc\_async\_signals\_input\_stage in modules/common of
|
|
|
[general-cores](https://www.ohwr.org/project/general-cores)
|
|
|
- if your code is auto-generated (e.g. by wbgen2) do not modify it
|
|
|
unless you are really sure what you do (usually, this never happens)
|
|
|
- If your code is auto-generated (e.g. by wbgen2) do not modify it,
|
|
|
unless you are really sure what you do (usually you need to do the
|
|
|
modification because you don't know)
|
|
|
- State copyright and license in all files, [see
|
|
|
example](https://www.ohwr.org/4734)
|
|
|
- Git:
|
|
|
- don't commit Modelsim <sub>transcript</sub>
|
|
|
- don't commit the <sub>.xise</sub> in <sub>syn/</sub> unless it's
|
|
|
in a release commit
|
|
|
- Follow good practices when using git, in specific for HDL designs:
|
|
|
- don't commit Modelsim "**transcript**"
|
|
|
- don't commit the "\*.xise" in syn/ folder unless it's in a
|
|
|
release commit
|
|
|
- Remove unused signals/variables/inputs/outputs
|
|
|
- Avoid ambiguous code, e.g:
|
|
|
- Set a signal, use value on line afterwards (takes 'previous'
|
|
|
value). Behavior would be different if it was a variable
|
|
|
|
... | ... | |