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

[Niclas Hedhman <niclas@hedhman.org>]

On Wednesday 28 May 2003 07:33 am, Tom Hawkins wrote:
> On Wednesday 28 May 2003 08:20 am, Marko Mlinar wrote:
> > wire[31:0] x = wishbone.read(address);
> >
> > where 'read' is a part of bus interface interface.
>
> What is the behavior of the above?  I am interpreting this as, "A bus
> object 'wishbone' has a 'read' method that when given an 'address'
> performs a read operation and returns a result."

In 'pure' OO, the behavioural model belongs to the class of the wishbone 
instance, it cannot be implied by looking at the usage. And this can be hard 
to twist your head around (not saying that OO is suitable for RTL synthesis, 
I don't yet). C++ allows operator overloading, that means that you can 
redefine the meaning of all operators, so that;

a = b + c;

could mean anything, and worse yet, resolved in runtime, so the operator 
behaviour can depend on the subclass implementation of the type of these 
parameters. And then throw in cast-operator overloading, and suddenly you can 
really mess up the meaning, when you mix the types.

Nevertheless, noone (except Microsoft) ever uses the operator overloading for 
anything but the obvious;

String a = oneString + anotherString;

compared to the C alternative (or the "behavioural model");

char * a = malloc( strlen(oneString) + strlen(anotherString) );
strcpy( a, oneString );
strcat( a, anotherString );


> This implies that result is stored in some sort of register that is
> updated when the 'read' method is called.  But where and when is it
> valid to call 'read'?  Is this a continuous action, or can it only be
> invoked inside a synchronized always block?  What kind of logic can
> drive 'address'?  Is the following valid?
>
>   x = wishbone0.read(wishbone1.read(address));

I had the similar type of questions when I went from a procedural to OO 
software model. And I also found a lot of ways to make it very confusing to 
prove a point, but I could do worse in C;

For instance, this is actual code in one of my early C programs;
	p = (*f[p])(s,p);
p = pointer in interpreted code,
f = array of pointers to functions
s = pointer to top of stack
(implementation of a 'bytecode' interpreter)

Everything can be abused, and some people don't want to increase the 
abstraction level. That should be considered OK, and languages that evolves 
stands a much better chance of survival than brand new ones, history has 
shown in SW more than once.


Cheers
Niclas


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