So I have the following bit of code:
int post_quantum_kem_encr( unsigned char m[32],
unsigned char pk[800],
unsigned char coin[32],
unsigned char c[736]) {
#pragma HLS INTERFACE ap_memory port = m
#pragma HLS INTERFACE ap_memory port = pk
#pragma HLS INTERFACE ap_memory port = coin
#pragma HLS INTERFACE ap_memory port = c
#pragma HLS INTERFACE ap_none port = return
some_crypto(m, pk, coin, c);
return crypto_kem_enc_def;
}
Synthesizing this and exporting it as IP results in the following IP block:
My question is, why is c split up into c_d0 and c_d1? (Same goes for pk and coin.) It doesn't happen for m so it seems to be some kind of optimization. I however would like it just to do straight single byte access to the memory element I'm hooking it up to.
It seems that Vivado HLS trying to treat port c as interface to 2-port memory. You can try to add the following directive to force 1-port mode:
#pragma HLS RESOURCE variable=c core=RAM_1P
This solution may look like request to use internal RAM of FPGA, but it seems that it just configures ap_memory interface.
P.S. I found some information about this here (they used core=RAM_2P_BRAM to force 2-port interface): https://www.xilinx.com/content/dam/xilinx/support/documents/sw_manuals/xilinx2014_3/ug871-vivado-high-level-synthesis-tutorial.pdf; pages 78-82
Related
The following code should read a value from DDR, decrement it, write the result back to the same address, and read the next value, repeating 256 times.
Instead on the first run it decrements the first 2 values (axi_ddr[0] and [1]), and on consecutive runs it only decrements the first value (axi_ddr[0]).
#include "ap_cint.h"
#include <stdio.h>
#include "string.h"
void hls_test(volatile int256 axi_ddr[256], uint32 *axi_lite_status_control){
#pragma HLS INTERFACE s_axilite port=axi_lite_status_control register bundle=BUS_A
#pragma HLS INTERFACE s_axilite port=return bundle=BUS_A
#pragma HLS INTERFACE m_axi depth=256 port=axi_ddr bundle=DDR
int256 axi_ddr_reg;
int256 diff = 1;
uint9 i = 0;
if (*axi_lite_status_control == 1){
for(i = 0; i < 256; i++){
axi_ddr_reg = axi_ddr[i];
axi_ddr[i] = axi_ddr_reg -diff;
}
*axi_lite_status_control = 2;
}
}
Both simulation and cosimulation passes as intended, and cannot figure out what is causing the issue.
Also tried C++, but it ended in the same behavior. The only time it was different, was when I forgot to give initial value to variable diff, and then the value in all 256 DDR locations became 0x0.
Could somebody please point out what am I missing?
The code looks fine to me and it should work flowlessly. However, if you're saying that both simulation and cosimulation pass, then something might be wrong with either you test code or with your hardware implementation.
Also, for the C++ version of the code, you shall be using the ap_uint<N> types defined in ap_int.h, instead of ap_cint.h.
I have started to work on I2C communication by examining adxl345 sensor. I wrote basic code to test if my code works or not. According to the ADXL345 technical documentation, the 0x00 register should return device id which is 0xE5.When I tried this register , the return value is 0. This application should be basic but I guess , I still missing something. Beside my experience, I also make a search at this community about the adxl345 problems,but I could not find answer. I would be very appreciated if you guide me in this problems. I attached my code.
void SysTick_Handler(void){
HAL_IncTick();
HAL_SYSTICK_IRQHandler();}
void SysClockEn();
/*System Configuration PA8-> I2C Clock , PC9-> I2C Data Lane*/
int main(){
SysClockEn();
HAL_Init();
/*------GPIO Configuration For I2C3------*/
__GPIOA_CLK_ENABLE();
GPIO_InitTypeDef *ptrB6,addrB6;
ptrB6 = &addrB6;
ptrB6->Alternate = GPIO_AF4_I2C3;
ptrB6->Pin = GPIO_PIN_8;
ptrB6->Pull = GPIO_NOPULL;
ptrB6->Speed =GPIO_SPEED_FREQ_HIGH;
ptrB6->Mode = GPIO_MODE_AF_OD;
HAL_GPIO_Init(GPIOA,ptrB6);
__GPIOC_CLK_ENABLE();
GPIO_InitTypeDef *ptrC,addrC;
ptrC = &addrC;
ptrC->Alternate =GPIO_AF4_I2C3;
ptrC->Mode =GPIO_MODE_AF_OD;
ptrC->Pin =GPIO_PIN_9;
ptrC->Pull =GPIO_NOPULL;
ptrC->Speed =GPIO_SPEED_FREQ_HIGH;
HAL_GPIO_Init(GPIOC,ptrC);
/*-----I2C Configurations-----*/
//__HAL_RCC_I2C3_CLK_ENABLE();
__I2C3_CLK_ENABLE();
I2C_HandleTypeDef *ptrI2C,addrI2C;
ptrI2C = &addrI2C;
ptrI2C->Instance = I2C3;
ptrI2C->Init.ClockSpeed = 100000; //100Khz
ptrI2C->Init.DutyCycle = I2C_DUTYCYCLE_2;
ptrI2C->Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;
ptrI2C->Mode =HAL_I2C_MODE_MASTER;
//ptrI2C->Init.GeneralCallMode =I2C_GENERALCALL_DISABLE;
//ptrI2C->Init.NoStretchMode=I2C_NOSTRETCH_DISABLE;
HAL_I2C_Init(ptrI2C);
__HAL_I2C_ENABLE(ptrI2C);
uint8_t data=0x00;
unsigned char buffer[2];
uint8_t *buf;
unsigned char pt;
uint32_t ptr;
uint8_t val
while(1){
val=HAL_I2C_IsDeviceReady(ptrI2C,0x1D,0xe5,1000);
pt=HAL_I2C_GetState(ptrI2C);
//HAL_I2C_Master_Transmit(ptrI2C,0x1d,0x00,1,0);
//HAL_I2C_Master_Receive(ptrI2C,0x1d,buffer,1,100);
//HAL_Delay(2);
HAL_I2C_Mem_Read(ptrI2C,SensAddr,0x00,1,buffer,2,1000);
ptr=HAL_I2C_GetError(ptrI2C);
}
}
void SysClockEn(){
__PWR_CLK_ENABLE();
}
The documentation of the sensor says:
the 7-bit I2C address for the device is 0x1D
So in your code your should write:
#define SensAddr (0x1D<<1)
...
HAL_I2C_Mem_Read(ptrI2C,SensAddr,0x00,1,buffer,2,1000);
...
This is because ST HAL considers the 7 bit address left shifted.
The documentation also says:
An alternate I2C address of 0x53 (followed by the R/W bit) can be chosen by grounding the SDO/ALT ADDRESS
If this is the case of your hardware, change the code to:
#define SensAddr (0x53<<1)
...
HAL_I2C_Mem_Read(ptrI2C,SensAddr,0x00,1,buffer,2,1000);
...
I am building a custom IP core in Vivado HLS to run withing image/video processing system that runs in embedded linux on the Zybo board. The core takes image/video data in via and AXI stream, performs a processing task (say Sobel), then outputs this to another AXI stream. This works, however, I'm wishing to use the on board switches for the Zybo to determine which processing task should be ran (default is a passthrough).
I cannot find a resource or simple example that shows (in HLS.. not IP Integrator or the Vivado SDK) how to create a HLS RESOURCE/INTERFACE to read the data from the GPIO switches. What I have is the code below in my top module:
#include <hls_video.h>
#include "ip_types.h"
void MultiImaging(AXI_STREAM& inputStream, AXI_STREAM& outputStream, int rows, int cols, bool sw0, bool sw1)
{
#pragma HLS INTERFACE axis port=inputStream
#pragma HLS INTERFACE axis port=outputStream
#pragma HLS RESOURCE variable=rows core=AXI_SLAVE metadata="-bus_bundle CONTROL_BUS"
#pragma HLS RESOURCE variable=cols core=AXI_SLAVE metadata="-bus_bundle CONTROL_BUS"
#pragma HLS INTERFACE ap_stable port=rows
#pragma HLS INTERFACE ap_stable port=cols
//are these two correct for the switches?
#pragma HLS INTERFACE axis port=sw0
#pragma HLS INTERFACE axis port=sw1
//are these two correct for the switches?
#pragma HLS RESOURCE variable=sw0 core=AXI_SLAVE //GPIO?
#pragma HLS RESOURCE variable=sw1 core=AXI_SLAVE //GPIO?
RGB_IMAGE img(rows, cols);
RGB_IMAGE oimg(rows, cols);
RGB_IMAGE sobel_output(rows,cols);
RGB_IMAGE imgh(rows, cols);
RGB_IMAGE imgv(rows, cols);
RGB_IMAGE hsobel(rows, cols);
RGB_IMAGE vsobel(rows, cols);
GRAY_IMAGE imgGray(rows, cols);
GRAY_IMAGE oimgGray(rows, cols);
#pragma HLS dataflow
hls::AXIvideo2Mat(inputStream, img);
//Passthrough
if(sw1 == 0 && sw0 == 0){
//..code here
}
//Sobel
else if(sw1 == 0 && sw0 == 1){
//..code here
}
//Threshold
else if(sw1 == 1 && sw0 == 0){
//..code here
}
//..etc
}
The above works and gives the proper output for 'C Simulation' and 'C Synthesis.' It errors out in the 'RTL/C Cosimulation' with: "OpenCV Error: Sizes of input arguments do not match." This makes no sense to me since ALL RGB_IMAGES are set initially with the same rows/cols.
Well, the size of the data is NOT done, in this specific case, only by ROWs and COLs.
Try to have a look in your header file, there should be something like:
// typedef video library core structures
typedef hls::stream<ap_axiu<24,1,1,1> > AXI_STREAM;
typedef hls::Scalar<3, unsigned char> RGB_PIXEL;
typedef hls::Mat<MAX_HEIGHT, MAX_WIDTH, HLS_8UC3> RGB_IMAGE;
This is clear because you are using AXI_STREAM. Here you are defining how many bit there are in a pixel, how many channel color in your pixel and so on. If the size of the images is the same, the sentence "Sizes of input arguments do not match" refers to this mismatching problem with the top main function.
I am trying to implement a SPI driver for custom hardware. I have started with a copy of the spidev driver, which has support for almost everything I need.
We're using a protocol that has three parts: a command bit (read / write) an address, and an arbitrary amount of data.
I had assumed that simply adding lseek capabilities would be the best way to do this. "Seek" to the desired address, then read or write any number of bytes. I created a custom .llseek in the new driver's file_operations, but I have never seen that function even be called. I have tried using fseek(), lseek(), and pread() and none of those functions seem to call the new my_lseek() function. Every call reports "errno 29 ESPIPE Illegal Seek"
The device is defined in the board.c file:
static struct spi_board_info my_spi_board_info[] __initdata = {
[0] = {
.modalias = "myspi",
.bus_num = 1,
.chip_select = 0,
.max_speed_hz = 3000000,
.mode = SPI_MODE_0,
.controller_data = &spidev_mcspi_config,
}, ...
I suspect there might be something with the way that the dev files get created, mainly because the example that I found references filp->f_pos
static int myspi_llseek(struct file *filp, loff_t off, int whence)
{
...
newpos = filp->f_pos + off;
...
}
So my questions are: Is there a way to have this driver (lightly modified spidev) support the "seek" call? At what point does this get defined to return errno 29? Will I have to start from a new driver and not be able to rely on the spi_board_info() and spi_register_board_info() setup?
Only one driver in the /drivers/spi directory (spi-dw) references lseek, and they use the default_llseek implementation. There are a couple of "hacks" that we've come up with to get everything up and running, but I tend to be a person who wants to learn to get it done the right way.
Any suggestions are greatly appreciated! (PS, the kernel version is 3.4.48 for an OMAP Android system)
Spi driver dose not support any llseek or fseek functionality. It has these many call back functions.
struct spi_driver {
const struct spi_device_id *id_table;
int (*probe)(struct spi_device *spi);
int (*remove)(struct spi_device *spi);
void (*shutdown)(struct spi_device *spi);
int (*suspend)(struct spi_device *spi, pm_message_t mesg);
int (*resume)(struct spi_device *spi);
struct device_driver driver;
};
Now drivers/spi/spi-dw.c is register as a charter-driver(debugfs_create_file("registers", S_IFREG | S_IRUGO,
dws->debugfs, (void *)dws, &dw_spi_regs_ops);). So they implement to create a file in the debugfs filesystem. they implement lseek callback function.
static const struct file_operations dw_spi_regs_ops = {
.owner = THIS_MODULE,
.open = simple_open,
.read = dw_spi_show_regs,
.llseek = default_llseek,
};
The file_operations structure is defined in linux/fs.h, and holds pointers to functions defined by the driver that perform various operations on the device. Each field of the structure corresponds to the address of some function defined by the driver to handle a requested operation
lseek -: lseek is a system call that is used to change the location of the read/write pointer of a file descriptor.
SPI -: The "Serial Peripheral Interface" (SPI) is a synchronous four wire serial link used to connect microcontrollers to sensors, memory, and peripherals. SPI can not provide any lseek and fseek functionlity.
There are two type of SPI driver (https://www.kernel.org/doc/Documentation/spi/spi-summary)
Controller drivers ... controllers may be built into System-On-Chip
processors, and often support both Master and Slave roles.
These drivers touch hardware registers and may use DMA.
Or they can be PIO bitbangers, needing just GPIO pins.
Protocol drivers ... these pass messages through the controller
driver to communicate with a Slave or Master device on the
other side of an SPI link.
If you want to user read, write and llseek then you will have to register a charter-driver on top of SPI. Then you will able to achieve your acquirement.
While I am trying to send data from Linux Client to Server over TCP I see extra zeros being added to the data. Can anyone please let me know why am I getting those additional zeroes? Please see below for the data packet format.
#define INT32 int32_t
#define UCHAR unsigned char
#define UINT8 u_int8_t
typedef struct cstruct_t {
UINT8 typ;
UINT8 l;
unsigned char buf[20];
} cksum_t;
cstruct_t cs;
INT32 fnlength;
Linux socket transfer is adding extra zero padding
No it certainly is not. You probably aren't reading it correctly. London to a brick you are ignoring the value returned by recv().
But you shouldn't be using a struct as a network protocol in the first place.
Since we dint want to add additional zeroes to make it 4-byte long as mentioned by #Soren we used
#pragma pack(push, 1)
#pragma pack(pop)
This worked perfectly for us.