Thanks re Introducing FPGA's, now - More Questions

[jdw]

It is gratifying to observe genuine interest in the challenges of an
unknown individual, being addressed in a meaningful way, by so many
helpful souls! Thanks! Being a newcomer, the following commentary
may in fact be off topic to the group so please provide me with
feedback to that effect, if such is the case.

Perhaps, in posting initially, I should have been more explicit.
However the replies were generally right on and helpful. I plan to be
a part of this group in the future as I attempt to learn the basics of
VHDL. Initially it looks more than "Very Hard" DL but what I am
finding is that part of its difficulty lies simply in becoming
familiar with the syntax and structure. At my age that means constant
repetitive exposure, even when full understanding is lacking, is still
useful.

Teaching at a level where our top student could be successful at
university, but an average student would not, is a challenge. Our
graduates are 2 year, EET (electronic engineering technologist) and so
it is important, I believe, to have a real, interesting, breadboarding
kind of activity associated with all major topics. We are aiming at
having the student demonstrate some creativity rather than doing show
and tell. For example, I am not inclined to want to teach FPGA's from
a strictly schematic capture perspective, although having limited
experience, I am ready to be enlightened. There are good suggestions
in the replies I received that I will be following up on.

At this moment if anyone would like to offer more very specific
suggestions I would be most appreciative. Remember please, that I
have no previous experience with FPGA's other than having a good
understanding of the basics of pld's and the pal22v10 in particular.
I might add that CUPL has been a very good tool for what we have been
doing and I believe that our students have been able to fully
appreciate how code turns into a fuse plot that is no different than
the discrete design they might have implemented. Is there
justification for keeping the limited CUPL coverage in the
introductory course and then pushing for the creation of a second
course which introduces VHDL? Is it justifiable to press for FPGA and
VHDL coverage if that would have negative reprecussions on our fairly
substantial Micro-Computer coverage using the HC11? We presently have
no explicit coverage on micro-controllers (pics) - any comment on
where we presently find ourselves? I already know we are sadly out of
touch - there is a fair amount of complacency here. I am confident
that we are doing a very good job with introductory material in
digital but beyond that we need to update.

Please make any suggestions, i.e. which tools are the best in your
opinion, as specific and practical as possible. Thanks in advance.

Jack

 

[Andy]

It is gratifying to observe genuine interest in the challenges of an
unknown individual, being addressed in a meaningful way, by so many
helpful souls! Thanks! Being a newcomer, the following commentary
may in fact be off topic to the group so please provide me with
feedback to that effect, if such is the case.

Perhaps, in posting initially, I should have been more explicit.
However the replies were generally right on and helpful. I plan to be
a part of this group in the future as I attempt to learn the basics of
VHDL. Initially it looks more than "Very Hard" DL but what I am
finding is that part of its difficulty lies simply in becoming
familiar with the syntax and structure. At my age that means constant
repetitive exposure, even when full understanding is lacking, is still
useful.

Teaching at a level where our top student could be successful at
university, but an average student would not, is a challenge. Our
graduates are 2 year, EET (electronic engineering technologist) and so
it is important, I believe, to have a real, interesting, breadboarding
kind of activity associated with all major topics. We are aiming at
having the student demonstrate some creativity rather than doing show
and tell. For example, I am not inclined to want to teach FPGA's from
a strictly schematic capture perspective, although having limited
experience, I am ready to be enlightened. There are good suggestions
in the replies I received that I will be following up on.

At this moment if anyone would like to offer more very specific
suggestions I would be most appreciative. Remember please, that I
have no previous experience with FPGA's other than having a good
understanding of the basics of pld's and the pal22v10 in particular.
I might add that CUPL has been a very good tool for what we have been
doing and I believe that our students have been able to fully
appreciate how code turns into a fuse plot that is no different than
the discrete design they might have implemented. Is there
justification for keeping the limited CUPL coverage in the
introductory course and then pushing for the creation of a second
course which introduces VHDL? Is it justifiable to press for FPGA and
VHDL coverage if that would have negative reprecussions on our fairly
substantial Micro-Computer coverage using the HC11? We presently have
no explicit coverage on micro-controllers (pics) - any comment on
where we presently find ourselves? I already know we are sadly out of
touch - there is a fair amount of complacency here. I am confident
that we are doing a very good job with introductory material in
digital but beyond that we need to update.

Please make any suggestions, i.e. which tools are the best in your
opinion, as specific and practical as possible. Thanks in advance.

Jack

One area where you might find synergy is between an FPGA/VHDL course
and a microprocessor course. One of the really cool things available
in FPGAs is soft-core processors (processors built out of the LUTs and
registers in the FPGA). The ability to virtually breadboard a
processor together with "peripherals" (uart, memory, interrupt
controllers, etc.), all inside the FPGA, could be very flexible and
effective for teaching the basic elements of a microprocessor system.
Later stages in the course could delve into the design of the
processor itself (assuming you pick an open source processor core),
with projects for designing extensions to the processor (new
instructions, addressing modes, etc.) to be completed by students. I
wish we had such stuff when I was getting my BSEE degree 22+ years
ago! On the other hand, I'd have never made it to class, always
playing with an FPGA demo board if I had one then.

I would stay away from schematic capture. Coding styles can be taught
to emulate netlisting if desired (very introductory), followed my more
functional styles that require the synthesis tool to infer circuitry
from a functional descriptions(advanced). If a microprocessor course
is already taught, then your students are expected to know about
programming languages, etc. at least at an introductory level, and
VHDL can build on (or provide a foundation for) that. VHDL can also be
used to build test benches that stimulate and monitor the "unit under
test", all from a computer.

In PAL/CPLD design, you focus on sum of products representations of
functions (since that determines what will fit where in a 22v10),
whereas before those, we focused on building functions out of gates,
multiplexers, encoders, decoders, etc. With the advent of schematic
capture for FPGAs, I kind of went full circle back to the gates/muxes/
encoders/decoders for a while. Then when we started using VHDL, a more
functional/behavioral approach emerged, similar to Abel/CUPL, but
without the emphasis on SOP implementations.

I'm not generally familiar with EET degrees to know what they are
expected to master upon graduation, so some of this may be out of
scope for such a program.

Andy

 

[Mike Treseler]

I plan to be
a part of this group in the future as I attempt to learn the basics of
VHDL. Initially it looks more than "Very Hard" DL but what I am
finding is that part of its difficulty lies simply in becoming
familiar with the syntax and structure.

My guru on these topics is modelsim.
The error messages are clear and to the point
and the the master is endlessly patient.


-- Mike Treseler

 

[Brian Drummond]

It is gratifying to observe genuine interest in the challenges of an
unknown individual, being addressed in a meaningful way, by so many
helpful souls! Thanks! Being a newcomer, the following commentary
may in fact be off topic to the group so please provide me with
feedback to that effect, if such is the case.

Perhaps, in posting initially, I should have been more explicit.
However the replies were generally right on and helpful. I plan to be
a part of this group in the future as I attempt to learn the basics of
VHDL. Initially it looks more than "Very Hard" DL but what I am
finding is that part of its difficulty lies simply in becoming
familiar with the syntax and structure. >It is gratifying to observe genuine interest in the challenges of an
unknown individual, being addressed in a meaningful way, by so many
helpful souls! Thanks! Being a newcomer, the following commentary
may in fact be off topic to the group so please provide me with
feedback to that effect, if such is the case.

Perhaps, in posting initially, I should have been more explicit.
However the replies were generally right on and helpful. I plan to be
a part of this group in the future as I attempt to learn the basics of
VHDL. Initially it looks more than "Very Hard" DL but what I am
finding is that part of its difficulty lies simply in becoming
familiar with the syntax and structure. At my age that means constant
repetitive exposure, even when full understanding is lacking, is still
useful.

Although some have suggested using schematics or other approaches to
save your students learning VHDL, I think that using VHDL may be a very
good way to start ... with a bit of guidance.

There is a lot to learn to get VHDL to do what you want - but much of it
is boilerplate - ensuring signals are the size and type you expect, and
interconnect in sensible ways. I regard it as a better tool than
Verilog; my impression is that there are fewer surprises left if you can
actually get it through the compiler ... BUT...

the actual "business" part of it, where you express operations such as
boolean equations, can be quite small and simple; certainly cleaner than
what I remember of CUPL.

Then you can introduce a standard clocked process template for
registered signals.

Then a single process state machine (simpler, shorter and easier to
maintain than the 2- and 3-process ones you see in books)

Then rational ways of doing arithmetic using numeric_std with unsigned
signals and variables (or signed where appropriate!) - where only the
top level ports need conversions to/from std_logic_vector. (Avoid the
non-standard std_logic_arith_signed_unsigned libraries like the plague,
and pass on the message LOUDLY to your students!

Then maybe a soft-core processor (I don't know if Microblaze would be
too ambitious, I think you'd want to avoid EDK. perhaps Picoblaze? )

so at least for an introductory class I believe you can supply "canned"
projects which leave only the area under discussion blank for the
students to play in; the supposed complexity of VHDL should not be a
barrier.

If you can get a syntax highlighting editor to paint the "off-limits"
sections red, the students can see what else is going on, but be
discouraged from editing it. Scripts could also check the off-limits
sections against (read-only!) reference versions.

For example a very basic exercise dealing with combinational signals
might look like...
------------------------------------------------------------------------------------------
entity adder is
-- port declarations etc
end entity;

architecture student of adder is
-- signal declarations
begin
-- message to students ! DO NOT MODIFY ABOVE THIS LINE!
-- exercise area begins here

-- fill in the blanks below

sum <=
carry <=

-- exercise area begins here
-- message to students ! DO NOT MODIFY BELOW THIS LINE!
end student;
------------------------------------------------------------------------------------------

This can be instantiated in a testbench for simulation, providing I/O,
registers, clocks etc - in parallel with a "teacher" architecture -
with a comparator checking both sets of results. Set up so that you open
the simulator, press "run", and see a waveform (as well as "asserts"
where differences occur).

It can also be dropped into a synthesis project (use a command line flow
from a pre-prepared script!) already set up to drive the blinky lights
and 7-segment display on the chosen evaluation board...

I believe you need the real hardware to engage the students, as well as
illustrating the power of simulation to catch errors.

Perhaps the adder can be instantiated in a counter...
the counter in a clock...
alongside a 7-segment decoder...

etc so the students can replace more and more of a project with their
own work as the course proceeds; then morph it into something else.

- Brian

 

[kennheinrich]

Please make any suggestions, i.e. which tools are the best in your
opinion, as specific and practical as possible. Thanks in advance.

Jack

Keep in mind that you can still do 22V10 CUPL/ABEL/PALASM style
designs in VHDL. Once you get the boilerplate code set up, there's no
reason you can't just go in and start writing the same boolean
equations you are used to. So there's no reason to be intimidated by
all the fancy stuff in the language and it's libraries; it would be
practical to still teach effectively the same course, just with a
different design tool language. You could think of the FPGA in your
demo board as a (really large) 22V10 if you wanted to.

This is likely not what the VHDL power-users would advocate, but if
you want to keep the basic ideas ("here's a NAND gate, here's an
inverted input") very simple, you could do it this way and still be
exposing your students to the very basics of VHDL.

- Kenn

 

[Chris Maryan]

I mentioned schematic capture in your previous thread, and I just want
to clarify that in no way is it a substitute for an HDL. But what it
does allow you to do is to bridge the gap between fundamental
knowledge of gates and more complex logic. The idea is that you can
introduce a latch as a series of gates with feedback, then they can
draw it in schematic capture, simulate it and see that, for example,
that series of gates holds the input value when the enable is held
low.

From there it's a pretty quick step to HDL and any arbitrary design.
The thing to stress is to make sure your students can relate their HDL
back to fundamental elements (muxes, flip flops, decoders, etc.). We
do this by making the students draw out a diagram of how they expect
their HDL to be synthesized into fundamental building blocks as part
of their lab assignments.

Chris