myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Documentation doubts

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

Hi all:

I am currently updating the documentation for release 0.5.
With the 0.5 release, I hope to attract new users.

However, I'm not sure the current set of docs is adequate
for new users. Pointing to the whatsnew document and the
manual may be overwhelming.

I'm not asking for addition work :-) but shouldn't there
be some kind of Getting Started document? E.g. taking
a simple example all the way to Verilog.

Or would it be sufficient to rewrite the first chapter
of the manual, e.g. by moving the stuff about bus-functional
procedures to a later chapter, and making it more tutorial-
like?

As you have all been new users at one point, perhaps you
have some ideas on what was missing (if anything) to get
you on track asap.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: myHDL docs wiki-ized

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

George Pantazopoulos wrote:
> Hi Jan,
> 
>   Any chance you could make the myHDL docs editable by members? 
> Sometimes I have ideas to make them clearer or more accurate and I wish 
> I could update the docs on the spot.

It's not trivial work - all tex sources would have to be
ported (with lots of manual interventions) to the wiki format.

Of course I see the value of the wiki-tization, that's why I
turned the whole website into a wiki. I am using that
for the latest whatsnew documents and for all future new documents.

I am just not sure yet that abandoning Latex altogether for the
manual is a good idea at this point. E.g. there is no
straightforward solution yet to make a complete html snapshot or pdf
document from dokuwiki pages. Also, printing from dokuwiki currently
doesn't look nearly as nice as the pdf generated from Latex.

I assume that some people may want to install the html for the
manual locally, or to print it out. Or not?

We could take a gradual approach by creating a documentation
development zone and starting an alternative wiki-based
manual, written/updated by users. As soon as it is better,
and when the above points get solved, it could become the
official manual.

Actually, you don't even need me for that - you can create new
wiki pages and you have the tex sources to start from if desirable.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: co-simulation: vpi file

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

Günter Dannoritzer wrote:
> George Pantazopoulos wrote:
> 
>>Hi all, in the example taken from the docs below, where is the myhdl.vpi
>>file supposed to come from?
>>
>>Thanks,
>>George
>>

> 
> 
> I did not pay attention whether one of the development snapshots Jan put
> on the page are complete.

The snapshots contain all you need (or at least all there is) in
terms of code. The latest snapshots just don't have the pdf
and html for the documentation.

However, all co-simulation stuff is oriented towards Linux/Unix
environments, and this is not clearly indicated in the various
README files.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] co-simulation: vpi file

[<dan...@we...>]

George Pantazopoulos wrote:
> Hi all, in the example taken from the docs below, where is the myhdl.vpi
> file supposed to come from?
> 
> Thanks,
> George
> 
> 
> import os
> 
> from myhdl import Cosimulation
> 
> cmd = "iverilog -o bin2gray -Dwidth=%s bin2gray.v dut_bin2gray.v"
>      def bin2gray(B, G, width):
>    os.system(cmd % width)
>    return Cosimulation("vvp -m ./myhdl.vpi bin2gray", B=B, G=G)
> 

I did not pay attention whether one of the development snapshots Jan put
on the page are complete. But if you download the 0.4 code and unpack
it, there is a cosimulation directory with an Icarus folder. In there is
a myhdl.c file which needs to be compiled and put in the folder,
specified in the README.txt file.

I saw you are using cygwin. I had trouble getting cosimulation going
under it, but that might be because of my strange setup with python. I
have the native windows python and that does not support the os.fork
command, which the myhdl cosimulation is relying on.

Now I tried the cygwin python version, which solved the os.fork problem,
but got some other error message. As I also use Linux I did not follow
up on that problem. I wonder whether it comes form the fact that I have
Icarus as windows package. I probably would need to compile it from
scratch under cygwin too to get it working.

Hope that helps.

Cheers,

Guenter

[myhdl-list] myHDL docs wiki-ized

[George P. <ge...@ga...>]

Hi Jan,

   Any chance you could make the myHDL docs editable by members? 
Sometimes I have ideas to make them clearer or more accurate and I wish 
I could update the docs on the spot.

Thanks,
George

[myhdl-list] co-simulation: vpi file

[George P. <ge...@ga...>]

Hi all, in the example taken from the docs below, where is the myhdl.vpi file supposed to come from?

Thanks,
George


import os

from myhdl import Cosimulation

cmd = "iverilog -o bin2gray -Dwidth=%s bin2gray.v dut_bin2gray.v"
      
def bin2gray(B, G, width):
    os.system(cmd % width)
    return Cosimulation("vvp -m ./myhdl.vpi bin2gray", B=B, G=G)

Re: [myhdl-list] Style based on decorators

[bedros <be...@ya...>]

I disagree with Matt, and agree with Jan.

This is still an experimental release (sub 1.0)
meaning major changes could happen. I think decorators
are brilliant idea; and make it look like a real HDL
rather than a hacked sequential language as in the old
style.

I would prefer to stay compatible with old style as
long it does not conflict with the new style; but
compatibality is not important.

I believe that the most important advantage with MyHDL
over other HDL's is the ability to express my designs
in the language in the least effort; and the ability
to read and understand the code without trying to
crack the cryptic ways of making it a parallel
language. Decorators simplify things and make coding
in MyHDL more elegant.

to me, MyHDL is to RTL design, is like what FPGA is to
ASIC. It's a way of getting something out quickly.
It's a fast way from concept to a cycle acurate model
of the concept; and run the design in simulation, to
verify the architecture; if things work well, I could
try toVerilog conversion; or replace parts of the
design with their equivalent verilog or VHDL by hand; 

In my work, we do everything in VHDL; I wonder if it's
possible to co-simulate VHDL and MyHDL via VHPI
interface; I don't need it right now, but probably in
a year; I'll try to figure it out.

keep the good work Jan.


-Bedros

--- Matt Ettus <ma...@et...> wrote:

> Jan Decaluwe wrote:
> > Hi:
> > 
> > I have decided to proceed with the introduction of
> decorators
> > to create local generators in 0.5.
> > 
> > In addition, I would like to make this the default
> coding style.
> > In particular, I would change all documentation
> and examples to
> > use decorators, including in tutorials. Note that
> 3 decorators
> > are introduced: @always, @always_comb, and
> @instance.
> > 
> > Also, the possibility to use a parametrizable
> generator directly
> > would be de-emphasized (but possible, of course).
> The equivalent
> > in VHDL/Verilog would be a process/always block
> with a port
> > interface, something which doesn't exist.
> Therefore, this
> > can be confusing to new users. Instead, one would
> use a function
> > that returns a single generator (as many of you do
> already).
> > This makes the overall style more consistent:
> structure is
> > always specified using a plain function, behavior
> using
> > a local generator (created with a decorator).
> > 
> > Note that all of this has no impact on backwards
> compatibility.
> > 
> > As always, let me know if you disagree.
> 
> I don't see the advantage of pushing everyone
> towards the decorators.
> Am I correct in my understanding that complex cases
> may still need the
> old syntax?
> 
> Also, I love Python and understand the desire to be
> Pythonic, but making
> things as different as possible from preexisting
> HDLs doesn't seem to
> buy anything but a steep learning curve.
> 
> Matt
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
>
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

[myhdl-list] Re: Style based on decorators

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

Matt Ettus wrote:

> I don't see the advantage of pushing everyone towards the decorators.
> Am I correct in my understanding that complex cases may still need the
> old syntax?

Generators are the raw material in MyHDL. They can have arguments,
and they can even be used dynamically in yield statements (anyone
ever tried that already?) For such cases (and all others, if you
want) the general syntax is and will always be available.

However, there is an overwhelmingly popular usage pattern: a local
generator function, embedded in a classic function that defines an
interface and structure. Such a generator function has rather special
characteristics. It is not intended to be reusable. Therefore, it
doesn't have parameters. We don't need its name, only its code. It is
intended to be called exactly once, to create a generator.

It is that clearly defined and very popular pattern that decorators
target. Within this pattern, there is always a decorator available,
no matter how complex the generator function. This is because the
@instance decorator is the catch-all decorator.

All decorators create the generator and reuse the name automatically.
This means that they automate the single meaningful way to use the
generator function, and their presence explicitly signals this.
Important advantages, I believe.

> Also, I love Python and understand the desire to be Pythonic, but making
> things as different as possible from preexisting HDLs doesn't seem to
> buy anything but a steep learning curve.

I don't think you can argue that the decorators make things
"as different as possible". On the contrary I would say, although
this is not a design goal either. In fact, there is a close
correspondence with certain Verilog statements:

   @instance    <->  initial
   @always      <=>  always
   @always_comb <=>  always_comb

I guess this may make MyHDL code with decorators easier to
understand by users of other HDLs.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: Problems inferring RAM when it is buried in system

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

George Pantazopoulos wrote:

> However, at this point I think I should rewrite it from scratch with unit
> testing and co-simulation in mind. Besides the online manual, do you know
> of any other complete examples or other resources to help get me started?

I think you have all the references for MyHDL-related info. In your
spare time background material on extreme programming (XP) techniques
may be useful reading.

Let me add some general remarks. Part of the vision behind MyHDL
is the idea that hardware design can be viewed as a specialized
software engineering discipline that can therefore benefit from
popular software development techniques, such as unit testing.

This is certainly not a mainstream viewpoint. Mainstream hardware
verification nowadays goes in totally different directions, such as
heavy use of embedded, complex assertions and constraint-driven random
testing.

So here again, we are in pioneering mode. I don't think anyone else
is considering to use unit testing (in the XP way) for hardware design.
I am very happy to hear that Tom seems completely sold on the
idea. But there's a lot of room left for exploration. I can
only hope that more people will pick it up - and also take the
time to document their findings.

Final practical remark: the standard unittest is nice, but
py.test may be an easier way to write unit tests. Disclaimer:
I haven't used it myself a lot, and you need to install
a subversion client to get it.

Greetings,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: Who is synthesizing hardware with myHDL?

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

George Pantazopoulos wrote:
> Hi all,
> 
>   Besides myself, who is synthesizing hardware with myHDL? What are you
> creating?
> 
> I'm working on a digital/analog hybrid music synthesizer like the MOS6581
> chip found in the Commodore 64. See the Users and Projects page for my
> entry: http://myhdl.jandecaluwe.com/doku.php/projects
> 
> Hopefully I'm not the only guinea pig :)

George:

I know of some other people who have done or are doing this.
But overall, you are still a pioneer. I hope you don't mind :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Re: Problems inferring RAM when it is buried in system

[Tom D. <td...@di...>]

George Pantazopoulos wrote:

>However, at this point I think I should rewrite it from scratch with unit
>testing and co-simulation in mind. Besides the online manual, do you know
>of any other complete examples or other resources to help get me started?
>
>
>  
>
Check this python information about unittest if you haven't seen it already.

http://docs.python.org/lib/module-unittest.html

Good luck.

Tom

Re: [myhdl-list] Style based on decorators

[Matt E. <ma...@et...>]

Jan Decaluwe wrote:
> Hi:
> 
> I have decided to proceed with the introduction of decorators
> to create local generators in 0.5.
> 
> In addition, I would like to make this the default coding style.
> In particular, I would change all documentation and examples to
> use decorators, including in tutorials. Note that 3 decorators
> are introduced: @always, @always_comb, and @instance.
> 
> Also, the possibility to use a parametrizable generator directly
> would be de-emphasized (but possible, of course). The equivalent
> in VHDL/Verilog would be a process/always block with a port
> interface, something which doesn't exist. Therefore, this
> can be confusing to new users. Instead, one would use a function
> that returns a single generator (as many of you do already).
> This makes the overall style more consistent: structure is
> always specified using a plain function, behavior using
> a local generator (created with a decorator).
> 
> Note that all of this has no impact on backwards compatibility.
> 
> As always, let me know if you disagree.

I don't see the advantage of pushing everyone towards the decorators.
Am I correct in my understanding that complex cases may still need the
old syntax?

Also, I love Python and understand the desire to be Pythonic, but making
things as different as possible from preexisting HDLs doesn't seem to
buy anything but a steep learning curve.

Matt

Re: [myhdl-list] Re: Problems inferring RAM when it is buried in system

[George P. <ge...@ga...>]

> George Pantazopoulos wrote:
>> Dear Jan and  Tom,
>>
>> I have created a simplified, representative mock-up of my system. When
>> this code is processed with myHDL (0.5dev1) and Xilinx ISE WebPACK
>> 7.1.04i, no RAM's are inferred. However, using the same RAM function i=
n
>> a trivial standalone example results in inferred RAM.
>>
> George:
>
> I have been able to reproduce your issue.
>
> By now I'm pretty sure that the problem is not related to embedded
> code, but to the fact that the design is not clean.
>

Jan, you were right. I tweaked my ram_inference_test_embedded.py example
to eliminate two signals that generated "assigned but never used" XST
warnings, and magically, a block ram got synthesized! :) Now I have to do
this with my real system, which will be more difficult.

However, at this point I think I should rewrite it from scratch with unit
testing and co-simulation in mind. Besides the online manual, do you know
of any other complete examples or other resources to help get me started?

Thanks,
George

Re: [myhdl-list] Re: Problems inferring RAM when it is buried in system

[Tom D. <td...@di...>]

George Pantazopoulos wrote:

>  It seems that some unit tests I would want to do require a human in the
>loop. Examples would be verifying that sounds are being produced, or
>certain messages displayed on an LCD screen. How do these fit into this
>flow, if the flow is to be automated?
>  
>

I've learned everything I know about unittests from the MyHDL manual, 
check out the unittest section:

http://www.jandecaluwe.com/Tools/MyHDL/manual/unittest.html

You need to figure out a test strategy for your system. I would not make 
a single module that I didn't test before combining it with other 
modules though and unittests make a great way to thoroughly test a 
module. And provide a means to retest later when new features are added 
or modified.

It is much easier to troubleshoot a problem in simulation than in 
hardware, so it well worth your while to create a simulation environment 
that more closely represents the real system.

>  Rather than unit tests, I've been doing test-benches and viewing the
>resulting waveforms with gtkwave. I'm running into the probem quite
>often that my system looks great in simulation, but does not work
>correctly (or at all sometimes) after being synthesized.
>  
>
Waveform viewing is very tedious and is difficult to really verify 
operation. I only look at waveforms out of desperation to help diagnose 
a problem.

>  I'd like to add unit tests to my flow, but I could really use some
>guidance and example code for this. What should I unit test? Should a
>unit test always be completely automated, etc?
>  
>
Like I said before, I would unittest everything and automate it all. 
Since you are testing in python, it becomes fairly simple to automate.

>  Could you tell me about co-simulation? I've had a tough time browsing
>the web looking for non-expert information about it. How would I go
>about doing this with myHDL and other free/low-cost tools?
>  
>
Co-simulation here refers to a mixed MyHDL and HDL simulation 
environment. Again check the manual for a great source of information:

http://www.jandecaluwe.com/Tools/MyHDL/manual/cosim.html


Tom

[myhdl-list] Who is synthesizing hardware with myHDL?

[George P. <ge...@ga...>]

Hi all,

  Besides myself, who is synthesizing hardware with myHDL? What are you
creating?

I'm working on a digital/analog hybrid music synthesizer like the MOS6581
chip found in the Commodore 64. See the Users and Projects page for my
entry: http://myhdl.jandecaluwe.com/doku.php/projects

Hopefully I'm not the only guinea pig :)

--=20
George Pantazopoulos
http://www.gammaburst.net

Re: [myhdl-list] Re: Problems inferring RAM when it is buried in system

[George P. <ge...@ga...>]

Hi Tom,

> It can't be stressed enough that the proper flow for logic design with
> MyHDL is the following:
>
> 1. MyHDL logic unittest, used here and in steps 2 and 4.

  It seems that some unit tests I would want to do require a human in the
loop. Examples would be verifying that sounds are being produced, or
certain messages displayed on an LCD screen. How do these fit into this
flow, if the flow is to be automated?

  Rather than unit tests, I've been doing test-benches and viewing the
resulting waveforms with gtkwave. I'm running into the probem quite
often that my system looks great in simulation, but does not work
correctly (or at all sometimes) after being synthesized.

  I'd like to add unit tests to my flow, but I could really use some
guidance and example code for this. What should I unit test? Should a
unit test always be completely automated, etc?

> 2. Apply unittest to toVerilog logic via cosimulation.

  Could you tell me about co-simulation? I've had a tough time browsing
the web looking for non-expert information about it. How would I go
about doing this with myHDL and other free/low-cost tools?

> 3. toVerilog logic synthesis with your favorite synthesis tool.
> 4. post synthesis unittest.
>
> If logic changes are required after step 4, all steps should be
> repeated. Note, these can all be automated from the MyHDL unittest.

Thanks,

George Pantazopoulos
http://www.gammaburst.net

Re: [myhdl-list] Re: Problems inferring RAM when it is buried in system

[Tom D. <td...@di...>]

Jan Decaluwe wrote:

>
> The overall message should be that you shouldn't draw too
> many conclusions from conversion/synthesis unless the
> design is clean. Clean meaning that it does something
> useful in simulation.

It can't be stressed enough that the proper flow for logic design with 
MyHDL is the following:

1. MyHDL logic unittest, used here and in steps 2 and 4.
2. Apply unittest to toVerilog logic via cosimulation.
3. toVerilog logic synthesis with your favorite synthesis tool.
4. post synthesis unittest.

If logic changes are required after step 4, all steps should be 
repeated. Note, these can all be automated from the MyHDL unittest.

>
> Note that it is normal and useful for synthesis tools
> to remove "unnecessary" logic, such as anything that
> is not connected to its surroundings.

XST is not that robust of a tool, but in general the cleaner the HDL, 
the less likely you get trouble with any synthesis tool.

Potentially that is another benefit of MyHDL as the Verilog generated 
should be less diverse than you could create from scratch. For example 
RAMs inferred from a list should always produce Verilog that is the same 
structure, leaving less opportunity for a synthesis problem.

Tom

[myhdl-list] Re: Problems inferring RAM when it is buried in system

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

George Pantazopoulos wrote:
> Dear Jan and  Tom,
> 
> I have created a simplified, representative mock-up of my system. When 
> this code is processed with myHDL (0.5dev1) and Xilinx ISE WebPACK 
> 7.1.04i, no RAM's are inferred. However, using the same RAM function in 
> a trivial standalone example results in inferred RAM.
> 
> I also noticed a major discrepancy between the HDL Synthesis and the 
> Final Report. Where did those 2048 flip-flops go? A similar discrepancy 
> appears to be in the "real" system too.

George:

I have been able to reproduce your issue.

By now I'm pretty sure that the problem is not related to embedded
code, but to the fact that the design is not clean.

Note that several signals are driven but not used. I have tried
the same with my Ram wrapper code: with the clean version, a
ram gets inferred, but when I disconnect the output register
from its surroundings, I get the same flip-flop inference and
advisor message as you are getting.

For MyHDL, I learn from this that it should issue similar
warning messages as XST about driven but unused signals.
I have added that to the development version.

The overall message should be that you shouldn't draw too
many conclusions from conversion/synthesis unless the
design is clean. Clean meaning that it does something
useful in simulation.

Note that it is normal and useful for synthesis tools
to remove "unnecessary" logic, such as anything that
is not connected to its surroundings.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Problems inferring RAM when it is buried in system

[George P. <ge...@ga...>]

Dear Jan and  Tom,

 I have created a simplified, representative mock-up of my system. When 
this code is processed with myHDL (0.5dev1) and Xilinx ISE WebPACK 
7.1.04i, no RAM's are inferred. However, using the same RAM function in 
a trivial standalone example results in inferred RAM.

I also noticed a major discrepancy between the HDL Synthesis and the 
Final Report. Where did those 2048 flip-flops go? A similar discrepancy 
appears to be in the "real" system too.

