RE: [oc] HDL coding guidelines

["Illan Glasner" <iglasner@zumanetworks.com>]

16-May-01

   Damjan Hi

	   Few commets :

1.
"Recommendation Avoid using 'ifdef' command. Try to use a global define
file that encapsulates all definitions. "

Some toold have problem with ifdef and don't support it and some tools
have even problme with define or at least require it to be in certain
order so I would say even better try to use parameter if posiable,
especaily when it come to Asic as you might end up with something
completly differnt than what you expect.

2.
"Strong Recommendation: Avoid using tri-state signals.
It increases the power consumption. It makes the backend tuning more
difficult."

I would suggest change it to recomendation or advise/good-practice  and
not Strong as in Asic not like in FPGA monitoring the states of the
whole chip is crusial for debug incase of problem and there is no way
you can monitor let say 1000-2000 wires using muxes and the better way
even tho' it have it's own disadvantage is using tri-state.

3.
"Signals that cross different clock domains should be sampled before and
after the crossing domains (double sampling is preferred)."

If you talk about Asic double sampling is not preferred but rather a
MUST , also to make netlist verification easier you should use one
module let say sync.v that will have in out and clk interface and the
first FF should have a unique name as this FF will have timing violation
and if it have unique name it is easier to trace it and "change" it to
not pass X's.

Also it should be clear that you pass ONLY the control signal and not
the data bus etc.

4.
"Strong Recommendation: All blocks external IOs should be sampled. "
When it come to FPGA Consider double sample this way the "outside" FF
can be put on the I/O and achive better su/ck->o.

5.
"Good Practice: In the global definition file, write at the beginning
'timescale' command : 'timescale 1n/10p'. "
any special reason why 1n/10p or not let say 1n/1n or 1n/100p ? I would
suggest have all FF clk->Q of 1n and other value only if there is a
specail reason.

6.
"Good Practice: Try to write '%m' in 'display' command (shows the
instance name). "
Also add the designer initial name to enable greping only your display.

7.
"Strong Recommendation: All system tasks for simulation should be within
a Synopsys command 'synopsys translate on/off'. "
or maybe consider having a monitor files that look right into the file
and this way your core code is clean.

8.
"Recommendation: Try to use the 'include' command without a path."
or maybe try to avoid `inculde, the -y -v and direct read of the module
name, will do the same as well as will if you add a file or remove one
you most likely will not need to do anything.

Also :
a. top level files should be conectivity only except the IO (including
tri-state), PLL/DLL.
b. incase of an Asic have a layer for the Jtag which will be inserted in
many cases by the vendor with whom you work.
c. consider bringing up all the memories at least when designing for
Asic.

have a nice day

   Illan


-----Original Message-----
From: Damjan Lampret [mailto:lampret@opencores.org]
Sent: Wednesday, May 16, 2001 9:55 AM
To: cores@opencores.org
Subject: [oc] HDL coding guidelines


Hello everyone,

Please take a moment and review HDL coding guidelines. They are very
important for HDL code coming from different developers with different
experience and using different tools to be portable accross different
EDA
environments and technologies. All comments/corrections/suggestions to
the
guidelines are welcome.

http://www.opencores.org/guidelines.shtml

This guidelines are part of other guidelines that also cover verfication
and
design. Once we are happy with all guidelines, they will be published on
opencores web site.

regards,
Damjan