I have the following predicates that models a PC. What I want is to print all pc compoments and sub-compoments.
I want to do something like this
find_set_of_attributes(X):-
print(X)
print(X[power)
print(X[power][usb])
pc([power).
power([usb, voltageregulator]).
usb([container, usbhead, pins]).
voltageregulator([barreljack, capacitor, regulator, leds]).
One way to describe the computer components and sub-components is to use Definite Clause Grammars (DCGs). For example:
computer --> monitor, cpu, keyboard, mouse.
...
power --> usb, voltageregulator.
usb --> container, usbhead, pins.
voltageregulator --> barreljack, capacitor, regulator, leds.
Components without sub-components can be defined as:
capacitor --> [capacitor].
leds --> [leds].
To list all the parts (e.g for printing), you can then simply use the de facto standard phrase/2 predicate. For example:
| ?- phrase(computer, Parts).
Related
I'm trying to draw an event-sourcing decider with mermaid.js from something I've seen in a YT video: https://youtu.be/kgYGMVDHQHs?t=1572.
My attempt so far:
graph LR
Command(Command) --> Decide[[Decide]]
Decide --> Events(NewEvents)
Events --> Evolve[[Evolve]]
PreviousState(Previous State) --> Evolve[[Evolve]]
Evolve --> State(New or Initial State)
State --> PreviousState
State --> Decide
Also available on mermaid.live
Which gives something like below:
It looks really clunky, I'm wondering how the different elements can be better positioned to look more like the first picture?
The video mentioned loop several times, perhaps the plot can be designed like this?
Try this sample code in Mermaid Live Editor:
graph LR
Command --> Decide
Evolve --> Event
subgraph A[loop]
direction LR
Evolve --> |New or Initial State|Decide
Decide --> |New events|Evolve
end
I am attempting to create a PID controller for an air hose and valve system. The system consists of an Omega FC-22 flow computer, a motorized valve, and a down stream sensor to measure cubic feet per minute (CFM). The control loop goes as follows: user punches in desired CFM -> valve turns until flow computer = desired CFM -> valve corrects itself when desired CFM exceeds +/- 1 (or so) CFM. The upstream airflow is not part of the control loop, once it is on, the valve is used to regulate it.
I understand how PID controllers work in Simulink, but am not sure how to go from a transfer function and PID controller to the scenario above. Also, another issue I face is figuring out how to interface the Omega FC-22 with Simulink, which is a critical portion. Any and all help is appreciated.
**I have attached the user guide for the Omega FC-22
https://www.omega.com/manuals/manualpdf/M2572.pdf
You'll have to make Simulink write the CV of the PID to the valve. Typically this is done via a 4-20mA signal from the controller (pc in your case). You'll probably have to see what types of input signals your valve supports and wire accordingly.
The PV of the PID will come from the flow computer's Modbus RS-485 interface. The manual didn't show a ModbusTCP or RS-232 option. You'll have to use an RS-232/RS-485 or a USB/RS-485 adapter. Then read in the appropriate flow from the modbus registers listed in Appendix C of the Omega manual.
The set point of the PID should be easy enough. Just have a way for the user to enter it on the pc and send that value to your Simulink code.
Using Qsys (Quartus II x64 15.0.1 build 150) I made a system with Nios2/e and several standard peripheral components. I also add my custom component with 1 MM-Slave and 2 Interrupt Senders. For each of them I set this slave as "Associated addressable interface" in Component editor during creation of _hw.tcl file.
Qsys reports no errors or warnings, but then I tried to make BSP project in Eclipse using New | Nios 2 BSP project wizard. I select "SOPC Information File name", but "CPU" ComboBox remains empty and error appears: "No Nios II CPU Found".
Then I launch BSP Editor from main menu: Nios 2 | BSP Editor and press File | New Nios 2 BSP. I again provide SOPC file and this tool found CPU, but also reports the error: "Can only have at most one IRQ associated with the following slaves of module "my_component" : mm_slave."
I then returned to Qsys and remove one of Interrupt Senders and this time everything works fine, but I need to generate more than one interrupt.
So what to do if you have Nios2/e connected to custom peripheral with 1 MM-Slave and several Interrupt Senders?
I have some ideas but don't like them:
Add MM-Slave for each irq (it looks like waste of resources).
Do not specify "Associated addressable interface" in Component editor (it is by the way works, but I don't know will it work properly all the time). What this option really do?
I was imprecise saying that it will work, sorry for that. In reality qsys and BSP can be generated but inside BSP's system.h IRQ number will be defined as -1, so it will not work.
Merge all interrupts into one wire (they all will share the same priority).
Configure Interrupt Sender to have irq signal with width more than 1 (Component Editors allows to do this but reports warning: "interrupt_sender: Signal irq_many[4] of type irq must have width [1]".) As with case 2 I don't know what will happen inside Altera's generators/compilers.
After Component Editor stage is finished Qsys doesn't accept such a system.
Please help.
At last, I have found the following:
A. If you need many IRQ Senders inside one custom Qsys module you need one MM-Slave per each. From GUI organization it seems that you are assigning MM-Slave to the IRQ, but (as far as I understand it) it works directly opposite: IRQ is tied to MM-Slave and it may has maximum one IRQ. I didn't try to actually run it, but BSP files looks correct and everything compiles at least.
I hope, that there is (or will be) a better way to achieve this.
B. If you can share the same priority between all interrupts, than you can avoid the problem by using only 1 Interrupt Sender and thus only 1 MM-Slave. It works on dev board.
Hello this will be an experts questions :) You should be familiar with the following topics
Xilinx Multi-Gigabit-Transceivers (MGTs), especially the 7-Series GTX/GTH transceivers (GTXE2_CHANNEL)
Serial-ATA Gen1, Gen2 and Gen3, especially Out-of-Band (OOB) communication
Question:
How should a GTXE2 be configured for Serial-ATA?
OOB signaling is not working neither RX_ElectricalIdle nor ComInit.
Introduction:
I implemented a SATA controller for my final bachelor project, which supports multiple vendor/device platforms (Xilinx Virtex-5, Altera Stratix II, Altera Stratix IV). Now it's time to port this controller to the next device family: Xilinx 7-Series devices, by name a Kintex-7 on a KC705 board.
The SATA controller has a additional abstraction layer in the physical layer, which is based on SAPIS and PIPE 3.0. So to port the SATA controller to a new device family, I have only to write a new transceiver wrapper for a GTXE2 MGT.
As of Xilinx's CoreGenerator doesn't support the SATA protocols in the CoreGen wizard, I started a transceiver project from scratch and applied all necessary settings as far as they are asked by the wizard. After that I copied the GTXE2_COMMON instantiation into my wrapper module, ordered the generics and ports into a meaning full schema.
As a third step I connected all unconnected ports (the wizards doesn't assign all values !!) to their default values (the default from UG476 or zero if not defined).
In step 4 I checked all generics and ports again against the UG476 if they are compatible to the SATA settings. After that I connected my wrapper ports to the MGT and inserted cross-clock modules if necessary.
As of the KC705 board has no 150 MHz reference clock, I program the Si570 to supply this clock as "ProgUser_Clock" after each board "bootup". The MGT is in powerdown mode (P2) while this reconfiguration. When the Si570 is stable, the MGT is powered up, the used Channel PLL (CPLL) locks after ca. 6180 clock cycles. This CPLL_Locked events releases the GTX_TX|RX_Reset wires, which cause a GTX_TX|RX_ResetDone event after additional 270|1760 cycles (all cycles # 150 MHz -> 6,6 ns).
This behavior can be seen in chipscope, captured with a stable, uninterrupted auxiliary clock (200 MHz, slightly oversampled).
So the GXTE2 seams to be powered-up, operational and all clocks are stable.
GTXE2 ports to control the OOB signaling:
The MGT has several ports for OOB signaling. On TX these are:
TX_ElectricalIdle - forces TX into electrical idle condition
TX_ComInit - send a ComInit sequence
TX_ComWake - send a ComWake sequence
TX_ComFinish - sequence was send -> ready for next command
On RX:
RX_ElectricalIdle - RX_n/TX_p are in electrical idle condition (low-level interface)
RX_ComInit_Detected - a complete ComInit sequence was send
RX_ComWake_Detected - a complete ComWake sequence was send
Detailed error desciption:
TX sends no OOB sequences if TX_ComInit is high for one cycle.
RX_ElectricalIdle is always high
Tests:
SATA loopback cable: cut a SATA cable and solder the apropriate wires ;)
-- I'm using a special SFP to SATA adapter, which extends the KC705 with a SATA connector - http://shop.trioflex.ee/product.php?id_product=73
SMA loopback cables: I moved the MGT and connected the LVDS wires to the SMA jacks and installed 2 SMA cables as cross-over.
I programmed my old ML505 (Virtex-5) with onboard SATA connector to send ComInit sequences. The 2 boards are connected with a special SATA cross-over cable.
I connected a HDD with a partial stripped SATA cable to the KC705 (SFP2SATA adapter) and connected a 2.5 GSps scope (yes the signals are undersampled, but it's good to see bursts and idle periods...).
Experiences:
Test 3 shows transmitted OOB sequences from Virtex-5 to Kintex-7 but the ChipScope trigger event does not occur - Rx_ElectricalIdle is still high.
Test 4 shows no transmitted OOB sequences on the cable.
Should I post parts or the complete transceiver instanziation?
only the instance has ca. 650 lines :(
Please ask if you need more information, images, code, ... :)
Appendix:
Electrical idle means that the MGT drives both LVDS wires (TX_n/TX_p) with common mode voltage (V_cm) which is in range 0..2000 mV. If this condition is met, the common mode delta voltage is less than 100 mV, which is referred to as ElectricalIdle condition.
OOB-signaling means that the MGT transmits bursts of electrical idle and normal data symbols (D10.2 in 8b/10b notation) on the LVDS wires. SATA/SAS defines 3 OOB sequences call ComInit, ComWake, ComSAS which have different burst/idle durations. Host controllers and devices use these "Morse signals" to establish a link.
So I think I found some answers to the problem and want to share them.
I started to simulate the GTXE2_CHANNEL hardmacro. The simulation is behaving as "false" as the hardware. So I tried to simulate the MGT in Verilog and used an instance template from here:
http://forums.xilinx.com/t5/7-Series-FPGAs/Using-v7gtx-as-sata-host-PHY-and-there-is-issue-bout-ALIGN/td-p/374203
This template simulates ElectricalIDLE conditions and OOB sequences nearly correct. So I started to diff both solutions:
TXPDELECIDLEMODE, which is a port to choose the behavior of TXElectricalIDLE is not working as expected. So now I'm using the synchronous mode.
PCS_RSVD_ATTR is a unconstrained bit_vector generic of 48 bit. If you have a look into the wrapper code of the secureip GTXE2_CHANNEL component, you will find a conversion from bit_vector => std_logic_vector => string. Internally all generics are treated as DOWNTO ranged. So it's important to pass a DOWNTO constant to the GTXE2 generics!
So now you could ask why is he using to-ranged constants and generics?
Xilinx ISE up to the latest version 14.7 has a major bug in handling vectors of user defined types in unconstrained generics. The default direction of vectors is TO. If you are passing vectors of enums as DOWNTO to unconstrained generics into a component, ISE is reversing the vector elements and "emits" a TO ranged vector in the components !!
This is especially "funny" if the design hierarchy, which uses this generic, is not a balanced tree...
If you are using enums of 2 elements, the problem is not existent -> maybe this enum is mapped to a boolean.
Which task are still open?
TXComFinish is still not acknowledging the send OOB sequences.
I have to investigate this two bug fixes in synthesis and measure the OOB sequences with a scope - this may last some days :)
Edit 1:
Solution for Bug 1:
I have added a timeout counter whose timeout depends on the current generation (clock frequency) and the current COM sequence which is to be send. If the timeout is reached I generate my own TXComFinished signal. Don't or the timeout signal with the original TXComFinished signal from GTX, because sometimes this signal is high while COMWAKE is to be send, but this finished strobe belongs still to the previous COMRESET sequence!
Solution for an other Bug:
RXElectricalIDLE is not glitch free! To solve this problem I added an filter element on this wire, which suppresses spikes on that line.
So currently my controller is running at SATA Gen1 with 1.5 GHz on a KC705 board with a SFP2SATA adapter and I think this question is solved.
I am going through the Uboot & kernel startup process. What exactly is the use of the FDT (Flat device tree) ?
Many link i have read they state that uboot pass the board & SOC configuration information to Kernel in the form of FDT
https://wiki.freebsd.org/FlattenedDeviceTree
Why kernel need the board configuration information ?
I am asking this question because when ever we make device driver in linux we use to initialize the device at probe() or module_init() call & use request_mem_region() & ioremap() function to get the range of address
& then set the clock & other register of the driver.
What does request_mem_region() actually do and when it is needed?
Now if my device drivers for onchip & offchip devices are doing the full board initialisation.
Then what is the use of flattened device tree for the kernel ?
You are right in assuming that the board files and device-trees are required for initialisation of on-chip blocks and off-chip peripherals.
While booting-up, the respective drivers for all on-chip blocks of an SoC and off-chip peripherals interfaced to it need to be "probed" i.e. loaded and called. On bus-es like USB and PCI, the peripherals can be detected physically and enumerated and their corresponding driver probed. However in general such a facility is NOT available is case of the rest of the peripherals on the rest of the buses like I2C, SPI etc.
In addition to above, when the device-driver is probed, one also needs to provide some information to it about the way in which we intend to configure and utilise the hardware. This varies depending upon the use case. For example the baud-rate at which we would like to operate an UART port.
Both the above classes of information i.e.
Physical Topology of the hardware.
Configuration options of the hardware.
were usually defined as structs within the "board" file.
However using the board-file approach required one to re-build the kernel even to simply modify a configurable option to a different value during initialisation. Also when several physical boards differing slightly in their topology/configuration exist, the "board" file approach becomes too cumbersome to maintain.
Hence the interest in maintaining this information separately in a device-tree. Any device-driver can parse the relevant branches and leaves of the device-tree to obtain the information it requires.
When developing your own device-driver, if your platform supports the device-tree, then you are encouraged to utilise the device tree to store the "platform data" required by your device-driver. This should help you clearly separate :
the generic driver code for your device in the <driver.c> file and
the device's config options specific to this platform into the device-tree.
A step-by-step approach to porting the Linux kernel to a board/SoC should help you appreciate the nuances involved and the advantages of using a device-tree.