myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Re: always_comb problem

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

David Brochart wrote:
> Or maybe there is a better way to do it. Could we have comments around the area
> of code we want to ignore, like this:
>     #Translate off
>     print ...
>     #Translate on
> This would allow us to add more options in the future.

I don't like this kind of "comment abuse". Code that
is supposed to have some significant effect, should be
part of the language definition in my opinion. Something
like the above could be alternatively done by defining
"pragma's" using the syntax of the language.

Note that Verilog (from where I suppose you got the
inspiration) has moved to dedicated pragma syntax in
SystemVerilog, for synthesis directives etc.

A related practical problem is that comments are not
part of the abstract syntax tree as produced by the
Python compiler package. This would mean that some
dedicated special processing would be required to
support comment processing - not good.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] VCD generation bug

[David B. <dav...@fr...>]

There is a bug in the generation of the VCD file. In the following exampl=
e:

-------------------------------------------------------------------------=
--

from myhdl import intbv, Signal, Simulation, delay, traceSignals

def gen(a):
    while 1:
        a.next =3D 0
        yield delay(10)
        a.next =3D 1
        yield delay(10)

def dummy(a):
    b =3D Signal(intbv(0))
    b_i0 =3D gen(b)
    return b_i0

def test():
    a =3D Signal(intbv(0))
    a_i0 =3D gen(a)
    dummy_i0 =3D dummy(a)
    return a_i0, dummy_i0

test =3D traceSignals(test)
sim =3D Simulation(test)
sim.run(100)

-------------------------------------------------------------------------=
--

You can see in the generated VCD file that several signals have the same
identifier. Also, signals in "a_i0" are not traced.

Regards,

David.

[myhdl-list] Re: always_comb problem

[David B. <dav...@fr...>]

Or maybe there is a better way to do it. Could we have comments around th=
e area
of code we want to ignore, like this:
    #Translate off
    print ...
    #Translate on
This would allow us to add more options in the future.

Regards,

David.



Selon David Brochart <dav...@fr...>:

> I think this is a good solution indeed, it would work for "always_comb"=
 a=3D
> nd
> "toVerilog".
>
> Thanks,
>
> David.
>
> Selon Jan Decaluwe <ja...@ja...>:
>
> > David Brochart wrote:
> > > Thanks for the explanation. I use "print" statements as debug funct=
io=3D
> ns but
> > I
> > > could as well use graphical functions if I do signal processing. In=
 o=3D
> ther
> > words
> > > in this example the problem was caused by "print" but it could be a=
ny=3D
> thing
> > that
> > > is not a signal or variable affectation. Then your solution doesn't=
 w=3D
> ork.
> > > Rather than adding a "pass" for everything we want to skip, we shou=
ld=3D
>  only
> > > "keep" the signal/variable affectations and "pass" everything else.=
 I=3D
> s
> > there a
> > > way to do that?
> >
> > Well, there may be an easy way to do this provided
> > there is some explicit help from the user.
> >
> > Actually there is a similar problem with conversion to
> > Verilog: sometimes one would like to add code (e.g.
> > for debug) that should be "hidden" from conversion (e.g.
> > because it contains non-convertible constructs.)
> >
> > A clean way to support this would be to use Python's
> > prefined __debug__ variable. (This is true by default,
> > and false when python is invoked with optimizations.)
> >
> > All code below an "if __debug__:" could simply be
> > ignored (for always_comb and also conversion.) So this
> > would be a general way for a user to add arbitrary code,
> > but of course he would have to state this explicitly.
> > But, as Explicit Is Better Than Implicit this may not
> > even be a disadvantage. Note that the actual value
> > of __debug__ would not be taken into consideration.
> >
> > What do you think?
> >
> > Regards, Jan
> >
> > --
> > Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> > Losbergenlaan 16, B-3010 Leuven, Belgium
> >     Python is fun, and now you can design hardware with it:
> >     http://jandecaluwe.com/Tools/MyHDL/Overview.html
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Sybase ASE Linux Express Edition - download now for FREE
> > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > http://ads.osdn.com/?ad_id=3D3D5588&alloc_id=3D3D12065&op=3D3Dclick
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Re: always_comb problem

[David B. <dav...@fr...>]

I think this is a good solution indeed, it would work for "always_comb" a=
nd
"toVerilog".

Thanks,

David.

Selon Jan Decaluwe <ja...@ja...>:

> David Brochart wrote:
> > Thanks for the explanation. I use "print" statements as debug functio=
ns but
> I
> > could as well use graphical functions if I do signal processing. In o=
ther
> words
> > in this example the problem was caused by "print" but it could be any=
thing
> that
> > is not a signal or variable affectation. Then your solution doesn't w=
ork.
> > Rather than adding a "pass" for everything we want to skip, we should=
 only
> > "keep" the signal/variable affectations and "pass" everything else. I=
s
> there a
> > way to do that?
>
> Well, there may be an easy way to do this provided
> there is some explicit help from the user.
>
> Actually there is a similar problem with conversion to
> Verilog: sometimes one would like to add code (e.g.
> for debug) that should be "hidden" from conversion (e.g.
> because it contains non-convertible constructs.)
>
> A clean way to support this would be to use Python's
> prefined __debug__ variable. (This is true by default,
> and false when python is invoked with optimizations.)
>
> All code below an "if __debug__:" could simply be
> ignored (for always_comb and also conversion.) So this
> would be a general way for a user to add arbitrary code,
> but of course he would have to state this explicitly.
> But, as Explicit Is Better Than Implicit this may not
> even be a disadvantage. Note that the actual value
> of __debug__ would not be taken into consideration.
>
> What do you think?
>
> Regards, Jan
>
> --
> Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>     Python is fun, and now you can design hardware with it:
>     http://jandecaluwe.com/Tools/MyHDL/Overview.html
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Re: always_comb problem

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

David Brochart wrote:
> Thanks for the explanation. I use "print" statements as debug functions but I
> could as well use graphical functions if I do signal processing. In other words
> in this example the problem was caused by "print" but it could be anything that
> is not a signal or variable affectation. Then your solution doesn't work.
> Rather than adding a "pass" for everything we want to skip, we should only
> "keep" the signal/variable affectations and "pass" everything else. Is there a
> way to do that?

Well, there may be an easy way to do this provided
there is some explicit help from the user.

Actually there is a similar problem with conversion to
Verilog: sometimes one would like to add code (e.g.
for debug) that should be "hidden" from conversion (e.g.
because it contains non-convertible constructs.)

A clean way to support this would be to use Python's
prefined __debug__ variable. (This is true by default,
and false when python is invoked with optimizations.)

All code below an "if __debug__:" could simply be
ignored (for always_comb and also conversion.) So this
would be a general way for a user to add arbitrary code,
but of course he would have to state this explicitly.
But, as Explicit Is Better Than Implicit this may not
even be a disadvantage. Note that the actual value
of __debug__ would not be taken into consideration.

What do you think?

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: always_comb problem

[David B. <dav...@fr...>]

Thanks for the explanation. I use "print" statements as debug functions b=
ut I
could as well use graphical functions if I do signal processing. In other=
 words
in this example the problem was caused by "print" but it could be anythin=
g that
is not a signal or variable affectation. Then your solution doesn't work.
Rather than adding a "pass" for everything we want to skip, we should onl=
y
"keep" the signal/variable affectations and "pass" everything else. Is th=
ere a
way to do that?

David.

Selon Jan Decaluwe <ja...@ja...>:

> David Brochart wrote:
> > Hello,
> >
> > In the following code:
> >
> > ---------------------------------------------------------------------=
-----
> >
> > from myhdl import intbv, Signal, Simulation, instances, delay, always=
_comb
> >
> > def test(a, b):
> >     c =3D intbv(2)
> >     def testFunc():
> >         b.next =3D a.val + c
> >         print b.val, a.val
> >     return always_comb(testFunc)
> >
> > def a_gen(a):
> >     while 1:
> >         yield delay(10)
> >         a.next =3D a.val + 1
> >
> > def top():
> >     a =3D Signal(intbv(0))
> >     b =3D Signal(intbv())
> >     test_i =3D test(a, b)
> >     a_gen_i =3D a_gen(a)
> >     return instances()
> >
> >
> > top_inst =3D top()
> > sim =3D Simulation(top_inst)
> > sim.run(100)
> >
> > ---------------------------------------------------------------------=
-----
> >
> > It seems that the "always_comb" function doesn't like the "print" in =
the
> "test"
> > function.
>
> Correct. Here's the background:
>
> always_comb inspects source code to see how signals are used. It flags
> "inout"
> usage as an error. Normally this is what you want (to get combinatorial
> semantics),
> but it may be too severe on "innocent" cases, as in this case.
>
> For those interested, I'll explain how this happens in the myhdl source=
 code,
> as well as the solution. Source inspection occurs by traversing an abst=
ract
> syntax tree, generated using the Python compiler package. See class
> _SigNameVisitor
> in the file myhdl/_always_comb.py. Adding the follows methods solves th=
is
> problem
> by avoiding that the traversal proceeds through print statements:
>
> class _SigNameVisitor(object):
>     ....
>     ....
>
>     def visitPrintnl(self, node):
>         pass # skip
>
>     def visitPrint(self, node):
>         pass # skip
>
> If have implemented this patch in my development tree, and the resultin=
g
> file is attached.
>
> > If I use the "while 1 - yield" structure it works fine, but it would
> > be nice to be able to use "always_comb" and still be able to insert d=
ebug
> > functions inside the code.
>
> But isn't it confusing that you will not necessarily see the resulting
> output value at the correct time (as the generator is not sensitive
> to the output signal)?
>
> Regards, Jan
>
> --
> Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>     Python is fun, and now you can design hardware with it:
>     http://jandecaluwe.com/Tools/MyHDL/Overview.html
>

[myhdl-list] Re: Signal initialization

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

David Brochart wrote:
> There is another issue that I would like to bring up. In the following code:
> 
> -------------------------------------------------------------
> 
> from myhdl import intbv, Signal, Simulation, instances, delay
> 
> def test(a, b, c):
>     while 1:
>         yield a, b
>         c.next = a.val + b.val
>         print "Test function executed"
> 
> def a_gen(a):
>     while 1:
>         yield delay(10)
>         a.next = 0
> 
> def top():
>     a = Signal(intbv(0))
>     b = Signal(intbv(1))
>     c = Signal(intbv())
>     a_gen_i = a_gen(a)
>     test_i = test(a, b, c)
>     return instances()
> 
> 
> top_inst = top()
> sim = Simulation(top_inst)
> sim.run(100)
> 
> -------------------------------------------------------------
> 
> The "test" function is never executed, because "a" and "b" never change their
> value (always 0 and 1 respectively). It means that if another function uses the
> "c" output value of "test", it will be wrong.

It's exactly what you should expect according to MyHDL semantics, or VHDL
or Verilog for that matter. The problem is rather that you expect this
template to correspond to combinatorial logic, which is not correct. Of
course the expectation is understandable because virtually everybody has
it. But still, it's based on a historical error introduced by synthesis
tools vendors. See further.

> A workaround would be to initialize "a" like this:
> 
> a = Signal(intbv(None))
> 
> So that "a" changes its value in the "a_gen" function. But then I found out that
> in the general case it causes too many problems because some inputs might not be
> initialized (still at "None") when the code is executed, resulting in an error.
> We can solve this by executing the code only if all the input values are
> different than "None". Writing this condition after every "yield" statement is
> not very beautiful (maybe MyHDL could resume the function only if all the input
> values are different than "None"?).

Mm, this is complicated and would introduce "special" behavior which is going
to be confusing. Quoting from the Zen of Python (>>> import this):
"Special cases aren't special enough to break the rules." :-)

> Another workaround would be to initialize "a" like that:
> 
> a = Signal(intbv(0))
> 
> and writing "test" with the "yield" statement at the end:
> 
> def test(a, b, c):
>     while 1:
>         c.next = a.val + b.val
>         print "Test function executed"
>         yield a, b
> 
> This way, "test" is always executed at least once. I don't know if "always_comb"
> corresponds to this configuration though.

Exactly. That's how the combinatorial template should have been in the first place.
And yes, that's how always_comb in SystemVerilog works. And also how it works in
MyHDL therefore. See the code in _always_comb.py, you'll see the actual generator
with the sensitivity list at the end.

Background: in Verilog, the problem would often not be apparent, because all
regs are implicitly initialized on x, which means that an event occurs as
soon as they get a defined value.

However, this doesn't mean that Verilog got it right. On the contrary, as is
typical of its zero delay behavior, it made a complete mess out of it. The
problem is what the following should do:

reg a = 1; # reg declaration plus assignment at the same time

In my opinion, the only sensible way to understand this would be as an
initialization. But Verilog chose to create an event from x->1 anyway,
for "compatibility". Or at least some simulators did. And this was how
it was described in the Verilog 2001 standard.

Finally, the SystemVerilog standardization realized the absurdity of the
above, and explicitly determined that it should be treated as an initialization
instead. In addition, it introduced the always_comb block with the semantics
of the sensitivity list at the end, as it should be.

Final note: there is a practical problem with synthesis. Synthesis tools may
not support the sensitivity list at the end (or the always_comb block of
SystemVerilog). Therefore, when a MyHDL always_comb is converted to
Verilog, I still put the sensitivity list at the beginning. This issue
is documented in section 6.7 of the manual.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Signal initialization

[David B. <dav...@fr...>]

There is another issue that I would like to bring up. In the following co=
de:

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

from myhdl import intbv, Signal, Simulation, instances, delay

def test(a, b, c):
    while 1:
        yield a, b
        c.next =3D a.val + b.val
        print "Test function executed"

def a_gen(a):
    while 1:
        yield delay(10)
        a.next =3D 0

def top():
    a =3D Signal(intbv(0))
    b =3D Signal(intbv(1))
    c =3D Signal(intbv())
    a_gen_i =3D a_gen(a)
    test_i =3D test(a, b, c)
    return instances()


top_inst =3D top()
sim =3D Simulation(top_inst)
sim.run(100)

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

The "test" function is never executed, because "a" and "b" never change t=
heir
value (always 0 and 1 respectively). It means that if another function us=
es the
"c" output value of "test", it will be wrong.
A workaround would be to initialize "a" like this:

a =3D Signal(intbv(None))

So that "a" changes its value in the "a_gen" function. But then I found o=
ut that
in the general case it causes too many problems because some inputs might=
 not be
initialized (still at "None") when the code is executed, resulting in an =
error.
We can solve this by executing the code only if all the input values are
different than "None". Writing this condition after every "yield" stateme=
nt is
not very beautiful (maybe MyHDL could resume the function only if all the=
 input
values are different than "None"?).
Another workaround would be to initialize "a" like that:

a =3D Signal(intbv(0))

and writing "test" with the "yield" statement at the end:

def test(a, b, c):
    while 1:
        c.next =3D a.val + b.val
        print "Test function executed"
        yield a, b

This way, "test" is always executed at least once. I don't know if "alway=
s_comb"
corresponds to this configuration though.

David.

[myhdl-list] Re: always_comb problem

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

David Brochart wrote:
> Hello,
> 
> In the following code:
> 
> --------------------------------------------------------------------------
> 
> from myhdl import intbv, Signal, Simulation, instances, delay, always_comb
> 
> def test(a, b):
>     c = intbv(2)
>     def testFunc():
>         b.next = a.val + c
>         print b.val, a.val
>     return always_comb(testFunc)
> 
> def a_gen(a):
>     while 1:
>         yield delay(10)
>         a.next = a.val + 1
> 
> def top():
>     a = Signal(intbv(0))
>     b = Signal(intbv())
>     test_i = test(a, b)
>     a_gen_i = a_gen(a)
>     return instances()
> 
> 
> top_inst = top()
> sim = Simulation(top_inst)
> sim.run(100)
> 
> --------------------------------------------------------------------------
> 
> It seems that the "always_comb" function doesn't like the "print" in the "test"
> function. 

Correct. Here's the background:

always_comb inspects source code to see how signals are used. It flags "inout"
usage as an error. Normally this is what you want (to get combinatorial semantics),
but it may be too severe on "innocent" cases, as in this case.

For those interested, I'll explain how this happens in the myhdl source code,
as well as the solution. Source inspection occurs by traversing an abstract
syntax tree, generated using the Python compiler package. See class _SigNameVisitor
in the file myhdl/_always_comb.py. Adding the follows methods solves this problem
by avoiding that the traversal proceeds through print statements:

class _SigNameVisitor(object):
    ....
    ....

    def visitPrintnl(self, node):
        pass # skip

    def visitPrint(self, node):
        pass # skip

If have implemented this patch in my development tree, and the resulting
file is attached.

> If I use the "while 1 - yield" structure it works fine, but it would
> be nice to be able to use "always_comb" and still be able to insert debug
> functions inside the code.

But isn't it confusing that you will not necessarily see the resulting
output value at the correct time (as the generator is not sensitive
to the output signal)?

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] always_comb problem

[David B. <dav...@fr...>]

Hello,

In the following code:

-------------------------------------------------------------------------=
-

from myhdl import intbv, Signal, Simulation, instances, delay, always_com=
b

def test(a, b):
    c =3D intbv(2)
    def testFunc():
        b.next =3D a.val + c
        print b.val, a.val
    return always_comb(testFunc)

def a_gen(a):
    while 1:
        yield delay(10)
        a.next =3D a.val + 1

def top():
    a =3D Signal(intbv(0))
    b =3D Signal(intbv())
    test_i =3D test(a, b)
    a_gen_i =3D a_gen(a)
    return instances()


top_inst =3D top()
sim =3D Simulation(top_inst)
sim.run(100)

-------------------------------------------------------------------------=
-

It seems that the "always_comb" function doesn't like the "print" in the =
"test"
function. If I use the "while 1 - yield" structure it works fine, but it =
would
be nice to be able to use "always_comb" and still be able to insert debug
functions inside the code.

Regards,

David.

[myhdl-list] Re: Suspending/Resuming/Stopping a simulation

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

bedros wrote:
> you could raise a SuspendSimulation exception and use
> "try" in the top level to catch it, fix it, and then
> resume the simulation by executing "run" method again.

(Sorry for the delayed response.)

It's more complicated. First, the run method catches
this exception itself. Moreover, it's not intended for
users to raise it. The simulation has both "real" time
steps and delta time steps. When you suspend, and then
continue, no events should be missed. Simply allowing
suspends at any moment makes this complicated. For that
reason the actual suspend occurs at a well defined
moment: at the end of a timestep, after delta cycle
convergence, right before real time is increased.

Probably the exception should be renamed _SuspendSimulation
to make this clear. This also explains why this exception
is not documented - you shouldn't use it.

The desired functionality could be implemented by introducing
a function, e.g. called suspend(), that a user could call.
This would set some global variable, and at the right time
the run method could then raise an exception that a user
could catch. In fact, we would need an exception that a
user would not be able to raise, only catch ... and this
would have to enforced by code to avoid mistakes. No
idea whether this is possible. Doesn't seem obvious, but
this is Python :-)

Regards, Jan

> 
> 
> 
> --- Frank Palazzolo <pal...@co...> wrote:
> 
>>>I couldn't find anything about SuspendSimulation,
>>
>>not
>>
>>>even in MyHDL 0.4 documents. Where did you find it?
>>
>>I just looked in the code...the beauty of open
>>source :)
>>
>>-Frank
>>
>>
>>
>>
>>
> 
> -------------------------------------------------------
> 
>>This SF.Net email sponsored by Black Hat Briefings &
>>Training.
>>Attend Black Hat Briefings & Training, Las Vegas
>>July 24-29 - 
>>digital self defense, top technical experts, no
>>vendor pitches, 
>>unmatched networking opportunities. Visit
>>www.blackhat.com
>>_______________________________________________
>>myhdl-list mailing list
>>myh...@li...
>>
> 
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com


-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: Verilog Generation issue - fixed signals

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

Frank Palazzolo wrote:

> So - is it possible to define constant signals within the heirarchy 
> in general?  I haven't been able to figure out how.  This is actually 
> pretty ugly, considering that I'd like generic modules at the bottom, 
> and I'd like to "hardcode" certain parameters on chip, with no 
> external signals for them outside the chip.

(Sorry for the delayed response.)

While generating Verilog, I can infer which internal signals
are not driven by others, and I deliberately chose to flag this
as an error (taking into consideration that the intent to go to
Verilog is likely synthesis and implementation).
This may have been a step too far. In the future, it may be
better to flag the issue as a warning instead of an error.

In addition, I would have to make sure that the reg gets
the proper initial value. One way would be at declaration time:

  reg [1:0] numchan = 3; # currently the initialization is not there

However, I don't know whether this is "synthesizable" in general.
Also, the semantics are ambiguous (it looks like initialization,
but in some simulators an event from x to 3 will be created.)

Another way would be to use assign statements - all synthesis tools
should understand those.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: python list of signals

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

Jan,

Thanks, that worked fine.

Jan Decaluwe wrote:

>
>
> This doesn't mean that you can't use lists of signals - the trick is to
> make sure to use them only during "elaboration". In other words, the
> restrictions to Verilog conversion only apply to the things at the
> lowest level - the generators. At the higher levels of the hierarchy,
> where you use plain functions, you have a lot of freedom, because
> the hierarchy is "elaborated" by the interpreter before conversion.


Thanks, that works fine.

Tom

[myhdl-list] Re: python list of signals

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

Tom Dillon wrote:
> I was trying to make a variable pipeline module with the following code:
> 
> def pipe(q, d, clk, stages=1):
>    """ pipe block
>      q      -- output, delayed d by stages pipe delays
>    d      -- input
>    clk    -- clock input
>    stages -- number of pipeline delays, 0 is no pipes
>    """
>    qReg = [Signal(intbv(0,0,q.max)) for i in range(stages)]
>    while 1:
>      if stages == 0 :
>        yield d
>        q.next = d
>      else :
>        yield posedge(clk)
>        if stages == 1 :
>          q.next = d
>        else :
>          qReg[0].next = d
>          q.next = qReg[stages-2]
>          for i in range(stages-2) :
>            qReg[i+1].next = qReg[i]
> 
> It simulates fine but the list of signals (qReg[]) isn't liked by the 
> Verilog converter.
> 
> stages is meant to be a compile time parameter and I would like to make 
> a variable number of signals based upon its value. Then easily use them 
> else where in the module.
> 
> If indeed this can't be converted, is there a simple way to accomplish 
> this.

At this moment, a list of signals itself is not mapped directly to Verilog.

Whether this would be possible or meaningful, using a Verilog memory, I'm not
sure. Verilog memories have certain strange restrictions,
and they may not be supported by synthesis.

This doesn't mean that you can't use lists of signals - the trick is to
make sure to use them only during "elaboration". In other words, the
restrictions to Verilog conversion only apply to the things at the
lowest level - the generators. At the higher levels of the hierarchy,
where you use plain functions, you have a lot of freedom, because
the hierarchy is "elaborated" by the interpreter before conversion.

BTW, the above explains also why I took this approach, as opposed to
trying to map the inferred hierarchy to Verilog. The way it is now,
you may be able to things that you couldn't do in Verilog (of
course) but *still* be able to convert!

Take a look at the test_RandomScrambler.py code in the
myhdl/test/toVerilog directory for an example.

[Sidenote: there is one disturbing issue that I still need to solve.
If you use lists of instances, where the instance is the result of
a direct generator call, conversion may not work. It has to do with
the difference between a plain function and a generator as seen by
the profiler. The workaround is to convert the generator into a
plain function with a local generator. If this sounds confusing,
again see test_RandomScrambler for an example (XorGate).]

Hope this helps,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] python list of signals

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

Frank,

Tried that with the same results. I'm sure there is an easy way to do 
this...

Tom


Frank Palazzolo wrote:

>>I was trying to make a variable pipeline module with the following code:
>>
>>def pipe(q, d, clk, stages=1):
>>    
>>
>
>Does it work if you take stages out of the function signature?  It may be
>that the Verilog generation assumes it is a Signal if it's in the
>signature..?
>
>Just a guess...
>-Frank
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>myhdl-list mailing list
>myh...@li...
>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>  
>

RE: [myhdl-list] python list of signals

[Frank P. <pal...@co...>]

>I was trying to make a variable pipeline module with the following code:
>
>def pipe(q, d, clk, stages=1):

Does it work if you take stages out of the function signature?  It may be
that the Verilog generation assumes it is a Signal if it's in the
signature..?

Just a guess...
-Frank

[myhdl-list] python list of signals

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

I was trying to make a variable pipeline module with the following code:

def pipe(q, d, clk, stages=1):
    """ pipe block
   
    q      -- output, delayed d by stages pipe delays
    d      -- input
    clk    -- clock input
    stages -- number of pipeline delays, 0 is no pipes
    """
    qReg = [Signal(intbv(0,0,q.max)) for i in range(stages)]
    while 1:
      if stages == 0 :
        yield d
        q.next = d
      else :
        yield posedge(clk)
        if stages == 1 :
          q.next = d
        else :
          qReg[0].next = d
          q.next = qReg[stages-2]
          for i in range(stages-2) :
            qReg[i+1].next = qReg[i]

It simulates fine but the list of signals (qReg[]) isn't liked by the 
Verilog converter.

stages is meant to be a compile time parameter and I would like to make 
a variable number of signals based upon its value. Then easily use them 
else where in the module.

If indeed this can't be converted, is there a simple way to accomplish this.

Thanks,
Tom Dillon

RE: [myhdl-list] Suspending/Resuming/Stopping a simulation

[bedros <be...@ya...>]

you could raise a SuspendSimulation exception and use
"try" in the top level to catch it, fix it, and then
resume the simulation by executing "run" method again.



--- Frank Palazzolo <pal...@co...> wrote:
> 
> >I couldn't find anything about SuspendSimulation,
> not
> >even in MyHDL 0.4 documents. Where did you find it?
> 
> I just looked in the code...the beauty of open
> source :)
> 
> -Frank
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings &
> Training.
> Attend Black Hat Briefings & Training, Las Vegas
> July 24-29 - 
> digital self defense, top technical experts, no
> vendor pitches, 
> unmatched networking opportunities. Visit
> www.blackhat.com
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

RE: [myhdl-list] Suspending/Resuming/Stopping a simulation

[Frank P. <pal...@co...>]

>I couldn't find anything about SuspendSimulation, not
>even in MyHDL 0.4 documents. Where did you find it?

I just looked in the code...the beauty of open source :)

-Frank

Re: [myhdl-list] Suspending/Resuming/Stopping a simulation

[bedros <be...@ya...>]

I use StopSimulation exception frequently if there's
an invalid condition in my simulation such as reading
from an empty FIFO.

eg: if ready_sig and FIFO.empty:
           raise StopSimulation,  "ERROR: reading from
empty fifo"

I couldn't find anything about SuspendSimulation, not
even in MyHDL 0.4 documents. Where did you find it?

-Bedros

--- Frank Palazzolo <pal...@co...> wrote:
> 
> Hello,
> 
> I'm interested in suspending a simulation after a
> certain event, and then
> resuming again, or possibly stopping.  The
> Simulation.run() call works for a
> fixed number of cycles.  Is there a way that I can
> use exceptions to do
> this?  I noticed that myhdl uses SuspendSimulation
> and StopSimulation
> internally to do this.
> 
> This might be a nice feature in general.  One could
> write a testbed which
> changes based on the simulation results. :)  
> 
> Thanks,
> Frank
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings &
> Training.
> Attend Black Hat Briefings & Training, Las Vegas
> July 24-29 -
> digital self defense, top technical experts, no
> vendor pitches,
> unmatched networking opportunities. Visit
> www.blackhat.com
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

[myhdl-list] Suspending/Resuming/Stopping a simulation

[Frank P. <pal...@co...>]

Hello,

I'm interested in suspending a simulation after a certain event, and =
then
resuming again, or possibly stopping.  The Simulation.run() call works =
for a
fixed number of cycles.  Is there a way that I can use exceptions to do
this?  I noticed that myhdl uses SuspendSimulation and StopSimulation
internally to do this.

This might be a nice feature in general.  One could write a testbed =
which
changes based on the simulation results. :) =20

Thanks,
Frank

[myhdl-list] Verilog Generation issue - fixed signals

[Frank P. <pal...@co...>]

Hello All,

Ok, I've sorted out my issue with Verilog Generation.  Sorry for the 
rather confused previous messages. :)

It turns out that my problem has to do with "Fixed" Signals, i.e. 
Signals which are defined like...

s = Signal(bool(0))

..which are used, but never set beyond initialization.

At the outermost level, these always seem to work.  You can set them 
in the testbed function and forget them, if you want.  I'm guessing 
that this is because they are defined outside the toVerilog() 
statement.  My problems show up if I try to use these at other levels 
of the heirarchy.

Inside of a generator, these always fail with "Can't infer variable 
type".  Granted, it's not too useful to use these inside of a 
generator, since it's not really a "Signal", so this isn't really a 
big deal.  It is a bit of a strange message, however.

The common case I am having trouble with is when you use one in a 
intermediate level, as in this oversimplified example...

def or_gate(a,b,c):
	while 1:
		yield a,b
		c = a | b

def my_bundle(p,q):
	x = Signal(bool(0))
	gen_or = or_gate(p,x,q)
	return instances()
		   
This fails with "signal is not driven".  I can get away with defining 
x = bool(0) in some cases.  However, in the general case this leads 
to another failure - because you can't yield on a non-signal. :(

So - is it possible to define constant signals within the heirarchy 
in general?  I haven't been able to figure out how.  This is actually 
pretty ugly, considering that I'd like generic modules at the bottom, 
and I'd like to "hardcode" certain parameters on chip, with no 
external signals for them outside the chip.

Thanks for any ideas,
Frank

[myhdl-list] Re: Explicit local state and verilog generation

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

Frank Palazzolo wrote:
> A small follow-up...  I realized later that my issue is really about
> type-definition, not state.  I want to bundle internal signal types along
> with a subsystem, and still be able to use verilog generation.  But I'm not
> sure which way is part of the convertable subset, if any.

Again, please send me a relevant example that fails.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: Explicit local state and verilog generation

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

Frank Palazzolo wrote:
> Hello,
> 
> I have an application which is doing something strange, and I'm wondering if
> it's my problem or MyHDL.  I am having problems with the verilog generation,
> not with simulation.
> 
> Let me explain via simplified examples:
> 
> Up until now, if I had explicit state inside a sequential logic block, I
> would define it at the outermost level.  So my generator looks like this:
> 
> def mycounter(clk,inbit,outbit,state):
> 	yield 1:
> 		if posedge(clk):
> 			if state < 12:
> 				state.next = state + 1
> 			else:
> 				state.next = 0
> 			outbit.next = state.next[4]

I assume the 'yield' should be 'while', and 'if posedge' should
be 'yield posedge'.

> State is defined outside, as I am not able to place it in the generator (for
> Verilog), though I would like to hide it.

Wait a moment - I don't follow this reasoning. Plain variables can also
contain state, and can be converted to Verilog. For example, the
following should work:

def mycounter(clk,inbit,outbit):
    state = intbv(0)[5:]
    while 1:
        yield posedge(clk)
        if state < 12:
            state += 1
        else:
            state[:] = 0
        outbit.next = state[4] # warning: will now have a clock cycle less delay

MyHDL makes the distinction between variables and signals (as VHDL, unlike
Verilog, but as it should be), but supports these in conversion by using
blocking vs. unblocking assignments appropriately. (Great, isn't it :-))

> So, I am using this technique instead:
> 
> def counter_with_state(clk,inbit,outbit):
> 	state = Signal(intbv(0,min=0,max=16)
> 	inst = mycounter(clk,inbit,outbit,state)
> 	return instances()
> 
> This bundles the state with the generator.  This seems to work for all cases
> in simulation, and in trivial ones with verilog generation.  However, for
> more complex cases, simulation works but verilog generation fails with
> "Signal is not driven" type errors.
> 
> My question is - is this a legitimate technique for Verilog generation?  If
> so, I have a error or have found a bug.  If not, why not?  Maybe I am
> missing something...

All of the above is possible, but I'll need an failing example (the
smallest possible :-)) to judge.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] RE: Explicit local state and verilog generation

[Frank P. <pal...@co...>]

A small follow-up...  I realized later that my issue is really about
type-definition, not state.  I want to bundle internal signal types along
with a subsystem, and still be able to use verilog generation.  But I'm not
sure which way is part of the convertable subset, if any.

Thanks again,
Frank