myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Deterministic output of toVHDL

[Knut E. <kn...@3d...>]

Hi all,

I would like the output of toVHDL to be deterministic, meaning the 
generated .vhd files should be identical when nothing has changed 
between runs. At least two things are non-deterministic in default branch:

1) The timestamp is included in output files.
2) The order of enum typedefs in package declarations is random.

1) is easily fixed by monkey-patching datetime, but this is not an ideal 
solution.

2) can be fixed by sorting the enum typedefs by name before emitting 
them. (I have a patch if interested)

Any thoughts on this?

Regards,
-- 
Knut Eldhuset

Re: [myhdl-list] Proposal: better support for hierarchy and user-defined code

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

>
> Angel Ezquerra wrote:
>
> > Jan, if you don't mind could you explain a bit further
> > whether there are technical reasons to not replicate the
> > python function hierarchy when you generate the VHDL or
> > Verilog code? That is, why use this 2-step approach and
> > not simply generate hierarchy code by default? Are there
> > some hidden drawbacks that I don't understand? I am still
> > trying to fully understand how myhdl conversion works, so
> > maybe there is something obvious that I did not get!
>
> The most important reason is not technical.
>
> The idea behind conversion is to use Verilog or VHDL as
> back-end languages that for advanced MyHDL users eventually
> disappear in the process - just some automated step in
> a Makefile. Having a single file instead of a whole bunch
> of files depending on the status of your design, just
> makes this a tad more transparent.
>
> (I realize that I'm working hard against this with
> nicely formatted code, and now the documentation forwarding,
> but still. It's the difference between attracting new
> users and the eventual goal.)
>
> Hierarchy is useful for human designers and debuggers,
> but up to several 100Ks of gates, not necessarily to tools.
> (Actually one well-known way to get better synthesis is by
> removing more hierarchical boundaries.)
>
> That having said, flattening out the hierarchy is really
> the simplest and most straightforward way to get the
> output, so this works in the same direction.

OK, thank you for the explanation. It would be nice to have the option to
generate some fully hierarchical code based on the python code hierarchy,
but I understand why this would not be your primary goal with MyHDL. As you
say you seem to be giving small steps in that direction. Hopefully one day
you'll find out that you've walked the whole way there! :-)


> > Sorry, I do not get exactly what would be the use case
> > for the "verilog_instance" attribute.
>
> Semi-automatic hierarchy. Just give a name and you get
> the instantiation, instead of having to write the instantiation
> template yourself. Note that this gives you fine-grained
> control of where you want to put the hierarchical boundaries.

I'd be nice if you could provide an example of how to do this. I'm still a
bit confused on how you'd use this feature...

Thanks,

Angel

Re: [myhdl-list] hg rev 1105 : better support for mapping to case statements

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

Christopher Felton wrote:
> I apologize for the lack of information up front.  I updated to the 
> latest tip to check out some of the changes.  I ran into an issue.
> 
> I believe it is related to the changes checked into revision 1105 
> (better support for mapping to case statements).  I reverted back to 
> 1104 and the issue didn't occur.
> 
> The issue/error was an invalid casez statement (?).  At least Icarus 
> determined it invalid "error: Unable to bind wire/reg/memory `False' in".
> 
> The previous versions converted the code to if/else statements with no 
> errors.  The failing code is part of the project posted 
> http://www.myhdl.org/doku.php/users:cfelton:projects:usbp .
> 
> When I have a little more time I can try and sandbox the problem to 
> narrow the issue and/or provide an easy method to reproduce the problem.

With the move to ast, I've run into all kinds of problems just
to reproduce the old behavior to map if then else's to case.

In additon, I have tried to make it more general so that the
mappping also happens in other cases than only with enum's.
So there may still be issues. If you find a bug, a small
example that can become part of the test suite would
be very welcome.

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Error in user defined VHDL code should show line, and column for error, rather than &amp; amp; amp; amp; quot; index&amp; amp; amp; amp; quot;

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> 
> Angel Ezquerra wrote:
> > Jan Decaluwe <jan <at> jandecaluwe.com> writes:
> >> Ok, what we could do is specify that the code for the
> >> new function attribute 'vhdl_code' is actually such a
> >> template, which would force you to help me debugging
> >> those 
> >>
> >> If that's OK, I'll put this change on top of the stack.
> >>
> >> Jan
> >>
> > 
> > OK! Let me know what the change is done! 
> 
> It's out.
> 

The simple tests that I've performed work fine!
This new syntax, while similar, it is also easier
to understand than the old method.

One comment that I have, and which is related to
this thread, is that if you make a mistake with
the name of one of the ports that you want to link
to your VHDL code, you get the following error:

  myhdl.ToVHDLError: in file dsp48e.py,
  function dsp48e starting on line 3:
  Error in user defined VHDL code:
  <type 'exceptions.KeyError'>: 'CLK'

(Note that I had to error message a bit to 
work around gmane's 80 character line length
restriction).

In this case I purposely tried to use a signal named 
"CLK" while the actual signal was named "clk".

The error message is the same that you would get
when using the old "__vhdl__" magic variable.
Fortunately, this seems to be the only error
that you could get when using templates, while
when using the old method you could also get
errors with the format of the format string, etc.

This error makes sense if you know what
MyHDL is doing in the background (which is to
interpolate a string using the namespace dictionary).
However, if you don't what MyHDL is doing
then I think that the error is quite cryptic.
It tells you that there is an error related 
to "CLK", but what is a "KeyError" and what 
does it have to do with anything?

Ideally it would be much better if MyHDL told you
that the unknown 'CLK' signal was used on the
user-defined code string.

Something else that I have noticed is that
MyHDL adds 5 empty lines between the "begin"
keyword of the architecture and the beginning
of the user-defined code. This is obviously a
very minor thing, but I don't know if this
was there before of if it has been introduced
by the new template-based code.

Cheers,

Angel

Re: [myhdl-list] Error in user defined VHDL code should show line, and column for error, rather than &amp; amp; amp; quot; index&amp; amp; amp; quot;

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

