myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] A puzzling error

[garyr <ga...@fi...>]

----- Original Message ----- 
From: "Christopher Felton" <chr...@gm...>
To: <myh...@li...>
Sent: Saturday, February 16, 2013 12:31 PM
Subject: Re: [myhdl-list] A puzzling error


> On 2/16/13 8:57 AM, garyr wrote:
>>
>> ----- Original Message -----
>> From: "Christopher Felton" <chr...@gm...>
>> To: <myh...@li...>
>> Sent: Saturday, February 16, 2013 4:37 AM
>> Subject: Re: [myhdl-list] A puzzling error
>>
>>
>>> On 2/15/13 10:28 PM, garyr wrote:
>>>> Below is a portion of the code for a multiplier module that works fine in
>>>> its
>>>> test bench. It also worked OK as part of a lowpass filter module; that is,
>>>> the
>>>> filter module test bench didn't reveal any problems. But when the filter
>>>> module
>>>> is converted to Verilog an error occurs. The -547 is the value assigned to
>>>> signal 'multiplier'. As you can see it wasn't negated properly; instead of
>>>> (--547) it should be (547). Is this a bug or have I screwed up somewhere?
>>>>
>>>>           elif start == ACTIVE_LOW:
>>>>               done.next = INACTIVE_HIGH
>>>>               result.next = 0
>>>>               if multiplier >= 0:
>>>>                   mpyVar.next = multiplier
>>>>                   negate.next = 0
>>>>               else:
>>>>                   mpyVar.next = -multiplier
>>>>                   negate.next = 1
>>>>
>>>>       else if ((FA_FO_startm == 0)) begin
>>>>           FA_FO_donem <= 1;
>>>>           FA_FO_result <= 0;
>>>>           if ((-547 >= 0)) begin
>>>>               FA_FO_MPY_mpyVar <= -547;
>>>>               FA_FO_MPY_negate <= 0;
>>>>           end
>>>>           else begin
>>>>               FA_FO_MPY_mpyVar <= (--547);
>>>>               FA_FO_MPY_negate <= 1;
>>>>           end
>>>>
>>>
>>>
>>> Why use "--"?  I did the following and it converted ok:
>>>
>>>
>>> ~~~~[MyHDL]~~~~
>>>      def m_neglit(clock, reset, ival, tval, oval, T=544):
>>>
>>>          @always_seq(clock.posedge, reset=reset)
>>>          def hdl():
>>>              if ival > (tval << 2):
>>>                  oval.next = -T
>>>              else:
>>>                  oval.next = --T
>>>
>>>          return hdl
>>>
>>> ~~~~[Verilog]~~~~
>>>      always @(posedge clock, negedge reset) begin: M_NEGLIT_HDL
>>>          if (reset == 0) begin
>>>              oval <= 0;
>>>          end
>>>          else begin
>>>              if ((ival > (tval << 2))) begin
>>>                  oval <= (-544);
>>>              end
>>>              else begin
>>>                  oval <= (-(-544));
>>>              end
>>>          end
>>>      end
>>> ~~~~~~~~~~~~~~~~~
>>>
>>> I tested it with using "T" and using the literal 544
>>> directly in the MyHDL source both methods convert fine.
>>>
>>> But I imagine your question is: why does it convert to
>>> (-(-544))?  The converter, typically, will not evaluate
>>> the code in the generators, it will convert it (translate
>>> line by line), essentially as is (only true for the code
>>> in the generators).  And the Python parsing does not simplify
>>> this expression either, so it is then converted to (-(-544)).
>>>
>>> The next question is: is this bad?  I don't think so, the
>>> converted Verilog behaves the same as the MyHDL and there
>>> should be no issues with synthesis.
>>>
>>> Regards,
>>> Chris
>>
>> Sorry, I didn't fully describe the problem.
>>
>> The signal 'multiplier' received its value from something like:
>>      multiplier.next = int(-0.26757*DATASF)
>> where DATASF had a value of 2**11. MyHDL generated the Verilog text shown
>> above
>> with two consecutive minus signs. The problem arises when this Verilog is
>> loaded into Quartus:
>>
>> Error (10170): Verilog HDL syntax error at lowpass.v(334) near text "-";
>> expecting "(" File: C:/Documents and Settings/Owner/My
>> Documents/Python/MyHDL/AllpassLP/LP3MPY/lowpass.v Line: 334
>>
>> Line 334 is:       FA_FO_MPY_mpyVar <= (--547);
>>
>>
>
> If the converter generated /--547/ sounds like this could
> be a bug.  But I haven't been able to reproduce conversion
> that generates /--547/ versus /(-(-547))/.  What version of
> Python and MyHDL are you using?
>
> Regards,
> Chris

I've written a small bit of code that invokes my multiply module and reproduces
the problem. I've indicated the main points below. I would be happy to send you
copies of this if you like. The test file is about 50 lines, most of which can
be ignored. The multiply file is about 100 lines and includes a test bench.

def test(clk, reset, start, done, mresult, mval):

    State = enum('STATE1', 'STATE2', 'IDLE')
    state = Signal(State.IDLE)

    multiplicand, multiplier = [Signal(intbv(0, min=-DATASF, max=DATASF)) for j
in range(2)]
    result = Signal(intbv(0, min=-RESULTSF, max=2*RESULTSF))
    startm, donem = [Signal(bool(INACTIVE_HIGH)) for j in range(2)]

    MPY = smpy(clk, reset, startm, donem, result, multiplicand, mval, \
            nbitsdata=NBITSDATA, nbitsresult=NBITSRESULT)

    *snip*

def tov():
    clk, reset, start, done = [Signal(bool(0)) for k in range(4)]
    mresult = Signal(intbv(0, min=-RESULTSF, max=RESULTSF))
    toVerilog(test, clk, start, reset, done, mresult, mval=-548)

if __name__ == '__main__':
    tov()


This is the interesting portion of the  multiply function:

def smpy(clk, reset, start, done, result, multiplicand, multiplier, \
            nbitsdata=12, nbitsresult=24):

     *snip*

        elif start == ACTIVE_LOW:
            done.next = INACTIVE_HIGH
            result.next = 0
            if multiplier >= 0:
                mpyVar.next = multiplier
                negate.next = 0
            else:
                mpyVar.next = -(multiplier)
                negate.next = 1

Re: [myhdl-list] A puzzling error

[garyr <ga...@fi...>]

----- Original Message ----- 
From: "Christopher Felton" <chr...@gm...>
To: <myh...@li...>
Sent: Saturday, February 16, 2013 12:31 PM
Subject: Re: [myhdl-list] A puzzling error


> On 2/16/13 8:57 AM, garyr wrote:
>>
>> ----- Original Message -----
>> From: "Christopher Felton" <chr...@gm...>
>> To: <myh...@li...>
>> Sent: Saturday, February 16, 2013 4:37 AM
>> Subject: Re: [myhdl-list] A puzzling error
>>
>>
>>> On 2/15/13 10:28 PM, garyr wrote:
>>>> Below is a portion of the code for a multiplier module that works fine in 
>>>> its
>>>> test bench. It also worked OK as part of a lowpass filter module; that is,
>>>> the
>>>> filter module test bench didn't reveal any problems. But when the filter
>>>> module
>>>> is converted to Verilog an error occurs. The -547 is the value assigned to
>>>> signal 'multiplier'. As you can see it wasn't negated properly; instead of
>>>> (--547) it should be (547). Is this a bug or have I screwed up somewhere?
>>>>
>>>>           elif start == ACTIVE_LOW:
>>>>               done.next = INACTIVE_HIGH
>>>>               result.next = 0
>>>>               if multiplier >= 0:
>>>>                   mpyVar.next = multiplier
>>>>                   negate.next = 0
>>>>               else:
>>>>                   mpyVar.next = -multiplier
>>>>                   negate.next = 1
>>>>
>>>>       else if ((FA_FO_startm == 0)) begin
>>>>           FA_FO_donem <= 1;
>>>>           FA_FO_result <= 0;
>>>>           if ((-547 >= 0)) begin
>>>>               FA_FO_MPY_mpyVar <= -547;
>>>>               FA_FO_MPY_negate <= 0;
>>>>           end
>>>>           else begin
>>>>               FA_FO_MPY_mpyVar <= (--547);
>>>>               FA_FO_MPY_negate <= 1;
>>>>           end
>>>>
>>>
>>>
>>> Why use "--"?  I did the following and it converted ok:
>>>
>>>
>>> ~~~~[MyHDL]~~~~
>>>      def m_neglit(clock, reset, ival, tval, oval, T=544):
>>>
>>>          @always_seq(clock.posedge, reset=reset)
>>>          def hdl():
>>>              if ival > (tval << 2):
>>>                  oval.next = -T
>>>              else:
>>>                  oval.next = --T
>>>
>>>          return hdl
>>>
>>> ~~~~[Verilog]~~~~
>>>      always @(posedge clock, negedge reset) begin: M_NEGLIT_HDL
>>>          if (reset == 0) begin
>>>              oval <= 0;
>>>          end
>>>          else begin
>>>              if ((ival > (tval << 2))) begin
>>>                  oval <= (-544);
>>>              end
>>>              else begin
>>>                  oval <= (-(-544));
>>>              end
>>>          end
>>>      end
>>> ~~~~~~~~~~~~~~~~~
>>>
>>> I tested it with using "T" and using the literal 544
>>> directly in the MyHDL source both methods convert fine.
>>>
>>> But I imagine your question is: why does it convert to
>>> (-(-544))?  The converter, typically, will not evaluate
>>> the code in the generators, it will convert it (translate
>>> line by line), essentially as is (only true for the code
>>> in the generators).  And the Python parsing does not simplify
>>> this expression either, so it is then converted to (-(-544)).
>>>
>>> The next question is: is this bad?  I don't think so, the
>>> converted Verilog behaves the same as the MyHDL and there
>>> should be no issues with synthesis.
>>>
>>> Regards,
>>> Chris
>>
>> Sorry, I didn't fully describe the problem.
>>
>> The signal 'multiplier' received its value from something like:
>>      multiplier.next = int(-0.26757*DATASF)
>> where DATASF had a value of 2**11. MyHDL generated the Verilog text shown 
>> above
>> with two consecutive minus signs. The problem arises when this Verilog is
>> loaded into Quartus:
>>
>> Error (10170): Verilog HDL syntax error at lowpass.v(334) near text "-";
>> expecting "(" File: C:/Documents and Settings/Owner/My
>> Documents/Python/MyHDL/AllpassLP/LP3MPY/lowpass.v Line: 334
>>
>> Line 334 is:       FA_FO_MPY_mpyVar <= (--547);
>>
>>
>
> If the converter generated /--547/ sounds like this could
> be a bug.  But I haven't been able to reproduce conversion
> that generates /--547/ versus /(-(-547))/.  What version of
> Python and MyHDL are you using?
>

