myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Help with initial config of MyHDL on Ubuntu 9.04

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

Hi,

I can't seem to find anything on what might be going wrong, but I just
installed MyHDL and tried to run a few of the examples.

I went into :

cd myhdl-0.6/example/rs232

and ran:

python test_rs232.py

All of the tests fail, and I get back several errors that look exactly like
this:

Traceback (most recent call last):
  File "test_rs232.py", line 102, in testCharacterize
    Simulation(self.bench(tx_baud_rate)).run(quiet=1)
  File "/usr/local/lib/python2.6/dist-packages/myhdl/_Simulation.py", line
132, in run
    waiter.next(waiters, actives, exc)
  File "/usr/local/lib/python2.6/dist-packages/myhdl/_Waiter.py", line 113,
in next
    (repr(clause), type(clause)))
TypeError: yield clause <myhdl._instance._Instantiator object at 0xa1a506c>
has type <class 'myhdl._instance._Instantiator'>

I am not a novice at VHDL, or Python for that matter, but this error message
is confusing because it appears to be complaining about a TypeError, but the
types listed match...

What am I missing?

Thanks in advance for anyone who can be of help!

Kevin

Re: [myhdl-list] GHDL co-simulation

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

Christopher L. Felton wrote:
> 
> I was investigating the GHDL VHPI (VPI) support a little since I have 
> been having issues with co-simulation, thought I would try another 
> approach.  According to the GHDL website enough of the VPI interface has 
> been implemented to support IVI.
> 
> Working off an example I was able to compile the cver myhdl_vpi.c and 
> load it in GHDL.  I have not looked at the MyHDL PLI/VPI implementation 
> enough to go beyond this point.
> 
> I have included the hg bundle that has the Makefile.  Does anyone know 
> if there is a GHDL VPI limitation that would make this _not_ worth 
> pursuing?  Or has the GHDL VPI interface matured enough to support 
> co-simulation with MyHDL?

If you can get this to work, it would be extremely helpful!

Regarding your questions: I have no idea :-) I've looked at the available
ghdl documentation again and its seems VPI functionality is in the same
state as when I looked at it a few years ago. Meaning: no real documentation,
only some examples.

It looks like ghdl itself is actively developed and supported, but I've
no idea whether this covers the VPI stuff also.

In short: we may be lucky and get it to work, but if we're not, we may
be in a dead end after a considerable amount of work. Getting this
to work with Icarus was painful, but I did get support when I needed
it. Given the ghdl uncertainties, I wasn't very motivated to work on
it, but of course, I welcome all fresh attempts to give it a try!

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] GHDL co-simulation

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

I was investigating the GHDL VHPI (VPI) support a little since I have 
been having issues with co-simulation, thought I would try another 
approach.  According to the GHDL website enough of the VPI interface has 
been implemented to support IVI.

Working off an example I was able to compile the cver myhdl_vpi.c and 
load it in GHDL.  I have not looked at the MyHDL PLI/VPI implementation 
enough to go beyond this point.

I have included the hg bundle that has the Makefile.  Does anyone know 
if there is a GHDL VPI limitation that would make this _not_ worth 
pursuing?  Or has the GHDL VPI interface matured enough to support 
co-simulation with MyHDL?

Also, is there a known limitation with local module signals named _* 
(variable name starting with a "_") and VHDL conversion?  I did not 
realize (remember) that two consecutive underscores was illegal in VHDL? 
  Unfortunately, I have been using Signal names that start with an 
underscore quite a bit and the conversion generates two consecutive 
underscores.

.chris

Re: [myhdl-list] cver fails Verilog power operator

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

Christopher Felton wrote:

> I wonder if any commercial (maybe the commercial version of cver) would 
> be interested in giving you a license for there simulator.  Simply to 
> get the exposure, "Company XXX Verilog/VHDL simulator compatible with 
> MyHDL".  Seems like a small cost for a company to provide a license or 
> two and possibly receive some additional exposure.

There would have to be a business reason for them, which is not
that obvious even (or especially) if MyHDL would be more widely used.
I believe our first such allies could be FPGA vendors, but probably
they will move only when their customers start asking for it.

> I am all for the open-source versions (maybe the open-source should use 
> MyHDL for unit-testing their simulators) but there appears to be some 
> limitations.

It wouldn't be too difficult for me to get access to commercial
licenses to check and add MyHDL support, by asking some befriended
companies. Here is why I've not done that:

- Cosimulation support for other simulators is an ideal task that
could be done and supported by someone else.
- I still have my hopes set on Icarus Verilog, of course one has to file
bug reports in case of problems.
- The best target for MyHDL is the most limited simulator or back-end
tool that still works reasonably (this is a compromise), because that
creates most value for a user; moreover it then certainly works for
more powerful tools.

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] Co-simulation and generating VCD with $dumpvars

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