Xilinx ISE Synthesis report except is pasted below, followed by the 
myHDL code of the mock system.

By the way, I'm fairly new to working with python, myHDL, and the FPGA 
design flow. So if I am doing something wrong, please let me know!

Hope this helps,
George


Release 7.1.04i - xst H.42
=========================================================================
*                           HDL Synthesis                               *
=========================================================================

Synthesizing Unit <ram_inference_test_embedded>.
    Related source file is "../../Synth_plus_UART_BUG.v".
WARNING:Xst:646 - Signal <_ADAP_0_buf_in1> is assigned but never used.
WARNING:Xst:646 - Signal <_ADAP_0_buf_in2> is assigned but never used.
WARNING:Xst:646 - Signal <_U_0_bufin> is assigned but never used.
WARNING:Xst:646 - Signal <_U_0_bufRxD> is assigned but never used.
    Register <adapter_to_synth_data> equivalent to <addr> has been removed
    Found 1-bit register for signal <audio_out>.
    Found 1-bit register for signal <TxD>.
    Found 8-bit adder for signal <$n0000> created at line 41.
    Found 8-bit adder for signal <$n0001> created at line 46.
    Found 8-bit adder for signal <$n0002> created at line 56.
    Found 8-bit register for signal <_ADAP_0_c1>.
    Found 8-bit register for signal <_SYNTH_0_c1>.
    Found 2048-bit register for signal <_SYNTH_0_SYNTH_0_0_mem>.
    Found 8-bit register for signal <_U_0_c1>.
    Found 8-bit register for signal <addr>.
    Found 1-bit register for signal <we>.
INFO:Xst:738 - HDL ADVISOR - 2048 flip-flops were inferred for signal 
<_SYNTH_0_SYNTH_0_0_mem>. You may be trying to describe a RAM in a way 
that is incompatible with block and distributed RAM resources available 
on Xilinx devices, or with a specific template that is not supported. 
Please review the Xilinx resources documentation and the XST user manual 
for coding guidelines. Taking advantage of RAM resources will lead to 
improved device usage and reduced synthesis time.
    Summary:
    inferred 2083 D-type flip-flop(s).
    inferred   3 Adder/Subtractor(s).
Unit <ram_inference_test_embedded> synthesized.


=========================================================================
*                            Final Report                               *
=========================================================================
Final Results
RTL Top Level Output File Name     : ram_inference_test_embedded.ngr
Top Level Output File Name         : ram_inference_test_embedded
Output Format                      : NGC
Optimization Goal                  : Speed
Keep Hierarchy                     : NO

Design Statistics
# IOs                              : 4

Macro Statistics :
# Registers                        : 4
#      1-bit register              : 2
#      8-bit register              : 2
# Adders/Subtractors               : 2
#      8-bit adder                 : 2

Cell Usage :
# BELS                             : 1
#      VCC                         : 1
# FlipFlops/Latches                : 4
#      FD                          : 2
#      FDR                         : 2
# Clock Buffers                    : 1
#      BUFGP                       : 1
# IO Buffers                       : 2
#      OBUF                        : 2
=========================================================================





/// Begin code ////////////////////

# George Pantazopoulos
# ram_inference_test_embedded.py

from myhdl import *

# Dummy system set up to show that RAM inference does not occur under
# Xilinx ISE WebPACK 7.1.04i (Windows free version with
# XST as the synthesis tool)

# Tested with myHDL 0.5a1

# RAM construct copied verbatim from the example on the myHDL website.
# In a trivial (standalone) case, a RAM was inferred from this code
# using Xilinx XST but fails to do so when part of this system.

# Instead, it instantiates 2048 flip-flops and prints a warning to that 
effect.

# ---------------------------
# Explanation of Mock system:
# ---------------------------

# PC serial port <-> UART <- bytestream -> Adapter <- SRAM-style ctrl -> 
Synth

# A Uart turns a stream of bits into a stream of bytes.

# This byte stream is parsed by the Adapter into address, data, and control
# signals

# These control signals communicate with the Synth module and manipulate
# its internal RAM bank.

# 
-----------------------------------------------------------------------------


# RAM construct copied verbatim from the example on the myHDL website.
def RAM(dout, din, addr, we, clk, depth=128):
    """  Ram model """
   
    mem = [Signal(intbv(0)[8:]) for i in range(depth)]
 
    @always(clk.posedge)
    def write():
        if we:
            mem[int(addr)].next = din
               
    @always_comb
    def read():
        dout.next = mem[int(addr)]
       
    return write, read

# 
-----------------------------------------------------------------------------

def UART(clk, RxD, TxD, data_out, data_in):

    c1 = Signal(intbv(0)[8:])

    bufRxD = Signal(bool(0))
    bufin = Signal(intbv(0)[8:])
   
    @always(clk.posedge)
    def UartProc():
        c1.next = (c1 + 1) % 2**8

        bufRxD.next = RxD
        TxD.next = c1[0]
        data_out.next = c1
        bufin.next = data_in
       
    return instances()

