myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] [PATCH 2 of 3] toVHDL: indent signal declarations

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

# HG changeset patch
# User Angel Ezquerra <ang...@gm...>
# Date 1349882392 -7200
# Branch 0.8-dev
# Node ID 54652ce766a4f8ee6318e662a5394df20a899711
# Parent  3c6f870ae4b826ac462778d3d61a6477928957ef
toVHDL: indent signal declarations

It is common practice to indent signal declarations (e.g. VHDL indent tools
often indent them). This also makes the generated VHDL code a bit cleaner.

diff --git a/myhdl/conversion/_toVHDL.py b/myhdl/conversion/_toVHDL.py
--- a/myhdl/conversion/_toVHDL.py
+++ b/myhdl/conversion/_toVHDL.py
@@ -303,7 +303,7 @@
                               )
             # the following line implements initial value assignments
             # print >> f, "%s %s%s = %s;" % (s._driven, r, s._name, int(s._val))
-            print >> f, "signal %s: %s%s;" % (s._name, p, r)
+            print >> f, "    signal %s: %s%s;" % (s._name, p, r)
         elif s._read:
             # the original exception
             # raise ToVHDLError(_error.UndrivenSignal, s._name)
@@ -312,7 +312,7 @@
                           category=ToVHDLWarning
                           )
             constwires.append(s)
-            print >> f, "signal %s: %s%s;" % (s._name, p, r)
+            print >> f, "    signal %s: %s%s;" % (s._name, p, r)
     for m in memlist:
         if not m._used:
             continue
@@ -327,8 +327,8 @@
         r = _getRangeString(m.elObj)
         p = _getTypeString(m.elObj)
         t = "t_array_%s" % m.name
-        print >> f, "type %s is array(0 to %s-1) of %s%s;" % (t, m.depth, p, r)
-        print >> f, "signal %s: %s;" % (m.name, t)
+        print >> f, "    type %s is array(0 to %s-1) of %s%s;" % (t, m.depth, p, r)
+        print >> f, "    signal %s: %s;" % (m.name, t)
     print >> f
 
 def _writeCompDecls(f,  compDecls):

[myhdl-list] [PATCH 1 of 3] toVHDL: improve indentation of type definitions

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

# HG changeset patch
# User Angel Ezquerra <ang...@gm...>
# Date 1349882135 -7200
# Branch 0.8-dev
# Node ID 3c6f870ae4b826ac462778d3d61a6477928957ef
# Parent  41d4a8b1380479a3c93e2ecbf7cb90f7dc955119
toVHDL: improve indentation of type definitions

Up until now the indentation of type definitions was be wrong. VHDL type
definitions span multiple lines but only only their first line was indented.

diff --git a/myhdl/conversion/_toVHDL.py b/myhdl/conversion/_toVHDL.py
--- a/myhdl/conversion/_toVHDL.py
+++ b/myhdl/conversion/_toVHDL.py
@@ -222,7 +222,7 @@
     _sortedEnumTypeList = list(_enumTypeSet)
     _sortedEnumTypeList.sort(cmp=lambda a, b: cmp(a._name, b._name))
     for t in _sortedEnumTypeList:
-        print >> f, "    %s" % t._toVHDL()
+        print >> f, "    %s" % t._toVHDL().replace('\n', '\n    ')
     print >> f
     print >> f, "end package pck_%s;" % intf.name
     print >> f

[myhdl-list] [PATCH 0 of 3 ] toVHDL: indentation and documentation placement improvements

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

This patch series addresses a few of the small issues that I recently discussedon this mailing list.
Please have a look at them and let me know if they are acceptable (in content and coding style).

Re: [myhdl-list] Some comments on the VHDL code that MyHDL generates

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

Actually I already fixed problems #1 (type definition indentation), #2
(signal declaration indentation) and #4.1 (location of the entity
level documentation). They were surprisingly easy to fix! :-)

I got 3 patches ready which I'll send in a minute to the list.

Cheers,

Angel


On Wed, Oct 10, 2012 at 9:04 AM, Angel Ezquerra
<ang...@gm...> wrote:
> In my quest to somehow start using MyHDL for my work, I've been
> playing around with it, trying to create a small module in MyHDL from
> scratch.
>
> Since Christopher Felton suggested that I may be able to generate VHDL
> in a way that my colleagues would not even notice, I created a small,
> simple module and looked into the VHDL code that MyHDL generates.
>
> My first impression is that the code is in fact quite similar to what
> I would have written, which is nice. However I have a few comments:
>
> 1. "type" definitions are not properly indented. For example:
>     The following MyHDL:
>
> ~~~
> t_State = enum('INIT', 'WORKING')
> ~~~
>
> becomes the following VHDL:
>
> ~~~
> package pck_sync_module is
>
>     type t_enum_t_State_1 is (
>     INIT,
>     WORKING
> );
>
> end package pck_sync_module;
> ~~~
>
> Here you can see that the lines below the type keyword itself
> (starting with "INIT") are not properly indented.
> Instead it should be (IMHO):
>
> ~~~
> package pck_sync_module is
>
>     type t_enum_t_State_1 is (
>         INIT,
>         WORKING
>     );
> ~~~
>
> 2. I prefer to have the declarations between the "architecture" header
> and the begin keyword to be indented. I also prefer to indent the
> architecture contents (everything between begin/end). This is nothing
> major, and obviously open to debate, but I think it looks clearer. For
> example, I'd prefer:
>
> ~~~
> architecture MyHDL of sync_module is
>
>     signal s_2pps_counter: unsigned(2 downto 0);
>     signal pulse_sync: std_logic;
>
> begin
> ~~~
>
> rather than the current:
>
> ~~~
> architecture MyHDL of sync_module is
>
> signal s_2pps_counter: unsigned(2 downto 0);
> signal pulse_sync: std_logic;
>
> begin
> ~~~
>
> 3. For some reason MyHDL added 3 empty lines between the architecture
> "begin" and the first line of code in it:
>
> ~~~
> architecture MyHDL of sync_module is
>
> signal s_2pps_counter: unsigned(2 downto 0);
> signal pulse_sync: std_logic;
> signal first_pulse: std_logic;
> signal pulse_state: t_enum_t_State_1;
>
> begin
>
>
>
> -- Main process
> SYNC_MODULE_P_PULSE: process (clk, rst) is
>     variable pulse_state3: t_enum_t_State_1;
> begin
>     if (rst = '1') then
> ~~~
>
> See the 3 blank lines betwen begin and the first comment. I would
> think that one single blank would be enough.
>
> 4. I tried to use docstrings to add comments to the generated VHDL, so
> that if someone where to inspect it it would be easier to understand
> without needing to go to my source MyHDL code. This works in most
> cases but there are a few things that could be improved (IMHO) and
> some things that I was just not able to do:
>
>     4.1. If I add a docstring to a function that contains an @always
> block, MyHDL generates a corresponding "top entity". I expected to see
> the docstring above the entity declaration. Instead MyHDL places the
> comment between the entity declaration and the architecture
> declaration, which I think it is a bit weird. I'd rather see the
> documentation as close to the top of the file as possible (i.e. right
> above the entity keyword, so that I can document it).
>
>     4.2. I am unable to use a docstring to comment an enum declaration
> (or any other signal declaration for that matter). This seems to be
> due to the fact that this is done outside of the instance generators.
> I think this is important, particularly for enums which are used for
> state machines. Maybe all MyHDL objects (signals, intbv, etc) could
> have a "comment" or "doc" field that you could set to include some
> info about them on the generated VHDL / Verilog code?
>
>     4.3. Is does not seem possible to add a "top level" file comment
> via a docstring. I guess this is not very important right now since
> there is not a one to one mapping between MyHDL .py files and the
> generated .vhd file.
>
> Please note that this is in no way a criticism of MyHDL. I know that
> the main goal of MyHDL is not to generate human readable VHDL code.
> However I think these small details could improve the generated code
> substantially. Items 1 to 3 could be fixed on the user's end by
> running the generated code through an automated VHDL indenter tool but
> unfortunately I don't know of any good, free indenter that is also
> easy to automate (perhaps emacs in batch mode?).
>
> I have some more comments which are not related to the actual code
> that MyHDL generates but I'll leave that for another email.
>
> Cheers,
>
> Angel

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

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