On 1/18/10 10:34 AM, Christopher Felton wrote:
>
> [background]
> Given the previous thread I realize that there are some Co-simulation
> issues with the Open-Source Verilog simulators.  With my development I
> have been jumping straight to hardware (not because of the limitations
> but mainly because it worked and/or laziness).  Everything has been
> working great.
>
> I did hit a point where the synthiszed design doesn't appear to match
> the simulated design (verified in lab with scope and compared simulation
> waveforms).  At that point I was attempting to verify with
> co-simulation.  The co-simulation has been generating mismatches.
>
> [dumpvars ??]
> In attempt to debug the co-simulation mismatches I wanted to create a
> VCD to look at the Verilog waveforms.  I tried adding the Verilog
> $dumpvars to my generated Verilog (using the __verilog__ in my top-level
> MyHDL).  This appeared to break the co-simulation, I would get an
> exception in the Co-simulation pipe read (possibly the Verilog simulator
> not responding?).
>
> Has anyone else seen similar behavior?  Is there a better method to
> produce a VCD from the co-simulated Verilog?
>

If I put the dumpvars in the generated testbench it works.  But I have 
to manually add the $dumpvars each time or change the conversion code.

Added to the end of the generated Verilog testbench interface, tb_*

initial begin
   $dumpfile("<dumpfile.vcd>");
   $dumpvars;
   $dumpvars(0, dut);
end

Still curious if this has been accomplished by some other mechanism.

.chris

[myhdl-list] Co-simulation and generating VCD with $dumpvars

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

[background]
Given the previous thread I realize that there are some Co-simulation 
issues with the Open-Source Verilog simulators.  With my development I 
have been jumping straight to hardware (not because of the limitations 
but mainly because it worked and/or laziness).  Everything has been 
working great.

I did hit a point where the synthiszed design doesn't appear to match 
the simulated design (verified in lab with scope and compared simulation 
waveforms).  At that point I was attempting to verify with 
co-simulation.  The co-simulation has been generating mismatches.

[dumpvars ??]
In attempt to debug the co-simulation mismatches I wanted to create a 
VCD to look at the Verilog waveforms.  I tried adding the Verilog 
$dumpvars to my generated Verilog (using the __verilog__ in my top-level 
MyHDL).  This appeared to break the co-simulation, I would get an 
exception in the Co-simulation pipe read (possibly the Verilog simulator 
not responding?).

Has anyone else seen similar behavior?  Is there a better method to 
produce a VCD from the co-simulated Verilog?

I don't think the co-simulation with VHDL is possible since my 
testbenches are too complicated to be converted to VHDL/Verilog 
testbenches.  The co-simulation is a much better option versus testbench 
conversion.

Thanks
chris

Re: [myhdl-list] cver fails Verilog power operator

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

On 1/18/10 3:39 AM, Jan Decaluwe wrote:
> Christopher L. Felton wrote:
>> Cver appears to fail the Verilog power operator?  Has anyone else seen this?
>>
>>
>> GPL CVER Version
>> """
>> GPLCVER_2.12a of 05/16/07 (Mac OSX).
>> Copyright (c) 1991-2007 Pragmatic C Software Corp.
>>     All Rights reserved.  Licensed under the GNU General Public License
>> (GPL).
>> """
>>
>> Example:
>>
>> _MyHDL_
>>       @always_comb
>>       def rtl_wp():
>>           wp_p1.next = (wp + 1) % 2**C_ASZ
>>
>> _Convert Verilog_
>>       assign spi0_txFifo_wp_p1 = ((spi0_txFifo_wp + 1) % (2 ** 3));
>>
>>
>>
>> My work around was to change the my MyHDL code to compute the mod value.
>> _MyHDL_
>> AddressMod = 2**C_ASZ
>> @always_comb
>>       def rtl_wp():
>>           wp_p1.next = (wp + 1) % AddressMod
>>
>>
>> The "**" is a Valid power operator in Verilog and Icarus Verilog appears
>> to handle it ok (as well as the synthesis tools).  I was wondering if a
>> warning should be added?
>>
>> Side note I have been using Icarus and Cver.  I ran into another error
>> using Icarus (probably self induced) and it wasn't clear what the
>> problem was so I tried Cver to hopefully shed some light when I hit the
>> problem.
>
> Unfortunately MyHDL has come to a point where neither Icarus nor Cver
> runs the conversion test suite completely without errors, though I have
> every reason to believe the generated Verilog is correct.
>
> The proper way is of course to file bug reports. However, for Cver this
> doesn't make sense anymore because open source development has stopped.
>
> The power operator is a special case. It was added in Verilog 2001. Cver
> doesn't support it and apparently never will, but recent versions of
> Icarus support it. However, when I was working on the convertor for it,
> it didn't work properly for neither Cver, Icarus and GHDL, so I dropped working
> on the unit tests at the time. I just checked again and immediately run
> into issues with Verilog, so the convertor output is probably buggy.
> (Probably low level bit width issues again.) This will have to be looked
> at in detail again.
>
> Jan
>