I'm using Python 2.6.7 and MyHDL 0.7

Re: [myhdl-list] A puzzling error

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

On 2/16/13 8:57 AM, garyr wrote:
>
> ----- Original Message -----
> From: "Christopher Felton" <chr...@gm...>
> To: <myh...@li...>
> Sent: Saturday, February 16, 2013 4:37 AM
> Subject: Re: [myhdl-list] A puzzling error
>
>
>> On 2/15/13 10:28 PM, garyr wrote:
>>> Below is a portion of the code for a multiplier module that works fine in its
>>> test bench. It also worked OK as part of a lowpass filter module; that is,
>>> the
>>> filter module test bench didn't reveal any problems. But when the filter
>>> module
>>> is converted to Verilog an error occurs. The -547 is the value assigned to
>>> signal 'multiplier'. As you can see it wasn't negated properly; instead of
>>> (--547) it should be (547). Is this a bug or have I screwed up somewhere?
>>>
>>>           elif start == ACTIVE_LOW:
>>>               done.next = INACTIVE_HIGH
>>>               result.next = 0
>>>               if multiplier >= 0:
>>>                   mpyVar.next = multiplier
>>>                   negate.next = 0
>>>               else:
>>>                   mpyVar.next = -multiplier
>>>                   negate.next = 1
>>>
>>>       else if ((FA_FO_startm == 0)) begin
>>>           FA_FO_donem <= 1;
>>>           FA_FO_result <= 0;
>>>           if ((-547 >= 0)) begin
>>>               FA_FO_MPY_mpyVar <= -547;
>>>               FA_FO_MPY_negate <= 0;
>>>           end
>>>           else begin
>>>               FA_FO_MPY_mpyVar <= (--547);
>>>               FA_FO_MPY_negate <= 1;
>>>           end
>>>
>>
>>
>> Why use "--"?  I did the following and it converted ok:
>>
>>
>> ~~~~[MyHDL]~~~~
>>      def m_neglit(clock, reset, ival, tval, oval, T=544):
>>
>>          @always_seq(clock.posedge, reset=reset)
>>          def hdl():
>>              if ival > (tval << 2):
>>                  oval.next = -T
>>              else:
>>                  oval.next = --T
>>
>>          return hdl
>>
>> ~~~~[Verilog]~~~~
>>      always @(posedge clock, negedge reset) begin: M_NEGLIT_HDL
>>          if (reset == 0) begin
>>              oval <= 0;
>>          end
>>          else begin
>>              if ((ival > (tval << 2))) begin
>>                  oval <= (-544);
>>              end
>>              else begin
>>                  oval <= (-(-544));
>>              end
>>          end
>>      end
>> ~~~~~~~~~~~~~~~~~
>>
>> I tested it with using "T" and using the literal 544
>> directly in the MyHDL source both methods convert fine.
>>
>> But I imagine your question is: why does it convert to
>> (-(-544))?  The converter, typically, will not evaluate
>> the code in the generators, it will convert it (translate
>> line by line), essentially as is (only true for the code
>> in the generators).  And the Python parsing does not simplify
>> this expression either, so it is then converted to (-(-544)).
>>
>> The next question is: is this bad?  I don't think so, the
>> converted Verilog behaves the same as the MyHDL and there
>> should be no issues with synthesis.
>>
>> Regards,
>> Chris
>
> Sorry, I didn't fully describe the problem.
>
> The signal 'multiplier' received its value from something like:
>      multiplier.next = int(-0.26757*DATASF)
> where DATASF had a value of 2**11. MyHDL generated the Verilog text shown above
> with two consecutive minus signs. The problem arises when this Verilog is
> loaded into Quartus:
>
> Error (10170): Verilog HDL syntax error at lowpass.v(334) near text "-";
> expecting "(" File: C:/Documents and Settings/Owner/My
> Documents/Python/MyHDL/AllpassLP/LP3MPY/lowpass.v Line: 334
>
> Line 334 is:       FA_FO_MPY_mpyVar <= (--547);
>
>

If the converter generated /--547/ sounds like this could
be a bug.  But I haven't been able to reproduce conversion
that generates /--547/ versus /(-(-547))/.  What version of
Python and MyHDL are you using?

Regards,
Chris

Re: [myhdl-list] A puzzling error

[garyr <ga...@fi...>]

----- Original Message ----- 
From: "Christopher Felton" <chr...@gm...>
To: <myh...@li...>
Sent: Saturday, February 16, 2013 4:37 AM
Subject: Re: [myhdl-list] A puzzling error


> On 2/15/13 10:28 PM, garyr wrote:
>> Below is a portion of the code for a multiplier module that works fine in its
>> test bench. It also worked OK as part of a lowpass filter module; that is,
>> the
>> filter module test bench didn't reveal any problems. But when the filter
>> module
>> is converted to Verilog an error occurs. The -547 is the value assigned to
>> signal 'multiplier'. As you can see it wasn't negated properly; instead of
>> (--547) it should be (547). Is this a bug or have I screwed up somewhere?
>>
>>          elif start == ACTIVE_LOW:
>>              done.next = INACTIVE_HIGH
>>              result.next = 0
>>              if multiplier >= 0:
>>                  mpyVar.next = multiplier
>>                  negate.next = 0
>>              else:
>>                  mpyVar.next = -multiplier
>>                  negate.next = 1
>>
>>      else if ((FA_FO_startm == 0)) begin
>>          FA_FO_donem <= 1;
>>          FA_FO_result <= 0;
>>          if ((-547 >= 0)) begin
>>              FA_FO_MPY_mpyVar <= -547;
>>              FA_FO_MPY_negate <= 0;
>>          end
>>          else begin
>>              FA_FO_MPY_mpyVar <= (--547);
>>              FA_FO_MPY_negate <= 1;
>>          end
>>
>
>
> Why use "--"?  I did the following and it converted ok:
>
>
> ~~~~[MyHDL]~~~~
>     def m_neglit(clock, reset, ival, tval, oval, T=544):
>
>         @always_seq(clock.posedge, reset=reset)
>         def hdl():
>             if ival > (tval << 2):
>                 oval.next = -T
>             else:
>                 oval.next = --T
>
>         return hdl
>
> ~~~~[Verilog]~~~~
>     always @(posedge clock, negedge reset) begin: M_NEGLIT_HDL
>         if (reset == 0) begin
>             oval <= 0;
>         end
>         else begin
>             if ((ival > (tval << 2))) begin
>                 oval <= (-544);
>             end
>             else begin
>                 oval <= (-(-544));
>             end
>         end
>     end
> ~~~~~~~~~~~~~~~~~
>
> I tested it with using "T" and using the literal 544
> directly in the MyHDL source both methods convert fine.
>
> But I imagine your question is: why does it convert to
> (-(-544))?  The converter, typically, will not evaluate
> the code in the generators, it will convert it (translate
> line by line), essentially as is (only true for the code
> in the generators).  And the Python parsing does not simplify
> this expression either, so it is then converted to (-(-544)).
>
> The next question is: is this bad?  I don't think so, the
> converted Verilog behaves the same as the MyHDL and there
> should be no issues with synthesis.
>
> Regards,
> Chris

Sorry, I didn't fully describe the problem.

The signal 'multiplier' received its value from something like:
    multiplier.next = int(-0.26757*DATASF)
where DATASF had a value of 2**11. MyHDL generated the Verilog text shown above
with two consecutive minus signs. The problem arises when this Verilog is
loaded into Quartus:

Error (10170): Verilog HDL syntax error at lowpass.v(334) near text "-";
expecting "(" File: C:/Documents and Settings/Owner/My
Documents/Python/MyHDL/AllpassLP/LP3MPY/lowpass.v Line: 334

Line 334 is:       FA_FO_MPY_mpyVar <= (--547);

Re: [myhdl-list] A puzzling error

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

On 2/15/13 10:28 PM, garyr wrote:
> Below is a portion of the code for a multiplier module that works fine in its
> test bench. It also worked OK as part of a lowpass filter module; that is, the
> filter module test bench didn't reveal any problems. But when the filter module
> is converted to Verilog an error occurs. The -547 is the value assigned to
> signal 'multiplier'. As you can see it wasn't negated properly; instead of
> (--547) it should be (547). Is this a bug or have I screwed up somewhere?
>
>          elif start == ACTIVE_LOW:
>              done.next = INACTIVE_HIGH
>              result.next = 0
>              if multiplier >= 0:
>                  mpyVar.next = multiplier
>                  negate.next = 0
>              else:
>                  mpyVar.next = -multiplier
>                  negate.next = 1
>
>      else if ((FA_FO_startm == 0)) begin
>          FA_FO_donem <= 1;
>          FA_FO_result <= 0;
>          if ((-547 >= 0)) begin
>              FA_FO_MPY_mpyVar <= -547;
>              FA_FO_MPY_negate <= 0;
>          end
>          else begin
>              FA_FO_MPY_mpyVar <= (--547);
>              FA_FO_MPY_negate <= 1;
>          end
>


Why use "--"?  I did the following and it converted ok:


~~~~[MyHDL]~~~~
     def m_neglit(clock, reset, ival, tval, oval, T=544):

         @always_seq(clock.posedge, reset=reset)
         def hdl():
             if ival > (tval << 2):
                 oval.next = -T
             else:
                 oval.next = --T

         return hdl

~~~~[Verilog]~~~~
     always @(posedge clock, negedge reset) begin: M_NEGLIT_HDL
         if (reset == 0) begin
             oval <= 0;
         end
         else begin
             if ((ival > (tval << 2))) begin
                 oval <= (-544);
             end
             else begin
                 oval <= (-(-544));
             end
         end
     end
~~~~~~~~~~~~~~~~~

I tested it with using "T" and using the literal 544
directly in the MyHDL source both methods convert fine.

But I imagine your question is: why does it convert to
(-(-544))?  The converter, typically, will not evaluate
the code in the generators, it will convert it (translate
line by line), essentially as is (only true for the code
in the generators).  And the Python parsing does not simplify
this expression either, so it is then converted to (-(-544)).

The next question is: is this bad?  I don't think so, the
converted Verilog behaves the same as the MyHDL and there
should be no issues with synthesis.

Regards,
Chris

[myhdl-list] A puzzling error

[garyr <ga...@fi...>]

Below is a portion of the code for a multiplier module that works fine in its
test bench. It also worked OK as part of a lowpass filter module; that is, the
filter module test bench didn't reveal any problems. But when the filter module
is converted to Verilog an error occurs. The -547 is the value assigned to
signal 'multiplier'. As you can see it wasn't negated properly; instead of
(--547) it should be (547). Is this a bug or have I screwed up somewhere?

        elif start == ACTIVE_LOW:
            done.next = INACTIVE_HIGH
            result.next = 0
            if multiplier >= 0:
                mpyVar.next = multiplier
                negate.next = 0
            else:
                mpyVar.next = -multiplier
                negate.next = 1

    else if ((FA_FO_startm == 0)) begin
        FA_FO_donem <= 1;
        FA_FO_result <= 0;
        if ((-547 >= 0)) begin
            FA_FO_MPY_mpyVar <= -547;
            FA_FO_MPY_negate <= 0;
        end
        else begin
            FA_FO_MPY_mpyVar <= (--547);
            FA_FO_MPY_negate <= 1;
        end

[myhdl-list] MyHDL comments in a Workshop

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

Recently, I burned the midnight oil to watch some
presentations at [1].  The group is looking at
alternatives to replace their Matlab/Simulink FPGA
configurations for their "seti" like projects.
The SKA group works with (alongside, competes?) the
CASPER folks [2].

An item in a presentation needs correcting.  At one
point a presenter was talking about MyHDL and he
indicated MyHDL does one-to-one conversion, the MyHDL
source to the converted source.  This is not entirely
true, MyHDL has an "elaboration" phase.  In the
elaboration there is a lot of power to be utilized if
one desires.  The description in the generator will be
one-to-one (or close to).  The one-to-one comment was
incorrect in the context and misleading.

One example is Norbo's recent low resource FFT
implementation [3].

Regards,
Chris

[1] https://sites.google.com/site/hpdspworkshopcpt2012/home
[2] https://casper.berkeley.edu/
[3] 
http://article.gmane.org/gmane.comp.python.myhdl/2976/match=re+low+resource+fft+core+myhdl+first+python+modell

Re: [myhdl-list] tristates and inout ports at the top level

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

On 2/11/2013 10:11 AM, garyr wrote:
>
> ----- Original Message -----
> From: "Christopher Felton" <chr...@gm...>
> To: <myh...@li...>
> Sent: Thursday, February 07, 2013 9:29 AM
> Subject: Re: [myhdl-list] tristates and inout ports at the top level
>
>
>> On 2/7/2013 11:18 AM, Christopher Felton wrote:
>>> On 2/7/2013 10:00 AM, Jose Ignacio Villar wrote:
>>>> Hi all!
>>>> First of all I'd like to apologise if this subject has already been
>>>> discussed.  I googled and searched this mailing list for a solution to my
>>>> problem and I couldn't find any answer to it.
>>>> It is about tristates in the top level of my design. Is it possible in
>>>> MyHDL?
>>>> I have integrated a memory controller which one of his ports is
>>>> input/output, and it has to reach outside of the top level since it is used
>>>> to communicate with the off-chip memory. The integration of this controller
>>>> is done through user defined verilog code.
>>>> I read the toVerilog converter but i couldn't find any place where inout
>>>> ports are generated.
>>>>
>>>> Thanks in advance,
>>>> Jose.
>>>>
>>>
>>> This thread/example might help:
>>> http://thread.gmane.org/gmane.comp.python.myhdl/2224/focus=2227
>>>
>>> Regards,
>>> Chris
>>>
>>>
>>
>> Looking at the thread I posted a little closer it might
>> not be what you want.  In the thread they simply resolved
>> the simulation - behavior - of a bidirectional bus.  You
>> are looking for a conversion method.
>>
>> Best of my knowledge there is no support for tri-states.
>> The most common solution is to write a very thin wrapper
>> in Verilog/VHDL to handle the tri-state portion.  There
>> probably is some slick way to keep in all in Python/MyHDL
>> using the <hdl_module>.verilog_code attribute but I have
>> not tried it.
>>
>> Regards,
>> Chris
>
> The following is the code I used to implement a bidirectional bus for a USB
> device (FT245R). I don't pretend to fully understand it all; I arrived at this
> after receiving suggestions from several posts to one of the Altera forums. No
> doubt it could be done in a more elegant manner. Unfortunately the declaration
> of the bidirectional bus signal in the generated Verilog file must be changed
> from output to inout.
>
<snip code>

Thanks for posting this example,

I think something like this should be the general
solution for tri-states (and other device specific
functions, not that tri-state is device specific).

As you elude, we should add to the converters to
detect a /TristateSignal/ at the top-level and
write and /inout/ instead of /in/ or /out/.

Regards,
Chris

Re: [myhdl-list] tristates and inout ports at the top level

[garyr <ga...@fi...>]

----- Original Message ----- 
From: "Christopher Felton" <chr...@gm...>
To: <myh...@li...>
Sent: Thursday, February 07, 2013 9:29 AM
Subject: Re: [myhdl-list] tristates and inout ports at the top level


> On 2/7/2013 11:18 AM, Christopher Felton wrote:
>> On 2/7/2013 10:00 AM, Jose Ignacio Villar wrote:
>>> Hi all!
>>> First of all I'd like to apologise if this subject has already been
>>> discussed.  I googled and searched this mailing list for a solution to my
>>> problem and I couldn't find any answer to it.
>>> It is about tristates in the top level of my design. Is it possible in
>>> MyHDL?
>>> I have integrated a memory controller which one of his ports is
>>> input/output, and it has to reach outside of the top level since it is used
>>> to communicate with the off-chip memory. The integration of this controller
>>> is done through user defined verilog code.
>>> I read the toVerilog converter but i couldn't find any place where inout
>>> ports are generated.
>>>
>>> Thanks in advance,
>>> Jose.
>>>
>>
>> This thread/example might help:
>> http://thread.gmane.org/gmane.comp.python.myhdl/2224/focus=2227
>>
>> Regards,
>> Chris
>>
>>
>
> Looking at the thread I posted a little closer it might
> not be what you want.  In the thread they simply resolved
> the simulation - behavior - of a bidirectional bus.  You
> are looking for a conversion method.
>
> Best of my knowledge there is no support for tri-states.
> The most common solution is to write a very thin wrapper
> in Verilog/VHDL to handle the tri-state portion.  There
> probably is some slick way to keep in all in Python/MyHDL
> using the <hdl_module>.verilog_code attribute but I have
> not tried it.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

The following is the code I used to implement a bidirectional bus for a USB
device (FT245R). I don't pretend to fully understand it all; I arrived at this
after receiving suggestions from several posts to one of the Altera forums. No
doubt it could be done in a more elegant manner. Unfortunately the declaration
of the bidirectional bus signal in the generated Verilog file must be changed
from output to inout.

def usbIO(clk, TXE, RXF, RD, WR, rxbyte, txbyte, usbbus):
    @always(clk.negedge)
    def logic():
        pass
    TXE.read = True
    RXF.read = True
    RD.read = True
    WR.read = True
    rxbyte.driven = "wire"
    txbyte.read = True
    usbbus.driven = "wire"      # must be changed to inout in usbIO.v.
    return logic
usbIO.verilog_code = \
"""
/*
    TXE     -   Write enable
    WR      -   Write strobe
    RXF     -   Read enable, active low
    RD      -   Read strobe, active low
    rxbyte  -   Byte received from device
    txbyte  -   Byte to be transmitted to device
    usbbus  -   Bidirectional I/O bus

input clk, TXE, RXF, RD, WR;
input [7:0] txbyte;
output [7:0] rxbyte;
inout [7:0] usbbus;
*/
reg [7:0] usbbusEn, rxbyteIn;
assign $rxbyte = rxbyteIn;
assign $usbbus = usbbusEn;

    always @ (negedge $clk) begin
        if (~$RXF & ~$RD)
            rxbyteIn <= $usbbus;

        if (~$TXE & $WR)
            usbbusEn <= $txbyte;

        if ($TXE == 1)
            usbbusEn <= 8'bz;
    end
"""

Re: [myhdl-list] tristates and inout ports at the top level

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

On 2/7/2013 11:18 AM, Christopher Felton wrote:
> On 2/7/2013 10:00 AM, Jose Ignacio Villar wrote:
>> Hi all!
>> First of all I'd like to apologise if this subject has already been
>> discussed.  I googled and searched this mailing list for a solution to my
>> problem and I couldn't find any answer to it.
>> It is about tristates in the top level of my design. Is it possible in
>> MyHDL?
>> I have integrated a memory controller which one of his ports is
>> input/output, and it has to reach outside of the top level since it is used
>> to communicate with the off-chip memory. The integration of this controller
>> is done through user defined verilog code.
>> I read the toVerilog converter but i couldn't find any place where inout
>> ports are generated.
>>
>> Thanks in advance,
>> Jose.
>>
>
> This thread/example might help:
> http://thread.gmane.org/gmane.comp.python.myhdl/2224/focus=2227
>
> Regards,
> Chris
>
>

Looking at the thread I posted a little closer it might
not be what you want.  In the thread they simply resolved
the simulation - behavior - of a bidirectional bus.  You
are looking for a conversion method.

Best of my knowledge there is no support for tri-states.
The most common solution is to write a very thin wrapper
in Verilog/VHDL to handle the tri-state portion.  There
probably is some slick way to keep in all in Python/MyHDL
using the <hdl_module>.verilog_code attribute but I have
not tried it.

Regards,
Chris

Re: [myhdl-list] tristates and inout ports at the top level

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

On 2/7/2013 10:00 AM, Jose Ignacio Villar wrote:
> Hi all!
> First of all I'd like to apologise if this subject has already been
> discussed.  I googled and searched this mailing list for a solution to my
> problem and I couldn't find any answer to it.
> It is about tristates in the top level of my design. Is it possible in
> MyHDL?
> I have integrated a memory controller which one of his ports is
> input/output, and it has to reach outside of the top level since it is used
> to communicate with the off-chip memory. The integration of this controller
> is done through user defined verilog code.
> I read the toVerilog converter but i couldn't find any place where inout
> ports are generated.
>
> Thanks in advance,
> Jose.
>

This thread/example might help:
http://thread.gmane.org/gmane.comp.python.myhdl/2224/focus=2227

Regards,
Chris

[myhdl-list] tristates and inout ports at the top level

[Jose I. V. <jo...@dt...>]

Hi all!
First of all I'd like to apologise if this subject has already been
discussed.  I googled and searched this mailing list for a solution to my
problem and I couldn't find any answer to it.
It is about tristates in the top level of my design. Is it possible in
MyHDL?
I have integrated a memory controller which one of his ports is
input/output, and it has to reach outside of the top level since it is used
to communicate with the off-chip memory. The integration of this controller
is done through user defined verilog code.
I read the toVerilog converter but i couldn't find any place where inout
ports are generated.

Thanks in advance,
Jose.


José Ignacio Villar <jo...@dt...>
Departamento de Tecnología Electrónica
Escuela Técnica Superior de Ingeniería Informática
Universidad de Sevilla
Avda. Reina Mercedes, s/n
41012 - Sevilla (Spain)

[myhdl-list] Some good conversations about MyHDL

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

MyHDL'ers you might be interested in Jan's latest post
at APP [1].  The comments are worth a read, the comment
conversations have been improving (from a technical point
of view).  If you have general comments you wanted Jan D. to
reply to I am sure you could post them there if you like.

[1] 
http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=258486&

Re: [myhdl-list] FPGA and Verilog Training Class For Python developers

[David B. <dav...@ya...>]

This sounds interesting.  I will definitely try this program and see as to how much skills can be obtained.
David Blubaugh



--- On Sat, 2/2/13, Christopher Lozinski <loz...@fr...> wrote:

From: Christopher Lozinski <loz...@fr...>
Subject: [myhdl-list] FPGA and Verilog Training Class For Python developers
To: myh...@li...
Date: Saturday, February 2, 2013, 3:20 PM

http://wiki.myhdlclass.com:8080/TrainingClass

This is a class for Python developers who are interested in digital
design, and want to learn more. It is particularly good for people
interested in MyHDL. I believe it is relatively easy to use MyHDL to
create a circuit design that simulates and creates some useful output.
It much much harder to create a circuit that works on a FPGA. In order
to be successful, you need to know a lot of rules about digital circuit
design.

Our approach is to watch a video of a FPGA Digital Design class. we are
starting with this one.

http://www.youtube.com/playlist?list=PL2BA78454E71FF0E5

I have watched the first two lectures.    I really like the teacher. I
have already learned a great deal about Digital Design that I did not
know. There are 26 lectures all together. If we meet twice a week, then
we will cover this material in 13 weeks. There must be other excellent
online videos we can watch after these.

We will watch the videos using Google Hangouts. They have the option for
multiple people to watch a youtube video simultaneously. When we do not
understand something, we can stop the video, rewind it, and hopefully
someone in the class can explain what the confusion is.  After class, we
invite you to present your designs, or anything else you want to talk
about.   People are free to leave when they want.  

I am of course open to your suggestions as to how the class should be run.

 Starts March 1st, 2013, maybe sooner. At least 13 weeks duration. Free.
You are welcome to join anytime.

Timing will depend on people's time zones and schedules.   I am on the
US East Coast Time Zone.

If you are interested, I invite you to join our Google Plus Community.

https://plus.google.com/s/pythonchip

Invite your friends!

 

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_jan
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] FPGA and Verilog Training Class For Python developers

[Christopher L. <loz...@fr...>]

http://wiki.myhdlclass.com:8080/TrainingClass

This is a class for Python developers who are interested in digital
design, and want to learn more. It is particularly good for people
interested in MyHDL. I believe it is relatively easy to use MyHDL to
create a circuit design that simulates and creates some useful output.
It much much harder to create a circuit that works on a FPGA. In order
to be successful, you need to know a lot of rules about digital circuit
design.

Our approach is to watch a video of a FPGA Digital Design class. we are
starting with this one.

http://www.youtube.com/playlist?list=PL2BA78454E71FF0E5

I have watched the first two lectures.    I really like the teacher. I
have already learned a great deal about Digital Design that I did not
know. There are 26 lectures all together. If we meet twice a week, then
we will cover this material in 13 weeks. There must be other excellent
online videos we can watch after these.

We will watch the videos using Google Hangouts. They have the option for
multiple people to watch a youtube video simultaneously. When we do not
understand something, we can stop the video, rewind it, and hopefully
someone in the class can explain what the confusion is.  After class, we
invite you to present your designs, or anything else you want to talk
about.   People are free to leave when they want.  

I am of course open to your suggestions as to how the class should be run.

 Starts March 1st, 2013, maybe sooner. At least 13 weeks duration. Free.
You are welcome to join anytime.

Timing will depend on people's time zones and schedules.   I am on the
US East Coast Time Zone.

If you are interested, I invite you to join our Google Plus Community.

https://plus.google.com/s/pythonchip

Invite your friends!

 

Regards
Chris

Re: [myhdl-list] Synopsis of reported issues

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

I added items 2 and 4 to the sourceforge tracker.

Regards,
Chris Felton

[myhdl-list] Synopsis of reported issues

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

Ok, there have been a burst of issues reported in the last couple
weeks.  I am trying to keep track of them, understand them,
and determine how severe the issues might be and possible
corrections.  All with the hope, to provide a clear definition
of the issues and help move things along.  Jan D. will have the
final say on all the issues.  There were two general simulation
and modeling issues and the rest were VHDL conversion failures.

    1. Mixing /bool/ and /intbv/.  This is a new issues in
       0.8dev.  This may simply be a mid-feature collision?  The
       fix, I believe makes sense, is to cast (is that the correct
       Python terminology) the /val/ in /_SetNextBool/ to a
       /bool/ and to an /int/ in /_SetNextInt/.  This will
       prevent the /Signal/ type (/val/) from changing.

       I can submit a patch for these changes but I will wait
       to see if the 0.8dev changes are in a final form [1].


    2. The "bound check race condition".  This is the error that
       arises from an /intbv/ bound check on a delta cycle,
       essentially an *assertion*.  Complex descriptions might
       have invalid delta cycle values (everything cannot be
       updated simultaneous).  Per K., which I agree, correctly
       identified that the bound check should be deferred to the
       end of the simulation step (after all delta-cycles).

       I have some ideas (I am sure Jan D. has the solution :) )
       and I can proposed an enhancement in a seprate thread, it
       could get involved.

    3. The following fails in VHDL conversion:
       x = Signal(intbv(0, min=0, max=8))
       y = Signal(intbv(0, min=0, max=8))
       z = Signal(bool(0))

       @always ...
           z.next = x[0] * y[0]

       The bit-operation "castings" might need some looking at?
       The tests could use some updating to cover lots of these
       cases.

    4. More than two right hand side operands fail VHDL
       conversion if the operands are mixed sizes:
          ...
          z.next = a + b + c

       Thomas Heller, pointed out this issue and reinforced that
       MyHDL has the design goal to handle the sizing and typing.

    5. Possible enhancment, VHDL conversion fails for an edge
       sensitive conditional for the following cases:
       It was indicated the following (at least 2) worked in
       previous versions.  Need to verify this and determine
       what might changed for edge sensitive conditionals.
          2. if sig == False
          3. if sig == intbv(0)

       And I am not convinced that /if not sig/ should not be
       supported.  It is acceptable (as shown in the mailing
       list) for non edge sensitve signals.  Why the limitation
       for edge sensitive signals in VHDL conversion.

    6. Older issue that was identified as a bug, for modeling
       only, attributes fail to be added to the sensitivty list
       in /always_comb/ generators.


I have tests for all of these in a bitbucket repo [2].

Thanks to everyone for reporting the issues and being patient
as we figure them out.  I was mistaken, it looks like Jan D.
has been actively using the sourceforge tracking [3] so I will
start adding the above to the bug list.

Regards,
Chris

[1] 
https://bitbucket.org/cfelton/myhdl_dev/src/tip/myhdl/_Signal.py?at=0.8-dev#cl-260

[2] https://bitbucket.org/cfelton/myhdl_tests

[3] http://sourceforge.net/tracker/?atid=596332&group_id=91207&func=browse

Re: [myhdl-list] VHDL Conversion Errors

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

On 1/26/13 8:30 PM, Christopher Felton wrote:
> <snip>
>>
>>           1 = /if not reset/
>>           2 = /reset == False/
>>           3 = /reset == bool(0)/
>>           4 = /reset == 0/
>>           5 = /reset == intbv(0)/
<snip>
>
> Norbo, thanks for posting this.  I think we got
> a little off track with this "issue", which I don't
> think is an issue.  The errors we were seeing were with
> the special case of *reset*.  As you demonstrated the
> different conditional statements work fine (except case 5).
> It is only the *reset* case that raises some questions with
> VHDL conversion or more generally an edge sensitive signal
> other than a clock.
>
> In the manual [1] Jan calls out /reset == 0/.  I think this
> is ok to require this for the reset cases.  It can be an
> enhancement to add /reset == False/ but I don't think it
> is a bug and I think it would be low priority enhancement.
> Since the four cases work fine in the other uses, I don't
> see the *reset* case being much worry, especially since we
> can use the /@always_seq/ with the latest 0.8dev.
>

Here is Jan's earlier response on this topic:
http://article.gmane.org/gmane.comp.python.myhdl/2773/match=logical+interpretation

Regards,
Chris

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?

[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 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...>]

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?

[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...>]

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?

[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