myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] myhdl.org website migration

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

On 02/11/2014 12:37 PM, Jan Coombs wrote:
> On 10/02/14 20:12, Jan Decaluwe wrote:
>> For a long time and for various reasons, ...
> All excellent changes, thanks.   I'd not heard of 'markdown',

Really ?? It's used everywhere :-)

> this appeals to me as ideal, and would be my tool of preference for
> writing manuals.

For truee manuals, asciidoc or restructuredText is probably
better. I will keep the MyHDL manual in rst format. But for
websites, things have to be straightforward
and easy and I believe markdown is optimal.

> I would like to move about half of my tiny contribution into the
> new framework, and hope to have much more to post later this year.

Please send me a peronsal email with your bitbucket account.


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

Re: [myhdl-list] myhdl.org website migration

[Jan C. <jen...@mu...>]

On 10/02/14 20:12, Jan Decaluwe wrote:
> For a long time and for various reasons, ...
All excellent changes, thanks.   I'd not heard of 'markdown', but 
this appeals to me as ideal, and would be my tool of preference for 
writing manuals.

I would like to move about half of my tiny contribution into the 
new framework, and hope to have much more to post later this year.

Jan Coombs.

[myhdl-list] @always_comb - Conversion Error

[Carlos S. <car...@sa...>]

Hi,

I´ve had been using MyHDL to generate dynamic Verilog code directly from a 
python program. Leaving apart some natural difficulties due to my need of 
dynamic number of inputs and input widths, I´m facing a problem with an 
instance that I thought will be simple to implement, but returned me an 
unexpected error.

Im trying to implement a simple 8x3 multiplexer and I receive the following 
error:

Traceback (most recent call last):
  File "C:\ECLIPSE\Scales_verilog\DYN\average_hw.py", line 624, in <module>
    N_TRUNC, N_CALIB)
  File "C:\Python27\lib\site-packages\myhdl\conversion\_toVerilog.py", line 
135, in __call__
    genlist = _analyzeGens(arglist, h.absnames)
  File "C:\Python27\lib\site-packages\myhdl\conversion\_analyze.py", line 
168, in _analyzeGens
    raise ConversionError(_error.UnsupportedType, n, info)
myhdl.ConversionError: File C:\ECLIPSE\Scales_verilog\DYN\HDW.py, line 182: 
Object type is not supported in this context: in4

The related parts of my code are:

    n0 = Signal(intbv(15))[12:0]
    n1 = Signal(intbv(31))[12:0]
    n2 = Signal(intbv(63))[12:0]
    n3 = Signal(intbv(127))[12:0]
    n4 = Signal(intbv(255))[12:0]
    n5 = Signal(intbv(511))[12:0]
    n6 = Signal(intbv(1023))[12:0]
    n7 = Signal(intbv(2047))[12:0]
    db6 = Signal(intbv(0)[12:0])
    n = Signal(intbv(0)[3:0])
    U_25 = Mux_8(n0, n1, n2, n3, n4, n5, n6, n7, db6, n)

# Multiplexer (8 inputs, 3 bits selector)
def Mux_8(in0, in1, in2, in3, in4, in5, in6, in7, out, sel):
    @always_comb
    def logic():
        if sel == 0x0:
            out.next = in0
        elif sel == 0x1:
            out.next = in1
        elif sel == 0x2:
            out.next = in2
        elif sel == 0x3:
            out.next = in3            
        elif sel == 0x4:
            out.next = in4          
        elif sel == 0x5:
            out.next = in5            
        elif sel == 0x6:
            out.next = in6
        else:
            out.next = in7      
    return instances()  


I have edited manually the code of "_extractHierarchy" with some print 
statements to obtain the types for each input, and it stops at in4, with the 
following sequence of prints:

<class 'myhdl._Signal._Signal'>
<class 'myhdl._Signal._Signal'>
<class 'myhdl._Signal._Signal'>
<class 'myhdl._Signal._Signal'>
<class 'myhdl._intbv.intbv'>


The original type of all the inputs is <class 'myhdl._intbv.intbv'>.

Using python 2.7 under Eclipse with Pydev and MyHDL 0.8.


Any sugestions?

[myhdl-list] myhdl.org website migration

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

For a long time and for various reasons, I was no longer
happy with myhdl.org. I have blogged about some of
the issues here:

http://www.jandecaluwe.com/blog/wikis-dont-work.html

Eventually, I have decided to move to a static approach.
There are many systems, but noone that suited my needs.
I have blogged about this there:

http://www.jandecaluwe.com/blog/i-dont-like-blogs.html

Therefore, I decided to write my own tool:

http://urubu.jandecaluwe.com/

I have migrated my own websites, and the migration
of myhdl.org is underway. I have decided to split
in into a "development" site and a "main" site.

Migration of the development site is well underway:

http://dev.myhdl.org/

For the new myhdl.org, I have a skeleton proposal
here:

http://new.myhdl.org/

Site development and deployment happens in a
natural way from mercurial repositories on bitbucket.

Of course, I don't want to force noone to move to
the new system. However, all those that have
made significant contributions in the past may
email me privately if they would like to become
a contributor to the new websites.

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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] MyHDL hierarchy extraction and conversion process is broken

[Jan C. <jen...@mu...>]

On 28/01/14 11:24, Alexander Hungenberg wrote:
> Hey guys
    . . .
> However, as often as I was happy about the great features MyHDL
> offers, I am getting frustrated by completely misguiding error
> messages for an unknown reason, where the only possible way to fix
> them is spending many hours debugging through the MyHDL source code
> and finding the relevant part which generates the exception. But even
> when I got there, it is very difficult to find out how the MyHDL
> conversion process got to this point and which line in my sourcecode
> is relevant.

I lost my project yesterday, about nine files 1100 locs.  Had a 
quick look round, and tried to find out what I'd done, then gave up.

After restoring two files from last backup the test and conversion 
was running again.  The file I most suspected turned out to be 
clean.  So I looked into the other one.  It took about an hour to 
restore the last sessions edits, running test & convert between 
each incremental reversion.  At the end, it was a silly typo, so I 
am now back on course.

Although sometimes my errors are unrecoverable (for me), I have 
noticed that the MyHDL errors are becoming more understandable.  
Or, it could be partly me, as I am also being much more careful, 
and can now see that the error messages cover more complex errors 
better, but really stupid dyslexic typo errors just seem to trash 
my code base.

Last week, out of idle curiosity I chucked the verilog into the 
chip tools.  I now have a pretty floor plan to hang on the wall.

Keep at it!  The first linux I used, and the first linux mobile I 
had, both would look like junk today, but they were the stepping 
stones towards the professional and friendly systems I use today.

Jan Coombs.

Re: [myhdl-list] MyHDL hierarchy extraction and conversion process is broken

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

On 1/28/2014 5:24 AM, Alexander Hungenberg wrote:
> Hey guys
>
> Sorry for the sensational subject. I do not really have the expertise
> to really throw out such a statement.

I believe you will receive a better reception if you
have a specific example (better yet a unit test)
that demonstrates the problem and a subject title asking
for assistance instead of declaring something not working
without much evidence to support the claim.

> But I programmed quite a bit in
> MyHDL now, and I _LOVE_ the approach. Using python as a HDL seems
> pretty natural and great to achieve more flexibility. Also writing of
> tests seems a lot more painless to me.
>

That is great to hear.

> However, as often as I was happy about the great features MyHDL
> offers, I am getting frustrated by completely misguiding error
> messages for an unknown reason, where the only possible way to fix
> them is spending many hours debugging through the MyHDL source code
> and finding the relevant part which generates the exception. But even
> when I got there, it is very difficult to find out how the MyHDL
> conversion process got to this point and which line in my sourcecode
> is relevant.

The best and most productive way to debug a module
is to have a test for the module.  I am not aware
of many (any?) cases when someone had a test and
proved the functionality, that conversion was much
of an issue.

>
> One example I recently tried to program was a flexible serial
> receiver/transmitter, which takes a variable amount of 16-bit
> arguments and transmits them on request using Xilinx's uart core. In
> python I declared this module as
>
> def communicator(rx, tx, ... , clk, *data)
>
> However, this didn't work. I digged through the MyHDL conversion
> process and let me say, even as a Python expert it is really painful
> :-D
>

Posting the error (or a chunk of it) or a sandbox
example of a similar error to this mailing-list,
you will get some useful help.

> MyHDL uses a large mix of profiling, static code inspection and
> runtime function inspection to determine the contained generators and
> used signals. Due to this the conversion process jumps around
> endlessly in the code, and precisely due to this mix (especially of
> static source code inspection and the dynamic one) it is impossible to
> use the great features which Python offers in terms of flexibility
> (dynamic numbers of arguments until the conversion process starts,
> code reuse by using classes, ...). Or at least it is not possible with
> my deepness of understanding of MyHDL.
>
> I know, this is some pretty blurry and not very constructive critics,
> but my intuition tells me that there should be a lot more consistent
> way of doing the conversion (ideally, only based on runtime
> inspection) which allows such ways of programming increasing the
> usefulness of MyHDL a lot. Even if it needs some additional function
> call in each module to register signals or generators to the
> converter.

The error messages are ever evolving and improving
but the converter is not a compiler and the information
from the converter might always be less than one
might hope.  As noted, if tested this usually is not
an issue.

Regards,
Chris

Re: [myhdl-list] MyHDL hierarchy extraction and conversion process is broken

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

On 01/28/2014 12:24 PM, Alexander Hungenberg wrote:
> Hey guys
>
> Sorry for the sensational subject. I do not really have the expertise
> to really throw out such a statement.

Then why do you make it?

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

Re: [myhdl-list] MyHDL hierarchy extraction and conversion process is broken

[Jan C. <jen...@mu...>]

On 28/01/14 11:24, Alexander Hungenberg wrote:
> Hey guys
    . . .

Thanks for the illuminating comments.  I'd noticed that conversion 
is complex, and sometimes error messages don't help me so much. 
That is why I am determined to test more fully, and check 
conversion as early and frequently as possible, so that I can guess 
what it is I am breaking!

Python and MyHDL are amazing, but do remind of the old saying:

"Any sufficiently advanced form of technology is indistinguishable 
from magic "

Jan Coombs.

[myhdl-list] MyHDL hierarchy extraction and conversion process is broken

[Alexander H. <ale...@gm...>]

Hey guys

Sorry for the sensational subject. I do not really have the expertise
to really throw out such a statement. But I programmed quite a bit in
MyHDL now, and I _LOVE_ the approach. Using python as a HDL seems
pretty natural and great to achieve more flexibility. Also writing of
tests seems a lot more painless to me.

However, as often as I was happy about the great features MyHDL
offers, I am getting frustrated by completely misguiding error
messages for an unknown reason, where the only possible way to fix
them is spending many hours debugging through the MyHDL source code
and finding the relevant part which generates the exception. But even
when I got there, it is very difficult to find out how the MyHDL
conversion process got to this point and which line in my sourcecode
is relevant.

One example I recently tried to program was a flexible serial
receiver/transmitter, which takes a variable amount of 16-bit
arguments and transmits them on request using Xilinx's uart core. In
python I declared this module as

def communicator(rx, tx, ... , clk, *data)

However, this didn't work. I digged through the MyHDL conversion
process and let me say, even as a Python expert it is really painful
:-D

MyHDL uses a large mix of profiling, static code inspection and
runtime function inspection to determine the contained generators and
used signals. Due to this the conversion process jumps around
endlessly in the code, and precisely due to this mix (especially of
static source code inspection and the dynamic one) it is impossible to
use the great features which Python offers in terms of flexibility
(dynamic numbers of arguments until the conversion process starts,
code reuse by using classes, ...). Or at least it is not possible with
my deepness of understanding of MyHDL.

I know, this is some pretty blurry and not very constructive critics,
but my intuition tells me that there should be a lot more consistent
way of doing the conversion (ideally, only based on runtime
inspection) which allows such ways of programming increasing the
usefulness of MyHDL a lot. Even if it needs some additional function
call in each module to register signals or generators to the
converter.

In the hope I didn't insult anyone and I didn't reveal myself as a
complete moron because I forgot a simple MyHDL key concept, please
tell me your opinions or what I could do better? Unfortunately I
currently have another project which needs some progress, so I can't
commit a lot work to commiting code to MyHDL, but I really want to see
this project going to the next level :-)

Best,
Alex

Re: [myhdl-list] Using lists for repetitive signal routing

[Jan C. <jen...@mu...>]

On 06/01/14 17:53, Christopher Felton wrote:
> On 1/5/2014 4:00 PM, Jan Coombs wrote:
>> I am trying to connect a series of code blocks using
>> lists.  The boolean signal lists are working, but the
>> intbv list seem not to.
> This sounds to be a debug problem?  I believe
> you are describing a scenario similar to the
> following:
>
>       N = 4
>       x = [Signal(intbv(ii)[32:]) for ii in range(N)]
>       g = []
>       for xx,yy in zip(x[:-1],x[1:]):
>           g.append(m_something(xx,yy))
Thanks, you are right.  I adapted the example above to match my code,
and tested, but still couldn't see the bug.  To keep things moving 
I did
an ugly work around, until I eventually spotted this:

   di1hOutL = [Signal(intbv(3))[LenDiIndx:] for i in range(NumHndls+2)]

I've now (at last) started to build table-driven tests for simpler 
modules,
and am finding that writing the code is much faster.

Jan Coombs
-- 

Re: [myhdl-list] Avoid Latches

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

On 1/16/2014 11:15 AM, Guy Eschemann wrote:
>
> I like how BSV (Bluespec SystemVerilog) uses the "?" expression for
> specifying "don't care":
>
>               if ( (a==0) && (b==0) )
>                  o = 1;
>               else if ( (a==1) && (b==1) )
>                  o = 0;
>               else
>                  o = ?;


The use of '?' in V/SV is the recommended don't
care for /casez/ statements.  The use of 'x' as a
don't care is a hijacking of the of the definition
(IMO).

But in general, I am not convinced a don't care is
needed at the HDL level.  I think there is a difference
between representing a logical function syntactically
in an HDL vs minimizing a logic expression with inputs
and outputs defined as "don't cares".

In other words, we know logic optimization works great
with simple input output tables but not necessarily
with conditional type descriptions.  It might be the
case we can simplify the HDL description if we don't
even consider don't cares.

     o.next = False if a and b else True
     # which is "not (a and b)"

Regards,
Chris

Re: [myhdl-list] Avoid Latches

[Guy E. <gu...@no...>]

I like how BSV (Bluespec SystemVerilog) uses the "?" expression for 
specifying "don't care":

             if ( (a==0) && (b==0) )
                o = 1;
             else if ( (a==1) && (b==1) )
                o = 0;
             else
                o = ?;

Since BSV uses 2-valued logic, the "?" does not mean 'X'. It just allows 
the compiler to pick whatever value it thinks is more convenient.

Cheers,
Guy.


Am 16.01.2014 15:43, schrieb Christopher Felton:
>> On 15.01.2014 17:12, Christopher Felton wrote:
>>> OT: 'x' in Verilog, is it "don't care" or is it
>>> "unknown" or when is it one or the other :)
>> don't care :)
> Designer use as don't care, simulator as unknown.
>
>>> In an @always_comb there can be no undefined paths,
>>> /dout/ and /iodriverr/ need to be defined for each
>>> logical path.
>> That's why I wanted a don't care value ;)
> See section 3 page 10 from:
> http://www.arm.com/files/pdf/Verilog_X_Bugs.pdf
>
>>> If this is a bus, in an FPGA it is reasonable to
>>> drive the bus to zero when not used, that way the
>>> buses can be "OR'd" together.
>> I use tristates for my bus, but okay. I think that's much easier,
>> because I can 'switch' results on and off to the case I need them.
> Typically, you would only use *tristates* for
> off-chip interfaces.  In an FPGA or ASIC an OR'd [1]
> bus or multiplexed bus would be used.
>
>>>        @always_comb
>>>        def read():
>>>            # default values
>>>            dout.next = 0
>>>            iodriverr.next = 0
>>>
>>>            # conditional values
>>>            if ready:
>>>                dout.next = in_data
>>>                if not hit:
>>>                    iodriverr.next = in_data
>>>
>>> This will prevent the latches.
>> This is one option, but iirc the reason for the don't care value is,
>> that the 'compiler' can optimize the output to make it as effective as
>> possible. But I will use the '0-solution' for now, thanks anyway.
>>
> The 'x' can cause more problems that it is worth.
>
> Here is another paper on Verilog's 'x':
> http://www.sutherland-hdl.com/papers/2013-DVCon_In-love-with-my-X_paper.pdf
>
> Recall, Verilog is not the standard - more often it
> provides examples how not to do things (sometimes
> leverage the good :)
>
> [1] really any logic the provides an "identity" can
>       be used, the simple case are OR and AND
>       A | 0 = A
>       A & 1 = A
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

-- 
Guy Eschemann
noasic e.K.
Sundheimer Feld 6
77694 Kehl, Germany

Tel.: +49 (0) 7851 63 66 305
Mobile: +49 (0) 173 72 51 886
gu...@no...
Follow me on Twitter: @geschema
Skype: guy.eschemann
http://noasic.com
http://fpga-exchange.com
http://fpga-news.de
USt-IdNr.: DE266749532
HRA 703582, Amtsgericht Freiburg i. Br.

Re: [myhdl-list] Avoid Latches

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

> On 15.01.2014 17:12, Christopher Felton wrote:
>> OT: 'x' in Verilog, is it "don't care" or is it
>> "unknown" or when is it one or the other :)
> don't care :)

Designer use as don't care, simulator as unknown.

>> In an @always_comb there can be no undefined paths,
>> /dout/ and /iodriverr/ need to be defined for each
>> logical path.
> That's why I wanted a don't care value ;)

See section 3 page 10 from:
http://www.arm.com/files/pdf/Verilog_X_Bugs.pdf

>> If this is a bus, in an FPGA it is reasonable to
>> drive the bus to zero when not used, that way the
>> buses can be "OR'd" together.
> I use tristates for my bus, but okay. I think that's much easier,
> because I can 'switch' results on and off to the case I need them.

Typically, you would only use *tristates* for
off-chip interfaces.  In an FPGA or ASIC an OR'd [1]
bus or multiplexed bus would be used.

>>       @always_comb
>>       def read():
>>           # default values
>>           dout.next = 0
>>           iodriverr.next = 0
>>
>>           # conditional values
>>           if ready:
>>               dout.next = in_data
>>               if not hit:
>>                   iodriverr.next = in_data
>>
>> This will prevent the latches.
> This is one option, but iirc the reason for the don't care value is,
> that the 'compiler' can optimize the output to make it as effective as
> possible. But I will use the '0-solution' for now, thanks anyway.
>

The 'x' can cause more problems that it is worth.

Here is another paper on Verilog's 'x':
http://www.sutherland-hdl.com/papers/2013-DVCon_In-love-with-my-X_paper.pdf

Recall, Verilog is not the standard - more often it
provides examples how not to do things (sometimes
leverage the good :)

[1] really any logic the provides an "identity" can
     be used, the simple case are OR and AND
     A | 0 = A
     A & 1 = A

Regards,
Chris

Re: [myhdl-list] Avoid Latches

[Marcel H. <1he...@in...>]

On 15.01.2014 17:12, Christopher Felton wrote:
> OT: 'x' in Verilog, is it "don't care" or is it
> "unknown" or when is it one or the other :)
don't care :)
> In an @always_comb there can be no undefined paths,
> /dout/ and /iodriverr/ need to be defined for each
> logical path.
That's why I wanted a don't care value ;)
> If this is a bus, in an FPGA it is reasonable to
> drive the bus to zero when not used, that way the
> buses can be "OR'd" together.
I use tristates for my bus, but okay. I think that's much easier,
because I can 'switch' results on and off to the case I need them.
>      @always_comb
>      def read():
>          # default values
>          dout.next = 0
>          iodriverr.next = 0
>
>          # conditional values
>          if ready:
>              dout.next = in_data
>              if not hit:
>                  iodriverr.next = in_data
>
> This will prevent the latches.
This is one option, but iirc the reason for the don't care value is,
that the 'compiler' can optimize the output to make it as effective as
possible. But I will use the '0-solution' for now, thanks anyway.

Greetings
Marcel

Re: [myhdl-list] Avoid Latches

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

On 1/15/2014 9:57 AM, Marcel Hellwig wrote:
> Hi everyone,
>
> currently I'm developing code for a FPGA and have the following code:
>
>> @always_comb
>> def read():
>>      if ready:
>>          dout.next = in_data
>>          if not hit:  # tell the cache the right data, so it can store it
>>              iodriverr.next = in_data
>
> the problem is that Quartus II complains about the following:
>
>> Warning (10240): Verilog HDL Always Construct warning at c25Board.v(358): inferring latch(es) for variable "Memory_MMU_mmuOut", which holds its previous value in one or more paths through the always construct
>
> after talking to my prof I figured out, why this happend and how to
> solve it. Just give the output a default value ('bx in verilog), but
> this is not possible in myhdl, because we do not have a "undefined" or
> don't care value, do we?!
> So, what is the best way to solve this?! I don't like to correct this
> manually in the verilog file every time.
>
> Greetings
> Marcel
>

OT: 'x' in Verilog, is it "don't care" or is it
"unknown" or when is it one or the other :)

