myhdl-list

[myhdl-list] intbv bit slicing in component instantiation

[Josy B. <jo...@c-...>]

While building a list of generated components:
   elements = [None for _ in range(RATIO_BA)]
   for i in range(RATIO_BA):
      elements[i] = ram3port( NUM_ENTRIES / RATIO_BA, WIDTH_D,
                           clkA, laddressa , dataA, wren_Z[i], 
                           lqa[(i+1) * WIDTH_D : i * WIDTH_D],
                           clkB, addressB, lqb[(i+1) * WIDTH_D : i * WIDTH_D],
                           0 , 0 ) 
1. The simulator showed that the wren_Z[i] had no effect. I experimented with 
different techniques to generate the wren_Z intbv signal, but no result...
Until I checked some examples on the MyHDL web-site, and there I found the 
use of wren_Z(i) which was well accepted. This differs from the MyHDL 
reference:
   Operation	Result  	 Notes
   bv[i]	item i of bv	(1)


2. The to_VHDL convertor flagged that lqa and lqb were not driven. Does that 
mean that we can not connect a slice of an intbv to receive the output of a 
component? I worked around that by changing the single Signal(intbv(0)
[WIDTH_D*RATIO_BA:]) into  [Signal(intbv(0)[WIDTH_D:]) for _ in range
(RATIO_BA)] which I could then connect as lqa[i] and lqb[i]. I then manually 
assembled the bigger output intbv from the parts.

Re: [myhdl-list] intbv bit slicing in component instantiation

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

On 4/22/14 5:02 AM, Josy Boelen wrote:
> While building a list of generated components:
>     elements = [None for _ in range(RATIO_BA)]
>     for i in range(RATIO_BA):
>        elements[i] = ram3port( NUM_ENTRIES / RATIO_BA, WIDTH_D,
>                             clkA, laddressa , dataA, wren_Z[i],
>                             lqa[(i+1) * WIDTH_D : i * WIDTH_D],
>                             clkB, addressB, lqb[(i+1) * WIDTH_D : i * WIDTH_D],
>                             0 , 0 )
> 1. The simulator showed that the wren_Z[i] had no effect. I experimented with
> different techniques to generate the wren_Z intbv signal, but no result...
> Until I checked some examples on the MyHDL web-site, and there I found the
> use of wren_Z(i) which was well accepted. This differs from the MyHDL
> reference:
>     Operation	Result  	 Notes
>     bv[i]	item i of bv	(1)
>

An /intbv/ bits need to stay together, assuming:

     wren_Z = intbv(0)[RATIO_B:]

If you want to separate the bits you need to create
/SliceSignals/ [1][2] as you did, with the "()" instead
of "[]".  The reason is, each bit needs a /Signal/ to
each module.

Since you do not use the collection of bits (wren_Z) as
a whole (e.g. to represent a bounded integer) you can
define it as:

     wren_Z - [Signal(bool(0)) for _ in range(RATIO_BA)]

and use a list of signals as the bit-vector instead of an
/intbv/ then you do not need to break out the /SliceSignals/
and it can be driven from multiple sources.

>
> 2. The to_VHDL convertor flagged that lqa and lqb were not driven. Does that
> mean that we can not connect a slice of an intbv to receive the output of a
> component? I worked around that by changing the single Signal(intbv(0)
> [WIDTH_D*RATIO_BA:]) into  [Signal(intbv(0)[WIDTH_D:]) for _ in range
> (RATIO_BA)] which I could then connect as lqa[i] and lqb[i]. I then manually
> assembled the bigger output intbv from the parts.
>

In general you can not drive slice signals from multiple
generators - if that were the case you should see an error
in conversion (see [2] for more information and background).
These signals must not be driven anywhere to receive the not
driven message.

Regards,
Chris


[1] 
http://docs.myhdl.org/en/latest/manual/structure.html#converting-between-lists-of-signals-and-bit-vectors
[2] http://dev.myhdl.org/meps/mep-105.html

Re: [myhdl-list] intbv bit slicing in component instantiation

[Josy B. <jo...@c-...>]

Christopher Felton <chris.felton <at> gmail.com> writes:

> 
> On 4/22/14 5:02 AM, Josy Boelen wrote:
> > While building a list of generated components:
> >     elements = [None for _ in range(RATIO_BA)]
> >     for i in range(RATIO_BA):
> >        elements[i] = ram3port( NUM_ENTRIES / RATIO_BA, WIDTH_D,
> >                             clkA, laddressa , dataA, wren_Z[i],
> >                             lqa[(i+1) * WIDTH_D : i * WIDTH_D],
> >                             clkB, addressB, lqb[(i+1) * WIDTH_D : i * 
WIDTH_D],
> >                             0 , 0 )
> > 1. The simulator showed that the wren_Z[i] had no effect. I 
experimented with
> > different techniques to generate the wren_Z intbv signal, but no 
result...
> > Until I checked some examples on the MyHDL web-site, and there I found 
the
> > use of wren_Z(i) which was well accepted. This differs from the MyHDL
> > reference:
> >     Operation	Result  	 Notes
> >     bv[i]	item i of bv	(1)
> >
> 
> An /intbv/ bits need to stay together, assuming:
> 
>      wren_Z = intbv(0)[RATIO_B:]
> 
> If you want to separate the bits you need to create
> /SliceSignals/ [1][2] as you did, with the "()" instead
> of "[]".  The reason is, each bit needs a /Signal/ to
> each module.
> 
> Since you do not use the collection of bits (wren_Z) as
> a whole (e.g. to represent a bounded integer) you can
> define it as:
> 
>      wren_Z - [Signal(bool(0)) for _ in range(RATIO_BA)]
> 
> and use a list of signals as the bit-vector instead of an
> /intbv/ then you do not need to break out the /SliceSignals/
> and it can be driven from multiple sources.
> 
Actually wren_Z is driven by another component (a 1 to n decoder), although 
in that module every 'bit' is set individually.
The distinction to make in either using an /intbv/ or a /list of bool/ is 
something I'll have to get used to. I just tried that and had to change the 
code for the decoder too from z.next[i] in to z[i].next (which is what I 
initially wrote instinctively)

> >
> > 2. The to_VHDL convertor flagged that lqa and lqb were not driven. Does 
that
> > mean that we can not connect a slice of an intbv to receive the output 
of a
> > component? I worked around that by changing the single Signal(intbv(0)
> > [WIDTH_D*RATIO_BA:]) into  [Signal(intbv(0)[WIDTH_D:]) for _ in range
> > (RATIO_BA)] which I could then connect as lqa[i] and lqb[i]. I then 
manually
> > assembled the bigger output intbv from the parts.
> >
> 
> In general you can not drive slice signals from multiple
> generators - if that were the case you should see an error
> in conversion (see [2] for more information and background).
> These signals must not be driven anywhere to receive the not
> driven message.
> 
Coming from the VHDL world some of the MyHDL constructs/concepts are a bit 
counter-intuitive. Actually it would be nice if some of the VHDL constructs 
(like 2Dx1D and other levels of arrays) would be possible. I could have 
written my ram3portmixedwidths in one go (without having to instantiate 
multiple single ram3port modules) and neither of the two pitfalls would 
have come up, but surely another one ...
 
> Regards,
> Chris
> 
Thanks for your quick and helpful answer.
Regards,
Josy
> [1] 
> http://docs.myhdl.org/en/latest/manual/structure.html#converting-between-
lists-of-signals-and-bit-vectors
> [2] http://dev.myhdl.org/meps/mep-105.html
> 
> 
----------------------------------------------------------------------------
--
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> 

Re: [myhdl-list] intbv bit slicing in component instantiation

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

On 4/22/2014 6:41 AM, Josy Boelen wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
<snip>
>>> Until I checked some examples on the MyHDL web-site, and there I found
> the
>>> use of wren_Z(i) which was well accepted. This differs from the MyHDL
>>> reference:
>>>      Operation	Result  	 Notes
>>>      bv[i]	item i of bv	(1)
>>>
>>
>> An /intbv/ bits need to stay together, assuming:
>>
>>       wren_Z = intbv(0)[RATIO_B:]
>>
>> If you want to separate the bits you need to create
>> /SliceSignals/ [1][2] as you did, with the "()" instead
>> of "[]".  The reason is, each bit needs a /Signal/ to
>> each module.
>>
>> Since you do not use the collection of bits (wren_Z) as
>> a whole (e.g. to represent a bounded integer) you can
>> define it as:
>>
>>       wren_Z - [Signal(bool(0)) for _ in range(RATIO_BA)]
>>
>> and use a list of signals as the bit-vector instead of an
>> /intbv/ then you do not need to break out the /SliceSignals/
>> and it can be driven from multiple sources.
>>
> Actually wren_Z is driven by another component (a 1 to n decoder), although
> in that module every 'bit' is set individually.
> The distinction to make in either using an /intbv/ or a /list of bool/ is
> something I'll have to get used to. I just tried that and had to change the
> code for the decoder too from z.next[i] in to z[i].next (which is what I
> initially wrote instinctively)
>

In the MEP [2]
http://dev.myhdl.org/meps/mep-105.html

Jan has a good explanation of V* behavior and why MyHDL is
different.  And yes, I agree the /intbv/ vs. /list of bool/
takes some experience / user preference.

You also have other alternatives, you can use an "interface"
[3] to define your bus.  If you want to convert with 0.8 you
need to reference the interface attributes explicitly in the
modules.  In 0.9 (development branch is stable thanks to the
exhaustive unit tests) the interfaces are converted.

>>>
>>> 2. The to_VHDL convertor flagged that lqa and lqb were not driven. Does
> that
>>> mean that we can not connect a slice of an intbv to receive the output
> of a
>>> component? I worked around that by changing the single Signal(intbv(0)
>>> [WIDTH_D*RATIO_BA:]) into  [Signal(intbv(0)[WIDTH_D:]) for _ in range
>>> (RATIO_BA)] which I could then connect as lqa[i] and lqb[i]. I then
> manually
>>> assembled the bigger output intbv from the parts.
>>>
>>
>> In general you can not drive slice signals from multiple
>> generators - if that were the case you should see an error
>> in conversion (see [2] for more information and background).
>> These signals must not be driven anywhere to receive the not
>> driven message.
>>
> Coming from the VHDL world some of the MyHDL constructs/concepts are a bit
> counter-intuitive. Actually it would be nice if some of the VHDL constructs
> (like 2Dx1D and other levels of arrays) would be possible. I could have
> written my ram3portmixedwidths in one go (without having to instantiate
> multiple single ram3port modules) and neither of the two pitfalls would
> have come up, but surely another one ...
>

I am sure many C to Python programmers have made similar
comments :)  I agree - those of us that have significant
experience with V*, somethings are odd compared to V* but in
reality they are better in MyHDL but we have conditioned
ourselves to the V* way of doing things.

I am not sure if I am following your 2Dx1D examples, you
should be able to use arrays (2D, 3D, etc. actually I have
never used/tested anything above 2D but I don't think there
is a limitation)?

Regards,
Chris

[1] 
http://docs.myhdl.org/en/latest/manual/structure.html#converting-between-lists-of-signals-and-bit-vectors
[2] http://dev.myhdl.org/meps/mep-105.html
[3] http://dev.myhdl.org/meps/mep-107.html

Re: [myhdl-list] intbv bit slicing in component instantiation

[Josy B. <jo...@c-...>]

Christopher Felton <chris.felton <at> gmail.com> writes:

> 
> On 4/22/2014 6:41 AM, Josy Boelen wrote:
> > Christopher Felton <chris.felton <at> gmail.com> writes:
> >
> <snip>
> >>> Until I checked some examples on the MyHDL web-site, and there I found
> > the
> >>> use of wren_Z(i) which was well accepted. This differs from the MyHDL
> >>> reference:
> >>>      Operation	Result  	 Notes
> >>>      bv[i]	item i of bv	(1)
> >>>
> >>
> >> An /intbv/ bits need to stay together, assuming:
> >>
> >>       wren_Z = intbv(0)[RATIO_B:]
> >>
> >> If you want to separate the bits you need to create
> >> /SliceSignals/ [1][2] as you did, with the "()" instead
> >> of "[]".  The reason is, each bit needs a /Signal/ to
> >> each module.
> >>
> >> Since you do not use the collection of bits (wren_Z) as
> >> a whole (e.g. to represent a bounded integer) you can
> >> define it as:
> >>
> >>       wren_Z - [Signal(bool(0)) for _ in range(RATIO_BA)]
> >>
> >> and use a list of signals as the bit-vector instead of an
> >> /intbv/ then you do not need to break out the /SliceSignals/
> >> and it can be driven from multiple sources.
> >>
> > Actually wren_Z is driven by another component (a 1 to n decoder), 
although
> > in that module every 'bit' is set individually.
> > The distinction to make in either using an /intbv/ or a /list of bool/ 
is
> > something I'll have to get used to. I just tried that and had to change 
the
> > code for the decoder too from z.next[i] in to z[i].next (which is what I
> > initially wrote instinctively)
> >
> 
> In the MEP [2]
> http://dev.myhdl.org/meps/mep-105.html
> 
> Jan has a good explanation of V* behavior and why MyHDL is
> different.  And yes, I agree the /intbv/ vs. /list of bool/
> takes some experience / user preference.
> 
> You also have other alternatives, you can use an "interface"
> [3] to define your bus.  If you want to convert with 0.8 you
> need to reference the interface attributes explicitly in the
> modules.  In 0.9 (development branch is stable thanks to the
> exhaustive unit tests) the interfaces are converted.
> 
Great, /interfaces/ is what the customer ordered. I'll download the 0.9 
development branch. In fact I did last night as I may want to cooperate ...
and I have a small change in the VCD generator: I'm using the Impulse VCD 
viewer inside Eclipse and that doesn't support the /real/-/string/ 
presentation and installing GTKWave (under Win 8.1) looks a real hassle to 
me

> >>>
> >>> 2. The to_VHDL convertor flagged that lqa and lqb were not driven. 
Does
> > that
> >>> mean that we can not connect a slice of an intbv to receive the output
> > of a
> >>> component? I worked around that by changing the single Signal(intbv(0)
> >>> [WIDTH_D*RATIO_BA:]) into  [Signal(intbv(0)[WIDTH_D:]) for _ in range
> >>> (RATIO_BA)] which I could then connect as lqa[i] and lqb[i]. I then
> > manually
> >>> assembled the bigger output intbv from the parts.
> >>>
> >>
> >> In general you can not drive slice signals from multiple
> >> generators - if that were the case you should see an error
> >> in conversion (see [2] for more information and background).
> >> These signals must not be driven anywhere to receive the not
> >> driven message.
> >>
> > Coming from the VHDL world some of the MyHDL constructs/concepts are a 
bit
> > counter-intuitive. Actually it would be nice if some of the VHDL 
constructs
> > (like 2Dx1D and other levels of arrays) would be possible. I could have
> > written my ram3portmixedwidths in one go (without having to instantiate
> > multiple single ram3port modules) and neither of the two pitfalls would
> > have come up, but surely another one ...
> >
> 
> I am sure many C to Python programmers have made similar
> comments :)  I agree - those of us that have significant
> experience with V*, somethings are odd compared to V* but in
> reality they are better in MyHDL but we have conditioned
> ourselves to the V* way of doing things.
> 
I am sure I have not yet enough experience with Python, and my mindset is C 
(not even ++) and VHDL. I'll have to read up on the MyHDL doc and MEPs.

> I am not sure if I am following your 2Dx1D examples, you
> should be able to use arrays (2D, 3D, etc. actually I have
> never used/tested anything above 2D but I don't think there
> is a limitation)?
> 
Actually I tried to extend the initial ram3port:
from
  storage = [Signal(intbv(0)[WIDTH_D:] for _ in range(NUM_ENTRIES)]
into
  storage = [[Signal(intbv(0)[WIDTH_D:] for _ in range(NUM_ENTRIES / 
RATIO_BA)] for __ in range(RATIO_BA)] (which is a 2Dx1D object)
but to_VHDL() choked. Altera's HDL coding guide uses either VHDL or 
SystemVerilog to infer a mixed-widths RAM, as Verilog itself can't handle 
it. As Jan specifically wants to support both Verilog and VHDL equally 
MyHDL doesn't convert this construct.
And thus I started the 'generate' approach I described at the start of this 
thread. It frustrated me a bit, but I did learn a bit more of MyHDL, so 
there's something gained (let's forget about what got lost, as it is lost)

Regards,

Josy