Open-Source Projects: Issueshttps://forge.ispras.ru/https://forge.ispras.ru/favicon.ico?16490126692020-04-08T09:12:41ZOpen-Source Projects
Redmine Verilog Translator - Bug #10237 (Closed): ru.ispras.verilog.parser.VerilogTexas97TestSuite#runTes...https://forge.ispras.ru/issues/102372020-04-08T09:12:41ZSergey Smolovsmolov@ispras.ru
<p>The tool reports about cycle inclusion, but the described file does not contain includes at all.<br />Run <strong>ru.ispras.verilog.parser.VerilogTexas97TestSuite#runTest_Pi_Bus_single_master_main2</strong> to reproduce it.</p> Verilog Translator - Bug #10216 (Closed): ru.ispras.verilog.parser.VerilogQuipTestSuite#runTest_n...https://forge.ispras.ru/issues/102162020-04-06T09:43:30ZSergey Smolovsmolov@ispras.ru
<pre>
ERROR: [Internal] null
java.lang.NullPointerException
at ru.ispras.verilog.parser.backends.syntax.checker.VerilogStaticChecker.onDefineParameterBegin(VerilogStaticChecker.java:388)
at ru.ispras.verilog.parser.walker.VerilogNodeVisitor$14.onBegin(VerilogNodeVisitor.java:417)
at ru.ispras.verilog.parser.walker.VerilogNodeVisitor.onBegin(VerilogNodeVisitor.java:770)
at ru.ispras.verilog.parser.core.TreeWalker.onBegin(TreeWalker.java:102)
at ru.ispras.verilog.parser.core.TreeWalker.start(TreeWalker.java:87)
at ru.ispras.verilog.parser.VerilogSyntaxBackend.start(VerilogSyntaxBackend.java:80)
at ru.ispras.verilog.parser.VerilogSyntaxBackends.start(VerilogSyntaxBackends.java:55)
at ru.ispras.verilog.parser.VerilogTranslator.start(VerilogTranslator.java:212)
at ru.ispras.verilog.parser.sample.VerilogPrinter.main(VerilogPrinter.java:45)
at ru.ispras.verilog.parser.util.VerilogBenchmarkTest.runTest(VerilogBenchmarkTest.java:62)
at ru.ispras.verilog.parser.VerilogQuipTestSuite.runTest_nut_001(VerilogQuipTestSuite.java:345)
</pre> Retrascope - Bug #10174 (Closed): nondeterminism at EFSM transitions generationhttps://forge.ispras.ru/issues/101742020-03-18T15:26:22ZSergey Smolovsmolov@ispras.ru
<p>Fluctuations appear at EFSM transition number:<br /><pre>
java.lang.AssertionError: [b05]: 'engine=gadd-efsm-transformer modules=B05 states=313 transitions=482 efsms=3' should end with 'states=313 transitions=480 efsms=3'
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at ru.ispras.retrascope.engine.gadd.transformer.efsm.VhdlGaddEfsmBenchTest.runTest(VhdlGaddEfsmBenchTest.java:129)
at ru.ispras.retrascope.engine.gadd.transformer.efsm.VhdlGaddEfsmBenchTest.runTest(VhdlGaddEfsmBenchTest.java:55)
at ru.ispras.retrascope.engine.gadd.transformer.efsm.VhdlGaddEfsmTestSuite.runTest_b05(VhdlGaddEfsmTestSuite.java:92)
</pre></p> Verilog Translator - Bug #10173 (Closed): javadoc: DefineStructure.java:37: warning: no @returnhttps://forge.ispras.ru/issues/101732020-03-18T14:25:02ZSergey Smolovsmolov@ispras.ru
<pre>
> Task :javadoc
D:\Sergey\projects\veritrans\src\main\java\ru\ispras\verilog\parser\util\DefineStructure.java:37: warning: no @return
public String getString(List<String> params) {
^
1 warning
</pre> MicroTESK - Bug #10102 (Closed): incorrect ld scripts for x86 test programshttps://forge.ispras.ru/issues/101022020-02-06T10:22:06ZSergey Smolovsmolov@ispras.ru
<p>For x86 test programs emulation on QEMU4V, the following approach can be used. Test program should be compiled as <em>bootable drive</em> and run on QEMU4V ("-hda" option). The following linker script should be generated:<br /><pre>
SECTIONS
{
/* The BIOS loads the code from the disk to this location.
* We must tell that to the linker so that it can properly
* calculate the addresses of symbols we might jump to.
*/
. = 0x7c00;
.text :
{
__start = .;
*(.text)
/* Place the magic boot bytes at the end of the first 512 sector of the disk. */
. = 0x1FE;
SHORT(0xAA55)
}
}
</pre></p>
<p>Now ld scripts look as follows:<br /><pre>
ENTRY(_start)
SECTIONS
{
. = 0x7C00;
.text : { *(".text")}
. = 0x8000;
.data : { *(".data")}
.bss : { *(".bss COMMON")}
. = ALIGN(8);
. = . + 0x10000;
stack_top = .;
}
</pre></p> Retrascope - Bug #10081 (Closed): tool hangs right after final "Duration: " msghttps://forge.ispras.ru/issues/100812020-01-29T13:57:36ZSergey Smolovsmolov@ispras.ru
<p>It was ok at 1.0.1 but appear at 1.1.1</p> Retrascope - Bug #10023 (Closed): ru.ispras.retrascope.parser.verilog.VerilogParserTestCase: java...https://forge.ispras.ru/issues/100232020-01-07T12:37:30ZSergey Smolovsmolov@ispras.ru
<pre>
java.lang.Exception: Method runTest should have no parameters
at org.junit.runners.model.FrameworkMethod.validatePublicVoidNoArg(FrameworkMethod.java:76)
at org.junit.runners.ParentRunner.validatePublicVoidNoArgMethods(ParentRunner.java:155)
at org.junit.runners.BlockJUnit4ClassRunner.validateTestMethods(BlockJUnit4ClassRunner.java:208)
at org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:188)
at org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:128)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:416)
at org.junit.runners.ParentRunner.<init>(ParentRunner.java:84)
at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:65)
at org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:10)
at org.junit.vintage.engine.discovery.DefensiveAllDefaultPossibilitiesBuilder$DefensiveJUnit4Builder.runnerForClass(DefensiveAllDefaultPossibilitiesBuilder.java:128)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at org.junit.vintage.engine.discovery.DefensiveAllDefaultPossibilitiesBuilder.runnerForClass(DefensiveAllDefaultPossibilitiesBuilder.java:56)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.vintage.engine.discovery.TestClassRequestResolver.createRunnerTestDescriptor(TestClassRequestResolver.java:55)
at org.junit.vintage.engine.discovery.VintageDiscoverer.lambda$discover$0(VintageDiscoverer.java:53)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(StreamSpliterators.java:312)
at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at org.junit.vintage.engine.discovery.VintageDiscoverer.discover(VintageDiscoverer.java:55)
at org.junit.vintage.engine.VintageTestEngine.discover(VintageTestEngine.java:62)
at org.junit.platform.launcher.core.DefaultLauncher.discoverEngineRoot(DefaultLauncher.java:130)
at org.junit.platform.launcher.core.DefaultLauncher.discoverRoot(DefaultLauncher.java:117)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:90)
at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:92)
at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$100(JUnitPlatformTestClassProcessor.java:77)
at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:73)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy5.stop(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.stop(TestWorker.java:131)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:155)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:137)
at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
at java.base/java.lang.Thread.run(Thread.java:834)
</pre>
<p>To reproduce the bug run the <strong>ru.ispras.retrascope.parser.verilog.VerilogParserTestCase</strong>. To see the described behavior, see last test results at <strong>Retrascope_Weekly_Build</strong> Jenkins item.</p> Verilog Translator - Bug #9993 (New): if two modules are passed to the tool and one includes anot...https://forge.ispras.ru/issues/99932019-12-18T12:43:15ZSergey Smolovsmolov@ispras.ru
<p>Suppose there are two files with Verilog modules: <em>a.v</em> and <em>b.v</em> (<em>a.v</em> contains "a" module, b.v contains "b" module). Module "a" includes module "b".</p>
<p>When the following args are used for the tool:<br /><pre>
a.v b.v --include-path /path/to/b/file --module-name a
</pre><br />the tool hangs. These arguments seem to be strange, because "b" module appears two times in the command line.<br />More adequate diagnostics should be shown here, and, of course, no freezes.</p> Verilog Translator - Bug #9915 (Closed): "Cycle inclusion has been detected in fine <filename>" e...https://forge.ispras.ru/issues/99152019-11-13T12:01:33ZSergey Smolovsmolov@ispras.ru
<p>The tool reports "Cycle inclusion has been detected in fine <filename>" error for the case when "a.v" and "b.v" modules include "c.v" module.</p>
<p>To reproduce the bug, checkout to <a class="changeset" title="hdl-benchmark submodule update Signed-off-by: chudnovmaxim <chudnov@ispras.ru>" href="https://forge.ispras.ru/projects/veritrans/repository/veritrans/revisions/5ca788cdbc460bf393ccdef4b9cd6451f71acdd0">5ca788cd</a> commit and run <strong>ru.ispras.verilog.parser.VerilogQuipTestCase</strong>. It should be fail-free, but it is not.</p>
<p>IMPORTANT: please run all the project tests before push and compare your results with Jenkins!</p> Retrascope - Task #9911 (Closed): merge "*/sample/*TestCase" Java test cases https://forge.ispras.ru/issues/99112019-11-12T08:52:05ZSergey Smolovsmolov@ispras.ru
<p>There are separate "*/sample/*TestCase" Java classes in the project. They contain duplicated code and should be merged the same way as benchmark-related test case collections at Verilog Translator project. See <strong>ru.ispras.verilog.parser.VerilogQuipTestCase</strong> for example.</p> QEMU4V - Bug #9288 (Closed): /target/mips/translate.c:2617:9: error: ‘else’ without a previous ‘if’https://forge.ispras.ru/issues/92882018-09-28T08:44:54ZSergey Smolovsmolov@ispras.ru
<p>Compilation error:</p>
<pre>
/srv/****/workspace/QEMU4V/target/mips/translate.c: In function ‘gen_logic_imm’:
/srv/****/workspace/QEMU4V/target/mips/translate.c:2617:9: error: ‘else’ without a previous ‘if’
else {
^~~~
/srv/****/workspace/QEMU4V/rules.mak:69: recipe for target 'target/mips/translate.o' failed
make[1]: *** [target/mips/translate.o] Error 1
Makefile:481: recipe for target 'subdir-mips-softmmu' failed
make: *** [subdir-mips-softmmu] Error 2
:make FAILED
</pre> Retrascope - Task #6367 (Closed): Fortress expressions printing in an SMV formathttps://forge.ispras.ru/issues/63672015-10-25T18:19:41ZSergey Smolovsmolov@ispras.ru
<p>We need utility methods for Fortress expressions printing in an SMV format.</p>
<p>The most wanted use case is:</p>
<p>we have a collection of Fortress expressions: <code>e[1]</code>, <code>e[2]</code>, ... , <code>e[n]</code>;<br />we want to produce and SMV file of the following structure (it is supposed to be so):</p>
<pre>
declarations(e[1])
...
declarations(e[n])
formula(e[1])
...
formula(e[n])
</pre>
<p>where i = 1, ... , n; <code>declarations(e[i])</code> is a list of variable declarations that are used in <code>e[i]</code> expression; <code>formula(e[i])</code> is an SMV equivalent for <code>e[i]</code> expression.</p> Retrascope - Bug #5719 (Closed): EFSM Test Generator hangs on b11https://forge.ispras.ru/issues/57192015-03-18T07:20:55ZSergey Smolovsmolov@ispras.ru
<p>The EFSM Test Generator that is run at <strong>EfsmTestGeneratorVhdlTestCase</strong> hangs on b11 VHDL design (or this testcase continues more than <strong>8 hours</strong> - it is very suspicious).</p>
<p>The log fragment is attached below.</p> Retrascope - Bug #5680 (Closed): [efsm][generator][test][fate] DirectedFateGenerator.generateSequ...https://forge.ispras.ru/issues/56802015-03-04T08:01:26ZSergey Smolovsmolov@ispras.ru
<p>The error appears upon b07 design processing.</p>
<p>The stack trace:</p>
<p>[stack]<br />java.lang.NullPointerException<br /> at ru.ispras.retrascope.engine.efsm.generator.test.fate.DirectedFateGenerator.generateSequence(DirectedFateGenerator.java:226)<br /> at ru.ispras.retrascope.engine.efsm.generator.test.fate.DirectedFateGenerator.getNextSequenceIterator(DirectedFateGenerator.java:163)<br /> at ru.ispras.retrascope.engine.efsm.generator.test.fate.EfsmFateTestGenerator.start(EfsmFateTestGenerator.java:315)<br /> at ru.ispras.retrascope.engine.efsm.generator.test.fate.EfsmFateTestGenerator.start(EfsmFateTestGenerator.java:52)<br /> at ru.ispras.retrascope.basis.Engine.start(Engine.java:200)<br /> at ru.ispras.retrascope.basis.ToolChain.start(ToolChain.java:106)<br /> at ru.ispras.retrascope.basis.Engine.start(Engine.java:200)<br /> at ru.ispras.retrascope.Retrascope$Run.start(Retrascope.java:116)<br /> at ru.ispras.retrascope.Retrascope.main(Retrascope.java:333)<br /> at ru.ispras.retrascope.Retrascope.main(Retrascope.java:355)<br /> at ru.ispras.retrascope.util.VhdlUtilTest.runRetrascope(VhdlUtilTest.java:148)<br /> at ru.ispras.retrascope.util.VhdlUtilTest.runVhdl(VhdlUtilTest.java:73)<br /> at ru.ispras.retrascope.util.HdlUtilTest.runVhdl(HdlUtilTest.java:94)<br /> at ru.ispras.retrascope.engine.efsm.generator.test.fate.EfsmFateTestGeneratorVhdlTestCase.generate(EfsmFateTestGeneratorVhdlTestCase.java:32)<br />[/stack]</p>
<p>Full log is attached below.</p> С++TESK Development Environment - Task #3756 (New): Генерация C++ кода для модели сообщенийhttps://forge.ispras.ru/issues/37562012-12-05T15:32:06ZSergey Smolovsmolov@ispras.ru
<p>Небходимо разработать метод генерации C++ кода для модели сообщений.</p>
<p>На вход методу подается несколько объектов класса Adapter. В виде какой структуры данных эти "несколько" будут подаваться - на твое усмотрение. Например, можно взять ту же, что использовалась<br />в инструменте signalsGrouper для хранения набора накликанных "интерфейсов".<br />Т.к. все адаптеры между собой различны и полных совпадений между ними быть не должно, то из самых общих соображений могу предложить использовать java.util.Set.</p>
<p>Суть метода такова: проходим по всем адаптерам и извлекаем из них объекты MessageType и помещаем их в промежуточное хранилище (возможно, тот же Set). При этом необходимо проверять, что в хранилище ещё нет такого же типа сообщений (а при разработке адаптеров для разных интерфейсов вполне реально, что они будут использовать сообщения одного типа)- делать такую проверку лучше всего посредством разработки метода сравнения equals в классе MessageType.</p>
<p><strong>Шаблон для *.h-файла</strong></p>
<pre>
#pragma once
#include <hw/message.hpp>
namespace имя_пространства_имен {
</pre> Про извлечение название пространства имен смотри <a class="issue tracker-2 status-1 priority-4 priority-default" title="Task: namespace name for test system prototypes (New)" href="https://forge.ispras.ru/issues/3755">#3755</a>
<p>Для каждого типа сообщений далее генерируем следующий код:<br /><pre>
MESSAGE(имя_типа_сообщений)
{
public:
имя_типа_сообщений();
virtual ~имя_типа_сообщений();
SUPPORT_CLONE(имя_типа_сообщений);
</pre></p>
<p>Далее для всех полей сообщения данного типа генерируем вызов соответствующего макроса. Макросы бывают следующие:<br />1) Если размер поля больше 64 бит, то нужно использовать<br /> - CPPTESK_DECLARE_FIELD_ARRAY(имя_поля, размер_массива, размер_поля); - если маска не задана<br /> - CPPTESK_DECLARE_MASKED_FIELD_ARRAY(имя_поля, размер_массива, размер_поля, маска_поля); - если маска задана</p>
<p>В силу особенностей реализации параметр размер_поля делаем равным 64, а параметр размер_массива делаем таким, чтобы удовлетворялось следующее неравенство:</p>
<p>capacity <= размер_поля*размер_массива</p>
<p>где capacity - одноименное поле соответствующего экземпляра класса MessageField.</p>
<p>2) Если размер поля меньше, или равен 64 бит, то нужно использовать<br /> - CPPTESK_DECLARE_FIELD(имя_поля, размер_поля);<br /> - CPPTESK_DECLARE_MASKED_FIELD(имя_поля, размер_поля, маска_поля);<br /> - CPPTESK_DECLARE_BIT(имя_поля); - если размер поля равен 1</p>
<pre>
};
}
</pre>
<p>Заголовочный файл называем имя_пространства_имен_msg.h</p>
<p><strong>Шаблон для .cpp файла</strong></p>
<pre>
include <имя_пространства_имен_msg.h>
namespace имя_пространства_имен {
</pre>
<p>Для каждого из типов сообщений генерируем следующий код конструктора и деструктора</p>
<pre>
имя_типа_сообщений::имя_типа_сообщений(void)
{
</pre>
<p>Для всех полей сообщения, у которых incomparable равно false (см. <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Task: флаг incomparable в полях сообщений (Closed)" href="https://forge.ispras.ru/issues/3754">#3754</a>):<br /><pre>
ADD_FIELD(имя_типа_сообщений::имя_поля);
</pre></p>
<p>Для всех полей сообщения, у которых incomparable равно true (см. <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Task: флаг incomparable в полях сообщений (Closed)" href="https://forge.ispras.ru/issues/3754">#3754</a>):<br /><pre>
ADD_INCOMPARABLE_FIELD(имя_типа_сообщений::имя_поля);
</pre></p>
<p>Рандомизируем значения полей - только если оно соответствует входному интерфейсу!<br /><pre>
RANDOMIZE_MESSAGE(*this);
}
имя_типа_сообщений::~имя_типа_сообщений(void) {}
}
</pre></p>
<p>Рекомендация - данную задачу стоить решать посредством разработки нескольких относительно простых методов в соответствующих классах, а не одного сложного.</p>