After Software, What's Next?

C

Charles Moeller

Dick Caro and Vladimir E. Zyubin,

The concept of <b>order</b> has meaning in the space-domain. We order spaces and assign numbers to them on our measuring sticks, our memory cells, and the dials of our clocks. We can determine the direction and amount of progress by whether the numbers are increasing or decreasing, and by how much. Our program counters access instructions in predetermined orders, usually consecutive.

The concept of <b>order</b> also has meaning in the time-domain. Temporal order is the sequence of events. The order of events determines the character of the process and its results. If the order of events goes awry, the process fails. A useful measure of a process, therefore, is the correct sequence of process events. If we want to determine the temporal order of two signals marking events, A and B, we have several options:

In Turing-type systems, sequence-monitoring must be performed via translation from the time-domain to the space-domain. The signal from A is sampled, the signal from B is sampled. When A occurs, a time-stamp is recorded in a designated location and A-sampling is suspended. When B occurs, a time stamp for it is recorded in a different location and B-sampling is suspended. When both locations have time stamps, they are differenced. The sign of the difference is used to determine the order of events.

In PTQ systems, a logic operator and corresponding logic element directly determines the temporal order (sequence) of two events. The operator (A SEQ B) discriminates the order of inception of conditions A and B to signify when it is the case that A goes high first, then B goes high. The lasting condition (output high) continues in time until purposely reset (returned to a low condition). The operator (B SEQ A) discriminates the order of inception of conditions A and B to signify when it is the case that B goes high first, then A goes high. The lasting condition (output high) continues in time until purposely reset (returned to a low condition). The dynamic SEQ operator and its corresponding hardware logic elements have been configured to sense the order of inception of conditions in the continuous-time domain. No logic designed for static evaluation can accomplish that task in such a straight-forward manner. Indeed, if a TM-type system is required to determine the temporal order of the inception of diverse conditions, it must sample and time-stamp all input conditions, then perform arithmetic procedures on those time-stamps after-the-fact to determine the order in which it received the conditions.

Best regards,
CharlieM
 
P
This is a very interesting thread , and i just started following it. I am trying to figure out how this new paradigm will work, but i have a few queries and comments about it that i want to share and discuss. from what i saw this was the most interesting part

statement 1 - "A method of physical process automation is announced that can function without microprocessors, software, clocked state-machines, or register-transfer-level devices. This "natural" method directly senses and operates on the elemental signals intrinsically bound to the process. The temporal relationships of the process activities that generate the signals are defined and determined by the character and conduct of the process. In like manner, the temporal relationships between and among the signals so generated enable direct monitoring and control of the process. This method of automata is based upon the temporal relationships of the events and conditions of the process as described and managed by the operators and formalisms of PTQ."

so what it means that your method is able to produce a exact inverse of the plant dynamics?? (based on the fact that you said "This "natural" method directly senses and operates on the elemental signals intrinsically bound to the process. The temporal relationships of the process activities that generate the signals are defined and determined by the character and conduct of the process")

or does it mean that it uses a fuzzy like set for control?? This method of automata is based upon the temporal relationships of the events and conditions of the process as described and managed by the operators and formalisms of PTQ.

i am confused between the two above statements what does it do, replicate and inverses the plant dynamics or just uses temporal relations like "if this do that" like fuzzy sets, or uses both??

Here is an example of what i understand

Let the plant dynamics (as you say elemental signals intrinsically bound to the process) can be represented by the state nonlinear equation

X(dot) = F(x) + B(x)*U

where X are the states of the system (can be any no), F(x) and B(x) represents the model (nature) of the system

does your automata give a control output such that U = Inverse(B(x)) ( -F(x) - Kx )? ie it can perfectly predict or approximate F(x) and B(x) such that when you apply this control signal to the system you will get

X(dot) = -Kx , a linear and stable system , with perfect tracking and rate of response dependent only on the set gain K??

statement 2 - "This new automation technology operates from DC to light-speed, has parallel-concurrent functionality, does not rely upon run-time software and is real-time and continuous-time as well as frame-freeze, and is both synchronous and asynchronous. It is safer, faster, and simpler, and costs much less to design, implement, and maintain time-, safety-, and mission-critical process-control systems (than computer- and microprocessor-based designs)."