Angel Ezquerra wrote:
> Jan Decaluwe <jan <at> jandecaluwe.com> writes:
>> Ok, what we could do is specify that the code for the
>> new function attribute 'vhdl_code' is actually such a
>> template, which would force you to help me debugging
>> those 
>>
>> If that's OK, I'll put this change on top of the stack.
>>
>> Jan
>>
> 
> OK! Let me know what the change is done! :-)

It's out.

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] hg rev 1105 : better support for mapping to case statements

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

I apologize for the lack of information up front.  I updated to the 
latest tip to check out some of the changes.  I ran into an issue.

I believe it is related to the changes checked into revision 1105 
(better support for mapping to case statements).  I reverted back to 
1104 and the issue didn't occur.

The issue/error was an invalid casez statement (?).  At least Icarus 
determined it invalid "error: Unable to bind wire/reg/memory `False' in".

The previous versions converted the code to if/else statements with no 
errors.  The failing code is part of the project posted 
http://www.myhdl.org/doku.php/users:cfelton:projects:usbp .

When I have a little more time I can try and sandbox the problem to 
narrow the issue and/or provide an easy method to reproduce the problem.

.chris

Re: [myhdl-list] Error in user defined VHDL code should show line, and column for error, rather than &amp; amp; amp; quot; index&amp; amp; amp; quot;

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:
> Ok, what we could do is specify that the code for the
> new function attribute 'vhdl_code' is actually such a
> template, which would force you to help me debugging
> those 
> 
> If that's OK, I'll put this change on top of the stack.
> 
> Jan
> 

OK! Let me know what the change is done! :-)

Angel

Re: [myhdl-list] Error in user defined VHDL code&amp; amp; quot; should show line, and column for error, rather than &amp; amp; quot; index&amp; amp; quot;

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

Angel Ezquerra wrote:

> 
> I had a quick look at the string.Template library, and it is
> very simple and easy to use. It seems that it would cover the
> regular use case, which is to connect signals to VHDL ports,
> very well. It also seems that it would be less error prone than
> direct string formatting.
> 
> Since you could still generate the template string itself 
> dynamically, I don't think that changing to the template 
> library would be any less flexible than the current method.
> So I cannot see any drawbacks to your proposal.

Ok, what we could do is specify that the code for the
new function attribute 'vhdl_code' is actually such a
template, which would force you to help me debugging
those :-)

If that's OK, I'll put this change on top of the stack.

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Proposal: better support for hierarchy and user-defined code

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

Angel Ezquerra wrote:

> Jan, if you don't mind could you explain a bit further
> whether there are technical reasons to not replicate the 
> python function hierarchy when you generate the VHDL or
> Verilog code? That is, why use this 2-step approach and
> not simply generate hierarchy code by default? Are there
> some hidden drawbacks that I don't understand? I am still
> trying to fully understand how myhdl conversion works, so
> maybe there is something obvious that I did not get!

The most important reason is not technical.

The idea behind conversion is to use Verilog or VHDL as 
back-end languages that for advanced MyHDL users eventually
disappear in the process - just some automated step in
a Makefile. Having a single file instead of a whole bunch
of files depending on the status of your design, just
makes this a tad more transparent.

(I realize that I'm working hard against this with
nicely formatted code, and now the documentation forwarding,
but still. It's the difference between attracting new
users and the eventual goal.)

Hierarchy is useful for human designers and debuggers,
but up to several 100Ks of gates, not necessarily to tools.
(Actually one well-known way to get better synthesis is by
removing more hierarchical boundaries.)

That having said, flattening out the hierarchy is really
the simplest and most straightforward way to get the
output, so this works in the same direction.

> Sorry, I do not get exactly what would be the use case
> for the "verilog_instance" attribute.

Semi-automatic hierarchy. Just give a name and you get
the instantiation, instead of having to write the instantiation
template yourself. Note that this gives you fine-grained
control of where you want to put the hierarchical boundaries.

> I think that this attribute based approach is a very 
> promising. Could this be used to allow you to define 
> libraries that must be used when using user generated code?
> 
> What I mean is that you could have another pair of attribures,
> mamed "vhdl_libraries" and "verilog_libraries", for example, 
> which you could use to define some libraries that you must add
> when you generate the vhdl or verilog code (as discussed in
> one of the recent threads?). Or maybe this could be used for
> something even more generic (i.e. not only for library 
> declarations).

All possible, but let's first see if this is really the
best way to handle technology libraries, see other threads.

Jan


-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Error in user defined VHDL code&amp; amp; quot; should show line, and column for error, rather than &amp; amp; quot; index&amp; amp; quot;

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> 
> Angel Ezquerra wrote:
> 
> > 
> > As I said you _can_ find the error. That does not mean that it
> > is easy 
> > 
> > Jokes aside, not many editors support going straight to a string offset,
> > which makes this error message much less useful that it could be
> > in practice.
> 
> I repeat my suggestion to check whether templating instead of
> regular string processing would be an acceptable solution to you,
> which would enable us to simply reuse the vast amounts of
> templating work readily available.
> 
> Start with string.Template from the standard library, probably
> this is just find for our purposes.

I had a quick look at the string.Template library, and it is
very simple and easy to use. It seems that it would cover the
regular use case, which is to connect signals to VHDL ports,
very well. It also seems that it would be less error prone than
direct string formatting.

Since you could still generate the template string itself 
dynamically, I don't think that changing to the template 
library would be any less flexible than the current method.
So I cannot see any drawbacks to your proposal.

Angel

Re: [myhdl-list] Adding library declarations to your VHDL code

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

Angel Ezquerra wrote:
> Jan Decaluwe <jan <at> jandecaluwe.com> writes:
> 
>> Angel Ezquerra wrote:
>>> I am trying to make a myhdl block that will let me introduced a 
>>> Xilinx DSP48e block.
>>>
>>> In order to use and simulate this block you must add the following 
>>> library use
>>> declaration before the declaration of the entity that will use 
>>> the DSP48 block:
>>>
>>> Library UNISIM;
>>> use UNISIM.vcomponents.all;
>> Actually, before the architecture declaration I guess (so that the entity
>> could be kept technology-independent).
> 
> I was actually following Xilinx' advice. I am basically trying to create
> MyHDL wrappers for some of the macros and templates that are provided
> by Xilinx in their ISE Project Navigator tool. In those templates they say:
> 
>     --  Copy the following two statements and paste them before the
>     --  Entity declaration, unless they already exist.
> 
>     Library UNISIM;
>     use UNISIM.vcomponents.all;
>  
> I have never tried doing otherwise. You think that should work?

Per the vhdl standard, definitely. Don't know about Xilinx.


> > 
> Cheers,
> 
> Angel
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

>>> I have the following questions:
>>> - Is there a way to tell myhdl that a certain entity
>>>  requires a certain set of libraries?
>> Currently there is no option to add libraries to the output. Probably
>> this should be added as an attribute to toVHDL().
> 
> Do you mean that you would pass the libraries as an additional argument
> to ToVHDL? Or do you mean that there could be some additional magic 
> variable or attribute, similar to the current __vhdl__ "magic" variable 
> or to the recently proposed vhdl_code attribute (perhaps named
> __vhdl_libraries__ or something similar)? You would set that new attribute
> on the MyHDL source code, which would then be picked up by the ToVHDL() 
> function.

> I'd very much prefer the second option, since it would ensure that
> all dependencies of a certain component are specified right where you
> define that component. Also it would let you use different libraries
> for different entities.
> 
> Is that what you had in mind?

Both options you describe are possible.

What I probably would prefer is not having to tell MyHDL about
vendor libraries at all, but declare them as late as possible
in the user defined code of your technology dependent architecture.



>>> - I created a "dummy" entity that simply contains the DPS48E 
>>> instance
>>> declaration and maps the input ports to the DSP48E instance ports:
>>>
>>>    - Is that the right approach?
>> I think this could be a good way to isolate technology dependent
>> stuff as much as possible.
> 
> Nice. My idea is to create a myhdl.xilinx package. This package could
> have several subpackages like virtex6, virtex5, etc. To use any of
> the Xilinx specific blocks in a MyHDL design one would simply need
> to do "from myhdl.xilinx.dsp48 import multiplier" or
> "from myhdl.xilinx.cpld.bufg", etc. Device specific blocks
> (i.e. devices which are only found in virtex5, etc) could go
> into their own subpackages (I am still thinking about the details).
> 
> But before I can do that I must make sure that it is actually doable,
> so any advice or support on your end would be appreaciated.
> 
> 
>>>    - Is it possible to force the port types
>> If the conversion doesn't do it right, you can set the
>> signal.driven (documented in the manual) and the 
>> signal.read (undocumented I believe) attributes in
>> the module yourself, to infer the proper port type.
> 
> The MyHDL documentation for the "driven" attribute says that
> it can have two possible values: "reg" and "wire". The documentation
> only talks about verilog. Since I do not know much verilog
> but if I recall properly the difference is related to whether a
> variable is given its value by behavioural or structural code. In
> both cases MyHDL sets the port type to inout, so I guess it does
> not matter which one you use, right?

In fact it can be False, 'reg', or 'wire' and it should make
a difference on how a port is inferred. 

> On the other hand, what are the valid values for the "read" attribute?

False and True.

It it doesn't seem work, let's use small examples.

> 
> 
>>>    ? MyHDL seems to be creating them as
>>> "inout"
>> This would normally mean that you both drive and read a signal
>> in a module. (Note: Verilog support reading from output ports.)
> 
> Actually, I have realized that this was a problem with my code, not
> a MyHDL problem.
> 
> I was blindly following the example in the myhdl documentation page
> without really understanding it! In the example the "driven" attribute
> of the input port was being set to "wire". This made my clock port
> be declared as inout by the MyHDL conversion.
> 
>  
>>>    - Can I make some ports optional (and give them default values?
>>>    - Should I declare the generics (i.e. the "generic map" part 
>>>      as regular python function arguments?
>>>
>>> Sorry if these questions are very basic. I did not find (or 
>>> perhaps understand) the corresponding information on the 
>>> User-Defined code part of the MyHDL documentation.
>> I'm not aware of a standard systematic approach currently -
>> research more than welcome. The ideal approach may depend
>> on the case. MyHDL probably lacks some features, or documentation,
>> as discussed above, to support certain realistic use cases.
>> Also, there is the question where to put boundary of the
>> parametrization, more to Python, or more to VHDL (e.g. by
>> using multiple architectures.)
> 
> I am not sure what you are suggesting here. How do you propose
> to generate more than one architecture from MyHDL?

I don't. What I suggest is that you could control the architecture
specified in your user defined instantiation:

   dut: entity work.MyModule(Xilinx) -- or work.MyModule(Altera)

depending on parameters.

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] &amp; quot; Error in user defined VHDL code&amp; quot; should show line, and column for error, rather than &amp; quot; index&amp; quot;

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

Angel Ezquerra wrote:

> 
> As I said you _can_ find the error. That does not mean that it
> is easy :-)
> 
> Jokes aside, not many editors support going straight to a string offset,
> which makes this error message much less useful that it could be
> in practice.

I repeat my suggestion to check whether templating instead of
regular string processing would be an acceptable solution to you,
which would enable us to simply reuse the vast amounts of
templating work readily available.

Start with string.Template from the standard library, probably
this is just find for our purposes.

Jan


-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] namedtuple support for converter

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

ala...@sp... wrote:
> Hi,
> 
> I wonder how difficult it would be to support namedtuple in the converter?
> I use them extensively to emulate vhdl records.

At some point we need a solution for this type of functionality,
but I've not yet found the time to think extensively about it.
namedtuple is may be a good candidate.


-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] namedtuple support for converter

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

 <alain.peteut <at> space.unibe.ch> writes:

> 
> Hi,
> 
> I wonder how difficult it would be to support namedtuple in the converter?
> I use them extensively to emulate vhdl records.

Wouldn't it make more sense to use regular python dictionaries?
They are the usual way to emulate structs in python...

In any case, support for records would be nice. Does verilog
have an equivalent construct?

Angel

Re: [myhdl-list] Adding library declarations to your VHDL code

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> 
> Angel Ezquerra wrote:
> > I am trying to make a myhdl block that will let me introduced a 
> > Xilinx DSP48e block.
> > 
> > In order to use and simulate this block you must add the following 
> > library use
> > declaration before the declaration of the entity that will use 
> > the DSP48 block:
> > 
> > Library UNISIM;
> > use UNISIM.vcomponents.all;
> 
> Actually, before the architecture declaration I guess (so that the entity
> could be kept technology-independent).

I was actually following Xilinx' advice. I am basically trying to create
MyHDL wrappers for some of the macros and templates that are provided
by Xilinx in their ISE Project Navigator tool. In those templates they say:

    --  Copy the following two statements and paste them before the
    --  Entity declaration, unless they already exist.

    Library UNISIM;
    use UNISIM.vcomponents.all;
 
I have never tried doing otherwise. You think that should work?
 

> > I have the following questions:
> > - Is there a way to tell myhdl that a certain entity
> >  requires a certain set of libraries?
> 
> Currently there is no option to add libraries to the output. Probably
> this should be added as an attribute to toVHDL().

Do you mean that you would pass the libraries as an additional argument
to ToVHDL? Or do you mean that there could be some additional magic 
variable or attribute, similar to the current __vhdl__ "magic" variable 
or to the recently proposed vhdl_code attribute (perhaps named
__vhdl_libraries__ or something similar)? You would set that new attribute
on the MyHDL source code, which would then be picked up by the ToVHDL() 
function.

I'd very much prefer the second option, since it would ensure that
all dependencies of a certain component are specified right where you
define that component. Also it would let you use different libraries
for different entities.

Is that what you had in mind?


> > - I created a "dummy" entity that simply contains the DPS48E 
> > instance
> > declaration and maps the input ports to the DSP48E instance ports:
> > 
> >    - Is that the right approach?
> 
> I think this could be a good way to isolate technology dependent
> stuff as much as possible.

Nice. My idea is to create a myhdl.xilinx package. This package could
have several subpackages like virtex6, virtex5, etc. To use any of
the Xilinx specific blocks in a MyHDL design one would simply need
to do "from myhdl.xilinx.dsp48 import multiplier" or
"from myhdl.xilinx.cpld.bufg", etc. Device specific blocks
(i.e. devices which are only found in virtex5, etc) could go
into their own subpackages (I am still thinking about the details).

But before I can do that I must make sure that it is actually doable,
so any advice or support on your end would be appreaciated.


> >    - Is it possible to force the port types
> 
> If the conversion doesn't do it right, you can set the
> signal.driven (documented in the manual) and the 
> signal.read (undocumented I believe) attributes in
> the module yourself, to infer the proper port type.

The MyHDL documentation for the "driven" attribute says that
it can have two possible values: "reg" and "wire". The documentation
only talks about verilog. Since I do not know much verilog
but if I recall properly the difference is related to whether a
variable is given its value by behavioural or structural code. In
both cases MyHDL sets the port type to inout, so I guess it does
not matter which one you use, right?

On the other hand, what are the valid values for the "read" attribute?


> >    ? MyHDL seems to be creating them as
> > "inout"
> 
> This would normally mean that you both drive and read a signal
> in a module. (Note: Verilog support reading from output ports.)

Actually, I have realized that this was a problem with my code, not
a MyHDL problem.

I was blindly following the example in the myhdl documentation page
without really understanding it! In the example the "driven" attribute
of the input port was being set to "wire". This made my clock port
be declared as inout by the MyHDL conversion.

 
> >    - Can I make some ports optional (and give them default values?
> >    - Should I declare the generics (i.e. the "generic map" part 
> >      as regular python function arguments?
> > 
> > Sorry if these questions are very basic. I did not find (or 
> > perhaps understand) the corresponding information on the 
> > User-Defined code part of the MyHDL documentation.
> 
> I'm not aware of a standard systematic approach currently -
> research more than welcome. The ideal approach may depend
> on the case. MyHDL probably lacks some features, or documentation,
> as discussed above, to support certain realistic use cases.
> Also, there is the question where to put boundary of the
> parametrization, more to Python, or more to VHDL (e.g. by
> using multiple architectures.)

I am not sure what you are suggesting here. How do you propose
to generate more than one architecture from MyHDL?

Cheers,

Angel

Re: [myhdl-list] &amp;amp; quot; Error in user defined VHDL code&amp;amp; quot; should show line, and column for error, rather than &amp;amp; quot; index&amp;amp; quot;

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

Please note that I had to remove some of the indentation from the
patch on my previous message, because gmane limits the width
of messages to 80 characters.

Angel

Re: [myhdl-list] Proposal: better support for hierarchy and user-defined code

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> 
> Support for hierarchical output from conversion is a FAQ.
> 
> In a current project, I need this also, so I have been thinking
> about ways to make this easier. Here is what I came up with.
> 
> The use case I'm concentrating on is where everything is generated
> by the MyHDL convertor (no third-party code in VHDL or Verilog)
> but you still want hierarchy. Currently you can use a 2 step
> approach, using user-defined code to generate an instantation
> when converting the top-level, and then converting the
> lower-level model separately later. One issue is that you
> still have to write the instantiation code in Verilog and
> VHDL itself, which can be tedious for large interfaces.
> 
> The proposal is to keep the 2 step approach, but letting the
> convertor generate the instantiation itself upon user request.
> With some magic, it has all the info to do so, except the 
> desired instance name.

Jan, if you don't mind could you explain a bit further
whether there are technical reasons to not replicate the 
python function hierarchy when you generate the VHDL or
Verilog code? That is, why use this 2-step approach and
not simply generate hierarchy code by default? Are there
some hidden drawbacks that I don't understand? I am still
trying to fully understand how myhdl conversion works, so
maybe there is something obvious that I did not get!

However, if that is not the case, I think that having
a fully automated way of generating hierarchical code
would be really nice.

> The problem then is the user interface. Currently, we use a
> magic variable __verilog__ or __vhdl__ to request user-defined
> code insertion instead of converting. The obvious way would be to
> introduce new magic variables. However, upon investigation it
> became clear this is really not the intended use of magic
> variables. In fact, I'm now convinced that the original
> __verilog__ and __vhdl_ were a bad idea, and my plan is
> to deprecate them in favour of a better solution.
> 
> The right solution I believe is to use function attributes.
> For example, user-defined Verilog code would be done
> as follows:
> 
> def f(...):
>    ...
> 
> f.verilog_code = <template_string>.
> 
> It is also possible to control this from within the function
> itself, which is probably the typical case:
> 
> def f(.., convert):
>    ...
>    if convert:
>        f.verilog_code = None
>    else:
>        f.verilog_code = <template_string>
> 
> And now I would introduce another attribute to request
> an instantiation, by merely specifying the instance name:
> 
> def f(..., convert):
>    ...
>    f.verilog_instance = None if convert else <instance_name>

Sorry, I do not get exactly what would be the use case
for the "verilog_instance" attribute.

> Similarly, we would have vhdl_code and vhdl_instance attributes.

I think that this attribute based approach is a very 
promising. Could this be used to allow you to define 
libraries that must be used when using user generated code?

What I mean is that you could have another pair of attribures,
mamed "vhdl_libraries" and "verilog_libraries", for example, 
which you could use to define some libraries that you must add
when you generate the vhdl or verilog code (as discussed in
one of the recent threads?). Or maybe this could be used for
something even more generic (i.e. not only for library 
declarations).


> I have already pushed a changeset that supports all this to the public
> repo's. However, there are no unit tests yet for the verilog_instance
> and vhdl_instance attributes - the generated instantiations may still
> have problems. Those who can use this and want to
> help debug, thanks. I will be debugging this in the coming weeks.

I'll give this a try. As I said, this seems a much
more flexible way to define user defined code :-)

Angel

Re: [myhdl-list] &amp; quot; Error in user defined VHDL code&amp; quot; should show line, and column for error, rather than &amp; quot; index&amp; quot;

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:
> 
> Angel Ezquerra wrote:
> > Jan Decaluwe <jan <at> jandecaluwe.com> writes:
> > 
> >> Error messages are often a weak point, but I thought that in the
> >> particular case of user-defined code, it was reasonable. I don't
> >> immediately understand what you describe here, a small example
> >> welcome.
> > 
> > I got the following error message while trying to use a very long 
> > VHDL user defined string on one of my myhdl python files:
> > 
> > "raise ToVHDLError("Error in user defined VHDL code", msg, info)
> > myhdl.ToVHDLError: in file dsp48e.py, function dsp48e starting on
> > line 3:
> > Error in user defined VHDL code: <type 'exceptions.ValueError'>:
> >  unsupported format character ',' (0x2c) at index 6175"
> > 
> > As you can see, the error indicates "index 6175" as the place where the
> > error happened. I assume that that refers to the 6175 character on the
> > __vhdl__ string. If that is the case, while it would actually be 
> > possible to use that information to find where the error happened,
> > it is definitelly not very practical to do so! Instead it would be
> > much better if the error message told you that the error happened
> > on line 89, column 12 of the __vhdl__ string, or, even better,
> > on line 101, column 20 of the original python script.
> 
> So you get the exact file, function, error condition, index in the string
> and even the offending character, and this is not good enough  Mm.

As I said you _can_ find the error. That does not mean that it
is easy :-)

