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

[teju-dj@attbi.com]

Perhaps I can add a point here to support the arguement for using the #
(parameter) in designs.

Currently I am workin on a very large custom ASIC and we are using #
(parameter) for all our well defined modules.  For example, we have one 
and only one FIFO sturcture that is written by one of the designers and 
it has been blessed by synthesis tools as well as PD guys.  Hence, all of 
us just instantiate the block by doing:

dpFIFO #(SIZE, ADDR_SIZE, WIDTH) (/*AUTOINST*/);

This way we won't get any surprises when we go to synthesis and 
layout.  Imagine that this is an async. FIFOs, it would be even more 
scary if everyone of us defined our own async. FIFOs.

Hence, it is more a design style, rather than should or should not.  In 
many cases, if a designer already have a handful of well define blocks 
(Flops, Muxes, FIFOs,.... ) in his library, why shouldn't he just use #
(parameter) to instantiate blocks?  It really cuts down a lot in the 
development time and it also helps to avoid bugs.

IMHO.

- Teju

----- Original Message ----- 
From: Rudolf Usselmann <rudi@a... > 
To: cores@o...  
Date: 20 May 2003 21:20:00 +0700 
Subject: Re: [oc] Verilog coding style for Open Cores-RTL - Case in 
pointSHA1 

> 
> 
> 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 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 ... 
> 
> .... 
> > 
> > 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 ! 
> 
> 
> > Ha de! 
> 
> I hope this means something nice ! ;*) 
> 
> > /Björn 
> > 
> > 
> 
> 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