cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
31,409 Views
Registered: ‎07-26-2013

Synthesis reports multi-driven net as Warning. Fails in bitstream generation

Hi,

 I am getting the following warning

CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5342/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5343/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5344/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5345/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5346/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5347/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5348/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5349/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5350/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 1st driver pin 'i_5351/O' [//fxt_dma_packer.v:65]
CRITICAL WARNING: [Synth 8-3352] multi-driven net O with 2nd driver pin 'GND' [//fxt_dma_packer.v:65]


in Synthesis. The tool is not giving any conclusive information as who the 2 drivers are for a particular net.

I would expect the tool the give an error and stop during synth but surpirsingly the tool completes PnR and fails in bitstream generation giving multidriven pin error.

 

The Synthesis utilization count is 56% LUT utilization and post PNR comes down to 0.5%.

 

I am using Vivado 2013.4 with V7330t FPGA.

 

Can Someone give any information why this could be happening?

The RTL doesnt actually have any mutlit driven net though as per my understanding.

 

Does it have to do anything with fifo IP generated from vivado ip generator that is used in the module? #Randomthought

 

-Sachin

 

 

0 Kudos
22 Replies
Highlighted
Xilinx Employee
Xilinx Employee
31,404 Views
Registered: ‎04-16-2012

Hi,

You can use the below tcl command to convert this critical warning to error:

set_msg_config -id "Synth 8-3352" -new_severity "ERROR"

To remove the issue, open elaborated design and search for the net mentioned in the critical warning and observe it's connectivity.

Thanks
--------------------------------------------------------------------------------------------
Have you tried typing your question in Google? If not you should before posting. Also, MARK this is as an answer in case it helped resolve your query/issue.Give kudos to the post that helped you to find the solution.
0 Kudos
Highlighted
31,400 Views
Registered: ‎07-26-2013

Synthesis completes despite setting that property.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
31,398 Views
Registered: ‎09-20-2012

Hi,

 

Synthesis completes with error messages. However it still proceeds with Implementation.

 

This is a known issue. A CR has been in place to fix this. Check this article http://www.xilinx.com/support/answers/59051.htm

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Highlighted
31,387 Views
Registered: ‎07-26-2013

The same module that gives a multidriver issue, doesnt report that in some other project.

This module i have implemented like n number of times.

With a new proj created today, it just wont allow me.

 

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
31,381 Views
Registered: ‎07-01-2010

Hi ,

Can you please share the project so that we can review it and let you know the root cause?

Regards,
Achutha
---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------
0 Kudos
Highlighted
31,367 Views
Registered: ‎07-26-2013

As suggested earlier,after synthesis, i tracked the pin in elaborate design to find the multidriver.

But it doesnt show multiple driver for that signal

 

Attached is snapshot.

DMA_CH[3].WREADY is o/p of dma_packer and there is only one driver in RTL as shwon by elaborate design.

Wondering why synthesis gives a multidriver problem.

 

I will try to send the project also by min number of files and issue reporduced.

multidriver.png
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
31,337 Views
Registered: ‎07-01-2010

Hi,

Looking at the details shared there is no multidriver for the net.
Can you try synthesizing the design using the flatten_hierarchy none and see if you see this warning?
Please share the design so that i can cross the details and suggest you.

Regards,
Achutha
---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
31,332 Views
Registered: ‎08-31-2009

I am also seeing exactly the same problem (using 2013.4). I am creating some IP and adding it to the IP catalog. When I synthesize just the IP project, I don't get the warning. When I include the IP in my microblaze design, synthesis reports many multi-driven nets. Bitstream generation is not allowed after this.

0 Kudos
Highlighted
31,318 Views
Registered: ‎07-26-2013

I am not sure how Vivado see things. With flatten_hierarchy none, i would see the multiple driver warnings in Synthesis.

With the option changed to full or rebulti hierarychy,Synthesis doesnt complain about multidriven nets but the PnR fails.

This is the synthesis result

 grep -i mult ../synth_1/runme.log | grep -i driv
|1     |multi_driven_nets |      0|        0|Passed |Multi driven nets |
|1     |multi_driven_nets |      0|        0|Passed |Multi driven nets |

 

impl_1]$ grep -i mult runme.log | head
INFO: [Place 30-611] Multithreading enabled for place_design using a maximum of 4 CPUs
Phase 3.1 Commit Multi Column Macros
Phase 3.1 Commit Multi Column Macros | Checksum: 32d148577
INFO: [Route 35-254] Multithreading enabled for route_design using a maximum of 4 CPUs
CRITICAL WARNING: [Route 35-14] Multi-driver net wpu_fpga_top_inst/fxt_fpga_top/fxt_pio_depacker/pio_dux5_2/pch1_pkt[6].ch_buff/n_0_bbstub_dout[61]__0 detected. Design will not pass DRC check. Router will ignore one driver
CRITICAL WARNING: [Route 35-14] Multi-driver net wpu_fpga_top_inst/fxt_fpga_top/fxt_pio_depacker/pio_dux5_2/pch1_pkt[6].ch_buff/n_0_bbstub_dout[61]__0 detected. Design will not pass DRC check. Router will ignore one driver
CRITICAL WARNING: [Route 35-14] Multi-driver net wpu_fpga_top_inst/fxt_fpga_top/fxt_pio_depacker/pio_dux5_2/pch1_pkt[6].ch_buff/n_0_bbstub_dout[61]__0 detected. Design will not pass DRC check. Router will ignore one driver
CRITICAL WARNING: [Route 35-14] Multi-driver net wpu_fpga_top_inst/fxt_fpga_top/fxt_pio_depacker/pio_dux5_2/pch1_pkt[6].ch_buff/n_0_bbstub_dout[61]__0 detected. Design will not pass DRC check. Router will ignore one driver
CRITICAL WARNING: [Route 35-14] Multi-driver net wpu_fpga_top_inst/fxt_fpga_top/fxt_pio_depacker/pio_dux5_2/pch1_pkt[6].ch_buff/n_0_bbstub_dout[61]__0 detected. Design will not pass DRC check. Router will ignore one driver
CRITICAL WARNING: [Route 35-14] Multi-driver net wpu_fpga_top_inst/fxt_fpga_top/fxt_pio_depacker/pio_dux5_2/pch1_pkt[6].ch_buff/n_0_bbstub_dout[61]__0 detected. Design will not pass DRC check. Router will ignore one driver
 followed by

 

ERROR: [Drc 23-20] Rule violation (MDRV-1) Multiple Driver Nets - Net wpu_fpga_top_inst/fxt_fpga_top/fxt_dma_packer/pch1_pkt[0].barrel_mux5/pch1_pkt[1].ch_buff/dout[90] has multiple drivers.
ERROR: [Drc 23-20] Rule violation (MDRV-1) Multiple Driver Nets - Net wpu_fpga_top_inst/fxt_fpga_top/fxt_dma_packer/pch1_pkt[0].barrel_mux5/pch1_pkt[1].ch_buff/dout[9] has multiple drivers.
ERROR: [Drc 23-20] Rule violation (MDRV-1) Multiple Driver Nets - Net wpu_fpga_top_inst/fxt_fpga_top/fxt_dma_packer/pch1_pkt[0].barrel_mux5/pch1_pkt[1].ch_buff/fxt_fifo_full[0] has multiple drivers.
ERROR: [Drc 23-20] Rule violation (MDRV-1) Multiple Driver Nets - Net wpu_fpga_top_inst/fxt_fpga_top/fxt_dma_packer/pch1_pkt[0].barrel_mux5/pch1_pkt[1].ch_buff/n_0_bbstub_dout[93]__0 has multiple drivers.
ERROR: [Drc 23-20] Rule violation (MDRV-1) Multiple Driver Nets - Net wpu_fpga_top_inst/fxt_fpga_top/fxt_dma_packer/pch1_pkt[0].barrel_mux5/pch1_pkt[1].ch_buff/n_0_bbstub_dout[94]__0 has multiple drivers.
ERROR: [Drc 23-20] Rule violation (MDRV-1) Multiple Driver Nets - Net wpu_fpga_top_inst/fxt_fpga_top/fxt_dma_packer/pch1_pkt[0].barrel_mux5/pch1_pkt[1].ch_buff/n_0_bbstub_dout[95]__0 has multiple drivers.
ERROR: [Drc 23-20] Rule violation (MDRV-1) Multiple Driver Nets - Net wpu_fpga_top_inst/fxt_fpga_top/fxt_dma_packer/pch1_pkt[0].barrel_mux5/pch1_pkt[1].ch_buff/p_0_in has multiple drivers.
ERROR: [Drc 23-20] Rule violation (MDRV-1) Multiple Driver Nets - Net wpu_fpga_top_inst/fxt_fpga_top/fxt_dma_packer/pch1_pkt[0].barrel_mux5/pch1_pkt[1].ch_buff/p_1_in[90] has multiple drivers.

 

errors.

 

Also as mentioned by someone, the IP also has wiered behaviour.

The signals mentioned above chbuff are o/ps of async_fifo.

dout typs signas. How could you have multiple drivers on dout of fifo ip?

 

Additionally,in one of other projects, i have see the fifo IP messing the PnR.

Eg a design shows postsynthesis LUT count as 56% and implementation fails after few minutes saying the it cannot fit the design. I simply go to IPsources tab of Vivado, right click the FIFO IP and click RESET Output ports and the synthesis+implementation goes through.

 

I dont know what the reset output ports really does. The documentation also simply says it resets the ports.but exactly what? Scary things going on.

 

I have a suspicion on one thing.

 

Consider below hierarchy

module A

     |__module B

     |

     |__module C

 

If there is an SV interface which runs thru A,B and C.

Few signals of the interface are driven by B and few are driven by module C, could that cause the tool to cause such an error.

Considering there is a similar known issue http://www.xilinx.com/support/answers/53546.html.

 

Purely a guess anyways.

 

-Thanks

Sachin

 

 

 

 

 

0 Kudos
Highlighted
16,623 Views
Registered: ‎07-26-2013

Well, I think i may have found the problem.

 

I simply created a new project and it went through to generate bitstream successfully.

I rerun my old project and it failed in bistream generation giving multiple driver problem on FIFO o/p ports.

 

When i had created a new project (project_12_2) , the flow began with async_fifo synthesis followed by regular RTL synthesis.

Contrast that with older project, it directly jumps to RTL synthesis and on its way, it gives a warning

grep -i locked ../../../project_12/project_12.runs/synth_1/runme.log
# set_property is_locked true [get_files /local_disk/sbhutada/oasis_fpga/oasis/fpga/xlnx_mem/fxt/fxt_async_fifo_core/fxt_async_fifo_core.xci]
INFO: [IP_Flow 19-2162] IP 'fxt_async_fifo_core' is locked. Locked reason: Property 'IS_LOCKED' is set to true by the system or user


With my new project (project_12_2):This is what i get from grep locked

 impl_1]$ grep -i locked ../synth_1/runme.log
[sbhutada@pc132 impl_1]$

 

Could this explain anything? Maybe i should do a reset ouput ports for this project_12 as well.

 

Highlighted
Scholar
Scholar
16,333 Views
Registered: ‎12-07-2009

I am experiencing exactly the same with Vivado 2013.3

I have 2 Kintex-7 FPGAs which are somewhat similar and it happened on both, although the part on which it happened was not common to both FPGAs.

On my first FPGA, I was able to solve the same problem by making a new project. On my second FPGA I had other errors along with the multi-driver error. I still tried to make a new project but after solving the other errors, the multi-driver error still remained.

 

I wil try again next week but this is probably a bug.

I plan on upgrading to 2014.1 asap but can't right now (I had problems with the simulation libraries I made for my homemade testbench).

0 Kudos
Highlighted
16,325 Views
Registered: ‎07-26-2013

Hi Sam,

 Based on my analysis there are multpile reasons for getting a false Multi driven net issue:

1) IP is locked. Creating a new project may resolve it.

2) Flatten hierarchy.

3) Try "reset o/p ports" for an IP.

 

Sachin

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
16,312 Views
Registered: ‎07-01-2010

Hi ,

 

I agree with Sachin in few cases.

 

Can anyone of you share the project so that i can check the root cause and get back to you?

 

Regards,

Achutha

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------
0 Kudos
Highlighted
Scholar
Scholar
16,304 Views
Registered: ‎12-07-2009

Hi

 

@Sachin 

Thank you for your reply. I am trying to make a new project.

 

1) My IPs are not locked. I did experience locked IPs too and I just used the IP report tool (Menu > Tools > Report IP status) to solve the problem (probably you don't need to remake the project). It tells you the reason why an IP is locked. In my case I have IPs common to my 2 Kintex-7 and I used them in a shared folder. One is a K7 160T FBG676-2 and the other is a K7 160T FPG484-1, hence the lock. By the way IPs locked are really annoying because I cannot not modify them, although my design is, I think, actually fine. I understand getting a warning for this but I don't see the need for locking the properties...

 

2) Do you mean that flatten the hierarchy can solve the problem ? Or you mean it is the cause ? I use basically all the default settings so it is set to "rebuilt"

 

3) I did it and even removed the dcp files manually. After that, when attempting to implement my FPGA, Vivado processed all the IPs first (which didn't happen last time I remade the project) But it still didn't work (my project was not new). So this time :

- I checked my IPs' status -> OK

- I right clicked on all IPs > Reset runs

- I deleted all dcp files inside the IP folder

- I remade a new project

 

-> I still have the multi-drivers...

 

I'll try to follow your advice for a last attempt.

0 Kudos
Highlighted
Scholar
Scholar
16,299 Views
Registered: ‎12-07-2009

achutha >

We usually do not disclose our sources. The FPGA on which the error occurs is not the most critical though, so if you can guarantee the data will not be disclosed to anyone else, then me may be able to send it.

 

Can you briefly give me some details about the way you deal with the data non-disclosure matters ? Including the files sharing method, who will have access to the data, if it will be erased after a short period etc.


PS: project sources matters have been solved.

0 Kudos
Highlighted
Scholar
Scholar
16,282 Views
Registered: ‎12-07-2009

Changing the hierarchy settings didn't solve the problem.

 

BUT, it helped me understanding what went wrong because the signals involved actually existed in my design, unlike those I had when in "rebuilt" mode which were incomprehensible.

 

I changed my hierarchy setting from "rebuilt" to "none" and then "full", and in "full" setting the multi-driver errors changed and were almost all related to the reset of my Aurora user application (sys_reset_out from Aurora core). Actually this signal had 2 drivers and it is likely to be the cause of my problem on my second FPGA.

 

On the other hand my first FPGA on which I had the same kind of multiple driver problem doesn't have this reset signal problem, and as I said previously, making a new project solved the problem for this one, so it still seems there is something strange with the project / ip files management, at least in Vivado 2013.3.

0 Kudos
Highlighted
Scholar
Scholar
16,037 Views
Registered: ‎12-07-2009

I did not experience too many of these problems recently, it seems it has something to do with input / output port direction mistakes as well as actual multi driven signals, although the error I had did not lead easily to the actual place where the multi driver happened.

 

In a nutshell, this happens because there is actually some problem in the user code, but the message is not explicit enough to be able to find the origin of it. Also as I say above, sometimes cleaning up the project (reset runs) makes it work.

0 Kudos
Highlighted
Visitor
Visitor
15,697 Views
Registered: ‎03-20-2014

Hello,

 

I experienced similar multi-driven nets errors when running synthesis of an IP based design in Vivado 2013.4.  Synthesis produced critical warnings for the multi driven nets which were converted into errors that caused bitstream generation to fail.

I did indeed have a signal that was driven in two diferent processes, but simultaneous writes to this signal from both processes would have been impossible.

 

I changed the synthesis settings to reduce the ammount of optimization and flattening and was able to successfully generate a bitstream.

I enabled the "-keep_eqivalent_registers" and  "-no_lc" options and changed "-flatten_hierachy" to "none" as shown in the screen shot below:

 

I hope this helps other users!

vivado_synthesis_settings.PNG

0 Kudos
Highlighted
Scholar
Scholar
15,687 Views
Registered: ‎12-07-2009

Actually in my case there was a multi-driven net in my design but the warning/error message did not help me too much to find it because it pointed signals inside the FIFO IP whereas the actual multi-driven signal was in my own code and in a different module of my design, although it was actually indirectly connected to the FIFO.

 

Simulation helped me to find it but you may also look for any signal that could be directly or indirectly connected to the IP getting the error.

0 Kudos
Highlighted
Visitor
Visitor
11,611 Views
Registered: ‎07-31-2014

I have a related problem that I haven't seen addressed in the forum.  I have created custom IP with interrupt support.  My selected language is Verilog.  I have made a few mods to insert my interrupt generation logic but I don't think the problem is in what I did since I didn't change any of the logic in question. When I synthesize my IP with S_AXI_INTR.v template created by the create wizard included I get the following critical warnings:

 

[Synth 8-3352] multi-driven net axi_pwdet_v1_0_S_AXI_INTR_inst/intr_ack_all with 1st driver pin 'axi_pwdet_v1_0_S_AXI_INTR_inst/gen_intrall[0].intr_ack_all_reg/Q' ["c:/psu_projects/ise_vivado_conversion/vivado_repository/ip_repo/axi_pwdet_1.0/hdl/axi_pwdet_v1_0_S_AXI_INTR.v":511]
[Synth 8-3352] multi-driven net axi_pwdet_v1_0_S_AXI_INTR_inst/intr_ack_all with 2nd driver pin 'axi_pwdet_v1_0_S_AXI_INTR_inst/gen_intrall[1].intr_ack_all_reg/Q' ["c:/psu_projects/ise_vivado_conversion/vivado_repository/ip_repo/axi_pwdet_1.0/hdl/axi_pwdet_v1_0_S_AXI_INTR.v":511]
[Synth 8-3352] multi-driven net axi_pwdet_v1_0_S_AXI_INTR_inst/intr_all with 1st driver pin 'axi_pwdet_v1_0_S_AXI_INTR_inst/gen_intrall[0].intr_all_reg/Q' ["c:/psu_projects/ise_vivado_conversion/vivado_repository/ip_repo/axi_pwdet_1.0/hdl/axi_pwdet_v1_0_S_AXI_INTR.v":494]
[Synth 8-3352] multi-driven net axi_pwdet_v1_0_S_AXI_INTR_inst/intr_all with 2nd driver pin 'axi_pwdet_v1_0_S_AXI_INTR_inst/gen_intrall[1].intr_all_reg/Q' ["c:/psu_projects/ise_vivado_conversion/vivado_repository/ip_repo/axi_pwdet_1.0/hdl/axi_pwdet_v1_0_S_AXI_INTR.v":494]

 

Looking at the elaborated design I see that there are two flip-flops synthesized (I have two interrupt sources) and that their Q outputs are, indeed, tied together.  

 

Looking at the Verilog, I see:

 

generate
for(i=0; i<= C_NUM_OF_INTR-1; i=i+1)
   begin : gen_intrall

   // detects interrupt in any intr input
   always @ ( posedge S_AXI_ACLK)
   begin
      if ( S_AXI_ARESETN == 1'b0 || intr_ack_all_ff == 1'b1)
      begin
         intr_all <= 1'b0;
      end
      else
         begin
            / / for(j=0; j<= C_NUM_OF_INTR-1; j=j+1)
            if (reg_intr_pending[i])
            begin
               intr_all <= 1'b1;
            end
        end
   end

   // detects intr ack in any reg_intr_ack reg bits
   always @ ( posedge S_AXI_ACLK)
   begin
      if ( S_AXI_ARESETN == 1'b0 || intr_ack_all_ff==1'b1)
         begin
            intr_ack_all <= 1'b0;
         end
      else
      begin
         // for(j=0; j<= C_NUM_OF_INTR-1; j=j+1)
         if (reg_intr_ack[i])
         begin
            intr_ack_all <= 1'b1;
         end
      end
   end

end // gen_intrall
endgenerate

 

which (it seems to me) would generate the logic shown in the schematic (two flip-flops).   I found a similar problem in the s_irq_lvl logic but was able to fix that by moving the s_irq_lvl logic outside the for loop in the generate block.

 

Is this a known problem?  Is there a better version of the S_AIX_INTR.v template that fixes the problem?  Is there a known fix?    Was the code ever checked with a peripheral that had more than one interrupt source?

 

BTW: As with some of the other posts, the peripheral does synthesize w/ errors and implement w/ errors but fails bitstream generation because of the mulitple drivers.


Thanks

Roy

 

 

 

Tags (1)
pwdet_multiple_driver_schematic.png
0 Kudos
Highlighted
Scholar
Scholar
11,603 Views
Registered: ‎12-07-2009

Well, outputs, intr_all and intr_ack_all should be indexed by i or it generates mutli drivers.

 

However, is it me (feeling sleepy right now) or it looks as a weird way of implementing a simple OR ?
If I understand correctly, the code could be simply :

 

always @ ( posedge S_AXI_ACLK)
begin
      if ( S_AXI_ARESETN == 1'b0 || intr_ack_all_ff == 1'b1)
      begin
           intr_all <= 1'b0;
           intr_ack_all <= 1'b0;
      end
      else
      begin
            intr_all <= |reg_intr_pending; // reduction OR
            intr_ack_all <= |reg_intr_ack;
      end
end

0 Kudos
Highlighted
Visitor
Visitor
11,590 Views
Registered: ‎07-31-2014

Yep, I agree.  Both intr_all and int_ack_all would need to be indexed to avoid inferrng multiple drivers...but they're not, and they are defined as single bit variables in the template.

 

reg intr_all;
reg intr_ack_all;

 

So, I believe this is an error in the template, along with a similar error in the logic for generating s_irk_lvl.  This single bit output was also enclosed in a for loop which imferred multiple flip-flops and hooked them together.  The solution in that case was to terminate the for loop before the IRQ generation block.

 

re: your solution and the function being a simple reduction OR, I agree.  I changed the code in pretty much the same way other than I preserved the structure of the template w/ two independent always blocks instead of the one you used in your code.

 

BTW:  I believe that the code provided in the template would synthesize correctly as long as there was only a single interrupt source.  My code (hopefully) handles two interrupt sources.

 

Thanks

Roy

0 Kudos