I am able to build the code in modelsim but, when simulation getting below error:
addr_x, driven via port connection, is multiply driven (44) Line :49
addr_f, driven via port connection, is multiply driven (46) Line :49
s_ready_x, driven via port connection, is multiply driven (44) Line :49
s_ready_f, driven via port connection, is multiply driven (46) Line :49
How can I resolve this? (system verilog)
There is no simple* fix: You have to change your design. You might even have to go "back to the drawing board" and fundamentally change your design.
In each of the ctrlpath.., modules you output an address. Thus you drive the same net from different outputs. You somehow have to distinguish which of those you are really going to need. Thus you need to add a multiplexer which 'knows' which on to pick.
The "multiple driven" error is a recurring question appearing on Stack Overflow and Electrical engineering. What you have done is connecting multiple output ports together. In electrical engineering we call this 'shorting outputs together'. The term shorting is important as it is effectively a short circuit. This is the equivalent circuit:
Some outputs will be high and others are low. The ones which are high will try to drive the output high opening a current path from the VCC to the output pin. The ones which are low will try to drive the output low. They open a current path from the output to ground. Together they form a short circuit between your VCC and ground.
*Do not think you can easily solve this with tri-state drivers. Theoretical it may seem possible, practically you really, really don't want that.
Here is one of the messages from VCS compilation:
Error-[ICSD] Illegal combination of drivers
design.sv, 38
Illegal combination of structural drivers.
Variable "s_ready_x" is driven by multiple structural drivers.
This variable is declared at
"design.sv", 38: logic s_ready_x;
The first driver is at "design.sv", 50: ctrlpatho c( .clk (clk), .reset
(reset), .wr_done_f (wr_done_f), .wr_done_x (wr_done_x), .addr_x
(addr_x), .addr_f (addr_f), .m_valid_y (m_valid_y), .c ...
The second driver is at "design.sv", 45: ctrlpathx x( .clk (clk), .reset
(reset), .s_ready_x (s_ready_x), .addr_x (addr_x), .wr_done_x
(wr_done_x), .wr_en_x (wr_en_x), .s_valid_x (s_valid_x));
it just propagates the issue to the top-level module, but gives correct locations of the drivers.
The problem is, that both ctrlpathf and ctrlpatho drive the same signal with output ports. The rule of thumb is:
you cannot drive the same variable with multiple drivers.
System verilog just adds this requirement to the standard and it gets checked for the specific system verilog blocks.
To fix it
you need to review your program, in case you just made a mistake.
verilog allows you to multiply drive net types and defines rules for the results. If you really want to have multiple drivers, you would need to declare those ports as wires or similar and change the code to reflect it. They can be multiply driven with the assign statements.
Related
I am attempting to use the IP packaging tools in Xilinx Vivado to create a co-processor with an AXI-Lite interface and utilize it in a Zynq SoC design for my Digital Systems Engineering class. The co-processor is a GCD calculator that we have already developed as part of a previous assignment. I followed the instructor's directions to create an IP out of the GCD calculator, and we loosely followed Tutorial 4A from the PDF located here to create the AXI interface (the I/O declarations are obviously modified to accomodate the GCD calculator). I have a data bus called 'data' running from the AXI IP and the GCD IP to send values to the calculator. However, when I attempt to Synthesize the design, I get an the following error:
[Synth 8-685] variable 'data' should not be used in output port connection'
The error directs to the line of my AXI bus interface instantiation where my data port is defined.
I've been searching online for a solution to this error for hours, but not even the Xilinx website, nor the Xilinx documents that have been made available to us, have any information regarding this error, and I have not been able to find any accounts from anyone experiencing the same error.
I emailed the professor to see if he has any ideas, but he probably won't be awake for another six hours and the assignment is due today (tomorrow?).
Has anyone heard of this error, or have any idea of how to correct it?
Here's a portion of code that contains the error's source:
// Instantiation of Axi Buss Interface S00_AXI
myip_v1.0_0_S00_AVI # (
.C_S_AXI_DATA_WIDTH(C_S00_AXI_DATA_WIDTH),
.C_S_AXI_ADDR_WIDTH(C_S00_AXI_ADDR_WIDTH)
) myip_v1_0_S00_AXI_inst (
.done_async(done_async),
.go(go),
.data(data), // The error points to this line
.S_AXI_ACLK(s00_axi_aclk),
... // all remaining ports were generated by the IP tools
);
Thanks,
-Andrew
It looks to me like you are trying to drive a variable from the output of an instantiated module. In Verilog you cannot drive a variable from an instantiated module. This is illegal in Verilog (though it is not in SystemVerilog):
reg OP; -- this is a variable
SOME_MODULE MODULE_INST (.IP(IP), .OP(OP));
whereas this is not illegal:
wire OP; -- this is a net
SOME_MODULE MODULE_INST (.IP(IP), .OP(OP));
The logic that I am using is set up to expect a diff-pair clock port. However, for one specific application, I can only input a single ended clock (due to hardware limitation). Modifying the logic to accept single ended clock is not an option as there are many files and lines of code involved. Is there a way I can input a single ended port and somehow feed it to diff-pair ports of modules? So for example in my top level I want to have a port like this:
input single_ended_clk
And I want to feed this to a module that takes the following ports:
input diff_pair_clk_p;
input diff_pair_clk_n;
A very naïve approach would be to do this:
mymodule m_i (
.diff_pair_clk_p(single_ended_clk),
.diff_pair_clk_n(~single_ended_clk),
);
but I don't think this is the proper way to do this.
Most chip designs, either ASICs or FPGAs explicitly instantiate clock buffers rather than infer them. In the FPGA world, the synthesis engines usually aren't smart enough to recognize a clock and hook the buffer outputs to the dedicated clock routing resources. So you really probably need to explicitly instantiate a clock buffer.
Now as to the case where sometimes you want a single ended clock buffer and sometimes you want a double edge clock buffer. While you can use generate statements referencing a parameter to decide which buffer to instantiate, you can't control the port list of the chip this way. You can keep the clock buffer inside the lower level module.
I would not recommend recreating a differential signal inside the chip. There are several problems with this. First, a differential clock buffer expects to be connected to external pins, not internally buffered signals. Secondly, there is a timing mismatch between the positive and negative clock which could create glitches on your resulting clock post-buffer which would make a real mess of your design.
Instead, keep both _n and _p inputs to your sub-module, and use a generate to select the type of clock buffer to be instantiated. In the case of a single ended clock, the _n input is left unconnected and only the _p input is used.
Here's an example for a Xilinx FPGA. The buffer primatives will be named differently in other types of FPGAs or ASIC libraries.
module clock_buffer (
input pin_clk_p,
input pin_clk_n,
output clk_int
);
parameter DIFF = 0;
generate
if (DIFF = 1)
clk_buf IBUFGDS(
.I (pin_clk_p),
.IB (pin_clk_n),
.O (clk_int)
);
else
clk_buf IBUFG(
.I (pin_clk_p),
.O (clk_int)
);
endgenerate
endmodule
There will be a phase offset, it might be within tolerance. It is hard to say without knowing timing requirements for the differential paired clock and single clock, how the clock tree is being handled, timing of buffers and inverters. You may be able to handle this from within the synthesizer by identifying the clocks and there relation. To do this, assign the clocks individually at the appropriate hierarchy level, maybe its own sub-module. diff_pair_clk_p and single_ended_clk are functionally the same, but they should be separated for load balancing and clock-tree balancing.
assign diff_pair_clk_p = single_ended_clk;
assign diff_pair_clk_n = ~single_ended_clk;
Sometime there are predefined modules that are part of the standard/macro cell library which are intend for solving or simplifying specific design challenges. Instantiate these modules where needed, a dont_touch pragma may be needed. Specifically look for cells described as symmetrical buffers and inverters. You may still need to give additional guidance to the synthesizer.
How are signals/ports of peripheral in a microcontroller connected to the PAD ??
Say, my SoC has 'n' signals. then these 'n' signals will be connected to pad and then reach the top-level. How is this connection done ?
Pad connections are made by HDL wires as with any other connection. Those wires would traverse hierarchical boundaries until they reach the pads which are instantiated cells like any other*. Some pads require more than one connection (for output signals, input signals, output enables and/or direction controls). Between your peripheral and the pad there may be additional SoC logic for pad functional multiplexing, test mode multiplexing, debug and/or jtag/scan test structures.
A typical (simplified) hierarchy may look like:
top
core
processor
system_logic
peripheral_1
peripheral_N
subsystem_M
io
pad_X
funcmux_X
testmux_X
jtag_X
pad_cell_X
pad_Y
pad_Y
A peripheral peripheral_1 may be hooked to pad_X, requiring 1 wire for a straight output or input pad, or 2 wires for a tristate-able output pad, or 3 for a bidirectional pad, or more for more complex electrical configurations of the pad. That bundle of N wires would travel up the Verilog hierarchy from peripheral_1 to top and down to the required pad logic, via any additional logic controlling pad multiplexing or test. The hierarchy above is just one example.
In an SoC, that's a lot of wires in total, and is very error-prone to do manually. An automated EDA IP assembly tool can be used.
*In standard-cell SoC design flows, the pad is just another cell.
The exact arrangement may be dictated by your cell library and/or physical design flow.
Referring to my earlier question here, I've been utilizing tri-states to work with a common bus. I still appear to have some implementation issues.
The tri-states use this type of code:
assign io [width-1:0] = (re)?rd_out [width-1:0]:{width{1'bz}};
Synthesis and translation goes well. No warnings or errors I wasn't expecting (I was expecting some since this is only a trial run and most of the components don't do anything and will hence be left unconnected). But when I actually try to implement it, all busses (there are three) output a 1111111111111111, or a -1, as converted by my binary to BCD converter. I checked if it really the case by instructing the control matrix to halt if the instruction received on the bus is -1, and it did halt.
The warning I receive for the tri-state being converted to logic is:
Xst:2040 - Unit Neptune_I: 16 multi-source signals are replaced by logic (pull-up yes)
Xst:2042 - Unit alu: 16 internal tristates are replaced by logic (pull-up yes):
And so on. Neptune_I is the top module, and I believe the multi-source signals it's referring to are the busses.
I have a doubt whether the pull-up yes is the root of this problem. Is it simply pulling everything up, causing it to be -1 all the time? But this does not make sense to me, because when the tri-state is activated, the signal should be controlled by whatever entity it is supposed to be controlled by.
I would like to take the time to replace the code with logic instead of the tri-states, but I'm unsure how to proceed.
Any help would be appreciated.
Are these signals going off-chip? Or are they internal to your FPGA? If the answer is the latter, you need to change your code. Modern FPGAs (like Spartan 6) no longer support internal tri-state buffers. They only exist for off-chip signals.
You need to write all of you internal code to avoid tri-state buffers. Create dedicated paths between components, no bidirectional interfaces.
I've been coding a 16-bit RISC microprocessor in Verilog, and I've hit yet another hurdle. After the code writing task was over, I tried to synthesize it. Found a couple of accidental mistakes and I fixed them. Then boom, massive error.
The design comprises of four 16-bit common buses. For some reason, I'm getting a multiple driver error for these buses from the synthesis tool.
The architecture of the computer is inspired by and is almost exactly the same as the Magic-1 by Bill Buzzbee, excluding the Page Table mechanism. Here's Bill's schematics PDF: Click Here. Scroll down to page 7 for the architecture.
The control matrix is responsible for handling when the buses and driven, and I am absolutely sure that there is only one driver for each bus at any given instance. I was wondering whether this could be the problem, since the synthesis tool probably doesn't know this.
Tri-state statements enable writing to a bus, for example:
assign io [width-1:0] = (re)?rd_out [width-1:0]:0; // Assign IO Port the value of memory at address add if re is true.
EDIT: I forgot to mention, the io port is bidirectional (inout) and is simply connected to the bus. This piece of code is from the RAM, single port. All other registers other than the RAM have separate input and output ports.
The control matrix updates a 30-bit state every negative edge, for example:
state [29:0] <= 30'b100000000010000000000000100000; // Initiate RAM Read, Read ALU, Write PC, Update Instruction Register (ins_reg).
The control matrix is rather small, since I only coded one instruction to test out the design before I spent time on coding the rest.
Unfortunately, it's illogical to copy-paste the entire code over here.
I've been pondering over this for quite a few days now, and pointing me over to the right direction would be much appreciated.
When re is low, the assign statement should be floating (driving Zs).
// enable ? driving : floating
assign io [width-1:0] = (re) ? rd_out [width-1:0] : {width{1'bz}};
If it is driving any other value then the synthesizer will treat is as a mux and not a tri-state. This is where the conflicting driver message come from.