Jokes aside, not many editors support going straight to a string offset,
which makes this error message much less useful that it could be
in practice.

> When something is wrong with the format string evaluation, MyHDL forwards
> you whatever exception Python gives it. So this is pretty much what
> native python would tell you. There are a myriad things that can go
> wrong, and the error may be Python-version dependent. What you are
> asking is combining the MyHDL info with the specific Python info,
> which is probably unfeasible in practical terms.

I agree that you cannot foresee all types of errors on the
user generated code. However this is an error which happens at 
the boundary between the Python and the user-defined VHDL 
code. It is at that point were any error generated by the 
python interpreter will be less specific. Thus, anything that
could be done to improve that would be nice.

For example, it would be quite straight forward to detect
this sort of error and show the offending line in the
user defined code string. This would make it very easy to
find the problem and fix it.

To that end, I digged a bit through the myhdl code and I saw 
that this error is generated on the line 334 of the _toVHDL.py 
file (on the _convertGens() function, to be exact).
The line says:

    blockBuf.write(str(tree))
    
This function calls the seems to call the __str__() method
of the _UserCode class. This makes me believe that this is
basically the most common if not the only error that MyHDL 
can detect on the user defined code.

So, as an exercise I applied the following patch:

diff --git a/myhdl/_extractHierarchy.py b/myhdl/_extractHierarchy.py
--- a/myhdl/_extractHierarchy.py
+++ b/myhdl/_extractHierarchy.py
@@ -101,10 +101,35 @@ class _UserCode(object):
      info = "in file %s, function %s starting on line %s:\n    " % \
             (self.sourcefile, self.funcname, self.sourceline)
      msg = "%s: %s" % (type, value)
+     
+     # Check whether the error contains a reference 
+     # to a position in the code string
+     s_index_tag = " at index "
+     i_error_index_position = msg.find(s_index_tag)
+     if i_error_index_position != -1:
+         # The error string contains an index -> extract 
+         # the corresponding line
+         i_error_index_position += len(s_index_tag)
+         i_error_position = int(msg[i_error_index_position:])
+         i_error_line_start = 1 + self.code[:i_error_position].rfind("\n")
+         i_error_line_end = i_error_position + \
+             self.code[i_error_position:].find("\n")
+         s_error_line = self.code[i_error_line_start:i_error_line_end]
+         
+         # And get the error column and line
+         n_error_column = i_error_position - i_error_line_start
+         n_error_line = len(self.code[:i_error_position].splitlines())
+         print("ERROR in line %d, column %d: %s" % (n_error_line, \
+             n_error_column, s_error_line))
+     
      self.raiseError(msg, info)
  code = "\n%s\n" % code
  return code

         
This is certainly not the most beautiful python code ever, but
it shows the information that I think would best help you
find these sorts of errors :-)

Cheers,

Angel

[myhdl-list] namedtuple support for converter

[<ala...@sp...>]

Hi,

I wonder how difficult it would be to support namedtuple in the converter?
I use them extensively to emulate vhdl records.

Best regards,
Alain

Re: [myhdl-list] &quot; Error in user defined VHDL code&quot; should show line, and column for error, rather than &quot; index&quot;

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