On Wed, Oct 10, 2012 at 2:25 PM, Christopher Felton
<chr...@gm...> wrote:
> <snip>
>>
>>
>>>> Anyway, since this process seems easy to automate (I can't really
>>>> tell, since I don't really understand it), the obvious question is why
>>>> not make MyHDL itself automate it for us? That should put to rest the
>>>> question of generating hierarchical VHDL or Verilog code which seems
>>>> to crop up regularly on this list and on other online discussions
>>>> about MyHDL!
>>>
>>> The obvious question is why someone interested in a
>>> feature doesn't propose a MEP and a patch?
>>
>> That is a fair point. I am still "testing the waters" with MyHDL so to
>> speak, so for now I am just raising the concerns that I come up with.
>>
>> I could try to write a MEP but first I'd like to see if there is some
>> consensus that this could be a worthy idea (as I believe it is). Also,
>> what would be the preferred way to indicate that a group of generators
>> should be grouped into an entity and placed on their own file?
>>
>> For example, in the case that you described, imagine that you had had
>> a magic wand that let you modify MyHDL in a way that you could have
>> avoided all the manual work involved in solving your problem. How
>> would you have liked to be able to tell MyHDL that you wanted to place
>> "submodule" on its own file?
>>
>> Contributing a patch is another matter though. I am quite busy
>> contributing to TortoiseHg at the moment and I don't know how complex
>> the MyHDL code base is. I don't know that I'd have the time to dig
>> deep enough into it to contribute such a patch.
>>
>
> I am having a hard time following you.  At one point
> you comment
>
>     "since this process seems easy to automate ..."
>
> then you comment
>
>     "... the amount of steps would be great"
>     (implying difficulty)
>
> But if it is easy to automate why would we be concerned
> with the number of steps?

I should have been more clear:
- The process "seems easy to automate" according to what you said.
- But it _currently_ requires a great number of steps since it must be
performed _manually_ (which does not necessarily mean that it would be
hard, just tiresome).

That is, currently MyHDL does not provide a way to make this without
too much effort, but apparently (from what you said) it should be
possible to make it automatic.

> I also get confused if you are only interested in an
> existing solution or you are willing to experiment and
> be part of a development.  This conversation seems to
> bounce back and forth between wanting a working solution
> and "testing the waters".  I am never sure which I am
> replying to.  Given the comments above, I assume you
> are mainly interested in existing and working solutions.
>
> Maintaining hierarchy during conversion is a reasonable
> feature request.  But the priority of the feature?  And
> the best path forward?  I think it is safe to say, given
> the resources available this feature will not be added
> any time soon.  I think you are simply trying to stimulate
> conversation and ideas (which is good!).  But I don't believe
> anyone has the bandwidth to experiment and implement the
> feature.

I'm mostly interested on working solutions, but since it seems there
are none (at least not experimental ones), I want to spur the
conversation some and show that there are people (at least one! :-)
interested on this feature.

As for contributing I have a few small patches ready that I will send
to the list shortly. These address some of small issues regarding VHDL
code generation that I identified on another email.

Cheers,

Angel

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

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

<snip>
>
>
>>> Anyway, since this process seems easy to automate (I can't really
>>> tell, since I don't really understand it), the obvious question is why
>>> not make MyHDL itself automate it for us? That should put to rest the
>>> question of generating hierarchical VHDL or Verilog code which seems
>>> to crop up regularly on this list and on other online discussions
>>> about MyHDL!
>>
>> The obvious question is why someone interested in a
>> feature doesn't propose a MEP and a patch?
>
> That is a fair point. I am still "testing the waters" with MyHDL so to
> speak, so for now I am just raising the concerns that I come up with.
>
> I could try to write a MEP but first I'd like to see if there is some
> consensus that this could be a worthy idea (as I believe it is). Also,
> what would be the preferred way to indicate that a group of generators
> should be grouped into an entity and placed on their own file?
>
> For example, in the case that you described, imagine that you had had
> a magic wand that let you modify MyHDL in a way that you could have
> avoided all the manual work involved in solving your problem. How
> would you have liked to be able to tell MyHDL that you wanted to place
> "submodule" on its own file?
>
> Contributing a patch is another matter though. I am quite busy
> contributing to TortoiseHg at the moment and I don't know how complex
> the MyHDL code base is. I don't know that I'd have the time to dig
> deep enough into it to contribute such a patch.
>

I am having a hard time following you.  At one point
you comment

    "since this process seems easy to automate ..."

then you comment

    "... the amount of steps would be great"
    (implying difficulty)

But if it is easy to automate why would we be concerned
with the number of steps?

I also get confused if you are only interested in an
existing solution or you are willing to experiment and
be part of a development.  This conversation seems to
bounce back and forth between wanting a working solution
and "testing the waters".  I am never sure which I am
replying to.  Given the comments above, I assume you
are mainly interested in existing and working solutions.

Maintaining hierarchy during conversion is a reasonable
feature request.  But the priority of the feature?  And
the best path forward?  I think it is safe to say, given
the resources available this feature will not be added
any time soon.  I think you are simply trying to stimulate
conversation and ideas (which is good!).  But I don't believe
anyone has the bandwidth to experiment and implement the
feature.

Regards,
Chris

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

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

On 10/10/2012 5:47 AM, Angel Ezquerra wrote:
<snip>
>>
>> The "*_instance" isn't currently documented in the
>> manual.  It is something that has been discussed on
>> the mailing list.  This is a discussion of methods
>> that might be possible.  It is not intended to be
>> cookbook solution to a specific problem.
>
> I see. But can you give the the gist of what it is supposed to do? Or
> perhaps a link to the particular thread on the mailing list?
>
This thread:

http://article.gmane.org/gmane.comp.python.myhdl/1484/match=vhdl_instance

has some information.  Note, I simply went to the gmane
myhdl page and did a search.

http://search.gmane.org/?query=vhdl_instance&group=gmane.comp.python.myhdl

But At this point, direct hierarchical conversion is *not*
supported and I don't know of anyone who has automated
the manual process.  I can only contrive possible solutions.
If you are looking for working known solutions, they
*don't exist*.  There are not specific threads and no other
information (as far as I know).  At this point in time what
you are looking for is not supported.

Will it be supported in the future?  I don't know.  It seems
reasonable but there are not the resources to implement it.

Regards,
Chris

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

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

Hi again Chris,

see my replies below.

On Wed, Oct 10, 2012 at 12:20 PM, Christopher Felton
<chr...@gm...> wrote:
> On 10/10/12 1:59 AM, Angel Ezquerra wrote:
>> On Tue, Oct 9, 2012 at 8:07 PM, Christopher Felton
>> <chr...@gm...> wrote:
>>> On 10/4/2012 4:02 PM, Angel Ezquerra wrote:
[...]
>>>>> On 9/28/2012 7:31 AM, Angel Ezquerra wrote:
>>>>>> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton
>> [...]
>>>>> 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.
>>>>
>>>> Could you detail what you mean by it "just takes a little more work"?
>>>
>>> Just that, you will need to convert each piece separately
>>> and merge them together.  Most of this can be automated
>>> (I believe).
>>>
>>> I had a rare case where I wanted to preserve hierarchy
>>> this is how I did it:
>>>
>>>          toVerilog(submodule, sigs, params)
>>>          # move to a new filename with params in the name
>>
>> Sorry, maybe I'm a bit thick but I don't know what you mean by "move
>> to a new filename with params in the name"
>
> When converting a module it has a "default" filename.  In
> this case I wanted a filename that represented the parameters
> used to generated the module.

OK, I understand.

>>>          submodule.verilog_instance = 'SUB1'
>>>          toVerilog(module, sigs, params)
>>>
>>> Where "module" instantiates 'submodule".  This will stub
>>> out "submodule" in module.  It is a little more work
>>> but not bad.  I had to add extra to the submodule
>>>
>>>          def submodule(...):
>>>             if hasattr(submodule, "verilog_instance"):
>>>                 out1.driven = 'wire'
>>>                 out2.driven = 'wire'
>>>                 # etc
>>
>> I don't know what "verilog_instance" does. I guess there is an
>> equivalent "vhdl_instance"? I looked for it on google but I did not
>> get any useful results. I also don't know why you need to set the
>> "driven" attribute.
>
> The "*_instance" isn't currently documented in the
> manual.  It is something that has been discussed on
> the mailing list.  This is a discussion of methods
> that might be possible.  It is not intended to be
> cookbook solution to a specific problem.

I see. But can you give the the gist of what it is supposed to do? Or
perhaps a link to the particular thread on the mailing list?


>> I feel as if these questions are very basic and I should know them...
>> Is there some documentation on these features that I missed?
>>
>>> If you had a design that is more complicated you could
>>> automate the first part.  You still would need to add
>>> the output definition in the module (submodule) being
>>> stubbed.  The nice thing about the above example, every
>>> thing will be wired up automatically.
>>>
>>> Note: I think Jan indicated the verilog_instance might
>>> need some work, use with caution.  I have used it
>>> without issue.
>>
>> As I said I don't really know what these do so I don't think I could
>> use them, even cautiously :-> It still seems a bit too complicated for
>> my taste though.
>
> That is a haste judgement.  If you don't know what
> it is how can you objectively comment that it is too
> complicated?

I don't fully understand each of the steps that you proposed but I see
the amount of steps per submodule. If you wanted to do this for a
large design with a fair amount of submodules the amount of steps
would be great, wouldn't it?


>> Anyway, since this process seems easy to automate (I can't really
>> tell, since I don't really understand it), the obvious question is why
>> not make MyHDL itself automate it for us? That should put to rest the
>> question of generating hierarchical VHDL or Verilog code which seems
>> to crop up regularly on this list and on other online discussions
>> about MyHDL!
>
> The obvious question is why someone interested in a
> feature doesn't propose a MEP and a patch?

That is a fair point. I am still "testing the waters" with MyHDL so to
speak, so for now I am just raising the concerns that I come up with.

I could try to write a MEP but first I'd like to see if there is some
consensus that this could be a worthy idea (as I believe it is). Also,
what would be the preferred way to indicate that a group of generators
should be grouped into an entity and placed on their own file?

For example, in the case that you described, imagine that you had had
a magic wand that let you modify MyHDL in a way that you could have
avoided all the manual work involved in solving your problem. How
would you have liked to be able to tell MyHDL that you wanted to place
"submodule" on its own file?

Contributing a patch is another matter though. I am quite busy
contributing to TortoiseHg at the moment and I don't know how complex
the MyHDL code base is. I don't know that I'd have the time to dig
deep enough into it to contribute such a patch.


>> That could be interesting although given that Xilinx XST will
>> sometimes give you a different result when you implement the same code
>> twice I would not put that much faith on the comparison results...
>> Sometimes I feel that the Xilinx uses the position of the stars and
>> the phase of the moon to decide how to synthesize their FPGAs :-P
>
> No, you should get consistent results from synthesis,
> you might get varying timing from PaR but functionally
> it should not change.  I have not noticed resource
> changes from synthesis run to synthesis run.

That was meant as a point in cheek comment about how finicky the
Xilinx tools are. Sorry if that was not clear.

Cheers,

Angel

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

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

On 10/10/12 1:59 AM, Angel Ezquerra wrote:
> Hi again Chris,
>
> thank you for your replies. See my comments below.
>
> On Tue, Oct 9, 2012 at 8:07 PM, Christopher Felton
> <chr...@gm...> wrote:
>> On 10/4/2012 4:02 PM, Angel Ezquerra wrote:
>>> Chris,
>>>
>>> Sorry it took me so long to get back to you. I've been really busy recently.
>>>
>>> First of all, thanks _a lot_ for taking the time to go through my concerns
>>> so carefully. I really appreciate it.
>>>
>>> See some replies below...
>>>
>>> On Fri, Sep 28, 2012 at 3:12 PM, Christopher Felton <chr...@gm...>
>>> wrote:
>>>> On 9/28/2012 7:31 AM, Angel Ezquerra wrote:
>>>>> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton
> [...]
>>>> 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.
>>>
>>> Could you detail what you mean by it "just takes a little more work"?
>>
>> Just that, you will need to convert each piece separately
>> and merge them together.  Most of this can be automated
>> (I believe).
>>
>> I had a rare case where I wanted to preserve hierarchy
>> this is how I did it:
>>
>>          toVerilog(submodule, sigs, params)
>>          # move to a new filename with params in the name
>
> Sorry, maybe I'm a bit thick but I don't know what you mean by "move
> to a new filename with params in the name"

When converting a module it has a "default" filename.  In
this case I wanted a filename that represented the parameters
used to generated the module.

>
>>          submodule.verilog_instance = 'SUB1'
>>          toVerilog(module, sigs, params)
>>
>> Where "module" instantiates 'submodule".  This will stub
>> out "submodule" in module.  It is a little more work
>> but not bad.  I had to add extra to the submodule
>>
>>          def submodule(...):
>>             if hasattr(submodule, "verilog_instance"):
>>                 out1.driven = 'wire'
>>                 out2.driven = 'wire'
>>                 # etc
>
> I don't know what "verilog_instance" does. I guess there is an
> equivalent "vhdl_instance"? I looked for it on google but I did not
> get any useful results. I also don't know why you need to set the
> "driven" attribute.

The "*_instance" isn't currently documented in the
manual.  It is something that has been discussed on
the mailing list.  This is a discussion of methods
that might be possible.  It is not intended to be
cookbook solution to a specific problem.

>
> I feel as if these questions are very basic and I should know them...
> Is there some documentation on these features that I missed?
>
>> If you had a design that is more complicated you could
>> automate the first part.  You still would need to add
>> the output definition in the module (submodule) being
>> stubbed.  The nice thing about the above example, every
>> thing will be wired up automatically.
>>
>> Note: I think Jan indicated the verilog_instance might
>> need some work, use with caution.  I have used it
>> without issue.
>
> As I said I don't really know what these do so I don't think I could
> use them, even cautiously :-> It still seems a bit too complicated for
> my taste though.

That is a haste judgement.  If you don't know what
it is how can you objectively comment that it is too
complicated?

>
> Anyway, since this process seems easy to automate (I can't really
> tell, since I don't really understand it), the obvious question is why
> not make MyHDL itself automate it for us? That should put to rest the
> question of generating hierarchical VHDL or Verilog code which seems
> to crop up regularly on this list and on other online discussions
> about MyHDL!

The obvious question is why someone interested in a
feature doesn't propose a MEP and a patch?

>
>
>>> My ideal workflow would be to be able to add a decorator to some function
>>> which would mark a file as describing an entity, which would group all
>>> processes defined within it as part of that entity, and which would put
>>> that entity on its own file.
>>>
>>> I think a "large" VHDL is an issue mostly because it would make it much
>>> harder to debug using a regular VHDL simulator (e.g. modelsim) and adding
>>> debug signals to a chipscope (Xilinx' in FPGA logic analyzer).
>>
>> This hasn't been my experience, I have an all MyHDL FPGA
>> design I use to interface to our mixed-signal ICs (ICs
>> also utilize MyHDL).  I use SignalTap frequently and it
>> doesn't cause me much heart-ache.
>
> Glad to know that. Maybe my intuition is wrong then... Still I
> anticipate that you would still need to look into the generated VHDL
> from time to time, possibly using (the terrible) ISE editor. In there
> you'd see a single entity on the hierarchy view. I'd definitely prefer
> to get a proper hierarchy in there instead.
>
>>> Additionally, some synthesizers (XST for example) give you options to
>>> control how optimizations and routing are handling across entity
>>> boundaries. I am by no means an expert of this though. This is just advice
>>> I've gotten from more experienced designers than I am.
>>
>> Not sure what the point is or the question you might
>> be asking?  If you describe your design with a lot of
>> hierarchy it is often beneficial, from a resource /
>> performance point of view, to optimize across boundaries.
>> But this breaks the structure and tools like ChipScope
>> and SignalTap might be more difficult to work with
>> (not much different than MyHDL flattening).
>>
>> An interesting case study would be to record the
>> synthesis results between a hierarchical design,
>> optimize across,and a MyHDL flattened design.
>
> That could be interesting although given that Xilinx XST will
> sometimes give you a different result when you implement the same code
> twice I would not put that much faith on the comparison results...
> Sometimes I feel that the Xilinx uses the position of the stars and
> the phase of the moon to decide how to synthesize their FPGAs :-P

No, you should get consistent results from synthesis,
you might get varying timing from PaR but functionally
it should not change.  I have not noticed resource
changes from synthesis run to synthesis run.

>
>>> I just know that on a somewhat conservative development team it would be
>>> way easier to add to a project a few files that have been automatically
>>> generated via MyHDL than adding a single, big, flat file. I know that I
>>> would face much more resistance with the single flat file than I would
>>> otherwise. Given that I am not the most experienced FW developer in our
>>> team it is uncertain that I'd be able to convince the most expert designers
>>> that this is not a problem.
>>>
>>> This is probably a matter of perception, but I am quite sure that this
>>> would be a big point against MyHDL.
>>
>> I think I might not be following you between "module"
>> and "files".  From my perspective, if you had a new module
>> that you needed to add, you could implement it in MyHDL
>> and you would have /one/ new file to add to the design.
>> Even if the module had many layers of hierarchy, and the
>> one new file would be minimal impact to the existing flow.
>
> Now I am not sure that I understand you. By module I mean a VHDL
> entity and by file I mean, well, a file :-)
>
> The issue I state is that adding a _single_, big, MyHDL generated VHDL
> file to an existing VHDL project would be a problem. The problem is
> not technical (or at least not mainly technical) but "social". I think
> that when working on a project with multiple designers they would not
> easily accept me adding a single file that implemented a significant
> part of the design particularly if they knew that the file had been
> automatically generated. They would ask me to "modularize" my
> contribution. According to what you said above that is something that
> can be done but it requires (unnecessary?) extra work with the current
> version of MyHDL.
>
> In my experience many FW designers are surprisingly risk averse and
> not prone to try new design tools and approaches. That is an
> unfortunate barrier to entry that MyHDL must go through.
>
> If MyHDL let me group part of my MyHDL design in entities or packages,
> which were saved into separate files when generating the VHDL or
> Verilog code, this problem would be gone. IMHO this would make it much
> easier ("socially") to introduce VHDL into an existing, VHDL or
> Verilog based, project.
>
> It may seem that I am blowing this issue out of proportion, but I know
> the people I've worked with and I'm pretty sure these concerns are
> real.
>
> Cheers,
>
> Angel
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>

[myhdl-list] DeprecationWarning when using Python 2.6

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

Hi,

I get a couple of "DeprecationWarning" when running toVHDL with Python 2.6:

C:\python26\lib\site-packages\myhdl\conversion\_toVHDL.py:271:
DeprecationWarning: functions overriding warnings.showwarning() must
support the 'line' argument
  category=ToVHDLWarning

and

C:\python26\lib\site-packages\myhdl\conversion\_toVHDL.py:302:
DeprecationWarning: functions overriding warnings.showwarning() must
support the 'line' argument
  category=ToVHDLWarning

Surprisingly this does not happen when using Python 2.7.

Cheers,

Angel

[myhdl-list] Some comments about using MyHDL to create a simple module

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

Hi,

As I said on my previous email I am trying to create a simple module
using MyHDL and I am trying to see how it feels compared to writing
the same module directly in VHDL. I'm taking notes as I go along. I
already sent some comments regarding the VHDL code that MyHDL
generates and now I have some comments about using MyHDL itself.
Hopefully some of you may find these interesting.

1. When you make a mistake, the toVHDL function raises an error which
spits out a long callback list. Out of this list only the last part is
(usually) interesting (I think!). For example:

C:\myhdl_test>python sync_module.py
Traceback (most recent call last):
  File "sync_module.py", line 56, in <module>
    sync_inst = toVHDL(sync_module, rst, clk, tcell_cnt, mode_2pps_width, sync_i
n, sync_out)
  File "C:\python26\lib\site-packages\myhdl\conversion\_toVHDL.py", line 150, in
 __call__
    genlist = _analyzeGens(arglist, h.absnames)
  File "C:\python26\lib\site-packages\myhdl\conversion\_analyze.py", line 176, i
n _analyzeGens
    v.visit(tree)
  File "C:\python26\lib\ast.py", line 231, in visit
    return visitor(node)
  File "C:\python26\lib\site-packages\myhdl\conversion\_analyze.py", line 1019,
in visit_Module
    self.generic_visit(node)
  File "C:\python26\lib\ast.py", line 239, in generic_visit
    self.visit(item)
  File "C:\python26\lib\ast.py", line 231, in visit
    return visitor(node)
  File "C:\python26\lib\site-packages\myhdl\conversion\_analyze.py", line 1112,
in visit_FunctionDef
    self.visit(n)
  File "C:\python26\lib\ast.py", line 231, in visit
    return visitor(node)
  File "C:\python26\lib\site-packages\myhdl\conversion\_analyze.py", line 710, i
n visit_If
    self.visitList(node.else_)
  File "C:\python26\lib\site-packages\myhdl\conversion\_misc.py", line 163, in v
isitList
    self.visit(n)
  File "C:\python26\lib\ast.py", line 231, in visit
    return visitor(node)
  File "C:\python26\lib\site-packages\myhdl\conversion\_analyze.py", line 506, i
n visit_Assign
    self.visit(target)
  File "C:\python26\lib\ast.py", line 231, in visit
    return visitor(node)
  File "C:\python26\lib\site-packages\myhdl\conversion\_analyze.py", line 758, i
n visit_Name
    self.setName(node)
  File "C:\python26\lib\site-packages\myhdl\conversion\_analyze.py", line 783, i
n setName
    self.raiseError(node, _error.UnboundLocal, n)
  File "C:\python26\lib\site-packages\myhdl\conversion\_misc.py", line 150, in r
aiseError
    raise ConversionError(kind, msg, info)
myhdl.ConversionError: in file sync_module.py, line 49:
    Not supported: Augmented signal assignment

I think this is unnecessary. It would be better if MyHDL only showed
you the last part. Perhaps there could be a "verbose" or "debug" mode
that could be used to show the whole thing in those (rare?) cases in
which it were necessary to debug the problem (which I guess would only
be necessary when you hit a bug on MyHDL itself). That is, it'd be
nice if this is what you got:

C:\myhdl_test>python sync_module.py
myhdl.ConversionError: in file sync_module.py, line 49:
    Not supported: Augmented signal assignment

2. I was surprised that that you cannot use the "+=" operator on
synthesizable code. Could't MyHDL convert:

~~~
s_2pps_counter.next += 2
~~~

into:

~~~
s_2pps_counter.next =  s_2pps_counter + 2
~~~
?

3. The error that you get when you forget to assign to the "next"
property of a signal is a bit weird. You get:

    Local variable may be referenced before assignment: s_2pps_counter

It is kind of obvious on hindsight but it took me a little while to
understand what the error was.

4. I don't see a way to set signal attributes that can be passed along
to the synthesizer (e.g. to specify that a memory should be
implemented as a block ram, etc). I believe someone (Jan?) told me
about this a while ago on this list but I cannot find the original
email on my inbox, sorry!

5. This may be a wacky idea, but perhaps MyHDL could show its strengh
over VHDL by making it easier to go to the "next" state on a state
machine. Currently (both on VHDL and MyHDL) you must explicitly set
next state on a state machine, even though this often means just going
to the "next" state on the state list (this is particularly true for
pipelined designs).

It would be cool (and something that VHDL cannot do) if enums had a
"next()" or "nextstate()" method that gave you the "next" state on the
state list. That is, if you had:

t_state = enum('INIT', 'WAIT', 'WORK')

Then you could do:

if state == t_state.INIT:
    # initalize stuff
    state.next = state.nextstate() # which would return t_state.WAIT
elif state == t_state.WAIT:
    # wait for something to happen, then:
    state.next = state.nextstate()
else:
    # do some work, then
    state.next = t_state.WAIT
    # You could mix the use of nextstate() with regular state jumps.
    # Here state.nextstate() would have returned INIT (or raise an error?)
    # so it would not make sense to jump to it.

This could make it simpler to introduce new intermediate states
without having to modify most of your existing code. On the other hand
it may be error prone... As I said, this is just an idea.

In VHDL and even on MyHDL you can do this today if you use a numeric
value rather than an actual enum, but then you lose the readability of
the "if/elif" clauses.


This is all I got so far.

Cheers,

Angel

[myhdl-list] Some comments on the VHDL code that MyHDL generates

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

In my quest to somehow start using MyHDL for my work, I've been
playing around with it, trying to create a small module in MyHDL from
scratch.

Since Christopher Felton suggested that I may be able to generate VHDL
in a way that my colleagues would not even notice, I created a small,
simple module and looked into the VHDL code that MyHDL generates.

My first impression is that the code is in fact quite similar to what
I would have written, which is nice. However I have a few comments:

1. "type" definitions are not properly indented. For example:
    The following MyHDL:

~~~
t_State = enum('INIT', 'WORKING')
~~~

becomes the following VHDL:

~~~
package pck_sync_module is

    type t_enum_t_State_1 is (
    INIT,
    WORKING
);

end package pck_sync_module;
~~~

Here you can see that the lines below the type keyword itself
(starting with "INIT") are not properly indented.
Instead it should be (IMHO):

~~~
package pck_sync_module is

    type t_enum_t_State_1 is (
        INIT,
        WORKING
    );
~~~

2. I prefer to have the declarations between the "architecture" header
and the begin keyword to be indented. I also prefer to indent the
architecture contents (everything between begin/end). This is nothing
major, and obviously open to debate, but I think it looks clearer. For
example, I'd prefer:

~~~
architecture MyHDL of sync_module is

    signal s_2pps_counter: unsigned(2 downto 0);
    signal pulse_sync: std_logic;

begin
~~~

rather than the current:

~~~
architecture MyHDL of sync_module is

signal s_2pps_counter: unsigned(2 downto 0);
signal pulse_sync: std_logic;

begin
~~~

3. For some reason MyHDL added 3 empty lines between the architecture
"begin" and the first line of code in it:

~~~
architecture MyHDL of sync_module is

signal s_2pps_counter: unsigned(2 downto 0);
signal pulse_sync: std_logic;
signal first_pulse: std_logic;
signal pulse_state: t_enum_t_State_1;

begin



-- Main process
SYNC_MODULE_P_PULSE: process (clk, rst) is
    variable pulse_state3: t_enum_t_State_1;
begin
    if (rst = '1') then
~~~

See the 3 blank lines betwen begin and the first comment. I would
think that one single blank would be enough.

4. I tried to use docstrings to add comments to the generated VHDL, so
that if someone where to inspect it it would be easier to understand
without needing to go to my source MyHDL code. This works in most
cases but there are a few things that could be improved (IMHO) and
some things that I was just not able to do:

    4.1. If I add a docstring to a function that contains an @always
block, MyHDL generates a corresponding "top entity". I expected to see
the docstring above the entity declaration. Instead MyHDL places the
comment between the entity declaration and the architecture
declaration, which I think it is a bit weird. I'd rather see the
documentation as close to the top of the file as possible (i.e. right
above the entity keyword, so that I can document it).

    4.2. I am unable to use a docstring to comment an enum declaration
(or any other signal declaration for that matter). This seems to be
due to the fact that this is done outside of the instance generators.
I think this is important, particularly for enums which are used for
state machines. Maybe all MyHDL objects (signals, intbv, etc) could
have a "comment" or "doc" field that you could set to include some
info about them on the generated VHDL / Verilog code?

    4.3. Is does not seem possible to add a "top level" file comment
via a docstring. I guess this is not very important right now since
there is not a one to one mapping between MyHDL .py files and the
generated .vhd file.

Please note that this is in no way a criticism of MyHDL. I know that
the main goal of MyHDL is not to generate human readable VHDL code.
However I think these small details could improve the generated code
substantially. Items 1 to 3 could be fixed on the user's end by
running the generated code through an automated VHDL indenter tool but
unfortunately I don't know of any good, free indenter that is also
easy to automate (perhaps emacs in batch mode?).

I have some more comments which are not related to the actual code
that MyHDL generates but I'll leave that for another email.

Cheers,

Angel

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

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

Hi again Chris,

thank you for your replies. See my comments below.

On Tue, Oct 9, 2012 at 8:07 PM, Christopher Felton
<chr...@gm...> wrote:
> On 10/4/2012 4:02 PM, Angel Ezquerra wrote:
>> Chris,
>>
>> Sorry it took me so long to get back to you. I've been really busy recently.
>>
>> First of all, thanks _a lot_ for taking the time to go through my concerns
>> so carefully. I really appreciate it.
>>
>> See some replies below...
>>
>> On Fri, Sep 28, 2012 at 3:12 PM, Christopher Felton <chr...@gm...>
>> wrote:
>>> On 9/28/2012 7:31 AM, Angel Ezquerra wrote:
>>>> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton
[...]
>>> 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.
>>
>> Could you detail what you mean by it "just takes a little more work"?
>
> Just that, you will need to convert each piece separately
> and merge them together.  Most of this can be automated
> (I believe).
>
> I had a rare case where I wanted to preserve hierarchy
> this is how I did it:
>
>         toVerilog(submodule, sigs, params)
>         # move to a new filename with params in the name

Sorry, maybe I'm a bit thick but I don't know what you mean by "move
to a new filename with params in the name"

>         submodule.verilog_instance = 'SUB1'
>         toVerilog(module, sigs, params)
>
> Where "module" instantiates 'submodule".  This will stub
> out "submodule" in module.  It is a little more work
> but not bad.  I had to add extra to the submodule
>
>         def submodule(...):
>            if hasattr(submodule, "verilog_instance"):
>                out1.driven = 'wire'
>                out2.driven = 'wire'
>                # etc

I don't know what "verilog_instance" does. I guess there is an
equivalent "vhdl_instance"? I looked for it on google but I did not
get any useful results. I also don't know why you need to set the
"driven" attribute.

I feel as if these questions are very basic and I should know them...
Is there some documentation on these features that I missed?

> If you had a design that is more complicated you could
> automate the first part.  You still would need to add
> the output definition in the module (submodule) being
> stubbed.  The nice thing about the above example, every
> thing will be wired up automatically.
>
> Note: I think Jan indicated the verilog_instance might
> need some work, use with caution.  I have used it
> without issue.

As I said I don't really know what these do so I don't think I could
use them, even cautiously :-> It still seems a bit too complicated for
my taste though.

Anyway, since this process seems easy to automate (I can't really
tell, since I don't really understand it), the obvious question is why
not make MyHDL itself automate it for us? That should put to rest the
question of generating hierarchical VHDL or Verilog code which seems
to crop up regularly on this list and on other online discussions
about MyHDL!


>> My ideal workflow would be to be able to add a decorator to some function
>> which would mark a file as describing an entity, which would group all
>> processes defined within it as part of that entity, and which would put
>> that entity on its own file.
>>
>> I think a "large" VHDL is an issue mostly because it would make it much
>> harder to debug using a regular VHDL simulator (e.g. modelsim) and adding
>> debug signals to a chipscope (Xilinx' in FPGA logic analyzer).
>
> This hasn't been my experience, I have an all MyHDL FPGA
> design I use to interface to our mixed-signal ICs (ICs
> also utilize MyHDL).  I use SignalTap frequently and it
> doesn't cause me much heart-ache.

Glad to know that. Maybe my intuition is wrong then... Still I
anticipate that you would still need to look into the generated VHDL
from time to time, possibly using (the terrible) ISE editor. In there
you'd see a single entity on the hierarchy view. I'd definitely prefer
to get a proper hierarchy in there instead.

>> Additionally, some synthesizers (XST for example) give you options to
>> control how optimizations and routing are handling across entity
>> boundaries. I am by no means an expert of this though. This is just advice
>> I've gotten from more experienced designers than I am.
>
> Not sure what the point is or the question you might
> be asking?  If you describe your design with a lot of
> hierarchy it is often beneficial, from a resource /
> performance point of view, to optimize across boundaries.
> But this breaks the structure and tools like ChipScope
> and SignalTap might be more difficult to work with
> (not much different than MyHDL flattening).
>
> An interesting case study would be to record the
> synthesis results between a hierarchical design,
> optimize across,and a MyHDL flattened design.

That could be interesting although given that Xilinx XST will
sometimes give you a different result when you implement the same code
twice I would not put that much faith on the comparison results...
Sometimes I feel that the Xilinx uses the position of the stars and
the phase of the moon to decide how to synthesize their FPGAs :-P

>> I just know that on a somewhat conservative development team it would be
>> way easier to add to a project a few files that have been automatically
>> generated via MyHDL than adding a single, big, flat file. I know that I
>> would face much more resistance with the single flat file than I would
>> otherwise. Given that I am not the most experienced FW developer in our
>> team it is uncertain that I'd be able to convince the most expert designers
>> that this is not a problem.
>>
>> This is probably a matter of perception, but I am quite sure that this
>> would be a big point against MyHDL.
>
> I think I might not be following you between "module"
> and "files".  From my perspective, if you had a new module
> that you needed to add, you could implement it in MyHDL
> and you would have /one/ new file to add to the design.
> Even if the module had many layers of hierarchy, and the
> one new file would be minimal impact to the existing flow.

Now I am not sure that I understand you. By module I mean a VHDL
entity and by file I mean, well, a file :-)

The issue I state is that adding a _single_, big, MyHDL generated VHDL
file to an existing VHDL project would be a problem. The problem is
not technical (or at least not mainly technical) but "social". I think
that when working on a project with multiple designers they would not
easily accept me adding a single file that implemented a significant
part of the design particularly if they knew that the file had been
automatically generated. They would ask me to "modularize" my
contribution. According to what you said above that is something that
can be done but it requires (unnecessary?) extra work with the current
version of MyHDL.

In my experience many FW designers are surprisingly risk averse and
not prone to try new design tools and approaches. That is an
unfortunate barrier to entry that MyHDL must go through.

If MyHDL let me group part of my MyHDL design in entities or packages,
which were saved into separate files when generating the VHDL or
Verilog code, this problem would be gone. IMHO this would make it much
easier ("socially") to introduce VHDL into an existing, VHDL or
Verilog based, project.

It may seem that I am blowing this issue out of proportion, but I know
the people I've worked with and I'm pretty sure these concerns are
real.

Cheers,

Angel

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

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

On 10/4/2012 4:02 PM, Angel Ezquerra wrote:
> Chris,
>
> Sorry it took me so long to get back to you. I've been really busy recently.
>
> First of all, thanks _a lot_ for taking the time to go through my concerns
> so carefully. I really appreciate it.
>
> See some replies below...
>
> On Fri, Sep 28, 2012 at 3:12 PM, Christopher Felton <chr...@gm...>
> wrote:
>> 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.
>
> Could you detail what you mean by it "just takes a little more work"?

Just that, you will need to convert each piece separately
and merge them together.  Most of this can be automated
(I believe).

I had a rare case where I wanted to preserve hierarchy
this is how I did it:

        toVerilog(submodule, sigs, params)
        # move to a new filename with params in the name
        submodule.verilog_instance = 'SUB1'
        toVerilog(module, sigs, params)

Where "module" instantiates 'submodule".  This will stub
out "submodule" in module.  It is a little more work
but not bad.  I had to add extra to the submodule

        def submodule(...):
           if hasattr(submodule, "verilog_instance"):
               out1.driven = 'wire'
               out2.driven = 'wire'
               # etc

If you had a design that is more complicated you could
automate the first part.  You still would need to add
the output definition in the module (submodule) being
stubbed.  The nice thing about the above example, every
thing will be wired up automatically.

Note: I think Jan indicated the verilog_instance might
need some work, use with caution.  I have used it
without issue.

> My ideal workflow would be to be able to add a decorator to some function
> which would mark a file as describing an entity, which would group all
> processes defined within it as part of that entity, and which would put
> that entity on its own file.
>
> I think a "large" VHDL is an issue mostly because it would make it much
> harder to debug using a regular VHDL simulator (e.g. modelsim) and adding
> debug signals to a chipscope (Xilinx' in FPGA logic analyzer).

This hasn't been my experience, I have an all MyHDL FPGA
design I use to interface to our mixed-signal ICs (ICs
also utilize MyHDL).  I use SignalTap frequently and it
doesn't cause me much heart-ache.

>
> Additionally, some synthesizers (XST for example) give you options to
> control how optimizations and routing are handling across entity
> boundaries. I am by no means an expert of this though. This is just advice
> I've gotten from more experienced designers than I am.

Not sure what the point is or the question you might
be asking?  If you describe your design with a lot of
hierarchy it is often beneficial, from a resource /
performance point of view, to optimize across boundaries.
But this breaks the structure and tools like ChipScope
and SignalTap might be more difficult to work with
(not much different than MyHDL flattening).

An interesting case study would be to record the
synthesis results between a hierarchical design,
optimize across,and a MyHDL flattened design.

>
> I just know that on a somewhat conservative development team it would be
> way easier to add to a project a few files that have been automatically
> generated via MyHDL than adding a single, big, flat file. I know that I
> would face much more resistance with the single flat file than I would
> otherwise. Given that I am not the most experienced FW developer in our
> team it is uncertain that I'd be able to convince the most expert designers
> that this is not a problem.
>
> This is probably a matter of perception, but I am quite sure that this
> would be a big point against MyHDL.

I think I might not be following you between "module"
and "files".  From my perspective, if you had a new module
that you needed to add, you could implement it in MyHDL
and you would have /one/ new file to add to the design.
Even if the module had many layers of hierarchy, and the
one new file would be minimal impact to the existing flow.


>
>>>> 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.
>
> Again, would you mind detailing (or linking to some wiki or post) some
> examples of what could be achieved? I believe I can imagine what we could
> do, mostly mixing some cool python modules such as matplotlib with our test
> benches, but some concrete examples would be nice.
>
> Cheers,
>
> Angel
>

Re: [myhdl-list] Cypress PSoC5

[Norbo <Nor...@gm...>]

just tried to find out how much general purpose Flip-Flops a PSoC5 has, if  
this makes sense.
looks like 24 UDBs version has 192 Flip-Flops. (Quelle:  
http://www.cypress.com/?docID=39788 )
somewhat unrelated.

greetings Norbert


Am 09.10.2012, 03:05 Uhr, schrieb Bob Cunningham <fl...@gm...>:

> I've been interested in MyHDL for some time, but found the general  
> barrier to entry to programmable logic design to be a bit higher than I  
> had the time to climb.
>
> I just came across the Cypress PSoC5 (http://www.cypress.com/?id=2233),  
> basically an ARM M3 wrapped in a small FPGA.  The PSoC5 has a  
> development/configuration environment called PSoC Creator  
> (http://www.cypress.com/?rID=56745) that manages and configures a large  
> collection of typical uP peripheral cells. It also permits the user to  
> add Verilog peripherals of their own design.
>
> My thought (well, hope) is that the PSoC5 may be a near-ideal  
> environment not only for embedded SW folks like myself to get a friendly  
> taste of basic FPGA design, but also that it may be a terrific  
> environment for MyHDL, where the translation to "flat" Verilog wouldn't  
> be an issue.
>
> I'm interested in the PSoC5 in any case, since I'm tired of selecting  
> MCUs based on the specific number of specific kinds of on-board  
> interfaces and peripherals my system designs need.  The allure of "Any  
> function, on any pin, at any time" makes the elevated cost (~$20, about  
> 5x-10x commodity MCUs) worth it, especially for rush designs where  
> hardware needs to be fabricated before the low-level design is finished.
>
> Before plunging in, what is the view of the MyHDL community of the PSoC5  
> as a target for MyHDL education and development?
>
>
> Thanks,
>
> -BobC
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev


-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[myhdl-list] Cypress PSoC5

[Bob C. <fl...@gm...>]

I've been interested in MyHDL for some time, but found the general barrier to entry to programmable logic design to be a bit higher than I had the time to climb.

I just came across the Cypress PSoC5 (http://www.cypress.com/?id=2233), basically an ARM M3 wrapped in a small FPGA.  The PSoC5 has a development/configuration environment called PSoC Creator (http://www.cypress.com/?rID=56745) that manages and configures a large collection of typical uP peripheral cells. It also permits the user to add Verilog peripherals of their own design.

My thought (well, hope) is that the PSoC5 may be a near-ideal environment not only for embedded SW folks like myself to get a friendly taste of basic FPGA design, but also that it may be a terrific environment for MyHDL, where the translation to "flat" Verilog wouldn't be an issue.

I'm interested in the PSoC5 in any case, since I'm tired of selecting MCUs based on the specific number of specific kinds of on-board interfaces and peripherals my system designs need.  The allure of "Any function, on any pin, at any time" makes the elevated cost (~$20, about 5x-10x commodity MCUs) worth it, especially for rush designs where hardware needs to be fabricated before the low-level design is finished.

Before plunging in, what is the view of the MyHDL community of the PSoC5 as a target for MyHDL education and development?


Thanks,

-BobC

Re: [myhdl-list] gmane: MyHDL

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

On 10/4/12 3:09 PM, Christopher Felton wrote:
> I can't say I understand the connection between the
> gmane list and the sourceforge email list.  But it
> doesn't look like the gmane list is being updated?
>
> Regards,
> Chris
>

Looks like it is working now and I don't know why
(or how) the above message was sent twice?

.chris

[myhdl-list] gmane: MyHDL

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

I can't say I understand the connection between the
gmane list and the sourceforge email list.  But it
doesn't look like the gmane list is being updated?

Regards,
Chris

[myhdl-list] gmane: MyHDL

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

I can't say I understand the connection between the
gmane list and the sourceforge email list.  But it
doesn't look like the gmane list is being updated?

Regards,
Chris

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

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

Hi again Chris,

more replies to some of your advice below.

On Fri, Sep 28, 2012 at 3:23 PM, Christopher Felton <chr...@gm...>
wrote:
> <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.

Some of the IP cores that we use are quite complex (e.g. turbo-decoders).
We could stub them out as you suggest but it makes using MyHDL a little
less convenient.

Also, most Xilinx' cores use std_logic_vector for their interfaces. Would
that be a problem? How do you convert the native MyHDL intbv types into the
std_logic_vector required by the external IP cores?

BTW, it would be super-nice if you could somehow import a regular VHDL file
into MyHDL (e.g. calling some MyHDL function with the VHDL filename) and
that made MyHDL automatically aware of the corresponding entity (i.e. its
name, interface, etc). I don't know how realistic is that though :-)

>> 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).

Probably not hard but it complicates things further compared to our
existing workflow. Hence my "concern".

>> 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.

Recently I've started playing with the Vivado Simulator, which is Xilinx'
next generation simulator (which replaces ISim). I wonder if it supports
PLI/VPI/DPI/VHPI.

>> 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.

Did this happen when you were using MyHDL to drive some legacy HDL code? Do
you have some examples available?

>> 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.

What I mean is that you do not get to have a mixed MyHDL / VHDL "project"
where you can see all your modules on a hierarchy view (as you can on ISE
or Sigasi) and where you can double click on the module to open the
corresponding MyHDL file. This exists for plain VHDL and is quite nice.

I wonder if Jan can somehow convince the Sigasi guys to add MyHDL support
to their awesome editor... :-)

This is by no means a huge thing, but I having an integrated development
environment would be nice. Not having it is a (small) step backwards
compared to an all VHDL or all Verilog environment.

>> 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.

I already addressed this on my previous reply. My main concern is that
adding a big, flat, automatically generated VHDL file to our VHDL project
would be frown upon by the other designers.

Do you know something about web technologies? If you do I guess I could say
that what I would like to get from MyHDL, compared to VHDL, is akin to what
you get from CoffeeScript compared to JavaScript. That is, you get a much
nicer language which compiles to idiomatic JavaScript.

All this being said, it could seem that I see a lot of problems with using
MyHDL. That may be true but I see _a lot_ of potential benefits. That is
why I'm thinking hard about how to best minimize the drawbacks while
getting most of the benefits.

Cheers,

Angel

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

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

Chris,

Sorry it took me so long to get back to you. I've been really busy recently.

First of all, thanks _a lot_ for taking the time to go through my concerns
so carefully. I really appreciate it.

See some replies below...

On Fri, Sep 28, 2012 at 3:12 PM, Christopher Felton <chr...@gm...>
wrote:
> 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.

Could you detail what you mean by it "just takes a little more work"?
My ideal workflow would be to be able to add a decorator to some function
which would mark a file as describing an entity, which would group all
processes defined within it as part of that entity, and which would put
that entity on its own file.

I think a "large" VHDL is an issue mostly because it would make it much
harder to debug using a regular VHDL simulator (e.g. modelsim) and adding
debug signals to a chipscope (Xilinx' in FPGA logic analyzer).

Additionally, some synthesizers (XST for example) give you options to
control how optimizations and routing are handling across entity
boundaries. I am by no means an expert of this though. This is just advice
I've gotten from more experienced designers than I am.

I just know that on a somewhat conservative development team it would be
way easier to add to a project a few files that have been automatically
generated via MyHDL than adding a single, big, flat file. I know that I
would face much more resistance with the single flat file than I would
otherwise. Given that I am not the most experienced FW developer in our
team it is uncertain that I'd be able to convince the most expert designers
that this is not a problem.

This is probably a matter of perception, but I am quite sure that this
would be a big point against 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?
>>
>> 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.

Again, would you mind detailing (or linking to some wiki or post) some
examples of what could be achieved? I believe I can imagine what we could
do, mostly mixing some cool python modules such as matplotlib with our test
benches, but some concrete examples would be nice.

Cheers,

Angel

Re: [myhdl-list] intb min, max confusion

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

>
>
> On Thu, Oct 4, 2012 at 1:43 AM, Angel Ezquerra <ang...@gm...> wrote:
> I think the comparison to range is not totally accurate. The docstring
> of the range function is as follows:
>
>     range([start,] stop[, step]) -> list of integers
>
> That is, there is no "max" parameter, but a "stop" parameter.
> I'm not saying the current behavior should be changed, just that
> perhaps the parameter name is a bit misleading.
>
> Cheers,
>
> Angel

Ok, /range/ might not have been the best example.  More
information on intbv can be found in the manual.

http://www.myhdl.org/doc/current/manual/intro.html#bit-oriented-operations

http://www.myhdl.org/doc/current/manual/reference.html#myhdl.intbv

Regards,
Chris

>
>
> On Thu, Oct 4, 2012 at 4:48 AM, Christopher Felton
> <chr...@gm...> wrote:
>> You would simply use MAXV = 2**NBITS.  This is common in
>> Python (there is a term for it).  Example if you use "range(3)"
>> the list you get is 0,1,2.  It doesn't include the 3 only up to.
>> The intbv works the same, max=N, the max value will be
>> N-1.  Even though a 3bit value was created "len(x) == 3" the max
>> value was specified and is checked during simulation.
>>
>> Hope that helps,
>> Chris
>>
>>
>> On Wed, Oct 3, 2012 at 6:53 PM, garyr <ga...@fi...> wrote:
>>>
>>> It appears to me that the max limit on an intbv value should be > (greater
>>> than) rather than >= (greater than or equal). In the following code, isn't
>>> 3
>>> a valid value for a 3-bit signal?
>>>
<snip>

Re: [myhdl-list] intb min, max confusion

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

I think the comparison to range is not totally accurate. The docstring
of the range function is as follows:

    range([start,] stop[, step]) -> list of integers

That is, there is no "max" parameter, but a "stop" parameter.
I'm not saying the current behavior should be changed, just that
perhaps the parameter name is a bit misleading.

Cheers,

Angel


On Thu, Oct 4, 2012 at 4:48 AM, Christopher Felton
<chr...@gm...> wrote:
> You would simply use MAXV = 2**NBITS.  This is common in
> Python (there is a term for it).  Example if you use "range(3)"
> the list you get is 0,1,2.  It doesn't include the 3 only up to.
> The intbv works the same, max=N, the max value will be
> N-1.  Even though a 3bit value was created "len(x) == 3" the max
> value was specified and is checked during simulation.
>
> Hope that helps,
> Chris
>
>
> On Wed, Oct 3, 2012 at 6:53 PM, garyr <ga...@fi...> wrote:
>>
>> It appears to me that the max limit on an intbv value should be > (greater
>> than) rather than >= (greater than or equal). In the following code, isn't
>> 3
>> a valid value for a 3-bit signal?
>>
>> from myhdl import *
>> def testBench():
>>     @instance
>>     def stimulus():
>>         NBITS = 3
>>         MAXV = 2**(NBITS-1)
>>         min = -MAXV
>>         max = MAXV-1
>>         print 'NBITS=%d   min=%d   max=%d' % (NBITS, min, max)
>>         x = Signal(intbv(0, min=min, max=max))
>>         x.next = min
>>         yield delay(1)
>>         print 'x', x
>>         x.next = max
>>         yield delay(1)
>>         print 'x', x
>>         raise StopSimulation
>>     return instances()
>> tb = testBench()
>> Simulation(tb).run(200)
>> ======================================
>> >python intbTest.py
>> NBITS=3   min=-4   max=3
>> x -4
>> Traceback (most recent call last):
>>   File "intbTest.py", line 22, in <module>
>>     Simulation(tb).run(200)
>>   File "C:\Python26\lib\site-packages\myhdl\_Simulation.py", line 132, in
>> run
>>     waiter.next(waiters, actives, exc)
>>   File "C:\Python26\lib\site-packages\myhdl\_Waiter.py", line 128, in next
>>     clause = self.generator.next()
>>   File "intbTest.py", line 15, in stimulus
>>     x.next = max
>>   File "C:\Python26\lib\site-packages\myhdl\_Signal.py", line 200, in
>> _set_next
>>     self._setNextVal(val)
>>   File "C:\Python26\lib\site-packages\myhdl\_Signal.py", line 266, in
>> _setNextIntbv
>>     self._next._checkBounds()
>>   File "C:\Python26\lib\site-packages\myhdl\_intbv.py", line 79, in
>> _checkBounds
>>     (self._val, self._max))
>> ValueError: intbv value 3 >= maximum 3
>> >Exit code: 1
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] intb min, max confusion

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

You would simply use MAXV = 2**NBITS.  This is common in
Python (there is a term for it).  Example if you use "range(3)"
the list you get is 0,1,2.  It doesn't include the 3 only up to.
The intbv works the same, max=N, the max value will be
N-1.  Even though a 3bit value was created "len(x) == 3" the max
value was specified and is checked during simulation.

Hope that helps,
Chris

On Wed, Oct 3, 2012 at 6:53 PM, garyr <ga...@fi...> wrote:

> It appears to me that the max limit on an intbv value should be > (greater
> than) rather than >= (greater than or equal). In the following code, isn't
> 3
> a valid value for a 3-bit signal?
>
> from myhdl import *
> def testBench():
>     @instance
>     def stimulus():
>         NBITS = 3
>         MAXV = 2**(NBITS-1)
>         min = -MAXV
>         max = MAXV-1
>         print 'NBITS=%d   min=%d   max=%d' % (NBITS, min, max)
>         x = Signal(intbv(0, min=min, max=max))
>         x.next = min
>         yield delay(1)
>         print 'x', x
>         x.next = max
>         yield delay(1)
>         print 'x', x
>         raise StopSimulation
>     return instances()
> tb = testBench()
> Simulation(tb).run(200)
> ======================================
> >python intbTest.py
> NBITS=3   min=-4   max=3
> x -4
> Traceback (most recent call last):
>   File "intbTest.py", line 22, in <module>
>     Simulation(tb).run(200)
>   File "C:\Python26\lib\site-packages\myhdl\_Simulation.py", line 132, in
> run
>     waiter.next(waiters, actives, exc)
>   File "C:\Python26\lib\site-packages\myhdl\_Waiter.py", line 128, in next
>     clause = self.generator.next()
>   File "intbTest.py", line 15, in stimulus
>     x.next = max
>   File "C:\Python26\lib\site-packages\myhdl\_Signal.py", line 200, in
> _set_next
>     self._setNextVal(val)
>   File "C:\Python26\lib\site-packages\myhdl\_Signal.py", line 266, in
> _setNextIntbv
>     self._next._checkBounds()
>   File "C:\Python26\lib\site-packages\myhdl\_intbv.py", line 79, in
> _checkBounds
>     (self._val, self._max))
> ValueError: intbv value 3 >= maximum 3
> >Exit code: 1
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] intb min, max confusion

[garyr <ga...@fi...>]

It appears to me that the max limit on an intbv value should be > (greater
than) rather than >= (greater than or equal). In the following code, isn't 3
a valid value for a 3-bit signal?

from myhdl import *
def testBench():
    @instance
    def stimulus():
        NBITS = 3
        MAXV = 2**(NBITS-1)
        min = -MAXV
        max = MAXV-1
        print 'NBITS=%d   min=%d   max=%d' % (NBITS, min, max)
        x = Signal(intbv(0, min=min, max=max))
        x.next = min
        yield delay(1)
        print 'x', x
        x.next = max
        yield delay(1)
        print 'x', x
        raise StopSimulation
    return instances()
tb = testBench()
Simulation(tb).run(200)
======================================
>python intbTest.py
NBITS=3   min=-4   max=3
x -4
Traceback (most recent call last):
  File "intbTest.py", line 22, in <module>
    Simulation(tb).run(200)
  File "C:\Python26\lib\site-packages\myhdl\_Simulation.py", line 132, in
run
    waiter.next(waiters, actives, exc)
  File "C:\Python26\lib\site-packages\myhdl\_Waiter.py", line 128, in next
    clause = self.generator.next()
  File "intbTest.py", line 15, in stimulus
    x.next = max
  File "C:\Python26\lib\site-packages\myhdl\_Signal.py", line 200, in
_set_next
    self._setNextVal(val)
  File "C:\Python26\lib\site-packages\myhdl\_Signal.py", line 266, in
_setNextIntbv
    self._next._checkBounds()
  File "C:\Python26\lib\site-packages\myhdl\_intbv.py", line 79, in
_checkBounds
    (self._val, self._max))
ValueError: intbv value 3 >= maximum 3
>Exit code: 1