myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Block return values (myhdl.BlockError)

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

I have been thinking about this for about
a month now, without a good resolution,
and it is holding development back.

We need to resolve this urgently though,
because if we go forward with @block a
release has to made before GSoC. (May 23).

It is a style I didn't think about before,
but of course it is something you can do
with dynamic Python...

My thoughts:

In this style, the return values become
part of the block interface. If we want to
support this with @block, we need to
permit different (perhaps all) types
of return values, and reorder them
using the decorator.

This seems to become complicated, and
also defies the purpose of @block somewhat
(stricter type checking).

So: if we don't support this, are we
really going to miss something in the
future? The workaround is of course
to use only the argument list for
the block interface, and to do type-dependent
processing of ports outside the @block.

Also, an intermediate workaround may
be to pass an "interface object" as
an argument, and populate it with
Signal objects locally within the @block.

Feedback is more than welcome.

Jan


On 29/03/16 15:54, Jos Huisken wrote:
> Hi,
>
> Sometimes I'm using a block like this:
>
> def tb():
>      m, clk, rst = clkrst()
>      return m, clk, rst
>
> In which 'm' is the list of instantiator objects, and 'clk'/'rst' are
> Signals.
> So this way you can specify a block in general:
>
> def unit(inputports):
>      ...
>      return m, outputports
>
> Note that this could be a preferred way of design. It just happened that I
> created few such examples.
>
> With the new block decorator this is not allowed anymore, raising a
> myhdl.BlockError.
>
> I can imagine that also other return values may be wanted by users.
> Is this something which can be taken into account?
> Or: should 'block's really be constrained in returning just block or
> instantiator objects?
>
> Thanks,
> Jos
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>


-- 
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
   Urubu, a static website CMS: http://urubu.jandecaluwe.com

Re: [myhdl-list] Inconsistency between simulation and conversion

[Nicolas P. <nic...@aa...>]

Le 28/04/2016 à 18:45, Christopher Felton a écrit :
>
>
> On Thu, Apr 28, 2016 at 8:05 AM, Nicolas Pinault <nic...@aa... 
> <mailto:nic...@aa...>> wrote:
>
>     Le 28/04/2016 à 13:47, Henry Gomersall a écrit :
>>     On 28/04/16 07:54, Nicolas Pinault wrote:
>>>     When using this statement "counter.next += 1" I get an error when
>>>     converting my design to VHDL :
>>>
>>>     myhdl.ConversionError: in file
>>>     Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51:
>>>          Not supported: Augmented signal assignment
>>>
>>>     This makes sense.
>>>     However, this same statement does not trig any error when simulating the
>>>     design.
>>>     Is this the intended behaviour ?
>>>
>>     Incrementing .next is a slightly odd thing to want to do, but is
>>     possible given .next is likely an int type. Clearly it doesn't really
>>     make sense from the perspective of conversion.
>     To be consistent, I expect simulation to raise an exception as
>     conversion does.
>
>
> Hmmm, might require some conversation.  Nothing would
> prevent someone from incrementing (augmenting) next in
> modeling or verification - kinda odd but not sure if it should
> throw and error.
Well, at least, a warning should be generated when simulating.
I used augmented assignment inadvertently in a module. I made all the 
development with it without any problem. Then I got an error when 
converting. At first, this was a big surprise. I quickly found (and 
understood) the source of the problem but I would have preferred to be 
aware of the problem during simulation.
At first, I don't see any useful case of augmenting next attribute, even 
in simulation.

Nicolas
>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


-- 
*Nicolas PINAULT
R&D electronics engineer
*** ni...@aa... <mailto:ni...@aa...>

*AATON-Digital*
38000 Grenoble - France
Tel +33 4 7642 9550

http://www.aaton.com
http://www.transvideo.eu
French Technologies for Film and Digital Cinematography

Follow us on Twitter
@Aaton_Digital
@Transvideo_HD

Like us on Facebook
https://www.facebook.com/AatonDigital

Re: [myhdl-list] Inconsistency between simulation and conversion

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

On Thu, Apr 28, 2016 at 8:05 AM, Nicolas Pinault <nic...@aa...> wrote:

> Le 28/04/2016 à 13:47, Henry Gomersall a écrit :
>
> On 28/04/16 07:54, Nicolas Pinault wrote:
>
> When using this statement "counter.next += 1" I get an error when
> converting my design to VHDL :
>
> myhdl.ConversionError: in file
> Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51:
>     Not supported: Augmented signal assignment
>
> This makes sense.
> However, this same statement does not trig any error when simulating the
> design.
> Is this the intended behaviour ?
>
>
> Incrementing .next is a slightly odd thing to want to do, but is
> possible given .next is likely an int type. Clearly it doesn't really
> make sense from the perspective of conversion.
>
> To be consistent, I expect simulation to raise an exception as conversion
> does.
>
>
Hmmm, might require some conversation.  Nothing would
prevent someone from incrementing (augmenting) next in
modeling or verification - kinda odd but not sure if it should
throw and error.

Regards,
Chris

Re: [myhdl-list] Inconsistency between simulation and conversion

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

On Thu, Apr 28, 2016 at 7:12 AM, Samuele Disegna <sm...@gm...> wrote:

> On Thu, Apr 28, 2016 at 1:47 PM, Henry Gomersall <he...@ma...> wrote:
>
>> On 28/04/16 07:54, Nicolas Pinault wrote:
>> > When using this statement "counter.next += 1" I get an error when
>> > converting my design to VHDL :
>> >
>> > myhdl.ConversionError: in file
>> > Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51:
>> >     Not supported: Augmented signal assignment
>> >
>> > This makes sense.
>> > However, this same statement does not trig any error when simulating the
>> > design.
>> > Is this the intended behaviour ?
>> >
>>
>> Incrementing .next is a slightly odd thing to want to do,
>
>
> I would remove slightly to the sentence :).
> You are supposed to do "counter.next = counter+1" and not "counter.next =
> counter.next+1"
>
> Simulation in MyHDL is just execution of your code and you are allowed to
> do nasty things!
>
> Samuele
>

Absolutely, well stated.  We shouldn't increment the "next" but
assigning "next" to "current (val) + 1".  The augmented does't make
sense.

Regards,
Chris

Re: [myhdl-list] Inconsistency between simulation and conversion

[Samuele D. <sm...@gm...>]

Ok, "counter.next +=1" is not equivalent to "counter.next = counter+1".
Is it really true that most people expect that equivalence?

.next  is a python property that gives to you the intbv object
counter._next. That object will be incremented.
This makes sense to me.

Anyway while checking MyHDL sources I spotted a little bug:

at line 546
https://github.com/jandecaluwe/myhdl/blob/master/myhdl/_Signal.py
"def _augm(self)" should be  "_augm(self,arg)"
# augmented assignment not supported
def _augm(self):
raise TypeError("Signal object doesn't support augmented assignment")
__iadd__ = __isub__ = __imul__ = __ipow__ = __imod__ = _augm
__ior__ = __iand__ = __ixor__ = __irshift__ = __ilshift__ = _augm
__itruediv__ = __ifloordiv__ = _augm

On Thu, Apr 28, 2016 at 3:05 PM, Nicolas Pinault <nic...@aa...> wrote:

> Le 28/04/2016 à 13:47, Henry Gomersall a écrit :
>
> On 28/04/16 07:54, Nicolas Pinault wrote:
>
> When using this statement "counter.next += 1" I get an error when
> converting my design to VHDL :
>
> myhdl.ConversionError: in file
> Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51:
>     Not supported: Augmented signal assignment
>
> This makes sense.
> However, this same statement does not trig any error when simulating the
> design.
> Is this the intended behaviour ?
>
>
> Incrementing .next is a slightly odd thing to want to do, but is
> possible given .next is likely an int type. Clearly it doesn't really
> make sense from the perspective of conversion.
>
> To be consistent, I expect simulation to raise an exception as conversion
> does.
>
> Nicolas
>
>
>
> Henry
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/myhdl-list
> .
>
>
>
>
> --
>
>
> * Nicolas PINAULT R&D electronics engineer * ni...@aa...
>
> *AATON-Digital*
> 38000 Grenoble - France
> Tel +33 4 7642 9550
>
> http://www.aaton.com
> http://www.transvideo.eu
> French Technologies for Film and Digital Cinematography
>
> Follow us on Twitter
> @Aaton_Digital
> @Transvideo_HD
>
> Like us on Facebook
> https://www.facebook.com/AatonDigital
>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

Re: [myhdl-list] Inconsistency between simulation and conversion

[Nicolas P. <nic...@aa...>]

Le 28/04/2016 à 13:47, Henry Gomersall a écrit :
> On 28/04/16 07:54, Nicolas Pinault wrote:
>> When using this statement "counter.next += 1" I get an error when
>> converting my design to VHDL :
>>
>> myhdl.ConversionError: in file
>> Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51:
>>      Not supported: Augmented signal assignment
>>
>> This makes sense.
>> However, this same statement does not trig any error when simulating the
>> design.
>> Is this the intended behaviour ?
>>
> Incrementing .next is a slightly odd thing to want to do, but is
> possible given .next is likely an int type. Clearly it doesn't really
> make sense from the perspective of conversion.
To be consistent, I expect simulation to raise an exception as 
conversion does.

Nicolas

>
> Henry
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> .
>


-- 
*Nicolas PINAULT
R&D electronics engineer
*** ni...@aa... <mailto:ni...@aa...>

*AATON-Digital*
38000 Grenoble - France
Tel +33 4 7642 9550

http://www.aaton.com
http://www.transvideo.eu
French Technologies for Film and Digital Cinematography

Follow us on Twitter
@Aaton_Digital
@Transvideo_HD

Like us on Facebook
https://www.facebook.com/AatonDigital

Re: [myhdl-list] [EXT] Re: Inconsistency between simulation and conversion

[David S. <dst...@kc...>]

This makes me wonder, in simulation is it actually incrementing counter.next, or is it incrementing the value of counter?

It doesn’t feel like having augmented operators work the way most people would expect (counter.next +=1 -> counter.next = counter + 1) is going to cause anyone any actual problem. Am I missing something? Or is it just harder to make work correctly than it’s worth?

Dave

From: Samuele Disegna [mailto:sm...@gm...]
Sent: Thursday, April 28, 2016 7:13 AM
To: General discussions on MyHDL
Subject: [EXT] Re: [myhdl-list] Inconsistency between simulation and conversion

On Thu, Apr 28, 2016 at 1:47 PM, Henry Gomersall <he...@ma...<mailto:he...@ma...>> wrote:
On 28/04/16 07:54, Nicolas Pinault wrote:
> When using this statement "counter.next += 1" I get an error when
> converting my design to VHDL :
>
> myhdl.ConversionError: in file
> Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51:
>     Not supported: Augmented signal assignment
>
> This makes sense.
> However, this same statement does not trig any error when simulating the
> design.
> Is this the intended behaviour ?
>

Incrementing .next is a slightly odd thing to want to do,

I would remove slightly to the sentence :).
You are supposed to do "counter.next = counter+1" and not "counter.next = counter.next+1"

Simulation in MyHDL is just execution of your code and you are allowed to do nasty things!

Samuele
This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature. For additional important disclaimers and disclosures regarding KCG’s products and services, please click on the following link:

http://www.kcg.com/legal/global-disclosures

Re: [myhdl-list] Inconsistency between simulation and conversion

[Samuele D. <sm...@gm...>]

On Thu, Apr 28, 2016 at 1:47 PM, Henry Gomersall <he...@ma...> wrote:

> On 28/04/16 07:54, Nicolas Pinault wrote:
> > When using this statement "counter.next += 1" I get an error when
> > converting my design to VHDL :
> >
> > myhdl.ConversionError: in file
> > Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51:
> >     Not supported: Augmented signal assignment
> >
> > This makes sense.
> > However, this same statement does not trig any error when simulating the
> > design.
> > Is this the intended behaviour ?
> >
>
> Incrementing .next is a slightly odd thing to want to do,


I would remove slightly to the sentence :).
You are supposed to do "counter.next = counter+1" and not "counter.next =
counter.next+1"

Simulation in MyHDL is just execution of your code and you are allowed to
do nasty things!

Samuele

Re: [myhdl-list] Inconsistency between simulation and conversion

[Henry G. <he...@ma...>]

On 28/04/16 07:54, Nicolas Pinault wrote:
> When using this statement "counter.next += 1" I get an error when
> converting my design to VHDL :
> 
> myhdl.ConversionError: in file
> Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51:
>     Not supported: Augmented signal assignment
> 
> This makes sense.
> However, this same statement does not trig any error when simulating the
> design.
> Is this the intended behaviour ?
> 

Incrementing .next is a slightly odd thing to want to do, but is
possible given .next is likely an int type. Clearly it doesn't really
make sense from the perspective of conversion.

Henry

Re: [myhdl-list] Inconsistency between simulation and conversion

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

On 4/28/16 1:54 AM, Nicolas Pinault wrote:
> Hi,
>
> When using this statement "counter.next += 1" I get an error when
> converting my design to VHDL :
>
> myhdl.ConversionError: in file
> Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51: Â Â Â  Not
> supported: Augmented signal assignment
>
> This makes sense. However, this same statement does not trig any
> error when simulating the design. Is this the intended behaviour ?

I believe it is expected, only a subset is convertible.
You would not want to error on non-convertible statements
because they could be useful for modeling and test
(i.e. non-conversion).

The manual doesn't state one way or the other for signal
assignments, we should add that the *augmented* assignment
operators are not supported for signal assignments:
http://docs.myhdl.org/en/stable/manual/conversion.html#signal-assignment

Regards,
Chris

[myhdl-list] Inconsistency between simulation and conversion

[Nicolas P. <nic...@aa...>]

Hi,

When using this statement "counter.next += 1" I get an error when 
converting my design to VHDL :

myhdl.ConversionError: in file 
Z:\myHDL_Tests\NoiseFilter\src\noise_filter.py, line 51:
     Not supported: Augmented signal assignment

This makes sense.
However, this same statement does not trig any error when simulating the 
design.
Is this the intended behaviour ?

Nicolas


-- 
*Nicolas PINAULT
R&D electronics engineer
*** ni...@aa... <mailto:ni...@aa...>

*AATON-Digital*
38000 Grenoble - France
Tel +33 4 7642 9550

http://www.aaton.com
http://www.transvideo.eu
French Technologies for Film and Digital Cinematography

Follow us on Twitter
@Aaton_Digital
@Transvideo_HD

Like us on Facebook
https://www.facebook.com/AatonDigital

Re: [myhdl-list] Waveform viewer

[Nicolas P. <nic...@aa...>]

Hi,
> GTKWave seems less modern than the other tools I am using (by a user 
> interface perspective) so I will have a look at Impulse.
GTKWave interface looks a little bit old but this is a very good tool.
Impulse interface is modern but it is not open source. You don't know if 
it will still be free in the future.

Nicolas

Re: [myhdl-list] Waveform viewer

[Samuele D. <sm...@gm...>]

Hello Nicolas,
I wanted to rise some questions about software tools too, is this ML a
place for this type of discussion?
I am currently using kdevelop, Jupyter, GTKWave and sometimes ipython shell.
GTKWave seems less modern than the other tools I am using (by a user
interface perspective) so I will have a look at Impulse.

Thank you!

On Wed, Apr 27, 2016 at 5:13 PM, Nicolas Pinault <nic...@aa...> wrote:

> Hi all,
> GTKWave is great to view traces generated by MyHDL.
> For those who are interested , I've just discovered Impulse (
> http://toem.de/index.php/projects/impulse).
> Impulse integrates perfectly with Eclipse. Eclipse+PyDev+Impulse is really
> cool.
> One interesting feature of Impulse is "combining" traces which superimpose
> traces like on a scope. This can be very useful with analog signals.
> The Basic edition is free (this is not an open source project) and almost
> complete.
>
> Nicolas
>
>
> --
>
>
> * Nicolas PINAULT R&D electronics engineer * ni...@aa...
>
> *AATON-Digital*
> 38000 Grenoble - France
> Tel +33 4 7642 9550
>
> http://www.aaton.com
> http://www.transvideo.eu
> French Technologies for Film and Digital Cinematography
>
> Follow us on Twitter
> @Aaton_Digital
> @Transvideo_HD
>
> Like us on Facebook
> https://www.facebook.com/AatonDigital
>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

[myhdl-list] Waveform viewer

[Nicolas P. <nic...@aa...>]

Hi all,

GTKWave is great to view traces generated by MyHDL.I have


-- 
*Nicolas PINAULT
R&D electronics engineer
*** ni...@aa... <mailto:ni...@aa...>

*AATON-Digital*
38000 Grenoble - France
Tel +33 4 7642 9550

http://www.aaton.com
http://www.transvideo.eu
French Technologies for Film and Digital Cinematography

Follow us on Twitter
@Aaton_Digital
@Transvideo_HD

Like us on Facebook
https://www.facebook.com/AatonDigital

[myhdl-list] Waveform viewer

[Nicolas P. <nic...@aa...>]

Hi all,