GPL Cver does have a sourceforge page, as you mentioned, probably no 
active developers.

http://sourceforge.net/projects/gplcver/

I wonder if any commercial (maybe the commercial version of cver) would 
be interested in giving you a license for there simulator.  Simply to 
get the exposure, "Company XXX Verilog/VHDL simulator compatible with 
MyHDL".  Seems like a small cost for a company to provide a license or 
two and possibly receive some additional exposure.

I am all for the open-source versions (maybe the open-source should use 
MyHDL for unit-testing their simulators) but there appears to be some 
limitations.

Re: [myhdl-list] fixed_point library and VHDL generation

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

On 1/12/10 3:30 PM, Christopher Felton wrote:
> Jan L.
>
>     a = Signal(fxintbv(0,Q=(0,16))
>     b = Signal(fxintbv(0,Q=(0,16))
>
>     i = 2
>
>     @always(clk.posedge)
>     def beh():
>             if b < 0:
>                     d = 1
>             else:
>                     d = -1
>             a.next = a - ((d*b) >> i)
>
>     The way I made that code working correctly is just casting a to int:
>     a.next = a*1 - ((d*b) >> i)
>
>
> The actual problem is that I relied on the lower level intbv to handle
> the logical and shift operators. The lower level intbv operators simply
> return an 'int' type.  I need to add the operator overloads (all of
> them) to the fxintbv and have them return fxintbv type.  They you will
> not get the error.  I will try to have the 0.4 release ASAP to fix this.

I have fixed these issues and put a new release on

http://www.myhdl.org/doku.php/users:cfelton:projects:fxintbv

I explain the issue incorrectly previously.  The math operators (add, 
sub, mul) were returning an int value the same as the underlying intbv 
(not the shift op).  That in turn would break the point alignment checking.

There should be more examples included in this release.

.chris

Re: [myhdl-list] _cosimulation.py fails on Windows

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

Alessandro Budai wrote:
> Python os.fork in not available on Windows platform.
> The  code should be refactored to use subprocess module (i didn't  
> checked the code
> but if this is a call to an external program subprocess.Popen object  
> can make it..)

The problem is how to do interprocess communication.

-- 
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] cver fails Verilog power operator

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

Christopher L. Felton wrote:
> Cver appears to fail the Verilog power operator?  Has anyone else seen this?
> 
> 
> GPL CVER Version
> """
> GPLCVER_2.12a of 05/16/07 (Mac OSX).
> Copyright (c) 1991-2007 Pragmatic C Software Corp.
>    All Rights reserved.  Licensed under the GNU General Public License 
> (GPL).
> """
> 
> Example:
> 
> _MyHDL_
>      @always_comb
>      def rtl_wp():
>          wp_p1.next = (wp + 1) % 2**C_ASZ
> 
> _Convert Verilog_
>      assign spi0_txFifo_wp_p1 = ((spi0_txFifo_wp + 1) % (2 ** 3));
> 
> 
> 
> My work around was to change the my MyHDL code to compute the mod value.
> _MyHDL_
> AddressMod = 2**C_ASZ
> @always_comb
>      def rtl_wp():
>          wp_p1.next = (wp + 1) % AddressMod
> 
> 
> The "**" is a Valid power operator in Verilog and Icarus Verilog appears 
> to handle it ok (as well as the synthesis tools).  I was wondering if a 
> warning should be added?
> 
> Side note I have been using Icarus and Cver.  I ran into another error 
> using Icarus (probably self induced) and it wasn't clear what the 
> problem was so I tried Cver to hopefully shed some light when I hit the 
> problem.

Unfortunately MyHDL has come to a point where neither Icarus nor Cver
runs the conversion test suite completely without errors, though I have
every reason to believe the generated Verilog is correct.

The proper way is of course to file bug reports. However, for Cver this
doesn't make sense anymore because open source development has stopped.

The power operator is a special case. It was added in Verilog 2001. Cver
doesn't support it and apparently never will, but recent versions of
Icarus support it. However, when I was working on the convertor for it,
it didn't work properly for neither Cver, Icarus and GHDL, so I dropped working
on the unit tests at the time. I just checked again and immediately run
into issues with Verilog, so the convertor output is probably buggy.
(Probably low level bit width issues again.) This will have to be looked
at in detail again.

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] Signal getattr and setattr

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

Christopher L. Felton wrote:
> Jan Decaluwe wrote:
>> Christopher L. Felton wrote:
>>> Jan Decaluwe wrote:
>>>> Chris:
>>>>
>>>> I don't have a lot of time these days (moving to new house) but
>>> No problem, this is not a bug often encountered and I have a work around 
>>> for accessing the "contained" objects attributes/properties.  Enjoy 
>>> moving to the new house!
>>>
>>>> did your patch mean that __slots__ is the problem?
>>> I don't believe __slots__ is the problem.  And you do get the 
>>> performance increase from __slots__ but I don't know how much.
>>>
>>> I believe the issue is how the copy works.  The copy tries to access 
>>> variables before they exist?  I don't know the exact mechanism of the 
>>> copy but that appears to be the issue.
>>>
>>> By adding an attribute read in __init__ before it is set, a similar 
>>> failure occurs.  Example first line of __init__ print self._val.
>>>
>>> At this point two options would be remove __getattr__ or add __copy__ 
>>> and __deepcopy__ to return a new instance and set attributes manually.
>> That seems the good solution.
>>
>> Of course, how easy it is depends on what "copying" means. The way I
>> think about it, it seems trivial: simply create a new signal with the
>> same initial value. This would create a new signal that, in the same
>> context, would behave identically to the original, but with for the
>> rest all separate data structures internally.
>>
>> That is what a "copy" is to me, but what about your application?
> 
> Yes, copy to me means the same.  Same as the copy implementations in 
> intbv?  Adding the __copy__ and __deepcopy__ makes sense otherwise it is 
> passed to the "val" copy implementation.

I expect returning Signal(self._init) should do the trick.

-- 
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] Signal getattr and setattr

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

Christopher L. Felton wrote:
> Jan Decaluwe wrote:
>> Christopher L. Felton wrote:
>>> Jan Decaluwe wrote:
>>>> Chris:
>>>>
>>>> I don't have a lot of time these days (moving to new house) but
>>> No problem, this is not a bug often encountered and I have a work around 
>>> for accessing the "contained" objects attributes/properties.  Enjoy 
>>> moving to the new house!
>>>
>>>> did your patch mean that __slots__ is the problem?
>>> I don't believe __slots__ is the problem.  And you do get the 
>>> performance increase from __slots__ but I don't know how much.
>>>
>>> I believe the issue is how the copy works.  The copy tries to access 
>>> variables before they exist?  I don't know the exact mechanism of the 
>>> copy but that appears to be the issue.
>>>
>>> By adding an attribute read in __init__ before it is set, a similar 
>>> failure occurs.  Example first line of __init__ print self._val.
>>>
>>> At this point two options would be remove __getattr__ or add __copy__ 
>>> and __deepcopy__ to return a new instance and set attributes manually.
>> That seems the good solution.
>>
>> Of course, how easy it is depends on what "copying" means. The way I
>> think about it, it seems trivial: simply create a new signal with the
>> same initial value. This would create a new signal that, in the same
>> context, would behave identically to the original, but with for the
>> rest all separate data structures internally.
>>
>> That is what a "copy" is to me, but what about your application?
> 
> Yes, copy to me means the same.  Same as the copy implementations in 
> intbv?  Adding the __copy__ and __deepcopy__ makes sense otherwise it is 
> passed to the "val" copy implementation.

Then I think the proper way is for the copy functions to
return Signal(self._init).


-- 
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] fxintbv dependency on dspsim

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

Felton Christopher wrote:
> On Jan 15, 2010, at 2:46 AM, Jan Decaluwe wrote:
> 
>> Christopher L. Felton wrote:
>>> Jan Decaluwe wrote:
>>>> I'm not a fixed-point specialist, but am I correct in thinking that
>>>> things would be considerably simpler if there would a fixed point
>>>> datatype that we could map to in VHDL/Verilog?
>>>>
>>>> I seem to have read that such a (synthesizable) datatype exists for
>>>> VHDL, but not yet for Verilog. But even it's VHDL-only, it seems  
>>>> like
>>>> an interesting path to investigate?
>>> I believe there is a fixed-point type in the latest standard of VHDL
>>> (VHDL-2007).  I don't know much more about the new VHDL type.  If  
>>> it has
>>> been ratified, supported in tools, etc.
>>>
>>> From a quick search, the VHDL fixed-point type doesn't do
>>> auto-promotion (what size should the result be).  The new types
>>> introduce the negative index in ranges (???).  I don't think it  
>>> supports
>>> all features the lib attempts to support.
>>>
>>> Regardless, I think this is one of highlights of MyHDL to handle  
>>> these
>>> kinds "types".  I think the current MyHDL approach gives the design  
>>> much
>>> more flexibility.  A designer might not always want the "default"  
>>> rules
>>> for handling fixed-point.  If mapped to the VHDL type I think there
>>> would be a "collision" of rules and loss of control.
>> I'm intrigued by these statements, please enlighten me.
> 
> Which statements?  My incomplete understanding of the VHDL fixed-point  
> support?   Or the flexibility of MyHDL to handle fractional numbers  
> without changing the core package?

