Skip to content
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

Jump to bottom

Support sensitivity of arrayed variables #366

Closed
veripoolbot opened this issue Jul 12, 2011 · 2 comments
Closed

Support sensitivity of arrayed variables #366

veripoolbot opened this issue Jul 12, 2011 · 2 comments
Labels
area: scheduling Issue involves scheduling/ordering of events effort: days Expect this issue to require roughly days of invested effort to resolve resolution: fixed Closed; fixed type: feature-IEEE Request to add new feature, described in IEEE 1800

Comments

@veripoolbot
Copy link
Contributor

Author Name: Joe Eiler
Original Redmine Issue: 366 from https://www.veripool.org
Original Date: 2011-07-12

We have some code that is in a generate loop trying to connect up some modules in what is basically a ring network. We are hitting an "Unsupported" error:

Unsupported: Can't detect changes on arrayed variable (probably with UNOPTFLAT warning suppressed

I wrote a simple test to just aggravate the Error without the generate, it is attached. I know we could work around it by not using arrayed wires but due to some non-technical reasons that isn't really an acceptable option.

Any guidance you could provide as to the difficulty of adding support for this would be appreciated. I was thinking of something along the lines of treating all unpacked dimensions as individual variable instances but haven't looked at the code to see if this would be easy to do.
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-07-21T11:31:29Z

I think unpacking dimensions would be the easiest way to work around this. Of course if the user ever had a non-constant index (after constant propagation) this wouldn't work, but most cases I've seen don't.

This would best be in V3Gate or something similar, so it would work across port boundaries.

This has unfortunately been on the wish list for a while, as it's both a good chunk of work and not something that has bothered my designs yet. If you're willing to start tackling it I'll provide tips.

@veripoolbot veripoolbot added area: scheduling Issue involves scheduling/ordering of events effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800 labels Dec 22, 2019
kbieganski added a commit to antmicro/verilator that referenced this issue Dec 13, 2021
@kbieganski
Move entropy_src modules to UHDM (verilator#366)
9048eca 
* Move entropy_src and alert files to UHDM

* Fixes after review
@wsnyder wsnyder added the resolution: fixed Closed; fixed label Oct 16, 2022
@wsnyder
Copy link
Member

wsnyder commented Oct 16, 2022

This was fixed I believe in 3.862.

@wsnyder wsnyder closed this as completed Oct 16, 2022
tgorochowik pushed a commit to antmicro/verilator that referenced this issue Feb 29, 2024
@kbieganski
Move entropy_src modules to UHDM (verilator#366)
a9dde3b 
* Move entropy_src and alert files to UHDM

* Fixes after review
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: scheduling Issue involves scheduling/ordering of events effort: days Expect this issue to require roughly days of invested effort to resolve resolution: fixed Closed; fixed type: feature-IEEE Request to add new feature, described in IEEE 1800
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wsnyder @veripoolbot