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

Unsupported: tristate construct: ASSIGNDLY #496

Closed
veripoolbot opened this issue Apr 26, 2012 · 3 comments
Closed

Unsupported: tristate construct: ASSIGNDLY #496

veripoolbot opened this issue Apr 26, 2012 · 3 comments
Labels
resolution: abandoned Closed; not enough information or otherwise never finished type: feature-IEEE Request to add new feature, described in IEEE 1800

Comments

@veripoolbot
Copy link
Contributor

Author Name: Alex Solomatnikov
Original Redmine Issue: 496 from https://www.veripool.org
Original Date: 2012-04-26

Source code:

generate 
if (USE_OUTPUT_STROBE == "true") 
begin: output_strobe 
...
         wire aligned_os_oe; 
         wire aligned_strobe; 

         if (USE_BIDIR_STROBE == "true") 
         begin 
                 reg strobe_r = 1'b0; 
                 reg strobe_n_r = 1'b0; 
                 always @(aligned_os_oe or aligned_strobe) 
                 begin 
                         strobe_r <= #(dqs_out_dtap_delay) ~aligned_os_oe ? aligned_strobe : 1'bz; 
                         if (DIFFERENTIAL_OUTPUT_STROBE=="true") 
                                 strobe_n_r <= #(dqs_out_dtap_delay) ~aligned_os_oe ? ~aligned_strobe : 1'bz; 
                 end 
                 assign strobe_io = strobe_r; 
                 if (DIFFERENTIAL_OUTPUT_STROBE=="true") 
                         assign strobe_n_io = strobe_n_r; 
         end

The errors are on strobe_r <= and strobe_n_r <= lines. Variables are not actually declared as tri-states.
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-04-26T11:15:38Z

I do not think it support delayed assignments without massive changes, but will think about it.

Obviously the manual work around is to make separate data and enable regs, and have a tristate driver using them. This is normally what one would do for synthesized code (which this presumably isn't).

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2012-04-26T18:22:41Z

I think this is a behavioral model of some FPGA hard macro.

Is it possible to simply ignore delay and issue a warning as verilator does in other cases? Then, non-blocking assignment becomes equivalent to blocking assignment at least in verilator simulation. This approach seems logical to me and inline with verilator approach.

I tried to convert the code manually and it seems to work:

                         strobe_r = ~aligned_os_oe ? aligned_strobe : 1'bz; 
                         if (DIFFERENTIAL_OUTPUT_STROBE=="true") 
                                 strobe_n_r = ~aligned_os_oe ? ~aligned_strobe : 1'bz;

The complication that I didn't mention before is that:

inout strobe_io;
inout strobe_n_io;

So, assignment of z value can make a difference.

In any case, this does not seem to be a big deal because it happens only in these 2 lines of code and I think I can safely convert it manually.

@veripoolbot veripoolbot added 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
@wsnyder wsnyder added resolution: abandoned Closed; not enough information or otherwise never finished and removed effort: days Expect this issue to require roughly days of invested effort to resolve labels Apr 5, 2020
@wsnyder
Copy link
Member

wsnyder commented Apr 5, 2020

Closing due to age - please open a new ticket if still a problem.

@wsnyder wsnyder closed this as completed Apr 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
resolution: abandoned Closed; not enough information or otherwise never finished 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