Using the iCE40 FOSS IceStorm FPGA flow: how does one write Verilog for a 3-state I/O pin (like a bidirectional data bus pin) using yosys/iceStorm?
Currently there is only limited support for inferring nontrivial IO buffers from behavioral code. So the best way of creating bidirectional IO buffers is by manually instantiating an SB_IO cell. For example:
SB_IO #(
.PIN_TYPE(6'b 1010_01),
.PULLUP(1'b 0)
) raspi_io [8:0] (
.PACKAGE_PIN(iopin),
.OUTPUT_ENABLE(dout_en),
.D_OUT_0(dout),
.D_IN_0(din)
);
(With iopin being the top-level module port.)
See the Lattice iCE40 technology library documentation for more details on SB_IO and other iCE40 primitives.
Related
I am trying to connect STM32G070 microcontroller with Quectel BC660K-GL via UART in DMA mode, using HAL libraries. There are two libraries both defining DMA communication functions (stm32g0xx_hal_uart.h and stm32g0xx_hal_dma.h). I am using Description of STM32G0 HAL and low-layer drivers manual. According to the manual _hal_dma.h defines Interrupt mode IO operation (page 215.), while _hal_uart.h provides, according to the description given in the library, Non-Blocking mode API's with DMA (lines 1054-1059). Hence I'm using DMA in order to offload CPU, which library would be preferred?
I'm currently working on an application where an MCU is receiving data from a hardware chip in the form of an asynchronous serial bit transmission at 2Mbps. This data has no encoding and no protocol aside from a start sequence, after which it is raw binary data.
The current approach for recovery is using the SPI module in 3-pin mode to oversample the stream 4x at 8MHz, allowing for recovery of the asynchronous data. While seemingly effective thus far with a simulated testbench, this method is rather complicated as an internal clock needs to be routed to the SPI CLK as the device is run in slave mode in order for DMA to recover the transmitted data while the processor executes another task.
Would it be possible to use any other peripherals efficiently for this task aside from SPI? Faking a communication protocol to recover a serial bit stream seems a bit roundabout, but I am not sure how to utilize UART or I2C without doing the same, and those might not even be possible to use as the protocol bits are not present in the stream. I also want to avoid using an ADC in the interest of power, along with the fact that the data is already digital so it seems unnecessary.
As the tensorflow paper states, Tensorflow' cross-device communication is achieved by adding "receive node" and "send node" into devices.
From my understanding, the device(Please considering only CPU devices are involved) is responsible for performing the computation of an operation. However,the data(ex:Tensor produced from an operation, Variable buffer) resides in memory. I don't know how data transfer from one device to another device is achieved physically. I guess the data transfer is achieved by shared memory. Is that right?
I will appreciate any explanation/corresponding codes regarding how the data transfer is achieved.
PS: TensorFlow paper link, Figure 4 shows the cross-device communication mechanism.
In TensorFlow, cross-device communication is achieved using the Rendezvous interface, which has multiple different implementations, depending on the deployment. The comment on that interface describes the general idea:
// A Rendezvous is an abstraction for passing a Tensor
// from a producer to a consumer, where the consumer may safely
// request the Tensor before or after it has been produced. A
// producer never blocks when using a Rendezvous. A consumer has the
// choice of making a blocking call or providing a callback: in either
// case, the consumer receives the Tensor as soon as it is available.
As you noted in your question, TensorFlow represents communication in the dataflow graph using Send and Recv ops that are added to the graph automatically when the graph is partitioned across devices. For each edge that has a source and destination on different devices, the graph partitioner inserts a pair of Send and Recv ops that share the same "rendezvous key" (an automatically generated string name that is used as a key in the rendezvous' index of pending tensors to be communicated). The implementation of the Send op is simple: it calls Rendezvous::Send(), passing in its rendezvous key and single input tensor, then returns immediately without blocking. The implementation of the Recv op is slightly more complicated: it registers a callback to be called when the tensor with the given key becomes available. That callback is responsible for "producing" the output of the Recv op, and unblocking subsequent computation.
The Rendezvous implementations perform the actual work of transferring the data:
IntraProcessRendezvous handles the transfer of data between devices in the same process. In the (unlikely) event that the transfer is between two CPU devices in the same process, the transfer can be achieved by a simple Tensor assignment. Otherwise, TensorFlow kicks off a device-specific DMA routine to transfer data between a CPU and GPU device.
The BaseRemoteRendezvous class and its subclasses handle cross-device communication in the case that the send and receiver can be in different processes. The main implementation of this class is RpcRemoteRendezvous, which uses gRPC to handle the remote transfers.
I am examining a way to connect two microcontrollers. On the level of serialization I am thinking of using Nano protobuffers (http://code.google.com/p/nanopb/). This way I can encode/decode messages and send them between two processors.
Basically, one small processor would be the RPC server, capable of doing several functions. Bigger processor will call there RPCs via messages sent, and then when data is ready, it will read it from smaller processor.
What would be the pros/cons of using UART, I2C or SPI?
Messages will be put in the mailbox que prior to sending.
It depends on your total requirements and how expensive are pins.
I2C only needs two pins, but it's slow and to handle it with or without interrupts is a pain, even with the build in peripheral modules.
It's a master/slave system, it's good for controlling many slow devices like temp sensors.
Only two lines for all bus devices, the selection is done via an I2C-Address in the protocol.
Uart needs two pins, it's normally faster, easier to handle, but requires (nearly) the same clocks at both sides.
One to one asynchronous system, can be good if both systems needs to be send sometimes data without waiting for a master poll request.
Can also be used as a bus system, but then you need a master/slave structure or more complex protocols.
SPI needs 3 (or 4 with CS) pins, it's the fastest, simple to implement even with DMA, low cpu time overhead, often buffered.
When you have enough free pins I would prefer it.
All of these interfaces have pros/cons.
UART connection in it's basic functionality requires 2 pins: RX and TX. The SW implementation of how to message over that UART is quite a bit more complicated...you'll have to develop your own messenging protocol between the devices and decide what is a good message and what is a bad message. It could get quite complicated because you pretty much have to define how to "communicate" over the physical link, what is an error, retries, etc. Unless you are implementing a serial port connection to a PC or some other external device, I think a UART is highly overkill for a IC to IC communication path. Master and slave are not specifically defined.
SPI is a master-slave relationship and can be a faster interface (I've seen up to 60MHz clock rates, not common) but it also requires more pins, 3 at a minimum for a point-to-point communication scheme but the number of pins increases to 3+n as the number of "slaves" increases above 1. There are no error indications via SPI. SPI is a "de-facto" standard...meaning it can vary in implementation...your mileage may vary depending on how a IC supplier defined "their" SPI implementation. I generally consider the lack of a true standard for SPI to be a "con".
I2C is also a two pin interface and is an actual "standard" developed by Phillips (now NXP.) As a standard, it is well-defined in how it operates, how errors are raised, and is simple to implement. It has an addressing scheme, can send commands, and can support 0 or more data frames in a transaction. CRC (optional) and higher data rates can be supported (up to 5Mbits.) It does have cons, namely bus capacitance can limit actual data rates (rise/fall time) but generally you can design around this "problem".
In their most basic forms, all of these busses are "ground referenced"...and can suffer from system induced noise. Obviously, lower rail voltages can make this even more of issue. Again careful design practice can mitigate many of the problems some people report to be the bain of their existence.
For the point-to-point system initially asked by the poster, if a master-slave arrangement is required, a SPI or I2C interface may be appropriate (data rate dependent.) If a master-master relationship is required, I2C or UART may be required.
For ease of implementation from a software point of view, I'd rank these communication methods in the following order:
I2C, if you need faster data rates than I2C can handle, then SPI
SPI, if you need multi-master, then I2C or UART
UART as a last resort...has a lot more software overhead to manage the communications channel
I would use UART or CAN or ETH or any protocol that is asynchronous.
If you use a synchronous protocol, the master must always "ask" the slave if it has data and generate unwanted traffic.
UART and RS232 are same protocols or not?If yes then why we called RS232 is a interfacing standard.Is the Protocol and interfacing standard same?
UART (universal asynchronous receiver/transmitter) refers to a hardware device for serial data transmission where the timing is recovered from the data frame. A frame has a start bit, data bits, optionally a parity bit, and a stop bit (or bits). The start but synchronises the bit sampling for the rest of the frame.
RS-232 refers to a series of related standards for the electrical interface and signalling of a specific serial interface. While the output of a UART will be at the logic level of the UART device, RS-232 defines specific voltage levels, so when a UART is used to implement an RS-232 interface, an RS-232 level line driver is required. RS-232 line levels are bi-polar (the logic states are negative and positive voltage), while UART will have logic levels of zero and some positive voltage.
Full RS-232 includes additional signal lines apart from serial Tx/Rx some of which (such as flow control) may be provided by a UART and others such ring indicator that would be provided by other logic such as GPIO. A minimal RS232 implementation (three-wire mode) requires Tx, Rx and Ground.
A UART might be used for other interfaces such as RS-422, RS-485, and for short distance chip-to-chip communication may be connected directly UART to UART. So UART and RS-232 are certainly not the same thing.
In the OSI 7-layer model for communications, RS-232 covers only Layer 1 - Physical Layer. A UART is merely a means of implementing part of such a physical layer.
So with respect to "protocols" RS-232 is a pysical layer protocol only - it does not define any semantics to the data being transmitted. A UART is not a protocol at all, but a digital electronic device for implementing a number of types of physical layer communications.
UART is a piece of translation hardware, not a protocol. they can work with many serial/parallel communications protocols including but not limited to RS232
RS232 is an electrical standard, not a protocol. Just like RS485, rs422 and others, all of which can carry the same serial protocol.
The output of an UART are UART frames. Frames are defined at the OSI layer2 Data Link Layer. So RS2-232 is a little bit more than Layer1 OSI.
RS485 and RS422 are working on LAye1 only because the rest of the communication will done by upper layer protocols such as Modbus or PROFIBUS for example (Layer2 and Layer7)
Peter The Netherlands