On Mon, 26 Nov 2007 12:05:44 -0800 (PST), jdw <[email protected]> wrote:

>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