Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Allow 'implicit' OR connections in nets #589

Closed
richardabendroth opened this issue Jun 23, 2023 · 4 comments
Closed

Allow 'implicit' OR connections in nets #589

richardabendroth opened this issue Jun 23, 2023 · 4 comments

Comments

@richardabendroth
Copy link

Currently, Antares seems to prevent implicit OR's, which is basically just connecting two digital outputs directly to one input. I get, that for the learner's convenience, it totally makes sense but it would be quite nice if there is a way to override this feature somehow, maybe by holding shift or something. Currently one always needs to place an OR gate which sometimes is just not what the original circuit intended.

image

image

@flandreas
Copy link
Owner

flandreas commented Jun 24, 2023

@richardabendroth There are several options here.

You can go to the circuit's properties and set "Wire Logic" to "Wired OR". This is a new feature we've introduced a year ago or so. It allows you to connect both outputs to the same wire, and Antares performs an OR operation in case the signals are in conflict.

In case it is primarily about the transmission gate, it is maybe a problem of this particular subcircuit. Output components of subcircuit have a property "Tri-State Output". If it is set, Antares allows to connect multiple such outputs to the same wire when the subcircuit is used in a parent circuit. Maybe we should set this property in the library component "Transmission Gate". But I guess your request is more general.

I'm aware what you are requesting has been asked for by other users in the past. I have to think about it. A modifier like CTRL is maybe a little bit too hidden. Perhaps a global user setting would be the better approach?

@richardabendroth
Copy link
Author

Ah nice, I didn't know this is already possible! It's exactly what I was looking for! My question is why you decided to make this a property of the whole circuit and not of the individual net?

@flandreas
Copy link
Owner

flandreas commented Jun 25, 2023

@richardabendroth Well actually, I was first more leaning towards making this property for the entire project and not only for a circuit, but that was kind of harder to implement. It's interesting that you would want to have it per net.

I've developed this feature when I was trying to build the circuits from the book "But how do it know" by John C. Scott (https://www.antarescircuit.io/docs/examples/but-how-do-it-know/description/). The circuits in the book don't use tri-state logic, but rely entirely on wired-or logic. It would have been quite cumbersome to set the property on every individual net.

@richardabendroth
Copy link
Author

That's interesting! I imagined the net being "conflict" protective in how it is now. It prevents the user from connecting outputs together. However, I imagined the net to always be able to handle implicit OR's. And when the user wants to override this "connection" protection, there would be some modifier key (like shift or sth.) that allows the user to connect the 2nd output to the net anyways. This net then could either have a different color indicating that there is an implicit OR in it, or the net node circle would become a square or diamond or something like that. I didn't imagine it working as a property at all but more of a safeguard that prevents the user from doing it. It's quite interesting to understand how you approached the problem completely from a different angle!

Repository owner locked and limited conversation to collaborators Sep 3, 2023
@flandreas flandreas converted this issue into discussion #618 Sep 3, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

2 participants