Want to get into FPGA

[rickman]

On Sep 9, 1:00 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

rickman <gnu...@gmail.com> wrote:
On Sep 8, 7:23 pm, Socrates <mail...@gmail.com> wrote:
In terms of FPGAs, the BS might indicate that you can program in a HDL,
MS that you understand HDLs in general, and PhD that you understand how
HDLs actually work.
Well, thats the point! I would like to go for MSEE somewhere in
Europe. Some people recommends me RWTH @ Germany. Maybe any other
offers in other places? I am mainly pointing to FPGA design
studies.
What would you like to learn about FPGAs?  I can't see how FPGAs would
be a topic of study in any level of school, not just graduate school.
FPGAs are where you would apply the general design theory you learn as
an undergraduate, but I don't see how there is anything you could
learn beyond that which would be a topic of "study".  Typically areas
of application are what you learn after you get out of school.

I think I agree with this.  The subject is digital logic and
logic design, with FPGAs as a practical and affordable way
to implement such designs.  

In addition, HDL is a way to write down logic that gets too
complicated to fit drawn on gates on a single piece of paper.

When I got my undergraduate, they taught us Karnaugh maps and various
methods of logic minimization as well as describing how PLAs worked.
But PLAs were a part of one class, not a topic of study.  On the other
hand, I took a class in more advanced logic design techniques which
covered things like string recognizers, state equivalence (in FSMs)
and asynchronous logic, all of which are applicable to PLAs as well as
FPGAs.

I don't know how many of those they still teach.  I do believe
that asynchronous (dual-rail, self-timed logic) is a lost art
by now.  I never got to take the class, but I do remember others
who did explaining how dual-rail logic works.

What would be the topics of study in FPGA design?  I can't think of
anything I have learned about FPGAs that would be considered college
level material.  Or are you thinking of how to design FPGA
architectures rather than FPGA usage?

Well, there do have to be a few of those.  Though I think by now,
it is more a marketing issue than a design issue.  I could come
up with many FPGA designs, but they would never get past any
marketing department.

I have wondered about an FGPA specifically for dual-rail
asynchronous logic.  No useless FF's, and routing optimized
for dual rail signaling.

I don't see HDL and FPGA as being synonymous as HDLs apply to all
logic devices, not just FPGAs.

-- glen

I'm not familiar with dual-rail async logic. What we learned was just
how to implement state machines in async logic which means every state
transition has to be designed and implemented in specific gates so
that the transitions go through a known sequence of meta-states as the
logic changes. At least that is what I recall about it. It was a
looooonnnng time ago and I never used it. I've only seen one async
design that that used a chip (again some thirty years ago) that was
designed to implement async logic. The advantage was it should have
been faster to respond to an input change since it didn't wait for a
clock.

It is a little scary thinking about my early FSM designs. I was
working for some 10 years or more before I learned about meta-
stability. In fact, I worked on a TTL logic design in one of my first
jobs that was not working right because of a problem with unsync'ed
inputs. I don't know that it was a meta-stability issue, but it
likely would have shown up if the more obvious problem wasn't
occurring more often. Military radar jamming equipment IIRC. I
expect it worked well enough to do the job to spec.

Rick

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:
(snip, I wrote)

I don't know how many of those they still teach.  I do believe
that asynchronous (dual-rail, self-timed logic) is a lost art
by now.  I never got to take the class, but I do remember others
who did explaining how dual-rail logic works.
(snip)

I have wondered about an FGPA specifically for dual-rail
asynchronous logic.  No useless FF's, and routing optimized
for dual rail signaling.
(snip)

I'm not familiar with dual-rail async logic. What we learned was just
how to implement state machines in async logic which means every state
transition has to be designed and implemented in specific gates so
that the transitions go through a known sequence of meta-states as the
logic changes. At least that is what I recall about it. It was a
looooonnnng time ago and I never used it.

Yes, a looonnng time ago, and I didn't even take the class.
I just remember discussing it with the people who were taking
the class.

There are a few sentences in the wikipedia Asynchronous_system page.

Every input needs three states, '0', '1', and 'no data'. Similar
to the input of an RS flip-flop, there are two lines, one goes
active for a '0', the other for a '1', and neither if no data is
being sent. Both active is an illegal state.

For a given logic block, all the inputs go to either '0' or '1',
then wait until the acknowledgement comes back. Then the inputs
(I believe at least one, though maybe all) go to the 'no data'
state until acknowledge goes away.

Inputs need to have three states, otherwise there is no way to
know when they are ready.

Well, the wikipedia page also describes single rail logic.
That seems not to be completely asyncronous, such that only
one 'ready' input is used for all the data lines.

I've only seen one async
design that that used a chip (again some thirty years ago) that was
designed to implement async logic. The advantage was it should have
been faster to respond to an input change since it didn't wait for a
clock.

It is a little scary thinking about my early FSM designs. I was
working for some 10 years or more before I learned about meta-
stability. In fact, I worked on a TTL logic design in one of my first
jobs that was not working right because of a problem with unsync'ed
inputs. I don't know that it was a meta-stability issue, but it
likely would have shown up if the more obvious problem wasn't
occurring more often. Military radar jamming equipment IIRC. I
expect it worked well enough to do the job to spec.

-- glen

 

[-jg]

On Sep 1, 8:52 pm, RealInfo <therighti...@gmail.com> wrote:

Hi all
I am a 52 years old electronics technician with massive experience in
analog electronics like audio and power supplies .

I want to start a career in FPGA designing .

My intention is to buy a good book and a good FPGA
evaluation board and to do some projects on it to
get experience .

I did some work in VHDL in the past .

My question is do I have a real chance to get into this field now
at my age ?

FPGA are just another tool in the toolbox, and it is a VERY wide
field.

If you build into it, by extending what you know already, it should
not be too difficult.

eg Quite a bit of scope for programmable Logic, in power supply
designs.

Possible pathways:

I see Lattice have a $29 special on their XP2 FPGA board. (Parallel
cable)
http://www.latticesemi.com/

Or, you could start with simpler CPLD programmable logic
via their ispmach4000zepicodevkit
- this includes a LCD display, and has a USB link, plus USB parallel
path, via a FT2232D.

Another training path, is the Cypress PSOC3/5
These are Processor (8051/ARM) plus moderate CPLD fabric, and you can
get going for $49.

-jg

 

[Socrates]

And are those generic design techniques not learned in school?  Of
course they are taught.  They just don't have specialized courses in
FPGA design because most of these techniques are not unique to FPGAs.
HDL is the only part of FPGA design that is not widely used in other
areas and that is also used, and in fact was invented for, chip
design.

Well, that's the point. There was no classes about HDL itself. Yes,
there was digital devices class, where students get information about
inverters/and/or gates and flip-flops, but not HDL itself, just
discrete elements. Someone mentioned here that MSEE could be the way
to get deeper, gain more experience and fill up empty knowledge spaces
- that is what I want, to have a course of deep analysis of the
system, not particularly FPGA or ASIC.

 

[rickman]

On Sep 9, 7:09 pm, Socrates <mail...@gmail.com> wrote:

And are those generic design techniques not learned in school?  Of
course they are taught.  They just don't have specialized courses in
FPGA design because most of these techniques are not unique to FPGAs.
HDL is the only part of FPGA design that is not widely used in other
areas and that is also used, and in fact was invented for, chip
design.

Well, that's the point. There was no classes about HDL itself. Yes,
there was digital devices class, where students get information about
inverters/and/or gates and flip-flops, but not HDL itself, just
discrete elements. Someone mentioned here that MSEE could be the way
to get deeper, gain more experience and fill up empty knowledge spaces
- that is what I want, to have a course of deep analysis of the
system, not particularly FPGA or ASIC.

Then stick with us kid, stick with us. We'll teach you everything you
need to know. Really. Schools don't teach the practical aspects of
engineering. They teach the stuff that came from somebody publishing
a paper at some point even if it was a hundred years ago.

I remember taking Diff Eq which was mostly filled with engineers.
About half way through the course someone asked what this stuff was
used for. The instructor said he didn't know and didn't care, this
was math!

Even the engineering schools aren't too far from that.

But I will agree, HDL should be taught just like they teach Fortran
and assembly language programming... they do still teach those,
right? But seriously folks, they do teach programming languages and I
think they ought to teach both Verilog and VHDL in undergraduate
courses. It might only be a single semester course, but if they did
it right, it fo a long way to starting you off on the right foot.
Learning to program in HDL is not really the same as wiring gates
together.

Rick

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:
(snip)

Then stick with us kid, stick with us. We'll teach you everything you
need to know. Really. Schools don't teach the practical aspects of
engineering. They teach the stuff that came from somebody publishing
a paper at some point even if it was a hundred years ago.

I remember taking Diff Eq which was mostly filled with engineers.
About half way through the course someone asked what this stuff was
used for. The instructor said he didn't know and didn't care, this
was math!

That sounds usual, but you do know that they are used in
engineering, even if the instructors didn't.

There is always the disconnect between the math department
(teaching the math) and the physics department (using it).
I have known schools to have a big conference between the
two departments, but the problem is always there. Pretty
much the same with engineering, though likely more disconnect
and less discussion.

I do remember my E&M TA noticing the distinction between those
who would be theoretical physics, and those who would be engineers
or experimental physics. Depending on the problem, one group or
the other would do well, but often not both.

I also remember a physics quiz needing a solution to a
differential equation the day before we learned how to
solve it in math class. Off by that much.

Even the engineering schools aren't too far from that.

But I will agree, HDL should be taught just like they teach Fortran
and assembly language programming... they do still teach those,
right? But seriously folks, they do teach programming languages and I
think they ought to teach both Verilog and VHDL in undergraduate
courses. It might only be a single semester course, but if they did
it right, it fo a long way to starting you off on the right foot.
Learning to program in HDL is not really the same as wiring gates
together.

They might not get very far, but that is all one should need.
Then get a book and start writing.

-- glen

 

[cvaldess]

Hi all,

I´m new to FPGA world too and just buy xilinx SP605, RF (SDR) are my
target, know there long way learning but like to learn.

there any place where start reading about?? any tips??

for now will start with USRP from gnu radio, my first plan is to port
the USRP2 code to the SP605 and design(OpenHardware) a FMC card with
the ADC/DAC and RF front end.

any help will good,

Thanks,
C.V

 

[rickman]

On Sep 9, 11:01 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

rickman <gnu...@gmail.com> wrote:

(snip)

Then stick with us kid, stick with us.  We'll teach you everything you
need to know.  Really.  Schools don't teach the practical aspects of
engineering.  They teach the stuff that came from somebody publishing
a paper at some point even if it was a hundred years ago.
I remember taking Diff Eq which was mostly filled with engineers.
About half way through the course someone asked what this stuff was
used for.  The instructor said he didn't know and didn't care, this
was math!

That sounds usual, but you do know that they are used in
engineering, even if the instructors didn't.

In theory, yes. But we have other ways of skinning that cat, no?
Laplace lets us change the awkward diff eq into much simpler
equations. I actually don't recall ever needing to figure out a diff
eq using any of the methods from the class. But it is important to
understand what they are about. A lot of stuff builds on them.

I do remember my E&M TA noticing the distinction between those
who would be theoretical physics, and those who would be engineers
or experimental physics.  Depending on the problem, one group or
the other would do well, but often not both.

At UM they had separate classes. There was a two semester physics
sequence for Chem majors, a three semester sequence for engineers and
a four semester sequence for the physics majors. I expect there was a
one semester race through for some other majors but I don't recall. I
was a chem major and took the engineering sequence just for fun... and
was covering my bases in case I switched. In the end, I got the BS in
Chem and went back for a MSEE.

Even the engineering schools aren't too far from that.
But I will agree, HDL should be taught just like they teach Fortran
and assembly language programming... they do still teach those,
right?  But seriously folks, they do teach programming languages and I
think they ought to teach both Verilog and VHDL in undergraduate
courses.  It might only be a single semester course, but if they did
it right, it fo a long way to starting you off on the right foot.
Learning to program in HDL is not really the same as wiring gates
together.

They might not get very far, but that is all one should need.
Then get a book and start writing.

I have found there is a lot to HDL that isn't really explained fully
in books. At least I've never seen it all in one book. But then I
guess that stuff wouldn't be covered in a class either. That is the
stuff I would need to learn if I ever switch to Verilog.

Rick

 

[Jan Coombs]

On 09/09/10 18:00, glen herrmannsfeldt wrote:
<snip>

I have wondered about an FGPA specifically for dual-rail
asynchronous logic. No useless FF's, and routing optimized
for dual rail signaling.

These parts are sold as high speed '1.5GHz', may be targeted by
synchronous designs, but are asynchronous internally:

http://achronix.com/technology.html

Detailed technical info seems hard to come by, but this seemed a
reasonable read:

http://www.en-genius.net/site/zones/programmablelogicZONE/product_reviews/plp_121508

Jan Coombs
--
(remove all x from email)