myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] VHDL Cosim Initial Thoughts

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

On 1/8/13 6:30 PM, Daryl Wasden wrote:
>>>> Also, I haven't yet figured out how to deal with delays...
>>> I am not sure what you are asking or not understanding
>>> here?
> I see how this works now. I didn't completely understand the
> format. Now, I see the protocol structure. The time is sent
> first, then any signal changes. Doing the socket-based
> cosimulation in verilog was helpful.
>
> I am still fixing one bug, but the simulation is running
> correctly using socket communication on windows. I ran
> the test_bin2gray using Icarus. The bug is related to
> reusing the same port when moving between tests... If I
> get this up and running and fix the bug, then I'll work
> on porting it over to Linux/Mac OSX as well.
>
> -Daryl
>
>

Sounds like you are making good progress.  If you want, we
can setup a bitbucket repository and I can test out your
changes as well.  I don't have a windows system right now
but I can test it out on a linux.

Regards,
Chris

Re: [myhdl-list] synchronous register with asynchronous reset

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

Hi Martin

the following code does the trick: (notice the rst.posedge in the  
sensitivity list)

   from myhdl import *
   def flipflop(clk,rst,din,dout):

       @always(clk.posedge,rst.posedge)
       def read():
         if rst==1:
   	  dout.next=0
         else:
           dout.next = din

       return read


   clk=Signal(bool(0))
   rst=Signal(bool(0))
   din=Signal(intbv(0)[8:])
   dout=Signal(intbv(0)[8:])
   toVHDL(flipflop,clk,rst,din,dout)

Anyway i am also not quite happy with the fact that the code suggestes  
that the reset is
edge sensitive (which is actually true from a Simulation standpoint).
But the way i imagine a Flip-Flop with an asynchron reset is that if the  
reset is active
then the Flip-Flop gets reset permanently and not only on a particular  
edge. For example if
the Flip-Flop is in reset state and gets flipped over by cosmic radiation  
/noise than no actuall
edge of the reset would be needed to flip it back to the reset state, its  
really more level sensitive i think.

Anyway i prefere using a Flip-Flop with a low reset level. And then use a  
"not" on the reset signal which goes
into the Module if needed. I think thats also how most fpga vendors  
implement it.

Anyway once working i just copy over these lines because they once did  
what i wanted.


Anyway thats probably the reason why i just realised that this code would  
not work with a bool value ( a "False" instead of a "0") like this:


    from myhdl import *
    def flipflop(clk,rst,din,dout):

     @always(clk.posedge,rst.negedge)
     def read():
       if rst==False:
	dout.next=0
       else:
         dout.next = din

     return read

     clk=Signal(bool(0))
     rst=Signal(bool(0))
     din=Signal(intbv(0)[8:])
     dout=Signal(intbv(0)[8:])
     toVHDL(flipflop,clk,rst,din,dout)



->> myhdl.ConversionError: in file FlipFlop.py, line 6:
     No proper edge value test


greetings
Norbo




Am 12.01.2013, 07:03 Uhr, schrieb Martin Schoeberl <ma...@jo...>:

> Hi all,
>
> playing around with MyHDL I have a beginner question on how to write the  
> synchronous part with an asynchronous reset (for VHDL synthesis).
>
> With following code:
>
>     @always(clk.posedge)
>     def hdl():
>         if reset == 1:
>             sig.next = 0
>         else:
>             sig.next = not sig
>
>     return hdl
>
> I get a synchronous reset, which is correct, but not what I want:
>
> FOO_HDL: process (clk) is
> begin
>     if rising_edge(clk) then
>         if (reset = '1') then
>             sig <= '0';
>         else
>             sig <= to_std_logic((not to_boolean(sig)));
>         end if;
>     end if;
> end process FOO_HDL;
>
> If I change the decoration as describers in to the MyHDL manual:
>
>     @always(clk.posedge, reset.negedge)
>
> I get following VHDL code:
>
> FOO_HDL: process (clk, reset) is
> begin
>     if (reset = '1') then
>         sig <= '0';
>     elsif rising_edge(clk)or falling_edge(reset) then
>         sig <= to_std_logic((not to_boolean(sig)));
>     end if;
> end process FOO_HDL;
>
> However, that's not what I really want. There shall be no falling_edge  
> on reset.
> I would like to write some MyHDL code to generate the 'standard' pattern  
> in VHDL:
>
>     if (reset = '1') then
>         sig <= '0';
>     elsif rising_edge(clk) then
>         sig <= to_std_logic((not to_boolean(sig)));
>     end if;
>
> Sorry, if this is a too rival question and I should have found the  
> answer somewhere else.
>
> Cheers,
> Martin
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122912


-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[myhdl-list] synchronous register with asynchronous reset

[Martin S. <ma...@jo...>]

Hi all,

playing around with MyHDL I have a beginner question on how to write the synchronous part with an asynchronous reset (for VHDL synthesis).

With following code:

    @always(clk.posedge)
    def hdl():
        if reset == 1:
            sig.next = 0
        else:
            sig.next = not sig

    return hdl

I get a synchronous reset, which is correct, but not what I want:

FOO_HDL: process (clk) is
begin
    if rising_edge(clk) then
        if (reset = '1') then
            sig <= '0';
        else
            sig <= to_std_logic((not to_boolean(sig)));
        end if;
    end if;
end process FOO_HDL;

If I change the decoration as describers in to the MyHDL manual:

    @always(clk.posedge, reset.negedge)

I get following VHDL code:

FOO_HDL: process (clk, reset) is
begin
    if (reset = '1') then
        sig <= '0';
    elsif rising_edge(clk)or falling_edge(reset) then
        sig <= to_std_logic((not to_boolean(sig)));
    end if;
end process FOO_HDL;

However, that's not what I really want. There shall be no falling_edge on reset.
I would like to write some MyHDL code to generate the 'standard' pattern in VHDL:

    if (reset = '1') then
        sig <= '0';
    elsif rising_edge(clk) then
        sig <= to_std_logic((not to_boolean(sig)));
    end if;

Sorry, if this is a too rival question and I should have found the answer somewhere else.

Cheers,
Martin

[myhdl-list] [PATCH] timezone in date in emitting HDL comment

[KISHIMOTO, M. <ksm...@dd...>]

Hello,

I propose patch to print timezone in date in emitting HDL comment.

diff -ur myhdl-0.7.ORG/myhdl/conversion/_toVHDL.py myhdl-0.7/myhdl/conversion/_toVHDL.py
--- myhdl-0.7.ORG/myhdl/conversion/_toVHDL.py	2010-10-15 02:58:48.000000000 +0900
+++ myhdl-0.7/myhdl/conversion/_toVHDL.py	2013-01-07 16:27:12.000000000 +0900
@@ -27,7 +27,7 @@
 import math
 
 import inspect
-from datetime import datetime
+import time
 #import compiler
 #from compiler import ast as astNode
 import ast
@@ -197,7 +197,7 @@
 def _writeFileHeader(f, fn):
     vars = dict(filename=fn, 
                 version=myhdl.__version__,
-                date=datetime.today().ctime()
+                date=time.strftime("%a %b %d %H:%M:%S %Y %Z")
                 )
     if not toVHDL.no_myhdl_header:
         print >> f, string.Template(myhdl_header).substitute(vars)
diff -ur myhdl-0.7.ORG/myhdl/conversion/_toVerilog.py myhdl-0.7/myhdl/conversion/_toVerilog.py
--- myhdl-0.7.ORG/myhdl/conversion/_toVerilog.py	2010-10-15 02:58:48.000000000 +0900
+++ myhdl-0.7/myhdl/conversion/_toVerilog.py	2013-01-07 16:27:44.000000000 +0900
@@ -27,7 +27,7 @@
 import math
 import traceback
 import inspect
-from datetime import datetime
+import time
 import compiler
 # from compiler import ast as astNode
 import ast
@@ -189,7 +189,7 @@
 def _writeFileHeader(f, fn, ts):
     vars = dict(filename=fn, 
                 version=myhdl.__version__,
-                date=datetime.today().ctime()
+                date=time.strftime("%a %b %d %H:%M:%S %Y %Z")
                 )
     if not toVerilog.no_myhdl_header:
         print >> f, string.Template(myhdl_header).substitute(vars)

Re: [myhdl-list] VHDL Cosim Initial Thoughts

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

> > > Also, I haven't yet figured out how to deal with delays...
> > I am not sure what you are asking or not understanding
> > here? 
I see how this works now. I didn't completely understand the 
format. Now, I see the protocol structure. The time is sent 
first, then any signal changes. Doing the socket-based 
cosimulation in verilog was helpful. 

I am still fixing one bug, but the simulation is running 
correctly using socket communication on windows. I ran
the test_bin2gray using Icarus. The bug is related to 
reusing the same port when moving between tests... If I 
get this up and running and fix the bug, then I'll work 
on porting it over to Linux/Mac OSX as well.

-Daryl 

Re: [myhdl-list] VHDL Cosim Initial Thoughts

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

I have a suggestion for a change to the file _Simulation.py 
that will help my socket implementation succeed. Right now, 
the _finalize method of the Simulation class contains two 
lines (76 and 77) that explicitly close the cosim._rt and 
cosim._wf pipes... Also line 78 waits for the child process. 
I think it would be better to call a cosim._finalize method 
that performs these operations on its own member data 
(preserving encapsulation of the Cosimulation object). 

I can do a temporary modification for myself, but I'd like 
to maintain as much compatibility with MyHDL as possible so 
I can benefit from future updates from the MyHDL community.
>From the user viewpoint, the behavior would be identical. 
At some point, I may want to propose a MEP with socket 
support added to Cosimulation (either as a subclass or 
built into the main class) in the main repository if people 
think this implementation will be useful to them, but I 
want a proof-of-concept first... Just to ensure it is 
feasible.

Any thoughts/feedback? Is posting here the right place for 
this type of suggestion? 

Thanks,
Daryl

Re: [myhdl-list] VHDL Cosim Initial Thoughts

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

Christopher Felton <chris.felton <at> gmail.com> writes:

> 
> On 1/4/13 2:55 PM, Daryl Wasden wrote:
<snip> 
> This sounds reasonable, instead of the $to_myhdl and
> $from_myhdl task (stubs to the VPI code) you can have
> equivalent VHDL processes.
> 
> I believe one of the items the FLI interface will need
> to support is getting a list of the signals from the
> VHDL simulator.  Resolving the signal interface from
> the MyHDL side to the VHDL simulator side, maybe a
> little tricky.  It might be simplified with the automatic
> generation of the VHDL processes?

It would be possible and easy to use a VHDL process to 
accomplish this with a wait statement terminating it, 
but I feel that may involve more work for the end user... 
However, I have settled on a different route that reads 
the port list of the module and if a signal is "in" it 
is used to populate the to_myhdl signals and if it is 
"out" it is used to populate the from_myhdl signals. This 
all occurs during initialization (right after elaboration 
has finished in ModelSim). I like this solution so far, 
but it will always be easy to go back to the approach that 
resembles the VPI Cosimulation approach more closely if 
desired (though it should appear the same from Python's
point-of-view). 

My view of how the VHDL Cosimulation is (only) slightly 
different from the Verilog Cosimulation. 

There will be a MyHDL top-level object containing the
testbench code as well as instantiations of any MyHDL
modules that will be used in the test. The simulator is
invoked with the Cosimulation() except that the arguments
that define the ports (by passing them to $to_myhdl and
$from_myhdl) are not required. These are instead defined
in the port list of a VHDL module that I am currently 
calling MyHDL_bridge and it is found in MyHDL_bridge.vhd.
This module is defined with the "foreign" attribute in 
its architecture and as such calls the C code that sets 
up the VHDL-side. There is also a top_level.vhd file 
that instantiates the MyHDL_bridge module as well as 
any VHDL modules that are used in the cosimulation and 
connects the ports from the MyHDL bridge to the 
instantiated modules. That's the track that I am 
currently pursuing...

> > Also, I haven't yet figured out how to deal with delays...
> I am not sure what you are asking or not understanding
> here? 

Sorry, I wasn't clear before. I meant to say I'm not sure 
how the C-side of the cosimulation knows that it needs to 
look for a delay. It looks like it is a well-defined 
ordering (it reads it in the read_only_callback shortly 
after sending the current HDL-state of the the signals to 
the MyHDL-side). Maybe this is due to the fact that delays 
are only allowed on the MyHDL-side, so a future event must 
be scheduled after all signals have settled? That's just a 
guess. If so, then I have found the way in FLI using a 
prioritized process (it should occur at exactly the same 
time as the read only callback does). Only one 
process/function is required in C, so I have to test to 
see if I am on a delta cycle iteration (at the same time 
step) or the first iteration at the current simulation 
time. Basically, all three of the call backs from the VPI 
method are collapsed into a single function in the FLI 
method. I haven't decided if this is going to be a 
problem yet... But I don't think so.

Anyway, like I said, I'm fairly confident I can resolve
this even if I'm wrong at the moment on exactly why it
works in the current implementation, but if it doesn't
work for the reasons I stated, it may take me some time
to figure out why and resolve it. But I will...

> > I am opting to subclass Cosimulation as CosimulationWithSockets.
> I think this sounds like a good idea and as you state
> might be a better option for other platforms (i.e. windows).
> I don't know enough about pipes or sockets to know if there
> are any issues.  My guess, is there should not be issues,
> but possibly performance?

I'm trying to have some preliminary code executing a 
cosimulation with Icarus Verilog and the old tests in 
the cosimulation directory using the socket-based 
communication in the next day or so, so I'll update 
this thread then with my findings. Hopefully, it will 
be a positive experience.
 
> The small consensus seem to support Modelsim as the most
> popular simulator for VHDL (obviously it would be nice to
> have an open-source option but it doesn't look like that
> is possible).  I don't recall anyone else stating another
> simulator (Aldec, ncsim, , etc)

There may be a way to do it using GHDL actually. GHDL does
support the VHPI for subprograms... I think with some 
creativity it might be possible to adopt an approach 
that would work... But it wouldn't be straightforward,
that's why I'm trying to get the FLI working. I want to 
start using MyHDL with VHDL as soon as I can...

Thanks for the responses,
Daryl

Re: [myhdl-list] VHDL Cosim Initial Thoughts

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

On 1/4/13 2:55 PM, Daryl Wasden wrote:
> Okay, I have read through _Cosimulation.py, _Simulation.py, and myhdl_vpi.c, and
> Jan's description here: http://www.myhdl.org/doc/0.7/manual/cosimulation.html
>
> I think I have a grasp on what the Verilog simulator is doing during
> cosimulation: Basically, run the simulation, schedule a callback that occurs
> when all signals are in steady-state, make successive callbacks to simulate
> Delta cycles from VHDL, and use delay callbacks to make sure the simulation
> times match up. At least if I'm interpreting everything correctly...

Sounds like the gist of it, I will have to review as a
refresher and see if any main points are not being
considered.

>
> I don't think this exact method will work with the ModelSim Foreign Language
> Interface (FLI) since it appears to me that some of these call backs are
> missing. However, I do see an easier/compatible option I think...
>
> My thoughts: The FLI allows one to register a VHDL process, create signals,
> assign a sensitivity list to the process, and read/drive signals from C. My plan
> (barring any problems in my interpretation so far) is to programmatically create
> a "MyHDL" process in the simulator with all of the from_myhdl signals in its
> sensitivity list, and read all of the output to_myhdl signals whenever this
> process is triggered and send them back to the Cosimulation object. These may be
> defined in the VHDL interface file somehow or else creating using FLI... I'm
> still working out details there.

This sounds reasonable, instead of the $to_myhdl and
$from_myhdl task (stubs to the VPI code) you can have
equivalent VHDL processes.

I believe one of the items the FLI interface will need
to support is getting a list of the signals from the
VHDL simulator.  Resolving the signal interface from
the MyHDL side to the VHDL simulator side, maybe a
little tricky.  It might be simplified with the automatic
generation of the VHDL processes?

>
> Also, I haven't yet figured out how to deal with delays from the MyHDL testbench
> (which will be important for sure)... But I'm sure I will find a way soon.

I am not sure what you are asking or not understanding
here?  The standard way to "delay" in a testbench is

       def testbench()
          ...
          @instance
          def tb_stimulus():
              yield delay(10)

The above will delay for 10 simulation cycles.
>
> In addition, I am opting to subclass Cosimulation as CosimulationWithSockets.
> This would override the methods of Cosimulation and modify them to implement
> their interprocess communication through network sockets instead of the pipes
> that are used now. This would allow the interprocess communication to occur over
> a network (letting me work on my laptop while running the simulation on a server
> for example). Also, it adds local cosimulation functionality to windows (via
> localhost) without Cygwin (with some performance loss maybe). It should work
> equally well (with appropriate preprocessing directives) under Windows,
> Unix/Linux, or Mac OS X. I've done some preliminary testing connecting python
> code to C code using sockets. So it looks like this is feasible.

I think this sounds like a good idea and as you state
might be a better option for other platforms (i.e. windows).
I don't know enough about pipes or sockets to know if there
are any issues.  My guess, is there should not be issues,
but possibly performance?

>
> Any comments/questions/ideas are welcome. Thoughts and feedback on pros/cons of
> this approach would be greatly appreciated. Also, would this be useful for
> anyone else? If so, I'll post code once I have it working.

The small consensus seem to support Modelsim as the most
popular simulator for VHDL (obviously it would be nice to
have an open-source option but it doesn't look like that
is possible).  I don't recall anyone else stating another
simulator (Aldec, ncsim, , etc)

Regards,
Chris

>
> Once I have something that I believe is working, I'll test it by running the
> tests in the cosimulation directory (appropriately modified and using VHDL).
>
> Thanks for any feedback,
> Daryl
>
>
>
> ------------------------------------------------------------------------------
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122812
>

[myhdl-list] VHDL Cosim Initial Thoughts

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

Okay, I have read through _Cosimulation.py, _Simulation.py, and myhdl_vpi.c, and 
Jan's description here: http://www.myhdl.org/doc/0.7/manual/cosimulation.html 

I think I have a grasp on what the Verilog simulator is doing during 
cosimulation: Basically, run the simulation, schedule a callback that occurs 
when all signals are in steady-state, make successive callbacks to simulate 
Delta cycles from VHDL, and use delay callbacks to make sure the simulation 
times match up. At least if I'm interpreting everything correctly...

I don't think this exact method will work with the ModelSim Foreign Language 
Interface (FLI) since it appears to me that some of these call backs are 
missing. However, I do see an easier/compatible option I think... 

My thoughts: The FLI allows one to register a VHDL process, create signals, 
assign a sensitivity list to the process, and read/drive signals from C. My plan 
(barring any problems in my interpretation so far) is to programmatically create 
a "MyHDL" process in the simulator with all of the from_myhdl signals in its 
sensitivity list, and read all of the output to_myhdl signals whenever this 
process is triggered and send them back to the Cosimulation object. These may be 
defined in the VHDL interface file somehow or else creating using FLI... I'm 
still working out details there.

Also, I haven't yet figured out how to deal with delays from the MyHDL testbench 
(which will be important for sure)... But I'm sure I will find a way soon.

In addition, I am opting to subclass Cosimulation as CosimulationWithSockets. 
This would override the methods of Cosimulation and modify them to implement 
their interprocess communication through network sockets instead of the pipes 
that are used now. This would allow the interprocess communication to occur over 
a network (letting me work on my laptop while running the simulation on a server 
for example). Also, it adds local cosimulation functionality to windows (via 
localhost) without Cygwin (with some performance loss maybe). It should work 
equally well (with appropriate preprocessing directives) under Windows, 
Unix/Linux, or Mac OS X. I've done some preliminary testing connecting python 
code to C code using sockets. So it looks like this is feasible. 

Any comments/questions/ideas are welcome. Thoughts and feedback on pros/cons of 
this approach would be greatly appreciated. Also, would this be useful for 
anyone else? If so, I'll post code once I have it working. 

Once I have something that I believe is working, I'll test it by running the 
tests in the cosimulation directory (appropriately modified and using VHDL).

Thanks for any feedback,
Daryl

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

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

Hello,

its done. -> Low resource FFT core in myhdl
The file (a single file implementation, oh i like them) of the core is  
attached.
Here are basically the specs of the core:


# Description: This Unit does FFT in Hardware, with Fixpoint, it uses 2  
multipliers only
#        + Input data bitwidth is adjustable, Twiddle bitwidth must be the  
same for now
#        + Calculation time:   N*log2(N)+8 clock cycles , N...FFT length
#        + FFT length is setable to: 16,32,64,128,256, ...
#        + Does a complex FFT (real and imaginary values)
#        + With 18 Bit input data and 18 Bit twiddle factor the 128 point  
complex FFT has the following
#        resource usage on a Cyclon II with Quartus: 427 Logic Elements,  
4501 Memory Bits,
#        4 9Bit Multipliers== 2 18Bit Multipliers ,  runs up to 80Mhz on  
Cyclon II EP2C35 speedgrad 8
#        + The FFT core read and writes from/to an external supplied RAM.  
The RAM needs a seperate read-address
#        and write-address.During operation the FFT core needs full read  
and write acces to the RAM. Every
#        clock cycle (when the piplene is filled) one Data is read and one  
is written to/from the RAM.
#        + No Scaling
#        + The Testbench shows the error of Fixpoint FFT vs. Floatingpoint  
FFT pylab reference implementation
#        for a given inputvector-Testdata, or if an overflow occours  
(myhdl built in).
#        +Simple performance evaluation, just add some simple python code  
to the testbench to check whether the
#        fixpoint implementation matches your accuracy needs.
#        + FFT length could be made adjustable during operation in  
Hardware with little effort. e.g for interpolation
#        Note: To do the iFFT, conjungate the data before the start of the  
FFT and after the FFT is finished
#        and dont forget the scaling


All the best,
New year and X-mas greetings
Norbert



Am 26.11.2012, 16:53 Uhr, schrieb Norbo <Nor...@gm...>:

