Guest
On Jun 23, 12:16 pm, Andy <jonesa...@comcast.net> wrote:
It's really interesting to hear all of the intelligent comments in
this thread, and I can agree to a certain extent with most of the
viewpoints. I think the root issue being debated here is how best to
implement a design - using a bigger emphasis on "hardware-ish pure
structure" or more on the "software-ish procedural approach". They are
certainly closely related, but are definitely not equivalent. The "old-
timers" who grew up with boards filled with 74LS logic and 22V10's
will likely feel more comfortable with the hardware-ish approach -
it's just an extension of hierachical schematics. The more
intellectually adventurous old-timers will then discover functions and
procedures and use these to neaten up their code. Those with a strong
software background will often see everything as a procedure and not
intuitively see how the entity/architecture/component structuring
would be the right approach in part of the design.
There are some places where E/A structuring is dead-simply the right
thing. For example, an FPGA which requires N identical (or nearly
identical, modulo some generics) modules - DRAM controllers, gigabit
transceiver modules, register files, what have you. If an FPGA vendor
tells me they have a big honking hardware block that does function X
for me, for free, then the right thing is to plonk it down as a
component instance. No matter how elegant the academic theory behind
it might be, I'll never try to infer a Sonet controller similarly to
the way I infer a block RAM. (Even a dual-port RAM doesn't infer
right half the time - anyone who's done it will probably agree.) No
amount of procedural finessing can work around this.
But there are other places where the old-time hardware guy is missing
the boat by slavishly implementing every little piece of his design
using the explicit combinatorial logic and flops he sees in his head
as he considers what the schematic for his circuit ought to look
like. The CRC is a nice example - with the right procedures defined,
the circuit using the procedures is short, concise, understandable,
and easy to modify. The manually written mess of gates, or even the
inline instantiation of a separate CRC-32 engine can be much longer,
less obvious, and interrupt the "flow" of your description. These can
become critical things as the complexity of your design grows.
Both styles need to be written with the right amount of room to grow.
This is basic good design practice, and it's as much an art as a
science. Room to grow, and good engineering, encompasses using the
right parameterization (generics), the right default values, the right
use of procedural style and instantiation at the right layers, and the
right interfaces, among all of the other choices related to the
implementation of the design itself.
I've seen guys who implement every interface as a std_logic_vector,
that just grows, and grows, and grows, as needed. I've also seen their
code: it's an endless sea of meaningless code like
if (interface_a(16) and not interface_b(14)) then -- this means the
event triggered
interface_c(14) := '1'; -- so clear the reset
The use of records as a conduit (I like that analogy) is one good
technique to manage the OP's original problem. It has other VHDL-
imposed drawbacks though - there are all sorts of rules about
partially associated records in interfaces, resolved vs non-resolved
records types, multiple drivers, interface element modes, and so on.
It's like a poor-man's version of type polymorphism (not the same as
the parametric polymorphism when we talk about overloading
operators). It's type polymorphism because if your conduit just goes
between two levels, you can make it carry the right type by editing
your record definition in the package. It's poor-man's because there
no way of automatically inferring the type of the pipe -- if an entity
does nothing more than carry a unidirectional signal from the outer
ports to an inner component, why can't I just say "connect the two",
rather than spelling it all out, manually, over and over. This feature
(type polymorhism) is a nice feature in languages like Standard ML and
Haskell, which use well known and well understood mechanisms to make
this happen nicely. These solutions are also guaranteed to be type-
safe, which is the reason we have so much explicit type specification
in VHDL to begin with! Unfortunately, I can see this would be
difficult to implement with all of the extra quirks of the language
(port modes, multiple driver rules, resolution, etc, not to mention
possible interactions with conventional VHDL name resolution).
What does this all mean? VHDL is quirky, obviously "designed by
committee", and large. But it's also flexible, and you can generally
do most of what you need, once you get your head around it. At the end
of the day it's just a tool, and the tool is nothing better than the
person wielding it.
(Going off to the woodpile to get my axe... now THERE's a tool
- Kenn
It's really interesting to hear all of the intelligent comments in
this thread, and I can agree to a certain extent with most of the
viewpoints. I think the root issue being debated here is how best to
implement a design - using a bigger emphasis on "hardware-ish pure
structure" or more on the "software-ish procedural approach". They are
certainly closely related, but are definitely not equivalent. The "old-
timers" who grew up with boards filled with 74LS logic and 22V10's
will likely feel more comfortable with the hardware-ish approach -
it's just an extension of hierachical schematics. The more
intellectually adventurous old-timers will then discover functions and
procedures and use these to neaten up their code. Those with a strong
software background will often see everything as a procedure and not
intuitively see how the entity/architecture/component structuring
would be the right approach in part of the design.
There are some places where E/A structuring is dead-simply the right
thing. For example, an FPGA which requires N identical (or nearly
identical, modulo some generics) modules - DRAM controllers, gigabit
transceiver modules, register files, what have you. If an FPGA vendor
tells me they have a big honking hardware block that does function X
for me, for free, then the right thing is to plonk it down as a
component instance. No matter how elegant the academic theory behind
it might be, I'll never try to infer a Sonet controller similarly to
the way I infer a block RAM. (Even a dual-port RAM doesn't infer
right half the time - anyone who's done it will probably agree.) No
amount of procedural finessing can work around this.
But there are other places where the old-time hardware guy is missing
the boat by slavishly implementing every little piece of his design
using the explicit combinatorial logic and flops he sees in his head
as he considers what the schematic for his circuit ought to look
like. The CRC is a nice example - with the right procedures defined,
the circuit using the procedures is short, concise, understandable,
and easy to modify. The manually written mess of gates, or even the
inline instantiation of a separate CRC-32 engine can be much longer,
less obvious, and interrupt the "flow" of your description. These can
become critical things as the complexity of your design grows.
Both styles need to be written with the right amount of room to grow.
This is basic good design practice, and it's as much an art as a
science. Room to grow, and good engineering, encompasses using the
right parameterization (generics), the right default values, the right
use of procedural style and instantiation at the right layers, and the
right interfaces, among all of the other choices related to the
implementation of the design itself.
I've seen guys who implement every interface as a std_logic_vector,
that just grows, and grows, and grows, as needed. I've also seen their
code: it's an endless sea of meaningless code like
if (interface_a(16) and not interface_b(14)) then -- this means the
event triggered
interface_c(14) := '1'; -- so clear the reset
The use of records as a conduit (I like that analogy) is one good
technique to manage the OP's original problem. It has other VHDL-
imposed drawbacks though - there are all sorts of rules about
partially associated records in interfaces, resolved vs non-resolved
records types, multiple drivers, interface element modes, and so on.
It's like a poor-man's version of type polymorphism (not the same as
the parametric polymorphism when we talk about overloading
operators). It's type polymorphism because if your conduit just goes
between two levels, you can make it carry the right type by editing
your record definition in the package. It's poor-man's because there
no way of automatically inferring the type of the pipe -- if an entity
does nothing more than carry a unidirectional signal from the outer
ports to an inner component, why can't I just say "connect the two",
rather than spelling it all out, manually, over and over. This feature
(type polymorhism) is a nice feature in languages like Standard ML and
Haskell, which use well known and well understood mechanisms to make
this happen nicely. These solutions are also guaranteed to be type-
safe, which is the reason we have so much explicit type specification
in VHDL to begin with! Unfortunately, I can see this would be
difficult to implement with all of the extra quirks of the language
(port modes, multiple driver rules, resolution, etc, not to mention
possible interactions with conventional VHDL name resolution).
What does this all mean? VHDL is quirky, obviously "designed by
committee", and large. But it's also flexible, and you can generally
do most of what you need, once you get your head around it. At the end
of the day it's just a tool, and the tool is nothing better than the
person wielding it.
(Going off to the woodpile to get my axe... now THERE's a tool
- Kenn