myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] MyHDL usable for Transaction Level Modeling ?

[<hma...@fr...>]

Hi,

I'm wondering if/how MyHDL could be used as an ESL language for system
simulations "a la" SystemC but without the burden of C++ ?

I'd like to make simulations of a system on chip (simulate traffic on an
interconnection micronetwork from several initiators like CPU, DSP, DMA, etc...
and dimension accordingly memory bit width, latencies, FIFO sizes, etc...).

I'm aware speed might be an issue depending on teh level of modeling used, but
for a high-level TLM I'm not scared a priori.

It strikes me that Python should be used for ESL, andif MyHDL for some reason is
not suitable, at least the same generator mechanism could be reused.

Obviously, the Verilog converter is of lesser interest in this case. May be a
SystemC converter .. ?

Any comment ?

Regards,
Hervé

[myhdl-list] 0.6dev7

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

Development version 0.6dev7 is available from here:

     http://myhdl.jandecaluwe.com/doku.php/dev:snapshots#snapshots

* All outstanding bugs have been addressed and changed to "Pending" status.
* issue with bit inversion on intbv's addressed, as discussed recently in
the mailing list.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Issue with namespaces after conversion

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

For the next development release I want to address all outstanding
bug requests. I have implemented a satisfactory fix for all of them
except one, and I'd like to make everyone aware of this.

The problem is that conversion flattens hierarchy, and signals get renamed
to have a "global" name that is non-conflicting among themselves.
However, those new names may conflict with "local" names from variables
within generators/processes/always blocks. This issue is not detected
in current releases.

The way to solve this would be to change local names if necessary. However,
this is not so trivial. Moreover, there are other naming issues (e.g.
VHDL and Verilog keywords are not detected at this moment) so this
calls for a general solution that solves all naming issues at once.

But there's no time to do that now. So what I have implemented is simply
to detect the situation and flag it as an "error". This is not satisfactory,
but at least you'll get an early warning.

The bug report in question lives here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1837003&group_id=91207&atid=596332

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Cosimulation with Modelsim

[Kanchan D. <kan...@gm...>]

I had been running cosimulation with icarus but discovered that certain
features (such as  arrays of nets)  are not supported by icarus. My verilog
code (with arrays of nets) does work with Modelsim though. Hence I was
wondering if anyone has worked on cosimulation using Modelsim, and if not,
could I get some pointers as to how I should start modifying the PLI so that
I can cosimulate using Modelsim?

Thanks
Kanchan

Re: [myhdl-list] Bit-wise inversion issue

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

Jan Decaluwe wrote:

> Conclusion
> ----------
> 
> The drawback of the "Pure Python" solution is probably fatal
> for practical purposes. Therefore, I propose to keep the
> "Practical Hardware" solution.

I have implemented this, including conversion support for
Verilog and VHDL.

This will be included in the upcoming development release 0.6dev7.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Bit-wise inversion issue

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

Christopher L. Felton wrote:


> If I am following, the "Practical Hardware" solution is the proposal,  
> but it has the "disturbing" attribute (operate(s) having to look at  
> the constraints).
> The solution will include the positive and negative intbv (as far as  
> the ~ operator goes)?

Yes.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Bit-wise inversion issue

[Christopher L. F. <cf...@uc...>]

On Mar 3, 2008, at 10:55 AM, Jan Decaluwe wrote:

> Ok, let's try to reach a decision.
>
> I believe there are 2 solutions that can be defended.
>
> Possible solutions
> ------------------
>
> 1) "Pure Python"
> Bit inversion for intbv's behaves like for Python int's.
>
> 2) "Practical Hardware"
> Make an exception for intbv's whose allowed values are
> a finite set of positive values. Let's call these p-intbv's.
> For a p-intbv, bits outside the bit range of an unsigned
> representation, are assumed to remain zero upon bit-inversion.
>
> Analysis
> --------
> Both solutions have advantages and drawbacks.
>
> The major drawback of the "Pure Python" solution is that it
> may be counter-intuitive to hardware designers. Many designs
> mainly use p-intbvs, e.g. created by the form intbv(0)[n:].
> But with this solution it would not be possible to represent
> the bit-inversion of a p-intbv by another p-intbv. Negative
> values would have to be introduced just for this purpose.
>
> The major drawback of the "Practical Hardware" solution is
> that the result of a bit-inversion would not just depend
> on the intbv value, but also on its constraints. It is the
> only operator for which this would be so. This is disturbing.
>
> Conclusion
> ----------
>
> The drawback of the "Pure Python" solution is probably fatal
> for practical purposes. Therefore, I propose to keep the
> "Practical Hardware" solution. This is in line with the
> feedback from this thread thus far.

