myhdl-list

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Henry G. <he...@ca...>]

On 06/05/15 19:11, Christopher Felton wrote:
> The question will be, is there a useful project
> structure that meets all our needs?  Or will we
> need to settle with separate projects?

Good question. In terms of the build workflow, I'm sure there is little 
point reproducing effort. There are loads of way of loading metadata 
which we're all likely to solve, but I doubt there is one that is 
objectively the best.

I suspect that other projects that sit on top of such systems are best 
handled as their own project - I'm a big fan of small tools that work 
well and work well together - I think that's the benefit of talking 
about this.

Cheers,

Henry

Re: [myhdl-list] Mixing MyHDL-generated source with other code

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

On 5/7/15 2:44 AM, Henry Gomersall wrote:
> On 06/05/15 19:11, Christopher Felton wrote:
>> The question will be, is there a useful project
>> structure that meets all our needs?  Or will we
>> need to settle with separate projects?
>
> Good question. In terms of the build workflow, I'm sure there is little
> point reproducing effort. There are loads of way of loading metadata
> which we're all likely to solve, but I doubt there is one that is
> objectively the best.
>
> I suspect that other projects that sit on top of such systems are best
> handled as their own project - I'm a big fan of small tools that work
> well and work well together - I think that's the benefit of talking
> about this.

Yes, but also the ability to find the tools.

Regards,
Chris

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Euripedes R. F. <roc...@gm...>]

I agree with the idea of small tools with focus on each step and integrated
to build the development flow. A good documentation is the way to allow
them to be found. Also have different tools doesn't mean different places.
They can live in the same repository as submodules.

Before knowing the existence of myhdl_tools/gizflo I was thinking in use a
python based build system and base my own tool on top of it. How are you
guys doing the "project" configuration? I mean, how the source files are
found, how the options are passed to the synthesis tools... I was thinking
in use a set of yaml files for tools, source list and board configuration.


2015-05-07 8:20 GMT-03:00 HenryGomersall <he...@ca...>:

> On 07/05/15 12:11, Christopher Felton wrote:
> > On 5/7/15 2:44 AM, Henry Gomersall wrote:
> >> >On 06/05/15 19:11, Christopher Felton wrote:
> >>> >>The question will be, is there a useful project
> >>> >>structure that meets all our needs?  Or will we
> >>> >>need to settle with separate projects?
> >> >
> >> >Good question. In terms of the build workflow, I'm sure there is little
> >> >point reproducing effort. There are loads of way of loading metadata
> >> >which we're all likely to solve, but I doubt there is one that is
> >> >objectively the best.
> >> >
> >> >I suspect that other projects that sit on top of such systems are best
> >> >handled as their own project - I'm a big fan of small tools that work
> >> >well and work well together - I think that's the benefit of talking
> >> >about this.
> > Yes, but also the ability to find the tools.
>
> Right, so we need to collate them somewhere :)
>
> hen
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Henry G. <he...@ca...>]

On 07/05/15 12:55, Euripedes Rocha Filho wrote:
>
> Before knowing the existence of myhdl_tools/gizflo I was thinking in 
> use a python based build system and base my own tool on top of it. How 
> are you guys doing the "project" configuration? I mean, how the source 
> files are found, how the options are passed to the synthesis tools... 
> I was thinking in use a set of yaml files for tools, source list and 
> board configuration.

Yes, something like that...

I actually use a python config file:
https://github.com/hgomersall/Veriutils/blob/master/veriutils.cfg

which (among some other stuff) is used to populate a template:
https://github.com/hgomersall/Veriutils/blob/master/vivado/templates/simulate.tcl.tmpl

It's pretty simple, and it may be that for more complex stuff more is 
needed, but it works for me for the time being.

Cheers,

Henry

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Jan <jen...@mu...>]

On Tue, 5 May 2015 13:23:25 -0700
Ben Reynwar <be...@re...> wrote:

> Hi again,
> 
> One of the things I'm trying to work out as I
> get acquainted with MyHDL is how best to mix
> MyHDL-generated code with existing code.  This
> can be reduced to two basic problems:

[...]

> For (2) I can get close using the
> `vhdl_instance` property but that seems like
> it's more for generating separate VHDL files
> from MyHDL rather than for interfacing with
> non-MyHDL modules.  The things that make this
> difficult to use are that it assumes an
> architecture named 'MyHDL' and that it does not
> allow for generic parameters.  [...]

The following appears to work for RAM
initialisation in verilog, as it is accepted by
the synth tools, the VHDL is obviously broken,
but the technique should work:

def SB_RAM1024x4_cfg(RDATA,RADDR,RCLK,RCLKE,RE,\
  WADDR,WCLK,WCLKE,WDATA,WE, ConfigBits): 
''' sim & synth version of iCE40 block RAM in \
  1024x4 format ''' GSW = 4  #len(WDATA) 
  
  mem=[]
    [... code to build list for simulation]

  @always_comb 
  def ReadLogic(): [...]
  
  @always(WCLK.posedge)
  def WriteLogic(): [...]
  
  # config strings need simple variables #
  CB0x0 = ConfigBits[0x0]
  CB0x1 = ConfigBits[0x1]
    [...]
  CB0xF = ConfigBits[0xF]

__verilog__ = \
"""
SB_RAM1024x4 ram1024x4_01 (
  .RDATA(%(RDATA)s), 
  .RADDR(%(RADDR)s), 
    [...]
  .WE(%(WE)s) 
);   
  
defparam ram1024x4_01.INIT_0 =\
  256'h%(CB0x0)064x; 
defparam ram1024x4_01.INIT_1 =\
  256'h%(CB0x1)064x; 
      [...]
defparam ram1024x4_01.INIT_F =\ 
  256'h%(CB0xF)064x; """

__VHDL__ = \
"""
RAM1024X4: SB_RAM1024x4
generic map(  
  INIT_0 => X"%(CB0x0)064x",
  INIT_1 => X"%(CB0x1)064x",
    [...]
  INIT_F => X"%(CB0xF)064x"   ) 
  
port map (
  RDATA => (%(RDATA)s),
  (%(RADDR)s) => RADDR,
    [...]
  WE => (%(WE)s)  );
"""
    
(I'm about six weeks away from using this in a
design)

Jan Coombs. 
-- 

Re: [myhdl-list] Mixing MyHDL-generated source with other code

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

On 5/5/2015 3:23 PM, Ben Reynwar wrote:
> Hi again,
>
> One of the things I'm trying to work out as I get acquainted with MyHDL is
> how best to mix MyHDL-generated code with existing code.  This can be
> reduced to two basic problems:
>
> 1) Be able to generate VHDL/verilog with a predictable interface so it can
> used by a non-MyHDL module.
> 2) Be able to generate VHDL/verilog containing an instantiation of a module
> that is not specified by MyHDL.

Yes, if I understand your 1 and 2, I would refer
to it as:

   1. Verilog/VHDL top-levels, including MyHDL
      generated IP.

   2. MyHDL top-level, including Verilog/VHDL
      modules in the converted MyHDL design.

The first, is simply creating blocks in MyHDL and
converting them individually and including them
in an existing flow.  This method seems preferred
for those that use a lot of vendor IP and for
early adoption.  You can still use MyHDL for all
verification.

The second, if you are verifying the MyHDL before
conversion (highly recommended) you have to create
functional models to represent the behavior, then
you can use verilog_code and vhdl_code to instantiate
the V* module/component.  The process should be
seamless :)

>
> For (1) it seems to mostly work out of the box.  Sometimes I find that the
> `_name` property on the signal has not been forced to match the function
> argument name on the top module.  But I'm not sure if that's a bug I've
> introduced myself in my local copy.

You might be venturing into areas that haven't been
explored a whole lot.

If you have a module with ports:

    def my_module(a, b, c d):

and you convert the module using Signals, the names of
the ports will be: a, b, c, d.

If you are using interfaces (and multiple levels of
interfaces) that might not hold.  I think this is
what you might be eluding to?  This might be worth
discussion but is somewhat independent of this thread.

>
> For (2) I can get close using the `vhdl_instance` property but that seems
> like it's more for generating separate VHDL files from MyHDL rather than
> for interfacing with non-MyHDL modules.  The things that make this
> difficult to use are that it assumes an architecture named 'MyHDL' and that
> it does not allow for generic parameters.  The simplest way to get round
> this would be to default to not specifying the architecture and interpret a
> parameter called 'architecture' to be specifying that.  In a similar manner
> a parameter called 'parameters' could be used as the generic parameters.
> This would be a small, local change but would add a lot of flexibility.

The vhdl_code and vhdl_instance are what you would want
to use to have your code instantiate VHDL components.
Note, vhdl_instance is beta and not documented, it is
incomplete at this time (e.g. can't define the architecture,
it defaults to "MyHDL").

I believe others posted some examples, here is another:

https://gist.github.com/cfelton/0b12dd0725eb2decbd2a
https://gist.github.com/cfelton/0792c5823d418afee604

And here are the docs on vhdl_code and verilog_code:
http://docs.myhdl.org/en/latest/manual/conversion.html#user-defined-code

>
> Based on the fact that it's not trival to do this, I'm assuming that most
> people aren't mixing MyHDL with hand-coded Verilog and VHDL much.  Is there
> a reason for this?

Many (most when they start) are mixing.

Regards,
Chris

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Ben R. <be...@re...>]

Yes, my issues with the top module interface occur only when using
interfaces.  I've got a fix but I'm waiting to test things better before I
submit a pull request.

Thanks for the links!

On Wed, May 6, 2015 at 8:43 AM, Christopher Felton <chr...@gm...>
wrote:

> On 5/5/2015 3:23 PM, Ben Reynwar wrote:
> > Hi again,
> >
> > One of the things I'm trying to work out as I get acquainted with MyHDL
> is
> > how best to mix MyHDL-generated code with existing code.  This can be
> > reduced to two basic problems:
> >
> > 1) Be able to generate VHDL/verilog with a predictable interface so it
> can
> > used by a non-MyHDL module.
> > 2) Be able to generate VHDL/verilog containing an instantiation of a
> module
> > that is not specified by MyHDL.
>
> Yes, if I understand your 1 and 2, I would refer
> to it as:
>
>    1. Verilog/VHDL top-levels, including MyHDL
>       generated IP.
>
>    2. MyHDL top-level, including Verilog/VHDL
>       modules in the converted MyHDL design.
>
> The first, is simply creating blocks in MyHDL and
> converting them individually and including them
> in an existing flow.  This method seems preferred
> for those that use a lot of vendor IP and for
> early adoption.  You can still use MyHDL for all
> verification.
>
> The second, if you are verifying the MyHDL before
> conversion (highly recommended) you have to create
> functional models to represent the behavior, then
> you can use verilog_code and vhdl_code to instantiate
> the V* module/component.  The process should be
> seamless :)
>
> >
> > For (1) it seems to mostly work out of the box.  Sometimes I find that
> the
> > `_name` property on the signal has not been forced to match the function
> > argument name on the top module.  But I'm not sure if that's a bug I've
> > introduced myself in my local copy.
>
> You might be venturing into areas that haven't been
> explored a whole lot.
>
> If you have a module with ports:
>
>     def my_module(a, b, c d):
>
> and you convert the module using Signals, the names of
> the ports will be: a, b, c, d.
>
> If you are using interfaces (and multiple levels of
> interfaces) that might not hold.  I think this is
> what you might be eluding to?  This might be worth
> discussion but is somewhat independent of this thread.
>
> >
> > For (2) I can get close using the `vhdl_instance` property but that seems
> > like it's more for generating separate VHDL files from MyHDL rather than
> > for interfacing with non-MyHDL modules.  The things that make this
> > difficult to use are that it assumes an architecture named 'MyHDL' and
> that
> > it does not allow for generic parameters.  The simplest way to get round
> > this would be to default to not specifying the architecture and
> interpret a
> > parameter called 'architecture' to be specifying that.  In a similar
> manner
> > a parameter called 'parameters' could be used as the generic parameters.
> > This would be a small, local change but would add a lot of flexibility.
>
> The vhdl_code and vhdl_instance are what you would want
> to use to have your code instantiate VHDL components.
> Note, vhdl_instance is beta and not documented, it is
> incomplete at this time (e.g. can't define the architecture,
> it defaults to "MyHDL").
>
> I believe others posted some examples, here is another:
>
> https://gist.github.com/cfelton/0b12dd0725eb2decbd2a
> https://gist.github.com/cfelton/0792c5823d418afee604
>
> And here are the docs on vhdl_code and verilog_code:
> http://docs.myhdl.org/en/latest/manual/conversion.html#user-defined-code
>
> >
> > Based on the fact that it's not trival to do this, I'm assuming that most
> > people aren't mixing MyHDL with hand-coded Verilog and VHDL much.  Is
> there
> > a reason for this?
>
> Many (most when they start) are mixing.
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Mixing MyHDL-generated source with other code

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

On 5/6/15 12:54 PM, Ben Reynwar wrote:
> At the moment pyvivado is doing four fairly independent things for me:
>
> 1) I use it as a build system to keep track of which modules depend on
> which other modules and IP blocks and to specify how files that need to
> be generated are generated.
> 2) I use it to run python unittests (very similar to what you do with
> veriutils)
> 3) I use it to automate Vivado (simulation, synthesis, implementation
> and deployment)
> 4) I use it to communicate with the FPGA from python.
>
> Things that I don't like about it are:
> Â  - Doesn't support MyHDL yet.
> Â  - Tests aren't interactive (i.e. I specify all the inputs and then
> read all the outputs)
> Â  - Too many different things rolled into one and more interdependent
> than they could be.  It should probably be 4 python packages for those
> 4 purposes.

I think there are at least two clear packages
here:

     1. the FPGA flow automation
     2. PLI/VPI less (no FLI) simulator (isim)

It seems your and Henry's work can be combined to
create the NoFLICosimulation and pyvivado and gizflo
can be leveraged for the tool-flow automation?

Regards,
Chris

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Ben R. <be...@re...>]

> I think there are at least two clear packages
> here:
>
>     1. the FPGA flow automation
>     2. PLI/VPI less (no FLI) simulator (isim)

Yes, although there is some overlap in the use of the toolchain.  For
example if I want to do a timing simulation, then I would need to use the
appropriate toolchain to do the synthesis and implementation.  I would be
inclined to put the functionality to run a Vivado simulation in the Vivado
toolchain.

Under this model we would have
1. A package for toolchains (or perhaps a package for each toolchain)
2. The FPGA flow automation (making use of the appropriate toolchain)
3. PLI/VPI less simulator (making use of the appropriate toolchain)

The other big area is taking a top level description of the module and
turning that into the files required by the toolchain.
For MyHDL this is straightforward since our top level description is the
top level function along with it's arguments.
For a project that consists of VHDL and Verilog it is straightforward but
tedious to determine what files are required.  If you're using code that
adheres to the hdlmake <http://www.ohwr.org/projects/hdl-make> or fusesoc
<https://github.com/olofk/fusesoc> then things are better since you can
work out dependencies automatically.
If you have a mix of VHDL, Verilog and MyHDL, and perhaps a script to
generate some VHDL then there's no good solution that I've found, which is
why I ended up rolling my own in pyvivado.  I think what we really need is
something like a parameterized package manager than plays nicely with
hdlmake and fusesoc but is flexible enough to allow generated code.


On Thu, May 7, 2015 at 4:12 AM, Christopher Felton <chr...@gm...>
wrote:

> On 5/6/15 12:54 PM, Ben Reynwar wrote:
> > At the moment pyvivado is doing four fairly independent things for me:
> >
> > 1) I use it as a build system to keep track of which modules depend on
> > which other modules and IP blocks and to specify how files that need to
> > be generated are generated.
> > 2) I use it to run python unittests (very similar to what you do with
> > veriutils)
> > 3) I use it to automate Vivado (simulation, synthesis, implementation
> > and deployment)
> > 4) I use it to communicate with the FPGA from python.
> >
> > Things that I don't like about it are:
> > Â  - Doesn't support MyHDL yet.
> > Â  - Tests aren't interactive (i.e. I specify all the inputs and then
> > read all the outputs)
> > Â  - Too many different things rolled into one and more interdependent
> > than they could be.  It should probably be 4 python packages for those
> > 4 purposes.
>
> I think there are at least two clear packages
> here:
>
>      1. the FPGA flow automation
>      2. PLI/VPI less (no FLI) simulator (isim)
>
> It seems your and Henry's work can be combined to
> create the NoFLICosimulation and pyvivado and gizflo
> can be leveraged for the tool-flow automation?
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Henry G. <he...@ca...>]

