non-cents productions, LLC
This
page sports some selected documents (and excerpts) apropos to Digital
Signal Processing (DSP) technology.
They (like the other pages here) serve to give brief, illustrative
glimpses into a few of
the works of ncp.
Here is presented a Programmer's Reference
manual
for a custom programmable DSP we created for purposes of specific
wireless communications algorithm research.
One
of the goals in creating the instruction set of this DSP was to
minimise the effort required to translate the algorithms into source
code programs for the processor. The target algorithms were mostly
written in the "c" programming language (or often described
in
"pseudo-c").
Unfortunately, though the common "OPCODE OPERAND OPERAND" type of assembly code allowed for dense and optimised code, it often made the resulting translations cumbersome and un-obvious at best ... and at worst unclear and prone to errors.
Consider also, that the underlying machine architecture consisted of a 5 stage pipeline and 7 variant processor and addressing units (the astute/experienced will now realise that programming the machine was an exercise in keeping track of a 5x7 matrix of machine activities) so maximal similarity between source algorithms and processor code was very strongly desired. Hence, the machine instructions for this processor were made as c-like as possible.
Unfortunately, though the common "OPCODE OPERAND OPERAND" type of assembly code allowed for dense and optimised code, it often made the resulting translations cumbersome and un-obvious at best ... and at worst unclear and prone to errors.
Consider also, that the underlying machine architecture consisted of a 5 stage pipeline and 7 variant processor and addressing units (the astute/experienced will now realise that programming the machine was an exercise in keeping track of a 5x7 matrix of machine activities) so maximal similarity between source algorithms and processor code was very strongly desired. Hence, the machine instructions for this processor were made as c-like as possible.
Here
is part of a document detailing
the initial estimations of chip
resource characteristics for a direct/dedicated hardware implementation of a
specific algorithm.
Prior
to spending a million bucks or more to do a chip, it's a good idea to
do a sanity check on the approach: is the size ok, is the power
consumption ok, etc. -- and to ask "is there a better way than the
obvious approach?"
This excerpt shows an example optimisation. It is based upon use of a half-band filter rather than a pair of general filters. This simplification is made possible by understanding the details of the problem space and some special characteristics of the computations involved.
One will notice that a detailed explanation of the approach is provided along with the analysis in the document. That is because it is held that there are two important audiences for any design/system/hardware/software/etc. First, and foremost is "the user" (be that a person, a machine, whatever) of the design and all that is wanted by "the user" is that the design do what it should do. If it does not work, then clearly it is not much good. The second audience for any design is all too often forgotten: it's the poor schmuck that must maintain it and fix it as needed. These latter are deserving of, and thankful for, all the explanations and notes and hints that the designer can provide beyond just basic documentation.
This excerpt shows an example optimisation. It is based upon use of a half-band filter rather than a pair of general filters. This simplification is made possible by understanding the details of the problem space and some special characteristics of the computations involved.
One will notice that a detailed explanation of the approach is provided along with the analysis in the document. That is because it is held that there are two important audiences for any design/system/hardware/software/etc. First, and foremost is "the user" (be that a person, a machine, whatever) of the design and all that is wanted by "the user" is that the design do what it should do. If it does not work, then clearly it is not much good. The second audience for any design is all too often forgotten: it's the poor schmuck that must maintain it and fix it as needed. These latter are deserving of, and thankful for, all the explanations and notes and hints that the designer can provide beyond just basic documentation.