[Fpga-synth] Learning FPGA Design

[Eric Brombaugh]

Scott,

That's an interesting account of HDL traps you've collected, but I can't 
look at any of your code examples and categorically state "That one is 
wrong." - they all look workable to me, and the one you specifically 
said doesn't work actually looks like the best representation in my 
experience.

You asked for a recommendation of a text which could warn you away form 
these problems, and unfortunately I can't give you any suggestions. I've 
been coding HDL for synthesis and simulation for almost 20 years now as 
well as taken classes from a wide variety of tool vendors and there is 
no one guaranteed way to success. The reason for this is simple - every 
simulator and synthesis tool out there was written by different people 
and will have different quirks. Your job as a user of these tools is to 
quickly find out where the snags are in the tool you're using today and 
remember to avoid them tomorrow. The unfortunate implication of this is 
that when the tool changes you'll likely have to rediscover the new snags.

Text books, vendor instruction and college courses can't lay these 
problems out for you in advance - the best preparation they can give you 
is rules of thumb for writing maintainable code and processes for 
debugging when you hit the inevitable problems. You have to supply the 
drive and intelligence to use these techniques to get a successful 
design, and from what I've read below you are doing fine in that regard.

Just wanted to let you know that you're not alone - these are problems 
that even the pros beat their heads against.

Eric

PS - Not to knock academia, but 'sagacious professors' are rare birds 
when it comes to these sorts of practical aspects of engineering. Most 
college EE professors don't know which end of a soldering iron to grab, 
and are way too busy hustling research grants and herding grad students 
to keep up with the fast pace of EDA tool evolution. They're the last 
people I'd look to for wisdom in this area.

Scott Gravenhorst wrote:
> 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.
> 
> _______________________________________________
> Fpga-synth mailing list
> Fpga-synth at rubidium.dyndns.org
> http://rubidium.dyndns.org/cgi-bin/mailman/listinfo/fpga-synth
>