GTKWave is great to view traces generated by MyHDL.
For those who are interested , I've just discovered Impulse 
(http://toem.de/index.php/projects/impulse).
Impulse integrates perfectly with Eclipse. Eclipse+PyDev+Impulse is 
really cool.
One interesting feature of Impulse is "combining" traces which 
superimpose traces like on a scope. This can be very useful with analog 
signals.
The Basic edition is free (this is not an open source project) and 
almost complete.

Nicolas


-- 
*Nicolas PINAULT
R&D electronics engineer
*** ni...@aa... <mailto:ni...@aa...>

*AATON-Digital*
38000 Grenoble - France
Tel +33 4 7642 9550

http://www.aaton.com
http://www.transvideo.eu
French Technologies for Film and Digital Cinematography

Follow us on Twitter
@Aaton_Digital
@Transvideo_HD

Like us on Facebook
https://www.facebook.com/AatonDigital

[myhdl-list] Customer Evaluation.....Participate & Get Paid!!!

[Opinion O. <kit...@ao...>]

 - This mail is in HTML. Some elements may be ommited in plain text. -

We currently have a customer evaluation assignment

available in your area

and we would like you to participate.


Get Paid $200.00 for every Assignment Completed.

Click Here

to read more and Sign Up if interested.
Thank you for participating.
Opinion Outpost?
6 Research Drive
Shelton, CT 06484. U.S.A
Attn: Robert Walsh

Re: [myhdl-list] Dual port ram, mixed width byte enables.

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

Josy,

I understand, I just wanted to make sure it was
clear to the OP that in the near-term it might not
be an option.

Regards,
Chris

On Tue, Apr 19, 2016 at 11:16 AM, Josy Boelen <jos...@gm...> wrote:

> Christopher Felton <chris.felton <at> gmail.com> writes:
>
> >
> >
> > Josy,
> > I am not 100% sure that it is limited to only multidim, I
> haven'tresearched this but I thought you could build mix port by using a
> model of the BRAM prims (1bit width) and build them from the simple
> model.  More of an elaboration / generate approach.
> >
> > If that doesn't work than the user code [1] would be the quickest
> > alternative (as we both stated).
> >
> > I think the Array will take some discussion etc. before it worked
> > in to the base.  It is a fairly important feature and I am sure there
> > will be significant feedback from the core devs.  It needs a clean
> > MEP etc. for discussion and review.  I don't think it is something
> > that can be used in the near-term.
> >
> > Regards,Chris
> >
> > [1] http://docs.myhdl.org/en/stable/manual/conversion.html#user-
> defined-code
>
> Hi Chris,
>
> I am (painfully) aware that the 'Array' needs a lot of care -
> unfortunately I have little free time lately. I'll try better.
>
> Regards,
>
> Josy
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Dual port ram, mixed width byte enables.

[Samuele D. <sm...@gm...>]

Hi, Ok this is what the model looks like now, I will try the user coded
part when I need it and have time:
Thanks

class ram_port():
    def __init__(self,WIDTH,DEPTH):
        self.addr = Signal(intbv(0,min=0,max=DEPTH))
        self.we = Signal(False)
        self.din = Signal(intbv(0)[WIDTH:])
        self.dout = Signal(intbv(0)[WIDTH:])
        self.WIDTH = WIDTH
        self.DEPTH = DEPTH

@block
def ram_dual_port(clk,ram_port1,ram_port2):
    if ram_port1.WIDTH * ram_port1.DEPTH != ram_port2.WIDTH *
ram_port2.DEPTH:
        raise ValueError("ram_port1 WIDTH*DEPTH != ram_port2 w*D")
    if ram_port1.WIDTH < ram_port2.WIDTH:
        raise ValueError("ram_port1.WIDTH < ram_port2.WIDTH")
    if not (ram_port1.WIDTH / ram_port2.WIDTH).is_integer():
        raise ValueError("ports width ratio must be an integer")

    mem = [Signal(intbv(0)[ram_port2.WIDTH:]) for i in
range(ram_port2.DEPTH)]
    RATIO = ram_port1.WIDTH // ram_port2.WIDTH

    @always(clk.posedge)
    def wr_port1():
        ram_port1.dout.next = concat(*[mem[ram_port1.addr*RATIO+i] for i in
reversed(range(RATIO))])
        if ram_port1.we:
            for i in range(RATIO):
                mem[ram_port1.addr*RATIO+i].next =
ram_port1.din[ram_port1.WIDTH*(i+1):ram_port1.WIDTH*i]

    @always(clk.posedge)
    def wr_port2():
        ram_port2.dout.next = mem[ram_port2.addr]
        if ram_port2.we:
            mem[ram_port2.addr].next = ram_port2.din

    return instances()

On Tue, Apr 19, 2016 at 6:16 PM, Josy Boelen <jos...@gm...> wrote:

> Christopher Felton <chris.felton <at> gmail.com> writes:
>
> >
> >
> > Josy,
> > I am not 100% sure that it is limited to only multidim, I
> haven'tresearched this but I thought you could build mix port by using a
> model of the BRAM prims (1bit width) and build them from the simple
> model.  More of an elaboration / generate approach.
> >
> > If that doesn't work than the user code [1] would be the quickest
> > alternative (as we both stated).
> >
> > I think the Array will take some discussion etc. before it worked
> > in to the base.  It is a fairly important feature and I am sure there
> > will be significant feedback from the core devs.  It needs a clean
> > MEP etc. for discussion and review.  I don't think it is something
> > that can be used in the near-term.
> >
> > Regards,Chris
> >
> > [1] http://docs.myhdl.org/en/stable/manual/conversion.html#user-
> defined-code
>
> Hi Chris,
>
> I am (painfully) aware that the 'Array' needs a lot of care -
> unfortunately I have little free time lately. I'll try better.
>
> Regards,
>
> Josy
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Dual port ram, mixed width byte enables.

[Josy B. <jos...@gm...>]

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

> 
> 
> Josy,
> I am not 100% sure that it is limited to only multidim, I 
haven'tresearched this but I thought you could build mix port by using a 
model of the BRAM prims (1bit width) and build them from the simple 
model.  More of an elaboration / generate approach.
> 
> If that doesn't work than the user code [1] would be the quickest
> alternative (as we both stated).
> 
> I think the Array will take some discussion etc. before it worked
> in to the base.  It is a fairly important feature and I am sure there 
> will be significant feedback from the core devs.  It needs a clean 
> MEP etc. for discussion and review.  I don't think it is something 
> that can be used in the near-term.
> 
> Regards,Chris
> 
> [1] http://docs.myhdl.org/en/stable/manual/conversion.html#user-
defined-code

Hi Chris,

I am (painfully) aware that the 'Array' needs a lot of care - 
unfortunately I have little free time lately. I'll try better.

Regards,

Josy

Re: [myhdl-list] Dual port ram, mixed width byte enables.

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

Josy,

I am not 100% sure that it is limited to only multidim, I haven't
researched this but I thought you could build mix port by using
a model of the BRAM prims (1bit width) and build them from
the simple model.  More of an elaboration / generate approach.

If that doesn't work than the user code [1] would be the quickest
alternative (as we both stated).

I think the Array will take some discussion etc. before it worked
in to the base.  It is a fairly important feature and I am sure there
will be significant feedback from the core devs.  It needs a clean
MEP etc. for discussion and review.  I don't think it is something
that can be used in the near-term.

Regards,
Chris

[1] http://docs.myhdl.org/en/stable/manual/conversion.html#user-defined-code


On Tue, Apr 19, 2016 at 9:35 AM, Josy Boelen <jos...@gm...> wrote:

> Christopher Felton <chris.felton <at> gmail.com> writes:
>
> >
> >
> >
> > On Tue, Apr 19, 2016 at 7:32 AM, Samuele Disegna <smldis <at>
> gmail.com> wrote:Yes! There is a multidimensional array that enables
> indexing of the smaller port (or the ability to have byte enables).
> >
> > Yes that will be a problem :(
> >
> > There are a couple options: first, try and rework the example without
> the multidimension array.  Second, you could use the user defined code
> and wrap the template.  That would probably be the fastest and you would
> be able to still model the same logic in myhdl just not convert the
> multidim array.
> >
>
> Chris, Samuele,
>
> It needs to be a proper multidim VHDL array to have Quartus infer an
> 'altsyncram'. You can try using one single-dimension array per byte-
> enable, but then you will end up with multiple 'altsyncram'.
> So there is only the second option left; write a model in MyHDL for the
> testbench and include 'user defined code' for conversion.
> It will be possible using the future/proposed 'myhdl.Array' type.(I have
> that working in my local branch, but with the new '@block' decorator
> making a proper PR is a lot more work. And I have indulged in a few more
> 'enhancements'. Maybe I should start sharing those first)
>
> Regards,
>
> Josy
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Dual port ram, mixed width byte enables.

[Josy B. <jos...@gm...>]

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

> 
> 
> 
> On Tue, Apr 19, 2016 at 7:32 AM, Samuele Disegna <smldis <at> 
gmail.com> wrote:Yes! There is a multidimensional array that enables 
indexing of the smaller port (or the ability to have byte enables).
> 
> Yes that will be a problem :( 
> 
> There are a couple options: first, try and rework the example without 
the multidimension array.  Second, you could use the user defined code 
and wrap the template.  That would probably be the fastest and you would 
be able to still model the same logic in myhdl just not convert the 
multidim array.
> 

Chris, Samuele,

It needs to be a proper multidim VHDL array to have Quartus infer an 
'altsyncram'. You can try using one single-dimension array per byte-
enable, but then you will end up with multiple 'altsyncram'.
So there is only the second option left; write a model in MyHDL for the 
testbench and include 'user defined code' for conversion.
It will be possible using the future/proposed 'myhdl.Array' type.(I have 
that working in my local branch, but with the new '@block' decorator 
making a proper PR is a lot more work. And I have indulged in a few more 
'enhancements'. Maybe I should start sharing those first)

Regards,

Josy

Re: [myhdl-list] Dual port ram, mixed width byte enables.

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

On Tue, Apr 19, 2016 at 7:32 AM, Samuele Disegna <sm...@gm...> wrote:

> Yes! There is a multidimensional array that enables indexing of the
> smaller port (or the ability to have byte enables).
>

Yes that will be a problem :(

There are a couple options: first, try and rework the example without
the multidimension array.  Second, you could use the user defined
code and wrap the template.  That would probably be the fastest and
you would be able to still model the same logic in myhdl just not
convert the multidim array.

Regards,
Chris

Re: [myhdl-list] Dual port ram, mixed width byte enables.

[Samuele D. <sm...@gm...>]

Yes! There is a multidimensional array that enables indexing of the smaller
port (or the ability to have byte enables).

This is my rough code for symmetric ports:

from myhdl import *

class ram_port():
    def __init__(self,WIDTH,DEPTH):
        self.addr = Signal(intbv(0,min=0,max=DEPTH))
        self.we = Signal(False)
        self.din = Signal(intbv(0)[WIDTH:])
        self.dout = Signal(intbv(0)[WIDTH:])

@block
def ram_dual_port(clk,ram_port1,ram_port2,WIDTH,DEPTH):
    mem = [Signal(intbv(0)[WIDTH:]) for i in range(DEPTH)]

    @always(clk.posedge)
    def wr_port1():
        ram_port1.dout.next = mem[ram_port1.addr]
        if ram_port1.we:
            mem[ram_port1.addr].next = ram_port1.din

    @always(clk.posedge)
    def wr_port2():
        ram_port2.dout.next = mem[ram_port2.addr]
        if ram_port2.we:
            mem[ram_port2.addr].next = ram_port2.din
    return instances()

WIDTH = 8
DEPTH = 1000
clk = Signal(False)
p1 = ram_port(WIDTH,DEPTH)
p2 = ram_port(WIDTH,DEPTH)
ram = ram_dual_port(clk,p1,p2,WIDTH,DEPTH)

ram.convert(hdl='VHDL')



On Tue, Apr 19, 2016 at 12:39 PM, Christopher Felton <chr...@gm...
> wrote:

> On 4/18/16 12:56 PM, Samuele Disegna wrote:
> > Hi MyHDLs, Is there a way to implement a dual port ram with mixed
> > width ports and or byte enables?
> >
> > The template to infer one with Altera tools is something like this in
> > VHDL:
>
> You should be able to duplicate the template in
> MyHDL.  Is there a concern or specific issue you
> are having trouble with?
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Dual port ram, mixed width byte enables.

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

On 4/18/16 12:56 PM, Samuele Disegna wrote:
> Hi MyHDLs, Is there a way to implement a dual port ram with mixed
> width ports and or byte enables?
>
> The template to infer one with Altera tools is something like this in
> VHDL:

You should be able to duplicate the template in
MyHDL.  Is there a concern or specific issue you
are having trouble with?

Regards,
Chris

[myhdl-list] Dual port ram, mixed width byte enables.

[Samuele D. <sm...@gm...>]

Hi MyHDLs,
Is there a way to implement a dual port ram with mixed width ports and or
byte enables?

The template to infer one with Altera tools is something like this in VHDL:

architecture rtl of mixed_width_true_dual_port_ram is
constant RATIO       : natural := 2 ** (ADDRESS_WIDTH1 - ADDRESS_WIDTH2) ;
constant DATA_WIDTH2 : natural := DATA_WIDTH1 * RATIO;
constant RAM_DEPTH   : natural := 2 ** ADDRESS_WIDTH2;

-- Use a multidimensional array to model mixed-width
type word_t is array(RATIO - 1 downto 0) of std_logic_vector(DATA_WIDTH1 -
1 downto 0);
type ram_t is array (0 to RAM_DEPTH - 1) of word_t;

-- declare the RAM
signal ram : ram_t;

signal w1_local : word_t;
signal q1_local : word_t;

begin  -- rtl
-- Re-organize the write data to match the RAM word type
unpack: for i in 0 to RATIO - 1 generate
w1_local(i) <= data_in2(DATA_WIDTH1*(i+1) - 1 downto DATA_WIDTH1*i);
data_out2(DATA_WIDTH1*(i+1) - 1 downto DATA_WIDTH1*i) <= q1_local(i);
end generate unpack;

--port A
process(clk)
begin
if(rising_edge(clk)) then
if(we2 = '1') then
ram(addr2) <= w1_local;
end if;
q1_local <= ram(addr2);
end if;
end process;

-- port B
process(clk)
begin
if(rising_edge(clk)) then
data_out1 <= ram(addr1 / RATIO )(addr1 mod RATIO);
if(we1 ='1') then
ram(addr1 / RATIO)(addr1 mod RATIO) <= data_in1;
end if;
end if;
end process;
end rtl;


Greetings,
 Samuele