I was referring to your statement that "A designer might not always
want the "default" rules for handling fixed point".

Regardless of the mechanism to make fixed point available with MyHDL,
I would hope, naively perhaps, that we can find a single way to make
everybody happy. But again, I've not yet studied the subject in depth.


-- 
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] cver fails Verilog power operator

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

Cver appears to fail the Verilog power operator?  Has anyone else seen this?


GPL CVER Version
"""
GPLCVER_2.12a of 05/16/07 (Mac OSX).
Copyright (c) 1991-2007 Pragmatic C Software Corp.
   All Rights reserved.  Licensed under the GNU General Public License 
(GPL).
"""

Example:

_MyHDL_
     @always_comb
     def rtl_wp():
         wp_p1.next = (wp + 1) % 2**C_ASZ

_Convert Verilog_
     assign spi0_txFifo_wp_p1 = ((spi0_txFifo_wp + 1) % (2 ** 3));



My work around was to change the my MyHDL code to compute the mod value.
_MyHDL_
AddressMod = 2**C_ASZ
@always_comb
     def rtl_wp():
         wp_p1.next = (wp + 1) % AddressMod


The "**" is a Valid power operator in Verilog and Icarus Verilog appears 
to handle it ok (as well as the synthesis tools).  I was wondering if a 
warning should be added?

Side note I have been using Icarus and Cver.  I ran into another error 
using Icarus (probably self induced) and it wasn't clear what the 
problem was so I tried Cver to hopefully shed some light when I hit the 
problem.

.chris

Re: [myhdl-list] Signal getattr and setattr

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

Jan Decaluwe wrote:
> Christopher L. Felton wrote:
>> Jan Decaluwe wrote:
>>> Chris:
>>>
>>> I don't have a lot of time these days (moving to new house) but
>> No problem, this is not a bug often encountered and I have a work around 
>> for accessing the "contained" objects attributes/properties.  Enjoy 
>> moving to the new house!
>>
>>> did your patch mean that __slots__ is the problem?
>> I don't believe __slots__ is the problem.  And you do get the 
>> performance increase from __slots__ but I don't know how much.
>>
>> I believe the issue is how the copy works.  The copy tries to access 
>> variables before they exist?  I don't know the exact mechanism of the 
>> copy but that appears to be the issue.
>>
>> By adding an attribute read in __init__ before it is set, a similar 
>> failure occurs.  Example first line of __init__ print self._val.
>>
>> At this point two options would be remove __getattr__ or add __copy__ 
>> and __deepcopy__ to return a new instance and set attributes manually.
> 
> That seems the good solution.
> 
> Of course, how easy it is depends on what "copying" means. The way I
> think about it, it seems trivial: simply create a new signal with the
> same initial value. This would create a new signal that, in the same
> context, would behave identically to the original, but with for the
> rest all separate data structures internally.
> 
> That is what a "copy" is to me, but what about your application?

Yes, copy to me means the same.  Same as the copy implementations in 
intbv?  Adding the __copy__ and __deepcopy__ makes sense otherwise it is 
passed to the "val" copy implementation.

> 
>>> I would hesitate a lot to apply a patch that customizes __setattr__,
>>> and that makes every attribute access slower.
>> That is a good point, performance impact.  I do like the idea of a 
>> "transparent" Signal object but it is not looking to feasible.  But if 
>> the setattr isn't  propagated to the "contained" object does it make 
>> sense to allow __getattr__?
> 
> Like always, reading an writing are not symmetrical, with reading
> being the easy case :-) Using __getatrr__ to delegate attribute access to
> the current value is exactly how I think a signal should work
> intuitively. It also does what you expect: it only comes into play
> for attributes that don't exist already. But that is not true for
> __setattr__: once it exists, you have to use it for any attribute
> access, which may be tricky and counterintuitive.
> 

Re: [myhdl-list] fixed_point library and VHDL generation

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

> Correct, the intbv would work correctly and the bug is in the fxintbv.
> 
> Simple example why you would use the fxintbv you can do the following
> x = fxintbv(3.142592).  Yes, you could do the conversion by hand and  
> pass the integer to intbv.  The fixed point classes give some  
> additional features when dealing with non-integers numbers.
> 

Embarrassing yes, I fat fingered the value of pi.

Re: [myhdl-list] fixed_point library and VHDL generation

[Felton C. <chr...@gm...>]

On Jan 15, 2010, at 2:31 AM, Jan Decaluwe wrote:

