Re: [oc] HDL coding guidelines

["Damjan Lampret" <lampret@opencores.org>]

Hi Illan,

thank you very much for your comments. I'll include them in modified
guidelines..

regards,
Damjan

----- Original Message -----
From: "Illan Glasner" <iglasner@zumanetworks.com>
To: <cores@opencores.org>
Cc: <lampret@opencores.org>
Sent: Wednesday, May 16, 2001 10:54 PM
Subject: RE: [oc] HDL coding guidelines


> 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
>
>
>