myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] "Error in user defined VHDL code" should show line, and column for error, rather than "index"

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

Angel Ezquerra wrote:
> Hi,
> 
> I am trying to create a MyHDL wrapper for some of the most common xilinx FPGA
> constructs (such as PLLs and DSP48 blocks). In order to do so I'm following the
> example that can be found at:
> 
> http://www.myhdl.org/doc/0.6/manual/conversion_examples.html#conv-usage-custom
> 
> While doing so, I've found some problems. These are certainly in my own code.
> However I've noticed that the error message could be improved a bit. The current
> message is not very informative in the sense that it tells you that there is a
> problem at a certain "index". I assume that the index is an offset from the
> beginning of the __vhdl__ string that contains the user defined code.
> 
> Instead, it would be much better if it could tell you the line that contains the
> error and also the column offset in that line (if possible).
> 
> This would make it much easier to spot where the error is, specially when the
> __vhdl__ string is very long (as in this case).

Error messages are often a weak point, but I thought that in the particular
case of user-defined code, it was reasonable. I don't immediately understand
what you describe here, a small example welcome.

> Also (and I don't know if this may be possible at all), it would be nice if the
> error message told you the line in which the __vhdl__ string was declared.

Probably not trivial.

> On a related note, I get the following warning while trying to do the conversion
> of this user-defined block:
> 
> "c:\Python26\lib\site-packages\myhdl\conversion\_toVHDL.py:232: DeprecationWarnin
> g: functions overriding warnings.showwarning() must support the 'line' argument
>   category=ToVHDLWarning"
> 
> PErhaps this is a Python 2.6 vs 2.5 issue?

Probably.



-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] Adding library declarations to your VHDL code

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

I am trying to make a myhdl block that will let me introduced a Xilinx DSP48e 
block.

In order to use and simulate this block you must add the following 
library use
declaration before the declaration of the entity that will use 
the DSP48 block:

Library UNISIM;
use UNISIM.vcomponents.all;


Then you must 
declare an instance of the DSP48E block, linking its ports to the

corresponding signals:

-- BEGIN of DSP48E instantiation:

   -- DSP48E: DSP 
   Function Block
   --         Virtex-5
   -- Xilinx HDL Language Template, 
   version 11.2
   
   DSP48E_inst : DSP48E
   generic map (
      ACASCREG => 1
      ,       -- Number of pipeline registers between 
                           
                           -- A/ACIN input and ACOUT output, 0, 1, or 2
      ALUMODEREG => 1,     -- 
      Number of pipeline registers on ALUMODE input, 0 or 1
      AREG => 1
      ,           -- Number of pipeline registers on the A input, 0, 1 or 2
      
      AUTORESET_PATTERN_DETECT => FALSE, -- Auto-reset upon pattern detect, TRUE
or 
FALSE
      AUTORESET_PATTERN_DETECT_OPTINV => "MATCH", -- Reset if "MATCH" 
      or "NOMATCH" 
      A_INPUT => "DIRECT", -- Selects A input used, "DIRECT" (A 
      port) or
"CASCADE" (ACIN port)
      BCASCREG => 1,       -- Number of 
      pipeline registers between B/BCIN input
and BCOUT output, 0, 1, or 2
      
      BREG => 1,           -- Number of pipeline registers on the B input, 0, 1 or 2
      
      B_INPUT => "DIRECT", -- Selects B input used, "DIRECT" (B port) or
"
CASCADE" (BCIN port)
      CARRYINREG => 1,     -- Number of pipeline 
      registers for the CARRYIN
input, 0 or 1
      CARRYINSELREG => 1,  -- Number 
      of pipeline registers for the CARRYINSEL
input, 0 or 1
      CREG => 1
      ,           -- Number of pipeline registers on the C input, 0 or 1
      MASK 
      => X"3FFFFFFFFFFF", -- 48-bit Mask value for pattern detect
      MREG => 1
      ,           -- Number of multiplier pipeline registers, 0 or 1
      
      MULTCARRYINREG => 1, -- Number of pipeline registers for multiplier carry
in 
bit, 0 or 1
      OPMODEREG => 1,      -- Number of pipeline registers on 
      OPMODE input, 0 or 1
      PATTERN => X"000000000000", -- 48-bit Pattern 
      match for pattern detect
      PREG => 1,           -- Number of pipeline 
      registers on the P output, 0 or 1
      SIM_MODE => "SAFE", -- Simulation: "
      SAFE" vs "FAST", see "Synthesis and
Simulation
                          -- 
                          Design Guide" for details
      SEL_MASK => "MASK",  -- Select mask value 
      between the "MASK" value or the
value on the "C" port
      SEL_PATTERN => "
      PATTERN", -- Select pattern value between the "PATTERN"
value or the value on 
the "C" port
      SEL_ROUNDING_MASK => "SEL_MASK", -- "SEL_MASK", "MODE1", "
      MODE2" 
      USE_MULT => "MULT_S", -- Select multiplier usage, "MULT" (MREG 
      => 0), 
                            -- "MULT_S" (MREG => 1), "NONE" (not 
                            using multiplier)
      USE_PATTERN_DETECT => "NO_PATDET", -- Enable pattern 
      detect, "PATDET",
"NO_PATDET" 
      USE_SIMD => "ONE48") -- SIMD selection, "
      ONE48", "TWO24", "FOUR12" 
   port map (
      ACOUT => ACOUT,  -- 30-bit A 
      port cascade output 
      BCOUT => BCOUT,  -- 18-bit B port cascade output
      
      CARRYCASCOUT => CARRYCASCOUT, -- 1-bit cascade carry output
      
      CARRYOUT => CARRYOUT, -- 4-bit carry output
      MULTSIGNOUT => MULTSIGNOUT, 
      -- 1-bit multiplier sign cascade output
      OVERFLOW => OVERFLOW, -- 1-bit 
      overflow in add/acc output
      P => P,          -- 48-bit output
      
      PATTERNBDETECT => PATTERNBDETECT, -- 1-bit active high pattern bar detect

      output
      PATTERNDETECT => PATTERNDETECT, --  1-bit active high pattern 
      detect output
      PCOUT => PCOUT,  -- 48-bit cascade output
      UNDERFLOW 
      => UNDERFLOW, -- 1-bit active high underflow in add/acc output
      A => A
      ,          -- 30-bit A data input
      ACIN => ACIN,    -- 30-bit A cascade 
      data input
      ALUMODE => ALUMODE, -- 4-bit ALU control input
      B => B
      ,          -- 18-bit B data input
      BCIN => BCIN,    -- 18-bit B cascade 
      input
      C => C,          -- 48-bit C data input
      CARRYCASCIN => 
      CARRYCASCIN, -- 1-bit cascade carry input
      CARRYIN => CARRYIN, -- 1-bit 
      carry input signal
      CARRYINSEL => CARRYINSEL, -- 3-bit carry select input
      
      CEA1 => CEA1,      -- 1-bit active high clock enable input for 1st 
      stage A
registers
      CEA2 => CEA2,      -- 1-bit active high clock enable 
      input for 2nd stage A
registers
      CEALUMODE => CEALUMODE, -- 1-bit active 
      high clock enable input for
ALUMODE registers
      CEB1 => CEB1,      -- 1-
      bit active high clock enable input for 1st stage B
registers
      CEB2 => 
      CEB2,      -- 1-bit active high clock enable input for 2nd stage B
registers

      CEC => CEC,      -- 1-bit active high clock enable input for C 
      registers
      CECARRYIN => CECARRYIN, -- 1-bit active high clock enable 
      input for
CARRYIN register
      CECTRL => CECTRL, -- 1-bit active high clock 
      enable input for OPMODE and
carry registers
      CEM => CEM,       -- 1-bit 
      active high clock enable input for multiplier
registers
      CEMULTCARRYIN 
      => CEMULTCARRYIN,       -- 1-bit active high clock enable
for multiplier 
carry in register
      CEP => CEP,       -- 1-bit active high clock enable 
      input for P registers
      CLK => CLK,       -- Clock input
      MULTSIGNIN 
      => MULTSIGNIN, -- 1-bit multiplier sign input
      OPMODE => OPMODE, -- 7-
      bit operation mode input
      PCIN => PCIN,     -- 48-bit P cascade input 
      
      RSTA => RSTA,     -- 1-bit reset input for A pipeline registers
      
      RSTALLCARRYIN => RSTALLCARRYIN, -- 1-bit reset input for carry pipeline

      registers
      RSTALUMODE => RSTALUMODE, -- 1-bit reset input for ALUMODE 
      pipeline registers
      RSTB => RSTB,     -- 1-bit reset input for B 
      pipeline registers
      RSTC => RSTC,     -- 1-bit reset input for C 
      pipeline registers
      RSTCTRL => RSTCTRL, -- 1-bit reset input for OPMODE 
      pipeline registers
      RSTM => RSTM, -- 1-bit reset input for multiplier 
      registers
      RSTP => RSTP  -- 1-bit reset input for P pipeline registers
);


-- END of DSP48E_inst instantiation


I have the following questions:
- Is 
there a way to tell myhdl that a certain entity requires a certain set of

libraries?
- I created a "dummy" entity that simply contains the DPS48E 
instance
declaration and maps the input ports to the DSP48E instance ports:

   - Is that the right approach?
   - Is it possible to force the port types
   ? MyHDL seems to be creating them as
"inout"
   - Can I make some ports 
   optional (and give them default values?
   - Should I declare the generics (i.
   e. the "generic map" part as regular
python function arguments?

Sorry if 
these questions are very basic. I did not find (or perhaps understand)
the 
corresponding information on the User-Defined code part of the MyHDL

documentation.

Thanks,

Angel

P.S.- My idea is to create a "xilinx" package 
for MyHDL, which would let you
fully exploit the devices on the xilinx FPGAs 
from MyHDL. I don't know how far
I'll get but this is my first step in that 
direction :-)

Cheers,

Angel

[myhdl-list] "Error in user defined VHDL code" should show line, and column for error, rather than "index"

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

Hi,

I am trying to create a MyHDL wrapper for some of the most common xilinx FPGA
constructs (such as PLLs and DSP48 blocks). In order to do so I'm following the
example that can be found at:

http://www.myhdl.org/doc/0.6/manual/conversion_examples.html#conv-usage-custom

While doing so, I've found some problems. These are certainly in my own code.
However I've noticed that the error message could be improved a bit. The current
message is not very informative in the sense that it tells you that there is a
problem at a certain "index". I assume that the index is an offset from the
beginning of the __vhdl__ string that contains the user defined code.

Instead, it would be much better if it could tell you the line that contains the
error and also the column offset in that line (if possible).

This would make it much easier to spot where the error is, specially when the
__vhdl__ string is very long (as in this case).

Also (and I don't know if this may be possible at all), it would be nice if the
error message told you the line in which the __vhdl__ string was declared.

On a related note, I get the following warning while trying to do the conversion
of this user-defined block:

"c:\Python26\lib\site-packages\myhdl\conversion\_toVHDL.py:232: DeprecationWarnin
g: functions overriding warnings.showwarning() must support the 'line' argument
  category=ToVHDLWarning"

PErhaps this is a Python 2.6 vs 2.5 issue?

Cheers,

Angel

Re: [myhdl-list] docstrings forwarded to converted output

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> 
> Angel Ezquerra wrote:
> 
> > One slightly weird thing that I have noticed is that while most 
> > docstrings are
> > converted into comments which are put before the corresonding line in the
> > generated code, entity docstrings seem to be placed after the entity
> > declaration. Is that on intentional?
> 
> "Official" docstrings (on the first line in a function) are extracted
> separately, and I can put them where is most appropriate.
> 
> In Python, the docstring comes after the interface definition. That's what
> I do for entities. However, for always blocks that looked a little
> strange as they don't really have a functional interface, so I put
> it before the always block for now. But this can be changed, cast your 
> votes.

Personally I would like to always have the comments _before_ the 
corresponding code, including for the "official" docstrings. That 
is, I would like to be able to define the entity interface and have 
it before the actual entity declaration in the generated VHDL or 
verilog code. Currently it is put after the entity declaration, 
isn't it?


> > Also, is there a way to add comments for ports using this method?
> 
> Not directly with the ports. Ports are inferred and handled separately
> by the convertor.
> 
> I would use the Python convention: use the docstring to document the
> complete functional interface, that is, the ports in our case.

OK, that is a good idea, which increases even further my preference 
for having the comments before the entity declaration.

Cheers,

Angel

Re: [myhdl-list] docstrings forwarded to converted output

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

Angel Ezquerra wrote:

> One slightly weird thing that I have noticed is that while most docstrings are
> converted into comments which are put before the corresonding line in the
> generated code, entity docstrings seem to be placed after the entity
> declaration. Is that on intentional?

"Official" docstrings (on the first line in a function) are extracted
separately, and I can put them where is most appropriate.

In Python, the docstring comes after the interface definition. That's what
I do for entities. However, for always blocks that looked a little
strange as they don't really have a functional interface, so I put
it before the always block for now. But this can be changed, cast your votes.

> 
> 
> Also, is there a way to add comments for ports using this method?

Not directly with the ports. Ports are inferred and handled separately
by the convertor.

I would use the Python convention: use the docstring to document the
complete functional interface, that is, the ports in our case.

Jan


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] docstrings forwarded to converted output

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

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> 
> Angel Ezquerra wrote:
> >> On Tue, Jun 29, 2010 at 4:47 PM, Jan Decaluwe <jan <at> jandecaluwe.com>
> > wrote:I just pushed a changeset which is supposed to add support
> >> for forwarding docstrings to converted output.
> >> This provides a way to document the converted output.
> >> Ordinary Python comments are ignored, because they are
> >> not kept in the ast tree generated by the ast module.
> >> But any docstring is forwarded. Those on "official places"
> >> are put on a hopefully logical position, but "unofficial"
> >> ones are forwarded also, right on the line where they
> >> occur. By using a docstring instead of an ordinary comment,
> >> you can control which comments should be kept by the
> >> conversion, and which not.
> >> This is an experimental feature, not extensively tested.
> >> Let us know what you find.
> >> Jan
> > 
> > 
> > Jan,
> > 
> > I just gave this a try but it does not work for me. I download the latest
> > version from the mercurial repository and then I ran the rom.py example. This
> > example has some docstrings and also calls toVHDL, so I figured that it would
> > generate a rom.vhd file which should have the docstring (as a comment?).
> 
> Correct.
> 
> > However there is no trace of the docstring on the vhdl output.
> > 
> > Is there something that I should do to enable this feature? Or am I doing
> > something wrong?
> 
> Below you see what I get - the docstring as a VHDL comment as
> expected. Are you sure you are seeing the latest version
> (either after a fresh install, or by making sure that your
> PYTHONPATH sees your local repository first)?
> 

Thank you Jan. It turns out that it was an installation problem on my end. I had
updated my local mercurial repository, but I had forgotten to run "python
setup.py install"! Sorry about that!

Now it works fine. This feature is _very_ cool! :-D

One slightly weird thing that I have noticed is that while most docstrings are
converted into comments which are put before the corresonding line in the
generated code, entity docstrings seem to be placed after the entity
declaration. Is that on intentional?


Also, is there a way to add comments for ports using this method?

Re: [myhdl-list] docstrings forwarded to converted output

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

Angel Ezquerra wrote:
>> On Tue, Jun 29, 2010 at 4:47 PM, Jan Decaluwe <jan <at> jandecaluwe.com>
> wrote:I just pushed a changeset which is supposed to add support
>> for forwarding docstrings to converted output.
>> This provides a way to document the converted output.
>> Ordinary Python comments are ignored, because they are
>> not kept in the ast tree generated by the ast module.
>> But any docstring is forwarded. Those on "official places"
>> are put on a hopefully logical position, but "unofficial"
>> ones are forwarded also, right on the line where they
>> occur. By using a docstring instead of an ordinary comment,
>> you can control which comments should be kept by the
>> conversion, and which not.
>> This is an experimental feature, not extensively tested.
>> Let us know what you find.
>> Jan
> 
> 
> Jan,
> 
> I just gave this a try but it does not work for me. I download the latest
> version from the mercurial repository and then I ran the rom.py example. This
> example has some docstrings and also calls toVHDL, so I figured that it would
> generate a rom.vhd file which should have the docstring (as a comment?).

Correct.


> However there is no trace of the docstring on the vhdl output.
> 
> Is there something that I should do to enable this feature? Or am I doing
> something wrong?

Below you see what I get - the docstring as a VHDL comment as
expected. Are you sure you are seeing the latest version
(either after a fresh install, or by making sure that your
PYTHONPATH sees your local repository first)?


-- File: rom.vhd
-- Generated by MyHDL 0.7dev
-- Date: Fri Jul  2 00:25:43 2010

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use std.textio.all;

use work.pck_myhdl_07dev.all;

entity rom is
    port (
        dout: out unsigned(7 downto 0);
        addr: in unsigned(3 downto 0)
    );
end entity rom;
-- ROM model 

architecture MyHDL of rom is


begin




ROM_READ: process (addr) is
begin
    case to_integer(addr) is
        when 0 => dout <= "00010001";
        when 1 => dout <= "10000110";
        when 2 => dout <= "00110100";
        when others => dout <= "00001001";
    end case;
end process ROM_READ;

end architecture MyHDL;


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] docstrings forwarded to converted output

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