If I am following, the "Practical Hardware" solution is the proposal,  
but it has the "disturbing" attribute (operate(s) having to look at  
the constraints).
The solution will include the positive and negative intbv (as far as  
the ~ operator goes)?

I agree with the "disturbing" to a new user it may not be clear why or  
how a negative number is represented.  And it also falls out of the  
standard implementation (kinda a kludge).

Overall I think it is a fair compromise / solution.


>
>
> Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

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

Ok, let's try to reach a decision.

I believe there are 2 solutions that can be defended.

Possible solutions
------------------

1) "Pure Python"
Bit inversion for intbv's behaves like for Python int's.

2) "Practical Hardware"
Make an exception for intbv's whose allowed values are
a finite set of positive values. Let's call these p-intbv's.
For a p-intbv, bits outside the bit range of an unsigned
representation, are assumed to remain zero upon bit-inversion.

Analysis
--------
Both solutions have advantages and drawbacks.

The major drawback of the "Pure Python" solution is that it
may be counter-intuitive to hardware designers. Many designs
mainly use p-intbvs, e.g. created by the form intbv(0)[n:].
But with this solution it would not be possible to represent
the bit-inversion of a p-intbv by another p-intbv. Negative
values would have to be introduced just for this purpose.

The major drawback of the "Practical Hardware" solution is
that the result of a bit-inversion would not just depend
on the intbv value, but also on its constraints. It is the
only operator for which this would be so. This is disturbing.

Conclusion
----------

The drawback of the "Pure Python" solution is probably fatal
for practical purposes. Therefore, I propose to keep the
"Practical Hardware" solution. This is in line with the
feedback from this thread thus far.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Bit-wise inversion issue

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

On Thursday 28 February 2008 03:36:37 pm Jan Decaluwe wrote:
> Tom Dillon wrote:
> > I don't think the sliced result gets ._nrbits .min or .max set.
> >
> > I think it should, at least for clarification.
>
> Actually a slice returns a new intbv with _nrbits, min and max set.
> (this is the idiomatic way to create an "unsigned", hardware-oriented
> intbv).
>
sorry, I misunderstood the example I ran to come to the conclusion they weren't set. I was wrong, it 
seems fine to me the way it is.

Re: [myhdl-list] Bit-wise inversion issue

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

Tom Dillon wrote:
> I don't think the sliced result gets ._nrbits .min or .max set. 
> 
> I think it should, at least for clarification.

Actually a slice returns a new intbv with _nrbits, min and max set.
(this is the idiomatic way to create an "unsigned", hardware-oriented
intbv).

But it is the only operator that does this. All others currently
return unsized intbv's or even int's.

This is usually not an issue, because the idiomiatic MyHDL usage
for updates is:

for intbv's:
    a[m:n] = <expression>
in particular, to set a new value:
    a[:] = <expression>
and for signals:
    s.next = <expression>

Therefore, I don't need to look at the right-hand expression to derive
a bit width. In this way, all issues with this as in VHDL and especially
Verilog are simply avoided. And of course I can optimize a little
(and keep it simple) by not worrying about setting bit widths on operator
results. Last but not least, I don't think that conversion to VHDL or
Verilog would otherwise be feasible.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Bit-wise inversion issue

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

Christopher L. Felton wrote:
> Is the following expected behavior?
> 
>> >> y = intbv(15)[4:]
>> >> ~y
> intbv(0L)
>> >> z = ~y
>> >> z._nrbits
> 0
>> >> 
> 
> The new number of bits is 0? 

Now you know why it's a private variable :-)
Seriously, I use 0 (False) to indicate that the nr of bits
is undefined.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Bit-wise inversion issue

[Christopher L. F. <cf...@uc...>]

Here is a possible enhancement,

from _intbv.py around line 407

<<code>>
     def __invert__(self):
         if self._nrbits:
             if self._min < 0:
                 return intbv(~self._val, min=self._min, max=self._max)
             else:
                 return intbv(~self._val & (1L << self._nrbits)-1)
         else:
             return intbv(~self._val)
<<>>

I ran the test scripts, it didn't break anything.  Also the sequential  
mult that I sent works with the 2's comp flip.


On Feb 28, 2008, at 7:00 AM, Christopher L. Felton wrote:

> Is the following expected behavior?
>
> >>> y = intbv(15)[4:]
> >>> ~y
> intbv(0L)
> >>> z = ~y
> >>> z._nrbits
> 0
> >>>
>
> The new number of bits is 0?  I think in normal case this is fine  
> because usually it would be Signal.next, and the Signal type  
> wouldn't be overridden only the value?
>
>
> On Feb 27, 2008, at 2:41 PM, Tom Dillon wrote:
>
>> Jan,
>>
>> On Wednesday 27 February 2008 02:33:57 pm Jan Decaluwe wrote:
>>
>>>>
>>>> intbv(5)[3:] is unsigned, so I think 2L is the right answer.
>>>
>>> That's not how I think about it. (Warning: this may get subtle.)
>>> To me, intbv(5)[3:] is simply intbv(5) with constraints on the  
>>> allowed
>>> values. If the constraints are such that the value must be positive,
>>> then we can choose to represent such an intbv as an unsigned in
>>> another language such as Verilog or VHDL. An optimization really.
>>
>> yes, I agree with you thinking there. I was thinking the slice  
>> would produce an unsigned intbv, but
>> of course that is wrong.
>>
>> I think it has to make sense and be as simple as possible in MyHDL  
>> and force the translation to
>> Verilog or VHDL to produce the same results.
>>
>>>
>>> On the other hand, I see your point of course. We should be
>>> practical. I have to think further, there may be compromise  
>>> solutions.
>>>
>>> In any case, there really is something wrong. Consider:
>>>>>> ~intbv(5, min=-6, max=6)
>>>
>>> intbv(10L)
>>
>> What about ~intbv(5,min=0, max=15)?
>>
>> intbv(10L)
>>
>> I think that is correct.
>>
>> Tom
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

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

I don't think the sliced result gets ._nrbits .min or .max set. 

I think it should, at least for clarification.

Tom


On Thursday 28 February 2008 08:00:24 am Christopher L. Felton wrote:
> Is the following expected behavior?
>
>  >>> y = intbv(15)[4:]
>  >>> ~y
>
> intbv(0L)
>
>  >>> z = ~y
>  >>> z._nrbits
>
> 0
>
>
> The new number of bits is 0?  I think in normal case this is fine
> because usually it would be Signal.next, and the Signal type wouldn't
> be overridden only the value?
>
> On Feb 27, 2008, at 2:41 PM, Tom Dillon wrote:
> > Jan,
> >
> > On Wednesday 27 February 2008 02:33:57 pm Jan Decaluwe wrote:
> >>> intbv(5)[3:] is unsigned, so I think 2L is the right answer.
> >>
> >> That's not how I think about it. (Warning: this may get subtle.)
> >> To me, intbv(5)[3:] is simply intbv(5) with constraints on the
> >> allowed
> >> values. If the constraints are such that the value must be positive,
> >> then we can choose to represent such an intbv as an unsigned in
> >> another language such as Verilog or VHDL. An optimization really.
> >
> > yes, I agree with you thinking there. I was thinking the slice would
> > produce an unsigned intbv, but
> > of course that is wrong.
> >
> > I think it has to make sense and be as simple as possible in MyHDL
> > and force the translation to
> > Verilog or VHDL to produce the same results.
> >
> >> On the other hand, I see your point of course. We should be
> >> practical. I have to think further, there may be compromise
> >> solutions.
> >>
> >> In any case, there really is something wrong. Consider:
> >>>>> ~intbv(5, min=-6, max=6)
> >>
> >> intbv(10L)
> >
> > What about ~intbv(5,min=0, max=15)?
> >
> > intbv(10L)
> >
> > I think that is correct.
> >
> > Tom
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

[Christopher L. F. <cf...@uc...>]

Is the following expected behavior?

 >>> y = intbv(15)[4:]
 >>> ~y
intbv(0L)
 >>> z = ~y
 >>> z._nrbits
0
 >>>

The new number of bits is 0?  I think in normal case this is fine  
because usually it would be Signal.next, and the Signal type wouldn't  
be overridden only the value?


On Feb 27, 2008, at 2:41 PM, Tom Dillon wrote:

> Jan,
>
> On Wednesday 27 February 2008 02:33:57 pm Jan Decaluwe wrote:
>
>>>
>>> intbv(5)[3:] is unsigned, so I think 2L is the right answer.
>>
>> That's not how I think about it. (Warning: this may get subtle.)
>> To me, intbv(5)[3:] is simply intbv(5) with constraints on the  
>> allowed
>> values. If the constraints are such that the value must be positive,
>> then we can choose to represent such an intbv as an unsigned in
>> another language such as Verilog or VHDL. An optimization really.
>
> yes, I agree with you thinking there. I was thinking the slice would  
> produce an unsigned intbv, but
> of course that is wrong.
>
> I think it has to make sense and be as simple as possible in MyHDL  
> and force the translation to
> Verilog or VHDL to produce the same results.
>
>>
>> On the other hand, I see your point of course. We should be
>> practical. I have to think further, there may be compromise  
>> solutions.
>>
>> In any case, there really is something wrong. Consider:
>>>>> ~intbv(5, min=-6, max=6)
>>
>> intbv(10L)
>
> What about ~intbv(5,min=0, max=15)?
>
> intbv(10L)
>
> I think that is correct.
>
> Tom
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

[Christopher L. F. <cf...@uc...>]

Does this make sense, and is it possible (easily possible)

intbv(5)                     -> signed, because this is consistent with
                                 default python as you showed
                                 default min=-??, default max=??

intbv(5)[4:]                 ->  unsigned, has the feel of
                                  Verilog/VHDL bit-vectors
                                  default min=0, default max=16

intbv(5, min=0, max=15)      -> unsigned because explicitly defined no  
min

intbv(5, min=-8, max=7)      -> signed because explicitly defined min

intbv(5, min=-8, max=7)[4:]  -> ??

 >>> x = intbv(5, min=-8, max=7)[4:]
 >>> x
intbv(5L)
 >>> dir(x)
 >>> x._nrbits
4
 >>> x._val
5L
 >>> x.max
16
 >>> x.min
0
 >>>

Think the above would be somewhat straight forward, since the last  
example shows that the [4:] syntax overrides the min.

Chris

On Feb 27, 2008, at 1:33 PM, Jan Decaluwe wrote:

>
>>>> ~intbv(5, min=-6, max=6)
> intbv(10L)
>
> This intbv would have to be represented by a signed in a target
> language, yet bitwise inversion still returns a positive number
> with the current implementation. As a miminum, this should be
> fixed - if someone disagrees, let me know.
>
> Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

[Christopher F. <cf...@uc...>]

> In any case, there really is something wrong. Consider:
> 
> >>> ~intbv(5, min=-6, max=6)
> intbv(10L)
>
> This intbv would have to be represented by a signed in a target
> language, yet bitwise inversion still returns a positive number
> with the current implementation. As a miminum, this should be
> fixed - if someone disagrees, let me know.

I agree, we are representing 2 types (at least in Verilog speak) with
intbv.  Unsigned bit vectors and signed bit vectors.  As you pointed
out we need to determine what is the correct usage given the context.

As Tom pointed out for the bit vector that would be the expected value
but for a signed bit vector value you will run into the problem above.

Thanks!

Re: [myhdl-list] Bit-wise inversion issue

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

Jan,

On Wednesday 27 February 2008 02:33:57 pm Jan Decaluwe wrote:

> >
> > intbv(5)[3:] is unsigned, so I think 2L is the right answer.
>
> That's not how I think about it. (Warning: this may get subtle.)
> To me, intbv(5)[3:] is simply intbv(5) with constraints on the allowed
> values. If the constraints are such that the value must be positive,
> then we can choose to represent such an intbv as an unsigned in
> another language such as Verilog or VHDL. An optimization really.

yes, I agree with you thinking there. I was thinking the slice would produce an unsigned intbv, but 
of course that is wrong.

I think it has to make sense and be as simple as possible in MyHDL and force the translation to 
Verilog or VHDL to produce the same results.

>
> On the other hand, I see your point of course. We should be
> practical. I have to think further, there may be compromise solutions.
>
> In any case, there really is something wrong. Consider:
>  >>> ~intbv(5, min=-6, max=6)
>
> intbv(10L)

What about ~intbv(5,min=0, max=15)?

intbv(10L)

I think that is correct.

Tom

Re: [myhdl-list] Bit-wise inversion issue

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

Tom Dillon wrote:

> I'm not sure there is anything wrong, although I may not fully understand...
> 
> On Wednesday 27 February 2008 10:06:33 am Jan Decaluwe wrote:
> 
>>Chris Felton has recently signalled an issue with bit-wise
>>inversion. Hereby an analysis.
>>
>>Consider the following interpreter log:
>> >>> from myhdl import *
>> >>> ~5
>>-6
> 
> That is because a python int is signed, right?
> 
>> >>> ~intbv(5)
>>intbv(-6)
> 
> default intbv must be signed as well.
> 
>> >>> ~intbv(5)[3:]
>>intbv(2L)
> 
> intbv(5)[3:] is unsigned, so I think 2L is the right answer.

That's not how I think about it. (Warning: this may get subtle.)
To me, intbv(5)[3:] is simply intbv(5) with constraints on the allowed
values. If the constraints are such that the value must be positive,
then we can choose to represent such an intbv as an unsigned in
another language such as Verilog or VHDL. An optimization really.

On the other hand, I see your point of course. We should be
practical. I have to think further, there may be compromise solutions.

In any case, there really is something wrong. Consider:

 >>> ~intbv(5, min=-6, max=6)
intbv(10L)

This intbv would have to be represented by a signed in a target
language, yet bitwise inversion still returns a positive number
with the current implementation. As a miminum, this should be
fixed - if someone disagrees, let me know.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Bit-wise inversion issue

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

Hi,

I'm not sure there is anything wrong, although I may not fully understand...

On Wednesday 27 February 2008 10:06:33 am Jan Decaluwe wrote:
> Chris Felton has recently signalled an issue with bit-wise
> inversion. Hereby an analysis.
>
> Consider the following interpreter log:
>  >>> from myhdl import *
>  >>> ~5
> -6

That is because a python int is signed, right?
>
>  >>> ~intbv(5)
> intbv(-6)

default intbv must be signed as well.

>
>  >>> ~intbv(5)[3:]
>intbv(2L)

intbv(5)[3:] is unsigned, so I think 2L is the right answer. 

I would not expect a unsigned to get changed to signed with the ~ operator.

So I think the only question is should intbv(5)[3:] result in a signed or unsigned result?

I don't know if I would use Verilog as the guideline for how anything signed should work, as the 
Verilog rules are fairly complicated (overly I think).

Tom

[myhdl-list] Bit-wise inversion issue

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

Chris Felton has recently signalled an issue with bit-wise
inversion. Hereby an analysis.

Consider the following interpreter log:

 >>> from myhdl import *
 >>> ~5
-6
 >>> ~intbv(5)
intbv(-6)
 >>> ~intbv(5)[3:]
intbv(2L)

You can see that an "unsized" intbv behaves like an int,
but a "sized" intbv behaves differently. Obviously confusing.

Why is this? The answer is in the original support for
conversion to Verilog and VHDL. Originally, only unsigned
values were supported. But in Verilog and VHDL those
don't behave like a Python int: bit-wise inversion of
an unsigned (and therefore positive) number still returns
a positive number. In contrast, the sign of an int
is always changed upon bit-wise inversion.

I modified the behavior of sized intbv's to mimic Verilog
behavior. In this way the original convertor could support
bit-wise inversion without signed/unsigned machinery. This
behavior has not been changed since.

Looking at this now, I think it is wrong. A sized intbv
should also behave like a Python int. So I think the current
behavior should be changed.