when you say it operated from DC to light speed, do you mean that there is no time delay between measurement (estimation) and control?? is this possible even? Though this may sound desirable, in my humble opinion it may not be a good control option. how can disturbance be rejection be done if this is the case?

i apologise if my questions seem a little bit overboard. i am really curious to know how this automation control is implemented. as you say it has no processor based design, no software (the only option i see is a hardware which can emulate the inverse of the process dynamics)?? are you writing any paper in this regard ?? if you have already written i would really like to read it.
 
> First, there are, and have been for decades, microcontrollers that can
> present summed values in very short time intervals. So, while having an
> unclocked 16 bit adder might seem all new and clever, they aren't, and they
> aren't going to solve any of the problems that are being discussed.

This may be the first rationale posting on this thread. Thank you Julie. I too have managed programmers. In my experience, there can be more than 100 times the performance of an excellent programmer over a good programmer. No other profession has this gap in performance. There can also be a great difference between programmers who produce maintainable code, and those who produce write-only code that must be done over rather than maintained. The excellent programmers who worked for me produced maintainable code as well as completing assigned tasks rapidly. Maybe, this was their secret to productivity.

To me the problem was always to "do the right thing" more than "doing things right." Rather than to complete a program that maybe solved a problem, but doing it in record time is not the goal. The goal is FIRST careful definition of the problem to be solved, then to make sure the program did that. I always have insisted that the programmer document the program he/she was assigned BEFORE writing the first line of code. We carefully reviewed this USER MANUAL before the code was started to be sure that it was the right problem/application.

How the problem/application is solved (hardware or software) is irrelevant as long as the definition is correct. Personally, I cannot imagine solving process control problems/applications in pure hardware, but I am open to new solutions. However, do not blame software for all of the ills of digital systems. The solutions are management issues.

Dick Caro

Richard H. Caro, CEO, CMC Associates
Certified Automation Professional (ISA)
Buy my books at the ISA Bookstore:
Wireless Networks for Industrial Automation
Automation Network Selection
Consumers Guide to Fieldbus Network Equipment for Process Control
===============================================================
 
V

Vladimir E. Zyubin

Dick Caro wrote:
> To me the problem was always to "do the right thing" more than "doing things right." Rather than to complete a
> program that maybe solved a problem, but doing it in record time is not the goal. The goal is FIRST careful definition of
> the problem to be solved, then to make sure the program did that. I always have insisted that the programmer document
> the program he/she was assigned BEFORE writing the first line of code. We carefully reviewed this USER MANUAL
> before the code was started to be sure that it was the right problem/application.

Mostly agree, but the key goal is to reflect the algorithm, that is already "presented" in object under control, in a structural corresponding description. It provides readability, maintainability, local effects of corrections, etc. The algorithm is in head of the designer of the object.
 
V

Vladimir E. Zyubin

CharlieM wrote:

> The concept of <b> order</b> has meaning in the space-domain. We order spaces and assign numbers to them on our measuring
> sticks, our memory cells, and the dials of our clocks. We can determine the direction and amount of progress by
> whether the numbers are increasing or decreasing, and by how much. Our program counters access instructions in
> predetermined orders, usually consecutive.

According to my experience the order problem is not a problem at all. Would you like to provide an example from the control algorithm domain?

BTW, I have just read the article [1]. Alas, such an academic paper looks like scholastic exercises produced by people that never seen any control task. OK, I like fig. 4, mostly because it looks like borrowed from one of articles on process-oriented programming :)

best, Vladimir

1. Organizing the Aggregate: Languages for Spatial Computing
Jacob Beal (Raytheon BBN Technologies, USA),
Stefan Dulman (Delft Univ., the Netherlands),
Kyle Usbeck (Raytheon BBN Technologies, USA),
Mirko Viroli (Univ. Bologna, Italy),
Nikolaus Correll (Univ. Colorado Boulder, USA)

http://arxiv.org/pdf/1202.5509v1.pdf
 
C

Charles Moeller

Process Value,

I made a couple of statements:

> A method of physical process automation is announced that can function without microprocessors,
> software, clocked state-machines, or register-transfer-level devices. This "natural" method directly senses and
> operates on the elemental signals intrinsically bound to the process. The temporal relationships of the process
> activities that generate the signals are defined and determined by the character and conduct of the process. In like
> manner, the temporal relationships between and among the signals so generated enable direct monitoring and
> control of the process. This method of automata is based upon the temporal relationships of the events and
> conditions of the process as described and managed by the operators and formalisms of PTQ."


and

> This new automation technology operates from DC to light-speed, has parallel-concurrent
> functionality, does not rely upon run-time software and is real-time and continuous-time as well as frame-freeze,
> and is both synchronous and asynchronous. It is safer, faster, and simpler, and costs much less to design,
> implement, and maintain time-, safety-, and mission-critical process-control systems (than computer- and
> microprocessor-based designs).

In explanation, let us examine a simple control function, such as the direction (DIR) controller for an elevator.

The safety and operational constraints for a direction controller for a two-floor elevator is stated:

“The direction contactor (DIR) can change only when at a floor while the lift motor is off and after the door has opened and closed and the alternate floor has been requested. The alternate floor request is assessed after the constraints have been fulfilled.”

Stated in PTQ English:
At Floor 1 AND Lift Motor OFF AND Door Open SEQ Closed CREATES Door Cycle Complete WHILE DCC AND Floor 2 Requested CREATES DIR WHILE At Floor 2 AND Lift Motor OFF AND Door Open SEQ Closed CREATES Door Cycle Complete WHILE DCC AND Floor 1 Requested CREATES /DIR WHILE LM Resets DCC WHILE [(LM AND DIR) = UP] WHILE [(LM AND /DIR) = DN]

Condensed:
{[FL1 * /LM * (DO SEQ DC)] # DCC} [(DCC * FL2Req) # DIR] [(DIR * LM) = UP] {[FL2 * /LM * (DO SEQ DC)] # DCC} [(DCC * FL1Req) # /DIR] [(/DIR * LM) = DN]

The real-time logic of this part of an elevator controller can be stated in one continuous line of PTQ parallel-concurrent “source code” and implemented in functional hardware having seven inputs and one output in a configuration of less than 50 equivalent gates. This controller operates at the speed of the process and with a latency of only six gate-delays in the directly-connected logic (in whatever device technology used). Temporal discrimination is less than one gate-delay.

Q: How many lines of linear-sequential code and equivalent gates would be used in a TM-type controller?

Best regards,
CharlieM
 
V

Vladimir E. Zyubin

CharlieM wrote:

> Stated in PTQ English:
> At Floor 1 AND Lift Motor OFF AND Door Open SEQ Closed CREATES Door Cycle
> Complete WHILE DCC AND Floor 2 Requested CREATES DIR WHILE At Floor 2 AND Lift
> Motor OFF AND Door Open SEQ Closed CREATES Door Cycle Complete WHILE DCC
> AND Floor 1 Requested CREATES /DIR WHILE LM Resets DCC WHILE [(LM AND DIR) = UP]
> WHILE [(LM AND /DIR) = DN]

It seems, it is too long to be acceptable for the short-term memory. In practice we use points, and semicolons, and commas to divide any complex information to sentences. Just a psychology limit. Programming is mostly psychology, humans write programs for humans only. :) From the languages we need ability to structurize info, ability to hierarchicalize info, ability to metaphorize info, ability to isolate one part from other. So, I have my doubts that the elevator designer thinks according to the formula.

And elevator is too complex object. What about other challenge -- a washroom hand dryers? Just one input (hand sensor) and one output (phene control). The solution assumes a bit of temporal logic because of unstable hands position that leads to sensor jitter.
 
Charles,

You are either a genius or a crackpot - with the words you have written, I cannot tell which. If you have a user manual, I would certainly enjoy reading it. How can I get a copy.

Dick Caro
Richard H. Caro, CEO, CMC Associates
Certified Automation Professional (ISA)
Buy my books at the ISA Bookstore:
Wireless Networks for Industrial Automation
Automation Network Selection
Consumers Guide to Fieldbus Network Equipment for Process Control
===============================================================
 
C

Charles Moeller

Vladimir,

CharlieM wrote:

>> Stated in PTQ English:
>> At Floor 1 AND Lift Motor OFF AND
>Door Open SEQ Closed CREATES Door Cycle
>> Complete WHILE DCC AND Floor 2
>Requested CREATES DIR WHILE At Floor 2
>AND Lift

---- snip ----

Vladimir Zyubin wrote:
> It seems, it is too long to be acceptable for the short-term memory. In practice we use points, and semicolons,
> and commas to divide any complex information to sentences. Just a psychology limit.

---- snip ----

Sorry my language doesn’t meet your approval. You must keep in mind that PTQ is primarily a dynamic logic and language, rather than a (static) linear-sequential one, so it may appear somewhat strange, at first.

The punctuation in PTQ resides in the temporal operators, in the case given: WHILE, which can be implied. For example:

“At Floor 1 AND Lift Motor OFF AND Door Open SEQ Closed CREATES Door Cycle Complete” is one complete thought and activity.

> And elevator is too complex object.

I selected the elevator example as one having several safety concerns and constraints, but to keep it simple, only treated the DIR part of the whole controller.

Best regards,
CharlieM
 
C

Charles Moeller

Dick,

You wrote:
> You are either a genius or a crackpot - with the words you have written, I
> cannot tell which. If you have a user manual, I would certainly enjoy reading
> it. How can I get a copy.

I'll take that as a compliment after my 50 years of experience with controls, the last 40 as an engineer.

I do have a user manual and now working on other books plus patents. If I take the step of giving anyone a look, it would take a very strong NDA/NUA and include plans toward eventual commercialization.

Best regards,
CharlieM
 
There has been too much mystery and outrageous claims in this thread. As near as I can tell, if your application can be solved with Boolean state logic and it is not beyond the capacity of a field programmable gate array, then Mr. Moeller's configuration/programming software called PTQ can be used to program the gate array. From that point on, once the Inputs and Outputs are connected to the FPGA, the system works in real time. There is nothing really new here except perhaps Mr. Moeller's programming software.

You are welcome to correct my impression.

Dick Caro

Richard H. Caro, CEO, CMC Associates
Certified Automation Professional (ISA)
Buy my books at the ISA Bookstore:
Wireless Networks for Industrial Automation
Automation Network Selection
Consumers Guide to Fieldbus Network Equipment for Process Control
===============================================================
 
C

Charles Moeller

Dick Caro wrote:

> As near as I can tell, if your application can be solved with Boolean state logic
> and it is not beyond the capacity of a field programmable gate array, then Mr.
> Moeller's configuration/programming software called PTQ can be used to
> program the gate array. From that point on, once the Inputs and Outputs are
> connected to the FPGA, the system works in real time. There is nothing really
> new here except perhaps Mr. Moeller's programming software.

Dick urges that the rest of you folks just move along as there is nothing extraordinary to see here.

I will remain ready to answer questions from any individuals that have a continuing interest in my work on temporal logic.

BTW, I do not have any "programming software," at present. All my temporal logic designs are "hand-crafted" schematics composed by following the process specification and selecting the corresponding blocks from my proprietary library of special (and standard) logic elements. The resulting hardware configuration mirrors and monitors and controls the process in real time.

Best regards,
CharlieM
 
V

Vladimir E. Zyubin

CharlieM wrote:
>>> Stated in PTQ English: At Floor 1 AND Lift Motor OFF AND Door Open SEQ Closed CREATES Door Cycle
>>> Complete WHILE DCC AND Floor 2 Requested CREATES DIR WHILE At Floor 2 AND Lift

Vladimir Zyubin wrote:
>> It seems, it is too long to be acceptable for the short-term memory.

CharlieM wrote:
>Sorry my language doesn’t meet your approval. You must keep in mind that PTQ is primarily a dynamic logic and
>language, rather than a (static) linear-sequential one, so it may appear somewhat strange, at first.

I am sorry, it is not my approval. It is a restriction from the software psychology. Have a look at Ben Shneiderman's "Software Psychology: Human Factors in Computer and Information Systems", Little, Brown and Co. 1980 (sic!).