On 07/05/15 12:11, Christopher Felton wrote:
> On 5/7/15 2:44 AM, Henry Gomersall wrote:
>> >On 06/05/15 19:11, Christopher Felton wrote:
>>> >>The question will be, is there a useful project
>>> >>structure that meets all our needs?  Or will we
>>> >>need to settle with separate projects?
>> >
>> >Good question. In terms of the build workflow, I'm sure there is little
>> >point reproducing effort. There are loads of way of loading metadata
>> >which we're all likely to solve, but I doubt there is one that is
>> >objectively the best.
>> >
>> >I suspect that other projects that sit on top of such systems are best
>> >handled as their own project - I'm a big fan of small tools that work
>> >well and work well together - I think that's the benefit of talking
>> >about this.
> Yes, but also the ability to find the tools.

Right, so we need to collate them somewhere :)

hen

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Henry G. <he...@ca...>]

On 14/06/15 06:32, Ben Reynwar wrote:
> You should be able to take advantage of pyvivado Vivado stuff just by 
> using the `pyvivado.project` module.  You could just use that along 
> with all the V* files that you generated using Veriutils.  The main 
> speedup you get is that the project only gets regenerated if the files 
> have changed, which doesn't make much difference during development 
> but is a big plus when you're running unit tests later.  Still 
> annoyingly slow though!
>

Yeah, it is crap. There is a huge overhead in doing anything in Vivado - 
all my tests are creating new instances which takes ~7 seconds or so

> If I understand your comments on wrapper generation, you're suggesting 
> something similar to what I'm doing with the interface functions but 
> more formalized.  I could then use that same definition to generate 
> VHDL wrappers or a MyHDL wrapper. Is that correct?

Yeah exactly. Some sort of simple interface language/definition from 
which interface wrappers can be generated. Certainly, it's a common 
problem in myhdl that is in need of a neat solution.

That said, what does the new use_std_logic flag do? Is that per-module?

Cheers,

Henry

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Ben R. <be...@re...>]

OK.  So I've had a look at the Interface class I have in pyvivado to see
how it could be cleaned up.

Constructor is defined at
https://github.com/benreynwar/pyvivado/blob/91449e67330a053d5089aa4ba10c625cb43efb87/interface.py#L21

I think a bunch of crap could be removed to simplify it.  The important
parts are:

Interface Object
---------------------
wires - A list of wire objects.
name - The name of the module
generic_parameters - Parameters that define module (e.g. generic in VHDL)

Wire Object
----------------
name - Name of the wire
direction - Input or Output
signal_type - A signal type object

SignalType Object
------------------------
Responsible for conversion to and from bit arrays.
Responsible for conversion to and from python objects.
Responsible for generating appropriate signal definitions in VHDL or
Verilog and specifying any package dependencies for the type definition.

The interface and wire objects could just be represented as python
dictionaries since they're so simple.
The signal type object would need to be more complex.  Possibly an object
that would work here already exists in MyHDL.

Is that the kind of direction you were thinking?

I'm not sure what you're referring to with the 'use_std_logic' flag in the
previous email.

On Sun, Jun 14, 2015 at 2:01 AM, Henry Gomersall <he...@ca...> wrote:

> On 14/06/15 06:32, Ben Reynwar wrote:
> > You should be able to take advantage of pyvivado Vivado stuff just by
> > using the `pyvivado.project` module.  You could just use that along
> > with all the V* files that you generated using Veriutils.  The main
> > speedup you get is that the project only gets regenerated if the files
> > have changed, which doesn't make much difference during development
> > but is a big plus when you're running unit tests later.  Still
> > annoyingly slow though!
> >
>
> Yeah, it is crap. There is a huge overhead in doing anything in Vivado -
> all my tests are creating new instances which takes ~7 seconds or so
>
> > If I understand your comments on wrapper generation, you're suggesting
> > something similar to what I'm doing with the interface functions but
> > more formalized.  I could then use that same definition to generate
> > VHDL wrappers or a MyHDL wrapper. Is that correct?
>
> Yeah exactly. Some sort of simple interface language/definition from
> which interface wrappers can be generated. Certainly, it's a common
> problem in myhdl that is in need of a neat solution.
>
> That said, what does the new use_std_logic flag do? Is that per-module?
>
> Cheers,
>
> Henry
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>