myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Mismatch between Simulation and Conversion

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

On 09/13/2014 06:07 PM, Josy Boelen wrote:

> Can I classify this a bug? Or is it just me (not reading the manual
> thoroughly enough)?

It's really quite simple. When conversions succeeds, and there
is a mismatch between MyHDL and Verilog/VHDL simulation, then
there is a bug. No excuses.

Any rule has exceptions - the exception here is start-up
and initialization behavior at time 0.

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

[myhdl-list] Mismatch between Simulation and Conversion

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

Hi all,

In a large project (6700 lines of generated VHDL) I created a counter:
#start of code
def addresscounter( clk, reset, startValue, Length , initP, cntEn, isStart, 
isEnd, Q, WRAP_AROUND = False ):

   lq = Signal(intbv(0)[len(Q):])

   if WRAP_AROUND == False:
      @always_seq(clk.posedge, reset=reset)
      def counter():
         endval = startValue + Length
         if initP or cntEn:
            if initP :
               lq.next = startValue
               isStart.next = 1
               isEnd.next = 0
            else:
               isStart.next = 0
               if lq < (endval - 1):
                  lq.next = lq + 1

               if lq == (endval - 2) or lq == (endval - 1):
                  isEnd.next = 1
               else:
                  isEnd.next = 0

...
#end of code
The project simulated fine, but didn't run in the FPGA because the converted 
VHDL:
-- start of VHDL
entity addresscounter is
	port(
		clk        : in  std_logic;
		reset      : in  std_logic;
		startValue : in  unsigned(7 downto 0);
		Length     : in  unsigned(7 downto 0);
		initP      : in  std_logic;
		cntEn      : in  std_logic;
		isStart    : out std_logic;
		isEnd      : out std_logic;
		Q          : out unsigned(7 downto 0)
	);
end entity addresscounter;

architecture MyHDL of addresscounter is
	signal lq : unsigned(7 downto 0);

begin
	ADDRESSCOUNTER_COUNTER : process(clk, reset) is
		variable endval : integer;
	begin
		if (reset = '1') then
			isEnd   <= '0';
			isStart <= '0';
			lq      <= to_unsigned(0, 8);
		elsif rising_edge(clk) then
			endval := to_integer(startValue + Length);
			if (bool(initP) or bool(cntEn)) then
				if bool(initP) then
					lq      <= startValue;
					isStart <= '1';
					isEnd   <= '0';
				else
					if (signed(resize(lq, 9)) < (endval 
- 1)) then
						lq      <= (lq + 1);
						isStart <= '0';
					else
						lq      <= startValue;
						isStart <= '1';
					end if;
					if (signed(resize(lq, 9)) = (endval 
- 2)) then
						isEnd <= '1';
					else
						isEnd <= '0';
					end if;
				end if;
			end if;
		end if;
	end process ADDRESSCOUNTER_COUNTER;

	Q <= lq;

end architecture MyHDL;
--end of VHDL

The offending line is:
	endval := to_integer(startValue + Length);

as both StartValue and Length are unsigned(7 downto 0), the operation 
(startValue + Length) wraps around to zero in VHDL, but not when simulating 
in MyHDL.

Can I classify this a bug? Or is it just me (not reading the manual 
thoroughly enough)?

Best regards,

Josy

[myhdl-list] Possible Bug

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

Hello everyone,
While using MyHDL today, I am fairly certain that I came across a bug. At least, it didn't operate as I had expected. Please, correct me if I am mistaken and this is unsupported. I made some mockup code to demonstrate the problem Here it is:''' START OF CODE '''from myhdl import *
def add_c(inp_value, outp_value, clock):	''' '''	MY_CONSTANT = long(1234)	temp_sum = Signal(intbv(0)[16:])
	@always(clock)	def logic():		if inp_value > MY_CONSTANT:			temp_sum.next = MY_CONSTANT		else:			temp_sum.next = inp_value		outp_value.next = temp_sum + MY_CONSTANT
	return logic
if __name__ == '__main__':	a = Signal(intbv(0)[16:])	b = Signal(intbv(0)[16:])	clock = Signal(False)	toVHDL(add_c, a, b, clock)
''' END OF CODE '''
After toVHDL() conversion, I obtained the following (with whitespace edited to improve readability):
-- START OF CODE-- File: add_c.vhd-- Generated by MyHDL 0.8-- Date: Tue Sep  2 18:20:45 2014
library IEEE;use IEEE.std_logic_1164.all;use IEEE.numeric_std.all;use std.textio.all;
use work.pck_myhdl_08.all;
entity add_c is    port (        inp_value: in unsigned(15 downto 0);        outp_value: out unsigned(15 downto 0);        clock: in std_logic    );end entity add_c;
architecture MyHDL of add_c issignal temp_sum: unsigned(15 downto 0);begin
ADD_C_LOGIC: process (clock) isbegin    if (inp_value > 1234) then        temp_sum <= to_unsigned(MY_CONSTANT, 16);    else        temp_sum <= inp_value;    end if;    outp_value <= (temp_sum + 1234);end process ADD_C_LOGIC;
end architecture MyHDL;-- END OF CODE
The problem: MY_CONSTANT is used as a named constant in the RTL, but it was not declared in the declarative region. It seems that constants of type long are not recognized as constants and are not declared in the declarative region by toVHDL(). The same example using an int instead of a long works fine in simulation and conversion. I was using a long in my code because the value was 48 bits wide.
For the time being, a workaround is to use a temporary variable in the RTL. In other words replace the line "temp_sum.next = MY_CONSTANT" with the following two lines:''' START CODE '''temp_var = MY_CONSTANTtemp_sum.next = temp_var''' END CODE'''This converts the MY_CONSTANT to its numeric value and the converted code still simulates correctly. 
I tested this with MyHDL versions 0.8 and 0.9dev.
Is the mailing list the proper forum for reporting this or is there a better place?
Thanks,Daryl 		 	   		  

Re: [myhdl-list] Ignoring generators

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

On 9/1/2014 2:57 PM, Uri Nix wrote:
> Hi Chris,
>
> Actually yes: it can be useful when some of the Signals contain high level
> objects that can't be viewed by gtkwave. So a selective trace would allow
> ignoring the complex signal, but allow viewing the timing waves (clk,
> data_valid, etc).

Obviously, I agree :)  I haven't heard any reasons
not to suggest such a feature, once I finish some
other items (fixbv) I will try and propose the
enhancement.

That is exactly how I came across the need, I had
a simulation with some non-convertible generators
doing all kinds of funky stuff (writing files, etc),
but I also wanted to do some Signal tracing to debug
some logic - needless to say all the monitor type
generators didn't need to be analyzed or their Signals
traced, thought this could be useful.

Thanks for the input,
Chris


>
> Cheers,
> Uri
>
>
> On 27 August 2014 18:23, Christopher Felton <chr...@gm...> wrote:
>
>>
>> Does it make sense to have a function attribute that
>> can be set that allows conversion and tracing to ignore
>> a myhdl generator?
>>
>> Example:
>>
>>       @always_comb
>>       def logic():
>>          # some logic
>>       logic.tracing = False
>>       logic.conversion = False
>>
>> Maybe a single attribute "analyze" that would cover both.
>>
>> Regards,
>> Chris
>>
>>
>>

Re: [myhdl-list] Ignoring generators

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

Hi Chris,

Actually yes: it can be useful when some of the Signals contain high level
objects that can't be viewed by gtkwave. So a selective trace would allow
ignoring the complex signal, but allow viewing the timing waves (clk,
data_valid, etc).

Cheers,
Uri


On 27 August 2014 18:23, Christopher Felton <chr...@gm...> wrote:

>
> Does it make sense to have a function attribute that
> can be set that allows conversion and tracing to ignore
> a myhdl generator?
>
> Example:
>
>      @always_comb
>      def logic():
>         # some logic
>      logic.tracing = False
>      logic.conversion = False
>
> Maybe a single attribute "analyze" that would cover both.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] High-level thinking: Using Python for rapid verification

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

On 19/08/14 14:35, Chris Higgs wrote:
>
> Yes, there is overlap in terms of functionality regarding the cosimulation
> capabilities,
   [snipped interesting and detailed technical points]
> Obviously I think that MyHDL would benefit from re-using this code from Cocotb,
> it's a non-trivial amount of work that addresses some of the areas that could
> be improved in MyHDL.  The architecture of Cocotb is hopefully suitably
> isolated that GPI and its Python bindings could be usefully used without the
> other stuff.

Thanks.  Although this is outside my current technical interest, I 
am encouraged
to see your spirit of openness and co-operation, which will benefit 
us all.

Jan Coombs.
-- 
jan4myhdl at murray hyphen microft dot co dot uk

[myhdl-list] Ignoring generators

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

Does it make sense to have a function attribute that
can be set that allows conversion and tracing to ignore
a myhdl generator?

Example:

     @always_comb
     def logic():
	# some logic
     logic.tracing = False
     logic.conversion = False

Maybe a single attribute "analyze" that would cover both.

Regards,
Chris

Re: [myhdl-list] High-level thinking: Using Python for rapid verification

[Chris H. <chr...@po...>]

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

>  From my perspective it was more of frustration, obviously
> they have some nice features (would be great to see these
> merged into MyHDL) but from the big picture I don't see
> anything the MyHDL doesn't support: provides an interface
> to the V* simulators and you can cosim with Python.

Yes, there is overlap in terms of functionality regarding the cosimulation
capabilities, however perhaps it's worth examining some differences
between Cocotb and MyHDL regarding cosim:


1. Cocotb embeds the Python interpreter into the simulation process.

In a tightly coupled environment like simulation where there are many
events, embedding the Python interpreter has better performance than separate
processes communicating via pipes.


2. Cocotb removes the requirement for any wrapper code

This is one of the significant motivating factors of Cocotb - to reduce the
amount of effort required to create a testbench.  You could argue that the
$from_myhdl and $to_myhdl wrappers are low effort, however having to write a
top-level wrapper is still a barrier.


3. Race conditions / delta cycles

MyHDL solution to this forces passive Verilog whereas Cocotb ties into the
simulator scheduler in a way that allows it to work in an entirely passive
way.  This allows Python coverage models or protocol checkers to be attached
to existing test infrastructure.


There are of course other differences between the projects, specifically that
Cocotb is really designed from the ground up for cosimulation with
VHDL/Verilog whereas the cosim capability of MyHDL is a subsection of a much
larger endeavour.


> > The part you're referring to is called the Generic Procedural Interface
> > (GPI), and it seems to be written in C.
> >
> 
> GPI?  I realize the interesting chunks are the C code (they
> actually did some ugly stuff in the Python side), I will
> need to put this at the end of my infinite "check-out" list
> and see if their C code can be merged with MyHDLs VPI code -
> at this point I don't know if it even makes sense?


GPI is the Generic Procedural Interface, a layer that we have created to
abstract away the underlying simulator implementation.   We have completed
layers for VPI and VHPI and are working on Mentor FLI.  We have only
implemented the functionality we require for Cocotb, however this also
probably comprises the same capabilities that MyHDL might require.  There
are Python bindings for the GPI layer exposed as a module called "simulator".

Obviously I think that MyHDL would benefit from re-using this code from Cocotb,
it's a non-trivial amount of work that addresses some of the areas that could
be improved in MyHDL.  The architecture of Cocotb is hopefully suitably
isolated that GPI and its Python bindings could be usefully used without the
other stuff.


> they actually did some ugly stuff in the Python side

We're always happy to receive feedback, can you elaborate further?  I know you
have previously expressed distaste for the overridden <= assignment, however
you'll be pleased to hear that this has been deprecated (though there is an
ongoing discussion on Github[1] if you want to contribute).  The only
remaining 'hack' that could be considered un-pythonic is the use of a special
exception to return values back from coroutines.  If there is a better way to
achieve this we'd be happy to hear more.

Thanks,

Chris

[1] https://github.com/potentialventures/cocotb/issues/119

Re: [myhdl-list] dev.myhdl.org update

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

I'll go through MEP 107 over the weekend and update it to match the current
implementation.


On Wed, Aug 13, 2014 at 9:38 AM, Christopher Felton <chr...@gm...>
wrote:

> On 8/12/2014 10:09 AM, Jan Decaluwe wrote:
> > I have updated http://dev.myhdl.org
> > according to the current status.
> >
> > Meps 106, 108, and 109 have been declared Final,
> > as they have been implemented in 0.8.
> >
> > @ChrisFelton I changed the wording "class methods"
> > to "methods". In Python, "class methods" really
> > refer to methods that don't take an instance as their
> > first argument, but the class itself. Not our case here.
> >
> > Also, I think that mep 108 could benefit from another
> > proofread to make sure it fully matches what has been implemented.
> > There are also a few sentences that are not entirely clear
> > to me.
>
> Sounds good - I gave it a look over and pushed some
> updates to dev.  I did not recreate the HTML files
> in the repo, I don't have a machine setup to do that
> right now.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

Re: [myhdl-list] dev.myhdl.org update

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

On 8/12/2014 10:09 AM, Jan Decaluwe wrote:
> I have updated http://dev.myhdl.org
> according to the current status.
>
> Meps 106, 108, and 109 have been declared Final,
> as they have been implemented in 0.8.
>
> @ChrisFelton I changed the wording "class methods"
> to "methods". In Python, "class methods" really
> refer to methods that don't take an instance as their
> first argument, but the class itself. Not our case here.
>
> Also, I think that mep 108 could benefit from another
> proofread to make sure it fully matches what has been implemented.
> There are also a few sentences that are not entirely clear
> to me.

Sounds good - I gave it a look over and pushed some
updates to dev.  I did not recreate the HTML files
in the repo, I don't have a machine setup to do that
right now.

Regards,
Chris

[myhdl-list] dev.myhdl.org update

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

I have updated http://dev.myhdl.org
according to the current status.

Meps 106, 108, and 109 have been declared Final,
as they have been implemented in 0.8.

@ChrisFelton I changed the wording "class methods"
to "methods". In Python, "class methods" really
refer to methods that don't take an instance as their
first argument, but the class itself. Not our case here.

Also, I think that mep 108 could benefit from another
proofread to make sure it fully matches what has been implemented.
There are also a few sentences that are not entirely clear
to me.

Jan

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

Re: [myhdl-list] myhdl.concat

[Thomas H. <th...@ct...>]

Am 11.08.2014 22:57, schrieb Jan Decaluwe:
> Correct, thanks for the bug report, and for entering it in BitBucket.
> This is solved in development.
>
> On 08/09/2014 10:17 AM, Thomas Heller wrote:
>> I expected myhdl.concat to return a bit-wise concatenation of the arguments.
>> However, when I use concat(unsigned, signed) this is not the case.

Thank to YOU for the quick action, and thanks for myhdl anyway.
It makes FPGA development fun again!

Thomas

Re: [myhdl-list] myhdl.concat

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

Correct, thanks for the bug report, and for entering it in BitBucket.
This is solved in development.

On 08/09/2014 10:17 AM, Thomas Heller wrote:
> I expected myhdl.concat to return a bit-wise concatenation of the arguments.
> However, when I use concat(unsigned, signed) this is not the case.
> The following program prints '7FFFFFFD' instead of '8FFFFFFD':
>
> <code>
> #!/usr/bin/python2.7-32
> # -*- coding: utf-8 -*-
>
> import myhdl
>
> def unsigned(width, value=0, cls=myhdl.intbv):
>       """Create an unsigned signal based on a bitvector with the
>       specified width and initial value.
>       """
>       return myhdl.Signal(cls(value, 0, 2**width))
>
> def signed(width, value=0, cls=myhdl.intbv):
>       """Create an signed signal based on a bitvector with the
>       specified width and initial value.
>       """
>       return myhdl.Signal(cls(value, -2**(width-1), 2**(width-1)))
>
> a = unsigned(4, 8)
> b = signed(28, -3)
>
> print "%08X" % myhdl.concat(a, b)
> </code>
>
> Is this correct?  Changing (in myhdl 0.8, module _concat.py) this line
> gives the result that I expected:
>
> --- _concat.py~ Mon Aug  4 12:20:26 2014
> +++ _concat.py  Sat Aug  9 10:15:05 2014
> @@ -65,7 +65,7 @@
>            if not w:
>                raise TypeError, "concat: arg on pos %d should have
> length" % (i+1)
>            width += w
> -        val = val*(2**w) + v
> +        val = val*(2**w) | (v % 2**len(v))
>
>        if basewidth:
>            return intbv(val, _nrbits=basewidth + width)
>
>
> Thomas
>
>
> ------------------------------------------------------------------------------
>


-- 
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

[myhdl-list] Development status

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

Hello:

In the past months I have been busy with very interesting
projects, unfortunately with little MyHDL content.

In the coming weeks I have spare engineering cycles, and
I will give priority to give the project a much-needed
maintenance update, both code and websites. I have
already made good progress in the past days.

In particular, I would like to release the 0.8.1
maintenance release asap, and I am now addressing all
important issues with an obvious resolution.

It is clear that we have been moving away from SourceForge,
and to pypi/pip for distribution/installation, and to
Bitbucket for development.

In particular please use the Bitbucket bug tracker for
issues:

https://bitbucket.org/jandecaluwe/myhdl/issues?status=new&status=open

Please help me by entering clearly defined issues in the bug tracker.
You cannot expect me to weed through mailing lists in search
of possible issues, but you can expect that all bug tracker
issues will be addressed eventually.

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

[myhdl-list] myhdl.concat

[Thomas H. <th...@ct...>]

I expected myhdl.concat to return a bit-wise concatenation of the arguments.
However, when I use concat(unsigned, signed) this is not the case.
The following program prints '7FFFFFFD' instead of '8FFFFFFD':

<code>
#!/usr/bin/python2.7-32
# -*- coding: utf-8 -*-

import myhdl

def unsigned(width, value=0, cls=myhdl.intbv):
     """Create an unsigned signal based on a bitvector with the
     specified width and initial value.
     """
     return myhdl.Signal(cls(value, 0, 2**width))

def signed(width, value=0, cls=myhdl.intbv):
     """Create an signed signal based on a bitvector with the
     specified width and initial value.
     """
     return myhdl.Signal(cls(value, -2**(width-1), 2**(width-1)))

a = unsigned(4, 8)
b = signed(28, -3)

print "%08X" % myhdl.concat(a, b)
</code>

Is this correct?  Changing (in myhdl 0.8, module _concat.py) this line
gives the result that I expected:

--- _concat.py~ Mon Aug  4 12:20:26 2014
+++ _concat.py  Sat Aug  9 10:15:05 2014
@@ -65,7 +65,7 @@
          if not w:
              raise TypeError, "concat: arg on pos %d should have 
length" % (i+1)
          width += w
-        val = val*(2**w) + v
+        val = val*(2**w) | (v % 2**len(v))

      if basewidth:
          return intbv(val, _nrbits=basewidth + width)


Thomas

Re: [myhdl-list] Python bool type used as constant

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

Thanks for the bug report. I have fixed this
in the maintenance and development branches.


On 07/14/2014 10:55 AM, Josy Boelen wrote:
> Hi all,
>
> The following code:
> def ramreader( Clk, Reset , ... , WRAP_AROUND ): # WRAP_AROUND is a Python
> bool constant
> ...
>     @always_...
>     def f():
>        ...
>        if not  WRAP_AROUND :
>
> gets converted to:
>        if (not '1') then
>
> which is invalid VHDL ...
>
> A work-around is to bring the constant to the highest level and
> conditionally generate the two cases:
>
> def ramreader( Clk, Reset , ... , WRAP_AROUND ): # WRAP_AROUND is a Python
> bool constant
> ...
>     if not  WRAP_AROUND :
>        @always_...
>        def f():
>           ...
>     else:
>        @always_...
>        def f():
>           ...
>
> Now we have duplicated the code and the maintenance
>
> Regards,
>
> Josy
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck®
> Code Sight™ - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>


-- 
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] High-level thinking: Using Python for rapid verification

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

Cocotb is really nice. Plus it supports all major simulators. I think its
definitely worth investigating if their VPI code can be used by MyHDL.


On Fri, Aug 1, 2014 at 8:28 AM, Christopher Felton <chr...@gm...>
wrote:

> On 8/1/2014 3:14 AM, Guy Eschemann wrote:
> > I've watched the webinar and I was quite impressed. I'm actually waiting
> > for Cocotb to support Microsoft Windows (planned: Q3/2014) to try it out.
> >
>
>  From my perspective it was more of frustration, obviously
> they have some nice features (would be great to see these
> merged into MyHDL) but from the big picture I don't see
> anything the MyHDL doesn't support: provides an interface
> to the V* simulators and you can cosim with Python.
>
> > The part you're referring to is called the Generic Procedural Interface
> > (GPI), and it seems to be written in C.
> >
>
> GPI?  I realize the interesting chunks are the C code (they
> actually did some ugly stuff in the Python side), I will
> need to put this at the end of my infinite "check-out" list
> and see if their C code can be merged with MyHDLs VPI code -
> at this point I don't know if it even makes sense?
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

Re: [myhdl-list] High-level thinking: Using Python for rapid verification

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

On 8/1/2014 3:14 AM, Guy Eschemann wrote:
> I've watched the webinar and I was quite impressed. I'm actually waiting
> for Cocotb to support Microsoft Windows (planned: Q3/2014) to try it out.
>

 From my perspective it was more of frustration, obviously
they have some nice features (would be great to see these
merged into MyHDL) but from the big picture I don't see
anything the MyHDL doesn't support: provides an interface
to the V* simulators and you can cosim with Python.

> The part you're referring to is called the Generic Procedural Interface
> (GPI), and it seems to be written in C.
>

GPI?  I realize the interesting chunks are the C code (they
actually did some ugly stuff in the Python side), I will
need to put this at the end of my infinite "check-out" list
and see if their C code can be merged with MyHDLs VPI code -
at this point I don't know if it even makes sense?

Regards,
Chris

Re: [myhdl-list] High-level thinking: Using Python for rapid verification

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

On 7/31/2014 1:41 PM, Martin Strubel wrote:
> Hi,
>
> I'm using GHDL and some extensions ("ghdlex") to interface MyHDL logic
> with existing VHDL designs through netpp/python. Basically, a VirtualBus
> entity of Virtual FIFO speaks through external programs (like a python
> appplication) through network sockets.
>
> There's sparse info on the web, maybe you could use this one as entry
> point for inspiration:
>
> https://mail.gna.org/public/ghdl-discuss/2014-04/msg00012.html
>
> Greetings,
>
> - Martin
>

This is interesting, we don't have a good solution
to cosim with GHDL.  At one point we investigated
the limited VHPI support but didn't get too far.

But the normal road blocks, time and motivation :)

Regards,
Chris

Re: [myhdl-list] High-level thinking: Using Python for rapid verification

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

I've watched the webinar and I was quite impressed. I'm actually waiting 
for Cocotb to support Microsoft Windows (planned: Q3/2014) to try it out.

The part you're referring to is called the Generic Procedural Interface 
(GPI), and it seems to be written in C.

Regards,
Guy.

Am 31.07.2014 18:17, schrieb Christopher Felton:
> Has anyone else watched this webinar?  I was curious of
> others thoughts?
>
> https://www.aldec.com/en/support/resources/multimedia/webinars/1774
> (note you have to create a user account etc. to view
> the webinar).
>
> Would anyone be interested in determining if some of the
> backend code can be merged into MyHDL?  Specifically the
> VHPI (which will be hard to test without a VHPI simulator)
> and the VPI code that extracts the hierarchy from lower
> HDL?  It would not be directly usable but it might be a
> starting point.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

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

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

Re: [myhdl-list] High-level thinking: Using Python for rapid verification

[Martin S. <ha...@se...>]

Hi,

I'm using GHDL and some extensions ("ghdlex") to interface MyHDL logic
with existing VHDL designs through netpp/python. Basically, a VirtualBus
entity of Virtual FIFO speaks through external programs (like a python
appplication) through network sockets.

There's sparse info on the web, maybe you could use this one as entry
point for inspiration:

https://mail.gna.org/public/ghdl-discuss/2014-04/msg00012.html

Greetings,

- Martin

>> Looks cool. Correct me if I'm wrong, but there's currently not a great way
>> to integrate existing Verilog/VHDL IP into MyHDL simulations, is there?
>> Seems like this could bridge that gap nicely.
>>
> 
> Yes, there are options to integrate 3rd IP in MyHDL
> just not lots of examples.  We had a discussion just
> the other day how to do so in one case - is there a
> disgestible example that you can think of that might
> help make this clear?
> 
> I guess it depends on how you define "nicely" and it
> might be worthwhile determining if there are features
> that can be leveraged (V* signal extraction, etc.).
> 
> Regards,
> Chris
> 
>>
>> On Thu, Jul 31, 2014 at 9:17 AM, Christopher Felton <chr...@gm...>
>> wrote:
>>
>>> Has anyone else watched this webinar?  I was curious of
>>> others thoughts?
>>>
>>> https://www.aldec.com/en/support/resources/multimedia/webinars/1774
>>> (note you have to create a user account etc. to view
>>> the webinar).
>>>
>>> Would anyone be interested in determining if some of the
>>> backend code can be merged into MyHDL?  Specifically the
>>> VHPI (which will be hard to test without a VHPI simulator)
>>> and the VPI code that extracts the hierarchy from lower
>>> HDL?  It would not be directly usable but it might be a
>>> starting point.
>>>
>>> Regards,
>>> Chris
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Infragistics Professional
>>> Build stunning WinForms apps today!
>>> Reboot your WinForms applications with our WinForms controls.
>>> Build a bridge from your legacy apps to the future.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> myhdl-list mailing list
>>> myh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls. 
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

Re: [myhdl-list] High-level thinking: Using Python for rapid verification

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

On 7/31/2014 12:46 PM, Colin Beighley wrote:
> Looks cool. Correct me if I'm wrong, but there's currently not a great way
> to integrate existing Verilog/VHDL IP into MyHDL simulations, is there?
> Seems like this could bridge that gap nicely.
>

Yes, there are options to integrate 3rd IP in MyHDL
just not lots of examples.  We had a discussion just
the other day how to do so in one case - is there a
disgestible example that you can think of that might
help make this clear?

I guess it depends on how you define "nicely" and it
might be worthwhile determining if there are features
that can be leveraged (V* signal extraction, etc.).

Regards,
Chris

>
> On Thu, Jul 31, 2014 at 9:17 AM, Christopher Felton <chr...@gm...>
> wrote:
>
>> Has anyone else watched this webinar?  I was curious of
>> others thoughts?
>>
>> https://www.aldec.com/en/support/resources/multimedia/webinars/1774
>> (note you have to create a user account etc. to view
>> the webinar).
>>
>> Would anyone be interested in determining if some of the
>> backend code can be merged into MyHDL?  Specifically the
>> VHPI (which will be hard to test without a VHPI simulator)
>> and the VPI code that extracts the hierarchy from lower
>> HDL?  It would not be directly usable but it might be a
>> starting point.
>>
>> Regards,
>> Chris
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] High-level thinking: Using Python for rapid verification

[Colin B. <col...@gm...>]

Looks cool. Correct me if I'm wrong, but there's currently not a great way
to integrate existing Verilog/VHDL IP into MyHDL simulations, is there?
Seems like this could bridge that gap nicely.


On Thu, Jul 31, 2014 at 9:17 AM, Christopher Felton <chr...@gm...>
wrote:

> Has anyone else watched this webinar?  I was curious of
> others thoughts?
>
> https://www.aldec.com/en/support/resources/multimedia/webinars/1774
> (note you have to create a user account etc. to view
> the webinar).
>
> Would anyone be interested in determining if some of the
> backend code can be merged into MyHDL?  Specifically the
> VHPI (which will be hard to test without a VHPI simulator)
> and the VPI code that extracts the hierarchy from lower
> HDL?  It would not be directly usable but it might be a
> starting point.
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] High-level thinking: Using Python for rapid verification

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

Has anyone else watched this webinar?  I was curious of
others thoughts?

https://www.aldec.com/en/support/resources/multimedia/webinars/1774
(note you have to create a user account etc. to view
the webinar).

Would anyone be interested in determining if some of the
backend code can be merged into MyHDL?  Specifically the
VHPI (which will be hard to test without a VHPI simulator)
and the VPI code that extracts the hierarchy from lower
HDL?  It would not be directly usable but it might be a
starting point.

Regards,
Chris

Re: [myhdl-list] myHDL and BFM

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

On 07/28/2014 04:49 PM, Matthias Dübon wrote:
> Hello Guy,
>
> yes I am sure to write a BFM for AXI lite is not a big deal, but IMHO
> the power of myHDL increases with the number of third party
> tools/libraries/frameworks. If myHDL would not "only" be a replacement
> of VHDL/Verilog but a powerful verification, modelling framework, that
> would be really cool.

I don't think anyone will disagree with that, so that's
not a problem.

The remaining issue is how to get there :-)

-- 
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