Re: [myhdl-list] IP core library

[Christopher F. <chr...@gm...>]

On 4/25/15 4:49 PM, Euripedes Rocha Filho wrote:
>
>
> 2015-04-25 18:15 GMT-03:00 Christopher Felton <chr...@gm...
> <mailto:chr...@gm...>>:
>
>     On 4/25/15 1:54 PM, Euripedes Rocha Filho wrote:
>     > Hi,
>     > I'm starting a small (actually no IP so far) library and wondering if
>      > someone has some suggestion on how to structure it.Â
>
>     This is great, more IP (cores) development the
>     better.  Using common Python package structure
>     is a good place to start.
>
>     There are various projects out there,
>     here are a couple that you can look at:
>
>     This is my small collection of "cores", I slowly
>     add to it as I have time ...
>     https://github.com/cfelton/minnesota
>
>     FPGA digital radio (SDR) using MyHDL:
>     https://github.com/testaco/whitebox
>
>     Keerthan's HDL toolbox:
>     https://github.com/jck/uhdl
>
>     >
>     > The repository (just started the package using cookiecutter)
>      > Â https://github.com/euripedesrocha/instar
>     >
>     > My idea is to use MyHDL as both simulation and hdl decription language,
>     > using verilog conversion to put the design under the regular FPGA work
>     > flow ( also I'll use Chistopher's myhdl_tools package in the build flow ).
>     >
>
>     Note, I have moved the FPGA flow from myhdl_tools
>     to gizflo (couple reasons why and I can explain
>     if interested)
>     https://github.com/cfelton/gizflo
>
>
> I'll follow your movement and will clone and eventually contribute to
> gizflo.Â
>
>
>
>     > What I have in mind now is:
>     >
>     > There's any advantage in use a class packing the interface signals and a
>     > method with the hardware description, or use another structure?
>
>     This depends, in my opinion you don't want to go
>     class/object crazy :)Â  Creating clean interfaces
>     will help the code a ton.  I tend to keep my main
>     modules not part of a class but for models I include
>     many myhdl generators in a class.
>
>
> I want to pack the interface to be as simple as possible. I'm using a
> class to pack all signals interface in my simulations I think I will
> have all modules with a class named interface+a generator for each mode
> of operation. Later I'll think in a way to add Wishbone and AXI
> interface to modules and keep some regularity among interfaces.
>

I agree, use a class to define the various interfaces.

Here is how I did the mem-map bus interfaces:

Wishbone
https://github.com/cfelton/minnesota/blob/master/mn/system/memmap/_wishbone.py#L35

Avalon:
https://github.com/cfelton/minnesota/blob/master/mn/system/memmap/_avalonmm.py#L35

Each interface has some modules associated with them, e.g. the
bus interconnect etc.  In the `mn` project, the main components
will be functions (e.g. SPI controller) and a memmap interface
is passed that then can be tied to a register-file.  The goal
is to have concise and flexible interfaces to each module.

Toy example in use:
https://github.com/cfelton/minnesota/blob/master/examples/designs/btn_led_mm/btn_led_mm.py

Most of this (above) is WIP hopefully it will help as
an example what can be done.

Here is another example of building test environment and creating
AXI interfaces (stream only):
http://www.alexforencich.com/wiki/en/verilog/start
https://github.com/alexforencich/verilog-axis/blob/master/tb/axis_ep.py

Regards,
Chris