Book recommendation

On 10/10/13 09:47, Svenn Are Bjerkem wrote:
> I have been programming FPGA with VHDL for some years now. I came from high-speed full-custom and digital standard cell semiconductor design with cadence and that was 100% schematic capture.
>
> I have two books:
> FPGA prototyping by VHDL examples, by Pong P. Chu
> Circuit Design with VHDL, by Volnei A. Pedroni.
>
> Both books gave me a good introduction to the procedure of mapping something structural (schematic, block diagram) into something behavioural (RTL, FSM), and at the same time cover something I knew, real hardware.

Thanks, I'll have a look.


> Chu has a short tutorial on a Xilinx project to get started with the toolchain, and Pedroni has tutorials for Xilinx and Altera. I didn't follow any of these tutorials as I pretty much understood the FPGA tools by previous tool experience.

I'm sure I'll figure out the toolchain basics fairly quickly,
but I'm less convinced about the subtleties. I'm hoping
100 power tips for fpga designers" by Evgeni Stavinov
will give me some clues.


> Other than that, Xilinx has some documents on coding style, both for esthetics and for speed. Google for "xilinx coding guidelines" as they are hidden in obscure places.

I've tried "xilinx style guide", but that's a useful alternative term.


> The switch from schematic structural thinking to VHDL behavioural thinking sometimes lead to horrible code. The above books helped me through that period, specially regarding use of clock enable instead of gated clocks
Not concerned about avoiding that trap :)

> and avoid inferring unwanted latches.
...but that trap is more subtle :(


> Just remember to replace the clk'event and clk='1' with the modern rising_edge(clk) in the textbook examples.

I've read there are subtle differences, but I've forgotten what they are! "rising_edge(clk)" is terser.


> The biggest hurdle was to accept that the synthesizer could do a better job than me and stop being too clever during design.

I haven't of course, calibrated my definition of "too clever".
My current presumption is that I'll use behavioural code except
where I've decided I need a specific "high level" primitive
provided by the device manufacturer.

Svenn Are Bjerkem <svenn.bjerkem@googlemail.com> wrote:

(snip)
> The switch from schematic structural thinking to VHDL behavioural 
> thinking sometimes lead to horrible code. The above books helped 
> me through that period, specially regarding use of clock enable 
> instead of gated clocks and avoid inferring unwanted latches. 
> Just remember to replace the clk'event and clk='1' with the 
> modern rising_edge(clk) in the textbook examples.

I mostly write structural verilog, though behavioral for FFs
(the only way I know) and usually behavioral for state machines.
 
> The biggest hurdle was to accept that the synthesizer could do 
> a better job than me and stop being too clever during design.

Yes, this one I agree with. Though they don't find everything,
there are many cases where they can do well with more obvious,
and not so efficient looking, code.

-- glen