[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1
> > The OO defines an abstraction in different way than just defining
> > 'interface' module as it is currently done in Verilog. For example
> > you may define wishbone interface:
> >
> > 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."
It depends how you declare it -- normally you would want something like:
wishbone users and share the same wishbone resource, at the return the result
of a wire that goes from a data mux.
Look to a 'read' function as to logic generator.
> 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));
yes.
> This feels like sequential software -- synthesis would have to
> generate an machine (aka, processor) to implement these sequential
> transactions. Maybe I'm just having a hard time understanding how OO
> and RTL can work together. I'd appreciate your input! What language
> and tools are you using?
The statements are sequential but behavior is not.
It could be done sequentially also, but normally HW requires a lot of
paralelism.
The only problem here is that you have to define to which clock is it
sequential, but this can be done in the read function.
> If your example is just another means to instantiate a bus reader,
> well then Confluence is OO too!
>
> X <- {Wishbone.Reader, WishboneBus Address, $}
exactly, you can do the same with module instantiation in Verilog, however
with OO you can define interfaces and abstractions which are very much needed
for big designs and big companies.
(but note that the in Verilog and probably also in confluence solution is not
as straighforward as it seems at first glance, as I did suggest above).
Marko
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml