Re: FPGA with 5V and PLCC package
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: Fri, 23 Mar 2007 14:26:34 -0800
cs_posting@xxxxxxxxxxx wrote:
On Mar 22, 5:34 am, Herbert Kleebauer <k...@xxxxxxxxx> wrote:
(snip)
I don't know if all the supporters of VHDL/Verilog/HandleC here have
done low level logic development using a graphical representation and
just don't recognize how important that is to become a good designer
at VHDL level.
The problem I see is that you are making the assumption that
_graphical representation_ is the only appropriate way to do low level
design. I'd argue it generally isn't.
I have to argue somewhere in between. The designer should have some
idea about what is going on in the hardware. For FPGA it isn't quite
as easy to see, so imagine a standard cell design instead. For standard
cell the actual complexity is closer to that seen by the designer.
It does help to imagine it in terms of gates, just as a C programmer
can imagine his code in terms of machine instructions. Though with
modern RISC machines you might be as far from what one can imagine
as FPGAs are from gates. One should be able to choose a design
based on complexity or speed. (Often speed is more important
than size, and that isn't so obvious if you can't imagine the
gate level.)
More suitable low level design notations are things like minimum-sum-
of-products equations, and the Karnough maps that one might use to
create those by hand. Sum of products is directly implementable in
hardware - you could indeed have them draw some representative
examples as gates. But it's a much better notation system when you
find it necessary to take the black boxes apart and look at their
functionality.
One has to look at the problem at different levels. One is the
gate level, another would have been the MSI level in TTL days,
adders, counters, multiplexers, decoders. One doesn't need the
exact details (though I do still like to see the designs in the
TTL data book), but just to know how complex each one is or isn't.
(snip)
A key reality that you are refusing to acknowledge is that you will
not receive an actual "map to the city" of anything but a first-
generation FPGA. That kind of detail is proprietary. What you get on
the data sheet is a programming model, with a lot of things already
hidden from you. Using an FPGA to implement something that you've
designed at the gate level is not a bad idea, but you must come to
terms with the fact that your gate level design is only theoretical -
even if you draw it in schematic entry, the tools is going to refactor
it using its knowledge of the proprietary details of the hardware.
That is true, but as I said one can imagine it for standard cell.
One might even be able to run the synthesis and P&R for a standard
cell design to see how big or small things actually are.
(snip)
The same is true for software: if you know how the hardware
works you maybe can choose a different approach to solve the
problem which is much more appropriate for the hardware.
This is still very true for today's software. Maybe even
more, as many of the old rules don't apply anymore. With
overlapped execution it isn't easy to predict the timing for
even simple software projects.
(snip)
The purpose of Universities is not to teach the students the
use of tools but to teach them how to recognize, analyze and
solve problems. The tools you use to solve the problems change
rapidly but the ability to understand the source of a problem
and analyze it from all angeles without using blinders is an
essential requirement for the whole life.
And ever since we stopped designing chips on single pieces of paper,
the number one skill for a solving problems has been developing a
healthy relationship with the _concept of abstraction_.
Sorry, but it really doesn't matter whether the AND gate is implemented
as AND gate, by multiplexers or as a look-up table. They have learned
that this all is equivalent and that the order of complexity is the
same. But they must learn that there is big difference in the complexity
for the ALU operation "add" and "div" and they don't see this in
the VHDL source code.
But the order of complexity really isn't the same. A four input
exclusive or gate is much more complicated than a four input nand
gate made out of transistors, but not made out of LUTs.
They most certainly will see this in the VHDL source code if you have(snip)
require them to code up the ALU functionality from sufficiently small
building blocks!
The moral? Pick your battles. Your course project doesn't have
anything that can't easily be implemented as gates and registers, so
let your students implement in a gates and registers programming
model. But recognize that just because a language will let you
utilize fancy functions like a hardware multiplier does not mean that
you have to choose to do so, or let your students do so.
One should pick the appropriate blocks, either as schematic
capture or HDL. Most schematic capture systems include a
library of logic blocks, probably similar to those available
in HDL. Actually, more than the synthesis tools will generate
directly!
-- glen
.
- References:
- FPGA with 5V and PLCC package
- From: Herbert Kleebauer
- Re: FPGA with 5V and PLCC package
- From: Herbert Kleebauer
- Re: FPGA with 5V and PLCC package
- From: cs_posting
- Re: FPGA with 5V and PLCC package
- From: Herbert Kleebauer
- Re: FPGA with 5V and PLCC package
- From: cs_posting
- FPGA with 5V and PLCC package
- Prev by Date: Re: FPGA with 5V and PLCC package
- Next by Date: Re: OPB IPIF: write to DIER causing bus timeout
- Previous by thread: Re: FPGA with 5V and PLCC package
- Next by thread: Re: FPGA with 5V and PLCC package
- Index(es):
Relevant Pages
|
