myhdl-list

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

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

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.

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.

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.

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?

Cheers,
Ben

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

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

On 05/05/15 21:23, Ben Reynwar wrote:
> 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?
>

No, I do it quite a bit. The problem is more that the RTL needs to be 
implemented in MyHDL in order to be useful in that context.

See this:
https://github.com/hgomersall/Veriutils/blob/master/examples/dsp48e1/dsp48e1.py

For an example.

Cheers,

Henry

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

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

Thanks for that example.
If I understand correctly this is a MyHDL implementation of a Xilinx DSP
slice.  When you run a MyHDL cosimulation the tests all use the logic
defined in that module.  When you run those same tests with a Vivado
cosimulation, presumably the Xilinx primitive will be used instead.

I don't quite understand how you're using the vhdl_code property.  I
thought that the contents of this were placed into the module that was
being defined, whereas when I look at the VHDL code generated by your
Vivado cosimulation it looks as if the module has been replaced by that
code.

I also enjoyed looking through veriutils.  You're doing a lot of very
similar stuff to what I've been doing in pyvivado
<https://www.github.com/benreynwar/pyvivado>.

On Tue, May 5, 2015 at 2:14 PM, Henry Gomersall <he...@ca...> wrote:

> On 05/05/15 21:23, Ben Reynwar wrote:
> > 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?
> >
>
> No, I do it quite a bit. The problem is more that the RTL needs to be
> implemented in MyHDL in order to be useful in that context.
>
> See this:
>
> https://github.com/hgomersall/Veriutils/blob/master/examples/dsp48e1/dsp48e1.py
>
> For an example.
>
> Cheers,
>
> Henry
>
>
> ------------------------------------------------------------------------------
> 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 06/05/15 00:10, Ben Reynwar wrote:
> Thanks for that example.
> If I understand correctly this is a MyHDL implementation of a Xilinx 
> DSP slice.  When you run a MyHDL cosimulation the tests all use the 
> logic defined in that module.  When you run those same tests with a 
> Vivado cosimulation, presumably the Xilinx primitive will be used instead.
>

Yes exactly, but the specific module I linked to references a wrapper 
around the primitive, not the primitive itself:
https://github.com/hgomersall/Veriutils/blob/master/vivado/IP/xbip_dsp48_macro_0/dsp48_wrapper.vhd

(not that you should have trivially inferred that).

> I don't quite understand how you're using the vhdl_code property.  I 
> thought that the contents of this were placed into the module that was 
> being defined, whereas when I look at the VHDL code generated by your 
> Vivado cosimulation it looks as if the module has been replaced by 
> that code.
>
Are you referring to the wrapper? That is a separate piece of code that 
is referenced through the The VHDL code is inserted into the Vivado 
project (in work). The vhdl_code is put into the generated output.

> I also enjoyed looking through veriutils.  You're doing a lot of very 
> similar stuff to what I've been doing in pyvivado 
> <https://www.github.com/benreynwar/pyvivado>.

We should probably combine our efforts! What are your goals? So far, the 
intention has to be quite limited in scope, simply allow a back 
verification from Vivado, with the motivation driven by the need to 
allow encrypted IP blocks.

Cheers,

Henry

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

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

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'm a big fan of combining efforts!  What might be nice would be to take a
step back and think how we could divide stuff up into packages that play
nicely with one another.  For example pyvivado should probably just do (3)
and leave the other stuff to other packages.  We could then have other
packages then automate other toolchains but that provide a similar python
interface.  Perhaps this is a bit ambitious but it's fun thinking about!

On Wed, May 6, 2015 at 12:54 AM, Henry Gomersall <he...@ca...> wrote:

>  On 06/05/15 00:10, Ben Reynwar wrote:
>
> Thanks for that example.
> If I understand correctly this is a MyHDL implementation of a Xilinx DSP
> slice.  When you run a MyHDL cosimulation the tests all use the logic
> defined in that module.  When you run those same tests with a Vivado
> cosimulation, presumably the Xilinx primitive will be used instead.
>
>
> Yes exactly, but the specific module I linked to references a wrapper
> around the primitive, not the primitive itself:
>
> https://github.com/hgomersall/Veriutils/blob/master/vivado/IP/xbip_dsp48_macro_0/dsp48_wrapper.vhd
>
> (not that you should have trivially inferred that).
>
>  I don't quite understand how you're using the vhdl_code property.  I
> thought that the contents of this were placed into the module that was
> being defined, whereas when I look at the VHDL code generated by your
> Vivado cosimulation it looks as if the module has been replaced by that
> code.
>
>  Are you referring to the wrapper? That is a separate piece of code that
> is referenced through the The VHDL code is inserted into the Vivado project
> (in work). The vhdl_code is put into the generated output.
>
>  I also enjoyed looking through veriutils.  You're doing a lot of very
> similar stuff to what I've been doing in pyvivado
> <https://www.github.com/benreynwar/pyvivado>.
>
>
> We should probably combine our efforts! What are your goals? So far, the
> intention has to be quite limited in scope, simply allow a back
> verification from Vivado, with the motivation driven by the need to allow
> encrypted IP blocks.
>
> Cheers,
>
> Henry
>
>
> ------------------------------------------------------------------------------
> 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 06/05/15 18:54, 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.

Hi Ben (and all),

I've been thinking a bit more about this (in the context of every call 
to vivado taking an age to run) and I've just taken a bit of a look at 
your code. I'm sure Veriutils could benefit from the build system you 
offer. You've clearly put a lot of work into the interaction with Vivado 
and it would be stupid for me to replicate it all (Veriutil's 
interaction is very much simpler - a basic tcl script that is fleshed 
out with a template and then executed).

There's the mucky area around wrapping V* code, which you attack with 
your python function to generate an interface. My experience so far has 
been there are a few things that one wants to consider in wrapping 
existing code:
1) There are the port mappings (which may include different names).
2) Type conversions.
3) Ports held as a constant.
4) other things I've not thought of...

I dare say it would be possible to have a way of formalising those 
aspects, which could then be used to auto-generate wrappers around V* 
code. For some piece of VHDL (say), I currently have a VHDL wrapper as 
well as a vhdl_code snippet in the respective myhdl function.

I think this could be a really useful bit of code to break out as a 
separate project. I think it would make interaction between myhdl and 
vhdl much easier.

Cheers,

Henry

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

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

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!

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?



On Sat, Jun 13, 2015 at 2:58 AM, Henry Gomersall <he...@ca...> wrote:

> On 06/05/15 18:54, 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.
>
> Hi Ben (and all),
>
> I've been thinking a bit more about this (in the context of every call
> to vivado taking an age to run) and I've just taken a bit of a look at
> your code. I'm sure Veriutils could benefit from the build system you
> offer. You've clearly put a lot of work into the interaction with Vivado
> and it would be stupid for me to replicate it all (Veriutil's
> interaction is very much simpler - a basic tcl script that is fleshed
> out with a template and then executed).
>
> There's the mucky area around wrapping V* code, which you attack with
> your python function to generate an interface. My experience so far has
> been there are a few things that one wants to consider in wrapping
> existing code:
> 1) There are the port mappings (which may include different names).
> 2) Type conversions.
> 3) Ports held as a constant.
> 4) other things I've not thought of...
>
> I dare say it would be possible to have a way of formalising those
> aspects, which could then be used to auto-generate wrappers around V*
> code. For some piece of VHDL (say), I currently have a VHDL wrapper as
> well as a vhdl_code snippet in the respective myhdl function.
>
> I think this could be a really useful bit of code to break out as a
> separate project. I think it would make interaction between myhdl and
> vhdl much easier.
>
> Cheers,
>
> Henry
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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...>]

<snip>
>
> We should probably combine our efforts! What are your goals? So far, the
> intention has to be quite limited in scope, simply allow a back
> verification from Vivado, with the motivation driven by the need to
> allow encrypted IP blocks.

This is probably worth discussion, I have a similar
project as well that currently supports Quartus
and ISE, I will push the Vivado when I get a breathe:

https://github.com/cfelton/gizflo

There are 2-3 others that indicated they will be
contributing.

The question will be, is there a useful project
structure that meets all our needs?  Or will we
need to settle with separate projects?

Regards,
Chris

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

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

I'm also interested in have a python package to handle the fpga synthesis
flow, and will try to find some time to colaborate to it in the next weeks.
I think that there's a common structure in the fpga flow and also believe
that is possible to be flexible enough to meet several requirements.

In the last mile every project will need to be composed by a set of
Verilog/VHDL/ngc(?) files. We should go from this idea.

I like the simulation possibilities provided by MyHDL.
@Ben, are you adding Vivado simulator as a cosimulation option to myhdl?



2015-05-06 15:11 GMT-03:00 Christopher Felton <chr...@gm...>:

> <snip>
> >
> > We should probably combine our efforts! What are your goals? So far, the
> > intention has to be quite limited in scope, simply allow a back
> > verification from Vivado, with the motivation driven by the need to
> > allow encrypted IP blocks.
>
> This is probably worth discussion, I have a similar
> project as well that currently supports Quartus
> and ISE, I will push the Vivado when I get a breathe:
>
> https://github.com/cfelton/gizflo
>
> There are 2-3 others that indicated they will be
> contributing.
>
> The question will be, is there a useful project
> structure that meets all our needs?  Or will we
> need to settle with separate projects?
>
> 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

[Jeremy H. <jer...@gm...>]

I'd like to add my vote for something like gizflo, but I'm looking for a
tool that can go all the way from MyHDL/verilog to bitstream and
programming the device. Is that planned? I'd be happy to try to contribute
when I have time.

It would be great to do this across Xilinx, Altera and perhaps Lattice in
an abstracted way so that it doesn't matter what vendor you are targeting
(to some extent).

Thanks,
Jeremy

On Thu, 7 May 2015 at 11:12 Euripedes Rocha Filho <roc...@gm...>
wrote:

> I'm also interested in have a python package to handle the fpga synthesis
> flow, and will try to find some time to colaborate to it in the next weeks.
> I think that there's a common structure in the fpga flow and also believe
> that is possible to be flexible enough to meet several requirements.
>
> In the last mile every project will need to be composed by a set of
> Verilog/VHDL/ngc(?) files. We should go from this idea.
>
> I like the simulation possibilities provided by MyHDL.
> @Ben, are you adding Vivado simulator as a cosimulation option to myhdl?
>
>
>
> 2015-05-06 15:11 GMT-03:00 Christopher Felton <chr...@gm...>:
>
> <snip>
>> >
>> > We should probably combine our efforts! What are your goals? So far, the
>> > intention has to be quite limited in scope, simply allow a back
>> > verification from Vivado, with the motivation driven by the need to
>> > allow encrypted IP blocks.
>>
>> This is probably worth discussion, I have a similar
>> project as well that currently supports Quartus
>> and ISE, I will push the Vivado when I get a breathe:
>>
>> https://github.com/cfelton/gizflo
>>
>> There are 2-3 others that indicated they will be
>> contributing.
>>
>> The question will be, is there a useful project
>> structure that meets all our needs?  Or will we
>> need to settle with separate projects?
>>
>> 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
>>
>
> ------------------------------------------------------------------------------
> 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 8:21 PM, Jeremy Herbert wrote:
> I'd like to add my vote for something like gizflo, but I'm looking for a
> tool that can go all the way from MyHDL/verilog to bitstream and
> programming the device. Is that planned? I'd be happy to try to
> contribute when I have time.

The gizflo currently goes all the way to bitstream
and adding programming should be straightforward.

In my opinion, programming is board specific, this
would be tied to the board definitions but using
common components in the package to abstract:

     Xilinx programmer
     Quartus, quartus_pgm
     various USB programming methods

>
> It would be great to do this across Xilinx, Altera and perhaps Lattice
> in an abstracted way so that it doesn't matter what vendor you are
> targeting (to some extent).

The gizflo package already supports ISE, the
start of Vivado, and Quartus.  It shouldn't be
too difficult to add Lattice Diamond, actually
I think someone already started this when the
flow was part of myhdl_tools.

Regards,
Chris

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

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

hi Chris, 

> The gizflo currently goes all the way to
> bitstream and adding programming should be
> straightforward.

   . . .

> The gizflo package already supports ISE, the
> start of Vivado, and Quartus.  It shouldn't be
> too difficult to add Lattice Diamond, actually
> I think someone already started this when the
> flow was part of myhdl_tools.

I'd like to be able to distribute some fpga toys
with single-click rebuild.  I'm using Lattice
Diamond, and the Lattice (ex SiliconBlue) tools
to target small low power devices.  

Do you have any links to previous work?  

Either way, I'll copy the most used route in
gizflo and see if I can add paths for the tools
and boards I'm using.  Then I'll need to read
the git manual. 

Jan Coombs. 

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

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

On 5/9/15 9:12 AM, Jan Coombs wrote:
> hi Chris,
>
>> The gizflo currently goes all the way to
>> bitstream and adding programming should be
>> straightforward.
>
>     . . .
>
>> The gizflo package already supports ISE, the
>> start of Vivado, and Quartus.  It shouldn't be
>> too difficult to add Lattice Diamond, actually
>> I think someone already started this when the
>> flow was part of myhdl_tools.
>
> I'd like to be able to distribute some fpga toys
> with single-click rebuild.  I'm using Lattice
> Diamond, and the Lattice (ex SiliconBlue) tools
> to target small low power devices.
>
> Do you have any links to previous work?

No, not right now. I will have to do some digging
to see who was working on it and then ping them.

Regards,
Chris

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

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

I will work with gizflo in the next weeks for an altera based design,
simple one, to thest a new board.
As a result in this discussion we can say that we'll combine efforts around
gizflo?

2015-05-11 7:37 GMT-03:00 Christopher Felton <chr...@gm...>:

> On 5/9/15 9:12 AM, Jan Coombs wrote:
> > hi Chris,
> >
> >> The gizflo currently goes all the way to
> >> bitstream and adding programming should be
> >> straightforward.
> >
> >     . . .
> >
> >> The gizflo package already supports ISE, the
> >> start of Vivado, and Quartus.  It shouldn't be
> >> too difficult to add Lattice Diamond, actually
> >> I think someone already started this when the
> >> flow was part of myhdl_tools.
> >
> > I'd like to be able to distribute some fpga toys
> > with single-click rebuild.  I'm using Lattice
> > Diamond, and the Lattice (ex SiliconBlue) tools
> > to target small low power devices.
> >
> > Do you have any links to previous work?
>
> No, not right now. I will have to do some digging
> to see who was working on it and then ping them.
>
> 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 11/05/15 12:20, Euripedes Rocha Filho wrote:
> I will work with gizflo in the next weeks for an altera based design, 
> simple one, to thest a new board.
> As a result in this discussion we can say that we'll combine efforts 
> around gizflo?

An issue I have with Gizflo is the config options are written in Python 
and imported as such. Board import definitions shouldn't need to be 
vetted for security implications.

It would be pretty easy to fix I think at the moment. There are various 
easy batteries-included solutions for defining configurations with Python.

Cheers,

Henry

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

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

I agree with Henry about the configuration. A .cfg or Yaml file do a better
job.

Euripedes

2015-05-11 8:30 GMT-03:00 Henry Gomersall <he...@ca...>:

> On 11/05/15 12:20, Euripedes Rocha Filho wrote:
> > I will work with gizflo in the next weeks for an altera based design,
> > simple one, to thest a new board.
> > As a result in this discussion we can say that we'll combine efforts
> > around gizflo?
>
> An issue I have with Gizflo is the config options are written in Python
> and imported as such. Board import definitions shouldn't need to be
> vetted for security implications.
>
> It would be pretty easy to fix I think at the moment. There are various
> easy batteries-included solutions for defining configurations with Python.
>
> Cheers,
>
> Henry
>
>
> ------------------------------------------------------------------------------
> 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/11/2015 6:34 AM, Euripedes Rocha Filho wrote:
> I agree with Henry about the configuration. A .cfg or Yaml file do a better
> job.
>

Hey guys, I think collaborating is a good idea
and probably the best approach to create a tool
that meets the needs of many users.

It doesn't sound like gizflo is the best starting
point and I am not in a position to lead a project.

I have some short-term needs that I need to use
gizflo for, I will continue to make changes.  Hopefully,
whatever you guys come up with can be the defacto
tool in the future.  Keep us informed of your progress.

Regards,
Chris

> Euripedes
>
> 2015-05-11 8:30 GMT-03:00 Henry Gomersall <he...@ca...>:
>
>> On 11/05/15 12:20, Euripedes Rocha Filho wrote:
>>> I will work with gizflo in the next weeks for an altera based design,
>>> simple one, to thest a new board.
>>> As a result in this discussion we can say that we'll combine efforts
>>> around gizflo?
>>
>> An issue I have with Gizflo is the config options are written in Python
>> and imported as such. Board import definitions shouldn't need to be
>> vetted for security implications.
>>
>> It would be pretty easy to fix I think at the moment. There are various
>> easy batteries-included solutions for defining configurations with Python.
>>
>> Cheers,
>>
>> Henry
>>

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

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

On 11/05/15 21:43, Christopher Felton wrote:
> On 5/11/2015 6:34 AM, Euripedes Rocha Filho wrote:
>> >I agree with Henry about the configuration. A .cfg or Yaml file do a better
>> >job.
>> >
> Hey guys, I think collaborating is a good idea
> and probably the best approach to create a tool
> that meets the needs of many users.
>
> It doesn't sound like gizflo is the best starting
> point and I am not in a position to lead a project.
>
> I have some short-term needs that I need to use
> gizflo for, I will continue to make changes.  Hopefully,
> whatever you guys come up with can be the defacto
> tool in the future.  Keep us informed of your progress.

Hi Chris, I didn't mean to sound like a dick, I'm sorry. I sent the last 
email when I was a bit short of time. I actually think gizflo looks like 
a great starting point; my point was just that now is a good time to 
fiddle with the config layout.

Anyway, I too am lacking in time, so I should really shut up. My 
apologies for wading in, though clearly I'd also love to have a more 
myhdl oriented tool chain, and I dare say I'll start to commit patches 
when as and when I use something like gizflo.

Cheers,

Henry

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

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

I also had no intention to be rude. I think that gizflo is a great starting
point, acomodate all workflows is a complex task . As said I wish to able
to colaborate instead of create a new tool . Unless we agree on this path .
Em 11/05/2015 18:48, "Henry Gomersall" <he...@ca...> escreveu:

> On 11/05/15 21:43, Christopher Felton wrote:
> > On 5/11/2015 6:34 AM, Euripedes Rocha Filho wrote:
> >> >I agree with Henry about the configuration. A .cfg or Yaml file do a
> better
> >> >job.
> >> >
> > Hey guys, I think collaborating is a good idea
> > and probably the best approach to create a tool
> > that meets the needs of many users.
> >
> > It doesn't sound like gizflo is the best starting
> > point and I am not in a position to lead a project.
> >
> > I have some short-term needs that I need to use
> > gizflo for, I will continue to make changes.  Hopefully,
> > whatever you guys come up with can be the defacto
> > tool in the future.  Keep us informed of your progress.
>
> Hi Chris, I didn't mean to sound like a dick, I'm sorry. I sent the last
> email when I was a bit short of time. I actually think gizflo looks like
> a great starting point; my point was just that now is a good time to
> fiddle with the config layout.
>
> Anyway, I too am lacking in time, so I should really shut up. My
> apologies for wading in, though clearly I'd also love to have a more
> myhdl oriented tool chain, and I dare say I'll start to commit patches
> when as and when I use something like gizflo.
>
> Cheers,
>
> Henry
>
>
> ------------------------------------------------------------------------------
> 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/11/15 4:48 PM, Henry Gomersall wrote:
> On 11/05/15 21:43, Christopher Felton wrote:
>> On 5/11/2015 6:34 AM, Euripedes Rocha Filho wrote:
>>>> I agree with Henry about the configuration. A .cfg or Yaml file do a better
>>>> job.
>>>>
>> Hey guys, I think collaborating is a good idea
>> and probably the best approach to create a tool
>> that meets the needs of many users.
>>
>> It doesn't sound like gizflo is the best starting
>> point and I am not in a position to lead a project.
>>
>> I have some short-term needs that I need to use
>> gizflo for, I will continue to make changes.  Hopefully,
>> whatever you guys come up with can be the defacto
>> tool in the future.  Keep us informed of your progress.
>
> Hi Chris, I didn't mean to sound like a dick, I'm sorry. I sent the last
> email when I was a bit short of time. I actually think gizflo looks like
> a great starting point; my point was just that now is a good time to
> fiddle with the config layout.

No offense taken, all comments were reasonable.
It sounded like you guys had a good vision what
you wanted to accomplish (and on the same page)
I want to encourage it.  Building off of gizflo
works also - I don't want to limit anyone's
ambitions.

It is a good time to wade through the design
goals and architecture.  I think the cfg will
be too limiting and not the right fit.  I won't
explore the cfg but I encourage anyone to
demonstrate capturing the full board definitions
with cfg and we can discuss from there.

>
> Anyway, I too am lacking in time, so I should really shut up. My
> apologies for wading in, though clearly I'd also love to have a more
> myhdl oriented tool chain, and I dare say I'll start to commit patches
> when as and when I use something like gizflo.

No need for apologies, ideas can and should be
challenged and often we will disagree.  In the
cases where we disagree on technical issue we
need a method to move forward.  More often than
not we will eventually agree based on our
arguments :)

Regards,
Chris

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

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

On Mon, 11 May 2015 15:43:43 -0500
Christopher Felton <chr...@gm...> wrote:

> Hey guys, I think collaborating is a good idea
> and probably the best approach to create a tool
> that meets the needs of many users.
> 
> It doesn't sound like gizflo is the best
> starting point and I am not in a position to
> lead a project.
> 
> I have some short-term needs that I need to use
> gizflo for, I will continue to make changes.
> Hopefully, whatever you guys come up with can
> be the defacto tool in the future.  Keep us
> informed of your progress.

I also have short-term needs, and would rather
add to your tree than design my own. 

It may be a good time to review the detail once
a reasonable number of differing flows are tried
and tested. 

Jan Coombs. 

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

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

>
> I like the simulation possibilities provided by MyHDL.
> @Ben, are you adding Vivado simulator as a cosimulation option to myhdl?

I am fairly sure the isim (ISE/Vivado simulator)
does not support a foreign language interface,
no PLI/VPI.  You can't do Cosimulation as it is
done with all other simulators.

Henry (@heng) I believe put together a process to
create stimulus files, run the simulation, capture
the outputs, and then read them into the MyHDL and
validate (I think it went like that).  I believe
that is the best you can do with isim.

The isim Cosimulation is best kept as a standalone
package.  Although I haven't tried it, from Henry's
description it sounds like he has made good progress.
The isim Cosimulation as a standalone package might
make sense (i.e using Henry's approach).

Regards,
Chris

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

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

On 07/05/15 03:19, Christopher Felton wrote:
>> >I like the simulation possibilities provided by MyHDL.
>> >@Ben, are you adding Vivado simulator as a cosimulation option to myhdl?
> I am fairly sure the isim (ISE/Vivado simulator)
> does not support a foreign language interface,
> no PLI/VPI.  You can't do Cosimulation as it is
> done with all other simulators.
>
> Henry (@heng) I believe put together a process to
> create stimulus files, run the simulation, capture
> the outputs, and then read them into the MyHDL and
> validate (I think it went like that).  I believe
> that is the best you can do with isim.
>
> The isim Cosimulation is best kept as a standalone
> package.  Although I haven't tried it, from Henry's
> description it sounds like he has made good progress.
> The isim Cosimulation as a standalone package might
> make sense (i.e using Henry's approach).

Yes, I'm using it on a daily basis now for quite serious code - it's now 
pretty stable with a good test suite. In the confines in which I'm using 
it, i'm very pleased with it.

The build chain at the moment is limited to Vivado, but it's not really 
specific to Vivado - the calling interface is written in templated tcl, 
so a similar one (or indeed any other kind of driver script) could be 
written for other simulators.

It's works in a pretty seamless way - one writes a validated reference 
RTL model and the convertible code. Those can (1) be compared through 
one function to test myhdl RTL correctness (myhdl_cosimulation), which 
can then (2) be switched to another function (vivado_cosimulation) which 
calls Vivado to test the convertible code. The outputs from both the 
vivado run and the reference model are returned.

An example of (1) is given:
e.g. 
https://github.com/hgomersall/Veriutils/blob/master/examples/dsp48e1/test_dsp48e1.py#L188

A test class is then derived from that one that changes the cosimulation 
to use Vivado (i.e. 2) when it's available:
https://github.com/hgomersall/Veriutils/blob/master/examples/dsp48e1/test_dsp48e1.py#L564

Cheers,

Henry

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

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

On 07/05/15 08:39, Henry Gomersall wrote:
> On 07/05/15 03:19, Christopher Felton wrote:
>>>> >> >I like the simulation possibilities provided by MyHDL.
>>>> >> >@Ben, are you adding Vivado simulator as a cosimulation option to myhdl?
>> >I am fairly sure the isim (ISE/Vivado simulator)
>> >does not support a foreign language interface,
>> >no PLI/VPI.  You can't do Cosimulation as it is
>> >done with all other simulators.
>> >
>> >Henry (@heng) I believe put together a process to
>> >create stimulus files, run the simulation, capture
>> >the outputs, and then read them into the MyHDL and
>> >validate (I think it went like that).  I believe
>> >that is the best you can do with isim.
>> >
>> >The isim Cosimulation is best kept as a standalone
>> >package.  Although I haven't tried it, from Henry's
>> >description it sounds like he has made good progress.
>> >The isim Cosimulation as a standalone package might
>> >make sense (i.e using Henry's approach).
> Yes, I'm using it on a daily basis now for quite serious code - it's now
> pretty stable with a good test suite. In the confines in which I'm using
> it, i'm very pleased with it.
>
> The build chain at the moment is limited to Vivado, but it's not really
> specific to Vivado - the calling interface is written in templated tcl,
> so a similar one (or indeed any other kind of driver script) could be
> written for other simulators.

It also comes with set of utilities for making the stimulus easier (such 
as a random source) and various utilities to verify things like signal 
types (i.e. interface verification).

Cheers,

Henry

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

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

> @Ben, are you adding Vivado simulator as a cosimulation option to myhdl?

We can't do this properly.  But potentially we could have a hack where both
side (Vivado and python) monitor files to see if new lines have been added.

On Wed, May 6, 2015 at 6:11 PM, Euripedes Rocha Filho <
roc...@gm...> wrote:

> I'm also interested in have a python package to handle the fpga synthesis
> flow, and will try to find some time to colaborate to it in the next weeks.
> I think that there's a common structure in the fpga flow and also believe
> that is possible to be flexible enough to meet several requirements.
>
> In the last mile every project will need to be composed by a set of
> Verilog/VHDL/ngc(?) files. We should go from this idea.
>
> I like the simulation possibilities provided by MyHDL.
> @Ben, are you adding Vivado simulator as a cosimulation option to myhdl?
>
>
>
> 2015-05-06 15:11 GMT-03:00 Christopher Felton <chr...@gm...>:
>
> <snip>
>> >
>> > We should probably combine our efforts! What are your goals? So far, the
>> > intention has to be quite limited in scope, simply allow a back
>> > verification from Vivado, with the motivation driven by the need to
>> > allow encrypted IP blocks.
>>
>> This is probably worth discussion, I have a similar
>> project as well that currently supports Quartus
>> and ISE, I will push the Vivado when I get a breathe:
>>
>> https://github.com/cfelton/gizflo
>>
>> There are 2-3 others that indicated they will be
>> contributing.
>>
>> The question will be, is there a useful project
>> structure that meets all our needs?  Or will we
>> need to settle with separate projects?
>>
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>