# 
-----------------------------------------------------------------------------

# Mock-up bytestream to RAM protocol adapter
#
# Converts the stream of data bytes from the UART
# into a RAM write protocol.
def AdapterU2R(clk, uart_data_in, uart_data_out, ram_data_in, 
ram_data_out, addr, we):

    c1 = Signal(intbv(0)[8:])

    buf_in1 = Signal(intbv(0)[8:])
    buf_in2 = Signal(intbv(0)[8:])

    @always(clk.posedge)
    def dUtR():
        c1.next = (c1 + 1) % 2**8
        addr.next = c1
        we.next = c1[0]

        buf_in1.next = uart_data_in
        uart_data_out.next = c1

        buf_in2.next = ram_data_in
        ram_data_out.next = c1
       
    return instances()
# 
-----------------------------------------------------------------------------

# Mock up audio synthesizer.
# Controlled by talking to its internal register bank as a RAM.
#
# Takes commands from a SRAM-like interface.
# data_in and data_out are for doing writes/reads to its
# internal register bank.
def Synth(clk, we, addr, data_in, data_out, audio_out):

    c1 = Signal(intbv(0)[8:])

    # The register bank
    RAM_0 = RAM(dout=data_out,
                din=data_in,
                addr=addr,
                we=we,
                clk=clk,
                depth=256)
   
    @always(clk.posedge)
    def SynthProcess():
        c1.next = (c1 + 1) % 2**8
        audio_out.next = c1[0]
       
    return instances()

# 
-----------------------------------------------------------------------------

clk = Signal(bool(0))
RxD = Signal(bool(0))
TxD = Signal(bool(0))
audio_out = Signal(bool(0))

def Top(clk, RxD, TxD, audio_out):

    uart_to_adapter_data = Signal(intbv(0)[8:])
    adapter_to_uart_data = Signal(intbv(0)[8:])

    adapter_to_synth_data = Signal(intbv(0)[8:])
    synth_to_adapter_data = Signal(intbv(0)[8:])

    addr = Signal(intbv(0)[8:])
    we = Signal(bool(0))
   
    U_0 = UART(clk=clk,
               RxD=RxD,
               TxD=TxD,
               data_out=uart_to_adapter_data,
               data_in=adapter_to_uart_data)
   
    ADAP_0 = AdapterU2R(clk=clk,
                        uart_data_in=uart_to_adapter_data,
                        uart_data_out=adapter_to_uart_data,
                        ram_data_in=synth_to_adapter_data,
                        ram_data_out=adapter_to_synth_data,
                        addr=addr,
                        we=we)

    SYNTH_0 = Synth(clk=clk,
                    we=we,
                    addr=addr,
                    data_in=adapter_to_synth_data,
                    data_out=synth_to_adapter_data,
                    audio_out=audio_out)
   
    return instances()

toVerilog.name = "ram_inference_test_embedded"
toVerilog(Top, clk, RxD, TxD, audio_out)


///// End code /////////

Re: [myhdl-list] Problems inferring RAM when it is buried in system

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

George Pantazopoulos wrote:
> Hi Jan,
> 
>    Your trivial example of mapping a list of signals to a RAM memory 
> successfully infers a Distributed RAM under myHDL 0.5a1 and Xilinx ISE 
> 7.1.04i:
> 
> def RAM(dout, din, addr, we, clk, depth=128):
>    """  Ram model """
>       mem = [Signal(intbv(0)[8:]) for i in range(depth)]
> 
>    @always(clk.posedge)
>    def write():
>        if we:
>            mem[int(addr)].next = din
>                   @always_comb
>    def read():
>        dout.next = mem[int(addr)]
>           return write, read
> 
> 
> However, Xilinx ISE fails to infer a Distributed RAM if the ram logic is 
> buried in the system (input/output ports not exposed at top level).

Hi:

I have installed Xilinx Webpack for Linux and done some experiments. In
contrast to what you see, I have been able to infer distributed RAM for
embedded code.

Details:

I have used the MyHDL code above, as well as a wrapped version
in which every RAM interface signal comes from/goes to a register
(except the clock). So for the wrapped version, all RAM interface
signals except for the clock are internal.

For the default device choice, I noticed that only flip-flops
were inferred. I assume that the simpler devices don't contain
RAM. To be sure, I chose a Virtex 4 device for my experiments.

Initially the RAM inference style was set to "auto".

For the non-wrapped version, I get an info that it cannot use block
RAM, but then it uses distributed RAM correctly (and automatically).

For the wrapped version, it tries to use a block RAM, but then
XST fails with an internal error. However, when I then set
the RAM inference style to "distributed", a distributed RAM
gets properly inferred.

I think this shows that the issue you see is not necessarily
related to the "embedded" nature of the code, but may well be
related to other issues. Also, it seems there's nothing
conceptually wrong with the approach, but we need good
synthesis tools of course.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Problems inferring RAM when it is buried in system

[Tom D. <td...@di...>]

George,

Could you include the MyHDL code for the example that doesn't work?

My experience with XST (ISE synthesis tool) is that it isn't very useful 
at this.

