myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

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

On 9/28/2012 9:21 AM, Tom Dillon wrote:
>
> On 09/28/2012 08:53 AM, Christopher Felton wrote:
>> On 9/28/2012 8:25 AM, Tom Dillon wrote:
>>> Angel,
>>>
>>> My quick answer is to start in one of two areas.
>>>
>>> 1. Use MyHDL to design and test modules that are included in your VHDL
>>> design. Make the modules general purpose with parameters so that they
>>> are easily reused. The test bench and module source will be in MyHDL.
>>>
>>> 2. Use MyHDL as a test bench for existing VHDL modules. You can get far
>>> better test coverage quicker with this approach. Of course now we are
>>> talking about co-simulation, so you will have to be using a VHDL
>>> simulator that is supported or modify an existing interface to work with
>>> your simulator (usually not much work). I use Aldec Riviera and it works
>>> great.
>>>
>>> I would start there.
>>>
>>> Tom
>>>
>> Tom,
>>
>> Are you using cosimulation with Aldec and VHDL?  If so did you have to
>> do small mods for the VHPI interface?
>>
>> Regards,
>> Chris
>>
> Chris,
>
> Great question. It had been so long since I did that I forgot. I am
> using VPI (not VHPI) to connect to the Riviera simulator. I have a mixed
> mode version of Riviera so that allows me to simulate Verilog or VHDL
> modules.
>
> I suspect VHPI would work as well.
>
> Tom
>
>

Strangely modelsim does not appear to support VPI with
VHDL directly, you have to use their FLI interface.

But I do not know what happens if you do a mixed Verilog/VHDL
sim in Modelsim.  My guess is, you have to do a Verilog
mixed VHDL sim (top-level Verilog) and it would work.
If that is true, the quick path for MyHDL-VHDL cosim
would be this approach (mixed verilog/vhdl requires
Modelsim SE or Questa).

Regards,
Chris

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

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

On 09/28/2012 08:53 AM, Christopher Felton wrote:
> On 9/28/2012 8:25 AM, Tom Dillon wrote:
>> Angel,
>>
>> My quick answer is to start in one of two areas.
>>
>> 1. Use MyHDL to design and test modules that are included in your VHDL
>> design. Make the modules general purpose with parameters so that they
>> are easily reused. The test bench and module source will be in MyHDL.
>>
>> 2. Use MyHDL as a test bench for existing VHDL modules. You can get far
>> better test coverage quicker with this approach. Of course now we are
>> talking about co-simulation, so you will have to be using a VHDL
>> simulator that is supported or modify an existing interface to work with
>> your simulator (usually not much work). I use Aldec Riviera and it works
>> great.
>>
>> I would start there.
>>
>> Tom
>>
> Tom,
>
> Are you using cosimulation with Aldec and VHDL?  If so did you have to
> do small mods for the VHPI interface?
>
> Regards,
> Chris
>
Chris,

Great question. It had been so long since I did that I forgot. I am 
using VPI (not VHPI) to connect to the Riviera simulator. I have a mixed 
mode version of Riviera so that allows me to simulate Verilog or VHDL 
modules.

I suspect VHPI would work as well.

Tom


>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

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

On 9/28/2012 8:25 AM, Tom Dillon wrote:
> Angel,
>
> My quick answer is to start in one of two areas.
>
> 1. Use MyHDL to design and test modules that are included in your VHDL
> design. Make the modules general purpose with parameters so that they
> are easily reused. The test bench and module source will be in MyHDL.
>
> 2. Use MyHDL as a test bench for existing VHDL modules. You can get far
> better test coverage quicker with this approach. Of course now we are
> talking about co-simulation, so you will have to be using a VHDL
> simulator that is supported or modify an existing interface to work with
> your simulator (usually not much work). I use Aldec Riviera and it works
> great.
>
> I would start there.
>
> Tom
>

Tom,

Are you using cosimulation with Aldec and VHDL?  If so did you have to 
do small mods for the VHPI interface?

Regards,
Chris

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

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

Angel,

My quick answer is to start in one of two areas.

1. Use MyHDL to design and test modules that are included in your VHDL 
design. Make the modules general purpose with parameters so that they 
are easily reused. The test bench and module source will be in MyHDL.

2. Use MyHDL as a test bench for existing VHDL modules. You can get far 
better test coverage quicker with this approach. Of course now we are 
talking about co-simulation, so you will have to be using a VHDL 
simulator that is supported or modify an existing interface to work with 
your simulator (usually not much work). I use Aldec Riviera and it works 
great.

I would start there.

Tom


