myhdl-list

[myhdl-list] intbv with max != 2**n. Error or annoyance?

[Per K. <bas...@gm...>]

Hi!
Here is something that I can't make up my mind if it is an error or just
plain annoying:

I have a signal where the max value is not an even 2**n, and I
combinatorically assign it the value of a signal with a higher max value,
but only on the condition that the value is within range. This is fine.

But if the condition is moved to a separate @always_comb driving a flag and
the flag gates the assignment, then there is a ValueError. The generated
verilog is fine of course.
/Per

ps. Here is an example:

from myhdl import *

def range_check(capped, clk, rstn, cnt_max):
    cnt       = Signal(intbv(0, min=0, max=cnt_max))
    less_flag = Signal(intbv(0)[1:0])

    cnt_max      = cnt.max
    capped_max   = capped.max
    capped_width = len(capped)

    @always(clk.posedge, rstn.negedge)
    def count():
        if rstn==0:
            cnt.next = 0
        else:
            if cnt + 1 == cnt_max:
                cnt.next = 0
            else:
                cnt.next = cnt + 1

    @always_comb
    def setcapped():
        if less_flag==1:
            capped.next = cnt[capped_width:]
        else:
            capped.next = 0

    @always_comb
    def setless():
        if cnt < capped_max:
            less_flag.next = 1
        else:
            less_flag.next = 0

    return instances()

def tb(capped_max):
    clk   = Signal(intbv(0)[1:0])
    rstn  = Signal(intbv(0)[1:0])

    @instance
    def rstngen():
        rstn.next = 0
        yield delay(100)
        rstn.next = 1
        yield delay(10000)
        raise StopSimulation

    @always(delay(10))
    def clkgen():
        clk.next = not clk

    capped  = Signal(intbv(0, min=0, max=capped_max))
    cnt_max = 15
    dut   = range_check(capped, clk, rstn, cnt_max)
    return instances()

s = Simulation(tb(4))
s.run()
print "4 is OK"
s = Simulation(tb(5))
s.run()
print "5 is not"

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Per K. <bas...@gm...>]

Hi!
Over the weekend I have come to the conclusion that it is an error.

Checking the value of a combinatorical net before it has settled has to be
wrong. So depending on implementation feasibility and in order of
preference we could:

- Wait until the net has stabilized before checking the range, or
- Disable range checks for combinatorical nets, or
- Assert whenever a signal with range delimiters != 2**n is used as a
combinatorical net.

What do you say guys?
/Per




On Fri, Jan 25, 2013 at 1:08 PM, Per Karlsson <bas...@gm...>wrote:

> Hi!
> Here is something that I can't make up my mind if it is an error or just
> plain annoying:
>
> I have a signal where the max value is not an even 2**n, and I
> combinatorically assign it the value of a signal with a higher max value,
> but only on the condition that the value is within range. This is fine.
>
> But if the condition is moved to a separate @always_comb driving a flag
> and the flag gates the assignment, then there is a ValueError. The
> generated verilog is fine of course.
> /Per
>
> ps. Here is an example:
>
> from myhdl import *
>
> def range_check(capped, clk, rstn, cnt_max):
>     cnt       = Signal(intbv(0, min=0, max=cnt_max))
>     less_flag = Signal(intbv(0)[1:0])
>
>     cnt_max      = cnt.max
>     capped_max   = capped.max
>     capped_width = len(capped)
>
>     @always(clk.posedge, rstn.negedge)
>     def count():
>         if rstn==0:
>             cnt.next = 0
>         else:
>             if cnt + 1 == cnt_max:
>                 cnt.next = 0
>             else:
>                 cnt.next = cnt + 1
>
>     @always_comb
>     def setcapped():
>         if less_flag==1:
>             capped.next = cnt[capped_width:]
>         else:
>             capped.next = 0
>
>     @always_comb
>     def setless():
>         if cnt < capped_max:
>             less_flag.next = 1
>         else:
>             less_flag.next = 0
>
>     return instances()
>
> def tb(capped_max):
>     clk   = Signal(intbv(0)[1:0])
>     rstn  = Signal(intbv(0)[1:0])
>
>     @instance
>     def rstngen():
>         rstn.next = 0
>         yield delay(100)
>         rstn.next = 1
>         yield delay(10000)
>         raise StopSimulation
>
>     @always(delay(10))
>     def clkgen():
>         clk.next = not clk
>
>     capped  = Signal(intbv(0, min=0, max=capped_max))
>     cnt_max = 15
>     dut   = range_check(capped, clk, rstn, cnt_max)
>     return instances()
>
> s = Simulation(tb(4))
> s.run()
> print "4 is OK"
> s = Simulation(tb(5))
> s.run()
> print "5 is not"
>
>

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 1/28/2013 5:54 AM, Per Karlsson wrote:
> Hi!
> Over the weekend I have come to the conclusion that it is an error.
>
> Checking the value of a combinatorical net before it has settled has to be
> wrong. So depending on implementation feasibility and in order of
> preference we could:
>
> - Wait until the net has stabilized before checking the range, or
> - Disable range checks for combinatorical nets, or
> - Assert whenever a signal with range delimiters != 2**n is used as a
> combinatorical net.
>
> What do you say guys?
> /Per
>
>
>
>
> On Fri, Jan 25, 2013 at 1:08 PM, Per Karlsson <bas...@gm...>wrote:
>
>> Hi!
>> Here is something that I can't make up my mind if it is an error or just
>> plain annoying:
>>
>> I have a signal where the max value is not an even 2**n, and I
>> combinatorically assign it the value of a signal with a higher max value,
>> but only on the condition that the value is within range. This is fine.
>>
>> But if the condition is moved to a separate @always_comb driving a flag
>> and the flag gates the assignment, then there is a ValueError. The
>> generated verilog is fine of course.
>> /Per
>>
<snip>

I haven't had much time to look at this issue, I have
been busy trying to reproduce and understand the other
items that may or may not be issues :)

In this case, the Verilog works because it blindly assigns
the value, so /capped/ might momentarily have the incorrect
value but Verilog isn't concerned with an out of range value.
Now, with MyHDL, because of the constraint int behavior the
momentary assignment fails.  The momentary assignment occurs
depending on the order of events in the delta cycle.  In
this case /setcapped/ has both /less_flag/ and /cnt/ in the
sensitivity list.  So, /setcapped/ or /setless/ could execute
first.

What are the rules here?  For an intbv object any time it is
assigned a new value the bounds are checked.

    x = intbv(0, min=0, max=5)
    x[:] = 6   # exception

The simulator doesn't know specifics about the types inside a
signal.  It (the simulator) doesn't discriminate between
different signals (e.g. defer scheduling).  I don't believe
this is something you want to add to the simulator's scheduler.

My view is that you want to avoid this type of modeling
where you have multiple @always_comb dependent on each other
like the example provided.  The power of the bound checking
is greater than the limitations imposed.

I don't think the error is that you get the /ValueError/ on
the delta-cycle but possibly inconsistent behavior (?).  What
I mean by this is if the schedulers always schedules

    /setcapped/ -> /setless/

on the delta-cylces then it is consistent.  If there is the
possibility that

    /setless/ -> /setcapped/

can be scheduled then, this would be an error.  Because
one case you get the /ValueError/ and the other not.  But
I don't know (or forgot) the delta-cycle scheduling rules.
I believe your example demonstrates this?  By simply
changing capped_max you get different behavior.  Should
see if this failed in 0.7 or only 0.8dev?

I would suggest fixing it in the description to something
like:

     @always_comb
     def setcapped():
         if cnt < capped_max:
             capped.next = cnt[capped_width:]
         else:
             capped.next = 0

I realize this might be your *sandbox* example and a
larger design might be organized different.

Thanks for communicating the possible error.
Regards,
Chris

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Per K. <bas...@gm...>]

Hm.
Let's say the flag computation is something a lot more complex, and the
flag is used in a lot of places. Then the verilog is going to be more
compact, easier to maintain and less error prone.
Why then would we want myhdl?

Also, who says you have control over the flag computation? Perhaps it is a
combinatorical output from an IP.  (A myhdl IP of course!)

I think we need to root out all those instances where verilog makes more
sense than myhdl, or designers will stick with verilog.
/Per

On Mon, Jan 28, 2013 at 4:06 PM, Christopher Felton
<chr...@gm...>wrote:

> On 1/28/2013 5:54 AM, Per Karlsson wrote:
> > Hi!
> > Over the weekend I have come to the conclusion that it is an error.
> >
> > Checking the value of a combinatorical net before it has settled has to
> be
> > wrong. So depending on implementation feasibility and in order of
> > preference we could:
> >
> > - Wait until the net has stabilized before checking the range, or
> > - Disable range checks for combinatorical nets, or
> > - Assert whenever a signal with range delimiters != 2**n is used as a
> > combinatorical net.
> >
> > What do you say guys?
> > /Per
> >
> >
> >
> >
> > On Fri, Jan 25, 2013 at 1:08 PM, Per Karlsson <bas...@gm...
> >wrote:
> >
> >> Hi!
> >> Here is something that I can't make up my mind if it is an error or just
> >> plain annoying:
> >>
> >> I have a signal where the max value is not an even 2**n, and I
> >> combinatorically assign it the value of a signal with a higher max
> value,
> >> but only on the condition that the value is within range. This is fine.
> >>
> >> But if the condition is moved to a separate @always_comb driving a flag
> >> and the flag gates the assignment, then there is a ValueError. The
> >> generated verilog is fine of course.
> >> /Per
> >>
> <snip>
>
> I haven't had much time to look at this issue, I have
> been busy trying to reproduce and understand the other
> items that may or may not be issues :)
>
> In this case, the Verilog works because it blindly assigns
> the value, so /capped/ might momentarily have the incorrect
> value but Verilog isn't concerned with an out of range value.
> Now, with MyHDL, because of the constraint int behavior the
> momentary assignment fails.  The momentary assignment occurs
> depending on the order of events in the delta cycle.  In
> this case /setcapped/ has both /less_flag/ and /cnt/ in the
> sensitivity list.  So, /setcapped/ or /setless/ could execute
> first.
>
> What are the rules here?  For an intbv object any time it is
> assigned a new value the bounds are checked.
>
>     x = intbv(0, min=0, max=5)
>     x[:] = 6   # exception
>
> The simulator doesn't know specifics about the types inside a
> signal.  It (the simulator) doesn't discriminate between
> different signals (e.g. defer scheduling).  I don't believe
> this is something you want to add to the simulator's scheduler.
>
> My view is that you want to avoid this type of modeling
> where you have multiple @always_comb dependent on each other
> like the example provided.  The power of the bound checking
> is greater than the limitations imposed.
>
> I don't think the error is that you get the /ValueError/ on
> the delta-cycle but possibly inconsistent behavior (?).  What
> I mean by this is if the schedulers always schedules
>
>     /setcapped/ -> /setless/
>
> on the delta-cylces then it is consistent.  If there is the
> possibility that
>
>     /setless/ -> /setcapped/
>
> can be scheduled then, this would be an error.  Because
> one case you get the /ValueError/ and the other not.  But
> I don't know (or forgot) the delta-cycle scheduling rules.
> I believe your example demonstrates this?  By simply
> changing capped_max you get different behavior.  Should
> see if this failed in 0.7 or only 0.8dev?
>
> I would suggest fixing it in the description to something
> like:
>
>      @always_comb
>      def setcapped():
>          if cnt < capped_max:
>              capped.next = cnt[capped_width:]
>          else:
>              capped.next = 0
>
> I realize this might be your *sandbox* example and a
> larger design might be organized different.
>
> Thanks for communicating the possible error.
> Regards,
> Chris
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 01/28/2013 05:01 PM, Per Karlsson wrote:
> Hm. Let's say the flag computation is something a lot more complex,
> and the flag is used in a lot of places. Then the verilog is going to
> be more compact, easier to maintain and less error prone.

Of course not. It's going be convoluted and require playing delta
cycle games to understand what happens.

> Why then would we want myhdl?

MyHDL is for those who understand that Verilog's extreme
permissevess is evil.

-- 
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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 1/28/13 10:01 AM, Per Karlsson wrote:
> Hm.
> Let's say the flag computation is something a lot more complex, and the
> flag is used in a lot of places. Then the verilog is going to be more
> compact, easier to maintain and less error prone.
> Why then would we want myhdl?
>
> Also, who says you have control over the flag computation? Perhaps it is
> a combinatorical output from an IP.  (A myhdl IP of course!)
>
> I think we need to root out all those instances where verilog makes more
> sense than myhdl, or designers will stick with verilog.
> /Per
>