I will try it on Mentor Precision which is very good at inferring all 
the structures available in your target FPGA family.

You may need to use the new User Defined Verilog feature of MyHDL to 
include a hand coded Verilog module.

Tom




George Pantazopoulos wrote:

> Hi Jan,
>
>    Your trivial example of mapping a list of signals to a RAM memory 
> successfully infers a Distributed RAM under myHDL 0.5a1 and Xilinx ISE 
> 7.1.04i:
>
> def RAM(dout, din, addr, we, clk, depth=128):
>    """  Ram model """
>       mem = [Signal(intbv(0)[8:]) for i in range(depth)]
>
>    @always(clk.posedge)
>    def write():
>        if we:
>            mem[int(addr)].next = din
>                   @always_comb
>    def read():
>        dout.next = mem[int(addr)]
>           return write, read
>
>
> However, Xilinx ISE fails to infer a Distributed RAM if the ram logic 
> is buried in the system (input/output ports not exposed at top level).
>
> In my system, I have a UART (in myHDL) that feeds a RAM bank, such 
> that the RAM bank is not accessible directly from the outside world.
> I have boiled down the resulting Verilog code to just the code 
> necessary to show the problem.
>
> Xilinx ISE infers a Distributed RAM successfully from the Verilog code 
> I pasted below. However, merely commenting out the lines that bring 
> data_out to the top level causes ISE to fail to infer a Distributed 
> RAM. It wrongly creates 2048 flip-flops and prints a warning. Because 
> my RAM bank needs to be hidden within the system, I can not have 
> data_in or data_out listed as an input and output, respectively, at 
> the module level.
>
> Besides the possibility of a myHDL problem, am I going about things 
> wrong? All my work in myHDL so far has resulted in a single module( ); 
> section in the verilog code. Do I need to somehow make multiple modules?
>
> module Synth_plus_UART_BUG (
>    sysclk,
>    RxD,
>    TxD,
>    RxD_led,
>    audio_out,
>    debug_out,
>    data_in,
>    data_out,   // commenting this out causes RAM inference to fail
> );
>
> input sysclk;
> input RxD;
> output TxD;
> reg TxD;
> output RxD_led;
> reg RxD_led;
> output audio_out;
> reg audio_out;
> output [7:0] debug_out;
> reg [7:0] debug_out;
>
> input data_in;
> output data_out;   // commenting this out causes RAM inference to fail
>
> reg [7:0] addr;
>
>
> reg we;
>
> wire [7:0] data_out;
>
> reg [7:0] _S65X81_0_rbank [0:32-1];
> reg [7:0] _S65X81_0_S65X81_0_0_mem [0:256-1];
>
> always @(posedge sysclk) begin: _Synth_plus_UART_BUG_S65X81_0_RAM_0_write
>    if (we) begin
>        _S65X81_0_S65X81_0_0_mem[addr] <= data_in;
>    end
> end
>
>
> assign data_out = _S65X81_0_S65X81_0_0_mem[addr];
>
>
> endmodule
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Re: Problems inferring RAM when it is buried in system

[George P. <ge...@ga...>]

Hi Jan,

         I am using the free Xilinx ISE 
