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

[Bjorn Olsson <Bjorn.Olsson@InformAsic.com>]

Rudolf Usselmann wrote:
> On Tue, 2003-05-20 at 16:30, Bjorn Olsson wrote:
> 
>>>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.
>>
>>No, I would define the parameters once, possibly in an include file,
>>and then pass them along in the list passed on to the module.
>>
>>Such as: module Kalle(PARAMETER_1, PARAMETER_2, etc...)
> 
> 
> This is not how parameters are being passed. This how
> you pass signals/wires/connections.

I know the difference. I just would not pass a parameter the way you
use it. But again, if OC guide lines forced me to write it like that,
I would probably do it, for conformity reasons... ;-)

>>I just don't want to look at a block where parameter WITDH=1
>>and then it turns out that it actually something completely
>>different. I belive the parameters should be defined once
>>and then not changed inside the code.
> 
> 
> Well, the modules basic functionality doesn't necessarily
> change, only the data bus widths.
> 
> I still don't understand why you have a problem with parameters.
> When reading source code you can clearly see them ...
> 
> Anyway, there are alternative and they should satisfy your
> needs ... I don't see any point arguing over a dead dog ...

Agree.

>>I could try a short explanation: Let's assume you get a request for
>>a specific core. You have one on the OC website so you offer "the customer"
>>your OC code. "The customer" doesn't immediately understand it. He
>>therefore goes someplace else or writes the code himself.
>>Now, if you had provided "a Volvo", or code that at least were written
>>according to some conformity style, he might had understood the code
>>faster and therefore used it. You would, by spending a little extra effort
>>(time) have saved his time. Big deal? Well, maybe not if it's just _one_
>>customer. But we are OC. The numbers of customers out there is huge...
>>
>>Get my point? (BTW the same point as Niclas is trying to make...)
> 
> 
> No still don't get it. parameters don't change a core any
> more than define statements and other macros you include
> through include files or whatever mechanism you prefer. So
> if you have an adder that allows you to parameterize it's
> bus width, it does not mean it all of a sudden becomes a
> multiplier.
> 
> I guess you are trying to make the analogy that you are
> ordering a Volvo, but are getting a Saab. Now, I don't
> know enough about Swedish cars, bit I believe that this
> is a wrong comparison. Perhaps this will help you better
> understand it: You order a BMW 740iL with a 4 liter V6
> engine, but the dealer delivers you a BMW 750iL which
> has a 5 liter V8 engine, because his parameters where
> screwed up. However, in both cases you got a 7 series BMW
> same body, same features !

Sigh. Forget about the cars. It could have been any merchandise whatsoever.
The point is that if "the buyer" doesn't understand what he sees, he is less
likely to use it. Simply for the reason that he can't spend valuable
company time trying to figure it out.

What I am trying to explain is that if OC had a common guideline so that
you knew what to expect when downloading a core, then more people would
use and benefit from OC. I can't understand why you refuse to accept this?

Mark, I am not saying that _my_ coding should be the one and only. It could
very well be yours, or better yet, a mix. As long as there is anything...

>>Ha de!
> 
> 
> I hope this means something nice ! ;*)

It actually does. Short for "have a nice day" sort of...

Ha de!

/Bjorn

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