C
Charles Moeller
Armin,
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.
Armin Steinhoff wrote:
> 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 ...
Yes. I can also define a language by the names of its operators and their corresponding logic element schematics in a library.
CharlieM wrote:
>> 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
Armin Steinhoff wrote:
> The translation is absolutely necessary for the synthesis of the FPGAs.
One of the options for design entry is <b> schematic capture</b> , described in a Xilinx CPLD document (see below).
I quote from http://www.xilinx.com/publications/products/cpld/cpld_applications_handbook.pdf:
“Schematic capture is the traditional method that designers have used to specify gate arrays and programmable logic devices. It is a graphical tool that allows you to specify the exact gates required and how you want them connected. There are four basic steps to using schematic capture:
1. After selecting a specific schematic capture tool and device library, begin building the circuit by loading the desired gates from the selected library. You can use any combination of gates that you need. You must choose a specific vendor and device family library at this time, but you don’t yet have to know what device within that family you will ultimately use with respect to package and speed.
2. Connect the gates together using nets or wires. You have complete control and can connect the gates in any configuration required by your application.
3. Add and label the input and output buffers. These will define the I/O package pins for the device.
4. Generate a netlist. A netlist is a text equivalent of the circuit. It is generated by design tools such as a schematic capture program. The netlist is a compact way for other programs to understand what gates are in the circuit, how they are connected, and the names of the I/O pins. ..."
Other options allow the designer to add new library logic elements by specifying the kind and interconnections of gates. It is this option that allows me to specify unique groupings of logic gates that perform or recognize the desired temporal characteristics fundamental to real time processes and embed those in the controller.
CharlieM wrote:
>> 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).
Armin Steinhoff wrote:
> It's now 2012 and there are FPGAs with millions of gates.
Most of which are not needed for the simple controllers I have been writing about. Why use more than the minimum that will guarantee function and safety? More gates and more software will only increase the risk of faults.
CharlieM wrote:
>> PTQ constructions behave more similar to a dataflow, than an algorithmic model,
Armin Steinhoff wrote:
> When I correctly understand ... PTQ defines also processes, but they are based on algorithm.
PTQ describes real time processes not based upon algorithms. PTQ uses a non-registered real time dataflow-type method.
CharlieM wrote:
>> although signals are typically not registered. PTQ has temporal logic elements with an inherent sense of time
Armin Steinhoff wrote:
> In the moment I don't see any temporal elements in PTQ. Do you have a formal definition of PTQ and its semantic?
The temporal logic in the DIR contactor controller that I described was specified by "(DO SEQ DC)." This means "the Sequence: Door Open, Door Closed" A specified sequence qualifies as an identifiable temporal characteristic or quality.
Best regards,
CharlieM
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.
Armin Steinhoff wrote:
> 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 ...
Yes. I can also define a language by the names of its operators and their corresponding logic element schematics in a library.
CharlieM wrote:
>> 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
Armin Steinhoff wrote:
> The translation is absolutely necessary for the synthesis of the FPGAs.
One of the options for design entry is <b> schematic capture</b> , described in a Xilinx CPLD document (see below).
I quote from http://www.xilinx.com/publications/products/cpld/cpld_applications_handbook.pdf:
“Schematic capture is the traditional method that designers have used to specify gate arrays and programmable logic devices. It is a graphical tool that allows you to specify the exact gates required and how you want them connected. There are four basic steps to using schematic capture:
1. After selecting a specific schematic capture tool and device library, begin building the circuit by loading the desired gates from the selected library. You can use any combination of gates that you need. You must choose a specific vendor and device family library at this time, but you don’t yet have to know what device within that family you will ultimately use with respect to package and speed.
2. Connect the gates together using nets or wires. You have complete control and can connect the gates in any configuration required by your application.
3. Add and label the input and output buffers. These will define the I/O package pins for the device.
4. Generate a netlist. A netlist is a text equivalent of the circuit. It is generated by design tools such as a schematic capture program. The netlist is a compact way for other programs to understand what gates are in the circuit, how they are connected, and the names of the I/O pins. ..."
Other options allow the designer to add new library logic elements by specifying the kind and interconnections of gates. It is this option that allows me to specify unique groupings of logic gates that perform or recognize the desired temporal characteristics fundamental to real time processes and embed those in the controller.
CharlieM wrote:
>> 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).
Armin Steinhoff wrote:
> It's now 2012 and there are FPGAs with millions of gates.
Most of which are not needed for the simple controllers I have been writing about. Why use more than the minimum that will guarantee function and safety? More gates and more software will only increase the risk of faults.
CharlieM wrote:
>> PTQ constructions behave more similar to a dataflow, than an algorithmic model,
Armin Steinhoff wrote:
> When I correctly understand ... PTQ defines also processes, but they are based on algorithm.
PTQ describes real time processes not based upon algorithms. PTQ uses a non-registered real time dataflow-type method.
CharlieM wrote:
>> although signals are typically not registered. PTQ has temporal logic elements with an inherent sense of time
Armin Steinhoff wrote:
> In the moment I don't see any temporal elements in PTQ. Do you have a formal definition of PTQ and its semantic?
The temporal logic in the DIR contactor controller that I described was specified by "(DO SEQ DC)." This means "the Sequence: Door Open, Door Closed" A specified sequence qualifies as an identifiable temporal characteristic or quality.
Best regards,
CharlieM