myhdl-list

[myhdl-list] classes as interfaces

[Patricio K. <pat...@gm...>]

Hello, let me start by saying that I think myHDL is really cool. I am
playing with it and I see lots of potential.

I am trying to use a class as a system verilog interface, i.e. as a
collection of signals. It does not seem to synthesize though. I saw a
previous posting related to this, but I just want to present an example
where classes come handy.

Can anyone tell me if this is illegal and if so, what is the right approach?

thanks!
-patricio


class spi_if:
        # class attributes
        srdy = Signal(intbv(0)[1:0])
        drdy = Signal(intbv(0)[1:0])
        size = Signal(intbv(0)[3:0])
        data = Signal(intbv(0)[64:0])
        sop  = Signal(intbv(0)[1:0])
        eop  = Signal(intbv(0)[1:0])

def padder(padding, count, rx_spi, tx_spi, clk, rst):

    @always_comb
    def comb():
        rx_spi.drdy.next=(int(tx_spi.drdy==1 and padding==0 or
tx_spi.srdy==0))

    @always(clk.posedge)
    def seq():
        if rst:
                padding.next=0
                count.next=0
                tx_spi.srdy.next=0
        elif tx_spi.srdy==0 or tx_spi.drdy==1: # ready for new flit
                if padding:
                        tx_spi.srdy.next=1
                        count.next= count+8
                        if (count+8)==64:
                                padding.next=0
                elif rx_spi.srdy==1:
                        tx_spi.srdy.next=1

                        if rx_spi.eop==1 and rx_spi.size!=0:
                                tmp_count = count + rx_spi.size.val
                        else:
                                tmp_count= count + 8

Re: [myhdl-list] classes as interfaces

[Tom D. <TD...@di...>]

I agree this that having something along this line would be useful.

Some time ago, I tried to create a class that would represent a complex 
number, basically a real and imaginary signal that I could just pass around 
as a single signal. 

It worked fine, till I tried to use toVerilog, then ran into troubles that I 
couldn't get around. 

toVerilog would need to accept an object of a class as I/O and look inside the 
object for any signals, each one of them becoming a port. 

I'm sure that is way over simplified, but that is the idea.

Tom


On Tuesday 09 October 2007 09:48:00 pm Patricio Kaplan wrote:
> Hello, let me start by saying that I think myHDL is really cool. I am
> playing with it and I see lots of potential.
>
> I am trying to use a class as a system verilog interface, i.e. as a
> collection of signals. It does not seem to synthesize though. I saw a
> previous posting related to this, but I just want to present an example
> where classes come handy.
>
> Can anyone tell me if this is illegal and if so, what is the right
> approach?
>
> thanks!
> -patricio
>
>
> class spi_if:
>         # class attributes
>         srdy = Signal(intbv(0)[1:0])
>         drdy = Signal(intbv(0)[1:0])
>         size = Signal(intbv(0)[3:0])
>         data = Signal(intbv(0)[64:0])
>         sop  = Signal(intbv(0)[1:0])
>         eop  = Signal(intbv(0)[1:0])
>
> def padder(padding, count, rx_spi, tx_spi, clk, rst):
>
>     @always_comb
>     def comb():
>         rx_spi.drdy.next=(int(tx_spi.drdy==1 and padding==0 or
> tx_spi.srdy==0))
>
>     @always(clk.posedge)
>     def seq():
>         if rst:
>                 padding.next=0
>                 count.next=0
>                 tx_spi.srdy.next=0
>         elif tx_spi.srdy==0 or tx_spi.drdy==1: # ready for new flit
>                 if padding:
>                         tx_spi.srdy.next=1
>                         count.next= count+8
>                         if (count+8)==64:
>                                 padding.next=0
>                 elif rx_spi.srdy==1:
>                         tx_spi.srdy.next=1
>
>                         if rx_spi.eop==1 and rx_spi.size!=0:
>                                 tmp_count = count + rx_spi.size.val
>                         else:
>                                 tmp_count= count + 8

Re: [myhdl-list] classes as interfaces

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> I agree this that having something along this line would be useful.
> 
> Some time ago, I tried to create a class that would represent a complex 
> number, basically a real and imaginary signal that I could just pass around 
> as a single signal. 
> 
> It worked fine, till I tried to use toVerilog, then ran into troubles that I 
> couldn't get around. 
> 
> toVerilog would need to accept an object of a class as I/O and look inside the 
> object for any signals, each one of them becoming a port.

Yes, this is a very good idea. It's the way I would like to have support for
"signal bundling". Here are some early remarks and thoughts.

First, note that there's no problem in using "interfaces" for MyHDL modeling.
It may seem obvious, but I don't think it is: MyHDL "minimalistic" approach
makes it possible to use it in "unforeseen" ways.

Unfortunately, the minimalistic approach falls down with conversion, because
there you have to take into account another language also :-) In that case
anything not explicitly foreseen won't work. So don't get frustrated in trying
to do signal lookups in objects with toVerilog: it's not currently implemented,
and it won't work. (As always, this is only for code within generators.)

To implement this, we'll need to do some hard thinking about some details.
I would like to play the old trick to support it without requiring that
the target language supports it. In other words, you would be able to
use MyHDL interfaces even if you only have "simple" Verilog (not SystemVerilog)
or VHDL in the backend. That would be a nice bonus for MyHDL.

To do this, interfaces would have to become part of the "hierarchy" in some
way so they can get "flattened out" by the conversion. These are some
issues and implications:

- hierachy traversal is too complicated to my taste at this moment, I'd
like to simplify it before making it more complex. More specifically,
I'd like to support decorated function and generators *only*. (Currently
the convertors support all kind of generators.)

- one issue to resolve is whether interfaces should be viewed as
a "super-signal" or a "kind of module". In the first case they would
register themselves automatically (as signals do), in the second case
the designer would have to return them somewhere (as with instances).

Another issue is that sooner or later people may want to add behavior
to interfaces (this should work with modeling currently) and expect
to convert this to Verilog. Probably not required for a first version,
but something to keep in mind.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com