|
Message
From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?=<Joachim.Strombergson@I...>
Date: Mon, 19 May 2003 09:05:28 +0200
Subject: Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1
Aloha!
Rudolf Usselmann wrote:
> First of I want to re-state that I am totally against
> Coding/Design Guidelines, as every decent engineer will
> have his/her own style and will know what he is doing.
Totally against? So you think that these two documents available today on the
OC site should be hosed?
http://www.opencores.org/OIPC/projects/coding.shtml
http://www.opencores.org/cgi-bin/cvsget.cgi/common/opencores_coding_guidelines.pdf
Most commercial cores (that are available as readable RTL) follow some sort of
vendor guidelines. Additionally, soft, firm and hard cores usuall comply to
documented rules and guidelines, particularly on the interface (where it's
really needed). Clocking, reset and naming conventions for the interface is
there to make the integration process easier, and thereby the cost of
integrting a core lower.
Since we've been talking about getting acceptance for OC-cores in the
industry, lowering the barrier/cost of integration is one thing I belive is
important. No?
> Second, Joachim, shame on you !!!
Ouch!
> What Paul has written is perfectly legal and synthesizable
> code !
>
> Those are NOT delay statements ! Those are parameters that
> are passed the dffhr module. I admit it does look a bit
> misleading. What that really does is passes the number in
> "#(nnn)" to the modules firs parameter statement.
>
> Looking at Pauls code:
>
> module dffhr (d, r, clk, q);
> parameter WIDTH = 1;
> ....
>
> Now, we see that that parameter is "WIDTH". So Paul is instantiating
> the "dffhr" module several times with different width ...
Must have been extremely tired friday night. You are absolutely right. It's
amazing what operator overloading can do to confuse a tired engineer.
Looking at Sutherlands excellent Verilog HDL reference, we can see the three
types of uses for "(#<value>)".
http://www.sutherland-hdl.com/on-line_ref_guide/vlog_ref_body.shtml#7.0%20Data%20Type%20Declarations
http://www.sutherland-hdl.com/on-line_ref_guide/vlog_ref_body.shtml#8.0%20Module%20Instances
http://www.sutherland-hdl.com/on-line_ref_guide/vlog_ref_body.shtml#9.0%20Primitive%20Instances
For two of these, type declarations and primitive instantiation, (#<value>)
means delay, for the third (#<value>) it is compile time implicit redefine of
port value.
My old, trusty Verilog Golden Reference even has a warning about this (but not
against using it for port value redefines) - and I fell for it anyway.
Oh, and Altera Quartus-II did choke on the port value redefinition.
"Unsupported Verilog HDL Feature Error".
--
Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning.
VP, Research & Development
----------------------------------------------------------------------
InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden
Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02
E-mail: joachim.strombergson@i... Home: www.informasic.com
----------------------------------------------------------------------
|
 |
Browse
