|
|
|
| Authored by: Anonymous on Wednesday, January 09 2013 @ 11:55 AM EST |
{me} NO The challenge was to disprove that ALL software is
abstract.
{RAS}Sorry... that was not the challenge. Let's re-iterate
the challenge from the original post:
{RAS}Point to a single
example of the physical existence of Software!
{RAS}You can try and
claim a rewording of the challenge all you want but the challenge is right there
for all to see. I never once said to disprove all software is
abstract.
YES. I accept your original challenge is
different to my rewording, which was different to your claim in the comment that
I was responding to.
{RAS} I said to provide a single
piece of evidence showing the physical embodiment of software. I did say that if
you couldn't point to a single physical embodiment of software, then you can not
prove software is anything but abstract. That's a logical conclusion drawn from
the fact that you fail to provide a single physical
embodiment.
But we appear to be in violent agreement on
the significance of a single case of a physical embodiment of a piece of
software.
The following is your agreed set of premises from my
argument, that I also agree with :).
You've stated the
following facts (my words) which are not in dispute:
CPU is
physical
FPGA is physical
I do NOT
agree with this premise from your list...
{RAS} HDL (hardware
description language) is abstract
The claim "HDL is abstract" is
pejorative of the topic under discussion. HDL definitions are frequently
concrete in that they define how to create a particular circuit.
It is
possible have an abstract HDL code fragment, in the same way that it is possible
to have an abstract english sentance. It is however not required that either
language be used to discuss abstract subjects.
Similarly I do
NOT agree with this premise from your list...
{RAS} HD
Language can be embodied in software
This statement creates
the impression that "HD Language" is under discussion and distinct from
software. Rather, what is under discussion is the "Hardware Description
Language" code that defines a particular CPU.
I said (adding only
code to the original post).
{me} HDL code is
software
The definition of HDL in Wikipedia clearly shows that HDLs
are just another sort of programming language; and hence HDL code discussed is
software.
I disagree with the following also...
{RAS}
And then you tied them together with a logical fallacy hinted at in your
words:
HDL can model the FPGA, this is a concrete process,
therefore HDL is physical
Why is it a logical fallacy? Just because you
can model the physical with the abstract, and the modeling is incredibly useful,
doesn't somehow turn the abstract into the physical.
Again
you introduce the pejorative term model where the more accurate term is
define.
Nobody designs a CPU with millions to billions of transistors by
hand. They are defined in HDL code. Various modelling steps are performed
to reduce the risk of manufacturing a vastly expensive non-functional platter of
ICs, but the creative work is done in the HDL software; in the same way that the
creative design work is done in software for modern computer
applications.
I stand by what I wrote earlier (again adding
code to the original).
{me}The HDL code fully defines
the CPU, and in combination with the design rules
appropriate for manufacturing
process which is sufficient to build an
ASIC
implementation.
I disagree with the following
also...
{RAS} An electrical engineer can draw the FPGA with pencil
and paper. They can even duplicate the pattern of expected behavior via numerous
abstract methods such as mental tracing of the diagram. That doesn't somehow
turn the picture and mental tracing into a physical FPGA
component.
Sorry, an electrical engineer does NOT design
the FPGA application on paper in any detail, as the details of the internal
structure of the FPGA are trade secrets; the engineer must typically use the
synthesis tool suite( HDL compiler ) that is supplied by the FPGA manufacturer
or their partner.
I would love to find out that I am wrong here, and
that FPGA structures are required to be disclosed, but I currently understand
they are not.
This I agree with in a strange way - that does not
support your argument at all
{RAS}They can even duplicate the
pattern of expected behavior via numerous abstract methods such as mental
tracing of the diagram. That doesn't somehow turn the picture and mental tracing
into a physical FPGA component.
I agree, paper analysis can not
make an FPGA application.
The real engineers define the desired
circuit in HDL and then synthesise the design (think compilation) and then
download the bit-stream to the FPGA. That is how an FPGA application is
made.
For ASIC chips, the situation is similar, after synthesis from
the HDL code, the mask images are constructed by software and printed before
they are used to make the physical chips.
{me}Synthesis of the
net-list for the physical construction is a repeatable and
reliable step;
similar to generating the numbers sent to a Computer Controlled
Machine in order
to build a physical component from a CAD design; in fact
similar to how
procedural software code is compiled and linked to form and
executable binary
for a general purpose CPU.
Note the software for the CPU can be
embodied purely in hardware in the ASIC implementation of the CPU.
Also
the software for the CPU can be embodied as a bitstream that can be modified
after it is deployed in the FPGA implementation of the CPU; or alternatively it
can be burnt into a PROM to reduce costs and perhaps reduce the risk of a FLASH
data error.
And the software for the CPU can be embodied in various
simulators ... physics simulators a proposed new manufacturing process, code
simulators for compiler writers before the CPU is shipped, external signal
simulators for testing larger system designs...
Sorry -
you've failed.
RAS
I disagree.[ Reply to This | Parent | # ]
|
|
|
|
|