> On Tue, Jun 29, 2010 at 4:47 PM, Jan Decaluwe <jan <at> jandecaluwe.com>
wrote:I just pushed a changeset which is supposed to add support
> for forwarding docstrings to converted output.
> This provides a way to document the converted output.
> Ordinary Python comments are ignored, because they are
> not kept in the ast tree generated by the ast module.
> But any docstring is forwarded. Those on "official places"
> are put on a hopefully logical position, but "unofficial"
> ones are forwarded also, right on the line where they
> occur. By using a docstring instead of an ordinary comment,
> you can control which comments should be kept by the
> conversion, and which not.
> This is an experimental feature, not extensively tested.
> Let us know what you find.
> Jan


Jan,

I just gave this a try but it does not work for me. I download the latest
version from the mercurial repository and then I ran the rom.py example. This
example has some docstrings and also calls toVHDL, so I figured that it would
generate a rom.vhd file which should have the docstring (as a comment?). However
there is no trace of the docstring on the vhdl output.

Is there something that I should do to enable this feature? Or am I doing
something wrong?

Cheers,

Angel

P.S.- Jan, I'm the same Angel you've been exchanging emails these past few days.
This is my "public" email address.

Re: [myhdl-list] docstrings forwarded to converted output

[Jian L. <jia...@go...>]

Nice! This feature actually makes it easier to sell MyHDL to some old-school
guys.

On Tue, Jun 29, 2010 at 4:47 PM, Jan Decaluwe <ja...@ja...> wrote:

> I just pushed a changeset which is supposed to add support
> for forwarding docstrings to converted output.
> This provides a way to document the converted output.
>
> Ordinary Python comments are ignored, because they are
> not kept in the ast tree generated by the ast module.
> But any docstring is forwarded. Those on "official places"
> are put on a hopefully logical position, but "unofficial"
> ones are forwarded also, right on the line where they
> occur. By using a docstring instead of an ordinary comment,
> you can control which comments should be kept by the
> conversion, and which not.
>
> This is an experimental feature, not extensively tested.
> Let us know what you find.
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>    Python as a HDL: http://www.myhdl.org
>    VHDL development, the modern way: http://www.sigasi.com
>    Analog design automation: http://www.mephisto-da.com
>    World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] docstrings forwarded to converted output

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

I just pushed a changeset which is supposed to add support
for forwarding docstrings to converted output.
This provides a way to document the converted output.

Ordinary Python comments are ignored, because they are
not kept in the ast tree generated by the ast module.
But any docstring is forwarded. Those on "official places"
are put on a hopefully logical position, but "unofficial"
ones are forwarded also, right on the line where they
occur. By using a docstring instead of an ordinary comment,
you can control which comments should be kept by the
conversion, and which not.

This is an experimental feature, not extensively tested.
Let us know what you find.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] full case / parallel case

[Tom D. <TD...@Di...>]

On Tue, 2010-06-22 at 02:06 +0200, Jan Decaluwe wrote:
> Currently the Verilog convertor outputs
> the synthesis directives full case / parallel case.
> It's an old thing, originally intended to make designs
> with case statements more optimal.
> 
> I have read a paper that advocates against this,
> and I agree. A good synthesis tool should be able
> to infer these semantics from the code itself.
> If that's not possible, it means that there is a risk
> for simulation/synthesis mismatch.
> 
> So I propose to remove these directives.
> Any objections?

In general I would allow synthesis to do as much of the work as possible
and rely users having decent synthesis tools. Even XST is good enough
these days to handle of this kind of stuff.

