![[logo]](/img/veripool_small.png)
Issue #496
Unsupported: tristate construct: ASSIGNDLY
| Status: | Feature | Start date: | 04/26/2012 | |
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | Unsupported | |||
| Target version: | - |
Description
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.
History
Updated by Wilson Snyder about 1 year ago
- Subject changed from %Error: ...: Unsupported tristate construct: ASSIGNDLY to Unsupported: tristate construct: ASSIGNDLY
- Category set to Unsupported
- Status changed from New to Assigned
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).
Updated by Alex Solomatnikov about 1 year ago
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.
Updated by Wilson Snyder about 1 year ago
- Status changed from Assigned to Feature
- Priority changed from Normal to Low
Also available in: Atom