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

[Rudolf Usselmann <rudi@asics.ws>]

On Mon, 2003-05-19 at 14:05, Joachim Strömbergson wrote:
> 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.

I believe such "guide lines" give a false sense of security that
an IP core is written in a sane way and will work. Design guide
lines will only be as good as the users that are using them.

Just because OC has had a design guideline posted for some time,
it doesn't mean that even one person has followed it. There is no
QA, or even such basic things as verification at OC. Designers
verify their own cores ! This is horrible in my opinion. You know
the chances that you will duplicate a bug in the test bench that
you did in your RTL are very great. So why even bother ?!

> 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?

Yes, we do want to lower the cost of integration. It is important.
However, a design guide line will not help here. It's only a guide
line that designers might or might not follow, and users might or
might not agree with. Fact is, ALL IP Cores (including commercial
IPs) use different styles/design guide lines. Each [commercial] IP
vendor has his own style/design guide line. There is no industry
standard. So no point here.

A few weeks ago we had a small argument about synchronous/asynchronous
reset. I always thought we would never have such a discussion as
*for me* the choice seemed so clear. But as we have found out,
different users have different preferences. Are they wrong ? Are
your customers wrong ? No, probably not. The truth is as engineers,
we can make the most bizarre design work and perform miraculous
tasks (look at Microsoft Operating Systems :-).

Quite honestly I do not understand what kind of expectations people
have from design guidelines. It's not a magic recipe that will make
all problems go away and allow us to throw IP cores together like a
bunch of Lego Bricks.

...
> Oh, and Altera Quartus-II did choke on the port value redefinition. 
> "Unsupported Verilog HDL Feature Error".

I'll add this to mi list of "Why do I not use Alteras Quartus
Software. The first item is it filled up a 10GB hard disk trying
to "compile" a 100K gate design ! While my full custom ASIC tools
have a hard time filling up a 4GB partition for a 2.5M gate ASIC.
Hmm, makes you sometimes wonder wat's in their "Design Guideline" !

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