On 09/28/2012 02:26 AM, Angel Ezquerra wrote:
> Hi,
>
> For the past couple of years I've been following the MyHDL project
> with a lot of interest. I've been subscribed to the mailing list and
> followed many of the interesting discussions in here. I've done a few
> of the examples on my spare time and I have read the documentation a
> couple of times.
>
> I really like the language. I find it very clear and simply way nicer
> than VHDL, which is what we use in our projects where I work. I have
> quite a lot of experience with Python, and at work I sometimes use it
> with some of its great scientific packages, such as simpy, scipy,
> matplotlib, etc, mainly for simulation purposes although most of my
> colleagues use Matlab for this.
>
> That being said, I have trouble coming up with a good way to integrate
> MyHDL into our existing workflows. I'm looking for advice here to see
> if there is a way that we could use MyHDL to improve our productivity.
>
> Our current setup is as follows:
>
> - We use Xilinx FPGAs (Spartan and Virtex 5 and 6 and probably Kintex
> or Virtex 7 soon).
> - Our firmware code is 100% VHDL.
> - We use the latest version of the Xilinx ISE environment (which
> unfortunately is pretty weak, specially in the editing and code
> exploration departments).
>      - Some of us are also using the excellent Sigasi editor (which I
> discovered thanks to this list). For now we are using the basic
> edition which is nice but we hope to be able to buy a few licenses
> soon.
> - We use some Xilinx IP cores, which come as an NGC plus a VHDL simulation file.
> - We receive a basic firmware "shell" from our hardware team, which,
> basically, is the top VHDL file of the design. This "shell" sets up
> the system clocks, instantiates the different devices that are used to
> connect the FPGA firmware to the outside world (i.e. the different
> ports, etc), as well as the memories, and other devices that are
> present on the FPGA and on its board.
>      - That "shell" also contains an instance of the actual "top
> entity" that is the one that we create.
>      - They also give us the basic "constraints file" which selects the
> pinout, etc.
>      - We have no control over what we receive from the HW team. We
> must use what they give us "as is".
> - We do not use any custom TCL scripts to build our firmware. We just
> use the ISE "Generate Programming File" command.
> - We use either Modelsim or the builtin ISE ISim simulator to run our
> simulations. We are exploring the possibility of using Xilinx' new
> Vivado Simulator as well.
> - We usually create a "high level" Matlab or python based simulation
> models of our system. The model is not necessarily bit accurate to the
> actual VHDL implementation, but we try to make it so that it is able
> to generate the inputs necessary to drive our VHDL test benches
> (including configuration and data), and even our compiled firmware
> (mostly configuration)
> - We create VHDL test benches for most (although sadly not all) of our
> modules. These test benches are usually quite simple. They just read
> the inputs from some files (generated with our Matlab or python
> simulators) and save the outputs so that they can be compared to some
> "golden" outputs (usually generated with our high level simulators).
>      - When there are issues we often use the test benches to simulate
> the models and we use the (not so good) visualization capabilities of
> Modelsim to debug.
>     - We also tend to use ChipScope to add "logic analyzer modules" to
> our firmware so that we can debug "live" some specially tricky issues.
>      - We also use a logic analyzer port to output data that is then
> captured by an external logic analizer. This is necessary when the
> amount of data to capture is so great that it would not fit on a
> ChipScope block.
>
> What we definitely cannot do is introduce huge changes to our
> development practices. I am sure that there are plenty of things that
> we could do differently and that we should (and probably will)
> improve. However I'd like to introduce this new technology gradually,
> and once people are more comfortable with it we could do bigger
> changes to our work flow.
>
> The way I see it there are a few barriers that make it hard for us to
> use MyHDL. It is likely that some of these are moot (i.e. perhaps when
> we start using MyHDL I'll realize that they are not important), but
> for now they seem things that we should deal with:
>
> 1. The MyHDL code may need to interface with existing blocks,
> particularly with IP cores. This results in several problems:
>     - It would make it hard to run simulations on the "MyHDL world"
> since we do not have MyHDL models for the Xilinx IP cores.
>     - I got the impression that the MyHDL to VHDL "interface" is not
> that clean and that the process is manual (I have not looked much into
> this, so I may be wrong).
> 2. We should come up with a way to automatically generate the VHDL
> from the MyHDL when we generate our programming file.
> 3. There is no integration (AFAIK) between MyHDL and iSIM or Modelsim
> (at least on Windows).
> 4. For legacy reasons a lot of our code uses the IEEE.STD_LOGIC_ARITH
> and IEEE.STD_LOGIC_UNSIGNED packages, while MyHDL uses NUMERIC_STD
> (and rightly so). There may be issues mixing both sets of libraries.
> 5. There is no editor integration (not even with Sigasi).
> 6. I believe that the fact that the VHDL code that MyHDL generates is
> "flat" is a problem, because it makes it harder to introduce MyHDL
> little by little.
>     - This may be just my perception and turn out to be a non issue,
> but I think that if MyHDL generated regular structured code (e.g. if
> you could tell MyHDL "place all these processes on a single entity
> named foo") it would be much easier to start using MyHDL to create
> smaller modules that could be added to our regular VHDL project "as
> is".
>
> There are probably other issues that I have not thought about, and
> maybe some of these are not a problem at all.
>
> I'd like to get your opinions and your advice on whether you think it
> makes sense to try to fit MyHDL into our workflow. Perhaps it does not
> make sense unless you use MyHDL from start to end, but I hope it is
> possible.
>
> Cheers,
>
> Angel
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

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

<snip>
> The way I see it there are a few barriers that make it hard for us to
> use MyHDL. It is likely that some of these are moot (i.e. perhaps when
> we start using MyHDL I'll realize that they are not important), but
> for now they seem things that we should deal with:
>
> 1. The MyHDL code may need to interface with existing blocks,
> particularly with IP cores. This results in several problems:
>     - It would make it hard to run simulations on the "MyHDL world"
> since we do not have MyHDL models for the Xilinx IP cores.
>     - I got the impression that the MyHDL to VHDL "interface" is not
> that clean and that the process is manual (I have not looked much into
> this, so I may be wrong).

You would still use the VHDL environment interfacing
to IP cores for simulation would be the same.  In your
MyHDL "IP" development you would need to generate a
model (you can stub it out) or cosim.

> 2. We should come up with a way to automatically generate the VHDL
> from the MyHDL when we generate our programming file.

Yes, you can create a python script that drives
everything (Python world domination).

> 3. There is no integration (AFAIK) between MyHDL and iSIM or Modelsim
> (at least on Windows).

Not possible with iSim, possible with Modelsim but it will
take some work.  There is other cosim VHDL interest.

> 4. For legacy reasons a lot of our code uses the IEEE.STD_LOGIC_ARITH
> and IEEE.STD_LOGIC_UNSIGNED packages, while MyHDL uses NUMERIC_STD
> (and rightly so). There may be issues mixing both sets of libraries.

I don't believe this is an issue, because VHDL is
strongly typed you have to do explicit conversion going
from one type to another.  It can be a pain but shouldn't
be a problem.  I have had this issue in the past where
all my VHDL used numeric_std and I had to add type
conversion at the interfaces to the legacy HDL.

> 5. There is no editor integration (not even with Sigasi).

?? What do you mean by editor integration.  MyHDL is
simply Python, pydev in Eclipse works with other Eclipse
packages.

> 6. I believe that the fact that the VHDL code that MyHDL generates is
> "flat" is a problem, because it makes it harder to introduce MyHDL
> little by little.
>     - This may be just my perception and turn out to be a non issue,
> but I think that if MyHDL generated regular structured code (e.g. if
> you could tell MyHDL "place all these processes on a single entity
> named foo") it would be much easier to start using MyHDL to create
> smaller modules that could be added to our regular VHDL project "as
> is".

I don't see this as an issue?  If you have an existing
HDL design, say the top level looks like this (pseudo code,
err myhdl).

    i1 = block_vhdl(...)
    i2 = block_vhdl(...)
    i3 = block_myhdl_vhdl(...)

The "i3" module is the "flat" myhdl converted to VHDL.
There are some limitations but not many and most are
manageable.  I don't think this should be a concern.

>
> There are probably other issues that I have not thought about, and
> maybe some of these are not a problem at all.
>
> I'd like to get your opinions and your advice on whether you think it
> makes sense to try to fit MyHDL into our workflow. Perhaps it does not
> make sense unless you use MyHDL from start to end, but I hope it is
> possible.
>
> Cheers,
>
> Angel
>

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

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

On 9/28/2012 7:31 AM, Angel Ezquerra wrote:
> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton
> <chr...@gm...> wrote:
>> On 9/28/2012 2:26 AM, Angel Ezquerra wrote:
>>> Hi,
>>>
>>> For the past couple of years I've been following the MyHDL project
>>> with a lot of interest. I've been subscribed to the mailing list and
>>> followed many of the interesting discussions in here. I've done a few
>>> of the examples on my spare time and I have read the documentation a
>>> couple of times.
>>>
>>> I really like the language. I find it very clear and simply way nicer
>>> than VHDL, which is what we use in our projects where I work. I have
>>> quite a lot of experience with Python, and at work I sometimes use it
>>> with some of its great scientific packages, such as simpy, scipy,
>>> matplotlib, etc, mainly for simulation purposes although most of my
>>> colleagues use Matlab for this.
>>>
>>> That being said, I have trouble coming up with a good way to integrate
>>> MyHDL into our existing workflows. I'm looking for advice here to see
>>> if there is a way that we could use MyHDL to improve our productivity.
>>>
>> <snip>
>>
>> My quick two cents is that you adopt the "IP" developed
>> with MyHDL approach.  You start using the tool this way.
>> Your co-workers might never know you are using MyHDL.
>
> I'm not sure I understand what you mean. Do you mean that I would
> write my code on MyHDL, generate the VHDL and publish the generated
> VHDL as an "IP"?

Essentially, but I don't mean that you have to create a
netlist and integrate.  Simply take the generated VHDL
and use in the design.

>
> If that is the case I fear that the fact that the automatically
> generated code is flat may be a problem. Depending on how big are the
> modules that I work on it the resulting VHDL could be pretty big,
> couldn't it? I guess my colleagues would find that odd :-P

Why would a large VHDL be an issue?  I don't think it
is.  If you really need the hierarchy there are options,
just takes a little more work.

>
>> As you indicate, there are some short comings to this
>> approach.  One of the items you suggested is using MyHDL
>> for top-level simulation/verification (cosimulation with
>> VHDL).  What VHDL simulator are you using?
>
> We currently use Modelsim and ISim, on Windows.

Isim doesn't support PLI/VPI/DPI/VHPI you won't be able
to do cosim with Isim.  There's other interest with mti
VHDL cosim, this has a decent change of being developed.
If that occurs, you can start developing a top-level
verification environment and blow the socks off your
co-workers!  They will be utterly amazed.

>
>> Since you have an established flow, I imagine it will be
>> hard to radically change.  You will need to methodically
>> work MyHDL in.  My best guess, this would mean developing
>> individual pieces with MyHDL then incorporating into the
>> system.
>
> That is what I'd like to do but I don't quite see a good way to do so,
> given the concerns that I stated on my first email.

I believe all the concerns are manageable.  I guess nothing
really stood out that needed to be addressed.  Let me look
at the bullet list again.

>
>> Then second, you could start building your system sim and
>> verification in MyHDL.  This will require VHDL cosim.  There
>> might be enough interest to spend some cycles getting VHDL
>> cosim working, the hold back has been access to commerical
>> simulators.
>
> Being able to write test benches in python would be awesome, that is
> for sure! I really dislike how limited is VHDL for IO and other non
> synthesizable stuff.
>
> Angel

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

[Angel E. <ang...@gm...>]

On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton
<chr...@gm...> wrote:
> On 9/28/2012 2:26 AM, Angel Ezquerra wrote:
>> Hi,
>>
>> For the past couple of years I've been following the MyHDL project
>> with a lot of interest. I've been subscribed to the mailing list and
>> followed many of the interesting discussions in here. I've done a few
>> of the examples on my spare time and I have read the documentation a
>> couple of times.
>>
>> I really like the language. I find it very clear and simply way nicer
>> than VHDL, which is what we use in our projects where I work. I have
>> quite a lot of experience with Python, and at work I sometimes use it
>> with some of its great scientific packages, such as simpy, scipy,
>> matplotlib, etc, mainly for simulation purposes although most of my
>> colleagues use Matlab for this.
>>
>> That being said, I have trouble coming up with a good way to integrate
>> MyHDL into our existing workflows. I'm looking for advice here to see
>> if there is a way that we could use MyHDL to improve our productivity.
>>
> <snip>
>
> My quick two cents is that you adopt the "IP" developed
> with MyHDL approach.  You start using the tool this way.
> Your co-workers might never know you are using MyHDL.

I'm not sure I understand what you mean. Do you mean that I would
write my code on MyHDL, generate the VHDL and publish the generated
VHDL as an "IP"?

If that is the case I fear that the fact that the automatically
generated code is flat may be a problem. Depending on how big are the
modules that I work on it the resulting VHDL could be pretty big,
couldn't it? I guess my colleagues would find that odd :-P

> As you indicate, there are some short comings to this
> approach.  One of the items you suggested is using MyHDL
> for top-level simulation/verification (cosimulation with
> VHDL).  What VHDL simulator are you using?

We currently use Modelsim and ISim, on Windows.

> Since you have an established flow, I imagine it will be
> hard to radically change.  You will need to methodically
> work MyHDL in.  My best guess, this would mean developing
> individual pieces with MyHDL then incorporating into the
> system.

That is what I'd like to do but I don't quite see a good way to do so,
given the concerns that I stated on my first email.

> Then second, you could start building your system sim and
> verification in MyHDL.  This will require VHDL cosim.  There
> might be enough interest to spend some cycles getting VHDL
> cosim working, the hold back has been access to commerical
> simulators.

Being able to write test benches in python would be awesome, that is
for sure! I really dislike how limited is VHDL for IO and other non
synthesizable stuff.

Angel

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

[Angel E. <ang...@gm...>]

On Fri, Sep 28, 2012 at 2:07 PM, Christopher Felton
<chr...@gm...> wrote:
> On 9/28/2012 2:26 AM, Angel Ezquerra wrote:
>> Hi,
>>
>> For the past couple of years I've been following the MyHDL project
>> with a lot of interest. I've been subscribed to the mailing list and
>> followed many of the interesting discussions in here. I've done a few
>> of the examples on my spare time and I have read the documentation a
>> couple of times.
>>
>> I really like the language. I find it very clear and simply way nicer
>> than VHDL, which is what we use in our projects where I work. I have
>> quite a lot of experience with Python, and at work I sometimes use it
>> with some of its great scientific packages, such as simpy, scipy,
>> matplotlib, etc, mainly for simulation purposes although most of my
>> colleagues use Matlab for this.
>>
>
> Do you mean "simpy" or sympy?  One is a CAS and one is
> a discrete event simulator using generators and decorators
> (hmm, sounds familiar).
>
> .chris
>

I misspelled it. I meant sympy (http://sympy.org/en/index.html)!

Angel

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

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

On 9/28/2012 2:26 AM, Angel Ezquerra wrote:
> Hi,
>
> For the past couple of years I've been following the MyHDL project
> with a lot of interest. I've been subscribed to the mailing list and
> followed many of the interesting discussions in here. I've done a few
> of the examples on my spare time and I have read the documentation a
> couple of times.
>
> I really like the language. I find it very clear and simply way nicer
> than VHDL, which is what we use in our projects where I work. I have
> quite a lot of experience with Python, and at work I sometimes use it
> with some of its great scientific packages, such as simpy, scipy,
> matplotlib, etc, mainly for simulation purposes although most of my
> colleagues use Matlab for this.
>
> That being said, I have trouble coming up with a good way to integrate
> MyHDL into our existing workflows. I'm looking for advice here to see
> if there is a way that we could use MyHDL to improve our productivity.
>
<snip>

My quick two cents is that you adopt the "IP" developed
with MyHDL approach.  You start using the tool this way.
Your co-workers might never know you are using MyHDL.

As you indicate, there are some short comings to this
approach.  One of the items you suggested is using MyHDL
for top-level simulation/verification (cosimulation with
VHDL).  What VHDL simulator are you using?

Since you have an established flow, I imagine it will be
hard to radically change.  You will need to methodically
work MyHDL in.  My best guess, this would mean developing
individual pieces with MyHDL then incorporating into the
system.

Then second, you could start building your system sim and
verification in MyHDL.  This will require VHDL cosim.  There
might be enough interest to spend some cycles getting VHDL
cosim working, the hold back has been access to commerical
simulators.

Regards,
Chris

Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

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

On 9/28/2012 2:26 AM, Angel Ezquerra wrote:
> Hi,
>
> For the past couple of years I've been following the MyHDL project
> with a lot of interest. I've been subscribed to the mailing list and
> followed many of the interesting discussions in here. I've done a few
> of the examples on my spare time and I have read the documentation a
> couple of times.
>
> I really like the language. I find it very clear and simply way nicer
> than VHDL, which is what we use in our projects where I work. I have
> quite a lot of experience with Python, and at work I sometimes use it
> with some of its great scientific packages, such as simpy, scipy,
> matplotlib, etc, mainly for simulation purposes although most of my
> colleagues use Matlab for this.
>

Do you mean "simpy" or sympy?  One is a CAS and one is
a discrete event simulator using generators and decorators
(hmm, sounds familiar).

.chris

[myhdl-list] Integrating MyHDL into a more "traditional" design work flow

[Angel E. <ang...@gm...>]

Hi,

For the past couple of years I've been following the MyHDL project
with a lot of interest. I've been subscribed to the mailing list and
followed many of the interesting discussions in here. I've done a few
of the examples on my spare time and I have read the documentation a
couple of times.

I really like the language. I find it very clear and simply way nicer
than VHDL, which is what we use in our projects where I work. I have
quite a lot of experience with Python, and at work I sometimes use it
with some of its great scientific packages, such as simpy, scipy,
matplotlib, etc, mainly for simulation purposes although most of my
colleagues use Matlab for this.

That being said, I have trouble coming up with a good way to integrate
MyHDL into our existing workflows. I'm looking for advice here to see
if there is a way that we could use MyHDL to improve our productivity.

Our current setup is as follows:

- We use Xilinx FPGAs (Spartan and Virtex 5 and 6 and probably Kintex
or Virtex 7 soon).
- Our firmware code is 100% VHDL.
- We use the latest version of the Xilinx ISE environment (which
unfortunately is pretty weak, specially in the editing and code
exploration departments).
    - Some of us are also using the excellent Sigasi editor (which I
discovered thanks to this list). For now we are using the basic
edition which is nice but we hope to be able to buy a few licenses
soon.
- We use some Xilinx IP cores, which come as an NGC plus a VHDL simulation file.
- We receive a basic firmware "shell" from our hardware team, which,
basically, is the top VHDL file of the design. This "shell" sets up
the system clocks, instantiates the different devices that are used to
connect the FPGA firmware to the outside world (i.e. the different
ports, etc), as well as the memories, and other devices that are
present on the FPGA and on its board.
    - That "shell" also contains an instance of the actual "top
entity" that is the one that we create.
    - They also give us the basic "constraints file" which selects the
pinout, etc.
    - We have no control over what we receive from the HW team. We
must use what they give us "as is".
- We do not use any custom TCL scripts to build our firmware. We just
use the ISE "Generate Programming File" command.
- We use either Modelsim or the builtin ISE ISim simulator to run our
simulations. We are exploring the possibility of using Xilinx' new
Vivado Simulator as well.
- We usually create a "high level" Matlab or python based simulation
models of our system. The model is not necessarily bit accurate to the
actual VHDL implementation, but we try to make it so that it is able
to generate the inputs necessary to drive our VHDL test benches
(including configuration and data), and even our compiled firmware
(mostly configuration)
- We create VHDL test benches for most (although sadly not all) of our
modules. These test benches are usually quite simple. They just read
the inputs from some files (generated with our Matlab or python
simulators) and save the outputs so that they can be compared to some
"golden" outputs (usually generated with our high level simulators).
    - When there are issues we often use the test benches to simulate
the models and we use the (not so good) visualization capabilities of
Modelsim to debug.
   - We also tend to use ChipScope to add "logic analyzer modules" to
our firmware so that we can debug "live" some specially tricky issues.
    - We also use a logic analyzer port to output data that is then
captured by an external logic analizer. This is necessary when the
amount of data to capture is so great that it would not fit on a
ChipScope block.

What we definitely cannot do is introduce huge changes to our
development practices. I am sure that there are plenty of things that
we could do differently and that we should (and probably will)
improve. However I'd like to introduce this new technology gradually,
and once people are more comfortable with it we could do bigger
changes to our work flow.

The way I see it there are a few barriers that make it hard for us to
use MyHDL. It is likely that some of these are moot (i.e. perhaps when
we start using MyHDL I'll realize that they are not important), but
for now they seem things that we should deal with:

1. The MyHDL code may need to interface with existing blocks,
particularly with IP cores. This results in several problems:
   - It would make it hard to run simulations on the "MyHDL world"
since we do not have MyHDL models for the Xilinx IP cores.
   - I got the impression that the MyHDL to VHDL "interface" is not
that clean and that the process is manual (I have not looked much into
this, so I may be wrong).
2. We should come up with a way to automatically generate the VHDL
from the MyHDL when we generate our programming file.
3. There is no integration (AFAIK) between MyHDL and iSIM or Modelsim
(at least on Windows).
4. For legacy reasons a lot of our code uses the IEEE.STD_LOGIC_ARITH
and IEEE.STD_LOGIC_UNSIGNED packages, while MyHDL uses NUMERIC_STD
(and rightly so). There may be issues mixing both sets of libraries.
5. There is no editor integration (not even with Sigasi).
6. I believe that the fact that the VHDL code that MyHDL generates is
"flat" is a problem, because it makes it harder to introduce MyHDL
little by little.
   - This may be just my perception and turn out to be a non issue,
but I think that if MyHDL generated regular structured code (e.g. if
you could tell MyHDL "place all these processes on a single entity
named foo") it would be much easier to start using MyHDL to create
smaller modules that could be added to our regular VHDL project "as
is".

There are probably other issues that I have not thought about, and
maybe some of these are not a problem at all.

I'd like to get your opinions and your advice on whether you think it
makes sense to try to fit MyHDL into our workflow. Perhaps it does not
make sense unless you use MyHDL from start to end, but I hope it is
possible.

Cheers,

Angel

Re: [myhdl-list] VHDL cosimulation

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

>> This task will be involved.  After a little digging it doesn't look like
>> Modelsim (mti) supports VHPI.  VHPI is the VHDL equivalent to Verilog's
>> VPI.  VHPI would be the easiest to develop VHDL cosimulation support.
>> Modelsim has, what they call, FLI [1].  It should be possible to create
>> a FLI dynamic library which can be the glue between MyHDL and the mti
>> VHDL simulator.
>
> [1]
> http://homepages.cae.wisc.edu/~ece554/new_website/ToolDoc/Modelsim_docs/docs/pdf/fli.pdf
>
> Is that where you want me to start ??
>
> David
>

Yes, this would be the place to start.  The current cosimulation setup 
is only supported on a "posix" system.  BOMK, how it works is that the 
Python process opens a pipe to the simulator (mti) process.  Following 
this same architecture a similar mti FLI interface can be generated.

Looking at one of the current VPI examples 
(myhdl/cosimulation/modelsim/myhdl_vpi.c) is a good place to start and 
try to see if it can be mapped to the ModelSim VHDL FLI interface.

    1. Review an existing VPI example
    2. Review Modelsim FLI
    3. Determine if FLI can be implemented similar
       to existing VPI

Regards,
Chris

Re: [myhdl-list] VHDL cosimulation

[David B. <dav...@ya...>]

OK

Is that where you want me to start ??

David




--- On Wed, 9/26/12, Christopher Felton <chr...@gm...> wrote:

From: Christopher Felton <chr...@gm...>
Subject: Re: [myhdl-list] VHDL cosimulation
To: myh...@li...
Date: Wednesday, September 26, 2012, 6:31 PM

On 9/25/2012 3:21 PM, David Blubaugh wrote:
> Sure
>
> Whatever is required for mission success !!!
>
> david
>
>


This task will be involved.  After a little digging it doesn't look like 
Modelsim (mti) supports VHPI.  VHPI is the VHDL equivalent to Verilog's 
VPI.  VHPI would be the easiest to develop VHDL cosimulation support. 
Modelsim has, what they call, FLI [1].  It should be possible to create 
a FLI dynamic library which can be the glue between MyHDL and the mti 
VHDL simulator.


[1] 
http://homepages.cae.wisc.edu/~ece554/new_website/ToolDoc/Modelsim_docs/docs/pdf/fli.pdf



------------------------------------------------------------------------------
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] VHDL cosimulation

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

On 9/25/2012 3:21 PM, David Blubaugh wrote:
> Sure
>
> Whatever is required for mission success !!!
>
> david
>
>


This task will be involved.  After a little digging it doesn't look like 
Modelsim (mti) supports VHPI.  VHPI is the VHDL equivalent to Verilog's 
VPI.  VHPI would be the easiest to develop VHDL cosimulation support. 
Modelsim has, what they call, FLI [1].  It should be possible to create 
a FLI dynamic library which can be the glue between MyHDL and the mti 
VHDL simulator.


[1] 
http://homepages.cae.wisc.edu/~ece554/new_website/ToolDoc/Modelsim_docs/docs/pdf/fli.pdf

Re: [myhdl-list] VHDL cosimulation

[David B. <dav...@ya...>]

Sure

Whatever is required for mission success !!!

david




--- On Tue, 9/25/12, Christopher Felton <chr...@gm...> wrote:

From: Christopher Felton <chr...@gm...>
Subject: Re: [myhdl-list] VHDL cosimulation
To: myh...@li...
Date: Tuesday, September 25, 2012, 4:19 PM

On 9/25/2012 3:15 PM, Christopher Felton wrote:
 >>> On 9/25/2012 3:02 PM, David Blubaugh wrote:
 >>>> Is there a way to call VHDL within a MyHDL script file??
 >>>>
 >>>> I want to simulate a preexisting VHDL file within MyHDL !!!
 >>>>
 >>>> David
 >>>>
 >>
 >> Currently cosimulation with existing VHDL is not supported.  But it is
 >> possible with a VHDL simulator that supports VPI/VHPI.  BOMK modelsim
 >> and active-hdl support VHPI.  But there hasn't been much effort to test
 >> and verify the interfaces.
 >>
 >> Here are some notes on the GHDL-VHPI interface,
 >> http://www.myhdl.org/doku.php/dev:vhdl_cosim.  It has been awhile since
 >> we last check the GHDL VHPI status.
 >>
 >> Regards,
 >> Chris
 >>
 >
 > The simulator is MODELSIM / QUESTA which is embedded in Actel Libero 
!!!
 >
 > David

There would be some legwork that would have to be done but it *might* be 
possible.  Would you be able/willing to try and put together the 
VPI/VHPI interface together for modelsim?

.chris


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] VHDL cosimulation

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

On 9/25/2012 3:15 PM, Christopher Felton wrote:
 >>> On 9/25/2012 3:02 PM, David Blubaugh wrote:
 >>>> Is there a way to call VHDL within a MyHDL script file??
 >>>>
 >>>> I want to simulate a preexisting VHDL file within MyHDL !!!
 >>>>
 >>>> David
 >>>>
 >>
 >> Currently cosimulation with existing VHDL is not supported.  But it is
 >> possible with a VHDL simulator that supports VPI/VHPI.  BOMK modelsim
 >> and active-hdl support VHPI.  But there hasn't been much effort to test
 >> and verify the interfaces.
 >>
 >> Here are some notes on the GHDL-VHPI interface,
 >> http://www.myhdl.org/doku.php/dev:vhdl_cosim.  It has been awhile since
 >> we last check the GHDL VHPI status.
 >>
 >> Regards,
 >> Chris
 >>
 >
 > The simulator is MODELSIM / QUESTA which is embedded in Actel Libero 
!!!
 >
 > David

There would be some legwork that would have to be done but it *might* be 
possible.  Would you be able/willing to try and put together the 
VPI/VHPI interface together for modelsim?

.chris

[myhdl-list] VHDL cosimulation

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

> On 9/25/2012 3:02 PM, David Blubaugh wrote:
>> Is there a way to call VHDL within a MyHDL script file??
>>
>> I want to simulate a preexisting VHDL file within MyHDL !!!
>>
>> David
>>

Currently cosimulation with existing VHDL is not supported.  But it is 
possible with a VHDL simulator that supports VPI/VHPI.  BOMK modelsim 
and active-hdl support VHPI.  But there hasn't been much effort to test 
and verify the interfaces.

Here are some notes on the GHDL-VHPI interface, 
http://www.myhdl.org/doku.php/dev:vhdl_cosim.  It has been awhile since 
we last check the GHDL VHPI status.

Regards,
Chris

Re: [myhdl-list] VHDL Cosimulation was: MyHDL: Why Do We Need Signal Assignments?

[David B. <dav...@ya...>]

The simulator is MODELSIM / QUESTA which is embedded in Actel Libero !!!  

David







--- On Tue, 9/25/12, Christopher Felton <chr...@gm...> wrote:

From: Christopher Felton <chr...@gm...>
Subject: Re: [myhdl-list] VHDL Cosimulation was: MyHDL: Why Do We Need Signal Assignments?
To: myh...@li...
Date: Tuesday, September 25, 2012, 4:09 PM

On 9/25/2012 3:02 PM, David Blubaugh wrote:
> Is there a way to call VHDL within a MyHDL script file??
>
> I want to simulate a preexisting VHDL file within MyHDL !!!
>
> David
>

Which VHDL simulator are you using?

>
>
>
>
> --- On Tue, 9/25/12, Jan Decaluwe <ja...@ja...> wrote:
>
> From: Jan Decaluwe <ja...@ja...>
> Subject: Re: [myhdl-list] MyHDL: Why Do We Need Signal Assignments?
> To: myh...@li...
> Date: Tuesday, September 25, 2012, 12:24 PM
>
> On 09/25/2012 12:49 AM, Angel Ezquerra wrote:
>>
>> On Sep 23, 2012 10:13 AM, "Jan Decaluwe" <ja...@ja...
>> <mailto:ja...@ja...>> wrote:
>>>
>>> I have justed posted a blog about signal assignments, why they are
>>> needed and who MyHDL implements them.
>>>
>>> I feel these concepts are often misunderstood, which leads to
>>> misunderstandings later on. I hope you like it.
>>>
>>> http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=251153&
>>
>>>
>>
>>> -- th Co Jan Decaluwe
>>
>> Very nice and clear post. It covers some very basic stuff, yet this
>> is something that I think a lot of people do not really understand.
>
> Right, and judging from the lack of response, I'm not sure they
> do now :-) But anyway, this is done so I can refer to it in the
> future.
>
>> I remember that, when I first read about MyHDL, I found the way
>> signal assignments work (by assigning to the "next" property) very
>> intuitive. I'm sure a lot of people will find your article very
>> enlightening. I sure did, and I forwarded it to the members of my
>> team.
>
> Excellent!
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] VHDL Cosimulation was: MyHDL: Why Do We Need Signal Assignments?

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

On 9/25/2012 3:02 PM, David Blubaugh wrote:
> Is there a way to call VHDL within a MyHDL script file??
>
> I want to simulate a preexisting VHDL file within MyHDL !!!
>
> David
>

Which VHDL simulator are you using?

>
>
>
>
> --- On Tue, 9/25/12, Jan Decaluwe <ja...@ja...> wrote:
>
> From: Jan Decaluwe <ja...@ja...>
> Subject: Re: [myhdl-list] MyHDL: Why Do We Need Signal Assignments?
> To: myh...@li...
> Date: Tuesday, September 25, 2012, 12:24 PM
>
> On 09/25/2012 12:49 AM, Angel Ezquerra wrote:
>>
>> On Sep 23, 2012 10:13 AM, "Jan Decaluwe" <ja...@ja...
>> <mailto:ja...@ja...>> wrote:
>>>
>>> I have justed posted a blog about signal assignments, why they are
>>> needed and who MyHDL implements them.
>>>
>>> I feel these concepts are often misunderstood, which leads to
>>> misunderstandings later on. I hope you like it.
>>>
>>> http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=251153&
>>
>>>
>>
>>> -- th Co Jan Decaluwe
>>
>> Very nice and clear post. It covers some very basic stuff, yet this
>> is something that I think a lot of people do not really understand.
>
> Right, and judging from the lack of response, I'm not sure they
> do now :-) But anyway, this is done so I can refer to it in the
> future.
>
>> I remember that, when I first read about MyHDL, I found the way
>> signal assignments work (by assigning to the "next" property) very
>> intuitive. I'm sure a lot of people will find your article very
>> enlightening. I sure did, and I forwarded it to the members of my
>> team.
>
> Excellent!
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] VHDL simulated within MYHDL !!!!

[David B. <dav...@ya...>]

Is there a way to call VHDL within a MyHDL script file??

I want to simulate a preexisting VHDL file within MyHDL !!!

David








--- On Tue, 9/25/12, David Blubaugh <dav...@ya...> wrote:

From: David Blubaugh <dav...@ya...>
Subject: Re: [myhdl-list] MyHDL: Why Do We Need Signal Assignments?
To: myh...@li..., ja...@ja...
Date: Tuesday, September 25, 2012, 4:02 PM

Is there a way to call VHDL within a MyHDL script file??

I want to simulate a preexisting VHDL file within MyHDL !!!

David





--- On Tue, 9/25/12, Jan Decaluwe <ja...@ja...> wrote:

From: Jan Decaluwe <ja...@ja...>
Subject: Re: [myhdl-list] MyHDL: Why Do We Need Signal Assignments?
To: myh...@li...
Date: Tuesday, September 25, 2012, 12:24 PM

On 09/25/2012 12:49 AM, Angel Ezquerra wrote:
>
> On Sep 23, 2012 10:13 AM, "Jan Decaluwe" <ja...@ja...
> <mailto:ja...@ja...>> wrote:
>>
>> I have justed posted a blog about signal assignments, why they are
>> needed and who MyHDL implements them.
>>
>> I feel these concepts are often misunderstood, which leads to
>> misunderstandings later on. I hope you like it.
>>
>> http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=251153&
>
>>
>
>> -- th Co Jan Decaluwe
>
> Very nice and clear post. It covers some very basic stuff, yet this
> is something that I think a lot of people do not really understand.

Right, and judging from the lack of response, I'm not sure they
do now :-) But anyway, this is done so I can refer to it in
 the
