Re: VHDL Coding Standards document
You need to declare the range of a integer to stop it being synthesised as a 32 bit integer.
Defining a integer as say range 0 to 12 will still require storage in this case ceil(log10(13)/Log10(2)) = 3.7 or in this case 4 bits which is 2^4 or a range of 0 to 15.
So regardless of how you define the counter 0 to 12 or 0 to 15 the storage will be the same. However, by declaring the range as a power of two it can help formal equivelance checking at a later point in time and will help with single event analysis for a safety critical design.
As integer counters do not wrap around it will allow you to use the mod function to ensure that the RTL simualtion will wrap around like the final implementation with no impact on the size of the implemented code. As MOD is not syntheisable excpet for powers of two and in this case should add no extra logic.
Hope this helps
ravi
6/9/2012 1:45:41 AM
User Rank Clever Clogs
VHDL Coding Standards document
I've gone through you "FIELD PROGRAMABLE GATE ARRAY VHDL CODING STANDARDS" pdf. Very good compilation. Thanks a lot.
I have a doubt regarding what is mentioned in Page 8 point 22. You say
"Integer counters should be declared to cover a range that is a power of two. For example a counter with a terminal value of 19 should be declared with a range of 0 to 31."
Could you please elaborate the reason for that? Isn't the range only to check the limit? Why should it be a power of 2?
Niki
6/7/2012 4:42:29 AM
User Rank Beginner
Port / Signal naming conventions
As has already been noted, there are as many coding styles as there are coders, and in the end consistency is more important than the exact style used. (for the record, I prefer lower case keywords and Pascal case identifiers. E.g. FifoWrEn etc.). There is one convention which I would like to share which I have found particularly useful though:
I prepend all signals with lower case 's' and all ports with lower case 'p'. E.g.
port (
-- Clock and reset
pClk : in std_logic;
pReset : in std_logic;
-- Outputs
pResult : out std_logic_vector(15 downto 0);
pResultValid : out std_logic;
...
signal sResult : std_logic_vector(15 downto 0);
signal sResultValid : std_logic;
...
pResult <= sResult;
This very simple convention has a number of advantages:
- At a glance you can discriminate between internal signals and ports.
- Ports that are of out direction and their associated signals have the same basic names, which inhances clarity.
- When instantiating instances, the port mappings can be as simple as pClk => sClk, pResult => sResult, etc. which also enhances clarity.
There are of course variations on this theme, and you can add more information about the type of signal and whether it is combinatorial or registered etc, but there is balance between cluttering the identifier with all possible information and readability. So I prefer just the 'p' and 's'.
Regards,
Niki
jimbrake
6/6/2012 9:58:57 PM
User Rank Beginner
Coding Styles
Once upon a time the DEC PDP11/34 had a caligraphic display. Lower case became available and was much more readable than all upper case. I think all user names should be in mostly lower case. Tend to use underscores instead of camel case. Besides, all upper case is "shouting".
cfelton
6/5/2012 2:40:39 PM
User Rank Guru
Re: Pondering Python
"""Python makes all things better – including coding style ..."""
+1
Re: Pondering Python
I must disagree with some of the principles in "The Zen of Python".
Explicit is not always better than implicit. In coding (and many other forms of communication--but often not humor or poetry), ambiguity is bad; but explicit declaration of all related information leads to excessive verbosity and hinders clarity.
While I am not a Perl (TIMTOWTDI) zealot, having a variety of ways of expressing a general concept allows flexible thinking. Any particular implementation may be optimal for a given set of uses and constraints, but not all uses and constraints are known beforehand. Rather than a monoculture, it seems more desirable to have diversity (which seems to require some degree of separation) with cross communication. What the proper synthesis of "write-only" (so peculiar that even the coder cannot later extend or even maintain it) code and "One True Way" (so sterile that massive rewriting is necessary for any change) code is beyond my understanding; but I do not think either extreme by itself is correct.
The inability to explain an implementation to any given person is not guaranteed to mark the implementation as bad. In some cases cleverness is required to meet design goals. Ideally abstraction and what I call implementation overloading (where a more generic and/or more understandable implementation is presented as equivalent [ideally with compiler-performed proofs of equivalence] to a specialized/optimized implementation) would allow sufficient understanding.
Again, I am not a programmer, but I have read a little bit (and thought a little bit) about the art.
Re: What do professional C programmers do?
While I am not a professional (or even hobbyist) programmer, I have read a little about programming. While naming styles vary, C/C++ is case sensitive, so keywords and standard library names are not variably styled (except in the presentation provided by the editor/IDE).
CamelCase (http://en.wikipedia.org/wiki/CamelCase ) seems to be preferred over the use of underscores, though some use of undistinguished run together words seems to still be used sometimes.
One convention uses ALLCAPS for constants (especially macros, including function macros), but this usage seems to be declining.
Some programmers seem to prefer a style which distinguishes class/structure names from primitive variables and functions.
Variations on Hungarian notation (http://en.wikipedia.org/wiki/Hungarian_notation ), where type information is included in the name, seem to be somewhat less popular now (perhaps especially for languages with potentially stronger type checking and when more powerful code display tools are commonly used).
Another convention I have seen in C/C++ is the use of one or two leading underscores to mark "internal" (to the compiler, to the language standard, to the library) names. C++ namespaces would seem to eliminate the need for such, but C and legacy C++ compatibility and old habits might keep such around.
I receive the impression that some of the fiercest style "Holy Wars" concern the use of whitespace. It seems to me that in most cases a filter could readily convert between a canonical (whitespace) style--used by the version control system--and any personally preferred style, at least as long as multiple coders are not sharing a display.
Naming conventions can also be somewhat controversial. E.g., some programmers are very upset by the use of nouns in function names (there is a rationale for this; functions are about actions, so using a noun tends to be inherently less clear).
Well, that's my (just a technophile not a programmer) two cents.
Re: Coding standards and guidelines...
No problem looking at it again as I uploaded it, it is pretty detailed but it does require some knowledge I think hope it is of use.
if you want any explanations let me know.
Brian
6/4/2012 4:10:21 PM
User Rank Guru
Re: Coding standards and guidelines...
@Adam: got it. Thanks for the PDF!
Re: Coding standards and guidelines...
|
|
Would you class these as adages, aphorisms, axioms, dictums, epigrams, maxims, precepts, saws, truisms, or... well, what?
Here we discover how to use the XADC (Xilinx Analog-to-Digital Convertor) in the Zynq All Programmable SoC to read the chip's internal temperature and voltage parameters and output them over an RS-232 link.
When extreme thermal cycling causes circuit boards and chip packages and the silicon die in the packages to expand and contract at different rates, problems may ensue.
In part 3 of this epic tale we consider how we might use tri-state buffers, leading up to the legendary bi-directional buffer.
Digital engineers are often confused among operational amplifiers, differential amplifiers, and instrumentation amplifiers; this is exacerbated by the fact that their circuit symbols can be similar.
|
Tweet This