Re: [myhdl-list] full case / parallel case

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

On Mon, Jun 21, 2010 at 7:06 PM, Jan Decaluwe <ja...@ja...> wrote:

> Currently the Verilog convertor outputs
> the synthesis directives full case / parallel case.
> It's an old thing, originally intended to make designs
> with case statements more optimal.
>
> I have read a paper that advocates against this,
> and I agree. A good synthesis tool should be able
> to infer these semantics from the code itself.
> If that's not possible, it means that there is a risk
> for simulation/synthesis mismatch.
>
> So I propose to remove these directives.
> Any objections?
>
>
>
No objection here, feel free to remove.

.chris

[myhdl-list] full case / parallel case

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

Currently the Verilog convertor outputs
the synthesis directives full case / parallel case.
It's an old thing, originally intended to make designs
with case statements more optimal.

I have read a paper that advocates against this,
and I agree. A good synthesis tool should be able
to infer these semantics from the code itself.
If that's not possible, it means that there is a risk
for simulation/synthesis mismatch.

So I propose to remove these directives.
Any objections?


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] if-elif to case conversion

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

Jian LUO wrote:
> Hi Jan,
> 
> I found the conversion from if-elif-else to case doesn't work in 0.7dev 
> anymore,
> and tried to fix it.
> So far I got Verilog version work, but toVHDL still fails. 
> Maybe you can find a clue, why it doesn't work.

Thanks for debugging.

As it turns out, the whole if-elif thing was still completely
broken in development. 

The problem is that the old compiler package had a flat
representation of an if-elif tree, while the new ast package
represents it as a tree. For things like template transformation
(VHDL) and if-to-case mapping, the flat representation is
much easier. Therfore, my idea was to convert the tree
into the old representation and keep the old code. But
the flattening code was broken.

I have started by applying your patch, and then continued
to fix the problem. The flattening has been rewritten
completely.

One problem is that ast doesn't make a difference between:

   if rst == 0:
       q.next = 0
   else
      if en:
          q.next = 0

and:

   if rst == 0:
       q.next = 0
   elif en:
       q.next = 0

while the compiler package did.

I use the separate else clause to indicate the "clocked"
part for VHDL template transformation. To make the difference,
I had to introduce a very ugly hack: I detect the column offset
of the test body. If someone has a better idea, let me know,
but I really have to move on for now!

I have pushed all patches to the development branch.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] if-elif to case conversion

[Jian L. <jia...@go...>]

Hi Jan,

I found the conversion from if-elif-else to case doesn't work in 0.7dev
anymore,
and tried to fix it.
So far I got Verilog version work, but toVHDL still fails.
Maybe you can find a clue, why it doesn't work.
Attached is the changeset patch.

My model looks like this:

from myhdl import *

bitwise_op = enum('BW_AND', 'BW_ANDN', 'BW_OR', 'BW_XOR')

def TestUnit(o, a, b, op):
    @always_comb
    def bitwise():
        r = intbv(0)[8:]
        if op == bitwise_op.BW_AND:
            r[:] = a & b
        elif op == bitwise_op.BW_ANDN:
            r[:] = (~a) & b
        elif op == bitwise_op.BW_OR:
            r[:] = a | b
        elif op == bitwise_op.BW_XOR:
            r[:] = a ^ b
        o.next = r
    return instances()

if __name__ == '__main__':
    a, b, c = [Signal(intbv(0)[8:]) for i in range(3)]
    op = Signal(bitwise_op.BW_AND)
    toVHDL(TestUnit, c, a, b, op)

and the error message:

Traceback (most recent call last):
  File "test_enum.py", line 23, in <module>
    toVHDL(TestUnit, c, a, b, op)
  File "/home/daniel/Sources/myhdl/myhdl/conversion/_toVHDL.py", line 148,
in __call__
    _convertGens(genlist, siglist, vfile)
  File "/home/daniel/Sources/myhdl/myhdl/conversion/_toVHDL.py", line 334,
in _convertGens
    v.visit(tree)
  File "/usr/lib64/python2.6/ast.py", line 231, in visit
    return visitor(node)
  File "/home/daniel/Sources/myhdl/myhdl/conversion/_toVHDL.py", line 1672,
