Add an FSM editor about logisim-evolution HOT 12 OPEN

Dear Logisim developpers,

I am working on a FSM editor/analyzer/simulator/HDL codegen for logisim to be used in our
computer design classes. The current implementation (alpha stage) is hosted on a fork of the project (https://github.com/sderrien/logisim-evolution).

In its current status, the editor can be used to visually specify/edit FSM models that can then be natively simulated by logisim.

I initially planned to deliver it as a jar plugin, but I have unsuccesfull doing so because of library/jar dependencies from my plugin to third parties (EMF/Xtext). As a consequence, it is currently implemented as native library within logisim (see readme.md on my fork)

Any feedback is welcome.

Regards,

Steven

from logisim-evolution.

from logisim-evolution.

Hi sderrien,
Thank you for your message. This feature seems to be very interesting.
We will take a look at your feature.

from logisim-evolution.

Hi sderrien,
I tried to compile your fork with ant and eclipse and was not able to build a jar to test (one of the reasons of my current beta version as pull request). What is the status for the moment on this feature?

from logisim-evolution.

I played around a bit with the FSM editor and had a good impression. Even without modification, I managed to modify the FSM (adding/removing states, inputs, outputs). The error messages could be improved to indicate more clearly what is the problem and how it may be fixed (e.g., when wanting to change the encoding of the states, you also need to think to adjust the corresponding global setting of the FSM). I would very much like to see it integrated into our develop branch for the next release.

from logisim-evolution.

Hi,

I would very much like to see it integrated into our develop branch for the next release.

I tried to merge my version with the master branch but I am really lost with the new kotlin/gradle build system which I could not make work.

The main issue I have is that I need to work with 3 distinct source folder (I use xtend+xtext which transpiled into java source code), and I could not figure out how to modify the gradle build file.

At this point I can only get it to work directly from Eclipse, or as a separate logisim jar plugin, which has to be explicitely loaded through the menu.

Any help would be appreciated,

Regards,

Steven

from logisim-evolution.

Thanks @sderrien for your effort to integrate your code with our develop branch. We are also still in the process to familiarise ourselves more with the new Kotlin/Gradle build system for Logisim-evolution.

Does your current dev-with-fsm branch already contain all the necessary sources?

Could you more precisely describe your additional dependencies (emf, xtend, xtext)? Which version of them you need and how do you use them in your FSM editor? These dependencies will be needed to get referenced in the build.gradle.kts file -- most probably in the plugins and dependencies sections. I found that there are dedicated plugins for emf, xtend, and xtext. The plugins and dependencies are automatically downloaded and managed by Gradle so we ideally should not need any binary/JAR artefacts in the source repository.

We also need to know which additional steps you do to build Logisim-evolution with your FSM editor extension.

from logisim-evolution.

I forgot to mention that for the dependencies section, you can look up the necessary artefact IDs on search.maven.org. On the page of each artefact are the clearly stated the line to add to build.gradle.kts.

from logisim-evolution.

@sderrien: I had a closer look to your Logisim-evolution repository to checkout your enhancements. After going through your commit history, I compared your master branch to the state in commit 65e5259. Integrating your enhancements into the official Logisim-evolution repository will require some effort as a simple git rebase or git merge won't do due to the migration from ant to gradle and the therefore done restructuring of our repository. Cherry picking of your modifications one by one with clean-ups after each step seems also to be not a good option due it will be very time consuming and pull in quite some binary artefacts from 3rd-party dependencies and generated implementation files, which we should try to keep out from versioning.

Therefore, the best option for me seems to be to squash your modifications into single commits per feature/topic (support for the different FPGA boards, new Logisim simulation components, the FSM editor). Based from the current develop branch, a branch for each feature/topic should be created. Then, we need to copy in the modified/added files to implement that feature/topic. These files can be probably best identified from comparing your master branch to the state in commit 65e5259. This sorting would be ideally done by you as you are the most familiar with the done modifications. Before adding the modifications to the commit, all modified hunks in already existing files need to be reviewed carefully so that we don't add regressions by removing our fixes and enhancements done in the official Logisim-evolution repository since 65e5259, but only consider the hunks, which actually implement the enhancement. We also need to keep out from the commits out-dated files required by the removed ant build system as well as any binary artefacts from 3rd-party dependencies and auto-generated files. Once the implementation files for the feature are committed to the, we can open a pull request to review/test the changes. Any modifications necessary to take into account the feature during building with gradle, pulling-in the required 3rd-party dependencies, etc. will become additional commits in the branch. Once the feature/topic is working in this branch, we can merge it into the develop branch and we can continue with the next feature/topic.

What do you think?

from logisim-evolution.

Hello Torsten,

Yes I agree, with what you propose. So far, here are the features I believe should be integrated.

• to my opinion, the FSM editor is the most valuable add-on, but there are a few issues to solve from the build side (see below)

• The additional DE0-CV board model is also interesting, but I somewhat hacked the current board model so as to be able to add external interface combining both inputs and output ports (the goal was to be able to interface with a 4x4 keypad). So a direct integration may not be straightforward and need some discussion.

• I introduced several additional components, (keypad, Instruction Set Simulator for a toy NIOS-II/RISC-V CPU, etc.). These are really specific to my course, so we should see whether they are worth being integrated to the main branch.

As mentioned above, there are a few issues that need to be solved on the graddle build side, before I can commit all/part of these changes.

To make it short, most of the .java files commited on my fork are actually generated by either xtend (in the xtend-gen folder) or by xtext/ecore (in the src-gen folder). These folder can only be used to store generated file as they are cleared before every build (this is not under my control). We must therefore find a way to register these additional java source folders in the gradle build (something I was not able to do for the moment). Once I know how to handle this, I should be able to follow your guidelines.

Regards,

Steven

PS : note that there seem to be an effort by xtend/xtext people to support graddle builds, but I am still not sure how to use them, and there are a lot of mismatch between groovy/kotlin way of specifying things. which got me lost.

from logisim-evolution.

@sderrien: Thanks for your feedback! Based on it, we could first look to integrate the FSM editor. Could you add to a new branch forked from our develop branch just the source files related to it without any generated files and binary 3rd-party dependencies? Then, we could have a look to add the necessary steps to the gradle Kotlin build scripts. There it would help if you could sketch out which files need to be processed by which tool to create all generated files that need later to get compiled/copied into the final Logisim-evolution JAR archive. You could add this information to this ticket or, even better, to a pull request to add the FSM editor. It is not a problem that this pull request is initially not yet ready for merging. It will just serve us as a place to document our progress with the integration of your tool. I don't know to which extend I will be able to help as I also just started using gradle/Kotlin and I am not really familiar with Xtext and Xtend either.

Regarding the new support for the DE0-CV FPGA board and the additional components, we are open for reviewing these contributions with you to decide together what makes sense to get integrated in the official version.

from logisim-evolution.

Hello Torsten,

The pull request has been submitted

Regards

from logisim-evolution.