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