Kevin Stanton wrote:
> Perhaps I am oversimplifying a complex problem, but why couldn't a
> filter function be written like this:
> 
> def get_error_line_col(code_str, error_index, line_delimiter='\n'):

The problem would be to get the 'index' in a simple, general way.
Python's error messages are not standardized. Anyway, starting
to parse Python's error messages to "improve" upon them in
MyHDL is obviously the wrong way (it goes completely against
MyHDL's minimalistic design philosophy).

The correct way in principle is equally obvious: use a technique
such that Python gives you a better error message. In fact,
thinking about it, complex user-defined strings are used
like templates, and a direct template approach may be much better.
There is a whole array of templating solutions available,
but the string.Template from the standard libary may be
just fine, albeit less powerful than format strings.

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] Proposal: better support for hierarchy and user-defined code

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

Support for hierarchical output from conversion is a FAQ.

In a current project, I need this also, so I have been thinking
about ways to make this easier. Here is what I came up with.

The use case I'm concentrating on is where everything is generated
by the MyHDL convertor (no third-party code in VHDL or Verilog)
but you still want hierarchy. Currently you can use a 2 step
approach, using user-defined code to generate an instantation
when converting the top-level, and then converting the
lower-level model separately later. One issue is that you
still have to write the instantiation code in Verilog and
VHDL itself, which can be tedious for large interfaces.

The proposal is to keep the 2 step approach, but letting the
convertor generate the instantiation itself upon user request.
With some magic, it has all the info to do so, except the 
desired instance name.

The problem then is the user interface. Currently, we use a
magic variable __verilog__ or __vhdl__ to request user-defined
code insertion instead of converting. The obvious way would be to
introduce new magic variables. However, upon investigation it
became clear this is really not the intended use of magic
variables. In fact, I'm now convinced that the original
__verilog__ and __vhdl_ were a bad idea, and my plan is
to deprecate them in favour of a better solution.

The right solution I believe is to use function attributes.
For example, user-defined Verilog code would be done
as follows:

def f(...):
   ...

f.verilog_code = <template_string>.

It is also possible to control this from within the function
itself, which is probably the typical case:

def f(.., convert):
   ...
   if convert:
       f.verilog_code = None
   else:
       f.verilog_code = <template_string>

And now I would introduce another attribute to request
an instantiation, by merely specifying the instance name:

def f(..., convert):
   ...
   f.verilog_instance = None if convert else <instance_name>


Similarly, we would have vhdl_code and vhdl_instance attributes.

I have already pushed a changeset that supports all this to the public
repo's. However, there are no unit tests yet for the verilog_instance
and vhdl_instance attributes - the generated instantiations may still
have problems. Those who can use this and want to
help debug, thanks. I will be debugging this in the coming weeks.

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] &quot; Error in user defined VHDL code&quot; should show line, and column for error, rather than &quot; index&quot;

[Kevin S. <sta...@gm...>]

Perhaps I am oversimplifying a complex problem, but why couldn't a
filter function be written like this:

def get_error_line_col(code_str, error_index, line_delimiter='\n'):
	line_num = 1
	col_num = 1

	for i in range(0, error_index):
		if (code_str[i] == line_delimiter):
			line_num += 1
			col_num = 1
		else:
			col_num += 1

	return (line_num, col_num)

test case I tried on it:

test_str = '12345\n6789ABC\nDEFGHIJKLMNOPQ\n'

>>> get_error_line_col(test_str, 22)
(3, 9)
>>> get_error_line_col(test_str, 4)
(1, 5)

etc.

Hope this helps,
Kevin Stanton

On Jul 3, 2010, at 6:32, Jan Decaluwe <ja...@ja...> wrote:

> Angel Ezquerra wrote:
>> Jan Decaluwe <jan <at> jandecaluwe.com> writes:
>>
>>> Error messages are often a weak point, but I thought that in the particular
>>> case of user-defined code, it was reasonable. I don't immediately understand
>>> what you describe here, a small example welcome.
>>
>> I got the following error message while trying to use a very long VHDL
>> user defined string on one of my myhdl python files:
>>
>> "raise ToVHDLError("Error in user defined VHDL code", msg, info)
>> myhdl.ToVHDLError: in file dsp48e.py, function dsp48e starting on line 3:
>> Error in user defined VHDL code: <type 'exceptions.ValueError'>: unsupported
>> format character ',' (0x2c) at index 6175"
>>
>> As you can see, the error indicates "index 6175" as the place where the
>> error happened. I assume that that refers to the 6175 character on the
>> __vhdl__ string. If that is the case, while it would actually be
>> possible to use that information to find where the error happened,
>> it is definitelly not very practical to do so! Instead it would be
>> much better if the error message told you that the error happened
>> on line 89, column 12 of the __vhdl__ string, or, even better,
>> on line 101, column 20 of the original python script.
>
> So you get the exact file, function, error condition, index in the string
> and even the offending character, and this is not good enough :-) Mm.
>
> When something is wrong with the format string evaluation, MyHDL forwards
> you whatever exception Python gives it. So this is pretty much what
> native python would tell you. There are a myriad things that can go
> wrong, and the error may be Python-version dependent. What you are
> asking is combining the MyHDL info with the specific Python info,
> which is probably unfeasible in practical terms.
>
> String errors are not normally reported in lines or columns. So for
> complex cases like this, I think it's not unreasonable to organize
> for easier debugging. For example, by putting the large template
> string in a separate file, and use an editor that can move
> to buffer positions (emacs has this natively). Or even to debug
> the string in Python separately from its use in MyHDL.
>
> Jan
>
> --
> 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
>    Analog design automation: http://www.mephisto-da.com
>    World-class digital design: http://www.easics.com
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] &quot; Error in user defined VHDL code&quot; should show line, and column for error, rather than &quot; index&quot;

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

