[Fpga-synth] Learning FPGA Design

[Scott Gravenhorst]

Sorry about the length of this - if you just want to see the question I
ask, please just skip to the bottom.

While working with my polysynth design, I have confronted a problem that
seems to invade my designs intermittently.  The problem is that seemingly
insignificant changes will break the design.  An example:  The current
revision of PolyDaWG/8 code had a problem I thought would be easy to fix. 
I messed up with the tuning ROM and I mapped the lowest note in the table
to the lowest note of the keyboard.  Too bad that the keyboard is a C key
and the note that comes out is a B.  The change I made was to add a
different constant to the note number to change the mapping.  I checked
carefully to make sure it wasn't an overflow problem (but even if it were,
things would be incorrectly mapped, but should still work).  The new
constant (and many others) caused the synth to stop working.  When I put
the constant back the way it was, it worked again, albeit with the wrong
pitch.  

After much tweaking and testing, I found very odd often unrelated things
would break, inducing much pate scratching.

At this point, I copied the project to a test directory and began chopping
out chunks of the design to see if removing a particular piece would allow
the rest of it to work reliably.  

I ended up with the current test project which is nothing more than a MIDI
to TTY monitor program (two UARTs and a PicoBlaze).  

When I connect LEDs to different parts of this design it would
intermittently work or not work.  The RTL schematic always seemed like it
should work.  There were never any errors.

In that effort, I discovered some surprising (to me) things.  I found, for
example, that there are many more than one ways to manifest a toggle flip
flop, all of which look just fine in the RTL schematic, but simply don't
work.  Others worked as expected.

This wouldn't work:

reg QQ = 0;
always @ ( posedge clk ) QQ <= ~QQ;
assign led = {QQ,7'b0000000};

While this did work:

reg QQ = 0;
always @ ( posedge clk ) QQ <= QQ + 1;
assign led = {QQ,7'b0000000};

The schematic for the first one shows a D flipflop with the output passed
through an inverter back to the input.  Another odd thing is that the
second example, which works, produces an interesting RTL schematic
manifestation.  In the top level schematic, a box which looks like a module
instance appears with a name of QQ.  Opening the instance reveals an
internal flipflip with the inverter inside the module.  The instance type
is called out as "lpm_tff_3" and seems to be part of a library of
parameterized modules apparently supported internally.  I just found that
interesting.  

Oddly, the configurations which break the design (i.e., no output to the
TTY port) show that the toggle flipflop is actually working - and the
toggle flipflop has *nothing* to do with the MIDI to TTY portion.

I also noticed that in both of the UART modules (I use Jim Patchell's
Verilog UART modules) there were several AND gate that had only one input
connected and nothing connected to their outputs.  The inputs that were
connected went back to "CS" which is a 4 bit register used in state
maintenance.  The CS output was labeled "for debug", so I deleted the
"output" specification from these modules.  The weird AND gate problem
abated and all of a sudden all but three of the LED connection
configurations began to work.  One of the ones that doesn't work is
admittedly oddly expressed:

reg QQ = 0;
always @ ( posedge clk )
  begin
  if ( QQ == 1'b0 ) QQ <= 1'b1;
  else              QQ <= 1'b0;
  end

The above flipflop is actually flipping and flopping, but the rest of the
design is broken.  The same is true of the simpler versions which do this:

always @ ( posedge clk ) QQ <= ~QQ;

and

always @ ( posedge clk ) QQ <= QQ ^ 1'b1;

The flipflop flipflops, but no TTY output.  In these cases, I saw nothing
in the RTL schematic that indicated a misconnection.

Part of the problem with this is that connecting the LEDs to something may
or may not help me in that the connection could break something unrelated
to what I am trying to test.

=======================================================================

Most of you know that I am not formally educated in this field, so I
haven't had the benefit of sagacious professors warning me of certain pitfalls.

Is there a good book or set of books which can help me eliminate bad
technique from my designs?  I am gradually learning about some things such
as sprawling designs with many wide busses and designs with asynchronous
activity that can be made synchronous.  I've seen these truncated AND gates
appear as a result of my code, sometimes they are hard to track down, but
often they seem to portend failure of the design.

So - any book titles?  Or am I doing what needs to be done, fall into the
punji stick pit, crawl out and try again?

-- ScottG (who's body is perforated with punji stick holes)

-------------------------------------------------------------

-- Scott Gravenhorst
-- GateMan II - Xilinx Spartan-3E Based MIDI Synthesizer with SVF
-- PolyDaWG/8 - 8 Voice FPGA Polyphonic MIDI Synthesizer
-- FatMan: home1.gte.net/res0658s/fatman/
-- NonFatMan: home1.gte.net/res0658s/electronics/
-- When the going gets tough, the tough use the command line.