in visit_Module
    self.visit(stmt)
  File "/usr/lib64/python2.6/ast.py", line 231, in visit
    return visitor(node)
  File "/home/daniel/Sources/myhdl/myhdl/conversion/_toVHDL.py", line 2375,
in visit_FunctionDef
    self.visit_stmt(node.body)
  File "/home/daniel/Sources/myhdl/myhdl/conversion/_toVHDL.py", line 2069,
in visit_stmt
    self.visit(stmt)
  File "/usr/lib64/python2.6/ast.py", line 231, in visit
    return visitor(node)
  File "/home/daniel/Sources/myhdl/myhdl/conversion/_toVHDL.py", line 1540,
in visit_If
    self.mapToCase(node)
  File "/home/daniel/Sources/myhdl/myhdl/conversion/_toVHDL.py", line 1584,
in mapToCase
    self.visit_stmt(suite)
  File "/home/daniel/Sources/myhdl/myhdl/conversion/_toVHDL.py", line 2069,
in visit_stmt
    self.visit(stmt)
  File "/usr/lib64/python2.6/ast.py", line 231, in visit
    return visitor(node)
  File "/home/daniel/Sources/myhdl/myhdl/conversion/_toVHDL.py", line 993,
in visit_Assign
    if isinstance(lhs.vhd, vhd_type):
AttributeError: 'Subscript' object has no attribute 'vhd'

Cheers,

Jian

Re: [myhdl-list] Records in VHDL and MyHDL

[Jian L. <jia...@go...>]

On Sat, Jun 19, 2010 at 9:47 AM, Jan Decaluwe <ja...@ja...> wrote:

> Sigve Tjora wrote:
> > Hi!
> >
> > I generate VHDL from MyHDL and when the design has some size, it becomes
> > tedious and error prone to connect all the signals. Is it possible to
> > generate VHDL that uses VHDL-records to group related signals together
> > in the port-list of the generated VHDL code?
>
> Conversion hasn't support for something like this at this moment.
>
> One problem is that I want a solution that works for both Verilog
> and VHDL, as I want to address the whole audience. Therefore,
> I am more thinking about something like interfaces, that then
> would "disappear" in the converted output.
>
> BTW, to avoid connection tediousness, I typically use another
> solution currently. I give ports and signals at the highest
> level of hierarchy unique names, and declare them in
> separate modules. I then import them in the namespace,
> and use a function that does name-based lookup to make
> the connections automatically, based on the interface
> of a module.
>
>
Why not let conversion do the trick? How about a Interface class?
It's contents could be flattened with underscore and it's logic will be
translated
into verilog task or vhdl procedure?

Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>    Python as a HDL: http://www.myhdl.org
>    VHDL development, the modern way: http://www.sigasi.com
>    Analog design automation: http://www.mephisto-da.com
>    World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Records in VHDL and MyHDL

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

Jian LUO wrote:
> seconded, vhdl record or systemverilog interface kinda thing would be nice.

I agree, but the issue is that I need a solution that works for
both Verilog and VHDL and doesn't rely on SystemVerilog
features (more and more I think that SystemVerilog is
a disaster for the unhappy few :-)).

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Records in VHDL and MyHDL

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

Sigve Tjora wrote:
> Hi!
> 
> I generate VHDL from MyHDL and when the design has some size, it becomes 
> tedious and error prone to connect all the signals. Is it possible to 
> generate VHDL that uses VHDL-records to group related signals together 
> in the port-list of the generated VHDL code?

Conversion hasn't support for something like this at this moment.

One problem is that I want a solution that works for both Verilog
and VHDL, as I want to address the whole audience. Therefore,
I am more thinking about something like interfaces, that then
would "disappear" in the converted output.

BTW, to avoid connection tediousness, I typically use another
solution currently. I give ports and signals at the highest
level of hierarchy unique names, and declare them in
separate modules. I then import them in the namespace,
and use a function that does name-based lookup to make
the connections automatically, based on the interface
of a module.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Records in VHDL and MyHDL

[Jian L. <jia...@go...>]

seconded, vhdl record or systemverilog interface kinda thing would be nice.

On Fri, Jun 18, 2010 at 9:38 AM, Sigve Tjora <si...@tj...> wrote:

> Hi!
>
> I generate VHDL from MyHDL and when the design has some size, it becomes
> tedious and error prone to connect all the signals. Is it possible to
> generate VHDL that uses VHDL-records to group related signals together in
> the port-list of the generated VHDL code?
>
> Sigve
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

[myhdl-list] Records in VHDL and MyHDL

[Sigve T. <si...@tj...>]

Hi!

I generate VHDL from MyHDL and when the design has some size, it becomes
tedious and error prone to connect all the signals. Is it possible to
generate VHDL that uses VHDL-records to group related signals together in
the port-list of the generated VHDL code?

Sigve

Re: [myhdl-list] Proposal: SignalType symbol

[Kevin S. <sta...@gm...>]

Jan,

The factory function concept sounds nice and clean to me.

Kevin

On Sat, Jun 12, 2010 at 2:48 AM, Jan Decaluwe <ja...@ja...> wrote:

> Christopher L. Felton wrote:
> > On 6/11/2010 4:19 AM, Jan Decaluwe wrote:
>
>
> >> Correct. In effect, we decouple the interface to create Signal objects
> >> from their base class SignalType. Everywhere where you tested where
> >> an instance is a Signal, it should merely be a matter of using
> SignalType
> >> instead.
> >>
> >> Should I already push this change to the public repo's for
> experimenting?
> >>
> >>
> >>
> > Yes, sounds good to me
>
> Done
>
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>    Python as a HDL: http://www.myhdl.org
>    VHDL development, the modern way: http://www.sigasi.com
>    Analog design automation: http://www.mephisto-da.com
>    World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Kevin R. Stanton
c | 734•846•3915
e | sta...@gm...

Re: [myhdl-list] VHDL conversion fails when function has a argument of type 'enum'

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

Thanks for debugging and for using mercurial. I have applied your patch.

Jan

Jian LUO wrote:
> Hi list,
> 
> I found a bug in vhdl conversion. 
> A patch and a testcase are attached in the end of this mail.
> Don't know if I did it right.



-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Proposal: SignalType symbol

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

Christopher L. Felton wrote:
> On 6/11/2010 4:19 AM, Jan Decaluwe wrote:

   
>> Correct. In effect, we decouple the interface to create Signal objects
>> from their base class SignalType. Everywhere where you tested where
>> an instance is a Signal, it should merely be a matter of using SignalType
>> instead.
>>
>> Should I already push this change to the public repo's for experimenting?
>>
>>
>>    
> Yes, sounds good to me

Done


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] VHDL conversion fails when function has a argument of type 'enum'

[Jian L. <jia...@go...>]

Hi list,

I found a bug in vhdl conversion.
A patch and a testcase are attached in the end of this mail.
Don't know if I did it right.

MfG

Jian

Re: [myhdl-list] Proposal: SignalType symbol

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

On 6/11/2010 4:19 AM, Jan Decaluwe wrote:
> Christopher Felton wrote:
>    
>>       >  Your factory function Signal() must return the correct class object
>>       >  based upon the parameters passed to it.
>>       >
>>       >  So Signal is just a function now that returns a class object so
>>      there is
>>       >  no such thing as an instance of it.
>>
>>      Right. For completeness, there is still the guarantee that any returned
>>      object will be of type SignalType (so that the corresponding isinstance
>>      check will always be true), but the specific subtype depends on the
>>      parameters.
>>
>>
>> Ok, I am  going to back up and make sure I understand this.
>>
>> We have a base class, *Signal(...)* and derived classes DelayedSignal,
>> ShadowSignal, etc.  As you mentioned some earlier design decision guided
>> this path.  From a users point of view the desired effect is that they
>> only care about a *Signal* that may have some different attributes but
>> the user doesn't need to know that it is a different object (just
>> refreshing and sync'n out loud).
>>
>> Now we have a factory function (introduced with the ShadowSignal) and a
>> proposed SignalType.  The SignalType exposes the actual base class
>> *_Signal_* because we can't have an instance of the factory function
>> (well you can but that is not the use here).  So the SignalType property
>> exposes the base class so we identify variable's types.
>>      
> Correct. In effect, we decouple the interface to create Signal objects
> from their base class SignalType. Everywhere where you tested where
> an instance is a Signal, it should merely be a matter of using SignalType
> instead.
>
> Should I already push this change to the public repo's for experimenting?
>
>
>    
Yes, sounds good to me

>
>