I do not know, could the language grammatics be transformed in the acceptable form or not, but it have to be done if it is intended to be used by a human being.

BTW, It seems to me, after the "Door Cycle Complete" event has appeared, I (as a passenger) cannot open door again at the same floor. Is it correct? Or I can, but the mechanism also can begin to move (to make a cutlet from me :)

best regards, Vladimir
 
[ clip]
CharlieM wrote:
> In explanation, let us examine a simple control function, such as the direction (DIR) controller for an elevator.

> The safety and operational constraints for a direction controller for a two-floor elevator is stated:

> “The direction contactor (DIR) can change only when at a floor while the lift motor is off and after the door has opened and closed and the alternate floor has been requested. The alternate floor request is assessed after the constraints have been fulfilled.”

Is DIR a direction controller or a direction contactor ?

> Stated in PTQ English:
> At Floor 1 AND Lift Motor OFF AND Door Open SEQ Closed CREATES Door Cycle Complete WHILE DCC AND Floor 2 Requested CREATES DIR WHILE At Floor 2 AND Lift Motor OFF AND Door Open SEQ Closed CREATES Door Cycle Complete WHILE DCC AND Floor 1 Requested CREATES /DIR WHILE LM Resets DCC WHILE [(LM AND DIR) = UP] WHILE [(LM AND /DIR) = DN]

> Condensed:
> {[FL1 * /LM * (DO SEQ DC)] # DCC} [(DCC * FL2Req) # DIR] [(DIR * LM) = UP] {[FL2 * /LM * (DO SEQ DC)] # DCC} [(DCC * FL1Req) # /DIR] [(/DIR * LM) = DN]

This looks likes cryptified function block display or a sequence of macros ... it's un-readable like a "Lisp" program. Writing such a small application in one line is not an innovation :)

> The real-time logic of this part of an elevator controller can be stated in one continuous line of PTQ parallel-concurrent “source code” and implemented in functional hardware having seven inputs and one output in a configuration of less than 50 equivalent gates.

I would code it directly in VHDL ...

> This controller operates at the speed of the process and with a latency of only six gate-delays in the directly-connected logic (in whatever device technology used). Temporal discrimination is less than one gate-delay.

> Q: How many lines of linear-sequential code and equivalent gates would be used in a TM-type controller?

It would take one single line containing one expression of a macro call :)

Best Regards
Armin Steinhoff
 
C

Charles Moeller

Vladimir:

CharlieM wrote:
>> Sorry my language doesn’t meet your approval. You must keep in mind that PTQ is primarily a dynamic logic and
>> language, rather than a (static) linear-sequential one, so it may appear somewhat strange, at first.

Vladimir Zyubin wrote:
> I am sorry, it is not my approval. It is a restriction from the software psychology. Have a look at Ben
> Shneiderman's "Software Psychology: Human Factors in Computer and Information Systems", Little, Brown and Co. 1980 (sic!).

You misunderstand. PTQ is not software. It is a means of converting functional specifications, including safety and operations, to real time hardware that performs immediately according to the specifications.

> BTW, It seems to me, after the "Door Cycle Complete" event has appeared, I (as a passenger) cannot open door again
> at the same floor. Is it correct?

Not correct. This issue is treated in the autonomous door motor section of the elevator control system.

> Or I can, but the mechanism also can begin to move (to make a cutlet from me :)

There are major safety constraints for the operation of the door motor, the direction contactor, and the lift motor. I have shown only the cycles of activities and constraints for the operation of the direction contactor.

As previously stated, direction can't change unless the lift motor is not running and unless the door cycle is complete (with the door closed).

Best regards,
CharlieM
 
V

Vladimir E. Zyubin

Charlie:

CharlieM wrote:
>>> Sorry my language doesn’t meet your approval. You must keep in mind that PTQ is primarily a dynamic logic and
>>> language, rather than a (static) linear-sequential one, so it may appear somewhat strange, at first.

Vladimir Zyubin wrote:
>> I am sorry, it is not my approval. It is a restriction from the software psychology. Have a look at Ben
>> Shneiderman's "Software Psychology: Human Factors in Computer and Information Systems", Little, Brown and Co. 1980 (sic!).

CharlieM wrote:
> You misunderstand. PTQ is not software. It is a means of converting functional specifications, including safety and
> operations, to real time hardware that performs immediately according to the specifications.

I do understand that PTQ is not a software. Also I understand that the PTQ formalism is just a formal language intended to specify a control algorithm.

And please do not concentrate your attention on the word "software", please pay attention to the word "psychology".

Vladimir wrote:
>> BTW, It seems to me, after the "Door Cycle Complete" event has appeared, I (as a passenger) cannot open door again
>> at the same floor. Is it correct?

CharlieM wrote:
> Not correct. This issue is treated in the autonomous door motor section of the elevator control system.

I suspect the parallelism you mention as a advantage will play (sometimes) a malicious joke in the case. It will lead to transformation passenger to forcemeat.

Vladimir wrote:
>> Or I can, but the mechanism also can begin to move (to make a cutlet from me :)

CharlieM wrote:
> There are major safety constraints for the operation of the door motor, the direction contactor, and the lift motor.
> I have shown only the cycles of activities and constraints for the operation of the direction contactor.

> As previously stated, direction can't change unless the lift motor is not running and unless the door cycle is
> complete (with the door closed).

Which way can I verify safety of the algorithm descripted by means of PTQ formalism? As I write previously I suspect the PTQ formalism (with a parallel implementation) will lead to possibility the following parallel operations:
- lift motor running;
- door opening.

best regards, Vladimir
 
C

Charles Moeller

Vladimir,

CharlieM wrote:
>> You misunderstand. PTQ is not software. It is a means of converting functional specifications, including safety and
>> operations, to real time hardware that performs immediately according to the specifications.

Vladimir Zyubin wrote:
> I do understand that PTQ is not a software. Also I understand that the PTQ formalism is just a formal language
> intended to specify a control algorithm.

No. PTQ does not lead to an “algorithm,” which is (from Webster’s): "a procedure for solving a mathematical problem (as of finding the greatest common divisor) in a finite number of steps that frequently involves repetition of an operation; broadly: a step-by-step procedure for solving a problem or accomplishing some end especially by a computer."

PTQ replaces linear-sequential algorithms with reactive circuits that are real-time and parallel-concurrent and which respond immediately rather than after fetch and decode, search and match, instruction, clock, interrupt, or executive loop times.

> And please do not concentrate your attention on the word "software", please pay attention to the word "psychology".

I prefer not to leave considerations of safety up to "psychology." The best way to ensure safety is to use hardware lockouts, which are simple hardware interlocks (if this, not that).

Safety constraint 1. Door is prevented from opening if not at a floor or while lift motor is running.

This constraint is satisfied in my elevator system by also preventing power to the door motor at any time that power is applied to the lift motor. This is a physical safety interlock, not a software, mental or psychological safeguard.

Safety constraint 2. Lift motor direction is not allowed to change while lift motor is running.

This constraint in my elevator system is satisfied by preventing change in the operating condition of the direction contactor while power is being applied to the lift motor. This is also a physical safety interlock, not a software, mental or psychological safeguard.

Safety constraint 3. Lift motor is prevented from running while door is not closed.

This constraint in my elevator system is satisfied by preventing power from being applied to the lift motor unless the door is closed. This is also a physical safety interlock, not a software, mental, or psychological safeguard.

> I suspect the parallelism you mention as a advantage will play (sometimes) a malicious joke in the case. It will lead
> to transformation passenger to forcemeat.

Not true. See above safety constraints.

> Which way can I verify safety of the algorithm descripted by means of PTQ formalism?

By the specifications and by inspection and checking that the hardware is implemented according to the specifications, exactly.

> As I write previously I suspect the PTQ formalism (with a parallel implementation) will lead to
> possibility the following parallel operations:
> - lift motor running;
> - door opening.

The physical interlocks specified and implemented to meet the safety constraints prevent your feared conjunction in two ways. If it were left to software, I would be very afraid. In this case, it is hardware interlocks, implemented by:

Constraint 1. Door is prevented from opening if lift motor is running (if the elevator is moving power is not available to open door), and

Constraint 3. Lift motor is prevented from running if door is not closed (power is removed from lift motor if door opens).

