03-12-2018 09:42 AM
I came accross the following Xilinx document - found on the web - and I'm wondering how up-to-date this still is with regard to Vivado (2017.4 is the latest release at the time of writing).
I read through the document, and I'm mainly interested in 'naming conventions' used by Xilinx, when creating their own IP, examples, ... There are also guidelines on synthesis & inference, but UG901 (Vivado Synthesis Guide) is probably more up-to-date and 'the reference' for Vivado. However, it does only slightly cover 'naming conventions', and I found this document to be more complete and interesting.
Q: Is the above document still applicable with regards to naming of variables, signals, procedures, clock, reset, ...? Or is there any updated version of this document?
03-12-2018 10:14 AM
I just read through this, and it's definitely looking dated, despite some excellent advice which still remains absolutely true. The two areas that I thought needed updating was the signal naming recommendations, and the FSM philosophy.
I have a few things I like to do in VHDL signal naming..
Low level blocks with unconstrained ports are the bomb, and recursion should be encouraged, which is something barely tolerated now.
Anyway, the guide has some good advice, but badly needs updating, since 2 and 3 process state machines are definitely something from the 90's. I always just use 1 process these days. It also lacks any advice on physical synthesis approaches, which is a serious topic now with Vivado.
03-12-2018 10:31 AM
It is beneficial to differentiate the types of signals one will generate in the code. Differentiating between clocked and combinatorial signals is critical in many aspects of design and debug. So here's my take at it:
4a. Clocked signals have a prefix "f_"
4b. Combinatorial signals have a prefix "c_"
4c. Wires have a prefix "w_" -- Any connection that contains no logic changes. i.e. Connecting two components
3. For bi-directional pins "b_" -- Slightly easier to view than "io_" when filtering signals by prefix
5. Constants have "k_" instead of the stated "C_".
9. Variables have the prefix "v_"
10. Active Low signals have a suffix of "_n"
03-12-2018 01:25 PM - edited 03-12-2018 01:26 PM
@ronnywebers Its a pretty standard style document Ive seen in many places, where rules generally dont get adhered to. Some people love using i_ and o_ , and some dont. Given it appears to be a xilinx internal document, and the port names I see on Xilinx IP, I dont think they stick to the rules much either!
Personally, I just stick with the mantra that it should be clear, with useful/clear signal names, with plenty of comments explaining why (not how) you have done things the way you have. I also like to align all my code "nicely" (column edit essential for this!)
@jmcclusk Low level blocks with unconstrained ports are the bomb
Indeed they are. Especially when you mix in VHDL 2008 with unconstrained arrays and record types.
Although probably not so useful for synthesis, but definitely for simulation, are generic types, functions and packages. The LRM will even allow a package as a generic to anything (waiting for support from simulators on this one though - ER raised with Aldec!). Add in external names and you can start building yourself a testbench that behaves like UVM with just a VHDL licence!
03-14-2018 05:45 AM
thanks all for sharing your 'habits' :-) I'll leave this thread open for a while, still hoping someone from Xilinx comments on this post too.
Common sense is of course a good habit. Having these 'different' habbits here listed up, helps to construct an (minimal) own/company standard.
I know beforehand that it will not always be adhered to by everyone, but having 'a' standard is definitely more productive and will allow for easier code exchange than having no standard at all.
03-14-2018 05:55 AM - edited 03-14-2018 05:56 AM
Just be mindful that too prescriptive a standard can just annoy people, and code reviews can often boil down to a check of whether the standard has been followed, rather than whether the design appears to meet the design intent. This is what we found when we proscribed a coding standard and mandatory code reviews.
After a while, we decided that as long as people were following the spirit of the rules, then it was easier to study if the code followed design intent. Also, if they are too prescriptive, it can sometimes prevent nicer ways to code as new features are supported, like 2008 features for example.
As with all rules, they are made to be broken.