myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 05/11/2012 09:01 PM, James Lee wrote:
> Hi all,
>
> Thanks for the quick responses. I'm hoping this gets placed into the
> same email chain, since I foolishly forgot to subscribe to the
> mailing list before sending my previous post.

Actually you can perfectly use the usenet newsgroup
interface without ever needing to subscribe:

      http://www.myhdl.org/doku.php/mailing_list


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

Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

[Christopher L. <loz...@fr...>]

On 5/11/12 5:13 PM, Christopher Felton wrote:
>     a,b,c,d,w,x,y,z = [Signal(False) for ii in range(8)]
>     iFoo = Foo(a,b,w,x)
>     iBar = Bar(c,d,y,z)
>     toVerilog(iFoo, a,b,w,x)
>     toVerilog(iBar, c,d,y,z)
>
>
>
> In my case, I actually do not want to pass the "ports" to my 
> instantiation but rather the parameters of the design.

Good point.  Let me see if I understood you.  You do have to tell your
hardware modules what signals they are getting.  But passing signals is
not enough. I think when you instantiate a hardware module class you
would want to pass both the ports, and some parameters, such as if you
want a very fast or space efficient implementation of that hardware
module.   Is that a correct understanding?

To do this, all that is needed is that the ports method for the hardware
module class iterates through the instance variables, and only returns
those that are actually a subclass of signals.

I have modified the documentation for the proposed hardware module class
accordingly.

http://wiki.myhdlclass.com:8080/HardwareModuleClass

Existing Class

The other interesting use case is when you are defining a python
HardwareModule class for something that already exists, such as the
embedded multiplier blocks on a FPGA.  There is a need for a python
model of an existing hardware class, one already defined in Verilog.   
Such a class needs to exist in the python model, but does not convert,
because it already exists predefined in Verilog. The instances created
in python, just need to be created in Verilog.   This uses multiple
inheritance, so it can either be used with either a Atomic or Compound
Hardware module. 

Regards
Chris


 

Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

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

On 5/3/2012 10:03 AM, G. Andrew Stone wrote:
> In fact, what I thought myHDL was going to let me do is create classes that
> define blocks of logic at the RTL level (synthesizable), perhaps with
> inputs and output "Signals" as variables passed in the constructor and then
> by instantiating those classes I'd be in effect plunking down copies of
> that logic in the FPGA (or within larger logic blocks by instantiating
> these within the constructor of another class).  4 years ago I did not ever
> figure out how to do this... I don't think anything wrapped in a class was
> synthesizable back then.  But maybe that has changed now; I haven't tried
> using classes since.

These are some good points and similar topics pop up here and there. And 
based on these threads Jan D. has made some good changes to the 
documentation; -splitting the sections- and the "What MyHDL is not" 
page.  Hopefully, these help set the expectations and clear up some of 
the confusion?

 From my point of view; your class use case is only partially usable. If 
you pass the ports to the instantiation that object is literally "tied" 
in a particular use.  If I follow your description, in the following 
example I have a hypothetical python class and python function 
implementations, which is which.

    a,b,c,d,w,x,y,z = [Signal(False) for ii in range(8)]
    iFoo = Foo(a,b,w,x)
    iBar = Bar(c,d,y,z)
    toVerilog(iFoo, a,b,w,x)
    toVerilog(iBar, c,d,y,z)

If I added more code (use code not implementation) it might become 
clearer which is which.

In my case, I actually do not want to pass the "ports" to my 
instantiation but rather the parameters of the design.  If we are 
talking about using classes to model and describe complex pieces of 
hardware the "IP" usually includes much more than the hardware description.

If you get a complex piece of IP today is has a ton of stuff that comes 
with it.  It has the hardware description (Verilog/VHDL), scripts galore 
(tcl or worse perl), and models in C/C++/SystemC, Matlab, or whatever 
else HLL.  In my mind, Python/MyHDL objects are a great tool for 
simplifying complex IP organization.

Software to sea of gates (SoG) isn't a MyHDL thing.  This is an industry 
trend / problem to solve.  If you happen to be the person to correctly 
solve, you probably would have you billions and sitting on a beach some 
where :)  That assumes it is solvable with a generic high-level 
description or translation from existing program languages.

<snip>
On 5/3/2012 10:03 AM, G. Andrew Stone wrote:
> The fact of the matter is that Jan seems to have written myHDL to solve
> issues in complex hardware design and hardware simulation that only experts
> in the field can understand (either that or they are such totally obvious
> mistakes in doing a simulation that any software person would think OMG!!
> so we think that that CAN'T be the real issue:-)  ) and a lot of us are
> trying to twist the project to: 1. make it really easy to do quick and
> dirty FPGA hackups 2. learn how to program these "seas of gates".

To get to the quick and dirty FPGA, as Jan D. eluded we probably need a 
large open-source IP collection.  Then someone can tie together a bunch 
of components and implement something.

Regards,
Chris

Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

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

On 5/3/2012 10:03 AM, G. Andrew Stone wrote:
> Then write it... but honestly WRT proofreading I have one comment.  From
> reading this list it seems like you keep claiming the X does not exist and
> then Jan has to go off and point to the spot in the docs.  So the law clerk
> is having the lawyer run around and look stuff up... don't be a help
> vampire:http://slash7.com/2006/12/22/vampires/
>
> Cheers!
> Andrew

Some how I missed this when reading this thread the first time.  Nicely 
stated, the link is awesome.

Regards,
Chris

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

[James L. <rob...@gm...>]

Ah, okay, I'll keep at it and see what I can do. It seems VCS has some
limitations with vpi_get_value and vpi_put_value, this might be a lead.
Anyway, thanks for your time!

On Fri, May 11, 2012 at 4:15 PM, Christopher Felton
<chr...@gm...>wrote:

> On 5/11/12 2:44 PM, James Lee wrote:
> > No luck with 0.8 either, I tried cver, icarus, and modelsim.
> >
> > Maybe I'm not compiling it for VCS correctly? All I'm doing is changing
> > cver/myhdl_vpi.c to include "vcs_vpi_user.h" instead of "cv_vpi_user.h",
> > and changing the include path in the Linux makefile to point to the VCS
> > include directory. After that, I just compile the module into a .so and
> > link that into VCS by using the -load myhdl_vpi.so:myhdl_register +vpi
> > options, if anyone if familiar with VCS.
> >
>
> That sounds about right, if it is compiling and you don't' see any
> errors in VCS when you import the foreign interface, it "should" work.
> Sorry I don't have any suggestions for debugging the interfaces also.
> You do have to be careful for 64bit vs. 32bit but you will (should) get
> an error when importing if they don't match.
>
> I don't know enough (off the top of my head) about VCS or have access to
> VCS to be much use.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 5/11/12 2:44 PM, James Lee wrote:
> No luck with 0.8 either, I tried cver, icarus, and modelsim.
>
> Maybe I'm not compiling it for VCS correctly? All I'm doing is changing
> cver/myhdl_vpi.c to include "vcs_vpi_user.h" instead of "cv_vpi_user.h",
> and changing the include path in the Linux makefile to point to the VCS
> include directory. After that, I just compile the module into a .so and
> link that into VCS by using the -load myhdl_vpi.so:myhdl_register +vpi
> options, if anyone if familiar with VCS.
>

That sounds about right, if it is compiling and you don't' see any 
errors in VCS when you import the foreign interface, it "should" work. 
Sorry I don't have any suggestions for debugging the interfaces also. 
You do have to be careful for 64bit vs. 32bit but you will (should) get 
an error when importing if they don't match.

I don't know enough (off the top of my head) about VCS or have access to 
VCS to be much use.

Regards,
Chris

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

[James L. <rob...@gm...>]

No luck with 0.8 either, I tried cver, icarus, and modelsim.

Maybe I'm not compiling it for VCS correctly? All I'm doing is changing
cver/myhdl_vpi.c to include "vcs_vpi_user.h" instead of "cv_vpi_user.h",
and changing the include path in the Linux makefile to point to the VCS
include directory. After that, I just compile the module into a .so and
link that into VCS by using the -load myhdl_vpi.so:myhdl_register +vpi
options, if anyone if familiar with VCS.

On Fri, May 11, 2012 at 3:01 PM, James Lee <rob...@gm...>wrote:

> Hi all,
>
> Thanks for the quick responses. I'm hoping this gets placed into the same
> email chain, since I foolishly forgot to subscribe to the mailing list
> before sending my previous post.
>
> I tried compiling both the icarus and cver versions of the PLI modules and
> linking them in as shared objects, but the simulation seems to hang. I can
> confirm the callbacks are being executed by placing some debug print
> statements in myhdl_vpi.c, but when I dump the VCD, no signals are
> generated, so I'm convinced the VPI routines are not communicating signals
> correctly between the Python and the RTL.
>
> Previous to attempting to use VCS, I used iverilog for cosimulation
> successfully. So I am using all the same code with the only modifications
> being how the simulator is called on the Python side to create the
> Cosimulation object.
>
> I am using the 0.7 release right now, but I will go ahead and try with the
> latest dev release and report back with findings.
>
> Best,
> James
>
>
> On Thu, May 10, 2012 at 10:23 PM, James Lee <rob...@gm...>wrote:
>
>> Hi,
>>
>> I'm hoping to hack the PLI module for cosimulation with iverilog to make
>> it compatible with VCS.
>> Has anyone attempted something like this already and possibly provide me
>> with some insight on what changes would need to be made?
>>
>> Just based on what I read about the iverilog implementation, it seems
>> like the biggest hurdle is figuring out what type of callback to use and
>> when.
>> Would looking into if VCS can use the cbReadWriteSync callback instead of
>> the cbReadOnlySync be a good place to start?
>>
>> Thanks,
>> James
>>
>
>

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

[James L. <rob...@gm...>]

Hi all,

Thanks for the quick responses. I'm hoping this gets placed into the same
email chain, since I foolishly forgot to subscribe to the mailing list
before sending my previous post.

I tried compiling both the icarus and cver versions of the PLI modules and
linking them in as shared objects, but the simulation seems to hang. I can
confirm the callbacks are being executed by placing some debug print
statements in myhdl_vpi.c, but when I dump the VCD, no signals are
generated, so I'm convinced the VPI routines are not communicating signals
correctly between the Python and the RTL.

Previous to attempting to use VCS, I used iverilog for cosimulation
successfully. So I am using all the same code with the only modifications
being how the simulator is called on the Python side to create the
Cosimulation object.

I am using the 0.7 release right now, but I will go ahead and try with the
latest dev release and report back with findings.

Best,
James

On Thu, May 10, 2012 at 10:23 PM, James Lee <rob...@gm...>wrote:

> Hi,
>
> I'm hoping to hack the PLI module for cosimulation with iverilog to make
> it compatible with VCS.
> Has anyone attempted something like this already and possibly provide me
> with some insight on what changes would need to be made?
>
> Just based on what I read about the iverilog implementation, it seems like
> the biggest hurdle is figuring out what type of callback to use and when.
> Would looking into if VCS can use the cbReadWriteSync callback instead of
> the cbReadOnlySync be a good place to start?
>
> Thanks,
> James
>

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 5/11/12 9:37 AM, Tom Dillon wrote:
>
>
> On 05/11/2012 09:25 AM, Christopher Felton wrote:
>> Yes, for the 0.8dev you have to check it out of the repo,
>> http://www.myhdl.org/doku.php/dev:repo.
>>
>> Jan D. started a list of items for 0.8 release,
>> http://www.myhdl.org/doku.php/dev:0.8.  There are additional tweaks that
>> are not mentioned (I think) like the performance modifications to the
>> Signal.
>>
>> I have been using the 0.8dev without issues.  With any repo tip or
>> development branch use with caution.  Jan D. has put together a fairly
>> comprehensive set of unit/regression tests.  Most cases nothing is
>> committed to the repo if it doesn't pass the tests.  Meaning that the
>> dev branches is pretty stable.
>>
>> Thing to note, if you clone the repo, named branches are being used for
>> development.  After you clone the repo you have to "update" to the
>> development branch, example.
>>
>>      >>   hg clone http://hg.myhdl.org/myhdl
>>      >>   hg branches
>>      >>   hg up -C 0.8dev
>
> Thanks. Is there an easy to tell what version you are using? I know,
> getting a little lazy now.
>

 >> python
...
 >>> import myhdl
 >>> myhdl.__version___

That should give you the correct version.

Chris

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 05/11/2012 09:25 AM, Christopher Felton wrote:
> Yes, for the 0.8dev you have to check it out of the repo,
> http://www.myhdl.org/doku.php/dev:repo.
>
> Jan D. started a list of items for 0.8 release,
> http://www.myhdl.org/doku.php/dev:0.8.  There are additional tweaks that
> are not mentioned (I think) like the performance modifications to the
> Signal.
>
> I have been using the 0.8dev without issues.  With any repo tip or
> development branch use with caution.  Jan D. has put together a fairly
> comprehensive set of unit/regression tests.  Most cases nothing is
> committed to the repo if it doesn't pass the tests.  Meaning that the
> dev branches is pretty stable.
>
> Thing to note, if you clone the repo, named branches are being used for
> development.  After you clone the repo you have to "update" to the
> development branch, example.
>
>     >>  hg clone http://hg.myhdl.org/myhdl
>     >>  hg branches
>     >>  hg up -C 0.8dev

Thanks. Is there an easy to tell what version you are using? I know, 
getting a little lazy now.

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 5/11/12 8:40 AM, Tom Dillon wrote:
>
>> I concur, the cver version is more standard (?) should work with most
>> Verilog simulators out of the box.  If you get the latest development
>> code, 0.8dev, there is a modelsim directory in the cosim as well.
>> Modelsim had a memory leak some tweaks had to be made and a separate dir
>> was made.
>
> Off topic, but I have been wondering about this. I am using the 0.7
> release. Should I be using the 0.8dev?
>
> What is new? Do you have to check it out of the repos to use it?
>

Yes, for the 0.8dev you have to check it out of the repo, 
http://www.myhdl.org/doku.php/dev:repo.

Jan D. started a list of items for 0.8 release, 
http://www.myhdl.org/doku.php/dev:0.8.  There are additional tweaks that 
are not mentioned (I think) like the performance modifications to the 
Signal.

I have been using the 0.8dev without issues.  With any repo tip or 
development branch use with caution.  Jan D. has put together a fairly 
comprehensive set of unit/regression tests.  Most cases nothing is 
committed to the repo if it doesn't pass the tests.  Meaning that the 
dev branches is pretty stable.

Thing to note, if you clone the repo, named branches are being used for 
development.  After you clone the repo you have to "update" to the 
development branch, example.

   >> hg clone http://hg.myhdl.org/myhdl
   >> hg branches
   >> hg up -C 0.8dev

Chris

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

> I concur, the cver version is more standard (?) should work with most
> Verilog simulators out of the box.  If you get the latest development
> code, 0.8dev, there is a modelsim directory in the cosim as well.
> Modelsim had a memory leak some tweaks had to be made and a separate dir
> was made.

Off topic, but I have been wondering about this. I am using the 0.7 
release. Should I be using the 0.8dev?

What is new? Do you have to check it out of the repos to use it?

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 5/11/12 8:29 AM, Tom Dillon wrote:
> James,
>
> I don't know too much about this but I was able to use the myhdl_vpi.c
> source and compile it for Aldec Riviera and it works fine. I think that
> source was originally for cver? I did this quite some time ago.
>
> Have you tried to compile it for VCS?
>
> Tom
>
>
>

I concur, the cver version is more standard (?) should work with most 
Verilog simulators out of the box.  If you get the latest development 
code, 0.8dev, there is a modelsim directory in the cosim as well. 
Modelsim had a memory leak some tweaks had to be made and a separate dir 
was made.

As Tom said, you should be able to take the cver version and compile it 
for your simulator with a high probability that it will work.

Regards,
Chris

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

James,

I don't know too much about this but I was able to use the myhdl_vpi.c 
source and compile it for Aldec Riviera and it works fine. I think that 
source was originally for cver? I did this quite some time ago.

Have you tried to compile it for VCS?

Tom



On 05/10/2012 09:23 PM, James Lee wrote:
> Hi,
>
> I'm hoping to hack the PLI module for cosimulation with iverilog to 
> make it compatible with VCS.
> Has anyone attempted something like this already and possibly provide 
> me with some insight on what changes would need to be made?
>
> Just based on what I read about the iverilog implementation, it seems 
> like the biggest hurdle is figuring out what type of callback to use 
> and when.
> Would looking into if VCS can use the cbReadWriteSync callback instead 
> of the cbReadOnlySync be a good place to start?
>
> Thanks,
> James
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Restrictions for conversion

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

Am 10.05.2012, 04:06 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> On 5/5/12 10:20 AM, Norbo wrote:
>> Am 05.05.2012, 12:41 Uhr, schrieb Christopher Felton
>> <chr...@gm...>:
> <snip>
>>>>>>>
>>>>>>> I don't know if the _doinit flag is actually needed? I believe the
>>>>>>> conversion code can determine if the value should be written or not
>>>>>>> without modifying the Signal or intbv objects. As your modified  
>>>>>>> intbv
>>>>>>> does, it can always create the initial value unless the  
>>>>>>> Signal/intbv
>>>>>>> init value is None.
>>>>>> Yes this would be possible if the value (._val) of the intbv is set  
>>>>>> to
>>>>>> None.
>>>>>> But there are several things that raise, exceptions if the value is
>>>>>> set
>>>>>> to
>>>>>> None. (Boundcheck, __getitem__, etc..)
>>>>>> so i added the _doinit flag and set the (._val) to 0 (or to the min
>>>>>> value
>>>>>> if defined), and thereby avoided the error-prone changing of these
>>>>>> functions which wouldnt work with the None value.
>>>>>
>>>>> Why do you need "None"?  It would be my understanding that the
>>>>> conversion process will always create the init values in the  
>>>>> converted
>>>>> code.  You don't need the _doinit flag and you don't need None.
>>>>
>>>> My thought on this was that it may be usefull to have explicit  
>>>> controll
>>>> on
>>>> whether the initial values are written ot not. For example if a big  
>>>> ram
>>>> is
>>>> described
>>>> and you don't need the initial values, the converted file would be
>>>> filled
>>>> up with a
>>>> huge number of basically useless values. ->   Or in the words of  
>>>> "import
>>>> this" in python:
>>>> Explicit is better than implicit
>>>>
>>>
>>> To me this is *not* explicit, you don't have direct control over  
>>> _doinit
>>> you have implicit control if the initial values are generated or not
>>> (which I have even forgotten what the control is).
>> The idea of the controll was if you write:
>>       aList=[Signal(intbv(None)) for i in range(10) ]  -->  then the  
>> initial
>> values are not written no matter what.
>>       aList=[Signal(intbv(i)) for i in range(10) ]  -->  the initial  
>> values
>> are written in verilog and vhdl when there is
>> 							no combinatorical assignment ("as a path of least resistance  
>> right
>> now")
>>
>>
>
> I think we are both in agreement, now, that the None can be used for the
> explicit control (which means more changes in the implementation).  But
> I don't think I agree that there are cases when the values should *not*
> be written.  I think they should always be written (when not None).  I
> think we can work through the implementation changes.
>
> If None is used, that should mean the _doinit is not required.
>
>>
>>
>>> I hear the argument for the large inclusive of init values.  And with
>>> FPGA embedded memories and ASIC available ROM/RAM growing these could  
>>> be
>>> long init lists.  But I am not totally convinced the inconvenience of
>>> long inits are bad because it breaks the earlier argument "MyHDL to
>>> Verilog/VHDL mismatch".
>>
>> I didn't get that.
>
> It has been brought up in the past that if MyHDL simulation has initial
> values and the Verilog/VHDL does not have initial values.  Then you have
> a simulation mismatch at time 0 through time N (most cases, until the
> reset occurs).
>
> I think we have a good design plan to cover the initial values that
> includes the pre-init RAMS (nice addition).  We should probably
> summarize in a separate post (new thread, not buried).  I boils down to
> adding support for None and then creating  initial values in
> Verilog/VHDL if the intbv initial value is not None.

yup i think that hits it.
So i would summarize it like this:
* Adding support for None in the intbv (also setting None as the default  
value?)
* Creating initial values in Verilog/VHDL (when not None)
* Changing the verilog continuous assignment to the behavioral statement  
in the verilog conversion
* Work through the implementation changes needed, because of the None in  
the intbv (boundchecks, etc ..)

Re: [myhdl-list] Actel/Microsemi IGLOO nano starter kit

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

Am 10.05.2012, 23:53 Uhr, schrieb Jan Coombs  
<jan...@mu...>:

> On 10/05/12 21:06, Norbo wrote:
>     . . .
>> funny i just completed my UART Design:
>
> Excellent, there's much more to it than mine!  However, it didn't
> survive the fast dispatch and email shredding, so I've attached a
> zipped copy that runs. It has re-joined lines, odd tab chars
> removed, and an edit in the toVHDL line.


There seems to be an indentation error somewhere (i didnt figured out  
where),
it doesnt runs to the end of Simulation
where it prints: "End of Simulation, simulation succesfull!"
fixed also this: ** ToVHDLWarning: Output port is read internally:  
oWrBuffer_full
and removed the tabs.

greetings
Norbo

[myhdl-list] Developing PLI module for cosimulation with VCS

[James L. <rob...@gm...>]

Hi,

I'm hoping to hack the PLI module for cosimulation with iverilog to make it
compatible with VCS.
Has anyone attempted something like this already and possibly provide me
with some insight on what changes would need to be made?

Just based on what I read about the iverilog implementation, it seems like
the biggest hurdle is figuring out what type of callback to use and when.
Would looking into if VCS can use the cbReadWriteSync callback instead of
the cbReadOnlySync be a good place to start?

Thanks,
James

Re: [myhdl-list] Actel/Microsemi IGLOO nano starter kit

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

On 10/05/12 21:06, Norbo wrote:
    . . .
> funny i just completed my UART Design:

Excellent, there's much more to it than mine!  However, it didn't 
survive the fast dispatch and email shredding, so I've attached a 
zipped copy that runs. It has re-joined lines, odd tab chars 
removed, and an edit in the toVHDL line.

I'll polish mine & zip it up soon,  Jan Coombs.
-- 

Re: [myhdl-list] Actel/Microsemi IGLOO nano starter kit

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

Am 02.05.2012, 09:52 Uhr, schrieb Jan Coombs  
<jan...@mu...>:

> I have a number of MyHDL projects which build source files for
> demos on this low power FPGA card, and would be happy to share
> these.  Card detail:
>
> http://www.actel.com/products/hardware/devkits_boards/igloonano_starter.aspx
>
> They include access to switches and LEDs on the board, and the
> source for a UART for linking the card to a host PC.
>
> Next, I moving on to testing the block RAMs, then building a
> complex processor cache.  Anyone been there before?
>
> Jan Coombs

funny i just completed my UART Design:

#!/usr/bin/env python
# Description: UART Receiver and Transmitter with Receive- and  
Transmitbuffer
#
# Module Signals:
# +++++++++++++++
# iClk -> Clock Signal
# iRst -> Reset Signal
# iRX  -> Ansynchronous Receiver input Signals
# oTX  -> Ansynchronous Transmitter output Signals
# iData -> Data to write to the transmit-buffer
# WriteEnable -> Strobe this signal to write iData to the transmit-buffer  
(write addres is incremmented in the Module)
# oWrBuffer_full -> Indicates that the write buffer is full, if Data is  
written anyway it is ignored
# oData -> Output data at the read_addr of the receive-buffer
# read_addr -> address to read from the receive-buffer
# oRx_addr -> address where the next byte which will be received will be  
put into the receive buffer
# Clkfrequenz -> Constant which gives the frequency of iClk
# Baudrate -> Constant to set the Baudrate of the RS232 Module
# RX_BUFFER_LENGTH -> Constant, sets the receive-buffer size
# TX_BUFFER_LENGTH -> Constant, sets the transmit-buffer size
#
# Author: Norbert Feurle
# Last edit Date: 10.5.2012
# Licence: Only use it to do good, no garantie warranty

 from myhdl import *

def RS232_Module(iClk,iRst,iRX,oTX,  
iData,WriteEnable,oWrBuffer_full,oData,read_addr,oRx_addr,Clkfrequenz=12e6,Baudrate=38400,RX_BUFFER_LENGTH=8,TX_BUFFER_LENGTH=8):
     ##### Constants #####
     CounterCycle=int(Clkfrequenz/Baudrate)
     CounterCycle_half=int(Clkfrequenz/(Baudrate*2.0))

     ##### Signal definitions for Receiver Part ####
     Receive_RAM=[Signal(intbv(0)[8:]) for i in range(RX_BUFFER_LENGTH)]
     rx_counter=Signal(intbv(0,min=0,max=CounterCycle+2))
     rx_currentData=Signal(intbv(0)[9:])
     rx_bit_count=Signal(intbv(0,min=0,max=10))
     rx_addr=Signal(intbv(0,min=0,max=RX_BUFFER_LENGTH))
     rx_State=Signal(intbv(0,min=0,max=4))

     ##### Signal definitions for Transmitter Part ####
     Transmit_RAM=[Signal(intbv(0)[8:]) for i in range(TX_BUFFER_LENGTH)]
     tx_counter=Signal(intbv(0,min=0,max=CounterCycle+2))
     tx_bit_count=Signal(intbv(0,min=0,max=11))
     tx_addr=Signal(intbv(0,min=0,max=TX_BUFFER_LENGTH))
     write_addr=Signal(intbv(0,min=0,max=TX_BUFFER_LENGTH))
     tx_State=Signal(intbv(0,min=0,max=4))
     SendREG=Signal(intbv(0)[10:])

     @always_comb
     def comb_logic():
       if ((write_addr+1)%TX_BUFFER_LENGTH)==tx_addr:
	oWrBuffer_full.next=True
       else:
	oWrBuffer_full.next=False

     @always(iClk.posedge,iRst.negedge)
     def seq_logic():
       if iRst==0:
	###### Resets Receiver Part #####
	rx_State.next=0
	rx_counter.next=0
	rx_currentData.next=0
	rx_bit_count.next=0
	rx_addr.next=0
	oRx_addr.next=0
	
	###### Resets Transmitter Part #####
	tx_State.next=0
	tx_addr.next=0
	write_addr.next=0
	SendREG.next=0
	tx_counter.next=0
	tx_bit_count.next=0
       else:
	oRx_addr.next=rx_addr
	oData.next=Receive_RAM[read_addr]
	oTX.next=1
	
	################## Receiver Part ################
	if rx_State==0: #IDLE STATE
	  if iRX==0:
	    rx_counter.next=rx_counter+1
	  else:
	    rx_counter.next=0
	  if rx_counter==CounterCycle_half:
	    rx_State.next=1
	    rx_counter.next=0
	    rx_bit_count.next=0
	
	elif rx_State==1:  #RECEIVING STATE
	  rx_counter.next=rx_counter+1
	  if rx_counter==0:
	    rx_currentData.next=concat(iRX,rx_currentData[9:1])
	    rx_bit_count.next=rx_bit_count+1
	  if rx_counter==CounterCycle:
	    rx_counter.next=0
	  if rx_bit_count==9:
	    rx_State.next=2
	    rx_counter.next=0
	
	elif rx_State==2:  #STOPBIT STATE
	  rx_counter.next=rx_counter+1
	  if rx_counter==CounterCycle:
	    rx_State.next=0
	    rx_counter.next=0
	    if iRX==1: #Stopbit is Received
	      Receive_RAM[rx_addr].next=rx_currentData[9:1]
	      rx_addr.next=(rx_addr+1)%RX_BUFFER_LENGTH
	
	
	################## Transmitter Part ################
	#### Writing Data to Transmit Buffer ####
	#TODO Buffer full flag#
	if WriteEnable and (not oWrBuffer_full):
	  Transmit_RAM[write_addr].next=iData
	  write_addr.next=(write_addr+1)%TX_BUFFER_LENGTH
	
	#### Transmitting Statmachine ####
	if tx_State==0:
	  if write_addr!=tx_addr:
	    tx_counter.next=0
	    tx_State.next=1
	    tx_bit_count.next=0
	    SendREG.next=concat(intbv(1)[1:],Transmit_RAM[tx_addr],intbv(0)[1:])
	    tx_addr.next=(tx_addr+1)%TX_BUFFER_LENGTH
	elif tx_State==1: ### Send Bytes
	  oTX.next=SendREG[tx_bit_count]
	  tx_counter.next=tx_counter+1
	  if tx_counter==CounterCycle:
	    tx_bit_count.next=tx_bit_count+1
	    tx_counter.next=0
	    if tx_bit_count==9:
	      tx_State.next=0

     return seq_logic,comb_logic


def test_bench():
     ###### Constnats #####
     Clk_f=12e6 #12 Mhz
     BAUDRATE=38400

     ##### Signal definitions #####
     iData=Signal(intbv(0)[8:])
     oData=Signal(intbv(0)[8:])
     iClk=Signal(bool(0))
     iRst=Signal(bool(1))
     iRX=Signal(bool(1))
     oTX=Signal(bool(0))
     WriteEnable=Signal(bool(0))
     oWrBuffer_full=Signal(bool(0))
     read_addr=Signal(intbv(0,min=0,max=8))
     RX_BUFF_LEN=8
     rx_addr=Signal(intbv(0,min=0,max=RX_BUFF_LEN))

     ##### Instanziate RS232 Module #####
     rs232_instance=RS232_Module(iClk,iRst,iRX,oTX,  
iData,WriteEnable,oWrBuffer_full,oData,read_addr,rx_addr,Clkfrequenz=Clk_f,Baudrate=BAUDRATE,RX_BUFFER_LENGTH=RX_BUFF_LEN)
     toVHDL(RS232_Module,iClk,iRst,iRX,oTX,  
iData,WriteEnable,oData,read_addr,rx_addr,Clkfrequenz=Clk_f,Baudrate=BAUDRATE,RX_BUFFER_LENGTH=RX_BUFF_LEN)

     interval = delay(10)
     @always(interval)
     def clk_gen():
       iClk.next=not iClk

     @always_comb
     def rs232loopback():
	iRX.next=oTX

     def Write_to_rs232_send_buffer(value):
       yield iClk.posedge
       iData.next=value
       if oWrBuffer_full:
	print "Value:",value,"\tNot written, RS232 Transmittbuffer has indiciated  
to be allready full. (by oWrBuffer_full)"

       WriteEnable.next=1
       yield iClk.posedge
       WriteEnable.next=0

     def TestTransmitReceive(testARRAY):
       #### Write some Bytes to the Sendbuffer #####
       for data in testARRAY:
	yield Write_to_rs232_send_buffer(data)

       #### wait until data is received #####
       count=0
       currentArryPos=0
       while 1:
	yield iClk.posedge
	yield delay(0)
	count=count+1
	if rx_addr!=read_addr:
	  count=0
	  print "RXData:", oData,"\tTXData:",testARRAY[currentArryPos],  
"\t\tBuffer Address:",read_addr
	  assert testARRAY[currentArryPos]==oData
	  currentArryPos=currentArryPos+1
	  read_addr.next=(read_addr+1)%RX_BUFF_LEN
	
	#if Nothing is received for six possible complete RS232 transmissions
	# (8+2) means 8 Bits + 1 Startbit + 1 Stopbit
         if count>((Clk_f*1.0/BAUDRATE)*(8+2)*6):
           if not (currentArryPos==len(testARRAY)):
	    print "Warning: Not all values of the Array have been received (Check  
if Transmittbuffer was full)"
	    print "Missing Data is:", testARRAY[currentArryPos:]
           break

     @instance
     def stimulus():
       #### Reseting #####
       iRst.next=1
       yield delay(50)
       iRst.next=0
       yield delay(50)
       iRst.next=1
       yield delay(50)

       #### Some Test Data ####
       testARRAY=[0x55,0xAA,0xff,0,1,128,0xef,0xfe]
       print
       print "Running Test Array:",testARRAY
       print "#"*50
       yield TestTransmitReceive(testARRAY)

       #### Some Test Data ####
       testARRAY=[8,4,5,2,1,0]
       print
       print "Running Test Array:",testARRAY
       print "#"*50
       yield TestTransmitReceive(testARRAY)

       #### Some Test Data ####
       testARRAY=[255,254,253,251]
       print
       print "Running Test Array:",testARRAY
       print "#"*50
       yield TestTransmitReceive(testARRAY)


       #### Reseting #####
       iRst.next=1
       yield delay(50)
       iRst.next=0
       yield delay(50)
       iRst.next=1
       yield delay(50)

       ### artificial reset of read_addr ####
       read_addr.next=0

       #### Some Test Data ####
       testARRAY=[0x55,0xAA,0xff,0,1,128,0xef,0xfe,8,89,55]
       print
       print "Running Test Array:",testARRAY
       print "#"*50
       yield TestTransmitReceive(testARRAY)

       print
       print "End of Simulation, simulation succesfull!"
       raise StopSimulation

     return  clk_gen,rs232loopback,stimulus,rs232_instance#,Monitor_oTX


#tb = traceSignals(test_bench)
#sim= Simulation(tb)
sim = Simulation(test_bench())
sim.run()


greetings
Norbo

Re: [myhdl-list] FPGA meetup NYC

[David G. <dsg...@gm...>]

I am going! :)

I would love to meet MyHDL users in person!

This first session is geared toward talking about how we manage our flows,
which should provide ample opportunities to highlight the benefits of using
a full-powered language like Python/MyHDL instead of using a mix of
SystemC, VHDL, Perl, bash, and makefiles.

On Thu, May 10, 2012 at 8:12 AM, Christopher Felton
<chr...@gm...>wrote:

> Anyone in NYC or surrounding area might want to checkout the FPGA meetup
> group.  They have MyHDL listed as one of the interests!
>
> http://www.meetup.com/The-New-York-FPGA-Users-Group/
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] FPGA meetup NYC

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

Anyone in NYC or surrounding area might want to checkout the FPGA meetup 
group.  They have MyHDL listed as one of the interests!

http://www.meetup.com/The-New-York-FPGA-Users-Group/

Regards,
Chris

[myhdl-list] They forgot to include MyHDL!

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

http://www.aldec.com/en/company/news/2012-05-09/114

"""
The Aldec survey results revealed that, despite the excitement around 
SystemVerilog ... stick with VHDL; for a variety of technical, 
logistical and financial reasons.
"""

"""
“We’re increasingly encountering designers, working in VHDL, that are 
dealing with bigger and bigger designs. They appreciate the benefits of 
migrating to SystemVerilog but for some it’s too big a leap to make.”
"""

Only if they knew.

"""
Of the 2,400+ surveyed, 53% indicated they would be using VHDL (in 
isolation or in combination with another language). The other languages 
scored: Verilog (31%), SystemVerilog (32%), SystemC (11%), and C/C++ 
(23%); noting that the multiple-choice aspect means the total is more 
than 100%.
"""

Don't think a survey like this can truly represent the majority of HDL 
users.  One, I don't believe they accessed designers outside their tool 
base (i.e. participants were Aldec users).  I am not a stats guru but 
this smells of percent error >= 5.

Regards,
Chris

Re: [myhdl-list] conversion to case statement - odd behaviour?

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

On 10/05/12 03:14, Christopher Felton wrote:
>
> I reproduced your post and have encapsulated in a small example (can
> provide if needed).  But what I don't know is if this is bad or not.  Or
> if it is unintended conversion behavior.  It the converted code with the
> mix of if-else and case should synthesize fine (functionally equivalent)
> but I don't know if it is optimal for synthesis or not.

Thanks Chris, all help much appreciated. I was not concerned as 
this initially only seemed cosmetic, however, I have tried some 
further permutations, using enum, and separating the result latch. 
  Attached is the source and resulting Verilog files for each 
combination.  The one that interests me most will not convert:

jan@T60:~/work/projects/MyHDL/igloo-tests/SnL_58_LshiftLoadInvertRshift$ 
./test_SnL_58.py
<class 'myhdl._SuspendSimulation'>: Simulated 15000 timesteps
Traceback (most recent call last):
   File "./test_SnL_58.py", line 62, in <module>
     toVerilog(SnL_58, LEDs,PB_SW,DIP_SW, clk_20MHz,10000)
   File 
"/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_toVerilog.py", 
line 142, in __call__
     genlist = _analyzeGens(arglist, h.absnames)
   File 
"/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_analyze.py", 
line 165, in _analyzeGens
     _isMem(obj) or _isTupleOfInts(obj)
AssertionError
jan@T60:~/work/projects/MyHDL/igloo-tests/SnL_58_LshiftLoadInvertRshift$ 


I also have this problem in my main project, so getting a small 
example was a lucky catch.

Jan Coombs

Re: [myhdl-list] conversion to case statement - odd behaviour?

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

On 4/30/12 6:12 AM, Jan Coombs wrote:
> In this code the first condition is separated into a separate 'if'
> with the 'elif' lines becoming part of a verilog case statement:
>
>     @always(keyDBclk.posedge)
>     def ledLatchLogic():
>       ''' connect push button event to action '''
>       if   keyEventPB_SW==1:  ledLatch.next = ledLatch>>1
>       elif keyEventPB_SW==2:  ledLatch.next = ~ledLatch
>       elif keyEventPB_SW==4:  ledLatch.next = ~DIP_SW
>       elif keyEventPB_SW==8:  ledLatch.next = (ledLatch<<1)&  255
>       else:                   ledLatch.next = ledLatch
>
> I have tried reversing the order of bit selection, and without the
> 'else'/'default' clause.
>
> Jan Coombs
>
>

I reproduced your post and have encapsulated in a small example (can 
provide if needed).  But what I don't know is if this is bad or not.  Or 
if it is unintended conversion behavior.  It the converted code with the 
mix of if-else and case should synthesize fine (functionally equivalent) 
but I don't know if it is optimal for synthesis or not.

Regards,
Chris

Re: [myhdl-list] Actel/Microsemi IGLOO nano starter kit

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

On 5/2/12 2:52 AM, Jan Coombs wrote:
> I have a number of MyHDL projects which build source files for
> demos on this low power FPGA card, and would be happy to share
> these.  Card detail:
>
> http://www.actel.com/products/hardware/devkits_boards/igloonano_starter.aspx
>
> They include access to switches and LEDs on the board, and the
> source for a UART for linking the card to a host PC.
>
> Next, I moving on to testing the block RAMs, then building a
> complex processor cache.  Anyone been there before?
>
> Jan Coombs

Depends on what you mean by complex processor cache.  A processor cache 
design can be complex enough that it could chew up a substantial 
resources.  I do have a small (probably incomplete) example using BRAM 
in a MyHDL clone of the ZPU.

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

The stuff on the wiki is probably out of date.  I can upload my latest 
to a BitBucket repo if needed.

Also, another user has a MyHDL clone of the Microblaze in MyHDL dubbed 
*myblaze) and it is on open-cores.

http://opencores.org/project,myblaze

These might be some useful resources.

Regards,
Chris