TTool merge requestshttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests2020-11-25T22:56:24Zhttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/367Fix memory leak problem2020-11-25T22:56:24ZLe Van TruongFix memory leak problemI have just fixed the memory leak problems showed by valgrind. Here are some notes:
* To run valgrind efficiently we need to compile the simulator with "-Wall -ggdb3" option.
* Two mains issues detected by valgrind were:
* *"definitel...I have just fixed the memory leak problems showed by valgrind. Here are some notes:
* To run valgrind efficiently we need to compile the simulator with "-Wall -ggdb3" option.
* Two mains issues detected by valgrind were:
* *"definitely lost"*: due to not freed variables.
* *"Conditional jump or move depends on uninitialised value(s)"*: due to not initialed variables.
* I have already find all possible variables that can lead to the *"definitely lost"* and freed it, and I also assigned the initial value to the variables which need it.
* Now your "DSD.xml" can run without error detected by valgrind. I have also run valgrind with a lot of models to make sure no more memory leak issues could happen. After this merge, if your problem still occur I guess the main issue come from the size of memory chunk for transaction allocation (it is now 8000000 bytes \~= 8 Mbs for each transaction).
* The test has two executed ways: with and without valgrind.Ludovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/366Fix memory leak problem2020-11-23T13:19:16ZLe Van TruongFix memory leak problemI have just fixed the memory leak problems showed by valgrind. Here are some notes:
- To run valgrind efficiently we need to compile the simulator with "-Wall -ggdb3" option.
- Two mains issues detected by valgrind were:
- _"defini...I have just fixed the memory leak problems showed by valgrind. Here are some notes:
- To run valgrind efficiently we need to compile the simulator with "-Wall -ggdb3" option.
- Two mains issues detected by valgrind were:
- _"definitely lost"_: due to not freed variables.
- _"Conditional jump or move depends on uninitialised value(s)"_: due to not initialed variables.
- I have already find all possible variables that can lead to the _"definitely lost"_ and freed it, and I also assigned the initial value to the variables which need it.
- Now your "DSD.xml" can run without error detected by valgrind. I have also run valgrind with a lot of models to make sure no more memory leak issues could happen. After this merge, if your problem still occur I guess the main issue come from the size of memory chunk for transaction allocation (it is now 8000000 bytes ~= 8 Mbs for each transaction).Ludovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/365merging latest code of latency analysis2020-11-25T18:01:38ZMaysam Zoormerging latest code of latency analysishttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/364Fix memory leak problem2020-11-22T20:03:39ZLe Van TruongFix memory leak problemI have just fixed the memory leak problems showed by valgrind. Here are some notes:
* To run valgrind efficiently we need to compile the simulator with "-Wall -ggdb3" option.
* The memory leak appears due to some variables are not to be...I have just fixed the memory leak problems showed by valgrind. Here are some notes:
* To run valgrind efficiently we need to compile the simulator with "-Wall -ggdb3" option.
* The memory leak appears due to some variables are not to be freed. I have already freed it.
* Now the simulator can run normally without memory leak but valgrind also shows the issues about "_Conditional jump or move depends on uninitialised value(s)_". This issue happens because there are a lot of variables defined in header file without initial value and they will be assigned value on cpp file.
* Also valgrind has an option "--track-origins=yes" to track down where is "_Conditional jump or move depends on uninitialised value(s)_" occurs. I ran it and got no error, so I guess with the track down option valgrind will know where the variable is assigned value. This is common issue and it is not a memory leak issue.Ludovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/361Issue #196 CP (Communication Pattern) not updated when renaming HW nodes2020-11-09T18:07:26ZLe Van TruongIssue #196 CP (Communication Pattern) not updated when renaming HW nodesThe root cause of this issue is when user renames a HW, the mapping name of this HW on Communication Pattern is not changed. There are 2 ways to rename a HW on the interactive simulation window:
* Double click on HW node and then rename...The root cause of this issue is when user renames a HW, the mapping name of this HW on Communication Pattern is not changed. There are 2 ways to rename a HW on the interactive simulation window:
* Double click on HW node and then rename it.
* Right click on HW node and choose "edit".
I have handled both methods above, now user can rename HW without worrying about CP connection.
You can test this issue by the model "TTool/modeling/DIPLODOCUS/Zigbee_Andrea.xml" or you can create a new CP with any model for testing.![New_Project](/uploads/b5470b3c6b3a13b727f9bb1019aa15d2/New_Project.png)Ludovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/357FPGA reconfigure schedule2020-09-23T14:52:37ZLe Van TruongFPGA reconfigure scheduleIn this commit I have done:
* Fix FPGA scheduling: One can map several tasks on a FPGA. We can execute all these tasks together, or execute groups of tasks one after the other.
For instance, if we map T1, T2, T3, T4, T5 on the FPGA, a...In this commit I have done:
* Fix FPGA scheduling: One can map several tasks on a FPGA. We can execute all these tasks together, or execute groups of tasks one after the other.
For instance, if we map T1, T2, T3, T4, T5 on the FPGA, a user can specify T1 T2 ; T3 ; T4 T5 which means than T1 and T2 are first executed until they terminate. Then T3. Then T4 and T5. Note that if two tasks are connected with the same channel they should have the same scheduling (same priority).
* Remove redundant white space between FPGA and displayed tasks at first.
* Add tests for rescheduling of FPGA.
* I have an idea about scaling the timeline diagram: I will divide the length of each transactions to a predefined factor so the scale between each transactions remain the same. I will try to submit it on the next merger request.Ludovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/347Display timeline diagram using C++2020-07-10T14:19:38ZLe Van TruongDisplay timeline diagram using C++Ludovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/345Display timeline diagram using C++2020-07-08T10:14:22ZLe Van TruongDisplay timeline diagram using C++Ludovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/338display simulation result with timeline diagram2020-06-25T07:39:18ZLe Van Truongdisplay simulation result with timeline diagramLudovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/321Compare latency detailed analysis2020-03-22T22:56:36ZMaysam ZoorCompare latency detailed analysishttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/320Compare latency detailed analysis2020-03-18T19:18:06ZMaysam ZoorCompare latency detailed analysishttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/316New lip62020-03-12T16:38:54ZDaniela GeniusNew lip6https://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/315New lip62020-03-10T15:34:07ZDaniela GeniusNew lip6added script for SystemC and SystemC AMS environmentadded script for SystemC and SystemC AMS environmenthttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/314New lip62020-03-10T09:55:00ZDaniela GeniusNew lip6official version of echopen application (modelsward 2020); parts of correct-by-construction generation of GPIO interfaceofficial version of echopen application (modelsward 2020); parts of correct-by-construction generation of GPIO interfacehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/313Compare latency detailed anlysis2020-03-13T15:49:47ZMaysam ZoorCompare latency detailed anlysishttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/312Compare latency detailed anlysis2020-03-09T10:42:28ZMaysam ZoorCompare latency detailed anlysisLudovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/310#250 Emptying simulation transactions during simulation.2020-03-05T13:53:10ZLe Van Truong#250 Emptying simulation transactions during simulation.Ludovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/309#250 Emptying simulation transactions during simulation2020-03-05T11:05:29ZLe Van Truong#250 Emptying simulation transactions during simulationLudovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/308latency detailed analysis2020-03-05T14:05:36ZMaysam Zoorlatency detailed analysisupdating Latency Detailed analysis and adding compare function for latency detailed analysis for 2 simulation tracesupdating Latency Detailed analysis and adding compare function for latency detailed analysis for 2 simulation tracesLudovic ApvrilleLudovic Apvrillehttps://gitlab.telecom-paris.fr/mbe-tools/TTool/-/merge_requests/307#250 Emptying simulation transactions during simulation2020-03-05T09:26:19ZLe Van Truong#250 Emptying simulation transactions during simulationLudovic ApvrilleLudovic Apvrille