In an @always_comb there can be no undefined paths,
/dout/ and /iodriverr/ need to be defined for each
logical path.

If this is a bus, in an FPGA it is reasonable to
drive the bus to zero when not used, that way the
buses can be "OR'd" together.

     @always_comb
     def read():
         # default values
         dout.next = 0
         iodriverr.next = 0

         # conditional values
         if ready:
             dout.next = in_data
             if not hit:
                 iodriverr.next = in_data

This will prevent the latches.

Hope that helps,
Chris

[myhdl-list] Avoid Latches

[Marcel H. <1he...@in...>]

Hi everyone,

currently I'm developing code for a FPGA and have the following code:

> @always_comb
> def read():
>     if ready:
>         dout.next = in_data
>         if not hit:  # tell the cache the right data, so it can store it
>             iodriverr.next = in_data

the problem is that Quartus II complains about the following:

> Warning (10240): Verilog HDL Always Construct warning at c25Board.v(358): inferring latch(es) for variable "Memory_MMU_mmuOut", which holds its previous value in one or more paths through the always construct

after talking to my prof I figured out, why this happend and how to
solve it. Just give the output a default value ('bx in verilog), but
this is not possible in myhdl, because we do not have a "undefined" or
don't care value, do we?!
So, what is the best way to solve this?! I don't like to correct this
manually in the verilog file every time.

Greetings
Marcel

Re: [myhdl-list] MEP-107: Conversion of Attribute Signal Containers

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

On 1/14/2014 2:00 PM, Guy Eschemann wrote:
> Hello,
>
> I'm not sure whether this has been discussed before, but instead of
> using underscores to create the port names (MyObj_*):
>
>       entity ex1 is
>            port (
>                clk: in std_logic;
>                MyObj_x: in unsigned(7 downto 0);
>                MyObj_y: in unsigned(3 downto 0);
>                MyObj_z: out unsigned(8 downto 0)
>            );
>       end entity ex1;
>
> names could also be mangled by putting them between backslashes, e.g.:
>
>       entity ex1 is
>            port (
>                clk: in std_logic;
>                \MyObj#x\: in unsigned(7 downto 0);
>                \MyObj#y\: in unsigned(3 downto 0);
>                \MyObj#z\: out unsigned(8 downto 0)
>            );
>       end entity ex1;
>
> Not sure whether this would be desirable, though.
>
> Cheers,
> Guy.


We need to support both Verilog and VHDL conversion,
the underscores were a natural choice for both languages.

Regards,
Chris

[myhdl-list] MEP-107: Conversion of Attribute Signal Containers

[Guy E. <gu...@no...>]

Hello,

I'm not sure whether this has been discussed before, but instead of 
using underscores to create the port names (MyObj_*):

     entity ex1 is
          port (
              clk: in std_logic;
              MyObj_x: in unsigned(7 downto 0);
              MyObj_y: in unsigned(3 downto 0);
              MyObj_z: out unsigned(8 downto 0)
          );
     end entity ex1;

names could also be mangled by putting them between backslashes, e.g.:

     entity ex1 is
          port (
              clk: in std_logic;
              \MyObj#x\: in unsigned(7 downto 0);
              \MyObj#y\: in unsigned(3 downto 0);
              \MyObj#z\: out unsigned(8 downto 0)
          );
     end entity ex1;

Not sure whether this would be desirable, though.

Cheers,
Guy.

Re: [myhdl-list] VHDL Conversion Issue

[Guy E. <gu...@no...>]

Thanks, that did the trick.

Guy.

Am 12.01.2014 21:49, schrieb Marcel Hellwig:
> On 12.01.2014 21:19, Guy Eschemann wrote:
>> elif s_rom_dout[1+7:3] == intbv("11101"):
>
> simple write
> elif s_rom_dout[1+7:3] == 0b11101
>
> that should work fine :)
>
> Greetings
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] VHDL Conversion Issue

[Marcel H. <1he...@in...>]

On 12.01.2014 21:19, Guy Eschemann wrote:
> elif s_rom_dout[1+7:3] == intbv("11101"):

simple write
elif s_rom_dout[1+7:3] == 0b11101