Angel Ezquerra wrote:
> Jan Decaluwe <jan <at> jandecaluwe.com> writes:
> 
>> Error messages are often a weak point, but I thought that in the particular
>> case of user-defined code, it was reasonable. I don't immediately understand
>> what you describe here, a small example welcome.
> 
> I got the following error message while trying to use a very long VHDL 
> user defined string on one of my myhdl python files:
> 
> "raise ToVHDLError("Error in user defined VHDL code", msg, info)
> myhdl.ToVHDLError: in file dsp48e.py, function dsp48e starting on line 3:
> Error in user defined VHDL code: <type 'exceptions.ValueError'>: unsupported
>  format character ',' (0x2c) at index 6175"
> 
> As you can see, the error indicates "index 6175" as the place where the
> error happened. I assume that that refers to the 6175 character on the
> __vhdl__ string. If that is the case, while it would actually be 
> possible to use that information to find where the error happened,
> it is definitelly not very practical to do so! Instead it would be
> much better if the error message told you that the error happened
> on line 89, column 12 of the __vhdl__ string, or, even better,
> on line 101, column 20 of the original python script.

So you get the exact file, function, error condition, index in the string
and even the offending character, and this is not good enough :-) Mm.

When something is wrong with the format string evaluation, MyHDL forwards
you whatever exception Python gives it. So this is pretty much what
native python would tell you. There are a myriad things that can go
wrong, and the error may be Python-version dependent. What you are
asking is combining the MyHDL info with the specific Python info,
which is probably unfeasible in practical terms.

String errors are not normally reported in lines or columns. So for
complex cases like this, I think it's not unreasonable to organize
for easier debugging. For example, by putting the large template
string in a separate file, and use an editor that can move
to buffer positions (emacs has this natively). Or even to debug
the string in Python separately from its use in MyHDL.

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] &quot; Error in user defined VHDL code&quot; should show line, and column for error, rather than &quot; index&quot;

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> Error messages are often a weak point, but I thought that in the particular
> case of user-defined code, it was reasonable. I don't immediately understand
> what you describe here, a small example welcome.

I got the following error message while trying to use a very long VHDL 
user defined string on one of my myhdl python files:

"raise ToVHDLError("Error in user defined VHDL code", msg, info)
myhdl.ToVHDLError: in file dsp48e.py, function dsp48e starting on line 3:
Error in user defined VHDL code: <type 'exceptions.ValueError'>: unsupported
 format character ',' (0x2c) at index 6175"

As you can see, the error indicates "index 6175" as the place where the
error happened. I assume that that refers to the 6175 character on the
__vhdl__ string. If that is the case, while it would actually be 
possible to use that information to find where the error happened,
it is definitelly not very practical to do so! Instead it would be
much better if the error message told you that the error happened
on line 89, column 12 of the __vhdl__ string, or, even better,
on line 101, column 20 of the original python script.


> > Also (and I don't know if this may be possible at all), it would be nice 
> > if the error message told you the line in which the __vhdl__ 
> > string was declared.
> 
> Probably not trivial.

I imagined so, but it'd be much easier to find the errors if the
error position was given as an absolute offset from the start of
the source python file. One can always wish! :-)


Cheers,

Angel

Re: [myhdl-list] Adding library declarations to your VHDL code

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

Angel Ezquerra wrote:
> I am trying to make a myhdl block that will let me introduced a Xilinx DSP48e 
> block.
> 
> In order to use and simulate this block you must add the following 
> library use
> declaration before the declaration of the entity that will use 
> the DSP48 block:
> 
> Library UNISIM;
> use UNISIM.vcomponents.all;

Actually, before the architecture declaration I guess (so that the entity could
be kept technology-independent).


