myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

[Robert P. <bpe...@xt...>]

Jan,
Thank you for your reply.  I don't want to confuse how I use the word
module.  A circuit module, like an op-amp or A/D converter is also known as
a circuit block.  Let me refer to it in this discussion as a circuit block.
So we write a MyHDL model of an Op-Amp circuit block, and that model
contains a module for its digital controls (like PowerDown) and separate
modules for its bias, power supply and signal inputs?
Bob P.


-----Original Message-----
From: Jan Decaluwe [mailto:ja...@ja...] 
Sent: Thursday, January 22, 2015 4:08 PM
To: myh...@li...
Subject: Re: [myhdl-list] Is there something in MyHDL equivalent to
Verilog's OOMR?

On 01/21/2015 11:45 PM, Robert Peruzzi wrote:

> MyHDL is the tool of choice of my new client - for digital design and 
> verification.  My task is to use MyHDL for modeling analog and 
> mixed-signal blocks, and tie them into a full chip and its testbench.
> To do so, I need to find the MyHDL equivalent of Verilog's "out of 
> module reference" (OOMR).  After a few hours searching, I have not 
> found it.

Assuming the signals are special so that you can plan for them, you could
put them in a separate module, and import that module wherever you need
those signals.

Jan

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


----------------------------------------------------------------------------
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

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

On 01/21/2015 11:45 PM, Robert Peruzzi wrote:

> MyHDL is the tool of choice of my new client – for digital design and
> verification.  My task is to use MyHDL for modeling analog and
> mixed-signal blocks, and tie them into a full chip and its testbench.
> To do so, I need to find the MyHDL equivalent of Verilog’s “out of
> module reference” (OOMR).  After a few hours searching, I have not
> found it.

Assuming the signals are special so that you can plan for them,
you could put them in a separate module, and import that module
wherever you need those signals.

Jan

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

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

[Robert P. <bpe...@xt...>]

Chris,
Nice sine generator.  Similar approach to mine using Verilog.  Is there a
way to conduct that signal into a discrete-time analog processing block that
for example, multiplies its input by two?  In Verilog-AMS, in
continuous-time analog that would be 
	V(Vout) <+ 2.0 * V(Vin);

In Verilog, in discrete-time analog using OOMR, that would be something like
	assign ASCLK = TOP.SG.ASCLK_OOMR;
               always @(posedge ASCLK) begin
                   VIN_OOMR = TOP.SG.VSIG_OOMR;
                   Vout = 2.0 * VIN_OOMR;
               end	

-----Original Message-----
From: Christopher Felton [mailto:chr...@gm...] 
Sent: Thursday, January 22, 2015 11:40 AM
To: myh...@li...
Subject: Re: [myhdl-list] Is there something in MyHDL equivalent to
Verilog's OOMR?

On 1/21/2015 4:45 PM, Robert Peruzzi wrote:
> Today I heard the word "MyHDL" for the first time!
<snip>
>  Verilog, unlike VHDL, has no concept of real ports or wires, so I 
> write the module receiving the analog signal to look inside the source
module via OOMR.
>

Note, if you are modeling in Python/MyHDL there are no limitations on the
ports.  The OOMR type approach is probably not what you want in this case.
This is a very important point, if you are modeling you have lot of
flexibility!

I put together a simple example:
http://nbviewer.ipython.org/github/cfelton/musicbox_simple/blob/master/analo
g_model.ipynb

If you use object for all your models you can access all the object
attributes just like OOMR.

Regards,
Chris





----------------------------------------------------------------------------
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

[Robert P. <bpe...@xt...>]

Chris,
Email collision.  I didn't see this, which arrived just before I hit "Send"
a moment ago.  
Thanks,
Bob P.

-----Original Message-----
From: Christopher Felton [mailto:chr...@gm...] 
Sent: Thursday, January 22, 2015 11:40 AM
To: myh...@li...
Subject: Re: [myhdl-list] Is there something in MyHDL equivalent to
Verilog's OOMR?

On 1/21/2015 4:45 PM, Robert Peruzzi wrote:
> Today I heard the word "MyHDL" for the first time!
<snip>
>  Verilog, unlike VHDL, has no concept of real ports or wires, so I 
> write the module receiving the analog signal to look inside the source
module via OOMR.
>

Note, if you are modeling in Python/MyHDL there are no limitations on the
ports.  The OOMR type approach is probably not what you want in this case.
This is a very important point, if you are modeling you have lot of
flexibility!

I put together a simple example:
http://nbviewer.ipython.org/github/cfelton/musicbox_simple/blob/master/analo
g_model.ipynb

If you use object for all your models you can access all the object
attributes just like OOMR.

Regards,
Chris





----------------------------------------------------------------------------
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

[Robert P. <bpe...@xt...>]

Chris, Uri, anyone else interested,

 

Here is what I do in plain Verilog to transport an analog signal from block
to block;

 

Hierarchical path from top level to the signal generator:

               TOP.SG

Real variable VSIG_OOMR is the stimulus signal.  The module has an INOUT
port named VSIG which in this model is used for hand-shaking with the signal
receiver.

The signal generator also creates an analog sample clock

reg ASCLK_OOMR;

There is no ASCLK_OOMR port or wire. It is a fictitious clock, and is
accessed via OOMR from the signal receiver.

 


Hierarchical path from top level to the signal receiver:

               TOP.AFE

The AFE module has an INOUT port named VIN which in this module is used for
hand-shaking with the signal generator.

