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