In both cases, door open and elevator moving can’t take place at the same time. Your concerns are without basis.

Best regards,
CharlieM
 
[ clip]
Vladimir Zyubin wrote:
>> I do understand that PTQ is not a software. Also I understand that the PTQ formalism is just a formal language
>> intended to specify a control algorithm.

CharlieM wrote:
> No. PTQ does not lead to an “algorithm,”

PTQ is a declarative "language" (?) which specifies in general an algorithm in order to control something! This specification includes also the creation of modules and parallel threads or processes.

The implementation could be done with programmable hardware if the spec is compilable to VHDL, e.g.

Best Regards
Armin Steinhoff
 
C

Charles Moeller

Armin,

[ clip]
Vladimir Zyubin wrote:
>>> I do understand that PTQ is not a software. Also I understand that the PTQ formalism is just a formal language
>>> intended to specify a control algorithm.

>CharlieM wrote:
>> No. PTQ does not lead to an
>“algorithm,”

Armin Steinhoff wrote
> PTQ is a declarative "language" (?) which specifies in general an algorithm in order to control something! This
> specification includes also the creation of modules and parallel threads or processes.

PTQ is not a computer language. It is a behavioral description language that may be directly implemented in hardware as a configuration of logic gates.

One writes the physical process description (to be monitored and controlled) as accurately as possible using the operators available in PTQ. The process statement so created is the schematic and architecture of the resulting hardware logic element configuration.

So we have process specification-to-hardware controller (via schematic entry) in one step.

Armin Steinhoff wrote
> The implementation could be done with programmable hardware if the spec is compliable to VHDL, e.g.

PTQ descriptions can be translated into VHDL or stated in VHDL, but that is (usually) an unneeded complication because the PTQ logic element library fully defines the structure (in schematic form) of each of the roster of operators and corresponding hardware logic elements from which the designer can choose. Individual characteristics of each logic element (gate delay, output drive, etc.) will have values typical of the device generation being used (e.g., pz5032cs6a44, a Xilinx CPLD that was available in the year 2000).

PTQ constructions behave more similar to a dataflow, than an algorithmic model, although signals are typically not registered. PTQ has temporal logic elements with an inherent sense of time rather than being dependent upon a TM and software to tell it the time.

Best regards,
CharlieM
 
[ clip]
Armin Steinhoff wrote
>> PTQ is a declarative "language" (?) which specifies in general an algorithm in order to control something! This
>> specification includes also the creation of modules and parallel threads or processes.

CharlieM wrote:
> PTQ is not a computer language. It is a behavioral description language that may be directly implemented in hardware as a configuration of logic gates.

PTQ is a language directly implemented in hardware? How can you implement a language in such way ?
I can define a language by a formal syntax and semantic ...

> One writes the physical process description (to be monitored and controlled) as accurately as possible using the operators available in PTQ.

A process description as set of Lego Mindstorm modules ?? How ever, your statements are very confusing.

> The process statement so created is the schematic and architecture of the resulting hardware logic element configuration.

> So we have process specification-to-hardware controller (via schematic entry) in one step.

Armin Steinhoff wrote
>> The implementation could be done with programmable hardware if the spec is compliable to VHDL, e.g.
> PTQ descriptions can be translated into VHDL or stated in VHDL, but that is (usually) an unneeded complication

The translation is absolutely necessary for the synthesis of the FPGAs.

> because the PTQ logic element library fully defines the structure (in schematic form) of each of the roster of operators and corresponding hardware logic elements from which the designer can choose. Individual characteristics of each logic element (gate delay, output drive, etc.) will have values typical of the device generation being used (e.g., pz5032cs6a44, a Xilinx CPLD that was available in the year 2000).

It's now 2012 and there are FPGAs with millions of gates.

> PTQ constructions behave more similar to a dataflow, than an algorithmic model,

When I correctly understand ... PTQ defines also processes, but they are based on algorithm.

> although signals are typically not registered. PTQ has temporal logic elements with an inherent sense of time

In the moment I don't see any temporal elements in PTQ. Do you have a formal definition of PTQ and its semantic?

That are my last 2 cents ...

Best Regards
Armin Steinhoff
 
Top