WebPACK(http://www.xilinx.com/ise/logic_design_prod/webpack.htm). The 
latest version is 7.1.04i (which is what I am using). I would recommend 
installing it, even if you don't use a Xilinx part at the moment. You 
can choose to only synthesize (right click the Synthesize-XST item in 
the list of processes and select Run) and see what is being inferred 
when you view the synthesis report in the Design Summary. You don't need 
to do any other steps of the FPGA implementation. You probably need my 
device stats. I am using the xc3s1000 device, speed grade -4, package 
type ft256. You can see the templates that ISE looks for when inferring 
components if you select the menu Edit->Language Templates.

And yes, I was having the same problem with the shift register you 
showed me in a previous email. It would infer on a standalone example, 
but not if it was buried inside my system.

The warning I get is:

 "INFO:Xst:738 - HDL ADVISOR - 2048 flip-flops were inferred for signal 
<_S65X81_0_S65X81_0_0_mem>. You may be trying to describe a RAM in a way 
that is incompatible with block and distributed RAM resources available 
on Xilinx devices, or with a specific template that is not supported. 
Please review the Xilinx resources documentation and the XST user manual 
for coding guidelines. Taking advantage of RAM resources will lead to 
improved device usage and reduced synthesis time."

Even though my small example doesn't necessarily prove my statement, I 
have been watching the Synthesis Report when I synthesize my entire 
system, and no Distributed RAMs or shift registers are inferred. But 
they are inferred when I try synthesizing trivial examples. I'd like to 
provide you with a more complete example. Is there something specific 
you'd like to see? This is a crucial feature and I've come so far with 
myHDL already, thanks to your good work. I'd like to help you get it 
working.

Thanks,
George

> George Pantazopoulos wrote:
>
>> However, Xilinx ISE fails to infer a Distributed RAM if the ram logic 
>> is buried in the system (input/output ports not exposed at top level).
>
>
> That's quite surprizing, because I don't see the technical
> reason behind it, and it would also severely restrict the usefulness
> of the RAM inference feature. I assume other kinds of embedded
> structures are inferred properly (counters, shift registers ...)
>
> Now, I don't have Xilinx installed so I can't experiment myself. BTW, is
> this something that I could check with the free version? In that
> case, I'll install it here.
>
> Can other Xilinx users confirm this, perhaps with other (more recent?)
> ise versions, before we start looking for workarounds?
>
> Note that the small example you give doesn't prove your statement
> above: it merely shows that RAM inference fails when the output
> port is not connected at all. (In fact, I would have expected
> that the synthesis tool removes all logic in that case.)
> But I assume that the RAM output is properly connected in the
> embedded case, because otherwize the Verilog convertor would
> have turned it into an output.
>
> Jan
>

[myhdl-list] Re: Problems inferring RAM when it is buried in system

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

George Pantazopoulos wrote:

> However, Xilinx ISE fails to infer a Distributed RAM if the ram logic is 
> buried in the system (input/output ports not exposed at top level).

That's quite surprizing, because I don't see the technical
reason behind it, and it would also severely restrict the usefulness
of the RAM inference feature. I assume other kinds of embedded
structures are inferred properly (counters, shift registers ...)

Now, I don't have Xilinx installed so I can't experiment myself. BTW, is
this something that I could check with the free version? In that
case, I'll install it here.

Can other Xilinx users confirm this, perhaps with other (more recent?)
ise versions, before we start looking for workarounds?

Note that the small example you give doesn't prove your statement
above: it merely shows that RAM inference fails when the output
port is not connected at all. (In fact, I would have expected
that the synthesis tool removes all logic in that case.)
But I assume that the RAM output is properly connected in the
embedded case, because otherwize the Verilog convertor would
have turned it into an output.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Problems inferring RAM when it is buried in system

[George P. <ge...@ga...>]

Hi Jan,

    Your trivial example of mapping a list of signals to a RAM memory 
successfully infers a Distributed RAM under myHDL 0.5a1 and Xilinx ISE 
7.1.04i:

def RAM(dout, din, addr, we, clk, depth=128):
    """  Ram model """
    
    mem = [Signal(intbv(0)[8:]) for i in range(depth)]
 
    @always(clk.posedge)
    def write():
        if we:
            mem[int(addr)].next = din
                
    @always_comb
    def read():
        dout.next = mem[int(addr)]
        
    return write, read


However, Xilinx ISE fails to infer a Distributed RAM if the ram logic is 
buried in the system (input/output ports not exposed at top level).

In my system, I have a UART (in myHDL) that feeds a RAM bank, such that 
the RAM bank is not accessible directly from the outside world.
I have boiled down the resulting Verilog code to just the code necessary 
to show the problem.

Xilinx ISE infers a Distributed RAM successfully from the Verilog code I 
pasted below. However, merely commenting out the lines that bring 
data_out to the top level causes ISE to fail to infer a Distributed RAM. 
It wrongly creates 2048 flip-flops and prints a warning. Because my RAM 
bank needs to be hidden within the system, I can not have data_in or 
data_out listed as an input and output, respectively, at the module level.

Besides the possibility of a myHDL problem, am I going about things 
wrong? All my work in myHDL so far has resulted in a single module( ); 
section in the verilog code. Do I need to somehow make multiple modules?

module Synth_plus_UART_BUG (
    sysclk,
    RxD,
    TxD,
    RxD_led,
    audio_out,
    debug_out,
    data_in,
    data_out,   // commenting this out causes RAM inference to fail
);

input sysclk;
input RxD;
output TxD;
reg TxD;
output RxD_led;
reg RxD_led;
output audio_out;
reg audio_out;
output [7:0] debug_out;
reg [7:0] debug_out;

input data_in;
output data_out;   // commenting this out causes RAM inference to fail

reg [7:0] addr;


reg we;

wire [7:0] data_out;

reg [7:0] _S65X81_0_rbank [0:32-1];
reg [7:0] _S65X81_0_S65X81_0_0_mem [0:256-1];

always @(posedge sysclk) begin: _Synth_plus_UART_BUG_S65X81_0_RAM_0_write
    if (we) begin
        _S65X81_0_S65X81_0_0_mem[addr] <= data_in;
    end
end


assign data_out = _S65X81_0_S65X81_0_0_mem[addr];


endmodule

Re: [myhdl-list] 0.5a1

[<dan...@we...>]

George Pantazopoulos wrote:
> 
> Hi Guenter,
> 
> How did you go about removing your old version?
> 
> Thanks,
> George
> 

My python packages are in:

   /usr/lib/python/site-packages

To delete it I go as su in that folder and do:

  rm -rf myhdl

This will remove the installed package.

But to be safe and maybe keep it in case you want to switch back, you 
could just rename it.

   mv myhdl myhdl_old

as an example.

Now the myhdl folder is gone and you can install the new version from 
scratch.

I don't know whether there are better ways to do it. This worked always 
for me.


Cheers,

Guenter