myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] New MyHDL Tutorial Available.

[Christopher L. <loz...@fr...>]

I am going to fire up a Zope 3 server and wiki, and then we can write it 
in restructured text.

My priority was to get it up and available, so people can start using it.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] New MyHDL Tutorial Available.

[Martín G. <ga...@gm...>]

2011/4/10 Christopher Lozinski <loz...@fr...>

> I am pleased to announce a MyHDL tutorial at
> http://MyHDLClass.com
>
>
why no write this doc in restructuredtext ? would be more clear,
maintainable and "pythonic".

[myhdl-list] New MyHDL Tutorial Available.

[Christopher L. <loz...@fr...>]

I am pleased to announce a MyHDL tutorial at
http://MyHDLClass.com

Thank you Christopher Felton for all the hard work, and more importantly 
for getting it done so quickly.

I think that this demonstrates that MyHDL is evolving very rapidly.  The 
conference was over just 4 days ago.  Just watch!

We invite you to read and download the material, and go buy a board.
http://www.dsptronics.com/

There are some other boards that people have committed to supporting 
shortly.

I particularly invite you to edit the course material.  If we all make a 
few edits, in no time at all, there will be a rich deep and wonderful 
course.

Let me talk a little bit about the business model.  We had a business 
model.  Jan Decaluwe was using MyHDL and consulting.  Things were not 
moving very fast.  There was a perception of a one man show.  We all 
appreciate what he did.  We now have a new business model.  MyHDL is 
still open source material, but we have a class to offer, and charge 
people for.  My intention is to offer that class at the upcoming DAC 
conference, and use the proceeds to support a booth there.  The booth is 
not that expensive.  What is expensive is engineers time to man the 
booth.   And there are a lot of FPGA trade shows around the world to 
exhibit at and travel to.

So the course material is not strictly open source.  By contributing to 
it, you are allowing me to make some money off of it. Basically that 
will go to pay for my time, and trade show space.  This should allow 
MyHDL to grow much faster.   It is now easy for people to invest in 
MyHDL, because they know that things are happening very fast, moving at 
light speed.

So please thank Christopher Felton for all his hard work, or better yet, 
go and order one of his boards.
Please order one of his boards.   Please.

And try out the course material.

And if you want permission to edit the course material, just send me an 
email.
Also let me know if you want to sign up for the class.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

[myhdl-list] MyHDL in Cordoba

[Christopher L. <loz...@fr...>]

  Well I am delighted to say that we now have a poster session at the 
Cordoba FPGA conference.

Someone posted about the MyHDL conference there.

Jan Langer said he was going to the conference.

I asked him if he would be willing to run a booth.  He said yes, but there are no booths, just poster sessions.   So he asked for poster space.  And got it.  FREE! He just wrote to me:

>seems we are lucky.

So they are printing the poster there.

Here is the web page describing poster dimensions.
http://splconf.org/spl11/index.php?id=presentation-info

The poster may need to be edited to fit in their dimensions.   The conference starts on Wednesday, so there is time.

I have the flyers here.  I want to make a few small edits, and I will send it on.  Are there any other resources we should list?  I want to ad an introduction.

So does anyone want to chip in towards printing the poster?  I should send out emails to the chip vendors.

Does anyone want to contribute to printing flyers.  Maybe they could have a box next to the poster, so people could grab flyers if there is no one next to the poster all the time.  Volunteers to man the poster are most needed.

Pretty soon we will have a class to offer people, which we can charge for,  to help pay for the costs of booths at these conferences.  The blinking light demo is completed.  A descriptive text is written.  We need people to try it out, edit the text,  and buy some boards!  Things are happening.   These things happen very fast indeed.

  Any other conferences we should be exhibiting at?  DAC is coming up in San Diego in June.  I am in Los Angeles.  I have emailed them asking for booth space.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] Proposed Article: "The coming paradigm shift in Semiconductor Design and Manufacturing"

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

Andrew:

Your professonal life sounds like a nightmare. All those
idiots holding you back with all their bugs! But sorry,
I can't relate to it.

No one forces you to use anything from anyone. If you do, it
must be because the advantages largely outweigh the inevitable
problems. The net result is that you are greatly benefiting
from someone else's hard work, and they deserve your respect
for it. Of course, my opinion is strongly influenced by the
fact I have gone through the humbling experience of
publishing some embarassingly buggy software myself.

Your characterization of MyHDL is very disappointing.
You suggest that the key point about MyHDL is trying
to be a more powerful "implementation" language. It
doesn't work for you, because your real problem
is writing tests. Apparently I failed completetely
to get the message across.

The key point about MyHDL is that it tries to open
the Python universe to hardware designers. It it
minimalistic with the purpose to avoid standing in
the way as much as possible. It tries to give HDL
designers access to meaningful tools that are lacking
in traditional flows: the Python way of thinking
and solving problems, modern software development
techniques.

Take testing for example. Your sketch of a solution
doesn't give me a warm feeling. It seems extremely
complicated, but probably that is because I don't
really understand what you are saying. Frankly
though, I am not really interested. The reason is
that I have a solution that works great for me:
test-driven development for hardware.

Writing tests firsts addresses a lot of the issues
you describe. Tests are efficient, because they all
start by failing. As you are working with the specification
without the implementation, you are much more likely to
focus on all the boundary conditions. Writing tests with all
the python power available can also be fun. Finally, it
is very rewarding to see more and more tests working
as your implementation is progressing. Compare that
to the old flow of "breaking" a "working" implementation
when adding an new test.

Perhaps TDD doesn't work for you and we can stop the
discussion here. But if it does, how you can you say
that MyHDL doesn't provide an innovative solution?
(Innovation often is combining existing solutions
into an new application.) Do you know many unit test
frameworks for VHDL, Verilog, SystemVerilog? Do you
know many people who advocate the use of such techniques
in traditional design flows? I don't. But as I have
said on many occasions, including the MyHDL manual
(admittely using a trival example), I believe that
in a MyHDL-based design flow it is the way to go.

Jan


On 04/10/2011 05:48 AM, Andrew Lentvorski wrote:
> On 4/8/11 8:45 AM, Christopher Lozinski wrote:
>
>> So I echo Jan's comments, that I am in this for the long run.  It is
>> just clear to me that this is what the future holds.  But I also think
>> that this can all happen very fast, in parallel, with lots of different
>> people contributing different things.
>
> Software guys want higher level.  Sadly, I don't need higher level.  In
> fact, I can't use higher level.  The lower levels have so many bugs that
> the higher level abstraction breaks too often.
>
> The problem is that every single thing I use has bugs.  A *lot* of bugs.
>    And they *never* get fixed.  I primarily use FPGA's to paper over bugs
> rather than implement interesting stuff.  The problem is that marketing
> ensures that new features are always more valuable than fixing the 4
> irritating edge cases in the old silicon which probably require your
> grizzled vet to go figure out.
>
>
> If you truly want to win, you need two things:
>
> 1) To make writing tests easy for the user
>
> You need to go from the code I wrote and automatically generate tests
> that correspond.  Yes, you're going to generate tests that correspond to
> the baked-in bugs.  However, I only have to write by hand those tests
> that correspond to bugs I find and then kill the generated tests that
> were wrong.  That's a *LOT* easier than writing a whole bunch of tests
> from scratch.
>
> Yes, this is *HARD*.  Guess why nobody has done it?
>
> (While lots of research has gone into understanding, I suspect that a
> brute force approach would be good enough for we lowly engineers.
> Enumerate out all the state changes, edge events and ordering
> constraints, and then enumerate a *boatload* of tests (millions+).  As
> things change, quash those tests that fail because they were overly
> specific.  You'll kill 95%+ of the tests you generated after just a few
> small changes.  When done, you'll have the core tests you need).
>
>
> 2) A library of components with *tests*
>
> Want me to use MyHDL?  Have components that I can instantiate and *count
> on*.  I guarantee that I'll figure out how to use a MyHDL I2C block when
> I see the boatload of tests about all the boundary conditions that it
> gets right.  I guarantee you that Company X will use your CANbus
> controller when it works and their nice expensive Canbus FPGA IP failed
> on a boundary case.  Of course, the flip side is that until you have a
> baseline set of tests, you're not going to get used (guess why I write
> my own stuff instead of using OpenCores).  If I grab a block and only
> see it has 4 or 5 tests, I *KNOW* it has bugs. Unless I see close to
> 50-100 test cases, I'm better off writing it myself because I'll write a
> couple dozen myself.
>
> But tested library is going to be a lot of work.
>
>
> MyHDL by itself just doesn't have that much of an advantage.  I rarely
> lose time because my implementation language isn't powerful enough.  I
> lose time because writing tests sucks.
>
> The advantage would be to look at someone and say "You're right.  This
> block doesn't have all the snazzy features.  But since they wrote it
> with MyHDL, they tested it.  The features it does implement *WORK*.
> Here.  Take a couple of our generated tests and bounce them off of your
> own core and watch it die."
>
> *THAT* would get some attention.
>
> -a
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev


-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Proposed Article: "The coming paradigm shift in Semiconductor Design and Manufacturing"

[Andrew L. <bs...@al...>]

On 4/8/11 8:45 AM, Christopher Lozinski wrote:

> So I echo Jan's comments, that I am in this for the long run.  It is
> just clear to me that this is what the future holds.  But I also think
> that this can all happen very fast, in parallel, with lots of different
> people contributing different things.

Software guys want higher level.  Sadly, I don't need higher level.  In 
fact, I can't use higher level.  The lower levels have so many bugs that 
the higher level abstraction breaks too often.

The problem is that every single thing I use has bugs.  A *lot* of bugs. 
  And they *never* get fixed.  I primarily use FPGA's to paper over bugs 
rather than implement interesting stuff.  The problem is that marketing 
ensures that new features are always more valuable than fixing the 4 
irritating edge cases in the old silicon which probably require your 
grizzled vet to go figure out.


If you truly want to win, you need two things:

1) To make writing tests easy for the user

You need to go from the code I wrote and automatically generate tests 
that correspond.  Yes, you're going to generate tests that correspond to 
the baked-in bugs.  However, I only have to write by hand those tests 
that correspond to bugs I find and then kill the generated tests that 
were wrong.  That's a *LOT* easier than writing a whole bunch of tests 
from scratch.

Yes, this is *HARD*.  Guess why nobody has done it?

(While lots of research has gone into understanding, I suspect that a 
brute force approach would be good enough for we lowly engineers. 
Enumerate out all the state changes, edge events and ordering 
constraints, and then enumerate a *boatload* of tests (millions+).  As 
things change, quash those tests that fail because they were overly 
specific.  You'll kill 95%+ of the tests you generated after just a few 
small changes.  When done, you'll have the core tests you need).


2) A library of components with *tests*

Want me to use MyHDL?  Have components that I can instantiate and *count 
on*.  I guarantee that I'll figure out how to use a MyHDL I2C block when 
I see the boatload of tests about all the boundary conditions that it 
gets right.  I guarantee you that Company X will use your CANbus 
controller when it works and their nice expensive Canbus FPGA IP failed 
on a boundary case.  Of course, the flip side is that until you have a 
baseline set of tests, you're not going to get used (guess why I write 
my own stuff instead of using OpenCores).  If I grab a block and only 
see it has 4 or 5 tests, I *KNOW* it has bugs. Unless I see close to 
50-100 test cases, I'm better off writing it myself because I'll write a 
couple dozen myself.

But tested library is going to be a lot of work.


MyHDL by itself just doesn't have that much of an advantage.  I rarely 
lose time because my implementation language isn't powerful enough.  I 
lose time because writing tests sucks.

The advantage would be to look at someone and say "You're right.  This 
block doesn't have all the snazzy features.  But since they wrote it 
with MyHDL, they tested it.  The features it does implement *WORK*. 
Here.  Take a couple of our generated tests and bounce them off of your 
own core and watch it die."

*THAT* would get some attention.

-a

Re: [myhdl-list] help - hot bit encoder

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

On 08/04/11 08:31, Jan Coombs wrote:
> On 03/04/11 12:02, Jan Decaluwe wrote:
>  > Jan:
>  >
>  > You struggle . . .
>
> Yes.  . . .

I now have simulation working correctly, though I'm not sure if 
this is the simplest way to write the code I want.

Conversion to VHDL or Verilog is a problem.  I get the error:

Traceback (most recent call last):
   File "./encodeHotBit_map11.py", line 83, in <module>
     test_ehb()
   File "./encodeHotBit_map11.py", line 81, in test_ehb
     toVHDL(hotBit2binary, iv, ov, Width)
   File 
"/usr/local/lib/python2.6/dist-packages/myhdl/conversion/_toVHDL.py", 
line 145, in __call__
     genlist = _analyzeGens(arglist, h.absnames)
   File 
"/usr/local/lib/python2.6/dist-packages/myhdl/conversion/_analyze.py", 
line 165, in _analyzeGens
     _isMem(obj) or _isTupleOfInts(obj)
AssertionError


Any suggestions?  Jan Coombs

Re: [myhdl-list] Cordoba Booth

[Martín G. <ga...@gm...>]

2011/4/9 Christopher Lozinski <loz...@fr...>

> Jan Langer has offered to help man a booth at the Cordoba trade show.
>
> Could someone who writes Spanish well please inquire about an open
> source booth for MyHDL?
>
> Would anyone else like to help run the booth?  Jan does not speak Spanish.
>
> We have flyers here.  We can do an improved version.  Would anyone be
> willing to translate them into Spanish?
>
> Should we print a Spanish language banner?  First let us find out if we
> can get a booth.
>


Of course I could help, but I have no idea how to inquire a booth and if
there is time to do that. Should I contact organizers ?

I also could translate what be needed (my English isn't so good -- sorry --,
but I could write in Spanish well)  but I think due this conference is
international it's a better idea to keep flyers and banners in english.

BTW,  what about the people who presents the paper about MyHDL ? Does
somebody knows them? And is the paper available somewhere?

[myhdl-list] Cordoba Booth

[Christopher L. <loz...@fr...>]

Jan Langer has offered to help man a booth at the Cordoba trade show.

Could someone who writes Spanish well please inquire about an open 
source booth for MyHDL?

Would anyone else like to help run the booth?  Jan does not speak Spanish.

We have flyers here.  We can do an improved version.  Would anyone be 
willing to translate them into Spanish?

Should we print a Spanish language banner?  First let us find out if we 
can get a booth.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

[myhdl-list] Two Student Projects

[Christopher L. <loz...@fr...>]

The other day a student asked about implementing a microcontroller in MyHDL.  Sadly he got no repsonse.
And then we have a number of industry guys who need specific things.  Let us put them together.

So here are two examples, of reasonable projects for students to do.

1.  "Accessing Altera IP (specifically float point arithmetic) from MyHDL.  I believe this possible but I'm too much of an imbecile to figure it out.  Ideally, it would be nice to implement overloading operators for floating point but I could leave with calls to some "black box"."  I saw the email from Jan Decaluwe on this item, so if you volunteer to do it, you may get to work with the most senior guy here.

2. Building a floating point object.  This one is easy to do in python, and hard to export to Verilog or VHDL.  Maybe there are multiple ways to export them, I am not an expert in that area.  This is a controversial project.  The hardware guys say they are inefficient, and we are building application specific circuits, we know the range, we do not need a floating point number.  They are right.  The software guys say we are buiding microprocessors, we do not know the range, and we need them.  THey are also right.  Fortunately in a library situation, end users can choose if they want this or not.

There are a bunch of other obvious projects for students.  Support your favorite board, Integrate with your
favorite manufacturers custom functions.   Port over other ip cores.  Write a chapter in the course material.  But let us wait till people ask for specific student projects to happen.  Then there is an interested customer.

There are a number of advantages of this approach.   Frankly I think that microprocessor project was too hard to get done in a month.  And no one cared.  Here students are building specific libraries that people actually need.  They will get close attention from the senior guys on this list.  They get specific customers, and when they are done, they should get a reference letter.  For the rest of their lives they can say, I built the floating point classes in MyHDL!  And when we put up a review site for classes, all the people who review the class that they built, they can point to as their references.  Everyone wins.

And most importantly under this model, MyHDL grows very quickly.   I am starting to figure out the classes
that I need.  Floating Point being the most important.  At least you will have my attention!


-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] One Engineer at a time. Conference Report Mentorship Network Proposal

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

Angel:

Thanks for you clear report. It gives me the opportunity to
explain my views on a type of design flow that is commonly
found, but fundamentally flawed in my opinion. Please understand
that I don't intend to shoot the messenger here. In the
following, "You" refers to technical managements worldwide
responsible for such design flows.

When I say the design flow is flawed, I mean the following.
Consider what it would take to port your design, using your
current design flow, to Altera. Right - it would be close to
impossible. You are locked into Xilinx. They now have monopoly
power over you. Not good.

The sad thing is that HDL-based design provides all the tools
to achieve technology independence and preserve your negociating
power, without any loss of implementation efficiciency.
a) for synthesizable logic, you need a decent synthesis tool
b) for non-synthesizable logic, you need a methodology

I'm always amazed by the ease with which technical managements
give away such a tremendous advantage.

Now up to your specific points.

1) When you need a building block such as a fifo, or ram, or
stack,.. you first step should *not* be to look into the
Xilinx catalog. The first step is to write a spec and a
simulation model of what you want, with the interfaces you
define. Then, you add architectures per target vendor that
implement the model using logic and vendor-specific instantiations.
You use the model for simulation, and the vendor-specific
architecture for synthesis.

Now the rest of your design is not infected by vendor-specific
stuff, and porting becomes a matter of locally adding and
verifying architectures. This is how I have been doing it all
my professional life. Works great.

MyHDL is actually a great solution to write such module generators.
With python power, a simulation model will often be trivial.
By parametrization and the verilog/vhdl hooks, you can add
any logic and vendor-specific instantiation you want.

2) Using FPGA vendor-specific IP is bad, without source code
it's even worse. It should be last choice, not the first.
I'm not saying it may never be warranted, for some super-star IP.
But for the blocks you mention, it would seem that there
are better alternatives, from writing it yourself over opencores
to commercial vendor-independent IP providers.

Regarding MyHDL, it is true the lack of an IP library is
a problem here.

3) mixing signed/unsigned with std_logic_vector is a non-issue.
No work is required from the MyHDL side, no conversion functions
are needed. Those are closely-related types. You can cast using
the type name, even at instantiation time at both sides of a
named instantiation. Sorry, but this is basic VHDL stuff.

4) Your engineers are not just wary of the MyHDL approach:
they are wary of HDL-based design 'tout court'. Apparently
they have come to prefer technology-specific instantiation.
Schematic entry works much better for that.

Again, it's a consequence of doubtful design flow decisions.
If Xilinx synthesis doesn't recognize its own multipliers,
or is louzy for others reasons, consider alternatives. Good
synthesis tools do exist. If they cost money, so be it.
HDL-based design, based on VHDL, Verilog, or MyHDL, relies
on good synthesis. If you don't believe the productivity
story, better forget about it alltogether than only
going half the way.

If no synthesis tools would be able to infer said multipliers,
then treat them as non-synthesizable blocks as in 1).

Jan