that should work fine :)

Greetings

[myhdl-list] VHDL Conversion Issue

[Guy E. <gu...@no...>]

Hello,

I started using myHDL just a few days ago, and so far things are going 
*really* well.

One issue I've just run into is that the following line of Python code:

    elif s_rom_dout[1+7:3] == intbv("11101"):

gets converted to the following (incorrect) VHDL code:

    elsif (signed(resize(s_rom_dout((1 + 7)-1 downto 3), 6)) =
    string'("11101")) then

Am I doing something wrong, or is that a bug in the converter?

Thanks,
Guy.

-- 
Guy Eschemann
noasic e.K.
Sundheimer Feld 6
77694 Kehl, Germany

Tel.: +49 (0) 7851 63 66 305
Mobile: +49 (0) 173 72 51 886
gu...@no...
Follow me on Twitter: @geschema
Skype: guy.eschemann
http://noasic.com
http://fpga-news.de
USt-IdNr.: DE266749532
HRA 703582, Amtsgericht Freiburg i. Br.

Re: [myhdl-list] Modelsim cosim.do do script file for testing missing

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

On 01/07/2014 12:57 PM, Euripedes Rocha Filho wrote:
> Hi,
> I'm running the cosimulation tests using modelsim and the comi.do file is missing.
> I fixed it using tha same code found in:
> https://bitbucket.org/mattip/myhdl_fork/src/884f52072d3e?at=0.8-dev
>
> Just pointing for some one with the same issue.
>
> Another question is where are the right place to fork myhdl for start to help on the development and place issues. I found some repos in github, bitbucket and sourceforge.

http://myhdl.org/doku.php/dev:repo

>
> Regards
>
> Euripedes
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


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

Re: [myhdl-list] Modelsim cosim.do do script file for testing missing

[Euripedes R. F. <roc...@gm...>]

>
> Are you saying the cosim.do is not in the released
> package?


Yes. The released package doesn't have the file.



> >
> > Just pointing for some one with the same issue.
> >
> > Another question is where are the right place to fork myhdl for start to
> > help on the development and place issues. I found some repos in github,
> > bitbucket and sourceforge.
> >
>
> The official MyHDL repository is located at at:
>
> http://bitbucket.org/jandecaluwe/myhdl
>
> (I believe you forked already).  You will want
> to work on the 0.9-dev branch if you plan on
> creating an pull requests.
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Modelsim cosim.do do script file for testing missing

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

On 1/7/2014 5:57 AM, Euripedes Rocha Filho wrote:
> Hi,
> I'm running the cosimulation tests using modelsim and the comi.do file is
> missing.
> I fixed it using tha same code found in:
> https://bitbucket.org/mattip/myhdl_fork/src/884f52072d3e?at=0.8-dev

I am not sure what change you are talking about,
the "cosim.do" which is located in the
cosimuilation/modelsim/test is present in the main
repository?

https://bitbucket.org/jandecaluwe/myhdl/src/00fa55af16ba9ae48bda52da0c423ee7a11cf24d/cosimulation/modelsim/test/?at=default

Are you saying the cosim.do is not in the released
package?

>
> Just pointing for some one with the same issue.
>
> Another question is where are the right place to fork myhdl for start to
> help on the development and place issues. I found some repos in github,
> bitbucket and sourceforge.
>

The official MyHDL repository is located at at:

http://bitbucket.org/jandecaluwe/myhdl

(I believe you forked already).  You will want
to work on the 0.9-dev branch if you plan on
creating an pull requests.

Regards,
Chris

Re: [myhdl-list] Modelsim cosim.do do script file for testing missing

[Keerthan jai.c <jck...@gm...>]

Official repo: https://bitbucket.org/jandecaluwe/myhdl


On Tue, Jan 7, 2014 at 6:57 AM, Euripedes Rocha Filho <
roc...@gm...> wrote:

> Hi,
> I'm running the cosimulation tests using modelsim and the comi.do file is
> missing.
> I fixed it using tha same code found in:
> https://bitbucket.org/mattip/myhdl_fork/src/884f52072d3e?at=0.8-dev
>
> Just pointing for some one with the same issue.
>
> Another question is where are the right place to fork myhdl for start to
> help on the development and place issues. I found some repos in github,
> bitbucket and sourceforge.
>
> Regards
>
> Euripedes
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>


-- 
have a nice day
-jck