[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1
>>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.
I am not suggesting that a design guide would make bad code work
better. Not at all. What I saying is that a design guide might
make good code look more understandable and therefore make the
code more useful. There is a difference.
> 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.
... well, I don't. :-)
> 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...)
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.
> You see neither one of us is right or wrong, we both have our
> preferences.
Agree.
>>>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 see that my english failed me and it became blurry. I'm sorry
about that. I think the example above explains what I was trying
to say... ;-) I would probably not use defparam either, but rather
a standard parameter definition: "parameter Kalle=8'hAA;" or similar.
This is however an academic discussion... ;-)
>>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.
The reason for lack of improvement is probably that is hasn't been
emphasized enough that people should use the guidelines. Furthermore,
if you put a requirement on peoples code to follow ther guide lines
or else they will not be approved as an OC official release, I believe
you would in some time start to see an improvement.
I believe Niclas had an excellent point there. We are talking about
OC here. "If I open up a piece of code, the more familiar I am to that
particular style, the quicker I can understand what is going on."
This will make OC more attractive for designers, and more people will
benefit from OC.
(I'll even toss in a torch here: If Open Cores conformed to the world,
tossed the WishBone bus and instead used one of the industry standard
buses, (like for instance AMBA or Core-Connect) even more people would
start benefit from OC... my five cents of thoughts...)
>>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 ...
Well, I was trying to make an ironic point here. Obviously I failed...
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...)
Ha de!
/Björn
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml