Simulation terminating abnormally after ~billions of cycles.

Message transfer is currently managed by software, which is very slow.
Try to do it with DMA to reduce the time the processor looses with data transfer.

Recompiling the platform after changing one or another parameter in Configuration.mk file requires manual cleaning since Configuration.mk is not a compilation requirement for any file.

Possible solution:

#recipie for .h file taking mk as a requirement.
*.h : Configuration.mk

The mpsoc programmer should have a lib like this to perform profiling.

https://github.com/cyrus-and/prof/blob/master/prof.h

This lib is just a wrapper around #include <linux/perf_event.h>
and it reads event counters from the computer to measure several performance parameters.

Add support for software breakpoints by implementing 'Z' and 'z' messages in GDBRSP module. See

https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html#sec_exchange_target_remote

https://sourceware.org/gdb/current/onlinedocs/gdb/Stop-Reply-Packets.html#Stop-Reply-Packets

Auxiliary functions in gdbrsp module must be replaced by corresponding functions in std library or moved to outside the gdbrsp module.

functions:
strhti => converts an string represented hexadecimal number to its integer representation
strfind => find the index of some character in the character string
hexstr => converts a bytestream to its hexadcimal string representation
endswap => byte swap for endianess treatment

Ideal would be to each module to have its own parameter file. then, the orca parameter file would include the parameter file from each used submodule plus its own unique parameters.

however, in terms of software, three should be a separate parameter for each supported OS.

is it reaaaaaly necessary to have software related definitions together with hardware definitions ?
this situation should be avoided.

the hardware model should be totally independent of the software. I would highly recommend to move the software dir to a different repository. for example:

• orca-hellfire: orca compatible software running on top of hellfireOS
• orca-freertos: orca compatible software running on top of FreeRTOS
• orca-riot: ...
• orca-zephyr: ...

of course, at the low level, the software need to know, for instance, to whihch address the hardware is mapped. For this reason, the orca-sim repo would need a single header file with all the information the software layer needs to know. When the software is compiled, it would include this hardware-related header file.

the simulator dir should be replaced by a submodule of https://github.com/andersondomingues/ursa

Echo application echoes messages one byte less than expected. Possible cutting the last by the byte swap of endianess routine.

Possible fixes:

1. increase data packet size by 1 byte to avoid loss during byte swap
2. shift last byte to the left if packet size is even

Compilation scripts must implement one image for each of the individual PE, avoiding applications which are not executed by PE to be shipped into the image.

The current building system needs urgent improvements.
As far as I understood, at least the applications, tools, and OS should be completely decoupled from URSA and ORCA.

We need a more user friendly alternative to this script to easy the app development:
https://github.com/andersondomingues/ursa/blob/stable/Configuration.mk

I suggest something like this in the app dir

app/include
app/src
app/doc
app/build
CmakeLists.txt
ursa.exe

in the build dir we would have
build/sim <= ursa and orca libs
build/os <= HF
build/middleware <= self-adapt
build/app
build/tools

I can show you 2 Cmake-based projects I did in the past to see the final results.

Amory

The default application configured into

https://github.com/andersondomingues/ursa/blob/stable/software/orca-lib/src/orca-lib.c

isnt the same of

https://github.com/andersondomingues/ursa/blob/stable/Configuration.mk.

Add a new platform to the framework including two single-core CPU connected via their network interfaces.

• replace if-else by #ifdef at the startup routine to avoid useless code from being included in the images.
• generate startup code for individuals PE based on the mapped tasks.

Integration lib IP addresses are set to 127.0.0.1 (localhost) by default and cannot be overwritten using the global parameter in the .mk file.

• server_port and client_port work properly
• server_addr and client_addr have no effect

To avoid copyright issues, ORCA is being renamed.

The amount of parameters increases in a daily basis; thus some strategy to automate the configuration of the many possible platforms is required.
Today we use preprocessor directives to handle the matter, but It may not be "manageable" after a certain number of parameters.
Besides, dependency between parameters must be treated as well.