The convertor should cast unsigned arguments to signed,
to get the desired result (hopefully, to be checked).

This would imply a backward-incompatible change of intbv
behavior (but it could be viewed as a bug fix). So please
review this carefully and give feedback if necessary.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Array ports in verilog conversion

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

Leonardo Laguna Ruiz wrote:
> Hi!
> 
> I'm trying to make a block with an undefined number of inputs and outputs.
> An example is shown below. This in simulation works fine, and in the verilog
> conversion the only thing that does not work is that the 'us' and 'ds' ports
> are not defined.
> 
> Is there any way to explicitly declare that a module has the ports 'us' and
> 'ds', and these are arrays of bool signals ?????  

Unfortunately no, the problem is how to map these to Verilog ports.

However, this restriction only applies to the very top-level - for internal
modules you can use list of signals and convert to Verilog.

You may want to read the following cookbook design report; it deals with
these issues (and other ones) explicitly:

    http://myhdl.jandecaluwe.com/doku.php/cookbook:bitonic

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] newb question

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

Christopher L. Felton wrote:
> Oooppss, the simulation error I get is
> 
> <<Error>>
> ValueError: intbv value 552501280646915 >= maximum 281474976710656
> 
> << >>
> 
> Instead of performing 2's complement it greats a very large number.

I think I identified the problem, but it deserves some thought and
discussion. I'll start a specific thread about the issue.

Jan

> 
> The simulation should be ran as:
>  >> python mult_seq_hdl.py trace_s n
> 
> Not the previous
> 
> 
> On Feb 26, 2008, at 4:25 PM, Christopher L. Felton wrote:
> 
> 
>>Yes, I get that issue as well  (recently grabbed the latest  
>>development snapshot).
>>
>>The original error I observed was during simulation, I attached my  
>>file that has the testbench also.  I get an overflow during  
>>simulation.
>>
>>
>>The testbench can be run as >> python mult_seq_hdl.py trace n
>><mult_seq_hdl.py>
>>
>>
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Array ports in verilog conversion

[Leonardo L. R. <leo...@up...>]

Hi!

I'm trying to make a block with an undefined number of inputs and outputs.
An example is shown below. This in simulation works fine, and in the verilog
conversion the only thing that does not work is that the 'us' and 'ds' ports
are not defined.

Is there any way to explicitly declare that a module has the ports 'us' and
'ds', and these are arrays of bool signals ?????  


--------------------------------------------
def my_block (clk,us,ds):
    
    my_block_array =[ my_sub_block(clk,us[i],ds[i]) for i in range(4) ]

    return my_block_array

---------------------------------------------
us =  [ Signal(bool(0)) for i in range(4) ] 
ds =  [ Signal(bool(0)) for i in range(4) ]

my_block_instance = my_block(clk,us,ds)
--------------------------------------------


generated verilog:
--------------------
module my_block (
    clk
);



Thanks



Leonardo Laguna Ruiz
PhD. Student
 
Centro de Electrónica Industrial
E.T.S.I. Industriales
Universidad Politécnica de Madrid (UPM)

leo...@up...

Re: [myhdl-list] newb question

[Christopher L. F. <cf...@uc...>]

Oooppss, the simulation error I get is

<<Error>>
ValueError: intbv value 552501280646915 >= maximum 281474976710656

<< >>

Instead of performing 2's complement it greats a very large number.

The simulation should be ran as:
 >> python mult_seq_hdl.py trace_s n

Not the previous


On Feb 26, 2008, at 4:25 PM, Christopher L. Felton wrote:

> Yes, I get that issue as well  (recently grabbed the latest  
> development snapshot).
>
> The original error I observed was during simulation, I attached my  
> file that has the testbench also.  I get an overflow during  
> simulation.
>
>
> The testbench can be run as >> python mult_seq_hdl.py trace n
> <mult_seq_hdl.py>
>
>

Re: [myhdl-list] newb question

[Christopher L. F. <cf...@uc...>]

Yes, I get that issue as well  (recently grabbed the latest  
development snapshot).

The original error I observed was during simulation, I attached my  
file that has the testbench also.  I get an overflow during simulation.


The testbench can be run as >> python mult_seq_hdl.py trace n