Ignoring the specific bound check race condition for the
moment, simply because Jan D. would have better insight than
me, I need to take some time and ponder.

Only considering "instances where Verilog makes more sense
than myhdl" proposition. This can be difficult because in
most cases it is, somewhat, subjective and biased on our
past experiences. In Verilog I can do the following all
day long:

     wire [7:0] y;
     reg [2:0] x;
     assign y = 27;
     always @* begin  // or always_comb
         x = y;
     end

Not so much in VHDL and in MyHDL I cannot:

    y = Signal(intbv(27, min=0, max=256))
    x = Signal(intbv(0, min=0, max=4))
    @always_comb
    def hdl():
       x.next = y

Someone might like the Verilog version because  they
implicitly want the behavior - chop it -.  I think most
agree the /intbv/ is a nice abstraction (see [1]).
But if you are use to the rules and behavior of Verilog
it might be hard to break the habit :)

I realize I digressed a bit.  Back to the problem reported.
I want to test this failure with 0.7 and see if it is
something new or something that has been around.  More to
come ...

Regards,
Chris Felton

[1] http://www.jandecaluwe.com/hdldesign/counting.html
[2] 
https://bitbucket.org/cfelton/myhdl_tests/src/tip/test_bound_race.py?at=default

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Per K. <bas...@gm...>]

OK, the range check is essentially an assertion. Now, you wouldn't put an
assertion in a combinatorical block, would you?

So the least you can expect is a warning message that you got one when you
used an intbv with ranges != 2**n as a combinatorical net.

Don't worry, otherwise I like intbv as much as the next guy!
/Per

ps. It behaves the same in 0.7 and 0.8-dev.



On Tue, Jan 29, 2013 at 12:55 PM, Christopher Felton <chr...@gm...
> wrote:

> On 1/28/13 10:01 AM, Per Karlsson wrote:
> > Hm.
> > Let's say the flag computation is something a lot more complex, and the
> > flag is used in a lot of places. Then the verilog is going to be more
> > compact, easier to maintain and less error prone.
> > Why then would we want myhdl?
> >
> > Also, who says you have control over the flag computation? Perhaps it is
> > a combinatorical output from an IP.  (A myhdl IP of course!)
> >
> > I think we need to root out all those instances where verilog makes more
> > sense than myhdl, or designers will stick with verilog.
> > /Per
> >
>
>
> Ignoring the specific bound check race condition for the
> moment, simply because Jan D. would have better insight than
> me, I need to take some time and ponder.
>
> Only considering "instances where Verilog makes more sense
> than myhdl" proposition. This can be difficult because in
> most cases it is, somewhat, subjective and biased on our
> past experiences. In Verilog I can do the following all
> day long:
>
>      wire [7:0] y;
>      reg [2:0] x;
>      assign y = 27;
>      always @* begin  // or always_comb
>          x = y;
>      end
>
> Not so much in VHDL and in MyHDL I cannot:
>
>     y = Signal(intbv(27, min=0, max=256))
>     x = Signal(intbv(0, min=0, max=4))
>     @always_comb
>     def hdl():
>        x.next = y
>
> Someone might like the Verilog version because  they
> implicitly want the behavior - chop it -.  I think most
> agree the /intbv/ is a nice abstraction (see [1]).
> But if you are use to the rules and behavior of Verilog
> it might be hard to break the habit :)
>
> I realize I digressed a bit.  Back to the problem reported.
> I want to test this failure with 0.7 and see if it is
> something new or something that has been around.  More to
> come ...
>
> Regards,
> Chris Felton
>
> [1] http://www.jandecaluwe.com/hdldesign/counting.html
> [2]
>
> https://bitbucket.org/cfelton/myhdl_tests/src/tip/test_bound_race.py?at=default
>
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 01/29/2013 01:21 PM, Per Karlsson wrote:
> OK, the range check is essentially an assertion. Now, you wouldn't put an assertion in a combinatorical block, would you?

Of course I would. Why not?


-- 
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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 1/29/2013 6:21 AM, Per Karlsson wrote:
> OK, the range check is essentially an assertion. Now, you wouldn't put an
> assertion in a combinatorical block, would you?
>

Good point.  In general this is true because we have
these "transitional" values, so yes.

> So the least you can expect is a warning message that you got one when you
> used an intbv with ranges != 2**n as a combinatorical net.
>

At some point you would want the bound check, presumably
once everything settles out.  Does this simply suggest
the assignment should be in clocked process?  Is it fair
to assume the value will be clocked into a register eventually
and the combinatorial assignment shouldn't be used?  In other
words, does the bound assertion help enforce goodness?

> Don't worry, otherwise I like intbv as much as the next guy!
> /Per
>
> ps. It behaves the same in 0.7 and 0.8-dev.
>

Thanks for the additional information,
Chris

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Per K. <bas...@gm...>]

Hm, that would enforce a coding style where every combinatorial cloud must
be written monolithically. You could never break down a combinatorial
problem into parts.

I think this is a bad coding style. It makes for unreadable code, and it
limits the amount of complexity that can be tackled successfully.
/Per

On Tue, Jan 29, 2013 at 2:43 PM, Christopher Felton
<chr...@gm...>wrote:

> On 1/29/2013 6:21 AM, Per Karlsson wrote:
> > OK, the range check is essentially an assertion. Now, you wouldn't put an
> > assertion in a combinatorical block, would you?
> >
>
> Good point.  In general this is true because we have
> these "transitional" values, so yes.
>
> > So the least you can expect is a warning message that you got one when
> you
> > used an intbv with ranges != 2**n as a combinatorical net.
> >
>
> At some point you would want the bound check, presumably
> once everything settles out.  Does this simply suggest
> the assignment should be in clocked process?  Is it fair
> to assume the value will be clocked into a register eventually
> and the combinatorial assignment shouldn't be used?  In other
> words, does the bound assertion help enforce goodness?
>
> > Don't worry, otherwise I like intbv as much as the next guy!
> > /Per
> >
> > ps. It behaves the same in 0.7 and 0.8-dev.
> >
>
> Thanks for the additional information,
> Chris
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 1/29/2013 8:06 AM, Per Karlsson wrote:
> Hm, that would enforce a coding style where every combinatorial cloud must
> be written monolithically. You could never break down a combinatorial
> problem into parts.
>
> I think this is a bad coding style. It makes for unreadable code, and it
> limits the amount of complexity that can be tackled successfully.
> /Per
>

While reviewing the Signal code for the mixed /bool/ and
/intbv[1:]/, I was thinking maybe the Signal object should
be refactored to *not* include the /_setNext/ and /_update/
cases for each type.  But rather have the types provide a
hook.  Currently, this is mainly the /intbv/ type.  But it
will provide a mechanism for user defined modeling types that
can include checks (like the bound check/handle) without
modifying the /Signal/ class.

Instead of the /Signal/ object having a case for each type
it is updating it will check the update for certain attributes

    _sig_set_next(next_val) return next
    _sig_update(next) return val
    _sig_end_sim_cycle()

I am thinking out load here.  Something like this would simplify
the /Signal/ class some but add Signal and Simulation responsibility
to the modeling type.  It would give the user some power to define
checks for custom types she might use in modeling (not conversion,
yet).

This would also give a mechanism to do the deferred check to
the end of the cycle.  But at the cost of extra work to the
simulator, the simulator would have to keep a list of all active
signals in a cycle and then do a final check/walk at the end of
the cycle.  As mentioned this would provide a nice hook for user
defined types and would give a mechanism for the deferred check.

But I have this haunting feeling I am missing something basic and
the error we think is an error might not be?  If we could propose
something like the above as a possible solution.

Regards,
Chris

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 01/29/2013 03:06 PM, Per Karlsson wrote:
> Hm, that would enforce a coding style where every combinatorial cloud
> must be written monolithically. You could never break down a
> combinatorial problem into parts.
>
> I think this is a bad coding style. It makes for unreadable code, and
> it limits the amount of complexity that can be tackled successfully.

Come on, it's really the other way around. *Of course* it is better
to limit a combinatorial block to a single delta cycle, and possibly
use local variables for intermediate steps, instead of doing
everything with signals and a myrad of concatenated combinatorial blocks.




-- 
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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 01/28/2013 04:06 PM, Christopher Felton wrote:
> On 1/28/2013 5:54 AM, Per Karlsson wrote:
>> Hi!
>> Over the weekend I have come to the conclusion that it is an error.

I don't get this. Here, MyHDL tries to check dubious code a soon as
possible (like VHDL). This prevents you from writing convoluted code
that require you to play delta cycle games to see whether or not
a value is in the range it is supposed to be.

That is a good thing, and the intention.

-- 
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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 2/25/2013 9:22 AM, Jan Decaluwe wrote:
> On 01/28/2013 04:06 PM, Christopher Felton wrote:
>> On 1/28/2013 5:54 AM, Per Karlsson wrote:
>>> Hi!
>>> Over the weekend I have come to the conclusion that it is an error.
>
> I don't get this. Here, MyHDL tries to check dubious code a soon as
> possible (like VHDL). This prevents you from writing convoluted code
> that require you to play delta cycle games to see whether or not
> a value is in the range it is supposed to be.
>
> That is a good thing, and the intention.
>

When we were discussing this, the point that got
my attention was:  "where would you insert the
assertion" if it was not build into the /intbv/.

The example provided was someone implementing
a gating operation.  The gate signal occurs at
the same time as the out of bound value.  Yes,
the out of bounds (OOB) is detected ASAP but the
designers intent was to have the OOB gated (blocked).

     @always_comb
     def hdl():
        if block_oob:
           downstream.next = oob_truncation
        else:
           downstream.next = upstream

In this example the designers intent is to prevent
the OOB on the downstream, assuming the upstream
has greater range, the /block_oob/ was generate by
some other logic (OP's example was third party IP).

Are we saying, that generating a combinatorial
selection like this should be avoided because it
is a race-condition and you can't prevent /downstream/
from talking on the OOB value, simulation or physical?

Obviously changing the above to:

    @always_seq(clock.posedge, reset=reset)
    def hdl():
       if block_oob:
          downstream.next = oob_truncation
       else:
          downstream.next = upstream

will fix the issue.

Regards,
Chris

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

Chris:

We are overthinking this. Forget about delta cycles,
combinatorial logic and race conditions.

What we have is a language that hopefully tries to
help us to write better, clearer code.

A signal assignment is an assignment also (albeit
to a future value which may or may not be overwritten.)
When a designer specifies explicitly that a variable/signal
should *always* be within a range that he specifies,
it is a good thing that the language flags a
violation immediately. The fact that signals have
complex postponed behavior is a secondary issue.

What disturbs me a little in this discussion is the
Verilog angle. I think it is rather clear that
VHDL is my reference for "good design" (and Verilog
for "very bad design"). No?

Consider the following trivial VHDL:

--
entity test is
end entity test;

architecture beh of test is

signal a: integer range 0 to 7;

begin

process is
begin
     a <= 8; -- illegal assignment
     a <= 7;
     wait;
end process;

end beh;
--

Modelsim even gives a *compile-time* error here onthe
first assignment, though it is clear that it will
never define the eventual value.

Jan


On 02/25/2013 04:48 PM, Christopher Felton wrote:
> On 2/25/2013 9:22 AM, Jan Decaluwe wrote:
>> On 01/28/2013 04:06 PM, Christopher Felton wrote:
>>> On 1/28/2013 5:54 AM, Per Karlsson wrote:
>>>> Hi!
>>>> Over the weekend I have come to the conclusion that it is an error.
>>
>> I don't get this. Here, MyHDL tries to check dubious code a soon as
>> possible (like VHDL). This prevents you from writing convoluted code
>> that require you to play delta cycle games to see whether or not
>> a value is in the range it is supposed to be.
>>
>> That is a good thing, and the intention.
>>
>
> When we were discussing this, the point that got
> my attention was:  "where would you insert the
> assertion" if it was not build into the /intbv/.
>
> The example provided was someone implementing
> a gating operation.  The gate signal occurs at
> the same time as the out of bound value.  Yes,
> the out of bounds (OOB) is detected ASAP but the
> designers intent was to have the OOB gated (blocked).
>
>       @always_comb
>       def hdl():
>          if block_oob:
>             downstream.next = oob_truncation
>          else:
>             downstream.next = upstream
>
> In this example the designers intent is to prevent
> the OOB on the downstream, assuming the upstream
> has greater range, the /block_oob/ was generate by
> some other logic (OP's example was third party IP).
>
> Are we saying, that generating a combinatorial
> selection like this should be avoided because it
> is a race-condition and you can't prevent /downstream/
> from talking on the OOB value, simulation or physical?
>
> Obviously changing the above to:
>
>      @always_seq(clock.posedge, reset=reset)
>      def hdl():
>         if block_oob:
>            downstream.next = oob_truncation
>         else:
>            downstream.next = upstream
>
> will fix the issue.
>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
>


-- 
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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
> Chris:
>
> We are overthinking this. Forget about delta cycles,
> combinatorial logic and race conditions.

Fair enough.

>
> What we have is a language that hopefully tries to
> help us to write better, clearer code.
>
> A signal assignment is an assignment also (albeit
> to a future value which may or may not be overwritten.)
> When a designer specifies explicitly that a variable/signal
> should *always* be within a range that he specifies,
> it is a good thing that the language flags a
> violation immediately. The fact that signals have
> complex postponed behavior is a secondary issue.
>
> What disturbs me a little in this discussion is the
> Verilog angle. I think it is rather clear that
> VHDL is my reference for "good design" (and Verilog
> for "very bad design"). No?

It was inadvertent.  It was not the goal to imply myhdl
should behave like Verilog.  The oversight was --as you
identified-- not jumping to the VHDL example using a similar
type, that is: the constraint integer.

I am in agreement but I may beat on this topic some more,
purely so that I have a consistent and concise understanding
for future communications.

Regards,
Chris

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 02/26/2013 08:02 PM, Christopher Felton wrote:
> On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
>> Chris:
>>
>> We are overthinking this. Forget about delta cycles,
>> combinatorial logic and race conditions.
>
> Fair enough.
>
>>
>> What we have is a language that hopefully tries to
>> help us to write better, clearer code.
>>
>> A signal assignment is an assignment also (albeit
>> to a future value which may or may not be overwritten.)
>> When a designer specifies explicitly that a variable/signal
>> should *always* be within a range that he specifies,
>> it is a good thing that the language flags a
>> violation immediately. The fact that signals have
>> complex postponed behavior is a secondary issue.
>>
>> What disturbs me a little in this discussion is the
>> Verilog angle. I think it is rather clear that
>> VHDL is my reference for "good design" (and Verilog
>> for "very bad design"). No?
>
> It was inadvertent.  It was not the goal to imply myhdl
> should behave like Verilog.  The oversight was --as you
> identified-- not jumping to the VHDL example using a similar
> type, that is: the constraint integer.

Chris - I was not targetting you in any way. I fully
understand how you try to be helpful and open to
arguments.

I referred to the OP (Mr. Karlsson). Yes, I have a
problem with people who, after looking at MyHDL superficially
from just one angle (Verilog), immediately start
using big words and declarations just because it doesn't
look exactly like what they are used to.

Moreover - because of Verilog's bad design choices
(e.g. not making a difference between signals/variables)
what many Verilog designers are used to as a coding style
is equally bad. Using that as the norm is just too
crazy for words to me.

All of this is of course just my personal opinion - but I
made it abundantly clear on many occasions. Quite obviously,
MyHDL is my attempt to offer a sensible Verilog alternative
to those that share this analysis.

> I am in agreement but I may beat on this topic some more,
> purely so that I have a consistent and concise understanding
> for future communications.

No problem. For example: it is *definitely* a problem when
an "invalid" value sneaks through delta cycle. A signal
monitor has no way to know where it is in delta cycle
convergence process. Therefore, it could take seemingly
"impossible" decisions based on that invalid value.

(I am not talking about hardware here, but about the language
as it may be used in models and test benches. The inclination
to interprete everything in a hardware sense is another
sign of a bad methodology.)

-- 
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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Per K. <bas...@gm...>]

Hi guys!
I'm just back from vacation. It seems to me that Jan and I should both try
to keep a little cooler than we are used to when we're in the same
discussion. I remember no "big" words from my keyboard, but I shall try to
keep them smaller still. :D

So, first a little background: Yes, guilty as charged, I am mostly a
Verilog person. I've spent only a few years with VHDL, and the rest of the
time with Verilog. Therefore I am quite biased.

I think VHDL is chatty, and for me it's harder to think about hardware in
VHDL than in Verilog; and I always think about hardware when I design RTL.
For me RTL is not programming, it is a way to describe hardware.

That said I'm very happy that I found MyHdl, because it allows me to write
hardware in the leaf-cells, but I can use actual programming to build up
the system from the basic blocks and in the testbenches.

Normally I would either build Verilog from strings in Perl, or riddle my
Verilog with code-words and then run it through a Perl pre-processor
(depending on the needs of a particular design). MyHdl allows me to stay in
the same language and use Verilog as a netlist format.
I'm quite pleased with the design and test environments I have set up using
MyHdl, and they are going to get really nice when MEP108 is implemented!

Now, on topic: So, Jan, you are saying that we should never write hardware
where a combinatorial calculation takes more than one delta cycle?
I personally don't see how that is possible, but I have some respect for
the amount of thinking that you have done in this area so I am open to the
possibility that you will convince me otherwise.

It may be my hardware background fooling me (I started out as a rectangle
pusher), but for me glitches in combinatorial nets are near unavoidable.
You can of course balance all the paths to make the logic glitch-free, but
its hardly worth the hassle unless you are designing clock gating or a
reset signal.

This is not to say, of course, that the language has to mimic the
ripple behavior of physical hardware to be of any use. But still, when
sub-blocks or IPs have combinatorial inputs and outputs, or when there is a
combinatorial path through a block I don't see how it is avoidable.

You shouldn't take my rant about partitioning design too seriously, I
usually go a bit overboard when I try to prove a point. Certainly a single
process is best in a self-contained system with few dependencies, but it is
really the only way?

Humble greetings in small words
/Per




On Tue, Feb 26, 2013 at 8:45 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 02/26/2013 08:02 PM, Christopher Felton wrote:
> > On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
> >> Chris:
> >>
> >> We are overthinking this. Forget about delta cycles,
> >> combinatorial logic and race conditions.
> >
> > Fair enough.
> >
> >>
> >> What we have is a language that hopefully tries to
> >> help us to write better, clearer code.
> >>
> >> A signal assignment is an assignment also (albeit
> >> to a future value which may or may not be overwritten.)
> >> When a designer specifies explicitly that a variable/signal
> >> should *always* be within a range that he specifies,
> >> it is a good thing that the language flags a
> >> violation immediately. The fact that signals have
> >> complex postponed behavior is a secondary issue.
> >>
> >> What disturbs me a little in this discussion is the
> >> Verilog angle. I think it is rather clear that
> >> VHDL is my reference for "good design" (and Verilog
> >> for "very bad design"). No?
> >
> > It was inadvertent.  It was not the goal to imply myhdl
> > should behave like Verilog.  The oversight was --as you
> > identified-- not jumping to the VHDL example using a similar
> > type, that is: the constraint integer.
>
> Chris - I was not targetting you in any way. I fully
> understand how you try to be helpful and open to
> arguments.
>
> I referred to the OP (Mr. Karlsson). Yes, I have a
> problem with people who, after looking at MyHDL superficially
> from just one angle (Verilog), immediately start
> using big words and declarations just because it doesn't
> look exactly like what they are used to.
>
> Moreover - because of Verilog's bad design choices
> (e.g. not making a difference between signals/variables)
> what many Verilog designers are used to as a coding style
> is equally bad. Using that as the norm is just too
> crazy for words to me.
>
> All of this is of course just my personal opinion - but I
> made it abundantly clear on many occasions. Quite obviously,
> MyHDL is my attempt to offer a sensible Verilog alternative
> to those that share this analysis.
>
> > I am in agreement but I may beat on this topic some more,
> > purely so that I have a consistent and concise understanding
> > for future communications.
>
> No problem. For example: it is *definitely* a problem when
> an "invalid" value sneaks through delta cycle. A signal
> monitor has no way to know where it is in delta cycle
> convergence process. Therefore, it could take seemingly
> "impossible" decisions based on that invalid value.
>
> (I am not talking about hardware here, but about the language
> as it may be used in models and test benches. The inclination
> to interprete everything in a hardware sense is another
> sign of a bad methodology.)
>
> --
> 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
>      World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

<snip>
>
> Normally I would either build Verilog from strings in Perl, or riddle my
> Verilog with code-words and then run it through a Perl pre-processor
> (depending on the needs of a particular design). MyHdl allows me to stay
> in the same language and use Verilog as a netlist format.
> I'm quite pleased with the design and test environments I have set up
> using MyHdl, and they are going to get really nice when MEP108 is
> implemented!

MEP108 (conversion top-level class methods) is implemented in
0.8dev.

http://www.myhdl.org/doku.php/meps:mep-108

Regards,
Chris

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 02/26/2013 10:52 PM, Per Karlsson wrote:
> Hi guys! I'm just back from vacation. It seems to me that Jan and I
> should both try to keep a little cooler than we are used to when
> we're in the same discussion. I remember no "big" words from my
> keyboard, but I shall try to keep them smaller still. :D

I don't like it if something which is clearly a feature is
described as either an error or an annoyance. And I certainly
don't like it if such an analysis is based on the
"think hardware" conventional wisdom, which is my enemy in
HDL design and which is why I am actually developing MyHDL.

> So, first a little background: Yes, guilty as charged, I am mostly a
> Verilog person. I've spent only a few years with VHDL, and the rest
> of the time with Verilog. Therefore I am quite biased.
>
> I think VHDL is chatty, and for me it's harder to think about
> hardware in VHDL than in Verilog; and I always think about hardware
> when I design RTL. For me RTL is not programming, it is a way to
> describe hardware.

I am tired of such statements. Invariably, they are used as an excuse
for not learning the language in its full expressiveness, and for
ignoring the valuable lessons from software engineering.

> That said I'm very happy that I found MyHdl, because it allows me to
> write hardware in the leaf-cells, but I can use actual programming to
> build up the system from the basic blocks and in the testbenches.
>
> Normally I would either build Verilog from strings in Perl, or riddle
> my Verilog with code-words and then run it through a Perl
> pre-processor (depending on the needs of a particular design). MyHdl
> allows me to stay in the same language and use Verilog as a netlist
> format. I'm quite pleased with the design and test environments I
> have set up using MyHdl, and they are going to get really nice when
> MEP108 is implemented!
>
> Now, on topic: So, Jan, you are saying that we should never write
> hardware where a combinatorial calculation takes more than one delta
> cycle?

No I don't say that. I don't like words like "never" or "always" -
delta cycles have their role.

What I am saying is that the systematic usage of delta cycles and
events as an implicit way to order a sequence of calculations is
a bad idea, given that the language has many provisions to do
so directly, explicitly and locally, without events and delta cycles.

I personally don't see how that is possible,

Really? Well, my designs typically use close to 0 delta cycles. I may use
some combinatorial logic to condition some inputs/outputs, but
that's basically it. Everything is basically done in clocked processes.
BTW - that's much closer to the original meaning of RTL -
Register Transfer Level. True RTL languages don't have events,
delta cycles, or explicit combinatorioal logic.

> but I have some
> respect for the amount of thinking that you have done in this area so
> I am open to the possibility that you will convince me otherwise.

I am not trying to "convince" anyone - everything is provided
for free here so one should convince oneself, or not.

All I'm doing is pointing out misunderstandings and managing
(possibly false) expectations for efficiency reasons. Noone
should lose time unnecessarily.

> It may be my hardware background fooling me (I started out as a
> rectangle pusher), but for me glitches in combinatorial nets are near
> unavoidable.

Of course not.

> You can of course balance all the paths to make the
> logic glitch-free, but its hardly worth the hassle unless you are
> designing clock gating or a reset signal.
>
> This is not to say, of course, that the language has to mimic the
> ripple behavior of physical hardware to be of any use.

That is the point. In synchronous design, that ripple behavior
is irrelevant.

> But still,
> when sub-blocks or IPs have combinatorial inputs and outputs, or when
> there is a combinatorial path through a block I don't see how it is
> avoidable.

All IP blocks should have registered outputs. This is just a matter
of complexity management: localization of concerns.

> You shouldn't take my rant about partitioning design too seriously, I
> usually go a bit overboard when I try to prove a point. Certainly a
> single process is best in a self-contained system with few
> dependencies

Dependencies are not a given, but something that you can
manage and that should be minimized when partitioning a design.

but it is really the only way?

No. It's only the way I prefer.

>
> On Tue, Feb 26, 2013 at 8:45 PM, Jan Decaluwe <ja...@ja...
> <mailto:ja...@ja...>> wrote:
>
> On 02/26/2013 08:02 PM, Christopher Felton wrote:
>> On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
>>> Chris:
>>>
>>> We are overthinking this. Forget about delta cycles,
>>> combinatorial logic and race conditions.
>>
>> Fair enough.
>>
>>>
>>> What we have is a language that hopefully tries to help us to
>>> write better, clearer code.
>>>
>>> A signal assignment is an assignment also (albeit to a future
>>> value which may or may not be overwritten.) When a designer
>>> specifies explicitly that a variable/signal should *always* be
>>> within a range that he specifies, it is a good thing that the
>>> language flags a violation immediately. The fact that signals
>>> have complex postponed behavior is a secondary issue.
>>>
>>> What disturbs me a little in this discussion is the Verilog
>>> angle. I think it is rather clear that VHDL is my reference for
>>> "good design" (and Verilog for "very bad design"). No?
>>
>> It was inadvertent.  It was not the goal to imply myhdl should
>> behave like Verilog.  The oversight was --as you identified-- not
>> jumping to the VHDL example using a similar type, that is: the
>> constraint integer.
>
> Chris - I was not targetting you in any way. I fully understand how
> you try to be helpful and open to arguments.
>
> I referred to the OP (Mr. Karlsson). Yes, I have a problem with
> people who, after looking at MyHDL superficially from just one angle
> (Verilog), immediately start using big words and declarations just
> because it doesn't look exactly like what they are used to.
>
> Moreover - because of Verilog's bad design choices (e.g. not making a
> difference between signals/variables) what many Verilog designers are
> used to as a coding style is equally bad. Using that as the norm is
> just too crazy for words to me.
>
> All of this is of course just my personal opinion - but I made it
> abundantly clear on many occasions. Quite obviously, MyHDL is my
> attempt to offer a sensible Verilog alternative to those that share
> this analysis.
>
>> I am in agreement but I may beat on this topic some more, purely so
>> that I have a consistent and concise understanding for future
>> communications.
>
> No problem. For example: it is *definitely* a problem when an
> "invalid" value sneaks through delta cycle. A signal monitor has no
> way to know where it is in delta cycle convergence process.
> Therefore, it could take seemingly "impossible" decisions based on
> that invalid value.
>
> (I am not talking about hardware here, but about the language as it
> may be used in models and test benches. The inclination to interprete
> everything in a hardware sense is another sign of a bad
> methodology.)
>
> -- 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 World-class digital design:
> http://www.easics.com
>
>
> ------------------------------------------------------------------------------
>
>
Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite
> for free today: http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> <mailto:myh...@li...>
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
>
>
Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite
> for free today: http://p.sf.net/sfu/appdyn_d2d_feb
>
>
>
> _______________________________________________ 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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Per K. <bas...@gm...>]

Hm, you don't like "always" or "never", but "invariably" is OK? I'll grant
you, the "error or annoyance" thing was a bit harsh though...

Anyway, I have no interest in exchanging insults, I just want MyHdl to
become the best hardware design language it can be. Please try to see the
opportunity in someone whose design philosophy is the opposite of yours but
who's still deeply invested in MyHdl.

I don't think there is a contradiction between "thinking hardware" and
modern software development. I'm very hardware-focused, but I yearn for the
possibilities of a real programming language.
I don't deem the future of (general*) hardware design to be high level
synthesis for software guys, I think it lies in giving hardware guys the
proper tools and teaching them how to use them.

So somewhat on topic: I believe our approaches to combinatorial logic is
much the same, we just came there from opposite directions:
For me it is obvious that some combinatorial logic sometimes ripples,
therefore I assume a combinatorial assertion happens when the net is
stable.
If I think about it I realize there are times when a strict assertion is
beneficial, so then I'd like that as an option as well.
For you the features come in the opposite order.

-Cheers!
/Per

* There is of course a bright future for high level synthesis for some
narrowly delimited applications.


On Fri, Mar 1, 2013 at 5:24 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 02/26/2013 10:52 PM, Per Karlsson wrote:
> > Hi guys! I'm just back from vacation. It seems to me that Jan and I
> > should both try to keep a little cooler than we are used to when
> > we're in the same discussion. I remember no "big" words from my
> > keyboard, but I shall try to keep them smaller still. :D
>
> I don't like it if something which is clearly a feature is
> described as either an error or an annoyance. And I certainly
> don't like it if such an analysis is based on the
> "think hardware" conventional wisdom, which is my enemy in
> HDL design and which is why I am actually developing MyHDL.
>
> > So, first a little background: Yes, guilty as charged, I am mostly a
> > Verilog person. I've spent only a few years with VHDL, and the rest
> > of the time with Verilog. Therefore I am quite biased.
> >
> > I think VHDL is chatty, and for me it's harder to think about
> > hardware in VHDL than in Verilog; and I always think about hardware
> > when I design RTL. For me RTL is not programming, it is a way to
> > describe hardware.
>
> I am tired of such statements. Invariably, they are used as an excuse
> for not learning the language in its full expressiveness, and for
> ignoring the valuable lessons from software engineering.
>
> > That said I'm very happy that I found MyHdl, because it allows me to
> > write hardware in the leaf-cells, but I can use actual programming to
> > build up the system from the basic blocks and in the testbenches.
> >
> > Normally I would either build Verilog from strings in Perl, or riddle
> > my Verilog with code-words and then run it through a Perl
> > pre-processor (depending on the needs of a particular design). MyHdl
> > allows me to stay in the same language and use Verilog as a netlist
> > format. I'm quite pleased with the design and test environments I
> > have set up using MyHdl, and they are going to get really nice when
> > MEP108 is implemented!
> >
> > Now, on topic: So, Jan, you are saying that we should never write
> > hardware where a combinatorial calculation takes more than one delta
> > cycle?
>
> No I don't say that. I don't like words like "never" or "always" -
> delta cycles have their role.
>
> What I am saying is that the systematic usage of delta cycles and
> events as an implicit way to order a sequence of calculations is
> a bad idea, given that the language has many provisions to do
> so directly, explicitly and locally, without events and delta cycles.
>
> I personally don't see how that is possible,
>
> Really? Well, my designs typically use close to 0 delta cycles. I may use
> some combinatorial logic to condition some inputs/outputs, but
> that's basically it. Everything is basically done in clocked processes.
> BTW - that's much closer to the original meaning of RTL -
> Register Transfer Level. True RTL languages don't have events,
> delta cycles, or explicit combinatorioal logic.
>
> > but I have some
> > respect for the amount of thinking that you have done in this area so
> > I am open to the possibility that you will convince me otherwise.
>
> I am not trying to "convince" anyone - everything is provided
> for free here so one should convince oneself, or not.
>
> All I'm doing is pointing out misunderstandings and managing
> (possibly false) expectations for efficiency reasons. Noone
> should lose time unnecessarily.
>
> > It may be my hardware background fooling me (I started out as a
> > rectangle pusher), but for me glitches in combinatorial nets are near
> > unavoidable.
>
> Of course not.
>
> > You can of course balance all the paths to make the
> > logic glitch-free, but its hardly worth the hassle unless you are
> > designing clock gating or a reset signal.
> >
> > This is not to say, of course, that the language has to mimic the
> > ripple behavior of physical hardware to be of any use.
>
> That is the point. In synchronous design, that ripple behavior
> is irrelevant.
>
> > But still,
> > when sub-blocks or IPs have combinatorial inputs and outputs, or when
> > there is a combinatorial path through a block I don't see how it is
> > avoidable.
>
> All IP blocks should have registered outputs. This is just a matter
> of complexity management: localization of concerns.
>
> > You shouldn't take my rant about partitioning design too seriously, I
> > usually go a bit overboard when I try to prove a point. Certainly a
> > single process is best in a self-contained system with few
> > dependencies
>
> Dependencies are not a given, but something that you can
> manage and that should be minimized when partitioning a design.
>
> but it is really the only way?
>
> No. It's only the way I prefer.
>
> >
> > On Tue, Feb 26, 2013 at 8:45 PM, Jan Decaluwe <ja...@ja...
> > <mailto:ja...@ja...>> wrote:
> >
> > On 02/26/2013 08:02 PM, Christopher Felton wrote:
> >> On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
> >>> Chris:
> >>>
> >>> We are overthinking this. Forget about delta cycles,
> >>> combinatorial logic and race conditions.
> >>
> >> Fair enough.
> >>
> >>>
> >>> What we have is a language that hopefully tries to help us to
> >>> write better, clearer code.
> >>>
> >>> A signal assignment is an assignment also (albeit to a future
> >>> value which may or may not be overwritten.) When a designer
> >>> specifies explicitly that a variable/signal should *always* be
> >>> within a range that he specifies, it is a good thing that the
> >>> language flags a violation immediately. The fact that signals
> >>> have complex postponed behavior is a secondary issue.
> >>>
> >>> What disturbs me a little in this discussion is the Verilog
> >>> angle. I think it is rather clear that VHDL is my reference for
> >>> "good design" (and Verilog for "very bad design"). No?
> >>
> >> It was inadvertent.  It was not the goal to imply myhdl should
> >> behave like Verilog.  The oversight was --as you identified-- not
> >> jumping to the VHDL example using a similar type, that is: the
> >> constraint integer.
> >
> > Chris - I was not targetting you in any way. I fully understand how
> > you try to be helpful and open to arguments.
> >
> > I referred to the OP (Mr. Karlsson). Yes, I have a problem with
> > people who, after looking at MyHDL superficially from just one angle
> > (Verilog), immediately start using big words and declarations just
> > because it doesn't look exactly like what they are used to.
> >
> > Moreover - because of Verilog's bad design choices (e.g. not making a
> > difference between signals/variables) what many Verilog designers are
> > used to as a coding style is equally bad. Using that as the norm is
> > just too crazy for words to me.
> >
> > All of this is of course just my personal opinion - but I made it
> > abundantly clear on many occasions. Quite obviously, MyHDL is my
> > attempt to offer a sensible Verilog alternative to those that share
> > this analysis.
> >
> >> I am in agreement but I may beat on this topic some more, purely so
> >> that I have a consistent and concise understanding for future
> >> communications.
> >
> > No problem. For example: it is *definitely* a problem when an
> > "invalid" value sneaks through delta cycle. A signal monitor has no
> > way to know where it is in delta cycle convergence process.
> > Therefore, it could take seemingly "impossible" decisions based on
> > that invalid value.
> >
> > (I am not talking about hardware here, but about the language as it
> > may be used in models and test benches. The inclination to interprete
> > everything in a hardware sense is another sign of a bad
> > methodology.)
> >
> > -- 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 World-class digital design:
> > http://www.easics.com
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics Download AppDynamics Lite
> > for free today: http://p.sf.net/sfu/appdyn_d2d_feb
> > _______________________________________________ myhdl-list mailing
> > list myh...@li...
> > <mailto:myh...@li...>
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics Download AppDynamics Lite
> > for free today: http://p.sf.net/sfu/appdyn_d2d_feb
> >
> >
> >
> > _______________________________________________ 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
>      World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 03/01/2013 11:04 PM, Per Karlsson wrote:
> Hm, you don't like "always" or "never", but "invariably" is OK?

So you choose to ignore the obvious difference between an
adverb that simply qualifies an observed fact and a methodology
guideline which I don't want to carve in stone. Irritating.

> So somewhat on topic: I believe our approaches to combinatorial logic
> is much the same, we just came there from opposite directions: For me
> it is obvious that some combinatorial logic sometimes ripples,
> therefore I assume a combinatorial assertion happens when the net is
> stable. If I think about it I realize there are times when a strict
> assertion is beneficial, so then I'd like that as an option as well.
> For you the features come in the opposite order.

No, it's not a matter of order.  I argue that in the context of
MyHDL/VHDL, the inclination of see a hardware interpretation behind
any  HDL line or feature is simply wrong, and leads to a suboptimal
design methodology.

For example, there is nothing in the VHDL LRM about a hardware
interpretation. In particular, the goal of delta cycles is to
let event-driven models converge, not to model the rippling of
comibinatorial logic. Likewise, there is no such thing as a
"combinatorial assertion".

The point is that HDLs have an expressive value by themselves,
regardless of any direct hardware interpretion. Those who understand
that accomplish more in less time.

-- 
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
     World-class digital design: http://www.easics.com