Point of View
I was caught of guard when someone commented:
"when a FIR filter is full of multiple loops and complex code, something is wrong"
The comment was made during an informal discussion on alternative hardware description languages (HDL) and was targeted to the straightforward FIR filter implemented in MyHDL:
(different FIR description simulation results)
Personally, (and obviously since I created the example) I think this is a very reasonable description because it is explicit, readable, and concise. Also note, the MyHDL description is not too different than a Verilog or VHDL description (but there key benefits that make it more concise and readable).
Another way to describe this using the "functional approach to hardware" description (2), such as:
Both these examples are based on the Python language and both use MyHDL to achieve simulation and conversion (converted to Verilog for synthesis). The first is considered the RTL/simulation (3) description and the second is considered a functional(ish) description. The functional description is achieved by creating objects of primitive hardware types and using Python's list comprehension to construct the flow graph (connect the primitives). Most functional based hardware description languages use a similar approach.
I don't know if this "functional" description is any good or not. I don't know of any good metrics to objectively evaluate the above. I am use to the RTL/simulation descriptions and I don't see any big short comings and the "functional" versions seem to take more effort to understand / read.
There is something to note here, the RTL vs. functional hardware descriptions are not the same as imperative programming vs. functional programming. The RTL/simulation is a mix of event-driven description and small imperative code blocks, these statements can be used to describe many concurrent micro threads
Both the above examples synthesize to the same number of resources. For the most part the descriptions in other languages (the functional based ones) also synthesize to the same utilization. For this limited example there is no implementation benefits.
(photo by Faiza Faria)
This effort is really an exercise in futility, it is trying to determine an efficient description for a bunch of different folks with different backgrounds and expectations. It is kind of like trying to get a room of people to agree on the meaning of a Jackson Pollock painting. For me, the first description is fine (better than fine) and I don't see a need for a different description or how the simple circuit can be described any simpler.
(1) The FIR filter (SOP) data-path is not the most interesting data-path example but it is common, brief, and sufficient. It has a nice balance between a simple description and a complex result (many resources that do something). Typically, this description is not one that would be used for synthesis.
>> ... a line between technical argument and "trolling"
A troll can have great technical banter but if it is off topic
to appease the troll or antagonize - it is trolling.
>> I disagree with the opening statement
This odd, I also disagree with the quote, hence the post.
But my take was an unembellished opinion on language
design vs. the example implementation.
>> drawing _general_ conclusions from a toy example.
I take issue with condescending "toy example" comment
but I agree that general conclusions from a simple
example should be avoided (repeatedly stated). From a
language perspective I think it is interesting, the different
constructs, something we do not share in common.
>> when a FIR filter is full of multiple loops and complex code, something is wrong"
that comment seems somewhat academic.
Take a USD 50 FPGA as an example, i.e. Spartan 6 LX 45. There are about 50 hardware multipliers (give or take some), so it seems unlikely that I can afford to synthesize every multiplication in parallel hardware. Or maybe I can, but then it will be a very expensive and power-hungry filter.
On ASICs this is somewhat easier: multipliers can be scaled with clock speed and coefficient width, constant coefficients enable heavy logic reduction. Sometimes you can just write "*" in Verilog and get away with it. But I'd say it's the exception, not the rule.
In general, I'd expect that a typical non-trivial FIR filter implementation is a lot more complex, i.e. a ring shift register for coefficients, or cyclic buffers in RAM.
being discussed and not the filter design. This post/conversation
does not give recommendations how to build an efficient FIR filter
for a certain set of requirements. It (the FIR filter description)
was simply used to discuss a hardware description.
Choosing the right example is always difficult and is why I often
call this a sum-of-products instead of a FIR filter.
Yes, I agree a higher order, typical filter, would be more complex,
and consist of many of the features you suggested. I think we can
reasonably extrapolate - if the straightforward description is
lacking (which I don't think it is) then the optimized filters
would be even more complex.
I don't know if I agree with "x * y" is the exception and not the
rule, my experience would suggest otherwise.
let me put this another way: The expectation that a FIR filter is simple in RTL seems academic to me.
Also academic, to argue the quality of the language over a toy example.
What I meant is, take the original comment with a grain of salt.
No one loves the established languages, but they have a proven track record for large-scale industrial projects, and that is one of the main arguments to use them: I can be certain they'll take me all the way.
>> I don't know if I agree with "x * y"
Now this isn't meant as a filter design discussion, but have a look at this example for a naive parallel implementation of the data path:
They end up using half of the FPGA for a simple audio equalizer, which is very inefficient. A real-world implementation could manage with maybe 1..10 % of the resources, but the code for even a simple filter will get much more complex when there are multiple pipelined samples "in flight" around a shared multiplier, for example.
with the areas you refer to in your comments. But I find
your comments annoying and borderline "trolling".
The intention of the post is simple: given a particular
example how well does the language describe it? Nothing
more and nothing less. This is very straightforward and
the majority of readers will not infer more from it. I
don't think it is constructive to drag this simple topic
into an all-encompassing survey.
I understand your stance, you don't think this is a
worthwhile talking point, but I disagree, hopefully we
can agree to disagree. Maybe an area of contention is the
expectation of a *blog* post. Blog posts straddle the
spectrum of written content, from ridiculously simple
opinions to long technical essays - you can guess which
this post is.
In summary, this post:
* takes a particular example and discusses the
description design and style for a given language.
* is a short and simple "opinion".
* is *not* a comprehensive evaluation of a language
* is *not* a recommendation on an efficient implementation
for the example (obviously) or an in-depth look into
It feels really odd having to explicitly state the above I
do not see how one would assume otherwise from this
I am sorry you see it this way.
But, I hope you draw a line between a technical argument and "trolling".
I disagree with the opening statement
>> "when a FIR filter is full of multiple loops and complex code, something is wrong"
I also disagree with drawing _general_ conclusions from a toy example.
I tried to make a point, constructively, why that is my opinion. My comments don't relate to the relevance of the topic as such.
To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.
Please login (on the right) if you already have an account on this platform.
Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: