lnls-dig / bpm-sw Goto Github PK

Currently, we have a half way of doing this, without registering the same service twice, using the priv pointer to the SMIO bootstrap

Problem: CZMQ 3.0 brings new advancements, but it needs a little bit of rework in using them, such as the absence of a zctx () calls.

Solution: Rework the necessary code

Problem: In some cases, libclient code needs access to the export functions definitions structure, such as the following:

 disp_op_t fmc130m_4ch_leds_exp = {
    .name = FMC130M_4CH_NAME_LEDS,
    .opcode = FMC130M_4CH_OPCODE_LEDS,
    .func_fp = _fmc130m_4ch_leds,
    .retval = DISP_ARG_END,
    .retval_owner = DISP_OWNER_OTHER,
    .args = {
        DISP_ARG_ENCODE(DISP_ATYPE_UINT32, uint32_t),
        DISP_ARG_END
    }
};

Solution: Make separate files for the disp_op_t structures of each SMIO. In this way we can easily access the structures from outside code.

Problem: There is often a need to check for a return error from a function, set another error variable and exit (properly) the function with the appropriate error.

The current approach of using the ASSERT_TEST and ASSERT_ALLOC already does a good job in encapsulating some repetitive error checking, but it does not allow setting an error variable before exiting the function.

Solution: Implement an optional parameter in the ASSERT macros to set the error variable. This should be easy to do using the macros available in "hal/sm_io/rw_param/rw_param.h".

Problem: On loading an SMIO module, we should be able to set some default values to some registers

Solution: Implement an unified approach, using the available exported functions. By doing this we keep the modularity and internal module consistency , as we would use the same functions as the clients and would not bypass the API (error checking and the like).

Problem: There has been some cyclic header dependency and some other dirty includes.

Solution: Sanitize the header files following the principle outlined in http://rfc.zeromq.org/spec:21

Problem: The self->ops->release () is being called by the LLIO class itself. This should only be called once by its owner, the DEVIO instance. This does not pose a problem, as it's conceptually safe to call the release function more than once.

Solution: Remove this call by the LLIO, as the DEVIO already calls it!

Problem: The SMIO should monitor its PIPE socket, in order to self-destruct if any message comes across. This ensures a simple way of deallocating and managing SMIO resources.

Solution: The DEVIO part is already done. The only part left is on the SMIO side. We just need to monitor the PIPE socket through a simple asynchronous zmsg_recv () in the smio_loop () function and exist the thread (graciously ...).

Problem: CZMQ 3.0 brings a new API for threads, the zactor interface, providing a simple and more consistent API.

Solution: Change from zthread to zactor class

The current parsing is buggy and not user-proof

Issue by lerwys
Wednesday Jun 25, 2014 at 17:21 GMT
Originally opened as lerwys/bpm-software-old-bakcup#10

When trying to acquire 1 sample from ADC, the server never completes the acquisition. Hence, the client API gets stuck forever.

This is related to the fact that a minimum number of samples must be issued for each acquisition path, for memory padding purposes. So, the bug is probably related to the client API not handling the padding correctly for the ADC path.

Problem: As of now, for each new function created on the SMIOs, we need to manually add a new code for this function. This open a path to errors as the function opcode can change and leads to cumbersome addition of new functions.

Possible Solution: Automate this procedure by generating the opcode through hashing the function name

Problem: The FMC130M_4CH make an assumption that the instance ID 0 is the one controlling an specific (PCA9547) I2C bus. This should be passed to the class initialization function and not be hardcoded in the code.

The current parsing is buggy and not user-proof

Problem: Often, it is necessary to interface with the server in a easy way, without developing any code. Hence, a command-line interface, based in a "getopt" approach, could provide a lazy client an easy way to make requests to the server.

Solution: Implement a getopt program based in the libclient and lerwys/fcs-client.

The current parsing is buggy and not user-proof

Problem: The current version of the bpm-sw only allows for the active version to be selected. We must be able to select between PASSIVE and ACTIVE.

Solution: This option is a compile-time one. So, we must know a prior which board is inserted and disable the ACTIVE-only part of the code.

Issue by lerwys
Thursday May 22, 2014 at 13:41 GMT
Originally opened as lerwys/bpm-software-old-bakcup#1

Currently, on opening a PCIe device, it's hard-coded to the value "0". This works so far, as we only have a single FPGA board connected to the PCIe.

In the near future, we must support up to 6 FPGA boards (maybe more), so we need to
make the device number an initialization parameter.

Issue by lerwys
Thursday May 22, 2014 at 13:44 GMT
Originally opened as lerwys/bpm-software-old-bakcup#2

The maximum number of devices allowed to use the pcie driver is limited to 4
in the file "kernel/drivers/pcie/src/config.h".

We must remove this limitation in order to allow at least 6 devices, which is
our current use case.

Problem: We are currently using the libclient to initialize our SMIOs. This can only work if the functions are already exported to the broker. With this, a fast client could make a request before the the libclient had initialized its SMIOs.