future.

> I remember that, when I first read about MyHDL, I found the way
> signal assignments work (by assigning to the "next" property) very
> intuitive. I'm sure a lot of people will find your article very
> enlightening. I sure did, and I forwarded it to the members of my
> team.

Excellent!


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com


------------------------------------------------------------------------------
Live Security
 Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] MyHDL: Why Do We Need Signal Assignments?

[David B. <dav...@ya...>]

Is there a way to call VHDL within a MyHDL script file??

I want to simulate a preexisting VHDL file within MyHDL !!!

David





--- On Tue, 9/25/12, Jan Decaluwe <ja...@ja...> wrote:

From: Jan Decaluwe <ja...@ja...>
Subject: Re: [myhdl-list] MyHDL: Why Do We Need Signal Assignments?
To: myh...@li...
Date: Tuesday, September 25, 2012, 12:24 PM

On 09/25/2012 12:49 AM, Angel Ezquerra wrote:
>
> On Sep 23, 2012 10:13 AM, "Jan Decaluwe" <ja...@ja...
> <mailto:ja...@ja...>> wrote:
>>
>> I have justed posted a blog about signal assignments, why they are
>> needed and who MyHDL implements them.
>>
>> I feel these concepts are often misunderstood, which leads to
>> misunderstandings later on. I hope you like it.
>>
>> http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=251153&
>
>>
>
>> -- th Co Jan Decaluwe
>
> Very nice and clear post. It covers some very basic stuff, yet this
> is something that I think a lot of people do not really understand.

Right, and judging from the lack of response, I'm not sure they
do now :-) But anyway, this is done so I can refer to it in the
future.

> I remember that, when I first read about MyHDL, I found the way
> signal assignments work (by assigning to the "next" property) very
> intuitive. I'm sure a lot of people will find your article very
> enlightening. I sure did, and I forwarded it to the members of my
> team.

Excellent!


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Would you ...

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

On 9/25/2012 10:56 AM, Tom Dillon wrote:
> My personal preference is named arguments.
>
> I also use signal arguments to pass some functionality as well.
>
> Such as:
>
> mymodule(clock=None,reset=None, a=sig1, b=sig2, c=sig3, UseFilt=False)
>
> Would make it asynchronous. The mymodule definition would have to check
> for clock==None and return the appropriate logic.
>
>

I agree, name arguments is what you usually want and your example is a 
perfect demonstration of creating very flexible IP.

The use of "interfaces" helps as well.

     mymodule(syssigs=None, datapath=datapath, UseFilt=False)

and in the module you can have

     def mymodule(...):
         (a,b,c) = datapath.GetSigs()
         if syssigs is not None:
             clock = syssigs.clock
             reset = syssigs.reset
             # ...
         else:
             # ...

where datapath is:
     class Datapath(object):
         def __init__(self):
             self.a,self.b,self.c = [Signal...]
         def GetSigs(self):
             return self.a,self.b,self.c


