cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
453 Views
Registered: ‎03-05-2019

[Synth 8-5972] variable 'tready' cannot be written by both continuous and procedural assignments

Jump to solution

I have a design that makes liberal use of Systemverilog interfaces. The design also has two Xilinx FIR Compiler IP cores connected to each other. Since they both use the AXI Stream bus to communicate, this seems like a perfect use case for interfaces to me. However, when synthesizing, I get a "[Synth 8-5972] variable 'tvalid' cannot be written by both continuous and procedural assignments" Critical Warning the valid and ready signals (but not on the data signals). As far as I'm aware I don't assign any value to these signals outside of the FIR core. Implementation is able to complete without any related warnings or critical warnings as far as I can tell. I'm using Vivado 2019.2 on Windows 10 (64 bit).

If I replace the interface with individual 'logic' signals, I no longer receive the Critical Warning, and I haven't seen this error in other parts of my design where I use the interface, so I think the problem may be with the combination of interfaces and the FIR Compiler IP core. Does anyone know what the source of this problem might be?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
284 Views
Registered: ‎03-05-2019

Upon further investigation, my interface had assigned default values (for simulation) to tready and tvalid. Getting rid of those default values also resolved the issue (which makes sense since that's a procedural assignment). It would be nice if Vivado made that mistake more obvious (pointing to where the conflicting assignments come from), but this particular case appears to be user error and not a Vivado bug.

View solution in original post

0 Kudos
5 Replies
Highlighted
Xilinx Employee
Xilinx Employee
385 Views
Registered: ‎07-21-2014

Hi @nkraemer 

 

Can you share the testcase/project to take a closer look at why tool is issuing Critical Warning?

 

-Shreyas

----------------------------------------------------------------------------------------------
Try to search answer for your issue in forums or xilinx user guides before you post a new thread.

Kindly note- Please mark the Answer as "Accept as solution" if information provided solves your query.
Give Kudos (star provided in right) to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Scholar
Scholar
373 Views
Registered: ‎09-16-2009

Are you using modports to give the tools a hint as to port direction?  Modports are only really needed for synthesis tools in this regard.  I'm wondering how (the use|non-use) of modports would affect your results?

Regards,

Mark

0 Kudos
Highlighted
Scholar
Scholar
368 Views
Registered: ‎09-16-2009

For what it's worth, we extensively use SystemVerilog interfaces in our designs - including use for AXI, and AXIS buses.  Two things come to mind that may be helping us.  As mentioned above, we use modports to give the tool information regarding port direction.  And secondly, all our interface members are of net types - i.e. wire.  I understand that many guides on the web suggest using logic, but for me the concept of an interface is just a creative collection of wires, so I like the idea of the underlying organization matching the concept in my head.  

Using net types instead of variables changes the way testbenches may use the interfaces, but that's a solvable problem.  

We never run into the issue you're seeing, as it couldn't happen.  The error you're getting is in part of the tool that's trying to determine whether a variable type is continuously, or proceduraly driven.  This part of the tool would never be triggered when the interface is defined with net types - as net types can only be continuously driven.

Not saying that what you're doing shouldn't work.  Obviously, Vivado should be doing the correct thing.  But thought I'd give the suggestion above to help you move forward.

Regards,

Mark

Highlighted
Observer
Observer
301 Views
Registered: ‎03-05-2019

Hi @aher,

I've attached a simple test case that replicates the issue for me with Vivado 2019.2.

Thanks for the advice @markcurry . I use modports wherever possible, but this doesn't seem to help when using the FIR Complier IP core (data_in.tready is a "slave" modport but still gives this error). other Xilinx IP core's I've used don't seem to have this issue. I suspect it may be because the FIR Compiler is encrypted under the hood.

Switching my interface from 'logic' to 'wire' seems to do the trick however, at least with the testcase I attached. I'll try it with my main project and report back if I find further issues

0 Kudos
Highlighted
Observer
Observer
285 Views
Registered: ‎03-05-2019

Upon further investigation, my interface had assigned default values (for simulation) to tready and tvalid. Getting rid of those default values also resolved the issue (which makes sense since that's a procedural assignment). It would be nice if Vivado made that mistake more obvious (pointing to where the conflicting assignments come from), but this particular case appears to be user error and not a Vivado bug.

View solution in original post

0 Kudos