I wonder who supports FPGA HDL backend for OpenCL.
I thought that altera/intel and xilinx provide compiler for OpenCL to generate HDL backend.
But, does OpenCL framework itself provides HDL backend?
If I'm right, this is not possible, because FPGAs have unique options depending on which board we use.
There's no "OpenCL framework" as such: OpenCL is a specification, a standard, and each supported device (GPU, CPU, FPGA) and platform (OS) combination needs its own implementation that complies with the standard, usually developed by the device vendor or OS vendor.
Related
I have tested my code on Contiki OS Cooja Simulator, I now want to transfer it to esp8266 module but could not find a proper any guide on how to transfer code from ContikiOS?
It's not that simple - "transferring" the code to a microcontroller is the easy part! What you call "transfer" is more widely known as "programming", "flashing" or "uploading" in this area. Instruction how to do it with Contiki and Contiki-NG are in the tutorial here: https://github.com/contiki-ng/contiki-ng/wiki/Tutorial:-Hello,-World!#running-the-example-on-a-real-device
However, for an embedded OS such as Contiki to work correctly on a specific microcontroller, not only must the microcontroller specified in compilation settings (so that the compilers knows what code to generate), the OS itself must be adapted to that specific microcontroller and the specific board. Each microcontroller has its own way of providing functionality that the OS needs, for example, hardware timers and interrupts. OS needs to support the microcontroller, that is, provide an adaptation layer between the OS core code and the API exposed by the hardware. Different boards may use the same microcontroller, but differ in the pins used for I/O, LEDs, peripherals available, and so on. Each of the supported boards must have a small adaptation layer in the OS as well.
Unfortunately ESP microcontrollers have never been officially supported by the Contiki OS, so you will need to get another hardware to try it out!
I am just learning about embedded systems and checking about wifi modules. I see in the datasheet they mention about a core processor that is integrated with rf SoC. I also see another processor on the MCU called application processor. I am confused about its purpose. What is it used for? Can someone please clarify? For reference, I was reading about the ATSAMW25 module.
Typically, devices that include wireless technologies (whether its Bluetooth/BLE, WiFi, LoRa, etc) include both the hardware required to manage the wireless connectivity and then separate hardware for running the higher-level application of the system. Frequently, managing the wireless protocol is intensive enough that it is best done with its own small processor running its own firmware to deal with connectivity and sending data over the link and might include a fair amount of proprietary firmware from the vendor (ie, Microchip in your example). To enable programmers to write their own code for the system, these protocol processors are paired with application processors, ones for whom the development tools and documentation are more openly available to developers for implementing whatever they want to do with the module. By separating the two operations (wireless/protocol and application), the code developers implement has less chance of causing fundamental problems for the wireless connectivity (like, application code hanging causes entire WiFi networks to fail) and the proprietary aspects of the system can be better protected (or another way, more documentation can be provided to developers without signing an NDA as the application processor is more "open" while the details of the wireless implementation are usually not).
In the case of the module youre looking at, the wireless hardware is all inside the ATWINC1500 and is accessed via SPI and some other GPIO by the SAMD21G (the application processor). All the code you write for the module end up running on the SAMD21G with some library/driver support to implement the wireless functions (which under the hood, are implemented by talking to the ATWINC1500). The ATWINC1500 simply runs the code the vendor (Microchip) wrote to actually do all the wireless protocol work and provides an interface for another processor (in this module, the SAMD21G) to control it.
We are looking to buy a SuperMicro machine to install the Xilinx ZC706 board on it for a specific project. We wanted to make sure which machine is and which intel processor family ( Haswell or Broadwell ) is compatible with the board?
We had a bad experience in PCIe card compatibilities with different machines, so we want to first investigate before placing the order.
Thanks.
First of all the Xilinx ZC706 is a board containing a PCI-e connector.
If you plugin the card into whatever PC it would not be detected because you are missing curcial hardware building blocks.
You need to create the PCI-e controller on the FPGA either by using an IP core from Xilinx or DIY.
When you say that you had bad experience with pci-e compatibilities i would bet my money that it is your hardware design that is the culprit and not the motherboard.
Presently I am using Javapos for Communicating with peripherals , is any other option available to communicate with Peripherals like Pos Printer , Pos cash drawer etc with out Javapos directly to Peripherals from Java code.
Can we Use Opos or any other option like Javapos to communicate with peripherals ?
Is opos is platform independent ? whether it will work in windows and Linux ?
For question 1, according to the UPOS specification, there are JavaPOS, OPOS and POS .NET that you can use to control the peripherals without any knowledge of the hardware.
However, it is not necessary for peripheral's vendor to provide all of them for customers.
Therefore, you can only use the device/object service that the peripheral vendor provided unless you have the hardware programming guide.
For question 2, OPOS is tied to Windows because it is based on OLE and COM and it needs to communicate with hardware. (See Appendix A of the UnifiedPOS specification.)
I'm not sure if each hardware type (display screen, USB, printer, etc) has to follow a unified standard in order to communicate with the CPU. For example, the bits transmitted back and forth between a display screen interface and the CPU are interpreted by the CPU as a specific command, and this interpretation is also correct (for the same bits) even if another display screen is used (from another manufacturer).
If this is not true, how BIOS is supposed to communicate with hundreds of different hardware devices with varying methods of interpreting bits going back and forth from the device interface to the CPU?
I find the standardization notion to be much more practical.
The BIOS itself actually only needs to understand a limited set of hardware required to boot the CPU. It does not need to understand "hundreds" of devices. For example, the BIOS has no idea what a USB printer is.
In general, the BIOS only understands the following devices:
The CPU/Chipset "core" hardware - e.g. the DDR3 memory controller
Basic PCI/PCI Express initialization - nothing device-specific
The video controller - just enough code for basic initialization, typically provided by an Option ROM
The SATA controller - as long as it is IDE/ACHI compatible.
The USB controller - possibly just USB 2.0
Standard USB storage devices
Standard USB keyboard/mouse devices
Ethernet controller - typically provided by an Option ROM
Any other device is ignored by the BIOS, unless the vendor included an Option ROM on the board. (You typically see this on SAS/SCSI controllers or Ethernet cards.)
Note most of the devices listed above conform to a standard specification, so they are software compatible regardless of who made it. For example, a USB 2.0 controller should comply with the EHCI spec, it would be compatible across all BIOSes. SATA controllers should follow the AHCI spec.
Once the Operating System loads, it takes over from the BIOS and loads its own drivers to interface with the hardware.
There is specific way(i.e. protocol) for each hardware to communicate with CPU. Maybe we can regard it as "device specification". To communicate with hundreds of different hardware devices BIOS should implement corresponding protocols within it. Thus we can say BIOS is actually a "collection" of specifications.
Whenever new spec is announced, BIOS should be modified to support it, or BIOS does not identify the corresponding device,not to speak of configuring it !