> Jan Langer wrote:
>> Hi all,
>> i have solved my issues regarding Christopher's fixed_point  
>> library :-)
>>
>> There is one more thing I want to share. The following situation:
>>
>> a = Signal(fxintbv(0,Q=(0,16))
>> b = Signal(fxintbv(0,Q=(0,16))
>>
>> i = 2
>>
>> @always(clk.posedge)
>> def beh():
>>    if b < 0:
>>        d = 1
>>    else:
>>        d = -1
>>    a.next = a - ((d*b) >> i)
>>
>> The way I made that code working correctly is just casting a to int:
>> a.next = a*1 - ((d*b) >> i)
>
> What exactly wasn't working correctly? I believe that similar
> code with intbv should work without problems.

Correct, the intbv would work correctly and the bug is in the fxintbv.

Simple example why you would use the fxintbv you can do the following
x = fxintbv(3.142592).  Yes, you could do the conversion by hand and  
pass the integer to intbv.  The fixed point classes give some  
additional features when dealing with non-integers numbers.

>
>> However, this is not the correct way, but I was too lazy to do it  
>> right,
>> and I am still not really sure, what the correct way is.
>>
>> The second thing I want to share were two issues during VHDL  
>> synthesis.
>> First, the assignments of constants of bit lengths greater 32 does  
>> not
>> work. I will append a patch for that, that uses bit strings in this  
>> case.
>
> The convertor has some provisions to handle this type of problems,
> please let me know where it still goes wrong.
>
>> Second, local variables in processes hide global variables on top
>> level. The following code generates wrong VHDL:
>>
>> ---------------------
>>
>> from myhdl import *
>>
>> def Block2(clk,b):
>>    @always(clk.posedge)
>>    def beh():
>>        a = 4
>>        b.next = b + a
>>
>>    return instances()
>>
>> def Block1(clk):
>>    a = Signal(intbv(0)[4:])
>>
>>    b2 = Block2(clk,a)
>>
>>    return instances()
>>
>> clk = Signal(bool(0))
>> toVHDL(Block1,clk)
>>
>> ----------------------
>>
>> You can work around that problem easily by giving unique names, but  
>> its
>> quite annoying and hard to prevent when using third party blocks.
>
> Correct. At this moment, when the hierarchy is flattened, ports and
> signals are given new names in one namespace, and there are no
> provisions to prevent name clashes. I have been thinking about a
> good way to handle all cases, but it's not always that  
> straightforward.
>
>
>>
>> Apart from me always posting about problems or issues I do not
>> understand, I think myhdl is just a great effort in the direction I
>> personally see hardware development evolve in the future.
>>
>> Best regards,
>> Jan
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast  
>> and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
> -- 
> 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
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] fxintbv dependency on dspsim

[Felton C. <chr...@gm...>]

On Jan 15, 2010, at 2:46 AM, Jan Decaluwe wrote:

> Christopher L. Felton wrote:
>> Jan Decaluwe wrote:
>>> I'm not a fixed-point specialist, but am I correct in thinking that
>>> things would be considerably simpler if there would a fixed point
>>> datatype that we could map to in VHDL/Verilog?
>>>
>>> I seem to have read that such a (synthesizable) datatype exists for
>>> VHDL, but not yet for Verilog. But even it's VHDL-only, it seems  
>>> like
>>> an interesting path to investigate?
>>
>> I believe there is a fixed-point type in the latest standard of VHDL
>> (VHDL-2007).  I don't know much more about the new VHDL type.  If  
>> it has
>> been ratified, supported in tools, etc.
>>
>> From a quick search, the VHDL fixed-point type doesn't do
>> auto-promotion (what size should the result be).  The new types
>> introduce the negative index in ranges (???).  I don't think it  
>> supports
>> all features the lib attempts to support.
>>
>> Regardless, I think this is one of highlights of MyHDL to handle  
>> these
>> kinds "types".  I think the current MyHDL approach gives the design  
>> much
>> more flexibility.  A designer might not always want the "default"  
>> rules
>> for handling fixed-point.  If mapped to the VHDL type I think there
>> would be a "collision" of rules and loss of control.
>
> I'm intrigued by these statements, please enlighten me.

Which statements?  My incomplete understanding of the VHDL fixed-point  
support?   Or the flexibility of MyHDL to handle fractional numbers  
without changing the core package?

> With intbv, I have tried (and I believe not without success) to  
> implement
> the single way to do it "right". The basic idea is to let it behave
> as mathematical integers do (and there is little controversy about  
> that.)
> The convertor implements this in Verilog and VHDL with lower
> level types by using type casts and resizings.
> (In contrast, there is a lot of controversy about how such lower level
> types should behave!)

What I am trying to suggest and promote.   Is that, as you mention,  
the intbv handles the integers fine.  WIth fixed point we are trying  
to use fractional numbers like 3.141592.  The MyHDL architecture has a  
nice mechanism to do this.  During elaboration we can perform the  
necessary steps to get our integer representation of our fractional  
number.  Then all the conversion, simulation, etc is handled by the  
intbv.

>
> What you suggest is that with fixed point, something like that would
> not be possible: you suggest that there isn't "one good way to do it".
> I'd like to understand better why you think that is so.

I am doing a poor job of communicating.  I do think adding support  
(external packages) for higher types (fixed-point, floating-point) is  
possible!  Exactly as you say, instead of mapping to the VHDL type in  
MyHDL first map to intbv because the rules are clear!  The goal of the  
fixed point package is to give the developer the tools to map a  
fractional number to an integer representation.  Then intbv handles  
the rest.

The issues with these higher types is discovering a "user friendly"  
mechanism.  I have run across some issues, not necessarily MyHDL  
issues, but things I wanted to do in the elaboration and have not been  
able to do.

Hope that helps explain a little better?


>
> 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
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] fxintbv dependency on dspsim

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

