Recently I've noticed the following in the documentation for the AXI4-Stream protocol from ARM (found here):
Recommended assertion for TUSER as per ARM
I thought it was interesting that TUSER must be initialized during the deassertion of reset, contrary to other signals (such as TLAST, TDATA, TDEST, etc.), which need only be initialized after the assertion of TVALID. What is the reason for this? Do you know any practical case where it would be useful to have the value of TUSER set before the assertion of TVALID? I haven't found anything in the rest of the documentation that elucidates this.
I've found this detail while trying out an IP, and noticing it did not pass one of the checks in an AXI4-Stream protocol checker, which is this. I thought it was weird that the protocol demands TUSER to be initialized before the assertion of TVALID.
Related
With a friend we are currently working on a library to create and read SNMPv3 packet.
The idea is "only" to create the content of the packet and it will be sent independently.
I know that many libraries exist for that but not in the language that we need. Our major problem now is to specify the content of the different packets. Which part is mandatory? Which part comes in which type of request?
With some examples available on Wireshark's website and the RFCs we can have a beginning of an idea but as it is a protocol, we need to be very clear and sure of what is required in each type of request (get-request, set-request, get-bulk, trap, etc.).
Is there a way to know exactly how each type of packet is created or the only information sources are the RFCs?
First, I want to offer some clarification about the terminology. A UDP packet encodes an SNMP "message". The format of the message varies with the SNMP version, but in all cases, it contains a single PDU. I think when you say "packet", you really mean "PDU".
As for your question, there's no better source than the RFCs, and they are actually easier to read than you think, as long as you know which parts to read (that's the tricky part).
RFC 3416 specifies everything to do with PDUs, including the format (p. 8), a comprehensive list of PDU types (pp. 7-8), and an explanation of how each PDU is used (under section 4.2, starting on p. 10).
The format of all PDUs is the same (though the BulkPDU replaces error-status and error-index with two integer fields of different meanings):
PDU ::= SEQUENCE {
request-id INTEGER (-214783648..214783647),
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- for proxy compatibility
badValue(3), -- for proxy compatibility
readOnly(4), -- for proxy compatibility
genErr(5),
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
},
error-index -- sometimes ignored
INTEGER (0..max-bindings),
variable-bindings -- values are sometimes ignored
VarBindList
}
I completed Anton Potočniks' introductory guide to the red pitaya board and I am now able to send commands from the linux machine running on the SoC to its FPGA logic.
I would like to further modify the project so that I can control the phase of the signal that is being transmitted via the red pitayas' DAC. Some pins (from 7 down to 1) of the first GPIO port were still unused so I started setting them from within the OS and used the red pitaya's LEDs to confirm that they were being set without interfering with the functionality of Anton Potočnik's "high bandwidth averager".
I then set the DDS_compilers' to Phase Offset Programmability to "streaming" mode so that it can be configured on the fly using the bits that are currently controling the red pitaya's LEDs. I used some slices to connect my signals to the AXI4-Stream Constant IP core, which in turn drives the DDS compiler.
Unfortunately the DAC is just giving me a constant output of 500 mV.
I created a new project with a testbench for the DDS compiler, because synthesis takes a long time and doesn't give me much insight into what is happening.
Unfortunately all the output signals of the DDS compiler are undefined.
My question:
What am I doing wrong and how can I proceed to control DACs' phase?
EDIT1; here is my test bench
The IP core is configured as follows, so many of the control signals that I provided should not be required:
EDIT2; I changed declarations of the form m_axis_data_tready => '0' to m_axis_phase_tready => m_axis_phase_tready_signal. I also took a look at the wrapper file called dds_compiler_0.vhd and saw that it treats both m_axis_phase_tready and m_axis_data_tready as inputs.
My simulation results remained unchanged...
My new test bench can be found here.
EDIT3: Vivado was just giving me the old simulation results - creating a new testbench, deleting the file under <project_name>.sim/sim_1/behav/xsim/simulate.log and restarting vivado solved this problem.
I noticed that the wrapper file (dds_compiler_0.vhd) only has five ports:
aclk (in)
s_axis_phase_tvalid (in)
s_axis_phase_tdata (in)
m_axis_data_tvalid (out)
and m_axis_data_tdata (out)
So I removed all the unnecessary control signals and got a new simulation result, but I am still not recieving any useful output from the dds_compiler:
The corresponding testbench can be found here.
I also don't get any valid output when I include the control signals.
The corresponding testbench can be found here.
Looks like m_axis_data_tready is not connected. No data will come out unless that's asserted.
I'm busy writing a driver for a UART. The, struct uart_port has a field uartclk see this link. According to a slide set I found from free-electrons, this is among the most important fields to initialize. Yet, the Xilinx AXI UART Lite, which I'm writing a driver for, doesn't initialize this member see this link to see.
I'm wondering about the importance of this field. What is this in relation to a UART? Why is it important? What role does it play in the serial core?
Thanks
P.S. I know there's a driver existing. However, this driver assumes the UART Lite is to be used in an embedded environment. In the application I'm writing to, this is not the case.
The UART like any other IP in the system has to have functional and interface clocks. In some IPs it might be same clock, in some it might be more interface or functional clocks. The uartclk field reflects the actual frequency on the input to baudrate generator (don't be confused by the frequency of functional clock which most of the time is constant). When user calls termios to set a desired baudrate the UART driver for actual hardware recalculates uartclk, if needed, and bottom layer, if used, configures the registers. That's how 8250 works. In other cases it might be left unused, if, for example, serial hw driver does everything on its own.
Im attempting to use the Xilinx uartlite 2.0 IP with an AXI4-lite interface to transmit a byte without a microblaze processor. Unfortunately, all the ready signals remain low after I set the data and valid signals and the tx signal never transmits.
I've included my simulation results. any ideas?
For posterity, Had to invert the reset and ensure all the inputs were initialized. Thank you for the helpful comments. I've attached a working simulation
I've looked over the info on BSCANE2 in http://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf (pg 169 7 Series FPGA Configuration Guide) and I can't quite figure out how to use it based on that descriptions.
I want to be able to use the JTAG port on the KC705 board to shift in some configuration data for our design. I think (based on the description there in the user guide linked above) that the BSCANE2 is what I need to do that... but I really don't understand why all of the pins of the BSCANE2 component seem to have the wrong direction (TDO is an input while all of the other JTAG control sigs like TCK, RESET, TDI are outputs). Initially I had thought that there was an implicit connection from the signals of the JTAG port of the FPGA to the instantiated BSCANE2 component, but that doesn't appear to be the case based on the port directions. I suspect I'm missing some information somewhere and while I have read the docs it's still not clear to me how to actually use the BSCANE2 to do what I'm trying to do.
Any example usage of a BSCANE2 component would be appreciated.
NOTE: the description of the BSCANE2 in the user guide linked above says:
The BSCANE2 primitive allows access between the internal FPGA logic and the JTAG Boundary Scan logic controller. This allows for communication between the internal running design and the dedicated JTAG pins of the FPGA
This sounds exactly like what I need.
Xilinx offers a 8 bit CPU called PicoBlaze that uses a JTAGLoader module to reconfigure the PicoBlaze's instruction ROM at runtime. The JTAGLoader is provided in VHDL for Spartans and Series-7 devices.
But I think JTAG is not a good protocol for data transfer. Especially the JTAG software API is a mess.
What about UART? Most boards have a USB-UART bridge like CP2103 that supports up to 1 MBoud.