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
>