Christopher L. Felton wrote:
> Jan Decaluwe wrote:
>> I'm not a fixed-point specialist, but am I correct in thinking that
>> things would be considerably simpler if there would a fixed point
>> datatype that we could map to in VHDL/Verilog?
>>
>> I seem to have read that such a (synthesizable) datatype exists for
>> VHDL, but not yet for Verilog. But even it's VHDL-only, it seems like
>> an interesting path to investigate?
> 
> I believe there is a fixed-point type in the latest standard of VHDL 
> (VHDL-2007).  I don't know much more about the new VHDL type.  If it has 
> been ratified, supported in tools, etc.
> 
>  From a quick search, the VHDL fixed-point type doesn't do 
> auto-promotion (what size should the result be).  The new types 
> introduce the negative index in ranges (???).  I don't think it supports 
> all features the lib attempts to support.
> 
> Regardless, I think this is one of highlights of MyHDL to handle these 
> kinds "types".  I think the current MyHDL approach gives the design much 
> more flexibility.  A designer might not always want the "default" rules 
> for handling fixed-point.  If mapped to the VHDL type I think there 
> would be a "collision" of rules and loss of control.

I'm intrigued by these statements, please enlighten me.
With intbv, I have tried (and I believe not without success) to implement
the single way to do it "right". The basic idea is to let it behave
as mathematical integers do (and there is little controversy about that.)
The convertor implements this in Verilog and VHDL with lower 
level types by using type casts and resizings.
(In contrast, there is a lot of controversy about how such lower level
types should behave!)

What you suggest is that with fixed point, something like that would
not be possible: you suggest that there isn't "one good way to do it".
I'd like to understand better why you think that is so.

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] fixed_point library and VHDL generation

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

Jan Langer wrote:
> Hi all,
> i have solved my issues regarding Christopher's fixed_point library :-)
> 
> There is one more thing I want to share. The following situation:
> 
> a = Signal(fxintbv(0,Q=(0,16))
> b = Signal(fxintbv(0,Q=(0,16))
> 
> i = 2
> 
> @always(clk.posedge)
> def beh():
>     if b < 0:
>         d = 1
>     else:   
>         d = -1
>     a.next = a - ((d*b) >> i)
> 
> The way I made that code working correctly is just casting a to int: 
> a.next = a*1 - ((d*b) >> i)

What exactly wasn't working correctly? I believe that similar
code with intbv should work without problems.

> However, this is not the correct way, but I was too lazy to do it right, 
> and I am still not really sure, what the correct way is.
> 
> The second thing I want to share were two issues during VHDL synthesis. 
> First, the assignments of constants of bit lengths greater 32 does not 
> work. I will append a patch for that, that uses bit strings in this case.

The convertor has some provisions to handle this type of problems,
please let me know where it still goes wrong.

>  Second, local variables in processes hide global variables on top 
> level. The following code generates wrong VHDL:
> 
> ---------------------
> 
> from myhdl import *
> 
> def Block2(clk,b):
>     @always(clk.posedge)
>     def beh():
>         a = 4
>         b.next = b + a
> 
>     return instances()
> 
> def Block1(clk):
>     a = Signal(intbv(0)[4:])
>     
>     b2 = Block2(clk,a)
> 
>     return instances()
> 
> clk = Signal(bool(0))
> toVHDL(Block1,clk)
> 
> ----------------------
> 
> You can work around that problem easily by giving unique names, but its 
> quite annoying and hard to prevent when using third party blocks.

Correct. At this moment, when the hierarchy is flattened, ports and
signals are given new names in one namespace, and there are no
provisions to prevent name clashes. I have been thinking about a
good way to handle all cases, but it's not always that straightforward.


> 
> Apart from me always posting about problems or issues I do not 
> understand, I think myhdl is just a great effort in the direction I 
> personally see hardware development evolve in the future.
> 
> Best regards,
> Jan
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


-- 
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] Signal getattr and setattr

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

Christopher L. Felton wrote:
> Jan Decaluwe wrote:
>> Chris:
>>
>> I don't have a lot of time these days (moving to new house) but
> 
> No problem, this is not a bug often encountered and I have a work around 
> for accessing the "contained" objects attributes/properties.  Enjoy 
> moving to the new house!
> 
>> did your patch mean that __slots__ is the problem?
> 
> I don't believe __slots__ is the problem.  And you do get the 
> performance increase from __slots__ but I don't know how much.
> 
> I believe the issue is how the copy works.  The copy tries to access 
> variables before they exist?  I don't know the exact mechanism of the 
> copy but that appears to be the issue.
> 
> By adding an attribute read in __init__ before it is set, a similar 
> failure occurs.  Example first line of __init__ print self._val.
> 
> At this point two options would be remove __getattr__ or add __copy__ 
> and __deepcopy__ to return a new instance and set attributes manually.

That seems the good solution.

Of course, how easy it is depends on what "copying" means. The way I
think about it, it seems trivial: simply create a new signal with the
same initial value. This would create a new signal that, in the same
context, would behave identically to the original, but with for the
rest all separate data structures internally.

That is what a "copy" is to me, but what about your application?

>> I would hesitate a lot to apply a patch that customizes __setattr__,
>> and that makes every attribute access slower.
> 
> That is a good point, performance impact.  I do like the idea of a 
> "transparent" Signal object but it is not looking to feasible.  But if 
> the setattr isn't  propagated to the "contained" object does it make 
> sense to allow __getattr__?

Like always, reading an writing are not symmetrical, with reading
being the easy case :-) Using __getatrr__ to delegate attribute access to
the current value is exactly how I think a signal should work
intuitively. It also does what you expect: it only comes into play
for attributes that don't exist already. But that is not true for
__setattr__: once it exists, you have to use it for any attribute
access, which may be tricky and counterintuitive.