On 04/08/2011 01:28 PM, Angel Ezquerra wrote:
> I may be hijacking the thread, but I'd like to pitch in to tell you
> about my experience when trying to use MyHDL for actual design work on
> a shop that relies very heavily on Xilinx tools and FPGAs and that
> mostly uses VHDL (there is little Verilog in our code base).
>
> Obviously people not using Xilinx products may not experience the same
> sort of problems that we did, but I imagine that a lot of people may
> face similar problems. Also note that due to time constraints we did
> not devote a huge number of time or resources to trying to solve these
> problems, so perhaps this may be a bit of an unfair assessment of
> MyHDL.
>
> Basically, we've found the following difficulties when trying to use
> MyHDL in our environment:
>
> 1.- It is hard to use the built-in FPGA blocks, such as RAMs, FIFOs,
> CPLDs, etc in your design, and even if you do, it is basically
> impossible to simulate a design that uses them.
>
> The Xilinx ISE, as awful as it is, comes with a pretty big set of
> "Device Macro and Primitive Instantiation" templates that let you add
> FIFOs, RAMs, CPLDs, etc, that is, all those HW blocks that the FPGA
> that you are using contains and which are essential to get anything
> done with your FPGA. Also there are no python models of those blocks
> so that rules out simulating designs that use those blocks.
>
> 2.- It is hard to use external IP cores:
> We do not write all our VHDL code. Sometimes we rely on external IP
> cores. In particular we use a few Xilinx IP cores such as encoders,
> decoders, etc. Xilinx does not provide the actual source code for
> those cores. Instead they give a "simulation" version of the core,
> which is a huge VHDL file that is guaranteed to behave as the actual
> core itself, and which you can use to run simulations of projects that
> include those IP cores.
> Using these external cores practically rules out running any MyHDL
> simulation. Instead you must convert your blocks into VHDL and then
> simulate using Xilinx's tools.
>
> 3.- It is hard to mix MyHDL code with legacy VHDL code, specially if
> it uses std_logic_vector, rather than signed or unsigned values:
> This problem is often mixed with the two previous ones, because for
> some reason Xilinx tends to use std_logic_vector values in the
> interfaces of their blocks.
>
> This last problems seems like one that could potentially be solved on
> the MyHDL end, perhaps by providing some sort of seamless conversion
> between MyHDLs signed/unsigned types to/from std_logic_vector types?
>
> 4.- Over the years our engineers have learned the hard way that Xilinx
> tools do not work very well when you try to use "generic" VHDL. For
> example, the tools should be able to use the built-in FPGA DSP blocks
> when you use multiplication operators but it does not. Instead the
> tool may use a lot of logic blowing up your LUT count. Thus they are
> very wary of the MyHDL approach since they do not trust the underlying
> Xilinx synthesizer, mapper, etc to do the right thing.
>
> To sum up, these problems make it a bit unpractical to use MyHDL in
> this kind of environment, except perhaps to create small blocks that
> can be converted into VHDL and integrated into a greater VHDL-based
> design.
>
> I guess that if #3 was solved, it would make it much easier to make
> wrappers around the "device macro and Primitive instantiation"
> templates. We could potentially even generate those wrappers
> automatically,  partially solving #2. However we would still have the
> simulation problem, which means that we would always need to convert
> to VHDL and then simulate.
>
> Just my two cents!
>
> Angel
>
>
> On Fri, Apr 8, 2011 at 9:54 AM, Jan Decaluwe<ja...@ja...>  wrote:
>> Thank you and the team for the hard work, and for
>> the honest report. I hope you're not too disappointed.
>>
>> No, I don't see a substantial increase in downloads
>> (8 yesterday) or visits to myhdl.org (about 120 per day,
>> not counting the MyHDL manual).
>>
>> I'm not suprized - after similar experiences in the past.
>> I repeat my earlier analysis about the "audience mismatch".
>> Did you know that when you work at ARM - the most successful
>> electronic IP provider - you are not allowed to use
>> 'if' statements in HDL code? That's the kind of stupidity
>> that we are facing. I repeat: most HDL designers don't really
>> understand the technology they are using, and it's more
>> than 20 year old.
>>
>> On the other hand: if python has a good future, and if FPGAs
>> have a good future, the marxist in me (joking) believes evolutions
>> towards things like MyHDL are "inevitable" - but it will take a
>> new generation or an influx from different kind of people
>> like enlightened embedded software designers. And of course
>> we should try to make the transition as fast and smooth
>> as possible through a variety of initiatives, as are being
>> proposed. I will try to concentrate on technical stuff,
>> including "killer features" as discussed before.
>>
>> For the record: I'm in this game for the long run. You may
>> not hear from me for extended periods of time, but often
>> that is because I'm doing a MyHDL-based design project
>> with strict deadlines (like I'm doing now). Without MyHDL,
>> I wouldn't bother - I have seen enough VHDL and Verilog
>> for the rest of my life.
>>
>> On a daily basis, I try to stay motivated by having fun.
>> If you like digital electronics, and if you are a Python fan,
>> the choice seems obvious.
>>
>> Jan
>>
>>
>> On 04/08/2011 06:18 AM, Christopher Lozinski wrote:
>>> It was the last person I spoke to, I think Karl Kaiser, who gave me the
>>> best advice.  MyHDL will move forward not by selling to the top of the
>>> organizations, but by starting at the bottom.  Like the evolution of
>>> linux, we need to get one person at a time to use it.  Support them, and
>>> get the next person using it. Eventually management will find out it is
>>> being used on projects, and end up supporting it.
>>>
>>> I had thought that the large chip vendors would jump on the board as a
>>> way to sell to the python market place. Boy was I wrong.  Sure I
>>> collected 3 cards, one from each of the big 3, but they just are not
>>> that interested, not until such time as we start to move lots of boards,
>>> at which point, we no longer really need them.  But will still welcome
>>> them.
>>>
>>> I also thought, it is obvious this is how it should be done, there will
>>> be lots of interest in consulting.  Boy was I wrong.
>>>
>>> The conference  had Cisco talking about 10 gigahertz data transfer
>>> rates.   This FPGA array stuff still seems to be more about bandwidth,
>>> then about designing complex algorithms.   One engineer was complaining
>>> about not enough pin count.  Clearly his abstractions are wrong.
>>>
>>> There were a lot of design engineers who walked by and read our poster,
>>> but had the vacant expression on their faces, like they did not
>>> understand.  They didn't.
>>>
>>> There is strong moral support for MyHDL.   Like the guy who bought a
>>> board the other day.  Like the guy who said he will have to get his boss
>>> to spring for a class.  Like the three guys who have now offered to
>>> connect their boards.  And starting from companies like Tachyon
>>> simulation software.   And from all the lurkers on this mailing list.
>>>
>>> It is a start.  The longest journey begins with a single step.
>>>
>>> But we still have to win these guys over one engineer at a time.
>>>
>>> I am horrified that I saw all these people at the conference, got back,
>>> and see not a single new posting on the mailing list.   I am hoping the
>>> download numbers tell a different story.  What do the mailing list
>>> subscriptions say?
>>>
>>> So here is what I propose.   Let us put together a mentoring network.  I
>>> do not know about you, but I am always embarrassed to post my problems
>>> to a general mailing list.  My stupidity is then on the web forever.
>>> For those who are seriously interested in this stuff, let us assign them
>>> a mentor.  It goes two ways.  The mentor helps them get up to speed, but
>>> also the mentor gets a chance to hook them on this technology and draw
>>> them in.  We hope that they will stay with the technology, and pay it
>>> forward, by mentoring some other people.
>>>
>>> Here is my specific proposal.  Forgive me for using names before
>>> speaking to these people.  They may well decline to participate.   We
>>> have the two guys who want to port to their favorite boards.  Three if
>>> you count Chris Felton.   Thank you.  Most appreciated.  Jan Coombs
>>> asked me what he could do.  Maybe he would agree to mentor the two
>>> newbies efforts.  Now he does not know everything, perhaps Chris Felton
>>> would agree to only support Jan Coombs.  That would minimize Chris's
>>> time.  We would have a hierachy connecting the newbies to the most
>>> senior people.   The newbies get support.  The middle guys get respect.
>>> The senior guys feel that their time is being well leveraged.   We can
>>> all watch the network grow.  The newbies know they are just two people
>>> away from the senior guys, and the senior guys know they are supporting
>>> a broad network with very little time and effort.
>>>
>>> How does that sound?  Maybe eventually we can partition the network by
>>> industry.  The image processing guys over here, the communication guys
>>> over here.
>>>
>>> I think the grass roots approach makes sense.  I think the mentoring
>>> network makes sense.  Chris Felton is still on track to push out the
>>> code for the class. Jan Coombs could try it out, and document it, and
>>> then push it out to his mentees.  Eventually I hope that this approach
>>> would spread MyHDL in a very grass roots fashion.  Like a prairie fire.
>>>
>>> So let me know what you think?  Does anyone else want to be a mentor?
>>> Does anyone else want mentoring?
>>>
>>> And my eyes are on the obligatory Design Automation Conference in June
>>> in San Diego.  This time I think the banner should say:
>>>
>>> The Future of DA is open-source python.
>>>      Understand the paradigm shift today.
>>>
>>> More of a marketing message than an engineering message.  We can tell
>>> the managers that their teams need to understand this paradigm shift.  I
>>> had so many people ask me why not C?  I should have answered because in
>>> python we think about things differently, it is a paradigm shift.  We
>>> are not longer doing functional decomposition into design, simulation,
>>> verifaction and validation.  We are now building models, reusing class
>>> libraries, benefiting from polymorphism, multiple inheritance,
>>> decoration, and for the hard core python guys, acquisition, and
>>> interfaces.    The different language allows a different paradigm.
>>> Their organization needs to be educated about this paradigm shift.
>>>
>>> I wondered if we should be in the python conferences or in the design
>>> automation conferences.   Clearly the big money here is in the design
>>> automation conferences, not in the hackers.  And they do need our help.
>>>
>>> This experience has been great for me.  I have made significant progress
>>> on my chip design these last few days. I had a great time.  I learned a
>>> lot.  And this is way more interesting than my other job.  I will be
>>> around for a while.
>>>
>>
>>
>> --
>> 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
>>      Analog design automation: http://www.mephisto-da.com
>>      World-class digital design: http://www.easics.com
>>
>>
>> ------------------------------------------------------------------------------
>> Xperia(TM) PLAY
>> It's a major breakthrough. An authentic gaming
>> smartphone on the nation's most reliable network.
>> And it wants your games.
>> http://p.sf.net/sfu/verizon-sfdev
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev


-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Poster Offer For Argentine Conference

[Martín G. <ga...@gm...>]

2011/4/8 Christopher Lozinski <loz...@fr...>

> Chris Felton had my feeling, it should go to conferences and get forwarded.
>

The reality is even if you accepted, it is probably cheaper to print a new
> one there, than to fed ex it.
>
> But you can print your own copy if you wish.
>
>
That's fine. I could afford the poster print (around ~u$20 was my last one -
A0 format -) as a contribution to the project, but I'm not sure if it's an
efficient (in terms of cost) idea to make it itinerant. is that the idea?



> Are you offering a class there?
> What can we do to help you get MyHDL into your academic program?
>
>
Really I've just applied to give a pyday talk about MyHDL inviting
classmates personally.

In general, I think 'universities' are a very good target as marketing
strategy and a have special documentation for teachers (as guidelines, tips,
examples, exercises) would be an important help.

But I don't know if you will be happy if that brings a lot of newbies (like
myself) bothering here

cheers

Re: [myhdl-list] Poster Offer For Argentine Conference

[Christopher L. <loz...@fr...>]

Chris Felton had my feeling, it should go to conferences and get forwarded.

The reality is even if you accepted, it is probably cheaper to print a 
new one there, than to fed ex it.

But you can print your own copy if you wish.

Are you offering a class there?

What can we do to help you get MyHDL into your academic program?

Regards
Chris


On 4/8/11 10:11 AM, Martín Gaitán wrote:
> 2011/4/8 Christopher Lozinski<loz...@fr...>
>
>> If you are able to get an open source booth for the Argentina
>> conference, I would be happy to fed ex you this lovely 3x 5 poster we
>> have.   Sorry if the poster is in English, and in feet.
>>
>> I would also be happy to talk to someone on how to be more effective at
>> running the booth.  We need to focus on selling one engineer at a time.
>> That means no need to hand out millions of flyers, just figure out who
>> is likely to actually download this, get their business card, find them
>> a mentor, and bring them into the fold,
>>
>> "One engineer at a time".
>>
> That would be great!
> Even more useful than for the pyday, this poster will be great showed
> permanently at lab's doorway, where more "targets" are. I could achieve
> permissions to do that.
>
> I told here I enjoyed very much working with MyHDL (in an academic entry
> level) but I don't know really how much I'll use it in the future, because
> as a near computer engineer I have not very clear my professional future
> (although this topic is very interesting).
> However, I am pleased to spread MyHDL, helping classmates and enlightening
> teachers (humbly)  in the way.
>
> So, I mail you directly to arrange the poster shipping. Yay!
>


-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] One Engineer at a time. Conference Report Mentorship Network Proposal

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

Thanks for the conference report.  I would have liked to seen the 
picture of the faces!  I am surprised at the "C" question but I guess 
they might have been meaning C/C++/SystemC?

<snip>
>
> Here is my specific proposal.  Forgive me for using names before
> speaking to these people.  They may well decline to participate.   We
> have the two guys who want to port to their favorite boards.  Three if
> you count Chris Felton.   Thank you.  Most appreciated.  Jan Coombs
> asked me what he could do.  Maybe he would agree to mentor the two
> newbies efforts.  Now he does not know everything, perhaps Chris Felton
> would agree to only support Jan Coombs.  That would minimize Chris's
> time.  We would have a hierachy connecting the newbies to the most
> senior people.   The newbies get support.  The middle guys get respect.
> The senior guys feel that their time is being well leveraged.   We can
> all watch the network grow.  The newbies know they are just two people
> away from the senior guys, and the senior guys know they are supporting
> a broad network with very little time and effort.
>
> How does that sound?  Maybe eventually we can partition the network by
> industry.  The image processing guys over here, the communication guys
> over here.
>
> I think the grass roots approach makes sense.  I think the mentoring
> network makes sense.  Chris Felton is still on track to push out the
> code for the class. Jan Coombs could try it out, and document it, and
> then push it out to his mentees.  Eventually I hope that this approach
> would spread MyHDL in a very grass roots fashion.  Like a prairie fire.
>
>
This sounds fine to me.  Jan C. I will send you stuff as I have it.  I 
will review any thing you would like me to look at.  I know you posted a 
version of you one-hot encoder, I will try and look at that shortly.

OT.  You would think with the world-wide audience on this mailing-list 
we would have better distribution of name :)  We will need to start 
referring to people as 1of3 ... and ... 2of2.

Re: [myhdl-list] One Engineer at a time. Conference Report Mentorship Network Proposal

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

Thanks for sharing your experiences, in my opinion, this information is 
useful.  I think Jan D. and the community like hearing any type of 
feedback, positive or negative.

On 4/8/11 6:28 AM, Angel Ezquerra wrote:
> I may be hijacking the thread, but I'd like to pitch in to tell you
> about my experience when trying to use MyHDL for actual design work on
> a shop that relies very heavily on Xilinx tools and FPGAs and that
> mostly uses VHDL (there is little Verilog in our code base).
>
> Obviously people not using Xilinx products may not experience the same
> sort of problems that we did, but I imagine that a lot of people may
> face similar problems. Also note that due to time constraints we did
> not devote a huge number of time or resources to trying to solve these
> problems, so perhaps this may be a bit of an unfair assessment of
> MyHDL.
>
> Basically, we've found the following difficulties when trying to use
> MyHDL in our environment:
>
> 1.- It is hard to use the built-in FPGA blocks, such as RAMs, FIFOs,
> CPLDs, etc in your design, and even if you do, it is basically
> impossible to simulate a design that uses them.

There are few primitives in most FPGAs.  Block memory, DLL (xilinx), 
multipliers (i.e. dsp48), and maybe special IO ports.  The IO would be 
handled by your constraint definitions (.ucf for Xilinx, sdc for 
everything else).  The BRAM is automatically inferred 
(http://www.myhdl.org/doc/current/manual/conversion_examples.html#ram-inference). 
  Multipliers should be automatically inferred as well.  That just 
leaves the clock generators (PLL/DLLs) that need special handling.

I think the issue you are referring to.  Is that Xilinx and others 
provide a plethora of IP with GUIs to configure the IP.  Xilinx has 
coregen and Altera has megacore/megawiz.

Some of these IP modules, like FIFOs etc are slowly being implemented in 
MyHDL.  Example, in one of my projects I have FIFOs and other simple 
modules.  You can instantiate a sync/async FIFO something like

from cores.fifo import async_fifo #something like that

   ....
   fifo1 = async_fifo(clk, rst, din, dout, SIZE=128)
   ...

The above is not the exact / correct way to do it.  But I wanted to 
illustrate that some of these IP cores will be developed over time and 
designing a system will be *easier* than using coregen, etc.  This FIFO 
will use the BRAM in the device.  To your point, these are immature and 
have not been used / tested much.  But I think this will change with 
time.  I believe you will see more and more support for the functions 
you describe.

>
> The Xilinx ISE, as awful as it is, comes with a pretty big set of
> "Device Macro and Primitive Instantiation" templates that let you add
> FIFOs, RAMs, CPLDs, etc, that is, all those HW blocks that the FPGA
> that you are using contains and which are essential to get anything
> done with your FPGA. Also there are no python models of those blocks
> so that rules out simulating designs that use those blocks.


>
> 2.- It is hard to use external IP cores:
> We do not write all our VHDL code. Sometimes we rely on external IP
> cores. In particular we use a few Xilinx IP cores such as encoders,
> decoders, etc. Xilinx does not provide the actual source code for
> those cores. Instead they give a "simulation" version of the core,
> which is a huge VHDL file that is guaranteed to behave as the actual
> core itself, and which you can use to run simulations of projects that
> include those IP cores.
> Using these external cores practically rules out running any MyHDL
> simulation. Instead you must convert your blocks into VHDL and then
> simulate using Xilinx's tools.

This should not be difficult.  I have used external modules.  There has 
been some enhancements with the latest release in this area!
(http://www.myhdl.org/doc/current/whatsnew/0.7.html#new-method-to-specify-user-defined-code)

You might want to share some issues you have had.  The issue you might 
run into, if you use external cores, you really need to do co-simulation 
and not pure python simulation.  Which makes sense though, you have a 
VHDL module it needs to be simulated in VHDL.

At this point in time, for VHDL, you would be limited to testbench 
conversion versus MyHDL testbench driving a VHDL simulator.  We haven't 
cracked the VHPI for GHDL and have not had access to a commercial VHDL 
simulator to try.

>
> 3.- It is hard to mix MyHDL code with legacy VHDL code, specially if
> it uses std_logic_vector, rather than signed or unsigned values:
> This problem is often mixed with the two previous ones, because for
> some reason Xilinx tends to use std_logic_vector values in the
> interfaces of their blocks.

I think there are ways to handle this but it would need to be tested and 
documented.  And the problem might be the number of users that would 
need this.  It might not show up on the radar for things to do.

>
> This last problems seems like one that could potentially be solved on
> the MyHDL end, perhaps by providing some sort of seamless conversion
> between MyHDLs signed/unsigned types to/from std_logic_vector types?
>
> 4.- Over the years our engineers have learned the hard way that Xilinx
> tools do not work very well when you try to use "generic" VHDL. For
> example, the tools should be able to use the built-in FPGA DSP blocks
> when you use multiplication operators but it does not. Instead the
> tool may use a lot of logic blowing up your LUT count. Thus they are
> very wary of the MyHDL approach since they do not trust the underlying
> Xilinx synthesizer, mapper, etc to do the right thing.

I have not had this same experience.  I have done both Verilog and VHDL 
designs on a spectrum of devices and have not run into this?

>
> To sum up, these problems make it a bit unpractical to use MyHDL in
> this kind of environment, except perhaps to create small blocks that
> can be converted into VHDL and integrated into a greater VHDL-based
> design.
>
> I guess that if #3 was solved, it would make it much easier to make
> wrappers around the "device macro and Primitive instantiation"
> templates. We could potentially even generate those wrappers
> automatically,  partially solving #2. However we would still have the
> simulation problem, which means that we would always need to convert
> to VHDL and then simulate.

What VHDL simulator do you use?

>
> Just my two cents!
>
> Angel

Thanks for again for sharing, I believe this is useful information.

Chris Felton

Re: [myhdl-list] FW: Floating-point support --> Fixed-point

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

On 4/7/11 11:51 PM, Karl Kaiser wrote:
> I am interested in the status of Fix point support in MyHDL. Is there
> some effort on the way to implement this. I am a newbie on the Python
> side but may be able to contribute from the hardware side. I have done
> some work on an ASIC fix point DSP component library in Verilog in the past.
>
> Cheers,
> Karl Kaiser
>

Couple things, you can do fixed-point in MyHDL the same that you can do 
it in Verilog/VHDL.  I and others have done some work to add features / 
support as modules / libraries that sit on top of MyHDL 
(http://www.myhdl.org/doku.php/users:cfelton:projects:fxintbv).

Jan D. has mentioned some interest in adding fixed-point (not 
necessarily the approach of previous work) to the core MyHDL distro.

Any help is always welcome.  The first spot to help, if fixed-point is 
and interest, is to do a couple fixed-point projects and post them on 
the wiki and share you experiences on the mailing-list.

Note : The above statement MyHDL support is the same as Verilog/VHDL. 
This is true for the common versions of Verilog/VHDL used.  As part of 
VHDL (2008??) a fixed-point and floating-point libraries are being added.

Chris Felton

Re: [myhdl-list] Poster Offer For Argentine Conference

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

<snip>
>
>
> That would be great!
> Even more useful than for the pyday, this poster will be great showed
> permanently at lab's doorway, where more "targets" are. I could achieve
> permissions to do that.
>

Instead of the poster finding a permanent home.  It is better that the 
poster be forwarded on to the next conference.  Who ever agrees to 
receive the poster should also be willing to ship the poster to the next 
conference / need.

If the new recipient cannot cover the cost to ship the poster to the 
next conference they should make this known to the community before 
receipt.  The community can determine if "it" can cover the cost or 
which conference to send the poster.

We should try and get as many miles out of this poster as possible.  It 
sounds like we might be making new posters but I wouldn't want to retire 
the current poster until we have one that can replace it.

Chris Felton

Re: [myhdl-list] Poster Offer For Argentine Conference

[Martín G. <ga...@gm...>]

2011/4/8 Christopher Lozinski <loz...@fr...>

> If you are able to get an open source booth for the Argentina
> conference, I would be happy to fed ex you this lovely 3x 5 poster we
> have.   Sorry if the poster is in English, and in feet.
>
> I would also be happy to talk to someone on how to be more effective at
> running the booth.  We need to focus on selling one engineer at a time.
> That means no need to hand out millions of flyers, just figure out who
> is likely to actually download this, get their business card, find them
> a mentor, and bring them into the fold,
>
> "One engineer at a time".
>

That would be great!
Even more useful than for the pyday, this poster will be great showed
permanently at lab's doorway, where more "targets" are. I could achieve
permissions to do that.

I told here I enjoyed very much working with MyHDL (in an academic entry
level) but I don't know really how much I'll use it in the future, because
as a near computer engineer I have not very clear my professional future
(although this topic is very interesting).
However, I am pleased to spread MyHDL, helping classmates and enlightening
teachers (humbly)  in the way.

So, I mail you directly to arrange the poster shipping. Yay!

Re: [myhdl-list] FPGA Camp

[Jan L. <jan...@et...>]

Am 08.04.2011 um 16:53 schrieb Martín Gaitán:
> A bit quite, but I'm still over here. I'm the one who owes to MyHDL  
> a tiny miracle [0]
>
> Just to tell my humble work had some impact at my course, mainly due  
> how fast it was done (comparing with the .  A lot of people was  
> pleasantly surprised with Python and MyHDL.
>
> Casually, there is an important programmable logic conference [1] on  
> next week at my university, and to enforce the momentum
> there is a talk about MyHDL! [2]
> Python as a Hardware Description Language: A Case Study
> J. I. Villar, J. J. Chico, M. J. Bellido, J. Viejo, D. Guerrero  
> Martos and J. Decaluwe
> Hope Iattend it.
>
> But due this conference is paid and expensive for most students, I  
> think to give another talk at the next Python Day in Córdoba, on  
> April 30 [3].
>
> So, I will need some advices, because it should be enough basic to  
> people how understand python but have no idea of hardware  
> description (maybe, most of attenders at pyday) , and (specially)  
> people with knowledge about hardware but who never used python
>
> Experiences? slides ?
>
> BTW, I've been reading about the efforts made, and the I must say:  
> thank you  and patience! As Che Guevara said: ¡Venceremos!

Hi,
I will be in Cordoba, Argentina next week and I am already pretty  
excited to hear this talk. I will present a poster on comparing a  
design on different abstraction levels. Although, I didn't have the  
chance to work with MyHDL yet, other than playing around a little bit,  
I am really interested.
So, see you there,
Jan

-- 
Jan Langer
Professorship Circuit and System Design
Chemnitz University of Technology, Reichenhainer Str. 70, 09126 Chemnitz
Phone: +49 371 531-33158, Fax: +49 371 531-833158
http://www.tu-chemnitz.de/etit/sse

[myhdl-list] Poster Offer For Argentine Conference

[Christopher L. <loz...@fr...>]

If you are able to get an open source booth for the Argentina 
conference, I would be happy to fed ex you this lovely 3x 5 poster we 
have.   Sorry if the poster is in English, and in feet.

I would also be happy to talk to someone on how to be more effective at 
running the booth.  We need to focus on selling one engineer at a time.  
That means no need to hand out millions of flyers, just figure out who 
is likely to actually download this, get their business card, find them 
a mentor, and bring them into the fold,

"One engineer at a time".

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

[myhdl-list] Proposed Article: "The coming paradigm shift in Semiconductor Design and Manufacturing"

[Christopher L. <loz...@fr...>]

In Thomas Kuhn's 1962 book "The structure of scientific revolutions:

http://en.wikipedia.org/wiki/The_Structure_of_Scientific_Revolutions

He talks about different world views, and the transition from one world 
view to the other.

It is amazing how many blank stares I got at the conference.  I wish I 
had a video of it.
It is pretty clear to me that this is a change in world view.  The old 
school talks about
Design, Synthesis, Validation and Verification.  The new guys talk about 
models, missing libraries,
interfacing to boards.  It is a different paradigm.

Sure we all see clearly where this is going.  Thank you for the 
excellent critique this morning on the absence of class libraries.  That 
is why I am helping the marketing.  I cannot write all the needed class 
libraries, much easier to recruit in others who will do so.

But we need to operate on a higher level.  We need to call this a 
paradigm shift, and tell people that they need to get educated about 
this paradigm shift, and suddenly we are not the outcasts, we become the 
future.  We hold the moral high ground.

So I echo Jan's comments, that I am in this for the long run.  It is 
just clear to me that this is what the future holds.  But I also think 
that this can all happen very fast, in parallel, with lots of different 
people contributing different things.

Quick Paradigm Test.  Did you ask yourself why this article would also 
cover manufacturing?  Then you are still embedded in the old functional 
decomposition paradigm.  "Over here we have design and over here we have 
manufacturing".  In the new paradigm we just talk about the object model 
of semiconductors, and once you have that right, it is easy to do lots 
of different applications, Design, Synthesis, validation, manufacturing 
planning, shop floor scheduling, engineering data analysis.    It is a 
paradigm shift.

For the record, I used to do object models of manufacturing.  Those guys 
just did not get it.  I ran away.   Only recently did I understand that 
a paradigm shift was needed.  Clearly the same is true in Semiconductor 
design.

As the paradigm shifts, the language we use changes as well.  We need to 
support this young student from Argentina.  He sees the future.   
Paradigm shifts happen when the old school is replaced by the young school.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] FPGA Camp

[Martín G. <ga...@gm...>]

2011/4/8 Karl Kaiser <kk...@be...>

> Looking forward, what about leveraging the momentum of the booth by trying
> to get a paper into one of the sponsoring FPGA publications. This way many
> new engineers can be reached and a few are going to try MyHDL out.
>


Hi everybody

A bit quite, but I'm still over here. I'm the one who owes to MyHDL a tiny
miracle [0]

Just to tell my humble work had some impact at my course, mainly due how
fast it was done (comparing with the .  A lot of people was pleasantly
surprised with Python and MyHDL.

Casually, there is an important programmable logic conference [1] on next
week at my university, and to enforce the momentum
there is a talk about MyHDL! [2]
Python as a Hardware Description Language: A Case Study
J. I. Villar, J. J. Chico, M. J. Bellido, J. Viejo, D. Guerrero Martos and
J. Decaluwe
Hope I attend it.

But due this conference is paid and expensive for most students, I think to
give another talk at the next Python Day in Córdoba, on April 30 [3].

So, I will need some advices, because it should be enough basic to people
how understand python but have no idea of hardware description (maybe, most
of attenders at pyday) , and (specially) people with knowledge about
hardware but who never used python

Experiences? slides ?

BTW, I've been reading about the efforts made, and the I must say: thank
you  and patience! As Che Guevara said: ¡Venceremos!


[0] https://github.com/nqnwebs/pymips
[1] http://splconf.org/spl11/
[2] http://edas.info//p9279#S32383
[3] http://www.pyday.com.ar/cordoba2011/

Re: [myhdl-list] One Engineer at a time. Conference Report Mentorship Network Proposal

[Angel E. <ang...@gm...>]

I may be hijacking the thread, but I'd like to pitch in to tell you
about my experience when trying to use MyHDL for actual design work on
a shop that relies very heavily on Xilinx tools and FPGAs and that
mostly uses VHDL (there is little Verilog in our code base).

Obviously people not using Xilinx products may not experience the same
sort of problems that we did, but I imagine that a lot of people may
face similar problems. Also note that due to time constraints we did
not devote a huge number of time or resources to trying to solve these
problems, so perhaps this may be a bit of an unfair assessment of
MyHDL.

Basically, we've found the following difficulties when trying to use
MyHDL in our environment:

1.- It is hard to use the built-in FPGA blocks, such as RAMs, FIFOs,
CPLDs, etc in your design, and even if you do, it is basically
impossible to simulate a design that uses them.

The Xilinx ISE, as awful as it is, comes with a pretty big set of
"Device Macro and Primitive Instantiation" templates that let you add
FIFOs, RAMs, CPLDs, etc, that is, all those HW blocks that the FPGA
that you are using contains and which are essential to get anything
done with your FPGA. Also there are no python models of those blocks
so that rules out simulating designs that use those blocks.

2.- It is hard to use external IP cores:
We do not write all our VHDL code. Sometimes we rely on external IP
cores. In particular we use a few Xilinx IP cores such as encoders,
decoders, etc. Xilinx does not provide the actual source code for
those cores. Instead they give a "simulation" version of the core,
which is a huge VHDL file that is guaranteed to behave as the actual
core itself, and which you can use to run simulations of projects that
include those IP cores.
Using these external cores practically rules out running any MyHDL
simulation. Instead you must convert your blocks into VHDL and then
simulate using Xilinx's tools.

3.- It is hard to mix MyHDL code with legacy VHDL code, specially if
it uses std_logic_vector, rather than signed or unsigned values:
This problem is often mixed with the two previous ones, because for
some reason Xilinx tends to use std_logic_vector values in the
interfaces of their blocks.

This last problems seems like one that could potentially be solved on
the MyHDL end, perhaps by providing some sort of seamless conversion
between MyHDLs signed/unsigned types to/from std_logic_vector types?

4.- Over the years our engineers have learned the hard way that Xilinx
tools do not work very well when you try to use "generic" VHDL. For
example, the tools should be able to use the built-in FPGA DSP blocks
when you use multiplication operators but it does not. Instead the
tool may use a lot of logic blowing up your LUT count. Thus they are
very wary of the MyHDL approach since they do not trust the underlying
Xilinx synthesizer, mapper, etc to do the right thing.

To sum up, these problems make it a bit unpractical to use MyHDL in
this kind of environment, except perhaps to create small blocks that
can be converted into VHDL and integrated into a greater VHDL-based
design.

I guess that if #3 was solved, it would make it much easier to make
wrappers around the "device macro and Primitive instantiation"
templates. We could potentially even generate those wrappers
automatically,  partially solving #2. However we would still have the
simulation problem, which means that we would always need to convert
to VHDL and then simulate.

Just my two cents!

Angel


On Fri, Apr 8, 2011 at 9:54 AM, Jan Decaluwe <ja...@ja...> wrote:
> Thank you and the team for the hard work, and for
> the honest report. I hope you're not too disappointed.
>
> No, I don't see a substantial increase in downloads
> (8 yesterday) or visits to myhdl.org (about 120 per day,
> not counting the MyHDL manual).
>
> I'm not suprized - after similar experiences in the past.
> I repeat my earlier analysis about the "audience mismatch".
> Did you know that when you work at ARM - the most successful
> electronic IP provider - you are not allowed to use
> 'if' statements in HDL code? That's the kind of stupidity
> that we are facing. I repeat: most HDL designers don't really
> understand the technology they are using, and it's more
> than 20 year old.
>
> On the other hand: if python has a good future, and if FPGAs
> have a good future, the marxist in me (joking) believes evolutions
> towards things like MyHDL are "inevitable" - but it will take a
> new generation or an influx from different kind of people
> like enlightened embedded software designers. And of course
> we should try to make the transition as fast and smooth
> as possible through a variety of initiatives, as are being
> proposed. I will try to concentrate on technical stuff,
> including "killer features" as discussed before.
>
> For the record: I'm in this game for the long run. You may
> not hear from me for extended periods of time, but often
> that is because I'm doing a MyHDL-based design project
> with strict deadlines (like I'm doing now). Without MyHDL,
> I wouldn't bother - I have seen enough VHDL and Verilog
> for the rest of my life.
>
> On a daily basis, I try to stay motivated by having fun.
> If you like digital electronics, and if you are a Python fan,
> the choice seems obvious.
>
> Jan
>
>
> On 04/08/2011 06:18 AM, Christopher Lozinski wrote:
>> It was the last person I spoke to, I think Karl Kaiser, who gave me the
>> best advice.  MyHDL will move forward not by selling to the top of the
>> organizations, but by starting at the bottom.  Like the evolution of
>> linux, we need to get one person at a time to use it.  Support them, and
>> get the next person using it. Eventually management will find out it is
>> being used on projects, and end up supporting it.
>>
>> I had thought that the large chip vendors would jump on the board as a
>> way to sell to the python market place. Boy was I wrong.  Sure I
>> collected 3 cards, one from each of the big 3, but they just are not
>> that interested, not until such time as we start to move lots of boards,
>> at which point, we no longer really need them.  But will still welcome
>> them.
>>
>> I also thought, it is obvious this is how it should be done, there will
>> be lots of interest in consulting.  Boy was I wrong.
>>
>> The conference  had Cisco talking about 10 gigahertz data transfer
>> rates.   This FPGA array stuff still seems to be more about bandwidth,
>> then about designing complex algorithms.   One engineer was complaining
>> about not enough pin count.  Clearly his abstractions are wrong.
>>
>> There were a lot of design engineers who walked by and read our poster,
>> but had the vacant expression on their faces, like they did not
>> understand.  They didn't.
>>
>> There is strong moral support for MyHDL.   Like the guy who bought a
>> board the other day.  Like the guy who said he will have to get his boss
>> to spring for a class.  Like the three guys who have now offered to
>> connect their boards.  And starting from companies like Tachyon
>> simulation software.   And from all the lurkers on this mailing list.
>>
>> It is a start.  The longest journey begins with a single step.
>>
>> But we still have to win these guys over one engineer at a time.
>>
>> I am horrified that I saw all these people at the conference, got back,
>> and see not a single new posting on the mailing list.   I am hoping the
>> download numbers tell a different story.  What do the mailing list
>> subscriptions say?
>>
>> So here is what I propose.   Let us put together a mentoring network.  I
>> do not know about you, but I am always embarrassed to post my problems
>> to a general mailing list.  My stupidity is then on the web forever.
>> For those who are seriously interested in this stuff, let us assign them
>> a mentor.  It goes two ways.  The mentor helps them get up to speed, but
>> also the mentor gets a chance to hook them on this technology and draw
>> them in.  We hope that they will stay with the technology, and pay it
>> forward, by mentoring some other people.
>>
>> Here is my specific proposal.  Forgive me for using names before
>> speaking to these people.  They may well decline to participate.   We
>> have the two guys who want to port to their favorite boards.  Three if
>> you count Chris Felton.   Thank you.  Most appreciated.  Jan Coombs
>> asked me what he could do.  Maybe he would agree to mentor the two
>> newbies efforts.  Now he does not know everything, perhaps Chris Felton
>> would agree to only support Jan Coombs.  That would minimize Chris's
>> time.  We would have a hierachy connecting the newbies to the most
>> senior people.   The newbies get support.  The middle guys get respect.
>> The senior guys feel that their time is being well leveraged.   We can
>> all watch the network grow.  The newbies know they are just two people
>> away from the senior guys, and the senior guys know they are supporting
>> a broad network with very little time and effort.
>>
>> How does that sound?  Maybe eventually we can partition the network by
>> industry.  The image processing guys over here, the communication guys
>> over here.
>>
>> I think the grass roots approach makes sense.  I think the mentoring
>> network makes sense.  Chris Felton is still on track to push out the
>> code for the class. Jan Coombs could try it out, and document it, and
>> then push it out to his mentees.  Eventually I hope that this approach
>> would spread MyHDL in a very grass roots fashion.  Like a prairie fire.
>>
>> So let me know what you think?  Does anyone else want to be a mentor?
>> Does anyone else want mentoring?
>>
>> And my eyes are on the obligatory Design Automation Conference in June
>> in San Diego.  This time I think the banner should say:
>>
>> The Future of DA is open-source python.
>>     Understand the paradigm shift today.
>>
>> More of a marketing message than an engineering message.  We can tell
>> the managers that their teams need to understand this paradigm shift.  I
>> had so many people ask me why not C?  I should have answered because in
>> python we think about things differently, it is a paradigm shift.  We
>> are not longer doing functional decomposition into design, simulation,
>> verifaction and validation.  We are now building models, reusing class
>> libraries, benefiting from polymorphism, multiple inheritance,
>> decoration, and for the hard core python guys, acquisition, and
>> interfaces.    The different language allows a different paradigm.
>> Their organization needs to be educated about this paradigm shift.
>>
>> I wondered if we should be in the python conferences or in the design
>> automation conferences.   Clearly the big money here is in the design
>> automation conferences, not in the hackers.  And they do need our help.
>>
>> This experience has been great for me.  I have made significant progress
>> on my chip design these last few days. I had a great time.  I learned a
>> lot.  And this is way more interesting than my other job.  I will be
>> around for a while.
>>
>
>
> --
> 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
>     Analog design automation: http://www.mephisto-da.com
>     World-class digital design: http://www.easics.com
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] One Engineer at a time. Conference Report Mentorship Network Proposal

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

Thank you and the team for the hard work, and for
the honest report. I hope you're not too disappointed.

No, I don't see a substantial increase in downloads
(8 yesterday) or visits to myhdl.org (about 120 per day,
not counting the MyHDL manual).

I'm not suprized - after similar experiences in the past.
I repeat my earlier analysis about the "audience mismatch".
Did you know that when you work at ARM - the most successful
electronic IP provider - you are not allowed to use
'if' statements in HDL code? That's the kind of stupidity
that we are facing. I repeat: most HDL designers don't really
understand the technology they are using, and it's more
than 20 year old.

On the other hand: if python has a good future, and if FPGAs
have a good future, the marxist in me (joking) believes evolutions
towards things like MyHDL are "inevitable" - but it will take a
new generation or an influx from different kind of people
like enlightened embedded software designers. And of course
we should try to make the transition as fast and smooth
as possible through a variety of initiatives, as are being
proposed. I will try to concentrate on technical stuff,
including "killer features" as discussed before.

For the record: I'm in this game for the long run. You may
not hear from me for extended periods of time, but often
that is because I'm doing a MyHDL-based design project
with strict deadlines (like I'm doing now). Without MyHDL,
I wouldn't bother - I have seen enough VHDL and Verilog
for the rest of my life.

On a daily basis, I try to stay motivated by having fun.
If you like digital electronics, and if you are a Python fan,
the choice seems obvious.

Jan


On 04/08/2011 06:18 AM, Christopher Lozinski wrote:
> It was the last person I spoke to, I think Karl Kaiser, who gave me the
> best advice.  MyHDL will move forward not by selling to the top of the
> organizations, but by starting at the bottom.  Like the evolution of
> linux, we need to get one person at a time to use it.  Support them, and
> get the next person using it. Eventually management will find out it is
> being used on projects, and end up supporting it.
>
> I had thought that the large chip vendors would jump on the board as a
> way to sell to the python market place. Boy was I wrong.  Sure I
> collected 3 cards, one from each of the big 3, but they just are not
> that interested, not until such time as we start to move lots of boards,
> at which point, we no longer really need them.  But will still welcome
> them.
>
> I also thought, it is obvious this is how it should be done, there will
> be lots of interest in consulting.  Boy was I wrong.
>
> The conference  had Cisco talking about 10 gigahertz data transfer
> rates.   This FPGA array stuff still seems to be more about bandwidth,
> then about designing complex algorithms.   One engineer was complaining
> about not enough pin count.  Clearly his abstractions are wrong.
>
> There were a lot of design engineers who walked by and read our poster,
> but had the vacant expression on their faces, like they did not
> understand.  They didn't.
>
> There is strong moral support for MyHDL.   Like the guy who bought a
> board the other day.  Like the guy who said he will have to get his boss
> to spring for a class.  Like the three guys who have now offered to
> connect their boards.  And starting from companies like Tachyon
> simulation software.   And from all the lurkers on this mailing list.
>
> It is a start.  The longest journey begins with a single step.
>
> But we still have to win these guys over one engineer at a time.
>
> I am horrified that I saw all these people at the conference, got back,
> and see not a single new posting on the mailing list.   I am hoping the
> download numbers tell a different story.  What do the mailing list
> subscriptions say?
>
> So here is what I propose.   Let us put together a mentoring network.  I
> do not know about you, but I am always embarrassed to post my problems
> to a general mailing list.  My stupidity is then on the web forever.
> For those who are seriously interested in this stuff, let us assign them
> a mentor.  It goes two ways.  The mentor helps them get up to speed, but
> also the mentor gets a chance to hook them on this technology and draw
> them in.  We hope that they will stay with the technology, and pay it
> forward, by mentoring some other people.
>
> Here is my specific proposal.  Forgive me for using names before
> speaking to these people.  They may well decline to participate.   We
> have the two guys who want to port to their favorite boards.  Three if
> you count Chris Felton.   Thank you.  Most appreciated.  Jan Coombs
> asked me what he could do.  Maybe he would agree to mentor the two
> newbies efforts.  Now he does not know everything, perhaps Chris Felton
> would agree to only support Jan Coombs.  That would minimize Chris's
> time.  We would have a hierachy connecting the newbies to the most
> senior people.   The newbies get support.  The middle guys get respect.
> The senior guys feel that their time is being well leveraged.   We can
> all watch the network grow.  The newbies know they are just two people
> away from the senior guys, and the senior guys know they are supporting
> a broad network with very little time and effort.
>
> How does that sound?  Maybe eventually we can partition the network by
> industry.  The image processing guys over here, the communication guys
> over here.
>
> I think the grass roots approach makes sense.  I think the mentoring
> network makes sense.  Chris Felton is still on track to push out the
> code for the class. Jan Coombs could try it out, and document it, and
> then push it out to his mentees.  Eventually I hope that this approach
> would spread MyHDL in a very grass roots fashion.  Like a prairie fire.
>
> So let me know what you think?  Does anyone else want to be a mentor?
> Does anyone else want mentoring?
>
> And my eyes are on the obligatory Design Automation Conference in June
> in San Diego.  This time I think the banner should say:
>
> The Future of DA is open-source python.
>     Understand the paradigm shift today.
>
> More of a marketing message than an engineering message.  We can tell
> the managers that their teams need to understand this paradigm shift.  I
> had so many people ask me why not C?  I should have answered because in
> python we think about things differently, it is a paradigm shift.  We
> are not longer doing functional decomposition into design, simulation,
> verifaction and validation.  We are now building models, reusing class
> libraries, benefiting from polymorphism, multiple inheritance,
> decoration, and for the hard core python guys, acquisition, and
> interfaces.    The different language allows a different paradigm.
> Their organization needs to be educated about this paradigm shift.
>
> I wondered if we should be in the python conferences or in the design
> automation conferences.   Clearly the big money here is in the design
> automation conferences, not in the hackers.  And they do need our help.
>
> This experience has been great for me.  I have made significant progress
> on my chip design these last few days. I had a great time.  I learned a
> lot.  And this is way more interesting than my other job.  I will be
> around for a while.
>


-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] help - hot bit encoder

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

On 03/04/11 12:02, Jan Decaluwe wrote:
 > Jan:
 >
 > You struggle    . . .

Yes. I have a little karma elsewhere, and want to publish this code 
yesterday to promote MyHDL.  It is important that it can be 
exported as Verilog.  I have the required functionality, but am 
having trouble converting the result back to a bit vector.  I'd 
like to move on, please help.  Code, ready to test, is attached.

Jan Coombs.