> 
> 
> Then you must 
> declare an instance of the DSP48E block, linking its ports to the
> 
> corresponding signals:
> 
> -- BEGIN of DSP48E instantiation:
> 
>    -- DSP48E: DSP 
>    Function Block
>    --         Virtex-5
>    -- Xilinx HDL Language Template, 
>    version 11.2
>    
>    DSP48E_inst : DSP48E
>    generic map (
>       ACASCREG => 1
>       ,       -- Number of pipeline registers between 
>                            
>                            -- A/ACIN input and ACOUT output, 0, 1, or 2
>       ALUMODEREG => 1,     -- 
>       Number of pipeline registers on ALUMODE input, 0 or 1
>       AREG => 1
>       ,           -- Number of pipeline registers on the A input, 0, 1 or 2
>       
>       AUTORESET_PATTERN_DETECT => FALSE, -- Auto-reset upon pattern detect, TRUE
> or 
> FALSE
>       AUTORESET_PATTERN_DETECT_OPTINV => "MATCH", -- Reset if "MATCH" 
>       or "NOMATCH" 
>       A_INPUT => "DIRECT", -- Selects A input used, "DIRECT" (A 
>       port) or
> "CASCADE" (ACIN port)
>       BCASCREG => 1,       -- Number of 
>       pipeline registers between B/BCIN input
> and BCOUT output, 0, 1, or 2
>       
>       BREG => 1,           -- Number of pipeline registers on the B input, 0, 1 or 2
>       
>       B_INPUT => "DIRECT", -- Selects B input used, "DIRECT" (B port) or
> "
> CASCADE" (BCIN port)
>       CARRYINREG => 1,     -- Number of pipeline 
>       registers for the CARRYIN
> input, 0 or 1
>       CARRYINSELREG => 1,  -- Number 
>       of pipeline registers for the CARRYINSEL
> input, 0 or 1
>       CREG => 1
>       ,           -- Number of pipeline registers on the C input, 0 or 1
>       MASK 
>       => X"3FFFFFFFFFFF", -- 48-bit Mask value for pattern detect
>       MREG => 1
>       ,           -- Number of multiplier pipeline registers, 0 or 1
>       
>       MULTCARRYINREG => 1, -- Number of pipeline registers for multiplier carry
> in 
> bit, 0 or 1
>       OPMODEREG => 1,      -- Number of pipeline registers on 
>       OPMODE input, 0 or 1
>       PATTERN => X"000000000000", -- 48-bit Pattern 
>       match for pattern detect
>       PREG => 1,           -- Number of pipeline 
>       registers on the P output, 0 or 1
>       SIM_MODE => "SAFE", -- Simulation: "
>       SAFE" vs "FAST", see "Synthesis and
> Simulation
>                           -- 
>                           Design Guide" for details
>       SEL_MASK => "MASK",  -- Select mask value 
>       between the "MASK" value or the
> value on the "C" port
>       SEL_PATTERN => "
>       PATTERN", -- Select pattern value between the "PATTERN"
> value or the value on 
> the "C" port
>       SEL_ROUNDING_MASK => "SEL_MASK", -- "SEL_MASK", "MODE1", "
>       MODE2" 
>       USE_MULT => "MULT_S", -- Select multiplier usage, "MULT" (MREG 
>       => 0), 
>                             -- "MULT_S" (MREG => 1), "NONE" (not 
>                             using multiplier)
>       USE_PATTERN_DETECT => "NO_PATDET", -- Enable pattern 
>       detect, "PATDET",
> "NO_PATDET" 
>       USE_SIMD => "ONE48") -- SIMD selection, "
>       ONE48", "TWO24", "FOUR12" 
>    port map (
>       ACOUT => ACOUT,  -- 30-bit A 
>       port cascade output 
>       BCOUT => BCOUT,  -- 18-bit B port cascade output
>       
>       CARRYCASCOUT => CARRYCASCOUT, -- 1-bit cascade carry output
>       
>       CARRYOUT => CARRYOUT, -- 4-bit carry output
>       MULTSIGNOUT => MULTSIGNOUT, 
>       -- 1-bit multiplier sign cascade output
>       OVERFLOW => OVERFLOW, -- 1-bit 
>       overflow in add/acc output
>       P => P,          -- 48-bit output
>       
>       PATTERNBDETECT => PATTERNBDETECT, -- 1-bit active high pattern bar detect
> 
>       output
>       PATTERNDETECT => PATTERNDETECT, --  1-bit active high pattern 
>       detect output
>       PCOUT => PCOUT,  -- 48-bit cascade output
>       UNDERFLOW 
>       => UNDERFLOW, -- 1-bit active high underflow in add/acc output
>       A => A
>       ,          -- 30-bit A data input
>       ACIN => ACIN,    -- 30-bit A cascade 
>       data input
>       ALUMODE => ALUMODE, -- 4-bit ALU control input
>       B => B
>       ,          -- 18-bit B data input
>       BCIN => BCIN,    -- 18-bit B cascade 
>       input
>       C => C,          -- 48-bit C data input
>       CARRYCASCIN => 
>       CARRYCASCIN, -- 1-bit cascade carry input
>       CARRYIN => CARRYIN, -- 1-bit 
>       carry input signal
>       CARRYINSEL => CARRYINSEL, -- 3-bit carry select input
>       
>       CEA1 => CEA1,      -- 1-bit active high clock enable input for 1st 
>       stage A
> registers
>       CEA2 => CEA2,      -- 1-bit active high clock enable 
>       input for 2nd stage A
> registers
>       CEALUMODE => CEALUMODE, -- 1-bit active 
>       high clock enable input for
> ALUMODE registers
>       CEB1 => CEB1,      -- 1-
>       bit active high clock enable input for 1st stage B
> registers
>       CEB2 => 
>       CEB2,      -- 1-bit active high clock enable input for 2nd stage B
> registers
> 
>       CEC => CEC,      -- 1-bit active high clock enable input for C 
>       registers
>       CECARRYIN => CECARRYIN, -- 1-bit active high clock enable 
>       input for
> CARRYIN register
>       CECTRL => CECTRL, -- 1-bit active high clock 
>       enable input for OPMODE and
> carry registers
>       CEM => CEM,       -- 1-bit 
>       active high clock enable input for multiplier
> registers
>       CEMULTCARRYIN 
>       => CEMULTCARRYIN,       -- 1-bit active high clock enable
> for multiplier 
> carry in register
>       CEP => CEP,       -- 1-bit active high clock enable 
>       input for P registers
>       CLK => CLK,       -- Clock input
>       MULTSIGNIN 
>       => MULTSIGNIN, -- 1-bit multiplier sign input
>       OPMODE => OPMODE, -- 7-
>       bit operation mode input
>       PCIN => PCIN,     -- 48-bit P cascade input 
>       
>       RSTA => RSTA,     -- 1-bit reset input for A pipeline registers
>       
>       RSTALLCARRYIN => RSTALLCARRYIN, -- 1-bit reset input for carry pipeline
> 
>       registers
>       RSTALUMODE => RSTALUMODE, -- 1-bit reset input for ALUMODE 
>       pipeline registers
>       RSTB => RSTB,     -- 1-bit reset input for B 
>       pipeline registers
>       RSTC => RSTC,     -- 1-bit reset input for C 
>       pipeline registers
>       RSTCTRL => RSTCTRL, -- 1-bit reset input for OPMODE 
>       pipeline registers
>       RSTM => RSTM, -- 1-bit reset input for multiplier 
>       registers
>       RSTP => RSTP  -- 1-bit reset input for P pipeline registers
> );
> 
> 
> -- END of DSP48E_inst instantiation
> 
> 
> I have the following questions:
> - Is 
> there a way to tell myhdl that a certain entity requires a certain set of
> 
> libraries?

Currently there is no option to add libraries to the output. Probably
this should be added as an attribute to toVHDL().

> - I created a "dummy" entity that simply contains the DPS48E 
> instance
> declaration and maps the input ports to the DSP48E instance ports:
> 
>    - Is that the right approach?

I think this could be a good way to isolate technology dependent
stuff as much as possible.

>    - Is it possible to force the port types

If the conversion doesn't do it right, you can set the
signal.driven (documented in the manual) and the 
signal.read (undocumented I believe) attributes in
the module yourself, to infer the proper port type.

>    ? MyHDL seems to be creating them as
> "inout"

This would normally mean that you both drive and read a signal
in a module. (Note: Verilog support reading from output ports.)

>    - Can I make some ports 
>    optional (and give them default values?
>    - Should I declare the generics (i.
>    e. the "generic map" part as regular
> python function arguments?
> 
> Sorry if 
> these questions are very basic. I did not find (or perhaps understand)
> the 
> corresponding information on the User-Defined code part of the MyHDL
> documentation.

I'm not aware of a standard systematic approach currently -
research more than welcome. The ideal approach may depend
on the case. MyHDL probably lacks some features, or documentation,
as discussed above, to support certain realistic use cases.
Also, there is the question where to put boundary of the
parametrization, more to Python, or more to VHDL (e.g. by
using multiple architectures.)

Jan

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com