> The aim was to create a FFT core in Myhdl. The Number of FFT points  
> should
> be adjustable with 2**x.
> The upper limit of x should be not limited by the algorithm but just by
> the memory needed.
> The following python script should be a good starting point. Note the  
> code
> uses only
> multiplication, additions and the lookuptable (i am thinking about
> replacing the lookuptable by a recursive chebyshev cosinus generator so
> that the implementation itself can work quit inplace). It was written  
> with
> the hardware implementation in mind, wherby the input Data can be  
> supplied
> through a Embedded memory block. The memory bandwidth would then create
> the speedlimit. Since only one value would be read and written at a clock
> cycle.
> I am not sure if i will finish this. But every comment, critic,
> improvements are welcome.
>
> grettings
> Norbo
>
>
> ### Python FFT implementation (for a myhdl implementation reference) ####
> Author: Norbert
> Date:26.11.2012
> #########################################################################
>
>  from pylab import fft,log2,exp,pi,arange
> xin=[-7,2,3,4,5,6,7,8,-7,2,7,4,5,2,-7,2]
>
> FFTlength=len(xin)
> log2_FFTlength=int(log2(FFTlength))
>
> assert 2**log2_FFTlength==FFTlength
>
> ###data reordering ######
> Orderlookup=[]
> for i in range(FFTlength):
>      sst=list(bin(i)[2:].zfill(log2_FFTlength))
>      sst.reverse()
>      val=int("".join(sst),2)
>      Orderlookup.append(val)
>
> FFTdata=[xin[i]  for i in Orderlookup]
> ######end data reordering ########
>
> lookuptable=exp(-1j*2*pi*arange(0,FFTlength/2,1)/(FFTlength))
> count=0
> valx=2
> sections=FFTlength    #2**(log2_FFTlength-1)
> while valx<=FFTlength:
>      sections=sections>>1  # FFTlength/valx
>
>      for cur_sec in range(sections):
>          for i in range(valx>>1):
>              aww=FFTdata[i+valx*cur_sec]
>              bww=FFTdata[i+(valx>>1)+valx*cur_sec]*lookuptable[i*sections]
> # exp(-1j*2*pi*i/valx)
>
>              FFTdata[i+valx*cur_sec]=aww+bww
>              FFTdata[i+(valx>>1)+valx*cur_sec]=aww-bww
>              #count=count+1
>      valx=valx<<1
>
> ################# check result ##################
> fftxin_reference=fft(xin)
> Error_allowed=0.0001
> for ind,fftval in enumerate(FFTdata):
>      print fftval,"=",fftxin_reference[ind]
>      assert
> (abs(fftxin_reference[ind])*(1-Error_allowed))<abs(fftval)<(abs(fftxin_reference[ind])*(1+Error_allowed))
>      print "-"*50
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov


-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Re: [myhdl-list] Introduction and Question

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

On Tue, Dec 18, 2012 at 1:01 PM, Christopher Felton
<chr...@gm...> wrote:
> <snip>.
>>>
>>> We might want to poll the MyHDL community and see what the most popular
>>> VHDL simulator used is.  Might be easier to get more help :)
>>>
>>
>> Here we use Xilinx iSIM, Modelsim and we are also starting to use
>> Xilinx' next generator simulator (called Vivado Simulator).
>>
>> Cheers,
>>
>> Angel
>>
>
> Isim does not support VPI/DPI/VHPI, it has not support for external
> interfaces.  Do you know if the Vivado Simulator is based on Isim?  Does
> VivaSim support VHPI?
>
> Are you using a Vendor version of Modelsim?  Or do you have one of the
> DE/PE/Questa (was SE)?
>
> Regards,
> Chris

Chris,

we use the PE version. As for Vivado, I do not know if they support
VHPI. I don't think it is based on ISIM. They seem to have started
from scratch, which can only be a good thing given how bad ISE was.

Cheers,

Angel

Re: [myhdl-list] Introduction and Question

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

> Did you download the latest release or checkout the code from mercurial? 
>   The C-VPI files are in the cosimulation directory at the top-level.
> 
> I am fairly sure the 0.7 release has the same structure.  The files 
> would be in the unzipped tar.gz file and not the site-packages dirs.
> 
> Hope that helps,
> Chris
> 

I found the files, thanks. Is it recommended to use the 0.8dev or the 
official 0.7? Thus far, I've been using the latest release (0.7). I figured 
it was the officially released version and therefore assumed it was 
more stable, but I can switch if 0.8dev is considered stable enough 
for use or is recommended.

Daryl

Re: [myhdl-list] Introduction and Question

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

On 12/18/2012 12:10 PM, Daryl Wasden wrote:
> Okay, looking in the myhdl directory, there are no C modules... This
> confuses me, because the manual says that a PLI module for each
> simulator written in C is required... Am I missing something obvious?
>
> Anyway, I know you are busy. I'll figure this out on my own if necessary.
> I don't want to be a headache to anyone else. I'll post again when I have
> something working that is worth sharing. I'm sure I can get something
> working after reading through the FLI documentation and understanding
> the current cosimulation options a little better even if it takes a little
> while...
>
> -Daryl
>
>
>

Did you download the latest release or checkout the code from mercurial? 
  The C-VPI files are in the cosimulation directory at the top-level.

Here is a link to the webview of the merurial repository of the cver 
version.

http://hg.myhdl.org/cgi-bin/hgwebdir.cgi/myhdl/file/41d4a8b13804/cosimulation/cver

two directories above.
http://hg.myhdl.org/cgi-bin/hgwebdir.cgi/myhdl/file/41d4a8b13804/

I am fairly sure the 0.7 release has the same structure.  The files 
would be in the unzipped tar.gz file and not the site-packages dirs.

Hope that helps,
Chris

Re: [myhdl-list] Introduction and Question

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

> Just found these nice demo. ;)
> http://www.ht-lab.com/howto/uart2fli/uart2fli.html
> o use mostly modelsim.
> 
> greetings
> Norbo
> 

Thanks, Norbo. I found the C files for VPI on source forge, to. 
So, that should help as well.

-Daryl

Re: [myhdl-list] Introduction and Question

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

Am 18.12.2012, 18:49 Uhr, schrieb Daryl Wasden <dw...@ou...>:

> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
>> <snip>
>> >
>> > As a student (any type of student) you can get the student version of
>> > modelsim, Modelsim PE.  This will have the FLI and majority of the
>> > features you are probably interested in.
>> >
>> <snip>
>>
>> Ooopppss, forgot the link
>> http://model.com/content/modelsim-pe-student-edition-hdl-simulation
>>
>> .chris
>>
>
> Thanks, Chris. I'll look into the Verilog VPI examples so I have some  
> idea
> where to start. Mainly, to understand what the C modules on the myhdl
> side are doing. Then I'll see if I can write my own for ModelSim's FLI.
> Might take me a little while since I have other deadlines/projects that I
> have to attend to, but I'm hopeful I can get something working before
> too long. I appreciate your help/links.
>
> -Daryl
>



Just found these nice demo. ;)
http://www.ht-lab.com/howto/uart2fli/uart2fli.html
o use mostly modelsim.

greetings
Norbo

Re: [myhdl-list] Introduction and Question

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

Okay, looking in the myhdl directory, there are no C modules... This 
confuses me, because the manual says that a PLI module for each 
simulator written in C is required... Am I missing something obvious?

Anyway, I know you are busy. I'll figure this out on my own if necessary. 
I don't want to be a headache to anyone else. I'll post again when I have 
something working that is worth sharing. I'm sure I can get something 
working after reading through the FLI documentation and understanding 
the current cosimulation options a little better even if it takes a little 
while...

-Daryl

Re: [myhdl-list] Introduction and Question

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

Christopher Felton <chris.felton <at> gmail.com> writes:

> 
> <snip>
> >
> > As a student (any type of student) you can get the student version of
> > modelsim, Modelsim PE.  This will have the FLI and majority of the
> > features you are probably interested in.
> >
> <snip>
> 
> Ooopppss, forgot the link
> http://model.com/content/modelsim-pe-student-edition-hdl-simulation
> 
> .chris
> 

Thanks, Chris. I'll look into the Verilog VPI examples so I have some idea 
where to start. Mainly, to understand what the C modules on the myhdl 
side are doing. Then I'll see if I can write my own for ModelSim's FLI. 
Might take me a little while since I have other deadlines/projects that I 
have to attend to, but I'm hopeful I can get something working before 
too long. I appreciate your help/links.

-Daryl

Re: [myhdl-list] Introduction and Question

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

<snip>
>
> As a student (any type of student) you can get the student version of
> modelsim, Modelsim PE.  This will have the FLI and majority of the
> features you are probably interested in.
>
<snip>

Ooopppss, forgot the link
http://model.com/content/modelsim-pe-student-edition-hdl-simulation

.chris

Re: [myhdl-list] Introduction and Question

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

On 12/18/2012 9:40 AM, Daryl Wasden wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
>> <snip>.
>>>>
>>>> We might want to poll the MyHDL community and see what the most popular
>>>> VHDL simulator used is.  Might be easier to get more help :)
>>>>
>>>
>>> Here we use Xilinx iSIM, Modelsim and we are also starting to use
>>> Xilinx' next generator simulator (called Vivado Simulator).
>>>
>>> Cheers,
>>>
>>> Angel
>>>
>>
>> Isim does not support VPI/DPI/VHPI, it has not support for external
>> interfaces.  Do you know if the Vivado Simulator is based on Isim?  Does
>> VivaSim support VHPI?
>>
>> Are you using a Vendor version of Modelsim?  Or do you have one of the
>> DE/PE/Questa (was SE)?
>>
>> Regards,
>> Chris
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>>
>
> Chris,
>
> I have a copy of model sim se with a research license in my lab. I
> have used it with vhdl extensively before this. I just don't have
> a license for working at home. Not a big deal. I will look into the FLI
> information you posted.

As a student (any type of student) you can get the student version of 
modelsim, Modelsim PE.  This will have the FLI and majority of the 
features you are probably interested in.

It sounds like there is, at least a small majority using Modelsim (I too 
use Modelsim in addition to NCsim, CVC).  Modelsim probably is a 
reasonable choice.  The only downside - I believe - is that it will be 
hard to leverage the existing VPI examples for the mentor FLI.

Regards,
Chris

Re: [myhdl-list] Introduction and Question

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

Christopher Felton <chris.felton <at> gmail.com> writes:

> 
> <snip>.
> >>
> >> We might want to poll the MyHDL community and see what the most popular
> >> VHDL simulator used is.  Might be easier to get more help :)
> >>
> >
> > Here we use Xilinx iSIM, Modelsim and we are also starting to use
> > Xilinx' next generator simulator (called Vivado Simulator).
> >
> > Cheers,
> >
> > Angel
> >
> 
> Isim does not support VPI/DPI/VHPI, it has not support for external 
> interfaces.  Do you know if the Vivado Simulator is based on Isim?  Does 
> VivaSim support VHPI?
> 
> Are you using a Vendor version of Modelsim?  Or do you have one of the 
> DE/PE/Questa (was SE)?
> 
> Regards,
> Chris
> 
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> 

Chris,

I have a copy of model sim se with a research license in my lab. I 
have used it with vhdl extensively before this. I just don't have 
a license for working at home. Not a big deal. I will look into the FLI 
information you posted.

Angel,

I haven't looked at Vivado yet, but I plan to in the near future. If 
it does support cosimulation then I'll look into it sooner rather 
than later.

Thanks,
Daryl

Re: [myhdl-list] Introduction and Question

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

<snip>.
>>
>> We might want to poll the MyHDL community and see what the most popular
>> VHDL simulator used is.  Might be easier to get more help :)
>>
>
> Here we use Xilinx iSIM, Modelsim and we are also starting to use
> Xilinx' next generator simulator (called Vivado Simulator).
>
> Cheers,
>
> Angel
>

Isim does not support VPI/DPI/VHPI, it has not support for external 
interfaces.  Do you know if the Vivado Simulator is based on Isim?  Does 
VivaSim support VHPI?

Are you using a Vendor version of Modelsim?  Or do you have one of the 
DE/PE/Questa (was SE)?

Regards,
Chris

Re: [myhdl-list] Introduction and Question

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

On Tue, Dec 18, 2012 at 12:50 PM, Christopher Felton
<chr...@gm...> wrote:
> On 12/18/12 1:09 AM, Daryl Wasden wrote:
>> Christopher Felton <chris.felton <at> gmail.com> writes:
>>
>>>
>> snip
>>>
>>> It might be worth investigating if GHDL has updated the VPI/VHPI
>>> interface in the latest version of GHDL.  I monitor the GHDL
>>> mailing-list briefly and have not seen any updates.  I think the GHDL
>>> developers have mainly focused on a move to mcode.  If the status of the
>>> VPI/VHPI has not changed it will be some work to implement cosimulation
>>> with GHDL.  It will require the missing VPI functions implemented in GHDL.
>>>
>> snip
>>>
>>> I created this page and it was intended to be a working page towards
>>> GHDL co-simulation support.  The page lists which VPI functions are
>>> supported in GHDL (as of 03-Feb-2010).  The VPI function list was not
>>> complete enough to attempt a VPI port for GHDL.  I do not know if things
>>> have changed.
>>>
>>
>> Okay, I investigated this. I searched the current development repository for
>> the VPI functions that you had listed as Unknown in the table. It seems that
>> the following have at least some implementation (at least with the bleeding
>> edge repository version of GHDL).
>>
>> vpi_get_time()
>> vpi_put_value() [ has a comment FIXME, so maybe not working too well ]
>>
>> These were found in the file at the following URL:
>> http://svn.gna.org/svn/ghdl/trunk/translate/grt/grt-vpi.adb
>>
>> However, vpi_free_object() and vpi_register_systf() are declared as dummy
>> functions (I'm assuming this means that they are not implemented), and I
>> could not find vpi_control() anywhere. I'm not an expert ADA programmer
>> so I can't be certain that they are functioning 100% according to specs, but
>> they have something there. I probably don't want to worry about
>> implementing the missing functionality in ADA myself, so I'll have to take
>> the route you suggested below.
>>
>>>
>>> GHDL is not available for cosimulation.  But it is supported simulator.
>>> The flow for using GHDL is to convert the testbenches and run a full
>>> VHDL simulation that can be coordinated from Python.  See the following
>>> for some more information.
>>>
>>> http://www.myhdl.org/doc/current/whatsnew/0.6.html#conversion-of-test-benches
>>>
>>> Regards,
>>> Chris
>>>
>>
>> Thanks for pointing this out to me. Sorry I missed it. I'll look through
>> it and see what I can do. If need be, I can always just write VHDL test
>> benches for later simulations, just thinking it might be nice to use python...
>>
>> Thanks,
>> Daryl
>>
>
> There doesn't seem to be a free/open source VHDL simulator that fully
> supports VPI/VHPI.  But you might be able to get one of the commercial
> simulators working with VHDL cosimulation.  Because you are at a
> University, I don't think you will have issues getting a license/student
> version for free.  Aldec's Active-HDL appears to have the most complete
> implementation of VHPI.  Mentors Modelsim has their own FLI (foreign
> language interface) for VHDL cosimulation (not VHPI).
>
> You might want to look into one of these.  At one point I started
> exploring Modelsim's interface (FLI not available with the Altera's free
> version, IIRC).  I did not have the time to follow through and make any
> significant progress.
>
> We might want to poll the MyHDL community and see what the most popular
> VHDL simulator used is.  Might be easier to get more help :)
>

Here we use Xilinx iSIM, Modelsim and we are also starting to use
Xilinx' next generator simulator (called Vivado Simulator).

Cheers,

Angel

Re: [myhdl-list] Introduction and Question

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

On 12/18/12 1:09 AM, Daryl Wasden wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
> snip
>>
>> It might be worth investigating if GHDL has updated the VPI/VHPI
>> interface in the latest version of GHDL.  I monitor the GHDL
>> mailing-list briefly and have not seen any updates.  I think the GHDL
>> developers have mainly focused on a move to mcode.  If the status of the
>> VPI/VHPI has not changed it will be some work to implement cosimulation
>> with GHDL.  It will require the missing VPI functions implemented in GHDL.
>>
> snip
>>
>> I created this page and it was intended to be a working page towards
>> GHDL co-simulation support.  The page lists which VPI functions are
>> supported in GHDL (as of 03-Feb-2010).  The VPI function list was not
>> complete enough to attempt a VPI port for GHDL.  I do not know if things
>> have changed.
>>
>
> Okay, I investigated this. I searched the current development repository for
> the VPI functions that you had listed as Unknown in the table. It seems that
> the following have at least some implementation (at least with the bleeding
> edge repository version of GHDL).
>
> vpi_get_time()
> vpi_put_value() [ has a comment FIXME, so maybe not working too well ]
>
> These were found in the file at the following URL:
> http://svn.gna.org/svn/ghdl/trunk/translate/grt/grt-vpi.adb
>
> However, vpi_free_object() and vpi_register_systf() are declared as dummy
> functions (I'm assuming this means that they are not implemented), and I
> could not find vpi_control() anywhere. I'm not an expert ADA programmer
> so I can't be certain that they are functioning 100% according to specs, but
> they have something there. I probably don't want to worry about
> implementing the missing functionality in ADA myself, so I'll have to take
> the route you suggested below.
>
>>
>> GHDL is not available for cosimulation.  But it is supported simulator.
>> The flow for using GHDL is to convert the testbenches and run a full
>> VHDL simulation that can be coordinated from Python.  See the following
>> for some more information.
>>
>> http://www.myhdl.org/doc/current/whatsnew/0.6.html#conversion-of-test-benches
>>
>> Regards,
>> Chris
>>
>
> Thanks for pointing this out to me. Sorry I missed it. I'll look through
> it and see what I can do. If need be, I can always just write VHDL test
> benches for later simulations, just thinking it might be nice to use python...
>
> Thanks,
> Daryl
>

There doesn't seem to be a free/open source VHDL simulator that fully 
supports VPI/VHPI.  But you might be able to get one of the commercial 
simulators working with VHDL cosimulation.  Because you are at a 
University, I don't think you will have issues getting a license/student 
version for free.  Aldec's Active-HDL appears to have the most complete 
implementation of VHPI.  Mentors Modelsim has their own FLI (foreign 
language interface) for VHDL cosimulation (not VHPI).

You might want to look into one of these.  At one point I started 
exploring Modelsim's interface (FLI not available with the Altera's free 
version, IIRC).  I did not have the time to follow through and make any 
significant progress.

We might want to poll the MyHDL community and see what the most popular 
VHDL simulator used is.  Might be easier to get more help :)

Here are a couple links to possibly get started.

Modelsims FLI for VHDL:
http://www.pldworld.com/_hdl/2/_ref/se_html/manual_html/c_vhdl32.html
http://homepages.cae.wisc.edu/~ece554/new_website/ToolDoc/Modelsim_docs
/docs/pdf/fli.pdf
https://ece.uwaterloo.ca/~ece327/protected/modelsim/htmldocs/modelsim_se_fli/a_fli_intro11.html
http://www.asic-world.com/specman/interface_simulator1.html

Active-HDL VHPI:
http://www.aldec.com/resources/manuals/Active-HDL/avh00452.htm
http://www.aldec.com/resources/manuals/Active-HDL/avh00302.htm
http://www.aldec.com/en/support/resources/documentation/articles/1456
http://www.aldec.com/en/support/resources/documentation/articles/1457
http://www.aldec.com/en/search?search_field=VHPI&search_button=



Regards,
Chris

Re: [myhdl-list] Introduction and Question

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

Christopher Felton <chris.felton <at> gmail.com> writes:

> 
snip
> 
> It might be worth investigating if GHDL has updated the VPI/VHPI 
> interface in the latest version of GHDL.  I monitor the GHDL 
> mailing-list briefly and have not seen any updates.  I think the GHDL 
> developers have mainly focused on a move to mcode.  If the status of the 
> VPI/VHPI has not changed it will be some work to implement cosimulation 
> with GHDL.  It will require the missing VPI functions implemented in GHDL.
> 
snip
>
> I created this page and it was intended to be a working page towards 
> GHDL co-simulation support.  The page lists which VPI functions are 
> supported in GHDL (as of 03-Feb-2010).  The VPI function list was not 
> complete enough to attempt a VPI port for GHDL.  I do not know if things 
> have changed.
> 

Okay, I investigated this. I searched the current development repository for 
the VPI functions that you had listed as Unknown in the table. It seems that 
the following have at least some implementation (at least with the bleeding
edge repository version of GHDL). 

vpi_get_time() 
vpi_put_value() [ has a comment FIXME, so maybe not working too well ]

These were found in the file at the following URL: 
http://svn.gna.org/svn/ghdl/trunk/translate/grt/grt-vpi.adb 

However, vpi_free_object() and vpi_register_systf() are declared as dummy 
functions (I'm assuming this means that they are not implemented), and I 
could not find vpi_control() anywhere. I'm not an expert ADA programmer 
so I can't be certain that they are functioning 100% according to specs, but 
they have something there. I probably don't want to worry about 
implementing the missing functionality in ADA myself, so I'll have to take 
the route you suggested below. 

> 
> GHDL is not available for cosimulation.  But it is supported simulator. 
> The flow for using GHDL is to convert the testbenches and run a full 
> VHDL simulation that can be coordinated from Python.  See the following 
> for some more information.
> 
> http://www.myhdl.org/doc/current/whatsnew/0.6.html#conversion-of-test-benches
> 
> Regards,
> Chris
> 

Thanks for pointing this out to me. Sorry I missed it. I'll look through 
it and see what I can do. If need be, I can always just write VHDL test 
benches for later simulations, just thinking it might be nice to use python... 

Thanks,
Daryl

Re: [myhdl-list] Introduction and Question

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

On 12/17/12 5:48 PM, Daryl Wasden wrote:
> Hello everybody,
>
> I thought I would introduce myself, since I've been monitoring this mailing
> list for a few months and dabbling with MyHDL for about the same amount
> of time. I have had some success, and I am probably looking at making it
> my primary language for IP development.
>
> My name is Daryl, and I am a graduate student at the University of Utah. A
> big focus of my research is in implementing real-time DSP algorithms for
> applications in wireless communications. To this end, I occasionally find
> myself requiring IP blocks that are not readily available to me, and I end
> up writing my own. I have had some success, but I'm still learning. I am
> extremely interested in MyHDL because of its ability for unit testing and
> incorporating Python-based algorithm code into my test benches.
> Currently, I use VHDL most heavily, although I learned HDL with Verilog.

Thanks for the introduction and welcome!

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

It might be worth investigating if GHDL has updated the VPI/VHPI 
interface in the latest version of GHDL.  I monitor the GHDL 
mailing-list briefly and have not seen any updates.  I think the GHDL 
developers have mainly focused on a move to mcode.  If the status of the 
VPI/VHPI has not changed it will be some work to implement cosimulation 
with GHDL.  It will require the missing VPI functions implemented in GHDL.

> I found this link: http://www.myhdl.org/doku.php/dev:vhdl_cosim
>
> Which I think suggests that the VPI interface is supported although I'm not
> clear that it says that...

I created this page and it was intended to be a working page towards 
GHDL co-simulation support.  The page lists which VPI functions are 
supported in GHDL (as of 03-Feb-2010).  The VPI function list was not 
complete enough to attempt a VPI port for GHDL.  I do not know if things 
have changed.

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

GHDL is not available for cosimulation.  But it is supported simulator. 
  The flow for using GHDL is to convert the testbenches and run a full 
VHDL simulation that can be coordinated from Python.  See the following 
for some more information.

http://www.myhdl.org/doc/current/whatsnew/0.6.html#conversion-of-test-benches

Regards,
Chris