myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] [Patch] Missing import in _Signal.py

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

Hope it is ok to post these patches here instead of opeing a bug
report...

Thanks, Thomas

diff -r 890982e941e2 myhdl/_Signal.py
--- a/myhdl/_Signal.py  Thu Apr 11 22:20:37 2013 +0200
+++ b/myhdl/_Signal.py  Fri Apr 12 20:11:17 2013 +0200
@@ -29,6 +29,7 @@

  from inspect import currentframe, getouterframes
  from copy import copy, deepcopy
+import operator

  from myhdl import _simulator as sim
  from myhdl._simulator import _signals, _siglist, _futureEvents, now

Re: [myhdl-list] Non-unique function conversion

[Zhen W. <ich...@gm...>]

Cool, thanks for the clear up... So functions in verilog act more like
inline defs in C/C++ and the synthesizer should be smart enough to do any
optimizations


On Wed, Apr 3, 2013 at 1:00 AM, Martin Schoeberl <ma...@jo...>wrote:

>
> On 2 Apr, 2013, at 15:33, Christopher Felton wrote:
>
> > On 4/2/2013 4:12 AM, Zhen Wang wrote:
> >>> From the user manual:
> >> "Function calls are mapped to Verilog or VHDL subprogramsThe converter
> >> analyzes function calls and function code. Each function is mapped to an
> >> appropriate subprogram in the target HDL: a function or task in Verilog,
> >> and a function or procedure in VHDL. In order to support the full power
> of
> >> Python functions, a unique subprogram is generated per Python function
> >> call."
> >>
> >> Is it possible to disable this feature? I am currently doing a design,
> but
> >> I am over the LEs on the unit, and I think unique functions is not
> allowing
> >> the synthesizer to optimize for area.
> >>
> >> Cheers,
> >>
> >> Zhen
> >>
> >
> > Why do you think it is the unique functions?  If each
> > function has the same logic the optimizers should be
> > able to optimize (if applicable).  I don't think having
> > /unique/ or /nonunique/ would effect the LE utilization.
>
> Even if you use the same function (name), sharing of logic depends on
> input and
> output signals as well. If one function (combinational logic) is
> instantiated
> twice with different input signals, there is no sharing. Think in parallel
> working
> hardware, not in 'functions'.
>
> Cheers,
> Martin
>
> >
> > Regards,
> > Chris
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Own the Future-Intel(R) Level Up Game Demo Contest 2013
> > Rise to greatness in Intel's independent game demo contest. Compete
> > for recognition, cash, and the chance to get your game on Steam.
> > $5K grand prize plus 10 genre and skill prizes. Submit your demo
> > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
> >
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Non-unique function conversion

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

On 2 Apr, 2013, at 15:33, Christopher Felton wrote:

> On 4/2/2013 4:12 AM, Zhen Wang wrote:
>>> From the user manual:
>> "Function calls are mapped to Verilog or VHDL subprogramsThe converter
>> analyzes function calls and function code. Each function is mapped to an
>> appropriate subprogram in the target HDL: a function or task in Verilog,
>> and a function or procedure in VHDL. In order to support the full power of
>> Python functions, a unique subprogram is generated per Python function
>> call."
>> 
>> Is it possible to disable this feature? I am currently doing a design, but
>> I am over the LEs on the unit, and I think unique functions is not allowing
>> the synthesizer to optimize for area.
>> 
>> Cheers,
>> 
>> Zhen
>> 
> 
> Why do you think it is the unique functions?  If each
> function has the same logic the optimizers should be
> able to optimize (if applicable).  I don't think having
> /unique/ or /nonunique/ would effect the LE utilization.

Even if you use the same function (name), sharing of logic depends on input and
output signals as well. If one function (combinational logic) is instantiated
twice with different input signals, there is no sharing. Think in parallel working
hardware, not in 'functions'.

Cheers,
Martin

> 
> Regards,
> Chris
> 
> 
> 
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete 
> for recognition, cash, and the chance to get your game on Steam. 
> $5K grand prize plus 10 genre and skill prizes. Submit your demo 
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 
> 

Re: [myhdl-list] Function calls in combinatorial blocks

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

On 4/2/2013 10:40 AM, Christopher Felton wrote:
> On 4/2/2013 10:17 AM, Per Karlsson wrote:
>> There was an example in my original post. But of course there may be
>> something else that's wrong with that.
>> Especially since I just tried your example... and it works! :)
>> /Per
>>
>>
>
> Doh, missed the original example, will give it another
> look and see I see anything.
>
> .chris
>

The difference between my example and the one you
provided is that the function is in the local scope
(in the original example).  If I modify your example
slightly it works in the /@always_comb/.

I don't know if a local function working in the
sequential just happens to work or if the local
function not working in the comb is a bug.  I will
investigate (at some point :) ).

Regards,
Chris

~~~~ [modified example] ~~~~
     from myhdl import *

     def f(a):
         out = intbv(0)[len(a):]
         if a<3:
             out[:] = a
         else:
             out[:] = 0
         return out

     def w(a, b, c, clk):
         @always_comb
         def cm():
             b.next = f(a)

         @always(clk.posedge)
         def ck():
             c.next = f(a)

         return instances()

     def test():
         a = Signal(intbv(0)[10:])
         b = Signal(intbv(0)[10:])
         c = Signal(intbv(0)[10:])
         clk = Signal(bool(0))
         dut = toVerilog(w, a, b,c ,clk)
         return instances()

     s = Simulation(test())
     s.run()

Re: [myhdl-list] Function calls in combinatorial blocks

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

On 4/2/2013 10:17 AM, Per Karlsson wrote:
> There was an example in my original post. But of course there may be
> something else that's wrong with that.
> Especially since I just tried your example... and it works! :)
> /Per
>
>

Doh, missed the original example, will give it another
look and see I see anything.

.chris

Re: [myhdl-list] Function calls in combinatorial blocks

[Per K. <bas...@gm...>]

There was an example in my original post. But of course there may be
something else that's wrong with that.
Especially since I just tried your example... and it works! :)
/Per


On Tue, Apr 2, 2013 at 3:42 PM, Christopher Felton
<chr...@gm...>wrote:

> On 3/2/2013 7:11 AM, Christopher Felton wrote:
> > On 3/1/13 3:16 PM, Christopher Felton wrote:
> >> On 3/1/2013 9:12 AM, Per Karlsson wrote:
> >>> Hi!
> >>> Is there a particular reason that we do not support function calls in
> >>> combinatorial blocks?
> >>>
> >>
> >> I don't know if there is a reason, my guess is
> >> not.  But it is currently *not* supported.  To
> >> have the feature added it is ideal to create a
> >> MEP describing the feature.  Can simply start
> >> by describing the enhancement request to the
> >> mailing-list.
> >>
> >> My opinion, there are two levels: modeling and
> >> conversion.  In some cases we might want to take
> >> baby steps to implement, first just add for modeling
> >> and then for conversion.
> >
> > I should clarify, this works for "modeling" you can
> > have a function on the right hand side, I was speaking
> > generally in the second paragraph.
> >
> > Best of my knowledge, functions as described (on the RHS
> > of and assignment) are not convertible but I don't see
> > why we can't create a MEP and add it to the list of
> > future features.
> >
> > Regards,
> > Chris
> >
> >
>
> Hmmm, not sure what happened when I replied to this
> thread awhile ago.  I (*thought*) I tested this and
> saw the same phenomenon and thought it was not a
> supported feature.  Yet again, I was *wrong*!
> (a new post reminded me)
>
> A function in an /always_comb/ should be supported.
> I included an example below.  If you have an example
> that is not working let us know and I will see if
> I can help.  Sorry about any confusion.
>
> Regards,
> Chris
>
>
> ~~~ [Example with functions on RHS] ~~~~
>
>      def cadd(a,b):
>          return a + b
>
>      def m_add_seq(clock,reset,a,b,c):
>          @always_seq(clock.posedge, reset=reset)
>          def hdl():
>              c.next = cadd(a,b)
>          return hdl
>
>      def m_add_comb(a,b,c):
>          @always_comb
>          def hdl():
>              c.next = cadd(a,b)
>          return hdl
>
>      def test_add():
>          clock = Signal(bool(0))
>          reset = ResetSignal(0, active=0, async=False)
>          a,b = [Signal(intbv(0,min=-4,max=4)) for ii in (0,1)]
>          cs = Signal(intbv(0,min=-8,max=8))
>          cc = Signal(intbv(0,min=-8,max=8))
>
>          @always(delay(3))
>          def tb_clock():
>              clock.next = not clock
>
>          tb_dut_s = m_add_seq(clock,reset,a,b,cs)
>          tb_dut_c = m_add_comb(a,b,cc)
>
>          @instance
>          def tb_stim():
>              reset.next = False
>              yield delay(10)
>              reset.next = True
>              yield delay(10)
>              yield clock.posedge
>              for aa in xrange(4):
>                  for bb in xrange(4):
>                      a.next = aa
>                      b.next = bb
>                      yield clock.posedge
>                      yield clock.posedge
>                      assert cs == (a+b)
>                      assert cc == (a+b)
>              raise StopSimulation
>
>          Simulation((tb_clock,tb_dut_s,tb_dut_c,tb_stim)).run()
>          toVerilog(m_add_seq,clock,reset,a,b,cs)
>          toVerilog(m_add_comb,a,b,cc)
>
>
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete
> for recognition, cash, and the chance to get your game on Steam.
> $5K grand prize plus 10 genre and skill prizes. Submit your demo
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Function calls in combinatorial blocks

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

On 3/2/2013 7:11 AM, Christopher Felton wrote:
> On 3/1/13 3:16 PM, Christopher Felton wrote:
>> On 3/1/2013 9:12 AM, Per Karlsson wrote:
>>> Hi!
>>> Is there a particular reason that we do not support function calls in
>>> combinatorial blocks?
>>>
>>
>> I don't know if there is a reason, my guess is
>> not.  But it is currently *not* supported.  To
>> have the feature added it is ideal to create a
>> MEP describing the feature.  Can simply start
>> by describing the enhancement request to the
>> mailing-list.
>>
>> My opinion, there are two levels: modeling and
>> conversion.  In some cases we might want to take
>> baby steps to implement, first just add for modeling
>> and then for conversion.
>
> I should clarify, this works for "modeling" you can
> have a function on the right hand side, I was speaking
> generally in the second paragraph.
>
> Best of my knowledge, functions as described (on the RHS
> of and assignment) are not convertible but I don't see
> why we can't create a MEP and add it to the list of
> future features.
>
> Regards,
> Chris
>
>

Hmmm, not sure what happened when I replied to this
thread awhile ago.  I (*thought*) I tested this and
saw the same phenomenon and thought it was not a
supported feature.  Yet again, I was *wrong*!
(a new post reminded me)

A function in an /always_comb/ should be supported.
I included an example below.  If you have an example
that is not working let us know and I will see if
I can help.  Sorry about any confusion.

Regards,
Chris


~~~ [Example with functions on RHS] ~~~~

     def cadd(a,b):
         return a + b

     def m_add_seq(clock,reset,a,b,c):
         @always_seq(clock.posedge, reset=reset)
         def hdl():
             c.next = cadd(a,b)
         return hdl

     def m_add_comb(a,b,c):
         @always_comb
         def hdl():
             c.next = cadd(a,b)
         return hdl

     def test_add():
         clock = Signal(bool(0))
         reset = ResetSignal(0, active=0, async=False)
         a,b = [Signal(intbv(0,min=-4,max=4)) for ii in (0,1)]
         cs = Signal(intbv(0,min=-8,max=8))
         cc = Signal(intbv(0,min=-8,max=8))

         @always(delay(3))
         def tb_clock():
             clock.next = not clock

         tb_dut_s = m_add_seq(clock,reset,a,b,cs)
         tb_dut_c = m_add_comb(a,b,cc)

         @instance
         def tb_stim():
             reset.next = False
             yield delay(10)
             reset.next = True
             yield delay(10)
             yield clock.posedge
             for aa in xrange(4):
                 for bb in xrange(4):
                     a.next = aa
                     b.next = bb
                     yield clock.posedge
                     yield clock.posedge
                     assert cs == (a+b)
                     assert cc == (a+b)
             raise StopSimulation

         Simulation((tb_clock,tb_dut_s,tb_dut_c,tb_stim)).run()
         toVerilog(m_add_seq,clock,reset,a,b,cs)
         toVerilog(m_add_comb,a,b,cc)

Re: [myhdl-list] Non-unique function conversion

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

On 4/2/2013 4:12 AM, Zhen Wang wrote:
>>From the user manual:
> "Function calls are mapped to Verilog or VHDL subprogramsThe converter
> analyzes function calls and function code. Each function is mapped to an
> appropriate subprogram in the target HDL: a function or task in Verilog,
> and a function or procedure in VHDL. In order to support the full power of
> Python functions, a unique subprogram is generated per Python function
> call."
>
> Is it possible to disable this feature? I am currently doing a design, but
> I am over the LEs on the unit, and I think unique functions is not allowing
> the synthesizer to optimize for area.
>
> Cheers,
>
> Zhen
>

Why do you think it is the unique functions?  If each
function has the same logic the optimizers should be
able to optimize (if applicable).  I don't think having
/unique/ or /nonunique/ would effect the LE utilization.

Regards,
Chris

[myhdl-list] Non-unique function conversion

[Zhen W. <ich...@gm...>]

>From the user manual:
"Function calls are mapped to Verilog or VHDL subprogramsThe converter
analyzes function calls and function code. Each function is mapped to an
appropriate subprogram in the target HDL: a function or task in Verilog,
and a function or procedure in VHDL. In order to support the full power of
Python functions, a unique subprogram is generated per Python function
call."

Is it possible to disable this feature? I am currently doing a design, but
I am over the LEs on the unit, and I think unique functions is not allowing
the synthesizer to optimize for area.

Cheers,

Zhen

Re: [myhdl-list] VHDL Cosim Initial Thoughts

[Oscar D. <osc...@gm...>]

Hi

Sorry to join the thread so late, just recently I had to deal with
VHDLco-simulation in
GHDL (among other stuff) and manage to use the limited C-function calling
from VHDL to connect with existing co-simulation code.

https://github.com/dargor0/myhdl-addons/tree/master/cosimulation

I know it's somewhat limited but served my purpose. I hope this helps to
implement a definite solution for VHDL co-simulation.

Best regards


2013/1/17 Daryl Wasden <dw...@ou...>

> Thanks again. I cloned the code to my computer. I will push
> the changes once I have the cross-platform C-code completed.
> It works more or less, with the one problem I mentioned. I
> have some ideas for fixing it, just need to find a little
> more time....
>
> -Daryl
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] Verilog Cosimulation: dut with only inputs fails

[Jos H. <jos...@gm...>]

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

> If the /v/ is a port and is a signal that comes
> from the Verilog simulator after conversion :
> 
>      def m_inputs_outputs(clock,reset,v):
>          @always(clock.posedge)
>          def hdl():
>              vv = 0
>              if not reset:
>                  vv = v + 1
>              v.next = vv
>          return hdl
> 
> It runs without error.  But if /v/ is an internal
> signal it will fail while trying to read the "to"
> pipe (to_myhdl).  So, it looks like cosimulation
> expects signals to the Verilog simulator and signals
> from the Verilog simulator.  In general this is what
> you want, you want to provide some stimulus and verify
> the response to the stimulus.  You need inputs and
> outputs from the dut.

Hi Chris,

Thanks for cleaning up the example.
I was expecting something like this. Indeed having no outputs is generally not 
what you want. It just happened that I used .vcd file generation in icarus, so I 
could (temporarily) work without having output ports to the myhdl side.
But of course better and automated tests are being made! ;-)

Regards,
Jos

Re: [myhdl-list] Missing parens in isinstance call, in _toVHDL.py

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

Am 28.03.2013 21:04, schrieb Thomas Heller:
> The following diff is against the current 0.8-dev branch.
> The bug is triggered when code like this is converted:
>
>       dout.next = 0x8030 + (channel << 10)

Sorry for the wrapped lines, here is the patch again as attachment.

[myhdl-list] Missing parens in isinstance call, in _toVHDL.py

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

The following diff is against the current 0.8-dev branch.
The bug is triggered when code like this is converted:

     dout.next = 0x8030 + (channel << 10)

Thomas


diff -r 57a3b8fd0e77 myhdl/conversion/_toVHDL.py
--- a/myhdl/conversion/_toVHDL.py       Sun Mar 10 22:25:20 2013 +0100
+++ b/myhdl/conversion/_toVHDL.py       Thu Mar 28 21:01:14 2013 +0100
@@ -602,7 +602,7 @@
                  else:
                      raise AssertionError("unexpected op %s" % op)
              elif isinstance(left.vhd, vhd_int) and 
isinstance(right.vhd, vhd_vector):
-                if isinstance(op, ast.Add, ast.Sub, ast.Mod, ast.FloorDiv):
+                if isinstance(op, (ast.Add, ast.Sub, ast.Mod, 
ast.FloorDiv)):
                      right.vhd.size = ns
                      node.vhdOri.size = ns
                  elif isinstance(op, ast.Mult):

Re: [myhdl-list] Verilog Cosimulation: dut with only inputs fails

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

On 3/27/2013 10:00 PM, Christopher Felton wrote:
> On 3/25/13 10:51 AM, Jos Huisken wrote:
>> Hi,
>>
>> Trying to do a verilog co-simulation, having a DUT with only inputs.
>> Message:
>> ...
>> myhdl.CosimulationError: Premature simulation end
>> Exception TypeError: 'isinstance() arg 2 must be a class, type, or tuple of
>> classes and types' in <function _remove at 0xb73b2d14> ignored
>>
>> Or did I miss something?
>
> I don't know the exact mechanism that is causing
> the failure but it seems to be related to inputs
> (inputs to the cosim) only.  I created a similar
> but slightly modified version of your example.
>

I wanted to clarify, this is not as an error.
Cosimulation expects the MyHDL simulation to drive
the timing (typically providing the clock) and then
observe some set of outputs from the cosimulator.

The original example lacks the signals going back
to the MyHDL simulator.  As demonstrated, cosimulation
runs when everything is configured as documented.

http://www.myhdl.org/doc/current/manual/cosimulation.html#co-simulation-with-verilog

I realize some of this is subtle if you are new to
MyHDL.  We will gladly take suggestions if the docs
need to be updated.

Regards,
Chris Felton

Re: [myhdl-list] Verilog Cosimulation: dut with only inputs fails

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

On 3/25/13 10:51 AM, Jos Huisken wrote:
> Hi,
>
> Trying to do a verilog co-simulation, having a DUT with only inputs.
> Message:
> ...
> myhdl.CosimulationError: Premature simulation end
> Exception TypeError: 'isinstance() arg 2 must be a class, type, or tuple of
> classes and types' in <function _remove at 0xb73b2d14> ignored
>
> Or did I miss something?

I don't know the exact mechanism that is causing
the failure but it seems to be related to inputs
(inputs to the cosim) only.  I created a similar
but slightly modified version of your example.

https://bitbucket.org/cfelton/examples/src/tip/cosim/example1/cosim_inputs_only.py?at=default

If the /v/ is a port and is a signal that comes
from the Verilog simulator after conversion :

     def m_inputs_outputs(clock,reset,v):
         @always(clock.posedge)
         def hdl():
             vv = 0
             if not reset:
                 vv = v + 1
             v.next = vv
         return hdl

It runs without error.  But if /v/ is an internal
signal it will fail while trying to read the "to"
pipe (to_myhdl).  So, it looks like cosimulation
expects signals to the Verilog simulator and signals
from the Verilog simulator.  In general this is what
you want, you want to provide some stimulus and verify
the response to the stimulus.  You need inputs and
outputs from the dut.

Hope this helps,
Chris

Re: [myhdl-list] Verilog Cosimulation: dut with only inputs fails

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

On 3/27/2013 10:09 AM, Jos Huisken wrote:
> Hi Jan, Chris,
>
> You'll need a link to .../myhdl/cosimulation/icarus/myhdl.vpi to run.
> Likewise an 'import os' is needed in the script I posted.
>
> Could the reason be that I use a locally declared signal 'v' both as input and
> output in 'bug1'?
> If I add an 'vi' and 'vo' port to bug1, and externally connect them, I do not
> have the Cosimulation error.
>
> Further below I have added a working version with an input+output port.
>
> Regards,
> Jos

Sorry about the confusion, I misunderstood, the missing
VPI was from Jan C.'s output not your original, doh.

I have not tried to run your module yet, only looked at
the output and tried to predict what could be occurring.

In your original post, 'v' was not a port in the module
so it was not exposed to the VPI interface (nor did your
testbench use 'v').  The signal 'v' was only internal to
the module 'bug1'.

Adding the 'v' to the port should be fine, you can still
get the current value of 'v' and update 'v'.  You shouldn't
need 'vin' and 'vout' *unless* 'vin' is being driven by
another @always* generator (or an @instance).

I don't see why the original error is occurring, yet.  When
I get a chance to run the original module it probably will
shed some light.

Regards,
Chris

>
> My full output:
> -----
> $ python m.py
> bug1.v generated
> Simulation stopped at t = 100
> MyHDL simulation done
> == /usr/bin/iverilog -o bug1 bug1.v tb_bug1.v
> == /usr/bin/vvp -m ./myhdl.vpi -M/usr/lib/ivl bug1
> Traceback (most recent call last):
>    File "m.py", line 71, in <module>
>      tb = traceSignals(main)
>    File "/usr/local/lib/python2.7/site-packages/myhdl/_traceSignals.py", line 82,
> in __call__
>      h = _HierExtr(name, dut, *args, **kwargs)
>    File "/usr/local/lib/python2.7/site-packages/myhdl/_extractHierarchy.py", line
> 231, in __init__
>      _top = dut(*args, **kwargs)
>    File "m.py", line 41, in main
>      tb = bug1(clk, rst, CoSim)
>    File "m.py", line 23, in bug1
>      cosim = Cosimulation(cmd, clk = clk, rst = rst)
>    File "/usr/local/lib/python2.7/site-packages/myhdl/_Cosimulation.py", line 88,
> in __init__
>      raise CosimulationError(_error.SimulationEnd)
> myhdl.CosimulationError: Premature simulation end
> Exception TypeError: 'isinstance() arg 2 must be a class, type, or tuple of
> classes and types' in <function _remove at 0xb7390ca4> ignored
> -----
>
> If I run vvp from the shell (which seems normal behaviour):
> $ /usr/bin/vvp -m ./myhdl.vpi -M/usr/lib/ivl bug1
> ERROR: no write pipe to myhdl
> FROM 0 clk 1 rst 1
> $
>
> The running version with input+output:
> -----
> import os
> from myhdl import *
>
> path = "/usr/"  # icarus install path
>
>
> def bug1(clk, rst, vin, vout, CoSim=False):
>
>      #v = Signal(modbv()[3:])
>
>      @always(clk.posedge)
>      def dobug1():
>          vv = 0
>          if not rst:
>              vv = vin + 1
>          vout.next = vv
>
>      if CoSim:
>          cmd = path + 'bin/iverilog -o bug1 bug1.v tb_bug1.v'
>          print "==", cmd
>          os.system(cmd)
>          cmd = path + 'bin/vvp -m ./myhdl.vpi -M' + path + 'lib/ivl bug1'
>          print "==", cmd
>          cosim = Cosimulation(cmd, clk = clk, rst = rst, vin = vin, vout = vout)
>          return cosim
>      else:
>          return dobug1
>
>
> if __name__ == "__main__":
>
>      clk = Signal(bool(1))
>      rst = Signal(bool(0))
>      vi = Signal(modbv()[3:])
>      vo = Signal(modbv()[3:])
>
>      toVerilog(bug1, clk, rst, vi, vo)
>      print "bug1.v generated"
>
>      def main():
>
>          period = 10  # clock period in ns
>
>          tb = bug1(clk, rst, vi, vi, CoSim)
>
>          @instance
>          def clkgen():
>              clk.next = 0
>              while True:
>                  yield delay(period // 2)
>                  clk.next = not clk
>
>          @instance
>          def rstgen():
>              rst.next = 1
>              yield delay(2*period)
>              rst.next = 0
>
>          @always(clk.posedge)
>          def stop():
>              if now() > 95:
>                  print "Simulation stopped at t =", now()
>                  raise StopSimulation
>
>          return instances()
>
>      CoSim = False
>      tb = traceSignals(main)
>      sim = Simulation(tb)
>      sim.run()
>      print "MyHDL simulation done"
>
>      CoSim = True
>      tb = traceSignals(main)
>      sim = Simulation(tb)
>      sim.run()
>      print "MyHDL Verilog Co-simulation done"
>
> -----
>
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel&reg; Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>

Re: [myhdl-list] Verilog Cosimulation: dut with only inputs fails

[Jos H. <jos...@gm...>]

Hi Jan, Chris,

You'll need a link to .../myhdl/cosimulation/icarus/myhdl.vpi to run.
Likewise an 'import os' is needed in the script I posted.

Could the reason be that I use a locally declared signal 'v' both as input and 
output in 'bug1'?
If I add an 'vi' and 'vo' port to bug1, and externally connect them, I do not 
have the Cosimulation error.

Further below I have added a working version with an input+output port.

Regards,
Jos

My full output:
-----
$ python m.py
bug1.v generated
Simulation stopped at t = 100
MyHDL simulation done
== /usr/bin/iverilog -o bug1 bug1.v tb_bug1.v
== /usr/bin/vvp -m ./myhdl.vpi -M/usr/lib/ivl bug1
Traceback (most recent call last):
  File "m.py", line 71, in <module>
    tb = traceSignals(main)
  File "/usr/local/lib/python2.7/site-packages/myhdl/_traceSignals.py", line 82, 
in __call__
    h = _HierExtr(name, dut, *args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/myhdl/_extractHierarchy.py", line 
231, in __init__
    _top = dut(*args, **kwargs)
  File "m.py", line 41, in main
    tb = bug1(clk, rst, CoSim)
  File "m.py", line 23, in bug1
    cosim = Cosimulation(cmd, clk = clk, rst = rst)
  File "/usr/local/lib/python2.7/site-packages/myhdl/_Cosimulation.py", line 88, 
in __init__
    raise CosimulationError(_error.SimulationEnd)
myhdl.CosimulationError: Premature simulation end
Exception TypeError: 'isinstance() arg 2 must be a class, type, or tuple of 
classes and types' in <function _remove at 0xb7390ca4> ignored
-----

If I run vvp from the shell (which seems normal behaviour):
$ /usr/bin/vvp -m ./myhdl.vpi -M/usr/lib/ivl bug1
ERROR: no write pipe to myhdl
FROM 0 clk 1 rst 1
$ 

The running version with input+output:
-----
import os
from myhdl import *

path = "/usr/"  # icarus install path


def bug1(clk, rst, vin, vout, CoSim=False):

    #v = Signal(modbv()[3:])

    @always(clk.posedge)
    def dobug1():
        vv = 0
        if not rst:
            vv = vin + 1
        vout.next = vv

    if CoSim:
        cmd = path + 'bin/iverilog -o bug1 bug1.v tb_bug1.v'
        print "==", cmd
        os.system(cmd)
        cmd = path + 'bin/vvp -m ./myhdl.vpi -M' + path + 'lib/ivl bug1'
        print "==", cmd
        cosim = Cosimulation(cmd, clk = clk, rst = rst, vin = vin, vout = vout)
        return cosim
    else:
        return dobug1


if __name__ == "__main__":

    clk = Signal(bool(1))
    rst = Signal(bool(0))
    vi = Signal(modbv()[3:])
    vo = Signal(modbv()[3:])

    toVerilog(bug1, clk, rst, vi, vo)
    print "bug1.v generated"

    def main():

        period = 10  # clock period in ns

        tb = bug1(clk, rst, vi, vi, CoSim)

        @instance
        def clkgen():
            clk.next = 0
            while True:
                yield delay(period // 2)
                clk.next = not clk

        @instance
        def rstgen():
            rst.next = 1
            yield delay(2*period)
            rst.next = 0

        @always(clk.posedge)
        def stop():
            if now() > 95:
                print "Simulation stopped at t =", now()
                raise StopSimulation

        return instances()

    CoSim = False
    tb = traceSignals(main)
    sim = Simulation(tb)
    sim.run()
    print "MyHDL simulation done"

    CoSim = True
    tb = traceSignals(main)
    sim = Simulation(tb)
    sim.run()
    print "MyHDL Verilog Co-simulation done"

-----

Re: [myhdl-list] Verilog Cosimulation: dut with only inputs fails

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

On 3/27/2013 8:56 AM, Jan wrote:
> On 25/03/13 15:51, Jos Huisken wrote:
>> Hi,
>>
>> Trying to do a verilog co-simulation, having a DUT with only inputs.
>> Message:
>> ...
>> myhdl.CosimulationError: Premature simulation end
>> Exception TypeError: 'isinstance() arg 2 must be a class, type, or tuple of
>> classes and types' in <function _remove at 0xb73b2d14> ignored
>>
>> Or did I miss something?
> perhaps this:
>       ./myhdl.vpi: Unable to find module file `./myhdl.vpi' or
> `./myhdl.vpi.vpl.vpi'.
> it looks severe to me, but then...
>

Nice observation Jan C.  I missed this when I
first skimmed the information.


Jos - You need to goto the Comsimulation directory
in the myhdl package source you downloaded or pulled
and build the dynamic lib for your system (i.e. run
the Makefiles) and then copy the myhdl.vpi to your
directory.

If you need any additional guidance building the VPI
interface let us know.

Regards,
Chris

Re: [myhdl-list] Verilog Cosimulation: dut with only inputs fails

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

On 25/03/13 15:51, Jos Huisken wrote:
> Hi,
>
> Trying to do a verilog co-simulation, having a DUT with only inputs.
> Message:
> ...
> myhdl.CosimulationError: Premature simulation end
> Exception TypeError: 'isinstance() arg 2 must be a class, type, or tuple of
> classes and types' in <function _remove at 0xb73b2d14> ignored
>
> Or did I miss something?
perhaps this:
     ./myhdl.vpi: Unable to find module file `./myhdl.vpi' or 
`./myhdl.vpi.vpl.vpi'.
it looks severe to me, but then...


jan@T60:~/work/projects/MyHDL/coSimulation/2013-03-25_JosHuisken$ 
python bug1_JH.py
bug1.v generated
Simulation stopped at t = 100
MyHDL simulation done
== /usr/bin/iverilog -o bug1 bug1.v tb_bug1.v
== /usr/bin/vvp -m ./myhdl.vpi -M/usr/lib/ivl bug1
./myhdl.vpi: Unable to find module file `./myhdl.vpi' or 
`./myhdl.vpi.vpl.vpi'.
tb_bug1.v:7: Error: System task/function $from_myhdl() is not 
defined by any module.
bug1: Program not runnable, 1 errors.
Traceback (most recent call last):
   File "bug1_JH.py", line 75, in <module>
     tb = traceSignals(main)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line 
82, in __call__
     h = _HierExtr(name, dut, *args, **kwargs)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/_extractHierarchy.py", 
line 231, in __init__
     _top = dut(*args, **kwargs)
   File "bug1_JH.py", line 45, in main
     tb = bug1(clk, rst, CoSim)
   File "bug1_JH.py", line 26, in bug1
     cosim = Cosimulation(cmd, clk = clk, rst = rst)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/_Cosimulation.py", line 
88, in __init__
     raise CosimulationError(_error.SimulationEnd)
myhdl.CosimulationError: Premature simulation end
Exception TypeError: 'isinstance() arg 2 must be a class, type, or 
tuple of classes and types' in <bound method 
__AptDpkgPackageInfo.__del__ of 
<apport.packaging_impl.__AptDpkgPackageInfo instance at 0x8a70c6c>> 
ignored
jan@T60:~/work/projects/MyHDL/coSimulation/2013-03-25_JosHuisken$

Jan Coombs

Re: [myhdl-list] Verilog Cosimulation: dut with only inputs fails

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

On 3/25/2013 10:51 AM, Jos Huisken wrote:
> Hi,
>
> Trying to do a verilog co-simulation, having a DUT with only inputs.
> Message:
> ...
> myhdl.CosimulationError: Premature simulation end
> Exception TypeError: 'isinstance() arg 2 must be a class, type, or tuple of
> classes and types' in <function _remove at 0xb73b2d14> ignored
>

This error can be thrown if there is an issue with the
Verilog simulation command or an error occurs in the
Verilog simulator.  I would double check the command
and that no error is encountered in the simulator.

I can check your module but it will be a couple days
before I get a chance to run it against Icarus.

Regards,
Chris Felton

[myhdl-list] Verilog Cosimulation: dut with only inputs fails

[Jos H. <jos...@gm...>]

Hi,

Trying to do a verilog co-simulation, having a DUT with only inputs.
Message:
...
myhdl.CosimulationError: Premature simulation end
Exception TypeError: 'isinstance() arg 2 must be a class, type, or tuple of 
classes and types' in <function _remove at 0xb73b2d14> ignored

Or did I miss something?

Exposed by this example:
---
from myhdl import *

path = "/usr/"  # icarus install path


def bug1(clk, rst, CoSim=False):

    v = Signal(modbv()[3:])

    @always(clk.posedge)
    def dobug1():
        vv = 0
        if not rst:
            vv = v + 1
        v.next = vv

    if CoSim:
        cmd = path + 'bin/iverilog -o bug1 bug1.v tb_bug1.v'
        print "==", cmd
        os.system(cmd)
        cmd = path + 'bin/vvp -m ./myhdl.vpi -M' + path + 'lib/ivl bug1'
        print "==", cmd
        cosim = Cosimulation(cmd, clk = clk, rst = rst)
        return cosim
    else:
        return dobug1


if __name__ == "__main__":

    clk = Signal(bool())
    rst = Signal(bool())
    v = Signal(modbv()[3:])

    toVerilog(bug1, clk, rst)
    print "bug1.v generated"

    def main():

        period = 10  # clock period in ns

        tb = bug1(clk, rst, CoSim)

        @instance
        def clkgen():
            clk.next = 1
            while True:
                yield delay(period // 2)
                clk.next = not clk

        @instance
        def rstgen():
            rst.next = 1
            yield delay(2*period)
            rst.next = 0

        @always(clk.posedge)
        def stop():
            if now() > 95:
                print "Simulation stopped at t =", now()
                raise StopSimulation

        return instances()

    CoSim = False
    tb = traceSignals(main)
    sim = Simulation(tb)
    sim.run()
    print "MyHDL simulation done"

    CoSim = True
    tb = traceSignals(main)
    sim = Simulation(tb)
    sim.run()
    print "MyHDL Verilog Co-simulation done"

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 03/01/2013 11:04 PM, Per Karlsson wrote:
> Hm, you don't like "always" or "never", but "invariably" is OK?

So you choose to ignore the obvious difference between an
adverb that simply qualifies an observed fact and a methodology
guideline which I don't want to carve in stone. Irritating.

> So somewhat on topic: I believe our approaches to combinatorial logic
> is much the same, we just came there from opposite directions: For me
> it is obvious that some combinatorial logic sometimes ripples,
> therefore I assume a combinatorial assertion happens when the net is
> stable. If I think about it I realize there are times when a strict
> assertion is beneficial, so then I'd like that as an option as well.
> For you the features come in the opposite order.

No, it's not a matter of order.  I argue that in the context of
MyHDL/VHDL, the inclination of see a hardware interpretation behind
any  HDL line or feature is simply wrong, and leads to a suboptimal
design methodology.

For example, there is nothing in the VHDL LRM about a hardware
interpretation. In particular, the goal of delta cycles is to
let event-driven models converge, not to model the rippling of
comibinatorial logic. Likewise, there is no such thing as a
"combinatorial assertion".

The point is that HDLs have an expressive value by themselves,
regardless of any direct hardware interpretion. Those who understand
that accomplish more in less time.

-- 
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] Function calls in combinatorial blocks

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

On 3/1/13 3:16 PM, Christopher Felton wrote:
> On 3/1/2013 9:12 AM, Per Karlsson wrote:
>> Hi!
>> Is there a particular reason that we do not support function calls in
>> combinatorial blocks?
>>
>
> I don't know if there is a reason, my guess is
> not.  But it is currently *not* supported.  To
> have the feature added it is ideal to create a
> MEP describing the feature.  Can simply start
> by describing the enhancement request to the
> mailing-list.
>
> My opinion, there are two levels: modeling and
> conversion.  In some cases we might want to take
> baby steps to implement, first just add for modeling
> and then for conversion.

I should clarify, this works for "modeling" you can
have a function on the right hand side, I was speaking
generally in the second paragraph.

Best of my knowledge, functions as described (on the RHS
of and assignment) are not convertible but I don't see
why we can't create a MEP and add it to the list of
future features.

Regards,
Chris

Re: [myhdl-list] Design West

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

On 11/9/2012 3:14 AM, Jan Decaluwe wrote:
> Hello:
>
> CLive Maxfield from APP suggested to participate with
> a paper about MyHDL/Python in the Design West conference,
> in the "Processors and Programmable Devices" that he
> chairs.
>
> http://www.ubmdesign.com
>
> Deadline for abstract submission is TODAY however :-)
>
> I really don't have time - too many things on my plate,
> moreover I can't justify the long trip without a concrete
> business aspect to it.
>
> But perhaps a MyHDL'er nearer to the conference is
> interested? I think a MyHDL paper will be welcomed.
>
> Jan
>
>

I responded to the call (this was a couple of months
ago now) and submitted an abstract.  Being a last minute
effort I threw something together during lunch that day.
The quick effort was random and probably reflects items on
my mind that day.  Regardless, it was accepted.

 >> Go here and select only the “Processors and Programmable
 >> Devices” track
 >>
 >> http://www.ubmdesign.com/sanjose/schedule-builder/list
 >>
 >> And here’s a direct link to your session
 >>
 >> http://www.ubmdesign.com/sanjose/schedule-builder/session-id/96

The white-paper and presentation will be an introduction
(primer) and my experiences with MyHDL.

If anyone is attending or from/in the area feel free to
contact me and we can arrange a meeting.  The "expo" is
free but the tutorials and seminars have a significant
cost.

I am also meeting with other folks in the area during the
week if anyone wants to talk/discuss MyHDL let me know!
I might be able to meet at different locations.

Regards,
Chris Felton

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Per K. <bas...@gm...>]

Hm, you don't like "always" or "never", but "invariably" is OK? I'll grant
you, the "error or annoyance" thing was a bit harsh though...

Anyway, I have no interest in exchanging insults, I just want MyHdl to
become the best hardware design language it can be. Please try to see the
opportunity in someone whose design philosophy is the opposite of yours but
who's still deeply invested in MyHdl.

I don't think there is a contradiction between "thinking hardware" and
modern software development. I'm very hardware-focused, but I yearn for the
possibilities of a real programming language.
I don't deem the future of (general*) hardware design to be high level
synthesis for software guys, I think it lies in giving hardware guys the
proper tools and teaching them how to use them.

So somewhat on topic: I believe our approaches to combinatorial logic is
much the same, we just came there from opposite directions:
For me it is obvious that some combinatorial logic sometimes ripples,
therefore I assume a combinatorial assertion happens when the net is
stable.
If I think about it I realize there are times when a strict assertion is
beneficial, so then I'd like that as an option as well.
For you the features come in the opposite order.

-Cheers!
/Per

* There is of course a bright future for high level synthesis for some
narrowly delimited applications.


On Fri, Mar 1, 2013 at 5:24 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 02/26/2013 10:52 PM, Per Karlsson wrote:
> > Hi guys! I'm just back from vacation. It seems to me that Jan and I
> > should both try to keep a little cooler than we are used to when
> > we're in the same discussion. I remember no "big" words from my
> > keyboard, but I shall try to keep them smaller still. :D
>
> I don't like it if something which is clearly a feature is
> described as either an error or an annoyance. And I certainly
> don't like it if such an analysis is based on the
> "think hardware" conventional wisdom, which is my enemy in
> HDL design and which is why I am actually developing MyHDL.
>
> > So, first a little background: Yes, guilty as charged, I am mostly a
> > Verilog person. I've spent only a few years with VHDL, and the rest
> > of the time with Verilog. Therefore I am quite biased.
> >
> > I think VHDL is chatty, and for me it's harder to think about
> > hardware in VHDL than in Verilog; and I always think about hardware
> > when I design RTL. For me RTL is not programming, it is a way to
> > describe hardware.
>
> I am tired of such statements. Invariably, they are used as an excuse
> for not learning the language in its full expressiveness, and for
> ignoring the valuable lessons from software engineering.
>
> > That said I'm very happy that I found MyHdl, because it allows me to
> > write hardware in the leaf-cells, but I can use actual programming to
> > build up the system from the basic blocks and in the testbenches.
> >
> > Normally I would either build Verilog from strings in Perl, or riddle
> > my Verilog with code-words and then run it through a Perl
> > pre-processor (depending on the needs of a particular design). MyHdl
> > allows me to stay in the same language and use Verilog as a netlist
> > format. I'm quite pleased with the design and test environments I
> > have set up using MyHdl, and they are going to get really nice when
> > MEP108 is implemented!
> >
> > Now, on topic: So, Jan, you are saying that we should never write
> > hardware where a combinatorial calculation takes more than one delta
> > cycle?
>
> No I don't say that. I don't like words like "never" or "always" -
> delta cycles have their role.
>
> What I am saying is that the systematic usage of delta cycles and
> events as an implicit way to order a sequence of calculations is
> a bad idea, given that the language has many provisions to do
> so directly, explicitly and locally, without events and delta cycles.
>
> I personally don't see how that is possible,
>
> Really? Well, my designs typically use close to 0 delta cycles. I may use
> some combinatorial logic to condition some inputs/outputs, but
> that's basically it. Everything is basically done in clocked processes.
> BTW - that's much closer to the original meaning of RTL -
> Register Transfer Level. True RTL languages don't have events,
> delta cycles, or explicit combinatorioal logic.
>
> > but I have some
> > respect for the amount of thinking that you have done in this area so
> > I am open to the possibility that you will convince me otherwise.
>
> I am not trying to "convince" anyone - everything is provided
> for free here so one should convince oneself, or not.
>
> All I'm doing is pointing out misunderstandings and managing
> (possibly false) expectations for efficiency reasons. Noone
> should lose time unnecessarily.
>
> > It may be my hardware background fooling me (I started out as a
> > rectangle pusher), but for me glitches in combinatorial nets are near
> > unavoidable.
>
> Of course not.
>
> > You can of course balance all the paths to make the
> > logic glitch-free, but its hardly worth the hassle unless you are
> > designing clock gating or a reset signal.
> >
> > This is not to say, of course, that the language has to mimic the
> > ripple behavior of physical hardware to be of any use.
>
> That is the point. In synchronous design, that ripple behavior
> is irrelevant.
>
> > But still,
> > when sub-blocks or IPs have combinatorial inputs and outputs, or when
> > there is a combinatorial path through a block I don't see how it is
> > avoidable.
>
> All IP blocks should have registered outputs. This is just a matter
> of complexity management: localization of concerns.
>
> > You shouldn't take my rant about partitioning design too seriously, I
> > usually go a bit overboard when I try to prove a point. Certainly a
> > single process is best in a self-contained system with few
> > dependencies
>
> Dependencies are not a given, but something that you can
> manage and that should be minimized when partitioning a design.
>
> but it is really the only way?
>
> No. It's only the way I prefer.
>
> >
> > On Tue, Feb 26, 2013 at 8:45 PM, Jan Decaluwe <ja...@ja...
> > <mailto:ja...@ja...>> wrote:
> >
> > On 02/26/2013 08:02 PM, Christopher Felton wrote:
> >> On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
> >>> Chris:
> >>>
> >>> We are overthinking this. Forget about delta cycles,
> >>> combinatorial logic and race conditions.
> >>
> >> Fair enough.
> >>
> >>>
> >>> What we have is a language that hopefully tries to help us to
> >>> write better, clearer code.
> >>>
> >>> A signal assignment is an assignment also (albeit to a future
> >>> value which may or may not be overwritten.) When a designer
> >>> specifies explicitly that a variable/signal should *always* be
> >>> within a range that he specifies, it is a good thing that the
> >>> language flags a violation immediately. The fact that signals
> >>> have complex postponed behavior is a secondary issue.
> >>>
> >>> What disturbs me a little in this discussion is the Verilog
> >>> angle. I think it is rather clear that VHDL is my reference for
> >>> "good design" (and Verilog for "very bad design"). No?
> >>
> >> It was inadvertent.  It was not the goal to imply myhdl should
> >> behave like Verilog.  The oversight was --as you identified-- not
> >> jumping to the VHDL example using a similar type, that is: the
> >> constraint integer.
> >
> > Chris - I was not targetting you in any way. I fully understand how
> > you try to be helpful and open to arguments.
> >
> > I referred to the OP (Mr. Karlsson). Yes, I have a problem with
> > people who, after looking at MyHDL superficially from just one angle
> > (Verilog), immediately start using big words and declarations just
> > because it doesn't look exactly like what they are used to.
> >
> > Moreover - because of Verilog's bad design choices (e.g. not making a
> > difference between signals/variables) what many Verilog designers are
> > used to as a coding style is equally bad. Using that as the norm is
> > just too crazy for words to me.
> >
> > All of this is of course just my personal opinion - but I made it
> > abundantly clear on many occasions. Quite obviously, MyHDL is my
> > attempt to offer a sensible Verilog alternative to those that share
> > this analysis.
> >
> >> I am in agreement but I may beat on this topic some more, purely so
> >> that I have a consistent and concise understanding for future
> >> communications.
> >
> > No problem. For example: it is *definitely* a problem when an
> > "invalid" value sneaks through delta cycle. A signal monitor has no
> > way to know where it is in delta cycle convergence process.
> > Therefore, it could take seemingly "impossible" decisions based on
> > that invalid value.
> >
> > (I am not talking about hardware here, but about the language as it
> > may be used in models and test benches. The inclination to interprete
> > everything in a hardware sense is another sign of a bad
> > methodology.)
> >
> > -- 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
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics Download AppDynamics Lite
> > for free today: http://p.sf.net/sfu/appdyn_d2d_feb
> > _______________________________________________ myhdl-list mailing
> > list myh...@li...
> > <mailto:myh...@li...>
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics Download AppDynamics Lite
> > for free today: http://p.sf.net/sfu/appdyn_d2d_feb
> >
> >
> >
> > _______________________________________________ myhdl-list mailing
> > list myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-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
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>