The client can always issue a new request if necessary, but this is not optimal

Solution: One possbile solution is to add an initialized variable to each SMIO, informing if the SMIO is initialized or not. With this, we could always return the appropriate error to a fast client, such as a EAGAIN-like error.

Problem: Currently, the majordomo implementation (https://github.com/zeromq/majordomo) makes use of assertion to validate messages. Clearly, this is not the way to handle malformed messages, as anything incorrect would crash either the client, worker and/or broker.

Solution: Check for arity, size and contents of each message to check for its validity.

Problem: The debug message is as follows:

"TRACE: [09-01-14 23:21:12] [sm_io:acq] data_acquire: Previous acq params: number of samples = 9, channel = 1000"

But it should be:

"TRACE: [09-01-14 23:21:12] [sm_io:acq] data_acquire: Previous acq params: number of samples = 1000, channel = 9"

Solution: Just fix the output string. The parameters are OK.

Problem: On acquisition we can't perform reads from DDR3 past address 0x0FFFFFFF. Maybe this is related to the BAR2 page switching or the FPGA BAR2 paging addressing.

Issue by lerwys
Friday May 23, 2014 at 14:00 GMT
Originally opened as lerwys/bpm-software-old-bakcup#4

Problem: When acquiring FOFB samples the server takes a long time (sometimes never) to respond after it has finished acquiring the samples. The following messages appear on the log:

[sm_io:acq] data_acquire: Waiting for completion... #98
[sm_io:acq] data_acquire: Status done = 0x00000002
[sm_io:acq] data_acquire: Waiting for completion... #99
[sm_io:acq] data_acquire: Status done = 0x00000002
[sm_io:acq] data_acquire: Waiting for completion... #100
[sm_io:acq] data_acquire: Status done = 0x00010109
[sm_io:acq] wait_data_acquire: Number of tries was exceeded
14-05-23 10:56:54 worker created

Problem: There is a need for an automatic matching of dev_io and sm_io modules. This is very useful for making the software more generic and platform agnostic, as we wouldn't need to know beforehand exactly which gateware we are going to control. We only need to provide support for SMIO modules, but which SMIO module are actually gonna be exported is gateware dependant.

Solution: An adequate and fairly standard is to use the self describing bus (SDB) idea in software to parse the gateware bus hierarchy.

Problem: The ADC channel 1 is delayed by one clock cycle.

Possible Solution: Adjust the ADC delays.

Issue by lerwys
Wednesday May 28, 2014 at 12:08 GMT
Originally opened as lerwys/bpm-software-old-bakcup#8

Problem: When initializing DEV_MNGR, DEV_IO and SMIO components, if we pass a wrong bind address, such as tcp://ip_addr, without the port number for instance, the hal would initialize but fail silently, not accepting connections from any client.

Solution: Review the checking of wrong bind addresses and throw error messages

Problem: As of today, the only checking on SMIO received zeroMQ messages are the number of frames in a message (and through an assert). This must be improved to check for at least the following:

• Number of frames in the message
• Matching number of bytes per frame. Each frame must have the correct number of bytes.

Solution: Add a wrapper to our SMIO functions to check for errors

Problem: Often, it is easier to use a language like Python to create test programs and scripts. As we only have a C library, it is necessary to create bindings to allow a python program to access the libclient API.

Possible Solution: Use SIP tool to do this.

Issue by lerwys
Thursday May 22, 2014 at 14:03 GMT
Originally opened as lerwys/bpm-software-old-bakcup#3

Problem: Currently on receiving a zeroMQ (exported interface as well as internal message exchanges) we must check the errors one by one and often the same code gets repeated throughout the software.

Possible solution: Implement a set of macros to avoid code repetition and ease the
error treatment. For this, I think it should support macros that would send an error
message back to the requester.

Problem: We are moving the position calculation for TBT and MONIT rates to the high-level software (i.e., EPICS IOC). So, the following formulas:

x = Kx_(a+d-b-c)/(a+b+c+d) + Xoffset
y = Ky_(a+b-c-d)/(a+b+c+d) + Yoffset
q = Kx_(a+c-b-d)/(a+b+c+d)
sum = Ks_sum

are going to be calculated in software, only.

However, the FOFB rate, in addition to the above, needs to have its position calculated in gateware, as it's going to be used for the FOFB distribution system.

So, the FOFB offsets (Xoffset and Yoffset) needs to exported for high-level software to be used in gateware.

Solution: Export FOFB Xoffset and Yoffset. This also needs gateware support, however!

Problem: To implement the "automatic" spawn of "dev_io" on creation of the "/dev/fpga%u" devices, it is necessary to make dmngr_scan_devs () idenpotent. This means that we could call it within dev_mngr main loop to always update the current set of devices and its states (e.g., RUNNING, STOPPED, KILLED, etc)

Solution: Do a lookup on the dev_info hash table and check if the device is already there.

Issue by lerwys
Friday Jun 13, 2014 at 14:04 GMT
Originally opened as lerwys/bpm-software-old-bakcup#9

Currently,the error messages are only written to stdout (for debugging purposes), but it can be extended to allow writing WARNING, ERROR and FATAL messages to a logfile

Issue by lerwys
Wednesday May 28, 2014 at 12:03 GMT
Originally opened as lerwys/bpm-software-old-bakcup#7

Problem: Imagine a scenario where multiple clients access (i.e., requests) the same DEVIO
instance, being the same SMIO or not. For operations that work in 2 or more messages, like the acquisition, there could be a concurrency issue in that different clients request an acquisition with different parameters (by means of the data_aquire () function).

In this state, currently, there is no way to be sure that subsequently calls to get_data_block (), will return data relative to the respective data_aquire () parameters. Of course, if the a second
data_aquire () requests less samples than the first one, and the first client requests for a certain block of data, invalid blocks will still be reported to the client correctly, but that wouldn't make sense, as the client specifically requested for more samples.

Solution: There are various approaches that could be taken, two of them are:

• 1: Mark down operations that require two or more exported functions to be completed atomically
• 2: Don't allow other clients to perform functions belonging to a specific operation, until the first client has received an answer

Problem: There is a need to have standalone read/write FMC EEPROM

Problem: Due to a buggy FPGA firmware, there is a shift in the register addresses. This is not necessary and wrong in the newest firmwares.

Solution: Remove address shift

Issue by julianofjm
Friday May 23, 2014 at 19:01 GMT
Originally opened as lerwys/bpm-software-old-bakcup#6

Also, fixed some small bugs

julianofjm included the following code: https://github.com/lerwys/bpm-software-old-bakcup/pull/6/commits

Problem: This is a major bug. There is no bounds check for acquisition channel!

Solution: A good approach would be to export the valid channels, as well as its properties
over Wishbone. With this, we would be able to read this and check accordingly

Problem: Using the libbpmclient API for setting the K (Kx, Ky) values remotely does not work, and breaks all subsequently Wishbone communication with FPGA, but the cores which use the ADC clocks seem unaffected, such as the acquisition core. Also, using the libbpmclient API to set the K values locally works ok.

Issue by lerwys
Friday May 23, 2014 at 17:28 GMT
Originally opened as lerwys/bpm-software-old-bakcup#5

Problem: Currently, all zeroMQ messages (both internal and external) do not have a uniform structure, as every command had its own packet. Also, the only documentation is in the code following the format:

/* Message is:

• frame 1:
  *frame 2:
  */

Solution: Structurize the message to a single ""framework" and document the protocol.

Problem: So far we are using a simple poller from czmq API, which does not provide a balanced poll.

Solution: As per czmq documentation, we need to use zmq_poll API directly.

This would be needed for communicating with the RFFE controller

Problem: The clients rely on the structure disp_op_t for the arguments and the return types.
The actual implementation of _acq_get_data_block returns to the caller only the valid bytes read, as opposed to the specified in its corresponding disp_op_t structure.

Solution: Add the number of valid bytes in the data block structure and return the whole structure.

Problem: The current export subsystem is inconsistent, as we use a set of macros and some other times we don't. Also, the client side is difficult to maintain.

Solution: Implement a better export subsystem, based on exporting a regular function and wrapping it to the necessary zeroMQ functions

Problem: We had a verbose flag to indicate that more information should be written to the log, but we almost don't use it as we have the DBG macros to control this level of verbosity.

Solution: Remove the verbose flag from classes that don't use it

Problem: We need to be able to differentiate between active/passive version of the FMC130M_4CH boards, so we can export the necessary functions. The standard way of doing this is by reading the FMC FRU EEPROM and loading the necessary driver/firmware. However, this might be cumbersome and time-consuming to implement right now.

Intermediate Solution: A different solution, in the meantime, could be to try to read from a component only available in the active version of the board, through SPI or I2C. If unsuccessfully, we know the board is passive.

The proposed solution would be:

1. Treat all FMC ADC boards as active versions
2. Try to read from an IC only available in the active version
3. If unsuccessfully, fallback to the passive version. If not, continue to the active version

Problem: There are definitions which are board specific, such as the acquisition channel IDs and DDR3 memory size. We need to have different definitions depending on the chosen board.

Solution: Create a "arch" folder inside "hal/include". Inside this folder, and only in this folder, we put platform-specific definitions. Our build-system will be able to figure it out the definitions based on a makefile variable.

Problem: We need to support the active version of the FMC130M_4CH. This implies implementing all of the communication protocols, such as SPI and I2C, as well as interface for chips AD9510, Si571, and so on. We can start from porting the codes from github repo lerwys/fcs.

Problem: The SMIO ACQ functions do not correctly check for arguments boundaries, specifically the channel number. As such, on receiving an invalid channel number, we index a invalid vector position!

Solution: Check the received channel number prior to indexing anything

Problem: The _acq_get_data_block () returns the whole data block (as the function structure dictates),even if it's not valid or contains some invalid bytes.