... | @@ -4,20 +4,68 @@ |
... | @@ -4,20 +4,68 @@ |
|
|
|
|
|
Using the similar coding styles will ease re-useability. Many projects
|
|
Using the similar coding styles will ease re-useability. Many projects
|
|
on OHWR use the *Guidelines for VHDL Coding*.
|
|
on OHWR use the *Guidelines for VHDL Coding*.
|
|
[Guidelines for VHDL Coding](https://www.ohwr.org/project/hdl-core-lib/wikis/Documents/VHDL-coding-guidelines) (from
|
|
|
|
[HDL Core Lib project](https://www.ohwr.org/project/hdl-core-lib/wiki))
|
|
|
|
|
|
|
|
## Exceptions
|
|
- [Guidelines for VHDL Coding](https://www.ohwr.org/project/hdl-core-lib/wikis/Documents/VHDL-coding-guidelines)
|
|
|
|
(from [HDL Core Lib
|
|
|
|
project](https://www.ohwr.org/project/hdl-core-lib/wiki))
|
|
|
|
|
|
|
|
### Exceptions
|
|
|
|
|
|
The [White Rabbit core collection
|
|
The [White Rabbit core collection
|
|
project](https://www.ohwr.org/project/wr-cores/wiki) gives some
|
|
project](https://www.ohwr.org/project/wr-cores/wiki) gives some
|
|
exceptions and hints to make the Guidelines better usable for large
|
|
exceptions and hints to make the Guidelines better usable for large
|
|
complex modules.
|
|
complex modules.
|
|
|
|
|
|
White Rabbit core collection - Development - [Coding
|
|
- White Rabbit core collection - Development - [Coding
|
|
style](https://www.ohwr.org/project/wr-cores/wikis/Development-todo#coding-style)
|
|
style](https://www.ohwr.org/project/wr-cores/wikis/Development-todo#coding-style)
|
|
|
|
|
|
-----
|
|
-----
|
|
|
|
|
|
Erik van der Bij - 30 April 2012
|
|
## Usage of registers
|
|
|
|
|
|
|
|
The following are some hints that I received when I was a young fellow
|
|
|
|
designing some interface and spoke with a cleaver guy with login 'tbl'
|
|
|
|
who gave me some useful hints to make hardware that is easy to program.
|
|
|
|
Although those ideas are from the same time the web was being invented
|
|
|
|
at CERN, I think they are still valid and useful.
|
|
|
|
|
|
|
|
### Control registers
|
|
|
|
|
|
|
|
1. Make control registers all write-read. That way you can easily set a
|
|
|
|
single bit if needed without needing a copy of the data. Also easy
|
|
|
|
to check if everything works as you expect.
|
|
|
|
2. Default value (everything working as normal) should be 0. Anything
|
|
|
|
'special' set should be written as a 1.
|
|
|
|
3. Unused bits: define as: "reserved, write as 0.". This allows future
|
|
|
|
upgrades of hardware that still will work with old software that
|
|
|
|
doesn't know about added or hidden possibilities.
|
|
|
|
|
|
|
|
### Status registers
|
|
|
|
|
|
|
|
1. Default value (everything normal) should be 0. So you can easily see
|
|
|
|
if a bit is set.
|
|
|
|
2. Unused bits: define as: "reserved, ignore on read". This allows
|
|
|
|
future upgrades of hardware that still will work with old software
|
|
|
|
that doesn't know about added or hidden possibilities.
|
|
|
|
3. Interrupt status register (showing the cause of an interrupt):
|
|
|
|
actually the same as 4. But make the most significant bit an OR of
|
|
|
|
all the other bits, likely combined with an interrupt mask register.
|
|
|
|
With a single assembly instruction (check if negative) you can see
|
|
|
|
if any of the bits is set. This would make software go faster if it
|
|
|
|
has to scan many devices to check who has interrupted.
|
|
|
|
|
|
|
|
### General
|
|
|
|
|
|
|
|
1. Make that everything goes fast when things are OK (e.g with hint 6).
|
|
|
|
To find out what was the cause of an error condition may take much
|
|
|
|
more time.
|
|
|
|
2. If possible, make that your hardware can continue without an
|
|
|
|
interrupt being handled. E.g. one can have a counter that would show
|
|
|
|
how many interrupts it would have given when continued (e.g. number
|
|
|
|
of packets sent, so the software can just check off many items in a
|
|
|
|
list in one interrupt service routine).
|
|
|
|
|
|
|
|
-----
|
|
|
|
|
|
|
|
Erik van der Bij - 12 February 2013
|
|
|
|
|