The AFE module has a real variable VIN_OOMR which is gets its analog input
using this snippet of code

               assign ASCLK = TOP.SG.ASCLK_OOMR;

               .

               always @(posedge ASCLK) begin

                   VIN_OOMR = TOP.SIG.VSIG_OOMR;

               .

               end

               .

 

Within the AFE module, discrete-time analog signal processing is done at the
ASCLK rate on VIN_OOMR

 

Now, is there an equivalent to this in MyHDL?  I believe I can do
discrete-time analog signal processing on real variables within a MyHDL
model.  Correct?

 

The question is, can I grab a real or logic variable value from a different
MyHDL instantiation?

Thanks!

Bob P.

 

 

 

 

-----Original Message-----
From: Christopher Felton [mailto:chr...@gm...] 
Sent: Wednesday, January 21, 2015 7:53 PM
To: myh...@li...
Subject: Re: [myhdl-list] Is there something in MyHDL equivalent to
Verilog's OOMR?

 

On 1/21/2015 4:45 PM, Robert Peruzzi wrote:

> Today I heard the word "MyHDL" for the first time!

<snip>

> 

> Is there something in MyHDL equivalent to OOMR?  What is it called?

 

The short answer is no.

 

But I am not sure I exactly follow what you want to do.  Do you want to
access signals/variables in the Python/MyHDL environment?  Or do you want to
dig down into the Verilog simulation from Python/MyHDL (cosimulation)?

 

If it is the first, there might be a simple utility function you can build
to do what you want.

 

If it is that later, no tool exists to support this.

You can manually export (import?) each signal to the Python environment.

 

Regards,

Chris Felton

 

 

 

 

 

----------------------------------------------------------------------------
--

New Year. New Location. New Benefits. New Data Center in Ashburn, VA.

GigeNET is offering a free month of service with a new server in Ashburn.

Choose from 2 high performing configs, both with 100TB of bandwidth.

Higher redundancy.Lower latency.Increased capacity.Completely compliant.

 <http://p.sf.net/sfu/gigenet> http://p.sf.net/sfu/gigenet

_______________________________________________

myhdl-list mailing list

 <mailto:myh...@li...> myh...@li...

 <https://lists.sourceforge.net/lists/listinfo/myhdl-list>
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

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

On 1/21/2015 4:45 PM, Robert Peruzzi wrote:
> Today I heard the word "MyHDL" for the first time!
<snip>
>  Verilog, unlike VHDL, has no concept of real ports or wires, so I write the module
> receiving the analog signal to look inside the source module via OOMR.
>

Note, if you are modeling in Python/MyHDL there
are no limitations on the ports.  The OOMR type
approach is probably not what you want in this
case.  This is a very important point, if you
are modeling you have lot of flexibility!

I put together a simple example:
http://nbviewer.ipython.org/github/cfelton/musicbox_simple/blob/master/analog_model.ipynb

If you use object for all your models you can
access all the object attributes just like OOMR.

Regards,
Chris

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

[Robert P. <bpe...@xt...>]

Thank you, Uri.  This isn’t exactly what I’m doing, but it may hold clues to a solution.

Bob P.

 

 

From: Uri Nix [mailto:ur...@gm...] 
Sent: Thursday, January 22, 2015 9:52 AM
To: General discussions on MyHDL
Subject: Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

 

Hi Robert,

 

Might be relevant: http://old.myhdl.org/doku.php/projects:mixedmodesimulation

 

Cheers,

Uri

 

On 22 January 2015 at 00:45, Robert Peruzzi <bpe...@xt... <mailto:bpe...@xt...> > wrote:

Today I heard the word “MyHDL” for the first time!  

 

MyHDL is the tool of choice of my new client – for digital design and verification.  My task is to use MyHDL for modeling analog and mixed-signal blocks, and tie them into a full chip and its testbench.  To do so, I need to find the MyHDL equivalent of Verilog’s “out of module reference” (OOMR).  After a few hours searching, I have not found it.  I hope you will take the time to help. Here’s a quick explanation.

 

Modeling a signal flow of voltages or currents is sufficient for high-level verification, as opposed to modeling physically conservative networks obeying Kirchhoff’s laws.  Many times I use ordinary Verilog for models and Icarus for simulations.  An analog “source” model for analog signals uses a fictitious sampling clock with impossibly high sampling rate to create a sequence of real values on a real variable inside that model.  Verilog, unlike VHDL, has no concept of real ports or wires, so I write the module receiving the analog signal to look inside the source module via OOMR.  

 

Using this OOMR approach, the analog signal flows from a source through, say, an amplifier, then a filter, to an analog-to-digital converter.  The ports and wires of the netlist cannot conduct the analog signal so they may be separately used for verifying continuity.

 

Is there something in MyHDL equivalent to OOMR?  What is it called?  

 

Thank you very much.

 

Robert Peruzzi

Principal Engineer

XtremeEDA

Direct: +1 610 462 3939 <tel:%2B1%20610%20462%203939> 

BPe...@Xt... <mailto:BPe...@Xt...> 

 

 


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
myhdl-list mailing list
myh...@li... <mailto:myh...@li...> 
https://lists.sourceforge.net/lists/listinfo/myhdl-list

 

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

[Robert P. <bpe...@xt...>]

Thank you for responding, Chris.
Bob P.

-----Original Message-----
From: Christopher Felton [mailto:chr...@gm...] 
Sent: Wednesday, January 21, 2015 7:53 PM
To: myh...@li...
Subject: Re: [myhdl-list] Is there something in MyHDL equivalent to
Verilog's OOMR?

On 1/21/2015 4:45 PM, Robert Peruzzi wrote:
> Today I heard the word "MyHDL" for the first time!
<snip>
>
> Is there something in MyHDL equivalent to OOMR?  What is it called?

The short answer is no.

But I am not sure I exactly follow what you want to do.  Do you want to
access signals/variables in the Python/MyHDL environment?  Or do you want to
dig down into the Verilog simulation from Python/MyHDL (cosimulation)?

If it is the first, there might be a simple utility function you can build
to do what you want.

If it is that later, no tool exists to support this.
You can manually export (import?) each signal to the Python environment.

Regards,
Chris Felton





----------------------------------------------------------------------------
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

[Uri N. <ur...@gm...>]

Hi Robert,

Might be relevant:
http://old.myhdl.org/doku.php/projects:mixedmodesimulation

Cheers,
Uri

On 22 January 2015 at 00:45, Robert Peruzzi <bpe...@xt...> wrote:

> Today I heard the word “MyHDL” for the first time!
>
>
>
> MyHDL is the tool of choice of my new client – for digital design and
> verification.  My task is to use MyHDL for modeling analog and mixed-signal
> blocks, and tie them into a full chip and its testbench.  To do so, I need
> to find the MyHDL equivalent of Verilog’s “out of module reference”
> (OOMR).  After a few hours searching, I have not found it.  I hope you will
> take the time to help. Here’s a quick explanation.
>
>
>
> Modeling a signal flow of voltages or currents is sufficient for
> high-level verification, as opposed to modeling physically conservative
> networks obeying Kirchhoff’s laws.  Many times I use ordinary Verilog for
> models and Icarus for simulations.  An analog “source” model for analog
> signals uses a fictitious sampling clock with impossibly high sampling rate
> to create a sequence of real values on a real variable inside that model.
> Verilog, unlike VHDL, has no concept of real ports or wires, so I write the
> module receiving the analog signal to look inside the source module via
> OOMR.
>
>
>
> Using this OOMR approach, the analog signal flows from a source through,
> say, an amplifier, then a filter, to an analog-to-digital converter.  The
> ports and wires of the netlist cannot conduct the analog signal so they may
> be separately used for verifying continuity.
>
>
>
> Is there something in MyHDL equivalent to OOMR?  What is it called?
>
>
>
> Thank you very much.
>
>
>
> Robert Peruzzi
>
> Principal Engineer
>
> XtremeEDA
>
> Direct: +1 610 462 3939
>
> BPe...@Xt...
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

Re: [myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

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

On 1/21/2015 4:45 PM, Robert Peruzzi wrote:
> Today I heard the word "MyHDL" for the first time!
<snip>
>
> Is there something in MyHDL equivalent to OOMR?  What is it called?

The short answer is no.

But I am not sure I exactly follow what you want
to do.  Do you want to access signals/variables in
the Python/MyHDL environment?  Or do you want to
dig down into the Verilog simulation from
Python/MyHDL (cosimulation)?

If it is the first, there might be a simple utility
function you can build to do what you want.

If it is that later, no tool exists to support this.
You can manually export (import?) each signal to
the Python environment.

Regards,
Chris Felton

[myhdl-list] Is there something in MyHDL equivalent to Verilog's OOMR?

[Robert P. <bpe...@xt...>]

Today I heard the word "MyHDL" for the first time!  

 

MyHDL is the tool of choice of my new client - for digital design and
verification.  My task is to use MyHDL for modeling analog and mixed-signal
blocks, and tie them into a full chip and its testbench.  To do so, I need
to find the MyHDL equivalent of Verilog's "out of module reference" (OOMR).
After a few hours searching, I have not found it.  I hope you will take the
time to help. Here's a quick explanation.

 

Modeling a signal flow of voltages or currents is sufficient for high-level
verification, as opposed to modeling physically conservative networks
obeying Kirchhoff's laws.  Many times I use ordinary Verilog for models and
Icarus for simulations.  An analog "source" model for analog signals uses a
fictitious sampling clock with impossibly high sampling rate to create a
sequence of real values on a real variable inside that model.  Verilog,
unlike VHDL, has no concept of real ports or wires, so I write the module
receiving the analog signal to look inside the source module via OOMR.  

 

Using this OOMR approach, the analog signal flows from a source through,
say, an amplifier, then a filter, to an analog-to-digital converter.  The
ports and wires of the netlist cannot conduct the analog signal so they may
be separately used for verifying continuity.

 

Is there something in MyHDL equivalent to OOMR?  What is it called?  

 

Thank you very much.

 

Robert Peruzzi

Principal Engineer

XtremeEDA

Direct: +1 610 462 3939

BPe...@Xt... <mailto:BPe...@Xt...> 

 

 

Re: [myhdl-list] reusable blocks with different interfaces

[Josy B. <jos...@gm...>]

> <snip>

I managed to publish the VHDL code (and Quartus project) on Github. Enjoy ;)

Regards,

Josy

Re: [myhdl-list] reusable blocks with different interfaces

[Josy B. <jos...@gm...>]

Keerthan JC <jckeerthan <at> gmail.com> writes:

> 
> VHDL records are not isomorphic to python objects or SV interfaces. A
> VHDL record is similar to a SV struct.
> There is no general way to convert MyHDL interfaces to VHDL records.
> The way conversion currently works, you can think of attribute
> references as pointers to Signals rather than Interface objects being
> special datatypes.
> 
> wrt qsys, I don't understand how records simplify qsys components.
> Could you share some example code with me?
> <snip>

I'm *not* looking to convert MyHDL interfaces into VHDL records. You keep 
hanging on to that idea, but I never said so. My original question was:
Say we have used an interface in MyHDL to model a structured type in a 
module. The module will have to be usable both for import in other MyHDL 
modules, but also as a standalone component in Qsys. The interface works 
fine inside MyHDL. But we need to flatten this interface to a 
std_logic_vector for Qsys. Similar what a I do when using VHDL records: I 
write to_std_logic_vector( record_type_x r) and to_record_type_x( 
std_logic_vector v) functions. That was essentially my question in my first 
follow-up in this thread. I repeat it here:
<quote>
It would be nice if we also had a 'magic' way to export / import the 
interfaces as a std_logic_vector. As this is what Altera's Qsys 
understand. I doubt that Xilinx' IP Integrator will be any smarter.
</quote>
Perhaps I should have specified that it was about the *data* signal proper, 
not the global Sink or Source.
I have written several dozen Qsys components in VHDL and MyHDL and have 
done a mid-size MyHDL project using a Support Vector Machine (6700 lines of 
generated VHDL).

I'll post code on Github, later ...

Best regards,

Josy

Re: [myhdl-list] reusable blocks with different interfaces

[Keerthan JC <jck...@gm...>]

VHDL records are not isomorphic to python objects or SV interfaces. A
VHDL record is similar to a SV struct.
There is no general way to convert MyHDL interfaces to VHDL records.
The way conversion currently works, you can think of attribute
references as pointers to Signals rather than Interface objects being
special datatypes.

wrt qsys, I don't understand how records simplify qsys components.
Could you share some example code with me?

On Tue, Jan 20, 2015 at 5:11 PM, Josy Boelen <jos...@gm...> wrote:
> Jan Decaluwe <jan <at> jandecaluwe.com> writes:
>
>>
>> On 01/19/2015 10:23 PM, Josy Boelen wrote:
>> > Christopher Felton <chris.felton <at> gmail.com> writes:
>> >
>> >>
>> >> <snip>
>> >>> Henry is talking about extending the interfaces concept of MyHDL.
>> > When
>> >>> converted to VHDL this would result in having structured types
> (e.g.
>> > a
>> >>> record) as ports.
>> >>
>> >> I don't think supporting conversion to VHDL records
>> >> would be a good idea.  Then the Verilog and VHDL
>> >> conversions would diverge.
>> >>
>> >> I don't believe I understand the use case?  Is this
>> >> intended to simplify wiring up modules (components)
>> >> after conversion?
>> >>
>> >> Regards,
>> >> Chris
>> >> <snip>
>> >
>> > Apparently I have a problem explaining things (and may now mess it
> up
>> > even more):
>> >
>> > If we elaborate on the interfaces concept, we can have interfaces
> (which
>> > I see as kind of records in records) nicely connecting up in MyHDL.
>> > Eventually we have to convert into VHDL and integrate it in our top
>> > level project. Now, in the Altera-world some we have Qsys to make
> live
>> > easy. Except that Qsys only understands std_logic and
> std_logic_vector.
>> > Say we now define an interface in MyHDL to represent a structured
> type
>> > we have to write a to_std_logic_vector() and a to_myinterface() (as
> I
>> > now do in VHDL whenever a define a record)  function to 'map' the
> one to
>> > the other and back. My expectation is that this could be handled
>> > automagically. This would save us from writing those 'wrapper
> modules'
>> > to use MyHDL originated modules with 'interfaces' in order to use
> them
>> > with Qsys (or Xilinx' IP Integrator?).
>> >
>> > Keeping VHDL on a leash to please Verilog is, IMHO, hampering
> MyHDL's
>> > progress and adoption. Maybe it is time to start a
> to_SystemVerilog() at
>> > the same time expanding to_VHDL()?
>>
>> First, I am not following the logic in this post, and second, I don't
>> agree at all.
>>
>> You say we "keep VHDL on a leash to please Verilog". But in the
>> paragraph before, you seem to ask for a MyHDL solution to work around
>> a VHDL, or at least a VHDL tool, limitation. That seems "pleasing
> VHDL"
>> to me.
>>
>> Second, I don't see how MyHDL is limited by Verilog. It definitely is
>> limited by development time, that is for sure. But what you seem to
>> forget is that there are significant points where it improves both
>> on VHDL and Verilog. Integer handling, of course. Embedded scripting
>> can be just great.
>>
>> It is not necessarily a good idea to support "more advanced" concepts
>> in the target language directly. For example:
>> VDHL has records, Verilog does not. Does this limit MyHDL? No -
> records
>> are themselves too limited, e.g. you cannot mix in/out in with the
>> same record. A more general concept, such as interfaces in MyHDL 0.9,
>> is much better I believe. And we can support that without requiring
>> something similar in the target language! How can that be bad?
>>
>> How can assuming as little as possible from Verilog/VHDL hamper
> adoption?
>> The contrary must be true. Suppose we drop Verilog. The possible user
>> base drops immediately with more than half, and it is the half that
>> needs a more sensible solution most, and also the half that makes
>> the biggest chips and has most money. How can that be a good idea?
>>
>> Let me be clear and honest: "adoption" for me means commericial
>> adoption. The kind of adoption that pays the bills. That has not
>> happened yet, at least not on the scale that satisfies me. (I am
>> jealous on everyone who can use MyHDL in current projects, but
>> lately that has not been my case. Doing interesting projects
>> though.) I cannot understand how limiting the target language
>> or putting constraints on it can bring me close to that goal -
>> I am not going to attract Google or Apple's interest by
>> concentrating on VHDL.
>>
>> Jan
>>
>
> Obviously I conveyed my message wrong, but then I'm not that good a
> writer.
> First of all I'm big fan of MyHDL (I know you know.) I have mentally
> switched to MyHDL and started using it for our in-house
> projects/modules.
> But I see ways of improving MyHDL, some of them may perhaps be me-
> centered, but some of them will improve MyHDL's adoption.
>
> In one of the other messages I make my case for 2D (and even more-D)
> support. Python, and thus MyHDL's simulator, handles this perfectly but
> it doesn't convert. I assumed this was a limitation because it cannot be
> converted to Verilog because it is not handled (well) by Verilog as VHDL
> has no issue with this. If a true 2D-type cannot be converted to Verilog
> then there would be a case to expand the to_VHDL functionality, and a
> case for a to_SystemVerilog() module. Yes, that may leave Verilog users
> behind, but they would not loose any features. If I suggested on
> dropping Verilog (did I?) please accept my apologies.
>
> The other 'thread' is that interfaces certainly are what we want to use,
> but the FPGA tools only handle 'simple' types. So it would be nice if we
> could arrange the mapping when converting a top-level MyHDL module for
> use with those FPGA tools (saving us from writing wrappers to do this,
> as we currently have to). Maybe I'll have to accommodate that in another
> MyHDL support utility?
>
> Once again, I'm not a good writer, and this kind of 'thinking aloud'
> doesn't go well on paper. Perhaps we should find a reason to meet and
> enjoy a 'Mort Subite'?
>
> Best regards,
>
> Josy
>
>
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list



-- 
have a nice day
-jck

Re: [myhdl-list] reusable blocks with different interfaces

[Josy B. <jos...@gm...>]

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

> 
> On 01/19/2015 10:23 PM, Josy Boelen wrote:
> > Christopher Felton <chris.felton <at> gmail.com> writes:
> >
> >>
> >> <snip>
> >>> Henry is talking about extending the interfaces concept of MyHDL.
> > When
> >>> converted to VHDL this would result in having structured types 
(e.g.
> > a
> >>> record) as ports.
> >>
> >> I don't think supporting conversion to VHDL records
> >> would be a good idea.  Then the Verilog and VHDL
> >> conversions would diverge.
> >>
> >> I don't believe I understand the use case?  Is this
> >> intended to simplify wiring up modules (components)
> >> after conversion?
> >>
> >> Regards,
> >> Chris
> >> <snip>
> >
> > Apparently I have a problem explaining things (and may now mess it 
up
> > even more):
> >
> > If we elaborate on the interfaces concept, we can have interfaces 
(which
> > I see as kind of records in records) nicely connecting up in MyHDL.
> > Eventually we have to convert into VHDL and integrate it in our top
> > level project. Now, in the Altera-world some we have Qsys to make 
live
> > easy. Except that Qsys only understands std_logic and 
std_logic_vector.
> > Say we now define an interface in MyHDL to represent a structured 
type
> > we have to write a to_std_logic_vector() and a to_myinterface() (as 
I
> > now do in VHDL whenever a define a record)  function to 'map' the 
one to
> > the other and back. My expectation is that this could be handled
> > automagically. This would save us from writing those 'wrapper 
modules'
> > to use MyHDL originated modules with 'interfaces' in order to use 
them
> > with Qsys (or Xilinx' IP Integrator?).
> >
> > Keeping VHDL on a leash to please Verilog is, IMHO, hampering 
MyHDL's
> > progress and adoption. Maybe it is time to start a 
to_SystemVerilog() at
> > the same time expanding to_VHDL()?
> 
> First, I am not following the logic in this post, and second, I don't
> agree at all.
> 
> You say we "keep VHDL on a leash to please Verilog". But in the
> paragraph before, you seem to ask for a MyHDL solution to work around
> a VHDL, or at least a VHDL tool, limitation. That seems "pleasing 
VHDL"
> to me.
> 
> Second, I don't see how MyHDL is limited by Verilog. It definitely is
> limited by development time, that is for sure. But what you seem to
> forget is that there are significant points where it improves both
> on VHDL and Verilog. Integer handling, of course. Embedded scripting
> can be just great.
> 
> It is not necessarily a good idea to support "more advanced" concepts
> in the target language directly. For example:
> VDHL has records, Verilog does not. Does this limit MyHDL? No - 
records
> are themselves too limited, e.g. you cannot mix in/out in with the
> same record. A more general concept, such as interfaces in MyHDL 0.9,
> is much better I believe. And we can support that without requiring
> something similar in the target language! How can that be bad?
> 
> How can assuming as little as possible from Verilog/VHDL hamper 
adoption?
> The contrary must be true. Suppose we drop Verilog. The possible user
> base drops immediately with more than half, and it is the half that
> needs a more sensible solution most, and also the half that makes
> the biggest chips and has most money. How can that be a good idea?
> 
> Let me be clear and honest: "adoption" for me means commericial
> adoption. The kind of adoption that pays the bills. That has not
> happened yet, at least not on the scale that satisfies me. (I am
> jealous on everyone who can use MyHDL in current projects, but
> lately that has not been my case. Doing interesting projects
> though.) I cannot understand how limiting the target language
> or putting constraints on it can bring me close to that goal -
> I am not going to attract Google or Apple's interest by
> concentrating on VHDL.
> 
> Jan
> 

Obviously I conveyed my message wrong, but then I'm not that good a 
writer.
First of all I'm big fan of MyHDL (I know you know.) I have mentally 
switched to MyHDL and started using it for our in-house 
projects/modules. 
But I see ways of improving MyHDL, some of them may perhaps be me-
centered, but some of them will improve MyHDL's adoption.

In one of the other messages I make my case for 2D (and even more-D) 
support. Python, and thus MyHDL's simulator, handles this perfectly but 
it doesn't convert. I assumed this was a limitation because it cannot be 
converted to Verilog because it is not handled (well) by Verilog as VHDL 
has no issue with this. If a true 2D-type cannot be converted to Verilog 
then there would be a case to expand the to_VHDL functionality, and a 
case for a to_SystemVerilog() module. Yes, that may leave Verilog users 
behind, but they would not loose any features. If I suggested on 
dropping Verilog (did I?) please accept my apologies.

The other 'thread' is that interfaces certainly are what we want to use, 
but the FPGA tools only handle 'simple' types. So it would be nice if we 
could arrange the mapping when converting a top-level MyHDL module for 
use with those FPGA tools (saving us from writing wrappers to do this, 
as we currently have to). Maybe I'll have to accommodate that in another 
MyHDL support utility?

Once again, I'm not a good writer, and this kind of 'thinking aloud' 
doesn't go well on paper. Perhaps we should find a reason to meet and 
enjoy a 'Mort Subite'?

Best regards,

Josy

Re: [myhdl-list] reusable blocks with different interfaces

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

On 01/19/2015 10:23 PM, Josy Boelen wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
>> <snip>
>>> Henry is talking about extending the interfaces concept of MyHDL.
> When
>>> converted to VHDL this would result in having structured types (e.g.
> a
>>> record) as ports.
>>
>> I don't think supporting conversion to VHDL records
>> would be a good idea.  Then the Verilog and VHDL
>> conversions would diverge.
>>
>> I don't believe I understand the use case?  Is this
>> intended to simplify wiring up modules (components)
>> after conversion?
>>
>> Regards,
>> Chris
>> <snip>
>
> Apparently I have a problem explaining things (and may now mess it up
> even more):
>
> If we elaborate on the interfaces concept, we can have interfaces (which
> I see as kind of records in records) nicely connecting up in MyHDL.
> Eventually we have to convert into VHDL and integrate it in our top
> level project. Now, in the Altera-world some we have Qsys to make live
> easy. Except that Qsys only understands std_logic and std_logic_vector.
> Say we now define an interface in MyHDL to represent a structured type
> we have to write a to_std_logic_vector() and a to_myinterface() (as I
> now do in VHDL whenever a define a record)  function to 'map' the one to
> the other and back. My expectation is that this could be handled
> automagically. This would save us from writing those 'wrapper modules'
> to use MyHDL originated modules with 'interfaces' in order to use them
> with Qsys (or Xilinx' IP Integrator?).
>
> Keeping VHDL on a leash to please Verilog is, IMHO, hampering MyHDL's
> progress and adoption. Maybe it is time to start a to_SystemVerilog() at
> the same time expanding to_VHDL()?

First, I am not following the logic in this post, and second, I don't
agree at all.

You say we "keep VHDL on a leash to please Verilog". But in the
paragraph before, you seem to ask for a MyHDL solution to work around
a VHDL, or at least a VHDL tool, limitation. That seems "pleasing VHDL"
to me.

Second, I don't see how MyHDL is limited by Verilog. It definitely is
limited by development time, that is for sure. But what you seem to
forget is that there are significant points where it improves both
on VHDL and Verilog. Integer handling, of course. Embedded scripting
can be just great.

It is not necessarily a good idea to support "more advanced" concepts
in the target language directly. For example:
VDHL has records, Verilog does not. Does this limit MyHDL? No - records
are themselves too limited, e.g. you cannot mix in/out in with the
same record. A more general concept, such as interfaces in MyHDL 0.9,
is much better I believe. And we can support that without requiring
something similar in the target language! How can that be bad?

How can assuming as little as possible from Verilog/VHDL hamper adoption?
The contrary must be true. Suppose we drop Verilog. The possible user
base drops immediately with more than half, and it is the half that
needs a more sensible solution most, and also the half that makes
the biggest chips and has most money. How can that be a good idea?

Let me be clear and honest: "adoption" for me means commericial
adoption. The kind of adoption that pays the bills. That has not
happened yet, at least not on the scale that satisfies me. (I am
jealous on everyone who can use MyHDL in current projects, but
lately that has not been my case. Doing interesting projects
though.) I cannot understand how limiting the target language
or putting constraints on it can bring me close to that goal -
I am not going to attract Google or Apple's interest by
concentrating on VHDL.

Jan








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

Re: [myhdl-list] reusable blocks with different interfaces

[Josy B. <jos...@gm...>]

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

> 
> <snip>
> > A practical example: Once there was this site 'All Programmable 
Planet'. A
> > blog/thread was about the 'Game Of Life'. Out of curiosity I coded a 
VHDL
> > version of it. I used, of course, a (true) 2D array to represent the 
cells.
> > I later re-coded this in MyHDL and as MyHDL suffers from Verilogitis 
(I
> > deliberately make it sound like a disease) I had to recode it into a 
1D
> > array, otherwise it would not convert.
> 
> This is an important (IMO) topic, that is multidimensional
> array representation and abstractions.  A separate thread
> just on this topic might be useful - especially given your
> experience and example.
> 
> Regards,
> Chris
> 
> <snip>
I'll start by publishing the VHDL code on github (which I do not seem to 
succeed, syncing via Dropbox seems a lot easier to me).
Unfortunately I lost my 'pygol' project when clearing out Eclipse 
workspaces. But I'll redo that when we move further.

Best regards,

Josy

Re: [myhdl-list] reusable blocks with different interfaces

[Josy B. <jos...@gm...>]

Christopher Felton <chris.felton <at> gmail.com> writes:
> <snip> 
> First we need to define (review) the purpose of the
> generated Verilog and VHDL.  Is it a convenient
> intermediate representation or is MyHDL intended to be
> a V* generator (i.e. is the generated V* modified by
> the user - bootstrap)?
> 
> The V* are convenient IRs [1] and although MyHDL has
> readable converted code (etc.), the converted V* are
> akin to an IR more than a usable standalone piece of
> code (e.g. parameters are not preserved).
> 
> But, in my opinion, interoperability is important and in
> this case I think it is better supported by tools/plugins
> than conversion support.  As  <at> jck mentioned there are
> some processes (naming conventions) that can be used.  If
> I get time in the near future I will try and but together
> an example using  <at> jck suggestion.
> 
> Regards,
> Chris
> (as usual my 2 cents with normal disclaimers :)
> 
> [1] Things change over time and I see to have many false memories,
>      best of my knowledge this is Jan's goal/vision with V*.
> 
> <snip>
You are right, I too see the generated V* as just a convenient 
intermediate representation. This is exactly my point of 'converting' 
MyHDL interfaces into std_logic_vectors (and back) for use in other 
tools. Same reason I am currently (after hours ...) writing a Python 
utility to generate the necessary supporting files, so we can almost 
forget the IR completely and treat is an an opaque something (a black 
box). My utility does away with those (ugly) (Altera) naming conventions 
as it works with ST- and MM- interfaces directly. I hope I can post some 
debugged code soon now. I have an example module working for ST-
interfaces and am now working on an example that also has a MM-Slave 
interface. 
I haven't used interfaces to model Avalon ST-interfaces, yet. We looked 
into them for a project and tried to enhanced this further, but stumbled 
a few times, so I decide to write the project (as it was a fixed-price 
offer from our side) using the 'standard' interconnection method. 
Now an ST-module with MyHDL interfaces may/will conflict with my 
utility, but I'll learn ...

Best regards,

Josy

Re: [myhdl-list] reusable blocks with different interfaces

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

On 1/19/2015 3:23 PM, Josy Boelen wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>> <snip>
>>> Henry is talking about extending the interfaces concept of MyHDL.
> When
>>> converted to VHDL this would result in having structured types (e.g.
> a
>>> record) as ports.
>>
>> I don't think supporting conversion to VHDL records
>> would be a good idea.  Then the Verilog and VHDL
>> conversions would diverge.
>>
>> I don't believe I understand the use case?  Is this
>> intended to simplify wiring up modules (components)
>> after conversion?
<snip>
> Keeping VHDL on a leash to please Verilog is, IMHO, hampering MyHDL's
> progress and adoption. Maybe it is time to start a to_SystemVerilog() at
> the same time expanding to_VHDL()?
>

First we need to define (review) the purpose of the
generated Verilog and VHDL.  Is it a convenient
intermediate representation or is MyHDL intended to be
a V* generator (i.e. is the generated V* modified by
the user - bootstrap)?

The V* are convenient IRs [1] and although MyHDL has
readable converted code (etc.), the converted V* are
akin to an IR more than a usable standalone piece of
code (e.g. parameters are not preserved).

But, in my opinion, interoperability is important and in
this case I think it is better supported by tools/plugins
than conversion support.  As @jck mentioned there are
some processes (naming conventions) that can be used.  If
I get time in the near future I will try and but together
an example using @jck suggestion.

Regards,
Chris
(as usual my 2 cents with normal disclaimers :)

[1] Things change over time and I see to have many false memories,
     best of my knowledge this is Jan's goal/vision with V*.

Re: [myhdl-list] reusable blocks with different interfaces

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

<snip>
> A practical example: Once there was this site 'All Programmable Planet'. A
> blog/thread was about the 'Game Of Life'. Out of curiosity I coded a VHDL
> version of it. I used, of course, a (true) 2D array to represent the cells.
> I later re-coded this in MyHDL and as MyHDL suffers from Verilogitis (I
> deliberately make it sound like a disease) I had to recode it into a 1D
> array, otherwise it would not convert.

This is an important (IMO) topic, that is multidimensional
array representation and abstractions.  A separate thread
just on this topic might be useful - especially given your
experience and example.

Regards,
Chris

Re: [myhdl-list] reusable blocks with different interfaces

[Josy B. <jos...@gm...>]

Henry Gomersall <heng <at> cantab.net> writes:

> 
> On 19/01/15 21:23, Josy Boelen wrote:
> > Keeping VHDL on a leash to please Verilog is, IMHO, hampering MyHDL's
> > progress and adoption. Maybe it is time to start a to_SystemVerilog() at
> > the same time expanding to_VHDL()?
> 
> Given Python is a fully featured language, it would be perfectly 
> possible to write _anything_ into VHDL/Verilog, it's just developer time 
> to make this possible. The correct way IMO is to do the translation in 
> python and not try to match the features of some intermediate language 
> at all. Still, targetting VHDL and Verilog is very sensible.
> 
> Henry
> 

I'm a VHDL-guy (wouldn't touch Verilog with a bargepole).
VHDL has a few extras Verilog doesn't have, aside from Verilog's ugly 
blocking and non-blocking'. 
A practical example: Once there was this site 'All Programmable Planet'. A 
blog/thread was about the 'Game Of Life'. Out of curiosity I coded a VHDL 
version of it. I used, of course, a (true) 2D array to represent the cells. 
I later re-coded this in MyHDL and as MyHDL suffers from Verilogitis (I 
deliberately make it sound like a disease) I had to recode it into a 1D 
array, otherwise it would not convert. 

Now I couldn't care less that how the converted (VHDL or even Verilog) code 
looks, as long as it works but it is a not a step forward to 'advance by 
using Python, but limit yourself to Verilog-able constructs'.
So in my (not so humble anymore) opinion there is a brighter future for 
MyHDL, if only we manage to lift it above the Verilog coding rules. 

Regards,

Josy

Re: [myhdl-list] reusable blocks with different interfaces

[Henry G. <he...@ca...>]

On 19/01/15 21:23, Josy Boelen wrote:
> Keeping VHDL on a leash to please Verilog is, IMHO, hampering MyHDL's
> progress and adoption. Maybe it is time to start a to_SystemVerilog() at
> the same time expanding to_VHDL()?

Given Python is a fully featured language, it would be perfectly 
possible to write _anything_ into VHDL/Verilog, it's just developer time 
to make this possible. The correct way IMO is to do the translation in 
python and not try to match the features of some intermediate language 
at all. Still, targetting VHDL and Verilog is very sensible.

Henry

Re: [myhdl-list] reusable blocks with different interfaces

[Josy B. <jos...@gm...>]

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

> 
> <snip>
> > Henry is talking about extending the interfaces concept of MyHDL. 
When
> > converted to VHDL this would result in having structured types (e.g. 
a
> > record) as ports.
> 
> I don't think supporting conversion to VHDL records
> would be a good idea.  Then the Verilog and VHDL
> conversions would diverge.
> 
> I don't believe I understand the use case?  Is this
> intended to simplify wiring up modules (components)
> after conversion?
> 
> Regards,
> Chris
> <snip>

Apparently I have a problem explaining things (and may now mess it up 
even more):

If we elaborate on the interfaces concept, we can have interfaces (which 
I see as kind of records in records) nicely connecting up in MyHDL. 
Eventually we have to convert into VHDL and integrate it in our top 
level project. Now, in the Altera-world some we have Qsys to make live 
easy. Except that Qsys only understands std_logic and std_logic_vector. 
Say we now define an interface in MyHDL to represent a structured type 
we have to write a to_std_logic_vector() and a to_myinterface() (as I 
now do in VHDL whenever a define a record)  function to 'map' the one to 
the other and back. My expectation is that this could be handled 
automagically. This would save us from writing those 'wrapper modules' 
to use MyHDL originated modules with 'interfaces' in order to use them 
with Qsys (or Xilinx' IP Integrator?).

Keeping VHDL on a leash to please Verilog is, IMHO, hampering MyHDL's 
progress and adoption. Maybe it is time to start a to_SystemVerilog() at 
the same time expanding to_VHDL()?

Best regards,

Josy



Best 

Re: [myhdl-list] reusable blocks with different interfaces

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

<snip>
> Henry is talking about extending the interfaces concept of MyHDL. When
> converted to VHDL this would result in having structured types (e.g. a
> record) as ports.

I don't think supporting conversion to VHDL records
would be a good idea.  Then the Verilog and VHDL
conversions would diverge.

I don't believe I understand the use case?  Is this
intended to simplify wiring up modules (components)
after conversion?

Regards,
Chris

Re: [myhdl-list] reusable blocks with different interfaces

[Josy B. <jos...@gm...>]

Keerthan JC <jckeerthan <at> gmail.com> writes:

> 
> 
> Interfaces signals are converted with dots replaced to underscores. If 
you follow the qsys naming conversions(aso,asi,avm,avs), qsys will 
automatically detect the interfaces.
> 
> 

That's not what I meant: I'm currently working on a Python/MyHDL 
extension to generate the xx_hw.tcl files from within MyHDL (this would 
not have to use that ugly, perfectly useful for automated recognition 
but still ugly, naming convention). The xx_hw.tcl will not only guide 
the elaboartion, but also call back on the MyHDL module to generate the 
bespoke VHDL code.

My 'wish' is the following:
Henry is talking about extending the interfaces concept of MyHDL. When 
converted to VHDL this would result in having structured types (e.g. a 
record) as ports. My 'sigh' is that Qsys only handles std_logic_vector 
as the data type. So it would be great if we could automate the 
conversion between the required std_logic_vector port in VHDL (or even 
Verilog) and the inherently more useful interface object in MyHDL. See 
it as an interface within an interface (or in VHDL: a record in a 
record)

Regards,

Josy