Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1

[Rudolf Usselmann <rudi@asics.ws>]

On Mon, 2003-05-19 at 15:11, Bjorn Olsson wrote:
> Excuse me for barging into the discussion, but I couldn't
> help myself... :-)
> 
> Rudolf Usselmann wrote:
> > Two things here:
> > 
> > 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.
> 
> I agree with you... and not. In a company it is one thing, but
> here we have an OC-case, meaning that any designer - who may have
> a different coding style than the original author - should be
> able take the OC and use it. If you do at least some common
> guide lines that OC users are aware of, I believe that the
> use of OC would increase drastically.
> 
> I also think that there are a large number of "decent" designers
> out there who really writes crappy code, due to the abscense
> of guide lines. They would really benefit from that. Without
> removing the artistic freedom of course... :-)

Well, bad designers will be bad designers no matter how many
Design Guidelines you throw at them. Unfortunately there is a
misconception that a design guide line will make bad code work
better.

Most design Guidelines I have seen are really "Style" Guidelines.
And styles are a matter of preference. As we can see, further below,
you would never use parameterized modules. I think that statement
is absurd. So when writing generic modules, such as an adder, you
write and hard code (either really hard code, or in the parameters
inside the module) the width of the adder ?! I would write the
adder only once, and pass the width from the top level.

You see neither one of us is right or wrong, we both have our
preferences.

> > Second, Joachim, shame on you !!!
> > 
> > What Paul has written is perfectly legal and synthesizable
> > code !
> 
> Yes it is, but I would never use it due to the enormous
> potential for misunderstandings.
...
> 
> Yes. But for clearance the parameter could (and should) have been
> included in the parameter list. Personally I find it horrible to
> see the use of a parameter in a module that turns out not to be
> the defined value, but instead a passed value from some other part
> of the code. Often a completely different file.

Hugh ? Say again !? What ? You can only pass parameters by
defparam and by passing them to the module directly as Paul
did. And I believe defparam is being retired ...

> I don't argue the validity of the statement, but the code style is
> such that I would not use it, and I don't consider myself to be alone
> in that standpoint.
> 
> The reason for OC is for people to use it, right? If people don't,
> then whose fault is that?

Again, I seriously doubt that a design guideline will help. 

Look, this is a mute point anyway, since OC already has a Design
Guideline and nobody has suggested to remove it.
The OC guideline has been in place for quite some time, and I
haven't seen any improvement.

> 
> Compare:
> 
> A man at the car dealer: "I would like to buy a Volvo".
> The salesman: "That is ok, here you have a Saab."
> Of course the buyer leaves the store.
> The salesman: "Hey what? This car works just as good"
> 
> Who was right?

I don't get this, this doesn't make any sense ...

> Ha de!
> 
> Björn Olsson
> InformAsic AB

Cheers,
rudi               
-------------------------------------------------------
www.asics.ws  -- Solutions for your ASIC/FPGA needs ---
---------------- FPGAs * Full Custom ICs * IP Cores ---
* * * FREE IP Cores  --> http://www.asics.ws/ <-- * * *

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml