-
Notifications
You must be signed in to change notification settings - Fork 617
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inout pins #253
Comments
Yes, this would be a useful feature to add to Logisim-evolution. Logisim already contains a Tristate buffer component, but it is not yet supported by the Verilog/VHDL netlister. For this also the Pin component needs to get enhanced to be set its direction to The Logisim-evolution Holy Cross Edition by @kevinawalsh contains a Port I/O component with integrated tristate logic, which would satisfy your needs, but currently seems to be not supported for net listing on all FPGA boards. At least a simple test case I made led to a syntactically wrong VHDL top-level description when target was our GECKO4_EDUCATION board while it worked for TERASIC_DE0. However, I was not able to complete synthesis (my Quartus version is too recent to still support Cyclone III). Also note that the Port I/O component in Holy Cross edition differs in look and behaviour the already existing (undocumented) component with the same name in the official Logisim-evolution version. You may have noticed that @BFH-ktt1 is currently working very hard to back-port the enhancements made by @kevinawalsh in his Holy Cross Edition into the official Logisim-evolution source code and to generalise/improve upon these ideas. Support for inout pins is on his TODO list, but has lower priority than the integration of other features from the Holy Cross fork. Help for our effort to back-port improvements done in other forks of this code base as well as for the implementation of new features and fixing bugs is always welcome. |
Attached, you can find my extremely simple test case, which I made to test the Port I/O component in Logisim-evolution Holy Cross Edition by @kevinawalsh. |
Thanks for all the info. It looks like I should be able to get my Cyclone V GX Starter to work with the inout pins properly with LE-HC. I am looking into what would need to be done to get that feature working on LE. (I am a total noob with Java, fair warning). It looks like with the merge on 12\18\18; inout pins were added to the majority of the code. Seems like the feature just needs to be added to the following files; cburch/logisim/std/wiring/Pin.java I am going to get with a buddy that knows java to help me add the necessary stuff to these and test everything out. Will let you know how it turns out. Any hints or advice would be much appreciated. |
The PortIO code was a real mess and I recall it being very tricky to
getting it to work right. I probably didn't understand the HDL generation
code well enough at the time. Conceptually it is a very simple feature
though, and in the new LE-HC's HDL-generation code, PortIO is trivial,
barely more complicated than a Button or LED.
…On Thu, Apr 18, 2019 at 4:51 PM LordDecapo ***@***.***> wrote:
Thanks for all the info. It looks like I *should* be able to get my
Cyclone V GX Starter to work with the inout pins properly with LE-HC.
I am looking into what would need to be done to get that feature working
on LE. (I am a total noob with Java, fair warning). It looks like with the
merge on 12\18\18; inout pins were added to the majority of the code. Seems
like the feature just needs to be added to the following files;
cburch/logisim/std/wiring/Pin.java
cburch/logisim/std/wiring/PinAttributes.java
I am going to get with a buddy that knows java to help me add the
necessary stuff to these and test everything out. Will let you know how it
turns out. Any hints or advice would be much appreciated.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#253 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB4J3ATMGQHGGMWI3DMFTTTPRDNN3ANCNFSM4HFGNLDQ>
.
|
I noticed it is done with the PortIO component in Holy Cross. I am curious about adding it as a 3rd Pin option. So instead of having a boolean "Output?" option, you could have a "Type" dropdown with; Input, Output, InOut, as options. I know that would take more work to do, but for the normal simulation to work with it... it looks like you just need to update Pin.java and PinAttributes.java in order to give it the proper look and function. However, the HDL generation portion is where I am lost. I'm wondering if I could have just an additional catch on an existing if statement related to Pins > HDL to print out inout rather than in\out. Just thinking out loud. Does that seem like it would be a valid option? |
The native logisim simulator can't handle in/out ports, I believe. This is
why the Pin component has always been input only or output only, but not
both at the same time. It has been attempted in the past (by myself and by
others) to add a bidirectional option to Pin, but the simulator simply was
not designed for that. When I last looked at the idea of having a
bidirectional Pin option, I concluded that the entire simulator would need
a complete rewrite with an entirely different design. It is for this reason
that I decided the PortIO component should work more like a combination of
LED and Button, rather than as an extension of Pin. Currently PortIO has no
real interaction interface -- it uses colors to show the output, but it
doesn't have any way to use the mouse to interact with it as an input. I
don't know what the UI for that might look like, but it seems plausible to
try to add one.
Kevin
…On Thu, Apr 18, 2019 at 5:21 PM LordDecapo ***@***.***> wrote:
I noticed it is done with the PortIO component in Holy Cross. I am curious
about adding it as a 3rd Pin option. So instead of having a boolean
"Output?" option, you could have a "Type" dropdown with; Input, Output,
InOut, as options.
That would make the design and workflow for what I'm doing work very nice.
I know that would take more work to do, but for the normal simulation to
work with it... it looks like you just need to update Pin.java and
PinAttributes.java in order to give it the proper look and function.
However, the HDL generation portion is where I am lost. I'm wondering if I
could have just an additional catch on an existing if statement related to
Pins > HDL to print out inout rather than in\out.
Just thinking out loud. Does that seem like it would be a valid option?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#253 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB4J3AU44A24KAF6LD3N4IDPRDQ5ZANCNFSM4HFGNLDQ>
.
|
There are now I/O pins in logisim by use of the PORTIO component. I merged the holycross version of the portio by @kevinawalsh and adapted the hdl-generation such that we have inout ports on toplevel. Both VHDL and Verilog are supported. |
The following is a copy-paste of what I wrote in a duplicate issue:
I'm not familiar with the internals of Logisim, so I'm not sure how well this will work-out. But it should be easier than reworking the entire simulator. |
Hey,
I was wondering if its possible to add support for bidirectional pins. I want to make an MDIO controller for communications with a PHY device. (For a custom MAC solution).
MDIO uses a bidirectional pin for its data and a 2 clock cycle transition period for swapping between using the pin as an input vs an output.
Is this something that could be added to LE?
My thoughts, to make this easier, would be a custom component that takes 1 pin as an input, 1 pin as an output, a direction select input pin (maybe) , and finally 1 output that would only show up during FPGA commander pin assignments. That way you can just use 1 in and 1 out pin in your simulations (less tweaks to that system) then the FPGA commander could throw in the proper pin type when flashing.
The text was updated successfully, but these errors were encountered: