Re: Hardware book like "Code Complete"?

But using lower level of abstraction (i.e., separating comb logic and
register) has its advantage. For example, if we want to add scan chain
(for testing) to a synchronous system after completing the design, we
can simply replace the regular D FFs with dual-input scan FFs in a
two-process code. This will be messy for one-process code.

Maybe I'm missing something but in the one process code you would add the
following...
if (Scan_Chain_Active = '1') then
-- Assign the clocked signals here per how it's needed for scan chain
else
-- Assign the clocked signals here per how the design needs it to
function
-- (i.e. this was what was here prior to adding scan)
end if;

I don't see that as any particular burden or how that would be any different
in the clocked process of the two process approach. It certainy isn't any
messier.

Another example is to use a meta-stabile hardened D FF for
synchronization.

Kinda lost me on what you mean or how the two process approach would
help have any advantage over the one process approach.

They even go to the
extreme to suggest that all memory elements should be separately
instantiated. This is may be one reason that "Reuse Methodology
Manual" I mentioned in an earlier message also recommends two-process
style.


And I think that is the crux of the debate between the 'one process' versus
'two process' camps, the 'two process' folks can't explicitly state any real
advantage to their approach even though they recognize real costs to doing
so....to be blunt, you're paying a price and getting nothing in return. In
this particular case, can you explain what benefit is received for
separately instantiating each memory element?

In reality, since either approach yields the exact same function and
performance the debate centers solely on productivity....which method, can
one be more productive with and why? Productivity is economoics and
measuring productivity means using currency ($$, Euros, etc) as your basis
for comparison. You can't really measure productivity without also bringing
up which tools are being used either since use of a 'better' tool may
involve being somewhat less efficient on one end with the overall goal that
the entire process is more efficient.

Comparing the two process approach to the one process the basic difference
is that you have several more lines of code to write:
- Declarations for the additional set of signals (i.e. the 'D' and 'Q'
instead of just the 'Q')
- Adding the 'default' values for each of the 'D' equations so as to not
create unintended latches.
- The 'Q <= D;' code in the second (i.e. clocked) process of the two process
approach.
- Process sensitivity list maintenance (in VHDL)

Now take design creation and debug as an activity to measure cost. For
every line of code written, one can assume that there is a certain
probability that it will be wrong. For a given designer using a given
language using a given coding technique one will likely tend to have some
particular error rate measured in errors per line of code. Since errors
need to be fixed at some point you incur some cost to doing so. If nothing
else, the two process approach encourages more lines of code and therefore a
higher probability of having an error than the one process approach so what
does the two process approach bring to the table that would lower the error
rate that might somehow offset the increased lines of code?

One can take other tasks like scan chain insertion as you did, or test
creation, life cycle support etc. whatever tasks you can think of and try to
compare costs of those tasks using the two approaches and go through the
same process to come up with a $$ measure for each task. Total up the tasks
and see which approach is better.

Now if someone in the two process camp can walk through a single task and
show how even that one task is more efficient (i.e. productive) than the one
process approach you might be able to start convincing readers until
then....well one can always dream.

KJ


.

Relevant Pages

  • Re: interpretive vs. compiled
    ... Usually the development costs are tiny compared ... Managers have different objectives than developers. ... even hope to be not in charge when the big maintenance costs come. ... of good design and development. ...
    (comp.programming)
  • Re: UL/ETL Choking the market
    ... As a lighting designer with a lot of experience outside the US market ... In most of the world, standards are written to require manufacturers, ... design freedom the least possible, with descriptive, performance based ... It costs construction clients enormously. ...
    (sci.engr.lighting)
  • Re: OOP/OOD Philosophy
    ... >> methodology could have avoided the headaches - all things being equal. ... System design methodologies generally do guarantee ... If it costs more than you have, ... >>>still need specific deliverables from the prototyping. ...
    (comp.object)
  • Re: [PATCH RT RFC v4 1/8] add generalized priority-inheritance interface
    ... but priority end the only applies to tasks. ... the number of sinks per node. ... readers to num_online_cpus) which this design would retain. ... not how long the resulting chain can grow. ...
    (Linux-Kernel)
  • Re: The video Carl Rogers doesnt want you to see...
    ... "Happiness and productivity, in my opinion, seem one in the same." ... "I could sure use a Jamba Juice right now. ... right region of my neck were stretched, and by morning, pain made it ... design, and the color layout is more friendly with the eyes:). ...
    (misc.transport.road)