UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer maxdz8
Observer
1,602 Views
Registered: ‎01-08-2018

Multi driven net to axi due to reset clashing

Hello, this is a successor to my previous questions about AXI interfacing.

Context: I have created an AXI memory-mapped register-based IP by using the Vivado wizard.
I have decided to give my IP full memory-mapped I/O, with some memory addresses being designated outputs, some being inputs.

Currently I have those errors:

[Synth 8-3352] multi-driven net MY_LOGIC_inst/slv_reg22[31] with 1st driver pin 'MY_LOGIC_inst/slv_reg22_reg[31]__0/Q' ["C:/vivadoProjects/ip_repo/MY_LOGIC_0.1/hdl/MY_LOGIC_v0_1_MY_LOGIC.v":279]
[Synth 8-3352] multi-driven net MY_LOGIC_inst/slv_reg22[31] with 2nd driver pin 'MY_LOGIC_inst/slv_reg22_reg[31]/Q' ["C:/vivadoProjects/ip_repo/MY_LOGIC_0.1/hdl/MY_LOGIC_v0_1_MY_LOGIC.v":763]

And indeed, yeah, that's surely wrong.

 

23_37_14-badstuff.xpr.png


Now for some reason I had to fiddle a day instead of just clicking on the above errors and get to the incriminated assignments.

The first assign is in Vivado Wizard's "Implement memory mapped register select and write logic generation".
On reset pin low, it clears all the regs to zero. Here explained flip-flop's end name __0.

The second assign is in my wrapper's copy-out block.
   

// Module-definition level.
wire[255:0] my_magic_result;
wire my_work_is_done;
    
always @(posedge my_work_is_done)
begin
    if ( S_AXI_ARESETN != 1'b0 ) begin
        { slv_reg22, slv_reg23, slv_reg24, slv_reg25, slv_reg26, slv_reg27, slv_reg28, slv_reg29 } = my_magic_result;
    end
    else begin
        { slv_reg22, slv_reg23, slv_reg24, slv_reg25, slv_reg26, slv_reg27, slv_reg28, slv_reg29 } = 256'b0;
    end
end


On reset pin low, clear the regs to zero. Otherwise slap there the bits from the result.

Being assigned by two different processes, I can definitely see why something is going wrong.

Question is of course how to fix this. Pretty much same thing as Multi-driven net warning, just with the added complication to blend the result in automatic boilerplate code following proper practices. Are there proper practices?


#1 Just don't clear to zero on reset

 

As easy as it gets. My current understanding is the IP wizard assumes all regs to be IN or inout. That's not the case there. I have seen "values undefined on reset" a few times in the past and my collague says not resetting out pins is in general a fair idea but those are not pins. I'm currently inclined to this.

 

#2 Figure out some logic (multi driven net?) to pull values from the right place

Such as, have the reset branch in the automaticcally generated block read from somewhere else instead of zero. I'm not sure it would work.

 

#3 Don't reset.

What does reset do for my device? It is supposed to be fully combinatorial (albeit it probably won't). Reset seems to have deep implications. What does 'resetting' a device mean in general? I dealt with a couple of devices where reset really just meant 'flush the internal command FIFO' to others were reset would shut down internal supply, discharge all capacitances and come back to life after an eternity. The only way I see reset useful would be to 'break' the pipeline if it hangs. I'm much more interested in preventing it from hanging. FSM from Vivado HLS has plenty of reset controls, it seems like a lot of work to support a reset throughtly. Maybe I should leave reset to the boilerplate and not do it myself? I don't think that will suffice, as far as I understand the problem is with the real result assignment.

 

Final note.

I am mildly inclined to believe the 'number of registers' in Vivado wizard might be wrong. After all, if we're building a memory-mapped device we should know if something is IN, OUT or what. How much am I supposed to modify the automatically generated boilerplate?

 

Any hint and opinion is welcome. Just write anything, I want to get in the right perspective.

 

Tags (2)
0 Kudos
9 Replies
Scholar austin
Scholar
1,563 Views
Registered: ‎02-27-2008

Re: Multi driven net to axi due to reset clashing

In response to reset,

 

Go read:

 

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

 

Xilinx FPGA devices generally need no resets, as all registers, BRAM, are 0 at start.  Or they are the INIT values you specify.

 

The function you describe (force 0, or force result) sounds like a multiplexer (but you have no multiplexer).  Nothing happens instantly, and so the tools implement what you asked which then violates how the Xilinx device is capable of operating (no multi-driven nets).  Again, reset in this context makes no sense to me (just not needed for any reason).

Austin Lesea
Principal Engineer
Xilinx San Jose
Observer maxdz8
Observer
1,554 Views
Registered: ‎01-08-2018

Re: Multi driven net to axi due to reset clashing

Wow thank you! Indeed I couldn't see any use for reset but FSM from Vivado HLS have them all over the place so I thought it was a good idea. I'll take a stretch and say I understand most of the document.

 

This still doesn't cut it however. The boilerplate AXI Slave code contains several more assignments. In the end I just convinced myself the boilerplate code is just a starting point so I deleted all clear-outputs statements and it seems I am green now.

0 Kudos
Scholar austin
Scholar
1,550 Views
Registered: ‎02-27-2008

Re: Multi driven net to axi due to reset clashing

Note that one-hot FSM was the 0.01%,

 

In the pdf.  One does have to careful, if you wish to reset a FSM.  Hoever, it is better to design the FSM so it always returns to known good states )no hidden states, no unused states).  So I would say FSM in Xilin IP (like AXI cores) are designed properly.

 

One other nice thing about synthesis in the FPGA design, is that anything unused, is automatically removed, so it doesn't take away from the resources available.  So if the core has a reset, and you tie it to 0, it will get optimized away by the tools.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Scholar markcurry
Scholar
1,542 Views
Registered: ‎09-16-2009

Re: Multi driven net to axi due to reset clashing


@austin wrote:

In response to reset,

 

Go read:

 

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

 


Then after reading that document please read:
https://forums.xilinx.com/t5/Timing-Analysis/Confused-about-reset-timing/m-p/826925/highlight/true#M13187

Most of the FPGA desigers I work with think the advice in WP272 is, at BEST case, offered too freely and without reservation.

Personally, I think the document should be deprecated, and rewritten.  It's borderline reckless advise that can lead new designers down roads with quite nasty consequences.

@austin wrote:


Xilinx FPGA devices generally need no resets, as all registers, BRAM, are 0 at start.  Or they are the INIT values you specify.


Austin - I do really appreciate your guidance in these forums - I've learned a lot from your posts, but this statement is not correct at all.  First the "general" frequency you state (along with the made up numbers in WP272) have no basis in reality, nor data to back it up.

 

Second - you need to clarify what you mean by "start".  The term doesn't have concrete meaning.

 

The INIT values will guarantee the state of all FFs, and BRAMs at the completion of FPGA CONFIGURATION.  Nothing else is guaranteed at all.

 

If the FF / RAM clock is not stable - those INIT values are immediately gone. No model from Xilnix will indicate differently. 

 

Since the inactive edge of the configuration is an asynchronous inactive edge - you have a potential timing violation with the clock pin (if again, the clock is stable at all).  This behavior is NOT modeled by Xilinx at all, but any designer with much experience will recognize the hazard from inspection.

 

Please, please, please stop referring to WP272 so freely.


Regards,

Mark

0 Kudos
Scholar austin
Scholar
1,539 Views
Registered: ‎02-27-2008

Re: Multi driven net to axi due to reset clashing

Mark,

 

You are the first person to mention this (reset is really needed, and wp272 no longer applies -- and is dangerous advice).

 

I ask, what supports your view?  Happy to get wp272 pulled if it is that bad.  Educate me why suddenly resets are required where for the last twenty years, they were almost never required, except is specific instances as detailed in wp272.  How have designs changed? 

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Scholar markcurry
Scholar
1,534 Views
Registered: ‎09-16-2009

Re: Multi driven net to axi due to reset clashing

Austin,

 

Please see the referenced thread.   There are others on these forums as well.  I rant in my head every time I see a reference to WP272.  I probably only actually post a comment on the forums less than half the time.  The fact that you think I'm the first person to mention these problems with wp272, actually bugs me a bit.  We're evidently not ranting loudly, nor frequently enough.

 

I also don't think WP272 "no longer applies".  It was wrong when it was printed IMHO.

 

I had a very real debug session for trouble that was hitting us for months because I'd followed the general advice in WP272 without thinking it through.  Sure enough, after months of debug the reset issue was uncovered - and FIXED... by actually resetting a bunch of logic where previously I was just depending on INIT values. I referred to this debug in one of the other threads too - it's several years old, and I'm not finding it at the moment. Perhaps my search luck will be better later.

 

And keep in my mind that my rants on wp272 are in two categories:

  1. Waste of time (local vs global reset).  No dangers here, just wasting time on work the tools will undo.

  2. Actual problems with the advice leading to real design problems.

 

The latter is of course the more important issue.

 

Regards,

 

Mark

0 Kudos
Scholar markcurry
Scholar
1,524 Views
Registered: ‎09-16-2009

Re: Multi driven net to axi due to reset clashing

 

Ok - totally hijacking @maxdz thread now, but Austin's "You are the first person to mention this" commenting is gnawing at me. 


Relevant threads:

https://forums.xilinx.com/t5/Timing-Analysis/how-can-I-meet-the-rst-timing/m-p/340311/highlight/true#M4467

 

https://forums.xilinx.com/t5/Synthesis/GSR-net-and-flip-flop-initialization/m-p/746176/highlight/true#M20617

 

https://forums.xilinx.com/t5/Synthesis/Initial-values/m-p/332231/highlight/true#M8484

 

https://forums.xilinx.com/t5/Synthesis/what-s-initial-value-of-register-without-power-on-reset/m-p/480050/highlight/true#M11633

 

https://forums.xilinx.com/t5/Welcome-Join/timing-constraints/m-p/745513/highlight/true#M42839

 

The last one looks to be where I as alluding to the troubles we had in the lab for a few months.  The root cause of the trouble was following WP272 too closely, and not thinking it through....  I can fill in more details if you wish, but feel I'd be repeating myself.  "Mark's ranting again..."

 

Regards,

 

Mark

 

 

0 Kudos
Observer maxdz8
Observer
1,502 Views
Registered: ‎01-08-2018

Re: Multi driven net to axi due to reset clashing

I don't mind the discussion. Even though I have little understanding of what's going on.

 

FYI my design will not be a FSM. It might be a reasonable choice in general but it's not in this case. I think at this system as pipeline wires to blocks with buffers in the middle. For extra safety I flow a dispatch ID through all the stages so I know at the end if what comes out is ok or garbage.

 

But I insist there is an underlying problem in the memory mapping code of the AXI IP and (after some more tinkering) it's not really tied to reset. Let's check out where I had to apply changes:

// Implement memory mapped register select and write logic generation
// The write data is accepted and written to memory mapped registers when
// ... assign slv_reg_wren = axi_wready && S_AXI_WVALID && axi_awready && S_AXI_AWVALID; always @( posedge S_AXI_ACLK ) begin if ( S_AXI_ARESETN == 1'b0 ) begin slv_reg0 <= 0; // 'read' address range, so far so good ... slv_reg20 <= 0; slv_reg21 <= 0; // first of my output regs. Down there all multi nets ... slv_reg31 <= 0; end else begin if (slv_reg_wren) begin case ( axi_awaddr[ADDR_LSB+OPT_MEM_ADDR_BITS:ADDR_LSB] ) 5'h00: // 'read' regs for ( byte_index = 0; byte_index <= (C_S_AXI_DATA_WIDTH/8)-1; byte_index = byte_index+1 ) if ( S_AXI_WSTRB[byte_index] == 1 ) begin // Respective byte enables are asserted as per write strobes // Slave register 0 slv_reg0[(byte_index*8) +: 8] <= S_AXI_WDATA[(byte_index*8) +: 8]; end ... 5'h15: // 'write' regs. No you're really not supposed to do that. I do that reacting to results being ready. // I mean, really, you can do that. In the sense if the outer user wants to write there there's no problem for me. // As long as you keep the conseguences to yourself. And OFC I reserve the right to overwrite at my own will. for ( byte_index = 0; byte_index <= (C_S_AXI_DATA_WIDTH/8)-1; byte_index = byte_index+1 ) if ( S_AXI_WSTRB[byte_index] == 1 ) begin // Respective byte enables are asserted as per write strobes // Slave register 21 slv_reg21[(byte_index*8) +: 8] <= S_AXI_WDATA[(byte_index*8) +: 8]; end 5'h16: for ( byte_index = 0; byte_index <= (C_S_AXI_DATA_WIDTH/8)-1; byte_index = byte_index+1 ) if ( S_AXI_WSTRB[byte_index] == 1 ) begin // Respective byte enables are asserted as per write strobes // Slave register 22 slv_reg22[(byte_index*8) +: 8] <= S_AXI_WDATA[(byte_index*8) +: 8]; end default : begin slv_reg0 <= slv_reg0; ... slv_reg21 <= slv_reg21; slv_reg22 <= slv_reg22; // those will also multi-drive slv_reg23 <= slv_reg23; ... slv_reg31 <= slv_reg31; end endcase end end end

The fact is, those regs do not have the same semantics as the others. This is why I speculate the vivado wizard might need some clarification. Or perhaps there might be a simple note about being free to modify the baseline boilerplate instead; my understanding this was on 'don't touch it!' mode. Because, if it works, you don't touch it. But it doesn't. Or at least not with my understanding. How am I supposed to use it?

 

 

0 Kudos
Scholar austin
Scholar
1,472 Views
Registered: ‎02-27-2008

Re: Multi driven net to axi due to reset clashing

Mark,

 

Thank you,  I will review all the links.  WP272 is quite old, and it wouldn't be unusual for it to be revised.

 

Better guidance for coding resets is the goal:  why, when, how.

 

I will get back to you not on this thread.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos