myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Introduction and Question

[Daryl W. <dw...@ou...>]

Hello everybody,

I thought I would introduce myself, since I've been monitoring this mailing
list for a few months and dabbling with MyHDL for about the same amount 
of time. I have had some success, and I am probably looking at making it 
my primary language for IP development.

My name is Daryl, and I am a graduate student at the University of Utah. A 
big focus of my research is in implementing real-time DSP algorithms for 
applications in wireless communications. To this end, I occasionally find 
myself requiring IP blocks that are not readily available to me, and I end 
up writing my own. I have had some success, but I'm still learning. I am 
extremely interested in MyHDL because of its ability for unit testing and 
incorporating Python-based algorithm code into my test benches. 
Currently, I use VHDL most heavily, although I learned HDL with Verilog. 

For various reasons, I would prefer the end product to be in VHDL. For 
this reason, I was wondering if any progress had been made regarding 
CoSimulation with GHDL? If not, is there any reason I shouldn't try to 
work on this myself (i.e., someone already knows that it won't work)?

I found this link: http://www.myhdl.org/doku.php/dev:vhdl_cosim

Which I think suggests that the VPI interface is supported although I'm not 
clear that it says that... I've never used cosimulation in VHDL or Verilog 
before, so I don't know much about it (yet). The manual for MyHDL 0.7 
says that GHDL support is not there, unless I'm misreading it. Although, 
it lists GHDL in the list of possible simulators.

Thanks and nice to meet you all,
Daryl 

[myhdl-list] Interfaces (MEP-107 recap) and a Question

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

We had some good conversations about MEP-107 [1].  One
of the concepts introduced during the conversations was
the idea of "interfaces" (thanks Jan D.)  instead of
"containers".  My original MEP was over-reaching trying
to include all high-level structures that could contain
a Signal object.  Through the conversations this was narrowed
to interfaces.  An interface is an object passed as a
port to a myhdl module that has a Signal as an attribute.
These interfaces are supported in today's released versions
but you have to explicitly reference each signal in the
module but outside the generators, i.e. in the elaboration
phase (thanks to Oscar D. for pointing out the current support).

Example:

     def complex_add(x,y,z):
         # reference the Signals in the interface
         xr,xi = x.real,x.imag
         yr,yi = y.real,y.imag
         zr,zi = z.real,z.imag

         @always_comb
         def hdl_add():
             zr.next = xr + yr
             zi.next = xi + yi

         return hdl_add

Although this is a basic (digestible) example, this design
pattern can be very powerful and will convert with today's
releases.

MEP-107 proposes the feature to convert attributes so
designs have the option to write code like the above example
or by directly accessing the attributes in the generator.
The following would be the complex add with MEP-107:

     def complex_add(x,y,z):
         @always_comb
         def hdl_add():
             z.real = x.real + y.real
             z.imag = x.imag + y.imag

         return hdl_add

Although, this example illustrates the power of using the
attributes directly there are larger examples were using
the local references is preferred.  I reiterate interfaces
are supported in today's versions if locally referenced.

Another powerful feature of interfaces is *transactors*.
In this context a transactor is a piece of software that
replaces a digital function with a simplified implementation.
This can have huge speed and test implications on systems.
A simple example is an external serial interface, say
something as simple as an SPI bus.  The SPI bus is serial
and typically much slower (per bit) than the system.
The SPI bus can take a lot of simulation cycles to complete
a transfer.  If the physical SPI bus Signals are encapsulated
in an object it can also have a transactor function.

     def digi_sys(clock, reset, spi_bus, control_bus):
         # ...
         gspi = spi(clock, reset, spi_bus, mem_bus)
         # ...

     def spi(clock, reset, spi_bus, mem_bus):
         #... define spi slave functionality
         #...
         if spi_bus.use_transactor:
             g = spi_bus.Transactor(clock, reset, mem_bus)
         else:
             g = (hdl_serial_input, hdl_mem_intf) # ...
         return g

More is needed for this example to be complete but I hope
it gives a little idea how a *transactor* can be built
directly into the system.  Where I think this is beneficial
is you don't need a separate simulation environment to
remove/replace different interfaces, it can be built directly
into one simulation environment.  This simulation/verification 
environment can easily be configured to test different
levels of functionality.

That was a lot of background to recap and to get to my
question.  I want to update the MEP with this solidified
definition.  Should MEP-107 be rewritten or should it be
rejected as is and a new MEP created?  I would like to
rewrite/create with an updated focus on:

    * developing the concept of *interfaces* and clearly
      defining
    * example what is currently supported
    * proposal for direct usage of attributes
    * inclusion possible approach to implement attributes

Thanks,
Chris Felton

[1] http://www.myhdl.org/doku.php/meps:mep-107

Re: [myhdl-list] Signal initialization

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

On 12/3/12 11:37 AM, Angel Ezquerra wrote:
>
> On Dec 3, 2012 6:30 PM, "Christopher Felton" <chr...@gm...
> <mailto:chr...@gm...>> wrote:
>  >
>  > On 12/3/12 10:30 AM, Angel Ezquerra wrote:
>  > > On Mon, Dec 3, 2012 at 3:29 PM, Christopher Felton
>  > > <chr...@gm... <mailto:chr...@gm...>> wrote:
>  > >> <snip>
>  > >>>>
>  > >>>> Based on my recollection it has been agreed upon that using
> initialized
>  > >>>> signals/variables in the converted HDL (both VHDL and Verilog) is
>  > >>>> desired to avoid MyHDL simulation mismatch with the target HDL.
>   But in
>  > >>>> some cases it was disabled because it was not supported by FPGA
> vendor
>  > >>>> synthesis tools.  This was true with Verilog and Altera Quartus
> but my
>  > >>>> guess is that the synthesis tools probably support the VHDL
>  > >>>> initialization fine (have never ran into an issue).
>  > >>>>
>  > >>>> The initialization might have been disable because the converted
> Verilog
>  > >>>> and VHDL would differ (a guess)?
>  > >>>>
>  > >>>> I quick test and the modified line 306 in _toVHDL.py in the latest
>  > >>>> 0.8dev to:
>  > >>>>
>  > >>>>       print >> f, "signal %s: %s%s := %s;" % (s._name, p, r,
> str(s._val))
>  > >>>
>  > >>> I'll give this a try.
>  > >>> Interestingly, the lines right above the one you modified are as
> follows:
>  > >>>
>  > >>>       # the following line implements initial value assignments
>  > >>>       # print >> f, "%s %s%s = %s;" % (s._driven, r, s._name,
> int(s._val))
>  > >>>
>  > >>> They are commented, but they seem to be intended to do what we want
>  > >>> although  the code looks different enough that I am not sure this
>  > >>> would work with the current version of _toVHDL (there is no explicit
>  > >>> "signal", it uses _driven() and converts the value to an int rather
>  > >>> than calling str() on it).
>  > >>
>  > >> I am not sure what the comment line is but I do not believe it is
>  > >> correct (at least not for VHDL).  Someone would have to review the
>  > >> history to see
>  > >
>  > > I just did. That code is there since the toVHDL module was introduced,
>  > > and it seems it was copied and pasted code from the toVerilog module
>  > > (which predates it), since that exact line of code is found on the
>  > > toVerilog module as well.
>  > >
>  > > By the way, I also tried your proposed "hack" and it almost works. The
>  > > problem is that it just prints the initial value as is, wich means
>  > > that it initialized std_logic values to False, for example, rather
>  > > than to '0'.
>  > >
>  > >
>  >
>  > Yes, the *quick* hack wasn't intended to be a completed feature.  As you
>  > point out the *quick* hack isn't that useful.
>  >
>  > For a complete solution probably need to write a _getInitValue function
>  > which would be similar to the _getTypeString or _getRangeString.  Then
>  > it can format the the init value for the correct type.
>  >
>  > Regards,
>  > Chris
>
> Chris,
>
> I didn't mean to imply that the "hack" was wrong or anything like that.
> I did not and should not expect it to be flawless. I just wanted to
> point out the result of my test.
>
> Thanks again for your help and your comments. I really appreciate them!
>
> Angel
>

No problem but the "hack" is incomplete.  It is good to point out short 
comings etc.  No worries.

Regards,
Chris

Re: [myhdl-list] Signal initialization

[Angel E. <ang...@gm...>]

On Dec 3, 2012 6:30 PM, "Christopher Felton" <chr...@gm...> wrote:
>
> On 12/3/12 10:30 AM, Angel Ezquerra wrote:
> > On Mon, Dec 3, 2012 at 3:29 PM, Christopher Felton
> > <chr...@gm...> wrote:
> >> <snip>
> >>>>
> >>>> Based on my recollection it has been agreed upon that using
initialized
> >>>> signals/variables in the converted HDL (both VHDL and Verilog) is
> >>>> desired to avoid MyHDL simulation mismatch with the target HDL.  But
in
> >>>> some cases it was disabled because it was not supported by FPGA
vendor
> >>>> synthesis tools.  This was true with Verilog and Altera Quartus but
my
> >>>> guess is that the synthesis tools probably support the VHDL
> >>>> initialization fine (have never ran into an issue).
> >>>>
> >>>> The initialization might have been disable because the converted
Verilog
> >>>> and VHDL would differ (a guess)?
> >>>>
> >>>> I quick test and the modified line 306 in _toVHDL.py in the latest
> >>>> 0.8dev to:
> >>>>
> >>>>       print >> f, "signal %s: %s%s := %s;" % (s._name, p, r,
str(s._val))
> >>>
> >>> I'll give this a try.
> >>> Interestingly, the lines right above the one you modified are as
follows:
> >>>
> >>>       # the following line implements initial value assignments
> >>>       # print >> f, "%s %s%s = %s;" % (s._driven, r, s._name,
int(s._val))
> >>>
> >>> They are commented, but they seem to be intended to do what we want
> >>> although  the code looks different enough that I am not sure this
> >>> would work with the current version of _toVHDL (there is no explicit
> >>> "signal", it uses _driven() and converts the value to an int rather
> >>> than calling str() on it).
> >>
> >> I am not sure what the comment line is but I do not believe it is
> >> correct (at least not for VHDL).  Someone would have to review the
> >> history to see
> >
> > I just did. That code is there since the toVHDL module was introduced,
> > and it seems it was copied and pasted code from the toVerilog module
> > (which predates it), since that exact line of code is found on the
> > toVerilog module as well.
> >
> > By the way, I also tried your proposed "hack" and it almost works. The
> > problem is that it just prints the initial value as is, wich means
> > that it initialized std_logic values to False, for example, rather
> > than to '0'.
> >
> >
>
> Yes, the *quick* hack wasn't intended to be a completed feature.  As you
> point out the *quick* hack isn't that useful.
>
> For a complete solution probably need to write a _getInitValue function
> which would be similar to the _getTypeString or _getRangeString.  Then
> it can format the the init value for the correct type.
>
> Regards,
> Chris

Chris,

I didn't mean to imply that the "hack" was wrong or anything like that. I
did not and should not expect it to be flawless. I just wanted to point out
the result of my test.

Thanks again for your help and your comments. I really appreciate them!

Angel

Re: [myhdl-list] Signal initialization

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

On 12/3/12 10:30 AM, Angel Ezquerra wrote:
> On Mon, Dec 3, 2012 at 3:29 PM, Christopher Felton
> <chr...@gm...> wrote:
>> <snip>
>>>>
>>>> Based on my recollection it has been agreed upon that using initialized
>>>> signals/variables in the converted HDL (both VHDL and Verilog) is
>>>> desired to avoid MyHDL simulation mismatch with the target HDL.  But in
>>>> some cases it was disabled because it was not supported by FPGA vendor
>>>> synthesis tools.  This was true with Verilog and Altera Quartus but my
>>>> guess is that the synthesis tools probably support the VHDL
>>>> initialization fine (have never ran into an issue).
>>>>
>>>> The initialization might have been disable because the converted Verilog
>>>> and VHDL would differ (a guess)?
>>>>
>>>> I quick test and the modified line 306 in _toVHDL.py in the latest
>>>> 0.8dev to:
>>>>
>>>>       print >> f, "signal %s: %s%s := %s;" % (s._name, p, r, str(s._val))
>>>
>>> I'll give this a try.
>>> Interestingly, the lines right above the one you modified are as follows:
>>>
>>>       # the following line implements initial value assignments
>>>       # print >> f, "%s %s%s = %s;" % (s._driven, r, s._name, int(s._val))
>>>
>>> They are commented, but they seem to be intended to do what we want
>>> although  the code looks different enough that I am not sure this
>>> would work with the current version of _toVHDL (there is no explicit
>>> "signal", it uses _driven() and converts the value to an int rather
>>> than calling str() on it).
>>
>> I am not sure what the comment line is but I do not believe it is
>> correct (at least not for VHDL).  Someone would have to review the
>> history to see
>
> I just did. That code is there since the toVHDL module was introduced,
> and it seems it was copied and pasted code from the toVerilog module
> (which predates it), since that exact line of code is found on the
> toVerilog module as well.
>
> By the way, I also tried your proposed "hack" and it almost works. The
> problem is that it just prints the initial value as is, wich means
> that it initialized std_logic values to False, for example, rather
> than to '0'.
>
>

Yes, the *quick* hack wasn't intended to be a completed feature.  As you 
point out the *quick* hack isn't that useful.

For a complete solution probably need to write a _getInitValue function 
which would be similar to the _getTypeString or _getRangeString.  Then 
it can format the the init value for the correct type.

Regards,
Chris

Re: [myhdl-list] Signal initialization

[Angel E. <ang...@gm...>]

On Mon, Dec 3, 2012 at 3:29 PM, Christopher Felton
<chr...@gm...> wrote:
> <snip>
>>>
>>> Based on my recollection it has been agreed upon that using initialized
>>> signals/variables in the converted HDL (both VHDL and Verilog) is
>>> desired to avoid MyHDL simulation mismatch with the target HDL.  But in
>>> some cases it was disabled because it was not supported by FPGA vendor
>>> synthesis tools.  This was true with Verilog and Altera Quartus but my
>>> guess is that the synthesis tools probably support the VHDL
>>> initialization fine (have never ran into an issue).
>>>
>>> The initialization might have been disable because the converted Verilog
>>> and VHDL would differ (a guess)?
>>>
>>> I quick test and the modified line 306 in _toVHDL.py in the latest
>>> 0.8dev to:
>>>
>>>      print >> f, "signal %s: %s%s := %s;" % (s._name, p, r, str(s._val))
>>
>> I'll give this a try.
>> Interestingly, the lines right above the one you modified are as follows:
>>
>>      # the following line implements initial value assignments
>>      # print >> f, "%s %s%s = %s;" % (s._driven, r, s._name, int(s._val))
>>
>> They are commented, but they seem to be intended to do what we want
>> although  the code looks different enough that I am not sure this
>> would work with the current version of _toVHDL (there is no explicit
>> "signal", it uses _driven() and converts the value to an int rather
>> than calling str() on it).
>
> I am not sure what the comment line is but I do not believe it is
> correct (at least not for VHDL).  Someone would have to review the
> history to see

I just did. That code is there since the toVHDL module was introduced,
and it seems it was copied and pasted code from the toVerilog module
(which predates it), since that exact line of code is found on the
toVerilog module as well.

By the way, I also tried your proposed "hack" and it almost works. The
problem is that it just prints the initial value as is, wich means
that it initialized std_logic values to False, for example, rather
than to '0'.


>> That being said, I don't really know about Verilog, but default signal
>> values are part of the VHDL standard syntax. I don't understand why
>> would we not support it. IMHO it is _very_  surprising to have the
>> convertor ignore the init value that you explicitly set on the python
>> code, when the VHDL standard supports such a thing.
>
> Defaults are part of the Verilog standard as well.  For Verilog, at
> least a couple years ago, Altera Quartus synthesis did not support the
> syntax.  That is not the case any more.  And I doubt it was ever the
> case for VHDL.
>
>>
>> Do you know if there are any plants to add this to 0.8? Maybe Jan
>> could give his opinion on this?
>
> No, I am not aware of any explicit plans for init value in 0.8.

I see. Hopefully this can be added sooner rather than later :-)

Thanks,

Angel

Re: [myhdl-list] address decoder in myHDL

[Angel E. <ang...@gm...>]

On Mon, Dec 3, 2012 at 3:21 PM, Christopher Felton
<chr...@gm...> wrote:
> On 12/3/12 2:10 AM, Angel Ezquerra wrote:
>> You can use Python's three element comparison operator (e.g. x <= y
>> < z) on the synthesizable part. In particular you can turn
>>
>>      if addr >= laddr and addr < haddr:
>>          vsel = sel[ii]
>>
>> into:
>>
>>      if laddr <= addr < haddr:
>>          vsel = sel[ii]
>
> Chained comparisons are not supported by the converter.  Although this
> is nice for modeling and testing it cannot be used for conversion.
>
> Regards,
> Chris

You are right. I tested it and I thought it worked. However I just
tried it again and I got an error.

It is a pity, it would have been neat if it were supported.

Cheers,

Angel

Re: [myhdl-list] Signal initialization

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

On 12/3/12 3:56 AM, Martin Thompson wrote:
> Angel Ezquerra <ang...@gm...> writes:
>
>> I was thinking of the behavior of the code when some signals are still
>> not initialized (i.e. undefined). The "stdl" and "bool" functions on
>> the pck_myhdl helper file use comparions with 0 and '1'
>> (respectively), and I am unsure as to how those will behave when fed
>> and undefined value:
>>
>>      function stdl (arg: integer) return std_logic is
>>      begin
>>          if arg /= 0 then
>>              return '1';
>>          else
>>              return '0';
>>          end if;
>>      end function stdl;
>
> You can't feed that an uninitalised value - it takes an integer :)
>
>>
>>      function bool (arg: std_logic) return boolean is
>>      begin
>>          return arg = '1';
>>      end function bool;
>>
>
> That'll return false for everything other than a '1', so a 'U' (and
> 'X', and 'Z'...).  Also, 'H' will return false which may or may not be
> regarded as a bug?
>
>> In addition I wonder if this will not make VHDL simulations slower
>> unnecessarily? I don't know... it just feels a bit unnecessary.
>>
>
> I imagine this is a case of correctness-first, performance later (and
> only if a proven benefit can be demonstrated)

I would say, this is exactly the case.  Focus on correctness of the 
converted HDL and not the converted HDL simulation speed.

The design goal is that VHDL/Verilog (target HDLs) are intended to be an 
intermediate formats and mainly used by the tools.  Although you would 
need to verify the converted HDL has the same behavior as the MyHDL 
description it is common that the MyHDL simulation would run more often 
than the converted HDL simulation.

Regards,
Chris

Re: [myhdl-list] Handling combinational code

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

On 12/3/12 5:35 AM, Angel Ezquerra wrote:
> Hi,
>
> when writing VHDL code it is common to write combinational statements
> outside of processes. For example, I've got the following VHDL code
> that I wanted to rewrite using MyHDL:
>
>
<snip>
> The code in question is not very important. The important part is the last line:
>
>      output <= sync1 xor sync2;
>
> My question is, what is the most "idiomatic" way to handle this sort
> of statement in MyHDL? So far what I've done is creating an
> "always_proc" process called "combinational" in which I dump all
> statements that I would usually place outside all processes in the
> equivalent VHDL code. That is, in the example:
>
>      @always_comb
>      def combinational():
>          output.next = sync1 ^ sync2
>
> The MyHDL toVHDL converter seems to handle this fine and in fact it
> places these statements outside all processes as well.
>
> Is this the right/recommended way to handle this? The only drawback
> that I see is that it makes it harder to place these sort of
> statements close to the processes that are related to them, which may
> make the code a little harder to understand. I guess that I could
> solve that by creating multiple "combinational" always_proc
> generators, each located near the processes where the combinational
> inputs or outputs are used. Would that be a good solution?

Yes, that is the suggested method.  I create multiple always_comb I 
don't use one large one to capture all.

Regards,
Chris

Re: [myhdl-list] Signal initialization

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

<snip>
>>
>> Based on my recollection it has been agreed upon that using initialized
>> signals/variables in the converted HDL (both VHDL and Verilog) is
>> desired to avoid MyHDL simulation mismatch with the target HDL.  But in
>> some cases it was disabled because it was not supported by FPGA vendor
>> synthesis tools.  This was true with Verilog and Altera Quartus but my
>> guess is that the synthesis tools probably support the VHDL
>> initialization fine (have never ran into an issue).
>>
>> The initialization might have been disable because the converted Verilog
>> and VHDL would differ (a guess)?
>>
>> I quick test and the modified line 306 in _toVHDL.py in the latest
>> 0.8dev to:
>>
>>      print >> f, "signal %s: %s%s := %s;" % (s._name, p, r, str(s._val))
>
> I'll give this a try.
> Interestingly, the lines right above the one you modified are as follows:
>
>      # the following line implements initial value assignments
>      # print >> f, "%s %s%s = %s;" % (s._driven, r, s._name, int(s._val))
>
> They are commented, but they seem to be intended to do what we want
> although  the code looks different enough that I am not sure this
> would work with the current version of _toVHDL (there is no explicit
> "signal", it uses _driven() and converts the value to an int rather
> than calling str() on it).

I am not sure what the comment line is but I do not believe it is 
correct (at least not for VHDL).  Someone would have to review the 
history to see

>
> That being said, I don't really know about Verilog, but default signal
> values are part of the VHDL standard syntax. I don't understand why
> would we not support it. IMHO it is _very_  surprising to have the
> convertor ignore the init value that you explicitly set on the python
> code, when the VHDL standard supports such a thing.

Defaults are part of the Verilog standard as well.  For Verilog, at 
least a couple years ago, Altera Quartus synthesis did not support the 
syntax.  That is not the case any more.  And I doubt it was ever the 
case for VHDL.

>
> Do you know if there are any plants to add this to 0.8? Maybe Jan
> could give his opinion on this?
>

No, I am not aware of any explicit plans for init value in 0.8.


Regards,
Chris

Re: [myhdl-list] address decoder in myHDL

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

On 12/3/12 2:10 AM, Angel Ezquerra wrote:
> You can use Python's three element comparison operator (e.g. x <= y
> < z) on the synthesizable part. In particular you can turn
>
>      if addr >= laddr and addr < haddr:
>          vsel = sel[ii]
>
> into:
>
>      if laddr <= addr < haddr:
>          vsel = sel[ii]

Chained comparisons are not supported by the converter.  Although this 
is nice for modeling and testing it cannot be used for conversion.

Regards,
Chris

[myhdl-list] Handling combinational code

[Angel E. <ang...@gm...>]

Hi,

when writing VHDL code it is common to write combinational statements
outside of processes. For example, I've got the following VHDL code
that I wanted to rewrite using MyHDL:

~~~
----------------------------------------------------------------------------------
--
-- Module Name:    capture_synchronizer - Behavioral
-- Description:
--
-- Module that can be used to cross clock boundaries by detecting a
signal change
-- regardless of the input/output clock relationship.
--
-- This module follows the description on:
--
--     http://chipdesignmag.com/display.php?articleId=32&issueId=5
--
-- Figure 3.
--
-- [WARNING] This module introduces a 1 output cycle delay.
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.all;


entity capture_synchronizer is
    port (
        clk    : in  std_logic;
        rst    : in  std_logic;
        input  : in  std_logic;
        output : out std_logic
    );
end capture_synchronizer;

architecture Behavioral of capture_synchronizer is
    signal captured : std_logic := '0';
    signal demet    : std_logic := '0';
    signal sync1    : std_logic := '0';
    signal sync2    : std_logic := '0';
begin
    -- Capture any changes to the input signal
    -- This is done by implementing a process whose
    -- output toggles whenever the input signal changes,
    -- (which in turn is done by using the input signal)
    -- as a "clock"
    capturer : process(input, rst)
    begin
        if rst = '1' then
            captured <= '0';
        elsif rising_edge(input) then
            captured <= not captured;
        end if;
    end process;

    -- 1. Register the captured signal using the output clock
    -- we do so using a synchronizing double register
    -- 2. When the captured signal changes it means thatDetect changes
at the input by comparing the synchronized input
    -- with its previous value. When there is a change, activate the
    -- output for a single cycle
    demet_and_sync : process(clk, input)
    begin
        if rising_edge(clk) then
            -- Double register the "captured" signal to "demetastabilize" it
            demet <= captured;
            sync1 <= demet;
            -- Store the "demetastabilized" signal so that we can detect
            -- when it changes
            sync2 <= sync1;
            if rst = '1' then
                demet <= '0';
                sync1 <= '0';
                sync2 <= '0';
            end if;
        end if;
    end process;

    -- When the "demetastabilized" captured signal changes, toggle output
    output <= sync1 xor sync2;

end Behavioral;
~~~

The code in question is not very important. The important part is the last line:

    output <= sync1 xor sync2;

My question is, what is the most "idiomatic" way to handle this sort
of statement in MyHDL? So far what I've done is creating an
"always_proc" process called "combinational" in which I dump all
statements that I would usually place outside all processes in the
equivalent VHDL code. That is, in the example:

    @always_comb
    def combinational():
        output.next = sync1 ^ sync2

The MyHDL toVHDL converter seems to handle this fine and in fact it
places these statements outside all processes as well.

Is this the right/recommended way to handle this? The only drawback
that I see is that it makes it harder to place these sort of
statements close to the processes that are related to them, which may
make the code a little harder to understand. I guess that I could
solve that by creating multiple "combinational" always_proc
generators, each located near the processes where the combinational
inputs or outputs are used. Would that be a good solution?

Thanks,

Angel

Re: [myhdl-list] Signal initialization

[Martin T. <mar...@tr...>]

Angel Ezquerra <ang...@gm...> writes:

> I was thinking of the behavior of the code when some signals are still
> not initialized (i.e. undefined). The "stdl" and "bool" functions on
> the pck_myhdl helper file use comparions with 0 and '1'
> (respectively), and I am unsure as to how those will behave when fed
> and undefined value:
>
>     function stdl (arg: integer) return std_logic is
>     begin
>         if arg /= 0 then
>             return '1';
>         else
>             return '0';
>         end if;
>     end function stdl;

You can't feed that an uninitalised value - it takes an integer :)

>
>     function bool (arg: std_logic) return boolean is
>     begin
>         return arg = '1';
>     end function bool;
>

That'll return false for everything other than a '1', so a 'U' (and
'X', and 'Z'...).  Also, 'H' will return false which may or may not be
regarded as a bug?

> In addition I wonder if this will not make VHDL simulations slower
> unnecessarily? I don't know... it just feels a bit unnecessary.
>

I imagine this is a case of correctness-first, performance later (and
only if a proven benefit can be demonstrated)

Cheers,
Martin

-- 
mar...@tr... 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Re: [myhdl-list] Signal initialization

[Angel E. <ang...@gm...>]

On Sun, Dec 2, 2012 at 12:57 AM, Christopher Felton
<chr...@gm...> wrote:
> On 11/30/12 6:20 AM, Angel Ezquerra wrote:
>> Hi,
>>
>> I have a question that probably is quite basic, but I don't seem to
>> get it right and I have not found an answer on the documentation
>> (perhaps I missed it though).
>>
>> I am making a simple MyHDL module, and in it I define several
>> std_logic signals as follows:
>>
>>     captured, demet, sync1, sync2 = [Signal(bool(0)) for n in range(4)]
>>
>> I expected these to be converted into the following VHDL:
>>
>>      signal captured: std_logic := '0';
>>      signal demet: std_logic := '0';
>>      signal sync2: std_logic := '0';
>>      signal sync1: std_logic := '0';
>>
>> Instead I get:
>>
>>      signal demet: std_logic;
>>      signal sync2: std_logic;
>>      signal sync1: std_logic;
>>      signal captured: std_logic;
>
> Based on my recollection it has been agreed upon that using initialized
> signals/variables in the converted HDL (both VHDL and Verilog) is
> desired to avoid MyHDL simulation mismatch with the target HDL.  But in
> some cases it was disabled because it was not supported by FPGA vendor
> synthesis tools.  This was true with Verilog and Altera Quartus but my
> guess is that the synthesis tools probably support the VHDL
> initialization fine (have never ran into an issue).
>
> The initialization might have been disable because the converted Verilog
> and VHDL would differ (a guess)?
>
> I quick test and the modified line 306 in _toVHDL.py in the latest
> 0.8dev to:
>
>     print >> f, "signal %s: %s%s := %s;" % (s._name, p, r, str(s._val))

I'll give this a try.
Interestingly, the lines right above the one you modified are as follows:

    # the following line implements initial value assignments
    # print >> f, "%s %s%s = %s;" % (s._driven, r, s._name, int(s._val))

They are commented, but they seem to be intended to do what we want
although  the code looks different enough that I am not sure this
would work with the current version of _toVHDL (there is no explicit
"signal", it uses _driven() and converts the value to an int rather
than calling str() on it).

That being said, I don't really know about Verilog, but default signal
values are part of the VHDL standard syntax. I don't understand why
would we not support it. IMHO it is _very_  surprising to have the
convertor ignore the init value that you explicitly set on the python
code, when the VHDL standard supports such a thing.

Do you know if there are any plants to add this to 0.8? Maybe Jan
could give his opinion on this?

>>
>> Other than the order not being the same, which I guess is unavoidable,
>> the values are not being initialized to zero as I expected (which
>> causes my simulation to fail).
>
> Why does it cause your simulation to fail?

By "fail" I meant "it does not work as expected". If I compare the
(modelsim) simulation results of the generated VHDL code with and
without the default values the result is quite different. Without the
initialized values a lot of the signals have an undefined value at the
beginning, which causes my circuit to miss the first event on my test
bench.

This could be fixed by changing the reset code, but I do not want to
do that. The project I work on often relies on initial values to avoid
reset code which is sometimes expensive in terms of FPGA routing and
area. Our resets are often "light" in the sense that they just make
sure that the processing does not start until the reset is deasserted.
They are not meant to be able to reset the whole FPGA to its initial
state. It is "cheaper" for us to just reload the FPGA whenever we want
to do a real reset.

>> Additionally, I see in the converted code that the following code:
>>
>>      captured.next = not demet
>>
>> which uses the signals declared above is converted into:
>>
>>      captured <= stdl((not bool(demet)));
>>
>> rather than into:
>>
>>      captured <= not demet;
>>
>> The conversion from std_logic to bool and then back to std_logic is
>> unnecessary... I guess it probably does not matter except perhaps
>> during simulation before the reset, but maybe it can cause some
>> problems in simulation as well?
>
> I can't think of any simulation issues that may occur?  Simply cast
> std_logic to a bool perform the not on a bool then cast back to a std_logic?

I was thinking of the behavior of the code when some signals are still
not initialized (i.e. undefined). The "stdl" and "bool" functions on
the pck_myhdl helper file use comparions with 0 and '1'
(respectively), and I am unsure as to how those will behave when fed
and undefined value:

    function stdl (arg: integer) return std_logic is
    begin
        if arg /= 0 then
            return '1';
        else
            return '0';
        end if;
    end function stdl;

    function bool (arg: std_logic) return boolean is
    begin
        return arg = '1';
    end function bool;

In addition I wonder if this will not make VHDL simulations slower
unnecessarily? I don't know... it just feels a bit unnecessary.

Cheers (and thanks for your reply!)

Angel

Re: [myhdl-list] address decoder in myHDL

[Angel E. <ang...@gm...>]

On Sun, Dec 2, 2012 at 6:06 AM, Christopher Felton
<chr...@gm...> wrote:
> On 12/1/12 7:00 PM, Aaron Ferrucci wrote:
>> I'm trying to implement a  conceptually simple, but
>> Verilog/VHDL-unfriendly module in myHDL.  So far I've had success with
>> some simplified forms of the module, but not with the full-fledged spec.
>>
>> The module, an address decoder, takes as input an n-bit address input
>> signal and outputs an m-bit decoded value which can be considered as the
>> binary encoding of a selected slave, according to which of several
>> address ranges the address falls in.  If no address range matches, a
>> default value is output.  The set of decoded address ranges and their
>> output encodings are parameters of the generator.  Here's what one
>> generator instance could look like:
>>
>
> If I understood the requirements, this is the solution I came up with.
> Didn't have a lot of time this is a rough first pass.  I re-phrased the
> requirements at the beginning, I might be way off what you are trying to
> achieve.  The MyHDL works as expected but I didn't verify the converted
> HDL works as expected.
>
>
>     from myhdl import *
>     from random import randint
>     from pprint import pprint
>
>     # Create an m-bit address range based on an n-bit address.
>     # If there is no range match a default is output.  The
>     # address ranges are passed to the module.
>
>     def addr_range_decoder(addr, select,
>                            Ranges=[(),(),()],
>                            Default=0xFF):
>
>         assert len(Ranges) > 0
>         assert len(Ranges[0]) == 3
>
>         # Use the elaboration to put the Ranges into a usable form
>         Nranges = len(Ranges)
>         lr = tuple([ss[0] for ss in Ranges])  # low address
>         hr = tuple([ss[1] for ss in Ranges])  # high address
>         sel = tuple([ss[2] for ss in Ranges]) # select value for
>                                              # the address range
>         print(Nranges, len(lr), len(hr), len(sel))
>
>         @always_comb
>         def hdl_decoder():
>             vsel = Default
>             for ii in range(Nranges):
>                 laddr = lr[ii]
>                 haddr = hr[ii]
>                 if addr >= laddr and addr < haddr:
>                     vsel = sel[ii]
>             select.next = vsel
>
>         return hdl_decoder
>
>
>     def test():
>         NbitOpt = (8,16,20,24,32,36,48)
>         Nbit = NbitOpt[randint(0,len(NbitOpt)-1)]
>         Mbit = randint(2,8)
>         print("Nbit %d, Mbit %d" % (Nbit,Mbit))
>         d = (2**Nbit)/(2**Mbit)
>         Ranges = []
>         Laddr = {}
>         Nr = 2**Mbit
>         for ii in range(Nr-3):
>             la = ii*d
>             ha = (ii*d+d)-1
>             sv = ii
>             Ranges.append((la,ha,sv))
>             Laddr[la] = (la,ha,sv)
>         pprint(Ranges)
>
>         addr = Signal(intbv(0)[Nbit:])
>         select = Signal(intbv(0)[Mbit:])
>         tb_dut = addr_range_decoder(addr, select,
>                                     Ranges=Ranges,
>                                     Default=select.max-1)
>         TestAddrs = [randint(0,2**Nbit-1) for ii in range(32)]
>
>         @instance
>         def tb_stim():
>             for taddr in TestAddrs:
>                 addr.next = taddr
>                 yield delay(10)
>                 print(' addr %12X sel %X' % (addr, select))
>                 baddr = taddr - (taddr%d)
>                 if Laddr.has_key(baddr):
>                     tsel = Laddr[baddr][2]
>                 else:
>                     tsel = select.max-1
>                 assert tsel == select
>
>             raise StopSimulation
>
>         Simulation((tb_dut, tb_stim)).run()
>         toVerilog(addr_range_decoder, addr, select,
>                   Ranges=Ranges, Default=select.max-1)
>         toVHDL(addr_range_decoder, addr, select,
>                Ranges=Ranges, Default=select.max-1)
>
>
>     if __name__ == '__main__':
>         test()
>

Christopher,

this is a nice example, thanks!

I got a couple of comments, which are probably obvious to you but may
be interesting to others:

1. You can use Python's three element comparison operator (e.g. x <= y
< z) on the synthesizable part. In particular you can turn

    if addr >= laddr and addr < haddr:
        vsel = sel[ii]

into:

    if laddr <= addr < haddr:
        vsel = sel[ii]

which I think is a nice little way to show how you can leverage the
powerful Python syntax to simplify your code (compared to the
equivalent VHDL or Verilog).

2. In testing that #1 above works (which I was not sure to start with)
I had to resort to using the "random.seed" function to force your
randint() calls to give the same result on every execution. This is a
common and simple trick that perhaps others do not know?

BTW, I first called "seed(1)" and that threw an assert. I changed to
seed(2) and that worked fine. I did not dig deeper to check why the
random values generated with seed(1) cause the assert but it may be
worth checking.

Cheers,

Angel

Re: [myhdl-list] address decoder in myHDL

[Aaron F. <aar...@gm...>]

Thanks Christopher!  Your solution works just fine.  Now that I see how you
did it, it looks obvious :)

I tested the generated Verilog in Modelsim (6.6d) and ran it through
Quartus synthesis (11.1sp1), and everything looks ok.
-Aaron



On Sat, Dec 1, 2012 at 9:06 PM, Christopher Felton
<chr...@gm...>wrote:

> On 12/1/12 7:00 PM, Aaron Ferrucci wrote:
> > I'm trying to implement a  conceptually simple, but
> > Verilog/VHDL-unfriendly module in myHDL.  So far I've had success with
> > some simplified forms of the module, but not with the full-fledged spec.
> >
> > The module, an address decoder, takes as input an n-bit address input
> > signal and outputs an m-bit decoded value which can be considered as the
> > binary encoding of a selected slave, according to which of several
> > address ranges the address falls in.  If no address range matches, a
> > default value is output.  The set of decoded address ranges and their
> > output encodings are parameters of the generator.  Here's what one
> > generator instance could look like:
> >
>
> If I understood the requirements, this is the solution I came up with.
> Didn't have a lot of time this is a rough first pass.  I re-phrased the
> requirements at the beginning, I might be way off what you are trying to
> achieve.  The MyHDL works as expected but I didn't verify the converted
> HDL works as expected.
>
>
>     from myhdl import *
>     from random import randint
>     from pprint import pprint
>
>     # Create an m-bit address range based on an n-bit address.
>     # If there is no range match a default is output.  The
>     # address ranges are passed to the module.
>
>     def addr_range_decoder(addr, select,
>                            Ranges=[(),(),()],
>                            Default=0xFF):
>
>         assert len(Ranges) > 0
>         assert len(Ranges[0]) == 3
>
>         # Use the elaboration to put the Ranges into a usable form
>         Nranges = len(Ranges)
>         lr = tuple([ss[0] for ss in Ranges])  # low address
>         hr = tuple([ss[1] for ss in Ranges])  # high address
>         sel = tuple([ss[2] for ss in Ranges]) # select value for
>                                              # the address range
>         print(Nranges, len(lr), len(hr), len(sel))
>
>         @always_comb
>         def hdl_decoder():
>             vsel = Default
>             for ii in range(Nranges):
>                 laddr = lr[ii]
>                 haddr = hr[ii]
>                 if addr >= laddr and addr < haddr:
>                     vsel = sel[ii]
>             select.next = vsel
>
>         return hdl_decoder
>
>
>     def test():
>         NbitOpt = (8,16,20,24,32,36,48)
>         Nbit = NbitOpt[randint(0,len(NbitOpt)-1)]
>         Mbit = randint(2,8)
>         print("Nbit %d, Mbit %d" % (Nbit,Mbit))
>         d = (2**Nbit)/(2**Mbit)
>         Ranges = []
>         Laddr = {}
>         Nr = 2**Mbit
>         for ii in range(Nr-3):
>             la = ii*d
>             ha = (ii*d+d)-1
>             sv = ii
>             Ranges.append((la,ha,sv))
>             Laddr[la] = (la,ha,sv)
>         pprint(Ranges)
>
>         addr = Signal(intbv(0)[Nbit:])
>         select = Signal(intbv(0)[Mbit:])
>         tb_dut = addr_range_decoder(addr, select,
>                                     Ranges=Ranges,
>                                     Default=select.max-1)
>         TestAddrs = [randint(0,2**Nbit-1) for ii in range(32)]
>
>         @instance
>         def tb_stim():
>             for taddr in TestAddrs:
>                 addr.next = taddr
>                 yield delay(10)
>                 print(' addr %12X sel %X' % (addr, select))
>                 baddr = taddr - (taddr%d)
>                 if Laddr.has_key(baddr):
>                     tsel = Laddr[baddr][2]
>                 else:
>                     tsel = select.max-1
>                 assert tsel == select
>
>             raise StopSimulation
>
>         Simulation((tb_dut, tb_stim)).run()
>         toVerilog(addr_range_decoder, addr, select,
>                   Ranges=Ranges, Default=select.max-1)
>         toVHDL(addr_range_decoder, addr, select,
>                Ranges=Ranges, Default=select.max-1)
>
>
>     if __name__ == '__main__':
>         test()
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> DESIGN Expert tips on starting your parallel project right.
> http://goparallel.sourceforge.net/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] address decoder in myHDL

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

On 12/1/12 7:00 PM, Aaron Ferrucci wrote:
> I'm trying to implement a  conceptually simple, but
> Verilog/VHDL-unfriendly module in myHDL.  So far I've had success with
> some simplified forms of the module, but not with the full-fledged spec.
>
> The module, an address decoder, takes as input an n-bit address input
> signal and outputs an m-bit decoded value which can be considered as the
> binary encoding of a selected slave, according to which of several
> address ranges the address falls in.  If no address range matches, a
> default value is output.  The set of decoded address ranges and their
> output encodings are parameters of the generator.  Here's what one
> generator instance could look like:
>

If I understood the requirements, this is the solution I came up with. 
Didn't have a lot of time this is a rough first pass.  I re-phrased the 
requirements at the beginning, I might be way off what you are trying to 
achieve.  The MyHDL works as expected but I didn't verify the converted 
HDL works as expected.


    from myhdl import *
    from random import randint
    from pprint import pprint

    # Create an m-bit address range based on an n-bit address.
    # If there is no range match a default is output.  The
    # address ranges are passed to the module.

    def addr_range_decoder(addr, select,
                           Ranges=[(),(),()],
                           Default=0xFF):

        assert len(Ranges) > 0
        assert len(Ranges[0]) == 3

        # Use the elaboration to put the Ranges into a usable form
        Nranges = len(Ranges)
        lr = tuple([ss[0] for ss in Ranges])  # low address
        hr = tuple([ss[1] for ss in Ranges])  # high address
        sel = tuple([ss[2] for ss in Ranges]) # select value for
				             # the address range
        print(Nranges, len(lr), len(hr), len(sel))

        @always_comb
        def hdl_decoder():
            vsel = Default
            for ii in range(Nranges):
                laddr = lr[ii]
                haddr = hr[ii]
                if addr >= laddr and addr < haddr:
                    vsel = sel[ii]
            select.next = vsel

        return hdl_decoder


    def test():
        NbitOpt = (8,16,20,24,32,36,48)
        Nbit = NbitOpt[randint(0,len(NbitOpt)-1)]
        Mbit = randint(2,8)
        print("Nbit %d, Mbit %d" % (Nbit,Mbit))
        d = (2**Nbit)/(2**Mbit)
        Ranges = []
        Laddr = {}
        Nr = 2**Mbit
        for ii in range(Nr-3):
            la = ii*d
            ha = (ii*d+d)-1
            sv = ii
            Ranges.append((la,ha,sv))
            Laddr[la] = (la,ha,sv)
        pprint(Ranges)

        addr = Signal(intbv(0)[Nbit:])
        select = Signal(intbv(0)[Mbit:])
        tb_dut = addr_range_decoder(addr, select,
                                    Ranges=Ranges,
                                    Default=select.max-1)
        TestAddrs = [randint(0,2**Nbit-1) for ii in range(32)]

        @instance
        def tb_stim():
            for taddr in TestAddrs:
                addr.next = taddr
                yield delay(10)
                print(' addr %12X sel %X' % (addr, select))
                baddr = taddr - (taddr%d)
                if Laddr.has_key(baddr):
                    tsel = Laddr[baddr][2]
                else:
                    tsel = select.max-1
                assert tsel == select

            raise StopSimulation

        Simulation((tb_dut, tb_stim)).run()
        toVerilog(addr_range_decoder, addr, select,
                  Ranges=Ranges, Default=select.max-1)
        toVHDL(addr_range_decoder, addr, select,
               Ranges=Ranges, Default=select.max-1)


    if __name__ == '__main__':
        test()

[myhdl-list] address decoder in myHDL

[Aaron F. <aar...@gm...>]

I'm trying to implement a  conceptually simple, but Verilog/VHDL-unfriendly
module in myHDL.  So far I've had success with some simplified forms of the
module, but not with the full-fledged spec.

The module, an address decoder, takes as input an n-bit address input
signal and outputs an m-bit decoded value which can be considered as the
binary encoding of a selected slave, according to which of several address
ranges the address falls in.  If no address range matches, a default value
is output.  The set of decoded address ranges and their output encodings
are parameters of the generator.  Here's what one generator instance could
look like:

module decoder(input [7:0] addr, output [3:0] select);
  always @(addr) begin
    if (8'h0 <= addr && addr < 8'h10)
      select = 4'h0;
    else if (8'h20 < addr && addr < 8'h23)
      select = 4'h8;
    else if ...
      ... more ranges ...
    else
      select = 4'hF; // default value
  end
endmodule


Using myHDL, I have been able to create some simplified forms of the
decoder Here's one example:

module decoder0 (
    addr,
    select
);

input [7:0] addr;
output [3:0] select;
reg [3:0] select;

always @(addr) begin: DECODER0_ASSIGNMENTS
    if (((0 <= addr) && (addr < 16))) begin
        select = 1;
    end
    if (((32 <= addr) && (addr < 64))) begin
        select = 2;
    end
    else begin
        select = 3;
    end
end
endmodule

This is easy to implement in myHDL, but the number of decoded ranges is a
constant property. In other words, the myHDL python code closely matches
the generated Verilog's if/else if /else structure:
    @always_comb
    def assignments():
        if 0 <= addr and addr < 0x10:
            select.next = 1
        if 0x20 <= addr and addr < 0x40:
            select.next = 2
        else:
            select.next = 3



An alternate implementation generates this Verilog:
module decoder1 (
    addr,
    select
);

input [7:0] addr;
output [3:0] select;
reg [3:0] select;

always @(addr[9-1:6]) begin: DECODER1_ASSIGNMENTS
    case (addr[9-1:6])
        0: select = 3;
        1: select = 5;
        2: select = 7;
        3: select = 9;
        4: select = 10;
        5: select = 11;
        6: select = 14;
        default: select = 15;
    endcase
end
endmodule

The myHDL code which created this implementation allows a variable number
of decoded ranges, but each range must be the same size.  In Python I use
the range size and number of ranges to compute the slice indices of the
input address signal to shadow for the case select.

def decoder1(
    addr,
    select,
):

    # Continue to assume equal-span select ranges which span the entire
address space, but now compute the indices
    # of the shadow signal
    address_ranges = [(0, 0x40), (0x40, 0x80), (0x80, 0xC0), (0xC0, 0x100),
                      (0x100, 0x140), (0x140, 0x180), (0x180, 0x1C0),
(0x1C0, 0x200)],
    selects = tuple([3, 5, 7, 9, 10, 11, 14, 15]),
    span = address_ranges[0][1] - address_ranges[0][0]
    max_address = max(map(lambda span: span[1], address_ranges))
    msb = int(math.log(max_address, 2))
    lsb = int(math.log(span, 2))

    addr_bits = addr(msb, lsb)
    @always_comb
    def assignments():
        select.next = selects[addr_bits]
    return assignments

For this example, I let the ranges span the entire address space, but if I
wanted to decode certain "unallocated" regions to some default value, I
could do that easily.

I'd like to build a decoder with any number of ranges, whose size may not
all be the same.  I imagine that the generated HDL should look like an
if/else if/.../else structure with a variable number of "else ifs", but
there may be another form that I haven't thought of.  However, I haven't
been able to come up with a solution that combines myHDL's case statement
capability (variable number of cases) with range-detect expressions (as in
decoder0).

Does anyone have any hints?
thanks!
-Aaron

Re: [myhdl-list] Signal initialization

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

On 11/30/12 6:20 AM, Angel Ezquerra wrote:
> Hi,
>
> I have a question that probably is quite basic, but I don't seem to
> get it right and I have not found an answer on the documentation
> (perhaps I missed it though).
>
> I am making a simple MyHDL module, and in it I define several
> std_logic signals as follows:
>
>     captured, demet, sync1, sync2 = [Signal(bool(0)) for n in range(4)]
>
> I expected these to be converted into the following VHDL:
>
>      signal captured: std_logic := '0';
>      signal demet: std_logic := '0';
>      signal sync2: std_logic := '0';
>      signal sync1: std_logic := '0';
>
> Instead I get:
>
>      signal demet: std_logic;
>      signal sync2: std_logic;
>      signal sync1: std_logic;
>      signal captured: std_logic;

Based on my recollection it has been agreed upon that using initialized 
signals/variables in the converted HDL (both VHDL and Verilog) is 
desired to avoid MyHDL simulation mismatch with the target HDL.  But in 
some cases it was disabled because it was not supported by FPGA vendor 
synthesis tools.  This was true with Verilog and Altera Quartus but my 
guess is that the synthesis tools probably support the VHDL 
initialization fine (have never ran into an issue).

The initialization might have been disable because the converted Verilog 
and VHDL would differ (a guess)?

I quick test and the modified line 306 in _toVHDL.py in the latest 
0.8dev to:

    print >> f, "signal %s: %s%s := %s;" % (s._name, p, r, str(s._val))

This will add the initialization to the locally declared signals.  I 
didn't think about this much, just tried a hack.  Here is an example.

~~~ [MyHDL] ~~~
    from myhdl import *

    def goo(clock, reset, x, y, z, zz):
        b = Signal(intbv(5, min=-13, max=22))
        bb = Signal(intbv(5, min=z.min, max=z.max))
        @always_seq(clock.posedge, reset=reset)
        def hdl():
            z.next = (x - y) + b
            bb.next = z - (2*b)
            zz.next = z + bb
        return hdl

    clock = Signal(bool(0))
    reset = ResetSignal(bool(0), active=0, async=False)
    x,y,z = (Signal(intbv(3, min=-4, max=7)),
             Signal(intbv(0, min=-8, max=8)),
             Signal(intbv(-67, min=-80, max=80)))
    zz = Signal(intbv(-37, min=-80, max=80))
    toVHDL(goo, clock, reset, x, y, z, zz)

~~~ [VHDL] ~~~

    architecture MyHDL of goo is

    signal b: signed (5 downto 0);
    signal bb: signed (7 downto 0) := 5;

    begin

    b <= to_signed(5, 6);

    GOO_HDL: process (clock) is
    begin
        if rising_edge(clock) then
            if (reset = '0') then
                z <= 10111101;
                zz <= 11011011;
                bb <= 00000101;
            else
                z <= ((resize(x, 8) - y) + b);
                bb <= resize(z - (2 * b), 8);
                zz <= (z + bb);
            end if;
        end if;
    end process GOO_HDL;

    end architecture MyHDL;


>
> Other than the order not being the same, which I guess is unavoidable,
> the values are not being initialized to zero as I expected (which
> causes my simulation to fail).

Why does it cause your simulation to fail?

>
> Additionally, I see in the converted code that the following code:
>
>      captured.next = not demet
>
> which uses the signals declared above is converted into:
>
>      captured <= stdl((not bool(demet)));
>
> rather than into:
>
>      captured <= not demet;
>
> The conversion from std_logic to bool and then back to std_logic is
> unnecessary... I guess it probably does not matter except perhaps
> during simulation before the reset, but maybe it can cause some
> problems in simulation as well?

I can't think of any simulation issues that may occur?  Simply cast 
std_logic to a bool perform the not on a bool then cast back to a std_logic?

Regards,
Chris

[myhdl-list] Signal initialization

[Angel E. <ang...@gm...>]

Hi,

I have a question that probably is quite basic, but I don't seem to
get it right and I have not found an answer on the documentation
(perhaps I missed it though).

I am making a simple MyHDL module, and in it I define several
std_logic signals as follows:

   captured, demet, sync1, sync2 = [Signal(bool(0)) for n in range(4)]

I expected these to be converted into the following VHDL:

    signal captured: std_logic := '0';
    signal demet: std_logic := '0';
    signal sync2: std_logic := '0';
    signal sync1: std_logic := '0';

Instead I get:

    signal demet: std_logic;
    signal sync2: std_logic;
    signal sync1: std_logic;
    signal captured: std_logic;

Other than the order not being the same, which I guess is unavoidable,
the values are not being initialized to zero as I expected (which
causes my simulation to fail).

Additionally, I see in the converted code that the following code:

    captured.next = not demet

which uses the signals declared above is converted into:

    captured <= stdl((not bool(demet)));

rather than into:

    captured <= not demet;

The conversion from std_logic to bool and then back to std_logic is
unnecessary... I guess it probably does not matter except perhaps
during simulation before the reset, but maybe it can cause some
problems in simulation as well?

Thanks,

Angel

Re: [myhdl-list] Low resource FFT core in Myhdl, first python Modell

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

On 11/28/2012 1:40 PM, Norbo wrote:
>> I have not reviewed your version yet, thought this might be helpful
>> (compare/contrast).  Here is another basic FFT which uses the recursive
>> ability in MyHDL.
>>
>> http://www.myhdl.org/doku.php/users:cfelton:projects:recursivefft
>>
>> This version the required resources are similar to yours.  It has been
>> synthesize for an FPGA.
>>
>> Regards,
>> Chris
>
>
> Yeah, i looked at this implementation before i started. If i got it
> correctly the basic radix-N elements are described with the aim to
> calculate everything combinatorically. Where my aim is to use at least
> (N*log(N)) clock cycles. And have only one basic radix-2 element as a
> center element were everything gets clocked through. And the data gets
> read and written from and to a RAM.

Yes, my version is straight-forward and doesn't share resources or 
multiplex.  It is pipelined though it is not one large combnitorial 
computation.  But I see this page is incomplete, I don't have everything 
posted.

Regards,
Chris

Re: [myhdl-list] Low resource FFT core in Myhdl, first python Modell

[Norbo <Nor...@gm...>]

> I have not reviewed your version yet, thought this might be helpful
> (compare/contrast).  Here is another basic FFT which uses the recursive
> ability in MyHDL.
>
> http://www.myhdl.org/doku.php/users:cfelton:projects:recursivefft
>
> This version the required resources are similar to yours.  It has been
> synthesize for an FPGA.
>
> Regards,
> Chris


Yeah, i looked at this implementation before i started. If i got it  
correctly the basic radix-N elements are described with the aim to  
calculate everything combinatorically. Where my aim is to use at least  
(N*log(N)) clock cycles. And have only one basic radix-2 element as a  
center element were everything gets clocked through. And the data gets  
read and written from and to a RAM.


greetings
Norbo

Re: [myhdl-list] Low resource FFT core in Myhdl, first python Modell

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

On 11/26/2012 9:53 AM, Norbo wrote:
> The aim was to create a FFT core in Myhdl. The Number of FFT points should
> be adjustable with 2**x.
> The upper limit of x should be not limited by the algorithm but just by
> the memory needed.
> The following python script should be a good starting point. Note the code
> uses only
> multiplication, additions and the lookuptable (i am thinking about
> replacing the lookuptable by a recursive chebyshev cosinus generator so
> that the implementation itself can work quit inplace). It was written with
> the hardware implementation in mind, wherby the input Data can be supplied
> through a Embedded memory block. The memory bandwidth would then create
> the speedlimit. Since only one value would be read and written at a clock
> cycle.
> I am not sure if i will finish this. But every comment, critic,
> improvements are welcome.
>
> grettings
> Norbo
>

I have not reviewed your version yet, thought this might be helpful 
(compare/contrast).  Here is another basic FFT which uses the recursive 
ability in MyHDL.

http://www.myhdl.org/doku.php/users:cfelton:projects:recursivefft

This version the required resources are similar to yours.  It has been 
synthesize for an FPGA.

Regards,
Chris

[myhdl-list] Low resource FFT core in Myhdl, first python Modell

[Norbo <Nor...@gm...>]

The aim was to create a FFT core in Myhdl. The Number of FFT points should  
be adjustable with 2**x.
The upper limit of x should be not limited by the algorithm but just by  
the memory needed.
The following python script should be a good starting point. Note the code  
uses only
multiplication, additions and the lookuptable (i am thinking about  
replacing the lookuptable by a recursive chebyshev cosinus generator so  
that the implementation itself can work quit inplace). It was written with  
the hardware implementation in mind, wherby the input Data can be supplied  
through a Embedded memory block. The memory bandwidth would then create  
the speedlimit. Since only one value would be read and written at a clock  
cycle.
I am not sure if i will finish this. But every comment, critic,  
improvements are welcome.

grettings
Norbo


### Python FFT implementation (for a myhdl implementation reference) ####
Author: Norbert
Date:26.11.2012
#########################################################################

 from pylab import fft,log2,exp,pi,arange
xin=[-7,2,3,4,5,6,7,8,-7,2,7,4,5,2,-7,2]

FFTlength=len(xin)
log2_FFTlength=int(log2(FFTlength))

assert 2**log2_FFTlength==FFTlength

###data reordering ######
Orderlookup=[]
for i in range(FFTlength):
     sst=list(bin(i)[2:].zfill(log2_FFTlength))
     sst.reverse()
     val=int("".join(sst),2)
     Orderlookup.append(val)

FFTdata=[xin[i]  for i in Orderlookup]
######end data reordering ########

lookuptable=exp(-1j*2*pi*arange(0,FFTlength/2,1)/(FFTlength))
count=0
valx=2
sections=FFTlength    #2**(log2_FFTlength-1)
while valx<=FFTlength:
     sections=sections>>1  # FFTlength/valx

     for cur_sec in range(sections):
         for i in range(valx>>1):
             aww=FFTdata[i+valx*cur_sec]
             bww=FFTdata[i+(valx>>1)+valx*cur_sec]*lookuptable[i*sections]   
# exp(-1j*2*pi*i/valx)

             FFTdata[i+valx*cur_sec]=aww+bww
             FFTdata[i+(valx>>1)+valx*cur_sec]=aww-bww
             #count=count+1
     valx=valx<<1

################# check result ##################
fftxin_reference=fft(xin)
Error_allowed=0.0001
for ind,fftval in enumerate(FFTdata):
     print fftval,"=",fftxin_reference[ind]
     assert  
(abs(fftxin_reference[ind])*(1-Error_allowed))<abs(fftval)<(abs(fftxin_reference[ind])*(1+Error_allowed))
     print "-"*50

Re: [myhdl-list] Reference models

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

Yes

I know there were no implementations done yet.  However, I was thinking of what richard feynman had done one time when he created a supercomputer (Thinking Machines) by using cellular automata techniques !!!  I was wondering if the same can be done one again !!!  

David Blubaugh




--- On Mon, 11/19/12, Christopher Felton <chr...@gm...> wrote:

From: Christopher Felton <chr...@gm...>
Subject: Re: [myhdl-list] Reference models
To: myh...@li...
Date: Monday, November 19, 2012, 11:34 AM

On 11/15/2012 8:20 AM, David Blubaugh wrote:
> Jan,
> Wonderful article on cellular automata within MyHDL !!!
> I was wondering if it would be possible to create a supercomputer within an array of FPGAs by utilizing both MyHDL and CELLULAR AUTOMATA ???
> David Blubaugh
>
>
>

David,

If I read the post correctly, nothing has been implemented in MyHDL 
(yet).  Jan showed how Python can be used to create a reference model 
(a.k.a the golden model).  Hopefully, the take away is: the relative 
efficiency to create the reference model with Python and the *bonus* 
UI/visualization because batteries are included.

If you follow APP you will notice there are 3 version of the game of 
life (cellular automata) being implemented.  From what has been posted 
thus far, this is a noteworthy accomplishment by Jan.  Quantifiable 
progress towards an implementation.

In Jan's previous post he issued a similar challenge to create a 
reference for an arbitrary length gray code and he provided the Python 
example.  The challenge had mediocre responses, IIRC there was one VHDL 
submission and no Verilog submissions.

I have had limited participation because I am in the same boat as 
others, extremely busy!  The last 3-4 months I have had approaching zero 
time outside work and family.

The other GOL posts
GOL contender #1
http://www.programmableplanet.com/author.asp?section_id=2030&doc_id=247372

http://www.programmableplanet.com/author.asp?section_id=2030&doc_id=251373

http://www.programmableplanet.com/author.asp?section_id=2030&doc_id=253338

GOL contender #2
http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=252453

http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=252957


Jan's previous
http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=252295

A philosophical point.  There is a definite difference (regardless of 
language and technologies) that Jan's approach is top-down and 
verification driven.  From what has been posted thus far, the others are 
building up to the final system(?).

Regards,
Chris



------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list