myhdl-list — Mailing list for discussions on MyHDL

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

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

It's not so much an implementation problem as an
expectations problem.

Previously, one could do

    return m, sig1, sig2

and make a "contract" with oneself that m should be a list
of instances.

The problem I have is that this kind of decision would now
become part of the @block specification, valid for all, instead
simply being a local decision.

For example, what if one uses:
  
    return m1, m2, sig1, sig2

should that fail? And on what ground? And if it doesn't
fail, should the decorator than modify the return values
into something like:

    return Block(m1, m2), sig1, sig2

changing the argument aspect completely?

And what about

    return sig1, sig2, m


Or

    return m, siglist

And so on.

Jan

On 01/05/16 16:57, Samuele Disegna wrote:
> Hi! I am not getting the problem completely so I will try to give a
> probably wrong solution, I would like to hear some feedback on it in
> order to rise a more practical discussion:
>
> Block connections are usually indicated as arguments of the block
> functions, can we stick to this phylosophy and pass an empty list for
> signals defined inside the block itself? (the block will fill the
> list)
>
> Hardware Instances are usually passed through the return statement as
> single object, lists or tuples (Is this the maintenance problem?) and
> we are not capable of return anything else with the current
> implementation without getting errors (Have I got it right?). Can we
> decide to use a list for hardware instances embedded as the first
> element of a tuple (or in a dictionary)? The other elements will
> contain all kinds of return objects.
>
> Jan, could you list your thoughts about the problems you are getting
> on the implementation side :)? I am definitely interested.
>
> Samuele
>
> On Sun, May 1, 2016 at 12:46 PM, Henry Gomersall <he...@ma...
> <mailto:he...@ma...>> wrote:
>
> On 01/05/16 11:40, Jan Decaluwe wrote:
>> Feedback is more than welcome.
>
> Another potential option is to make the Block class part of the user
> API, or perhaps an alternative Block factory, to allow these more
> esoteric use cases.
>
> So, the @block decorator is used in the simple/common case. If you
> want to do something more complicated, you can use the alternative
> tools to extract the block object. Exactly how this would be realised
> I'm not sure, but I'm sure there would be a neat way.
>
> It touches on my comments in issue #162, which is another
> manifestation of the limitations of the decorator implementation.
>
> 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...
> <mailto:myh...@li...>
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
>
>
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
>


-- 
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

[myhdl-list] myhdl & co-simulation

[Edward V. <dev...@sb...>]

Hello All,

I have a Verilog file tb/wbdeppsimple.v which I hope to convert to myhdl.

I created the file tb/tb_wbdeppsimple.v to interface with myhdl.

I am creating the dr_wbdepp.py which creates "dr_wbdepp.v" with the command
dr_wbdepp.py --convert.

Should dr_wbdepp.v be included in the co-simulation or just a myhdl instance?

When I test the iverilog command from the command line, it does not get any errors.
iverilog -o ifdeppsimple tb/wbdeppsimple.v tb/tb_wbdeppsimple.v dr_wbdepp.v

The above command is called from dr_wbdepp.py --cosimtrace with the line below
cmd = "iverilog -o ifdeppsimple tb/wbdeppsimple.v tb/tb_wbdeppsimple.v dr_wbdepp.v"
which creates  tb/vcd/wbdeppsimple1.vcd.  

I then can use gtkwave to view the signals.

Should I create both a myhdl instance and instance in file tb_wbdeppsimple.v?

In the dr_wbdepp.py the tbstim instance, I am driving the signal o_para which drives
the signals o_b0 to o_b7.   

The file I am using are at https://github.com/develone/jpeg-2000-test/tree/master/xula2_fpga/parallel.

Any and all help is appreciated. Edward Vidal Jr. e-mail dev...@sb... 915-595-1613

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

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

Hi!
I am not getting the problem completely so I will try to give a probably
wrong solution, I would like to hear some feedback on it in order to rise a
more practical discussion:

Block connections are usually indicated as arguments of the block
functions, can we stick to this phylosophy and pass an empty list for
signals defined inside the block itself? (the block will fill the list)

Hardware Instances are usually passed through the return statement as
single object, lists or tuples (Is this the maintenance problem?) and we
are not capable of return anything else with the current implementation
without getting errors (Have I got it right?). Can we decide to use a list
for hardware instances embedded as the first element of a tuple (or in a
dictionary)? The other elements will contain all kinds of return objects.

Jan, could you list your thoughts about the problems you are getting on the
implementation side :)?
I am definitely interested.

Samuele

On Sun, May 1, 2016 at 12:46 PM, Henry Gomersall <he...@ma...> wrote:

> On 01/05/16 11:40, Jan Decaluwe wrote:
> > Feedback is more than welcome.
>
> Another potential option is to make the Block class part of the user
> API, or perhaps an alternative Block factory, to allow these more
> esoteric use cases.
>
> So, the @block decorator is used in the simple/common case. If you want
> to do something more complicated, you can use the alternative tools to
> extract the block object. Exactly how this would be realised I'm not
> sure, but I'm sure there would be a neat way.
>
> It touches on my comments in issue #162, which is another manifestation
> of the limitations of the decorator implementation.
>
> 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
>

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

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

On 01/05/16 11:40, Jan Decaluwe wrote:
> Feedback is more than welcome.

Another potential option is to make the Block class part of the user
API, or perhaps an alternative Block factory, to allow these more
esoteric use cases.

So, the @block decorator is used in the simple/common case. If you want
to do something more complicated, you can use the alternative tools to
extract the block object. Exactly how this would be realised I'm not
sure, but I'm sure there would be a neat way.

It touches on my comments in issue #162, which is another manifestation
of the limitations of the decorator implementation.

Henry

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