Regards,
Chris

Re: [myhdl-list] MyHDL: Why Do We Need Signal Assignments?

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

On 09/25/2012 12:49 AM, Angel Ezquerra wrote:
>
> On Sep 23, 2012 10:13 AM, "Jan Decaluwe" <ja...@ja...
> <mailto:ja...@ja...>> wrote:
>>
>> I have justed posted a blog about signal assignments, why they are
>> needed and who MyHDL implements them.
>>
>> I feel these concepts are often misunderstood, which leads to
>> misunderstandings later on. I hope you like it.
>>
>> http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=251153&
>
>>
>
>> -- th Co Jan Decaluwe
>
> Very nice and clear post. It covers some very basic stuff, yet this
> is something that I think a lot of people do not really understand.

Right, and judging from the lack of response, I'm not sure they
do now :-) But anyway, this is done so I can refer to it in the
future.

> I remember that, when I first read about MyHDL, I found the way
> signal assignments work (by assigning to the "next" property) very
> intuitive. I'm sure a lot of people will find your article very
> enlightening. I sure did, and I forwarded it to the members of my
> team.

Excellent!


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Would you ...

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

My personal preference is named arguments.

I also use signal arguments to pass some functionality as well.

Such as:

mymodule(clock=None,reset=None, a=sig1, b=sig2, c=sig3, UseFilt=False)

Would make it asynchronous. The mymodule definition would have to check 
for clock==None and return the appropriate logic.




On 09/25/2012 10:45 AM, Christopher Felton wrote:
> use function attributes instead of named arguments for a MyHDL module
> configuration?  Not sure if this would be a good idea or not.
>
> Example:
>
>       def mymodule(clock, reset, a, b, c):
>
>           if hasattr(mymodule, 'use_filter') and mymodule.use_filter:
> 	    aflt = Signal(intbv(0, min=c.min, max=c.max))
>               gens = myfilter(clock, reset, a, aflt)
>           else:
>               aflt,gens = (a,[])
>
>           @always_seq(clock.posedge, reset=reset)
>           def hdl():
>               c.next = a + b
>           gens = [gens, hdl]
>
>           return gens
>
> Traditionally you would add:
>
>       mymodule(clock, reset, a, b, c, UseFilt=False)
>
>
> After writing this it dawned on me, most of the time it would be bad.  I
> guess a function attribute would only be useful if you wanted every
> MyHDL module instance to act exactly the same (e.g. if the filter was
> enabled in one instance it would be enabled in all instances).
>
> So where this might be useful is if you are using technology primitives
> (FPGA primitives) and you want to instantiate a primitive based on a
> technology, say Xilin or Altera.  But in that case you would want the
> attribute to be global to all the modules, hmmm.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] Would you ...

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

use function attributes instead of named arguments for a MyHDL module 
configuration?  Not sure if this would be a good idea or not.

Example:

     def mymodule(clock, reset, a, b, c):

         if hasattr(mymodule, 'use_filter') and mymodule.use_filter:
	    aflt = Signal(intbv(0, min=c.min, max=c.max))
             gens = myfilter(clock, reset, a, aflt)
         else:
             aflt,gens = (a,[])

         @always_seq(clock.posedge, reset=reset)
         def hdl():
             c.next = a + b
         gens = [gens, hdl]

         return gens

Traditionally you would add:

     mymodule(clock, reset, a, b, c, UseFilt=False)


After writing this it dawned on me, most of the time it would be bad.  I 
guess a function attribute would only be useful if you wanted every 
MyHDL module instance to act exactly the same (e.g. if the filter was 
enabled in one instance it would be enabled in all instances).

So where this might be useful is if you are using technology primitives 
(FPGA primitives) and you want to instantiate a primitive based on a 
technology, say Xilin or Altera.  But in that case you would want the 
attribute to be global to all the modules, hmmm.

Regards,
Chris