Github has something called badges. There are few useful badges that give to the viewer more confidence about the design. This is a list of some of the most relevant ones:

• CI Travis. https://github.com/richelbilderbeek/travis_cpp_tutorial
• Docs
• coverage https://github.com/richelbilderbeek/cpp/blob/master/content/CppCodecov.md
• DOI https://zenodo.org/record/2525346
• license

here are few examples of repos with badges
https://github.com/amamory/seriation
https://github.com/lsa-pucrs/donnie-assistive-robot-sw
https://github.com/disaster-robotics-proalertas/usv_sim_lsa

For CI, it would be nice that there were few test applications (UNIT Testing?!?!)
so we can quickly assess the results of regression testing.

Off-chip module side thread keeps listening for UDP packets when it should be killed, causing "could not find signal in global observer" messages to be spammed in the reporting output. Packet sending is not affected.

Steps for reproducing the bug:

1. start any simulation
2. press CTRL+C once to stop the engine (do not press multiple times, wait for the simulation to finish properly)
3. see a couple of messages at the end of simulation regarding the orphaned thread

Solution: replace the pthread implementation with the asynchornous I/O impl. used in GDBRSP server.

It is important to use lowest amount of memory for future FPGA prototyping. Please test ORCA with very small memories. 2MBytes per node is too much !!!

not all class definitions have Doxygen comment style. It would be nice to have some tec docs. there are some tutorials about doxygen deployment in github
https://gist.github.com/vidavidorra/548ffbcdae99d752da02.

There also alternatives to doxygen, based on markdown.
I like ReadTheDocs, for instance, https://dont-be-afraid-to-commit.readthedocs.io/en/latest/documentation.html

it would also be nice to have readme.md files in the main dirs/modules to briefly explain its contents.

Choose one format and stick with it !

change the mpsoc's network on chip from 16 bits flit width to 32 bits. it also involves changing the NoC device driver and the DMA.

be aware about situations like this
https://github.com/andersondomingues/ursa/blob/1b81d804e34b3e0a491a8b9ac93ac427d805cebe/tools/riscv32toolchain.sh#L2

I suggest a recursive grep to find out other situations like this.

Currently it sends packets of fixed size, the maximum size. This will increase the network, bandwidth, the time spent to do data transfer, and energy consumption.
Support to smaller packets is important before using it on real robots.

in the readme file, replace rviz by graphviz

• Make sure you have installed doxygen and rviz to your system.

• Make sure you have installed doxygen and graphviz to your system.

Hello Anderson

I was testing "example-orca-udp" and the returned msg was not correct. The output was:

[ INFO] [1560961567.053192095]: r: "", 9 bytes (0:62:20)

The msg was empty, although It was received 9 bytes. Since the msg was incorrect, when the command "orca_mpsoc_to_ros.publish(msg)" was executed, a segmentation fault event has emerged.

Regards,
Marcelo

Add a new platform to the framework including a single-core CPU connected to the off-chip module.

The NI currently uses of the _comm_start signal to start their send operation. The cpu checks whether the signal is down before raise it up to send a packet to the network. Both module writes to this signal, so it must be replaced by two distinct signals: one to report status to the cpu (_comm_status), and another one to start the sending operation (_comm_start).

The network works properly until an arbitrary number of cycles, then gets stuck preventing data from going from one node to another. No error is shown. Data processing is not affected, only communication.

Reading these docs I had an ideia to create a fault injection framework (lib/protocol) with URSA. It would integrate with Gazebo and allow hardware in the loop once the FPGA prototyping is working.

• A Retargetable Fault Injection Framework for Safety Validation of Autonomous Vehicles
• Fault injection mechanisms for validating dependability of automotive systems
• libfiu - Fault injection in userspace

Gdbrsp module checks on the breakpoint list whenever the value of PC changes during execution, resulting in poor simulation performance.

Performance can be enhanced by replacing opcodes by ECALL or EBRAK (riscv only) instructions in each of the breakpoints' locations.