myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] 0.6dev4

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

Hi all:

0.6dev4 has been released on the development snapshot pages -
again one step closer to 0.6 and toVHDL.

Status info:
   http://myhdl.jandecaluwe.com/doku.php/dev:todo:0.6

The whatsnew page for 0.6 has been enhanced significanly. The
new verification process for conversion (that doesn't rely on
cosimulation) is described in a separate section, because
it should eventually work for toVerilog also:
   http://myhdl.jandecaluwe.com/doku.php/dev:whatsnew:0.6

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] MyHDL Logo

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

Hi all:

Thanks to Rodrigo Peixoto, MyHDL now has a logo:

   http://myhdl.jandecaluwe.com/doku.php/logo

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] MyHDL criticism on a russian forum

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

Poster Murr Von Kater had more or less the following to say:

 > I know Python and I can tell you it's very inconvenient for
 > FSMs because it doesn't have a case statement.

Answer: the lack of a case statement is a much debated Python
issue in general. It would be useful for many purposes, not just
the description of FSMs. Anyway, until now, Python's designer
doesn't consider the benefits large enough.

For pure modelling purposes, I personally don't consider this
to be a big deal. However, for hardware implementations, there
is an additional argument for case statements, as they may be
used to indicate exclusive conditions - which may result in
a more efficient implementation.

For this reason, the MyHDL to Verilog/VHDL convertor detects
when an if-then-else can be converted to a case statement,
and uses case statements in the output whenever possible.

 > All these 'return <instances>' statements look clumsy because
 > they are not necessary for the description of logic, but are
 > only needed for the interpreter.

It may seem redundant, but note that you don't necessarily
need a single return statement as the last line; you can return
different things under different conditions. This is how you
can support "configurations" in MyHDL, without the need for
a separate piece of code like in VHDL.

 > In general a python is a good and powerful language, but I use
 > it as the auxiliary tool, in particular for the generation of
 > Verilog code to avoid having to do things manually. But let's use
 > things for their intended purpose and not reinvent the wheel.

By using Python as a code generator, you implicitly assert that
Verilog only is not powerful enough for your purposes.

If you used MyHDL, you would have equivalent power but you would
have to do even less. Instead of writing a code *generator*, you
would write the code itself. You could verify it directly in Python
(much easier than in Verilog) and then have MyHDL convert it
*automatically* to Verilog.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] MyHDL criticism on a russian forum

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

Hi all:

There's an interesting discussion going on about MyHDL on a
russian forum:

     http://electronix.ru/forum/index.php?showtopic=32608

I don't speak russian :-) but thanks to online tranlation I can
more or less understand what's being said. It's quite critical,
which is good because at times I get worried about the lack of
criticism that MyHDL is getting (which can be interpreted as a lack
of interest.)

I'm going to address some of the points here and in subsequent
posts, and I hope our russian friends will read this and perhaps
join the discussion.

Poster makc says something like:
"MyHDL doesn't make sense. Instead of reinventing the wheel, time
and effort would be better spent on a free Verilog/VHDL simulator".

My answer:

The whole point of MyHDL is exactly *not* to reinvent the wheel.

1) There are free Verilog simulators (Icarus, cver) and at least one
free VHDL simulator (GHDL) available, so doing one more would
indeed be duplicating effort.

2) Instead, I'm trying to make it possible to use Python as a HDL.
Python is a very powerful language. It's the language behind
success stories like YouTube and Google. For every Verilog
designer, there must be hunderds of Python programmers. MyHDL
tries to show that you don't really need these "specialty" languages
for hardware design, but that you can use a true mainstream
language instead. How can that be a bad idea?

3) MyHDL is also about innovation. It has some features that
no mainstream HDL has. Case in point: the intbv class. With MyHDL,
you can avoid having to deal with signed/unsigned issues; the
Verilog convertor takes care of such details.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Tristate and bidirectional signals

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

On Tuesday 05 June 2007 02:21:32 am Jan Decaluwe wrote:
> Hi all:
>
> I have completed a draft proposal for tristate and bidirectional
> signal support in MyHDL:
>
>      http://myhdl.jandecaluwe.com/doku.php/meps:mep-103
>

That looks like a good approach. 

[myhdl-list] Tristate and bidirectional signals

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

Hi all:

I have completed a draft proposal for tristate and bidirectional
signal support in MyHDL:

     http://myhdl.jandecaluwe.com/doku.php/meps:mep-103

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Logo Python MyHDL

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

Hi all:

Thanks Rodrigo for the good work.

I have tried to include the version I like most on the website:
     http://myhdl.jandecaluwe.com

I wanted to scale it a little more, but then the spacing
between the pins becomes to small. So perhaps we should
consider a further change so that is scales better?
E.g. 12 pins instead of 16 pins at each side, for a 24pin DIP.

Feedback welcome,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] toVHDL

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

Thomas Heller wrote:
> Just because I'm curious:  *Why* do we need toVHDL?

Good question (and a great story btw).

I have commented on this briefly here:
    http://myhdl.jandecaluwe.com/doku.php/dev:whatsnew:0.6#rationale
but I'll elaborate on my current views further.

We certainly don't need toVHDL to close the gap to implementation.
As you note, since we have toVerilog, that is a done deal and
proven by now I believe. I have responded in this sense to some
initial requests for toVHDL, pointing out that there was no
real "urgency" anymore.

In fact, since we have toVerilog I believe MyHDL is more-or-less
a "complete" system that covers most aspects of modern hardware design.
So then the question becomes how to get more users, not features.
I remember a talk by Guido Van Rossum where he pointed out
that "once people use Python, we know that they will like it.
The problem is getting them to use it the first time".
I like to believe that it's the same for MyHDL.

So the problem then becomes to "lower the threshold". I see toVHDL
in that context, but again not as the most urgent effort. In fact,
the first thing I did for this was start up a Cookbook with real design
examples.

toVHDL is intended to lower the threshold for VHDL designers. It's
natural that designers want new things to fit in their current flow.
With toVHDL, they should be able to start using MyHDL and still
be fully compatible with their current VHDL-based design flow.

I have the impression that that holds for your case too. If toVHDL
would have been released already, perhaps you would have tried MyHDL
sooner (and you might also have realized sooner that you actually
don't need VHDL anymore :-))

With toVHDL, I believe we have two arguments to convince VHDL
designers. One is of course, Python itself - no need to elaborate
on that further here. But there is a second strong argument,
that should be attractive to designers with zero initial interest
in Python: the features of toVHDL itself.

Basically, toVHDL can make it easier to write VHDL. You note the
difficulties in working with signed/unsigned. Everyday, designers
must be struggling with this. With the backing of toVHDL,
I believe I can make the bold claim that it's all wasted energy.
With intbv's, expressions simply work as you expect. When
you convert to VHDL, the convertor handles all the necessary
castings and resizings. That should be good news.

The remaining question: how large is the public? At some point,
I thought VHDL support was no longer an issue as the whole world
was going to (System)Verilog. For the ASIC world, that may
actually be the case. On the other hand, just some days ago
I received an e-mail from a designer in a major electronics company
with suggestions for toVHDL.

For the FPGA world, I'm getting some feedback (including from this
mailing list) that suggests that the number of VHDL designers
may still be the majority. (I should release toVHDL before
more of them start thinking that Verilog would be a better option :-)).

On the other hand, there is prototype toVHDL function in the
development release, which is probably good enough to get started,
and I'm not getting a lot of feedback on this, so again it
doesn't seem very urgent. Of course, if the purpose is to
attract new users I shouldn't probably expect them to work
with development prototypes.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] toVHDL

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

Just because I'm curious:  *Why* do we need toVHDL?


I have developed a (very) few FPGA designs in VHDL, I learned it
because it seems to be the standard, and because I have visited one of the
free Xilinx seminars to get started.

My experience was somewhat frustating, and I got the impression that verilog
would have been a better choice.  But I never made the switch.

So, some days ago, I had to start a new small design, in VHDL of course.
Things were frustating again, problems with singed/unsigned interpretation
of signals and other stuff.

Well, I got the first part of the design working eventually.
For fun I thought: this is a good reason to try MyHDL again.
Recoded the main part of the design in MyHDL, simulated it,
it worked fine.  I called toVerilog() on it, had a verilog module,
inserted this as source into my project, and instantiated it in
the top-level VHDL module.  Xilinx ise even has a 'View HDL Instantiation
Template' command that produced the VHDL I needed to insert into the top level.
Synthesized the design and it worked again.

The, I needed a pipelined binary divider.  Xilinx provides a core in the core generator
that generates a netlist for it (as I understand).  Used it and it worked.  OTOH, I thought
it might be fun to design one in MyHDL.  It was fun, doing it with TDD, and after a few iterations
it simulated (in MyHDL) correctly - even had lower pipeline latency than the xilinx one because
of my special restrictions on the inputs; it is not as universal as the xilinx core.
Called toVerilog(), and - whoops - the design again worked in hardware.

So, the question again (which may be very dumb given my limited experience):
Do we really need toVHDL (I think I was one of those originally asking for it,
probably years ago)?

Thanks,
Thomas

Re: [myhdl-list] Small buglet

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

Thomas Heller wrote:

> When I was first playing with myhdl, I missed 'instances' so much (since it wasn't mentioned
> in the first chapters of the manual) that I decided to implement it myself.  Luckily
> I found it before the implementation did really work.

Ok, let's keep it then :-)

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Small buglet

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

Jan Decaluwe schrieb:
> Thomas Heller wrote:
>> While working with Python generators in a testbench to supply test data to my instances,
>> I found that the myhdl.instances() function not only returns MyHDL instances but also
>> these generators.
> 
> Right. Sometimes I think that myhdl.instances() is a result
> of me trying to be too clever, and therefore not really a good
> idea. Suppose it would be required to always return instances
> explicitly, would anyone have missed it?

Well, I like instances() a lot.  It allows me to split one 'instance'
into two or more which is sometimes a little more elegant, and avoids the error that
I forget to include the new instance into the return statement.
(toVerilog usually complains about some signals not been driven in that case,
but the simulation does not, IIRC.)

When I was first playing with myhdl, I missed 'instances' so much (since it wasn't mentioned
in the first chapters of the manual) that I decided to implement it myself.  Luckily
I found it before the implementation did really work.

> Anyway. I think that you expect that the function only finds
> instances created by the MyHDL decorators @instance, @always
> and @always_comb (and also the "hierarchical" instances of
> course.) Those decorators could return special objects that
> can be easily be looked up by type. That's indeed what currently
> happens with @always and @always_comb - but not with
> @instance, which creates a generator directly.
> 
> Before 0.5, MyHDL had no decorators and the only option was
> to use generators directly. Therefore, it was not possible
> to differentiate between "MyHDL" generators and other ones.
> At this point, myhdl.instances() is still compatible with
> that behavior.
> 
> In the future, I believe the function should be modified
> so that it works like you expect. It's a good idea to
> require using MyHDL decorators for instances. The code
> becomes clearer, and as you say, plain generators have
> other uses, also in MyHDL code.
> 
> In the mean time, returning instances explicitly is a good
> workaround. Perhaps better than the "feature" :-)
> 
> Feedback welcome.

Thanks,
Thomas

Re: [myhdl-list] Logo Python MyHDL

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

Rodrigo Peixoto wrote:
>     One question: what font did you use for "MyHDL"? 
> 
>  
> I did that!
>  
> 
>     Is it the
>     one from the Python logo?
> 
>  
> The python Logo is Flux Regular.
> 
>     I infer that we cannot simply use that same font without
>     paying someone?
> 
>  
> Really, we can't, but if I remove the "Python^tm" we don't need to pay.

Ok. I think we're almost done, except for some fine-tuning:

1) The letters you produced generally look good, but I have some
reservations. The left border of the "D" looks too thin too me,
and also I think the "D" may be confused with an "O". Also, I have
the impression that the letters aren't always rendered that well
when the logo is scaled, because of the curved edges.
Personally, I wouldn't mind if you used the (simple?) font from
your initial proposal.

2) Shouldn't the text be exactly centered (left margin = right margin)?

3) it seems that non-square packages with pins at all sides don't
exist, so even though it's "just a logo" I would prefer use the
dual-in-line version (your third alternative, but without the
"python" reference).

4) I think we also need a version without text that can be used
as a small icon, such as a favicon.

Thanks,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Logo Python MyHDL

[Rodrigo P. <rod...@gm...>]

>
> One question: what font did you use for "MyHDL"?


I did that!


> Is it the
> one from the Python logo?


The python Logo is Flux Regular.

I infer that we cannot simply use that same font without
> paying someone?


Really, we can't, but if I remove the "Python^tm" we don't need to pay.

Also, even without the python reference, I still would like to
> submit the logo to the PSF for review.


Ok, good!


>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Rodrigo Jos=E9 Sarmento
> Peixoto
>
> -------------------------------------------------------------------------=
---------------------
> UFPE - CIn ( EngenhariaDaComputacao )
> Skype: rodrigopex
> msn: rod...@ho...
>
> -------------------------------------------------------------------------=
---------------------
> Est=E1gio: Itautec Performance Lab (http://www.itautec.cin.ufpe.br)
> Projeto de extens=E3o: Inclus=E3o digital escola Padre Machado
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: [myhdl-list] Small buglet

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

Thomas Heller wrote:
> While working with Python generators in a testbench to supply test data to my instances,
> I found that the myhdl.instances() function not only returns MyHDL instances but also
> these generators.

Right. Sometimes I think that myhdl.instances() is a result
of me trying to be too clever, and therefore not really a good
idea. Suppose it would be required to always return instances
explicitly, would anyone have missed it?

Anyway. I think that you expect that the function only finds
instances created by the MyHDL decorators @instance, @always
and @always_comb (and also the "hierarchical" instances of
course.) Those decorators could return special objects that
can be easily be looked up by type. That's indeed what currently
happens with @always and @always_comb - but not with
@instance, which creates a generator directly.

Before 0.5, MyHDL had no decorators and the only option was
to use generators directly. Therefore, it was not possible
to differentiate between "MyHDL" generators and other ones.
At this point, myhdl.instances() is still compatible with
that behavior.

In the future, I believe the function should be modified
so that it works like you expect. It's a good idea to
require using MyHDL decorators for instances. The code
becomes clearer, and as you say, plain generators have
other uses, also in MyHDL code.

In the mean time, returning instances explicitly is a good
workaround. Perhaps better than the "feature" :-)

Feedback welcome.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Logo Python MyHDL

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

Jan Decaluwe wrote:
> Rodrigo Peixoto wrote:
> 
>>Trying one more time... The news proposes are attached .
> 

Ok, let's go for the second one, without reference to Python
for clarity.

One question: what font did you use for "MyHDL"? Is it the
one from the Python logo? That font is called "Flux regular"
and they say the following about it:
"The PSF owns a copy but we cannot distribute it, except for work
  on the PSF's behalf."
See also:
     http://www.python.org/community/logos/

I infer that we cannot simply use that same font without
paying someone?

Also, even without the python reference, I still would like to
submit the logo to the PSF for review.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Small buglet

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

While working with Python generators in a testbench to supply test data to my instances,
I found that the myhdl.instances() function not only returns MyHDL instances but also
these generators.

Thanks for a wonderful tool,
Thomas

Re: [myhdl-list] Logo Python MyHDL

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

I prefer the one without the python text, but they all look good.


On Wednesday 16 May 2007 21:44, Rodrigo Peixoto wrote:
> Trying one more time... The news proposes are attached .
>
>
> Best regards,
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Rodrigo Jos=E9 Sarmento
> Peixoto
> -------------------------------------------------------------------------=
=2D-
>------------------- UFPE - CIn ( EngenhariaDaComputacao )
> Skype: rodrigopex
> msn: rod...@ho...
> -------------------------------------------------------------------------=
=2D-
>------------------- Est=E1gio: Itautec Performance Lab
> (http://www.itautec.cin.ufpe.br)
> Projeto de extens=E3o: Inclus=E3o digital escola Padre Machado
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: [myhdl-list] Logo Python MyHDL

[Christopher L. F. <cf...@uc...>]

I like it as well.  Same reasons that have been discussed.  Simple,  
incorporates python colors, etc...  I am indifferent with python text  
being included or not.

But I imagine if it was used as an icon (smaller version) including  
only MyHDL text would be clearer.

On May 17, 2007, at 1:22 AM, Jan Decaluwe wrote:

> Rodrigo Peixoto wrote:
>> Trying one more time... The news proposes are attached .
>
> Ok, that should give us enough choices :-)
>
> I wonder what others think?
>
> --  
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>      From Python to silicon:
>      http://myhdl.jandecaluwe.com
>
>
> ----------------------------------------------------------------------- 
> --
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Need some help expressing my thoughts to myhdl

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

Jan Decaluwe wrote:
> Nathan Cain wrote:
> 
>>The split generators was an artifact from a time when this logic was  
>>part of another module.  I agree, this should be cleaned up before  
>>moving to synthesis... but I'm not there yet.
> 
> 
> Ok.
> 
> 
>>That being said, it still doesn't really answer the question of how  
>>to do the byte concatenation...
> 
> 
> Variable part-selects in Verilog are problematic.
> 
> I would avoid the issue altogether by using shifting, like so:
> 
>      cpu_d.next[8:0] = rom
>      cpu_d.next[W:8] = cpu_d.next[W-8:0]
Correction:              cpu_d[W-8:0]
> 
> where W = len(cpu_d).
> 
> Use the counter to decide when to shift, and to detect
> when the cpu_d is ready, all from within a generator
> triggered by a clock edge. This should also create
> efficient hardware.
> 
> Jan
> 


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Need some help expressing my thoughts to myhdl

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

Nathan Cain wrote:
> The split generators was an artifact from a time when this logic was  
> part of another module.  I agree, this should be cleaned up before  
> moving to synthesis... but I'm not there yet.

Ok.

> That being said, it still doesn't really answer the question of how  
> to do the byte concatenation...

Variable part-selects in Verilog are problematic.

I would avoid the issue altogether by using shifting, like so:

     cpu_d.next[8:0] = rom
     cpu_d.next[W:8] = cpu_d.next[W-8:0]

where W = len(cpu_d).

Use the counter to decide when to shift, and to detect
when the cpu_d is ready, all from within a generator
triggered by a clock edge. This should also create
efficient hardware.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Logo Python MyHDL

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

Rodrigo Peixoto wrote:
> Trying one more time... The news proposes are attached .

Ok, that should give us enough choices :-)

I wonder what others think?

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Need some help expressing my thoughts to myhdl

[Nathan C. <na...@in...>]

The split generators was an artifact from a time when this logic was  
part of another module.  I agree, this should be cleaned up before  
moving to synthesis... but I'm not there yet.

That being said, it still doesn't really answer the question of how  
to do the byte concatenation...

--Nathan


On May 16, 2007, at 2:52 AM, Jan Decaluwe wrote:

> Nathan Cain wrote:
>
> Before going to the heart of the matter, I have a problem
> with this code:
>
>>      @always(rst.negedge, state)
>>      def StateLogic():
>>          if(rst == 0 or state == 0):
>>              cpu_ready.next = 1
>>              rom_a.next = (cpu_a * bytes)
>>          if state != 0:
>>              #print "fetching byte %d, %x = %x" % (state, rom_a,  
>> rom_d)
>>              rom_a.next = rom_a + 1
>>              thistop = (top - ((state-1) * 8))
>>              #cpu_d.next[thistop:thistop-7] =  rom_d
>>              cells[state-1].next = rom_d
>>          if(state == bytes):
>>              cpu_ready.next = 0
>
> I expect that any synthesis tool would complain about this
> as it's not clear how this can be implemented in reliable
> hardware.
>
> I would expect that all your logic would be triggered by
> the clock. Also, the design seems simple enough so that
> everything can be done within a single generator,
> both the state (really a counter) and the data operations.
>
> Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>      From Python to silicon:
>      http://myhdl.jandecaluwe.com
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Logo Python MyHDL

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

Rodrigo Peixoto wrote:
> Hello people,
> 
> I try to propose an icon to Python MyHDL. The logo is attached. It's 
> just an idea.

Aha, brasilian design :-)

I like it. Use the colors of the python logo, but dump the snake and
use a chip. Plus the idea of pieces of a puzzle that fit together.

I'm just not sure whether mentioning 'Python' in the logo makes
it stronger or weaker. On the one hand, MyHDL is proud on its
Python foundation of course, but on the other hand, mentioning
both may make the logo less clear?

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] intbv

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

Christopher L.Felton schrieb:
> By default intbv (similar to int type) is by default signed, just  
> assign it to a negative value.  I believe some care is needed to direct  
> the toVerilog conversion.
> 
> Jan added an example,  
> http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp , just for this  
> topic.
> 
> The example shows how to use the intbv as signed value and also shows  
> the synthesis results.
> 
>  From the example sin_z0 = Signal(intbv(0, min=-M-D, max=M+D)) is used  
> to define a signed value with a limited range.
> 
> Also see.
> http://www.jandecaluwe.com/Tools/MyHDL/manual/ref-intbv.html
> http://www.jandecaluwe.com/Tools/MyHDL/manual/conf-features-signed.html

Yes, that did help indeed.  Quoting from the last url you mentioned:

    The Verilog converter handles negative intbv objects by using a signed Verilog representation. Also,
    it automatically performs sign extension and casting to a signed representation when unsigned numbers
    are used in a mixed expression. In this way, it automates a task which is notoriously hard to get
    right in Verilog directly.

I was confused because the tutorial always mentioned this
  Signal(intbv(0)[12:])
to create a 12-bit bus, but it does always create an unsigned signal.

> The following are some simple examples.

[...]

> Note at the end, the bit manipulations don't seem to maintain the  
> sign'ness?  Some one else maybe able to comment on why that is  
> incorrect usage?

Maybe this is a bug?

> Hope that helps.

Thanks,
Thomas

Re: [myhdl-list] intbv

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

On Wednesday 16 May 2007 07:42, Christopher L.Felton wrote:
> By default intbv (similar to int type) is by default signed, just
> assign it to a negative value.  I believe some care is needed to direct
> the toVerilog conversion.

toVerilog conversion works fine. All you need is an intbv with a negative min 
value and you will get a signed type in Verilog.

Tom