myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Global state and multiple instances

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

On 07/05/15 15:33, Henry Gomersall wrote:
> Oh, btw, it_should_  be thread safe, due to using thread local storage,
> but I haven't verified this.

It wasn't, but it is now. Changes committed to the same branch.

See this example:

https://gist.github.com/hgomersall/59e3d2b151e7931b1965

Cheers,

Henry

Re: [myhdl-list] Global state and multiple instances

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

On 07/05/15 15:41, Juan Pablo Caram wrote:
> Henry, do you have a minimal working example?

yup, good point!

https://gist.github.com/hgomersall/350a007980972a75859c

That shows two simulation instances working independently.

Cheers,

Henry

Re: [myhdl-list] Global state and multiple instances

[Juan P. C. <jp...@gm...>]

Henry, do you have a minimal working example?
Thanks,
JP

On Thu, May 7, 2015 at 10:33 AM, Henry Gomersall <he...@ca...> wrote:

> On 07/05/15 15:10, Henry Gomersall wrote:
> > The other problem is the state on a Signal object is not being handled
> > properly. I tried to implement the solution for this (currently
> > commented out in _simulator.py) in which on each context switch, the
> > signals are stashed (using _Signal._stash_state) to the context that is
> > being departed, and then the signal state is reloaded when it is
> > reentered (susing _Signal._recall_state). The tests begin to work and
> > then one gets into an infinite loop because some waiter or other is
> > missing. I'm not sure quite what I've missed. This is hard to bug
> > isolate because the tests all run in isolation or indeed, in their
> > respective test classes.
>
> I was wrong, all the tests actually seem to run with no error. The
> problem is that the overhead when the signal list becomes large is huge
> and really affects the simulation time.
>
> This can be dealt with with a bit of thought I'm sure. Most of the time,
> nothing is changed, so the Signal does not need to be stashed.
>
> I've pushed the changes with the full code.
>
> Oh, btw, it _should_ be thread safe, due to using thread local storage,
> but I haven't verified this.
>
> 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] Global state and multiple instances

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

On 07/05/15 15:10, Henry Gomersall wrote:
> The other problem is the state on a Signal object is not being handled
> properly. I tried to implement the solution for this (currently
> commented out in _simulator.py) in which on each context switch, the
> signals are stashed (using _Signal._stash_state) to the context that is
> being departed, and then the signal state is reloaded when it is
> reentered (susing _Signal._recall_state). The tests begin to work and
> then one gets into an infinite loop because some waiter or other is
> missing. I'm not sure quite what I've missed. This is hard to bug
> isolate because the tests all run in isolation or indeed, in their
> respective test classes.

I was wrong, all the tests actually seem to run with no error. The 
problem is that the overhead when the signal list becomes large is huge 
and really affects the simulation time.

This can be dealt with with a bit of thought I'm sure. Most of the time, 
nothing is changed, so the Signal does not need to be stashed.

I've pushed the changes with the full code.

Oh, btw, it _should_ be thread safe, due to using thread local storage, 
but I haven't verified this.

Cheers,

Henry

Re: [myhdl-list] Global state and multiple instances

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

On 06/05/15 09:18, Henry Gomersall wrote:
> In light of a PR I submitted last week, I have an idea to try... I'll
> try to get some code later on...

I've implemented a partial solution...

https://github.com/hgomersall/myhdl/tree/globals_free_sim

It's fairly clean and shouldn't break _too_ much. Most of the changes 
are in _simulator.py.

It works by creating a context which can be used to store all the 
current simulation variables.

So whenever access to the simulation variables is required, the context 
manager is used:

with _simulator.simulation_context(some_hashable):
     do the simulation stuff here

There is a default context which it falls back to when not inside the 
context manager.

All the core tests pass except two, in the tracing stuff. The issue here 
is that the simulation now uses its own context which the tracing code 
doesn't know about, so the variables are not shared. This is just an API 
issue so I haven't tried to fix it (i.e. what are peoples opinion, 
assuming the general approach is good).

The other problem is the state on a Signal object is not being handled 
properly. I tried to implement the solution for this (currently 
commented out in _simulator.py) in which on each context switch, the 
signals are stashed (using _Signal._stash_state) to the context that is 
being departed, and then the signal state is reloaded when it is 
reentered (susing _Signal._recall_state). The tests begin to work and 
then one gets into an infinite loop because some waiter or other is 
missing. I'm not sure quite what I've missed. This is hard to bug 
isolate because the tests all run in isolation or indeed, in their 
respective test classes.

Also, the signal code really hits performance, so it needs a bit of a 
reassessment from that perspective too.

I'd appreciate feedback on this approach.

Cheers,

Henry

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

[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: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

[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

[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

[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

[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

[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

[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

[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

[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

[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] Reusability and encapsulation

[Juan P. C. <jp...@gm...>]

Got it. Definitely not a blocker! I can work around it.
Is there a github ticket for it?
Thanks,
JP

On Wed, May 6, 2015 at 2:06 PM, Christopher Felton <chr...@gm...>
wrote:

> On 5/6/2015 12:58 PM, Juan Pablo Caram wrote:
> > Oh, sorry, I didn't actually run your notebook. I just didn't (and still
> > don't) see the difference between my code and yours.
> >
> > I'm not explicitly using _SuspendSimulation or StopSimulation. I don't
> know
> > why the simulation "stops" with _SuspendSimulation instead of
> > StopSimulation. It's stopping at the end of the specified time in
> > sim.run(stoptime).
>
> Understand, _SuspendSimulation and StopSimulation
> are the internal exceptions (state) for the simulator.
>
> When you run the simulator for a specific period
> of time:
>
>      sim = Simulation(tb())
>      sim.run(100)
>
> The simulator suspends so that it can resume:
>
>      sim.run(100)
>
> In my example I did not define a number of simulation
> steps to run (the argument to run).  When no duration
> is specified the simulation runs until there are no
> more events or StopSimulation is raised.
>
> Restarting the simulator in the second condition works
> fine but restarting in the first has an issue.
>
> >
> > Okay, now I see it. At the completion of simulation time
> _SuspendSimulation
> > is raised to exit (this is the bug?). You explicitly use StopSimulation.
>
> The raising of _SuspendSimulation is not the bug, the
> bug is when a new simulation instance is created after
> a suspend.
>
> 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...>]

<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] Reusability and encapsulation

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

On 5/6/2015 12:58 PM, Juan Pablo Caram wrote:
> Oh, sorry, I didn't actually run your notebook. I just didn't (and still
> don't) see the difference between my code and yours.
>
> I'm not explicitly using _SuspendSimulation or StopSimulation. I don't know
> why the simulation "stops" with _SuspendSimulation instead of
> StopSimulation. It's stopping at the end of the specified time in
> sim.run(stoptime).

Understand, _SuspendSimulation and StopSimulation
are the internal exceptions (state) for the simulator.

When you run the simulator for a specific period
of time:

     sim = Simulation(tb())
     sim.run(100)

The simulator suspends so that it can resume:

     sim.run(100)

In my example I did not define a number of simulation
steps to run (the argument to run).  When no duration
is specified the simulation runs until there are no
more events or StopSimulation is raised.

Restarting the simulator in the second condition works
fine but restarting in the first has an issue.

>
> Okay, now I see it. At the completion of simulation time _SuspendSimulation
> is raised to exit (this is the bug?). You explicitly use StopSimulation.

The raising of _SuspendSimulation is not the bug, the
bug is when a new simulation instance is created after
a suspend.

Regards,
Chris

Re: [myhdl-list] Interfaces in Interfaces

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

I have what I think is a working branch here:

https://github.com/benreynwar/myhdl/tree/fix_nested_interfaces

If you could improve my test so it's not crap that would be lovely!

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

> On 5/5/2015 2:11 PM, Ben Reynwar wrote:
> > Don't bother checking that first attempt.  It's totally broken.  I'll try
> > and sort it out properly and do a pull request and try to refrain the
> > spamming the list too much more.
> >
>
> I can create tests you can work against if you like?
>
> 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] Reusability and encapsulation

[Juan P. C. <jp...@gm...>]

Oh, sorry, I didn't actually run your notebook. I just didn't (and still
don't) see the difference between my code and yours.

I'm not explicitly using _SuspendSimulation or StopSimulation. I don't know
why the simulation "stops" with _SuspendSimulation instead of
StopSimulation. It's stopping at the end of the specified time in
sim.run(stoptime).

Okay, now I see it. At the completion of simulation time _SuspendSimulation
is raised to exit (this is the bug?). You explicitly use StopSimulation.

Thanks,

JP

On Wed, May 6, 2015 at 1:50 PM, Christopher Felton <chr...@gm...>
wrote:

> On 5/6/2015 12:15 PM, Juan Pablo Caram wrote:
> > Ok, installed from git. Version is 0.9.dev0. And the problem persists.
> Here
> > is some more detail:
> >
> > def tb():
> >      ...
> >      return ...
> >
> > model_inst = traceSignals(tb)
> > sim = Simulation(model_inst)
> > sim.run(1 * us)
> >
>
> This is a known problem with a known solution, the
> difference between _SuspendSimulation and StopSimulation.
>
> There will probably be a fix shortly'sh.
>
> There was a little confusion in this thread, because I
> thought you said you observed this issue in the example
> I mentioned:
>
> http://nbviewer.ipython.org/github/cfelton/musicbox_simple/blob/master/musicbox.ipynb
>
>  >>> if you try to run the line:
>  >>>
>  >>> Simulation(traceSignals(_test)).run()
>  >>>
>  >>> a second time without restarting the kernel.
>
> This problem (the second), could not be reproduced with the
> example I provided as described in a previous reply.
>
> 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

[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

[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] Reusability and encapsulation

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

On 5/6/2015 12:15 PM, Juan Pablo Caram wrote:
> Ok, installed from git. Version is 0.9.dev0. And the problem persists. Here
> is some more detail:
>
> def tb():
>      ...
>      return ...
>
> model_inst = traceSignals(tb)
> sim = Simulation(model_inst)
> sim.run(1 * us)
>

This is a known problem with a known solution, the
difference between _SuspendSimulation and StopSimulation.

There will probably be a fix shortly'sh.

There was a little confusion in this thread, because I
thought you said you observed this issue in the example
I mentioned:
http://nbviewer.ipython.org/github/cfelton/musicbox_simple/blob/master/musicbox.ipynb

 >>> if you try to run the line:
 >>>
 >>> Simulation(traceSignals(_test)).run()
 >>>
 >>> a second time without restarting the kernel.

This problem (the second), could not be reproduced with the
example I provided as described in a previous reply.

Regards,
Chris