-- 
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] Adding Error Messages to MyHDL source

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

Ben wrote:
> On Thu, Dec 17, 2009 at 16:20, Jan Decaluwe <ja...@ja...> wrote:
>> Thanks for using mercurial for patches!
>> I have applied an pushed it.
> 
> Thanks, thank you for using Mercurial as VCS !
> 
>> Note:
>>
>> - It think the idiomatic way to check for None should
>>  use 'is', not '=='
> 
> Make sense, my bad, want a patch that correct it ?
> 
>> - your patch reminds that I have to check whether it really
>> makes sense to support 'None' as an intbv value. I once thought
>> this was necessary to support 'X' and 'Z', but I now think
>> this is not true: we can use special signals for that and
>> leave the intbv simpler and more consistent. Now the 'None'
>> support looks clumsy and half-baked (my bad).
> 
> The main trouble is Signal declaration and the initialisation that
> comes with it, that taken apart, I don't use None as signal value. and
> that's anyway being reported by the traceVCD step. So no trouble for
> me to remove anything None related in the intbv type.

The whole question of tristate modelling is now handled better
with dedicated special signals. So I'm indeed inclined to redo
intbv and remove the "None" value related stuff alltogether.

-- 
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] len() of an intbv

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

sv...@te... wrote:
> Hi all,
> 
> Is ther a particular reason why the number of bits (according to the len() finction is 1 in following example:
> 
> a = intbv(0, min=0, max=1)
> len(a)
> --> returns 1 instead of an expected 0
> 
> I thought 'a' can only store '0' in this case, and you don't need any bits for doing that. 
> 
> b = intbv(0,min=0,max=2)
> len(b)
> --> returns 1
> 
> This is not so important at the moment for me, but it should be interesting to know where this (according to me) unlogical behavior comes from.

intbv.len() returns the minimal bit width required to represent
the possible values with traditional HDL bit vectors:
unsigned for naturals, 2's complement signed for integers.

intbv(0, min=0, max=1) would be mapped to unsigned'"0", with
bit width 1.

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] _cosimulation.py fails on Windows

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

Robert Seczkowski wrote:
> The error is:
> child_pid = self._child_pid = os.fork()
> AttributeError: 'module' object has no attribute 'fork'
> 
> Can anybody point me to the possible reason?
> Is it in myhdl or poython itself.
> Regards
> Robert


http://www.myhdl.org/doku.php/faq#how_can_i_run_co-simulation_on_windows

-- 
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] _cosimulation.py fails on Windows

[Alessandro B. <al...@pm...>]

Python os.fork in not available on Windows platform.
The  code should be refactored to use subprocess module (i didn't  
checked the code
but if this is a call to an external program subprocess.Popen object  
can make it..)

Regards,
Alessandro

On Jan 13, 2010, at 10:21 AM, Robert Seczkowski wrote:

> The error is:
> child_pid = self._child_pid = os.fork()
> AttributeError: 'module' object has no attribute 'fork'
>
> Can anybody point me to the possible reason?
> Is it in myhdl or poython itself.
> Regards
> Robert
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast  
> and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list