Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Signal unconnected in a block

Status
Not open for further replies.
G

guetguet

Member level 1
Joined
Jul 19, 2012
Messages
41
Helped
3
Reputation
6
Reaction score
3
Trophy points
1,288
Activity points
1,578
Hello everyone !

I have a serious problem for 2 hours ... I think the solution must be easy but I don't what to do. So the XST tool shows me a lot of warning. Several of them is due to a signal which is not connected according the XST Tool. But in my implementation, the signals which are unconnected according the XST tool are connected. Thus I don't understand why the XST detects those signals as not connected. Bellow is a part of the warnings and a part of my VHDL code included some signals detected as not connected :

WARNING:Xst:2677 - Node <VphaseAccumulator2_31> of sequential type is unconnected in block <SweepJammingDDSInst>.
WARNING:Xst:2677 - Node <invROM1Doutb> of sequential type is unconnected in block <SweepJammingDDSInst>.
WARNING:Xst:2677 - Node <VphaseAccumulator3_31> of sequential type is unconnected in block <SweepJammingDDSInst>.
WARNING:Xst:2677 - Node <VphaseAccumulator4_31> of sequential type is unconnected in block <SweepJammingDDSInst>.
WARNING:Xst:2677 - Node <invROM2Douta> of sequential type is unconnected in block <SweepJammingDDSInst>.
WARNING:Xst:2677 - Node <invROM2Doutb> of sequential type is unconnected in block <SweepJammingDDSInst>.
WARNING:Xst:2677 - Node <invROM1DoutbS1> of sequential type is unconnected in block <SweepJammingDDSInst>.
WARNING:Xst:2677 - Node <VphaseAccumulator_31> of sequential type is unconnected in block <SweepJammingDDSInst>.
Click to expand...

Code: 
signal VphaseAccumulator : std_logic_vector(31 downto 0);
signal VphaseAccumulator2 : std_logic_vector(31 downto 0);
signal VphaseAccumulator3 : std_logic_vector(31 downto 0);
signal VphaseAccumulator4 : std_logic_vector(31 downto 0);
signal invROM1Doutb : STD_LOGIC;
signal invROM2Douta : STD_LOGIC;
signal invROM2Doutb : STD_LOGIC;
signal invROM1DoutaS1 : STD_LOGIC;
signal invROM1DoutbS1 : STD_LOGIC;
....
....
process (RAZ, Clock250M)
begin
		
	if rising_edge(Clock250M) then
		if RAZAll = '1' then
			VphaseAccumulator4 <= (others => '0');
			cycle <= '1';
	
		elsif enable = '1' and S_JammingInProgress = '1' then				
			VphaseAccumulator <= VphaseAccumulator4 + step;
			if VphaseAccumulator(30) = '0' then
				adrROMA1 <= VphaseAccumulator(29 downto 15);
			else
				adrROMA1 <= "111111111111111" - (VphaseAccumulator(29 downto 15));
			end if;
			invROM1Douta <= VphaseAccumulator(31);
		
			VphaseAccumulator2 <= VphaseAccumulator4 + stepX2;			
			if VphaseAccumulator2(30) = '0' then
				adrROMB1 <= VphaseAccumulator2(29 downto 15);
			else
				adrROMB1 <= "111111111111111" - (VphaseAccumulator2(29 downto 15));
			end if;
			invROM1Doutb <= VphaseAccumulator2(31);

Could anyone hyelp me ?

Thanks !
 

You are only showing part of one process. Where do the signals from this process go? Is this a component that gets instantiated in a higher level module? I only see VphaseAccumulator4 set to zero, I don't see it ever getting any other value-that could cause signals to be trimmed.

Just not enough information here. But I suspect you are losing signals that, due to your math, are always zero or always one.
 

Yes this is a component which is instantiated in a higher level module. The signals VphaseAccumulator* and invROM*Dout* are not used in an other process. They are used to store values that are used during the next clock tick. I am confused, XST show a warning that tells "<VphaseAccumulator2_31> of sequential type is unconnected in block <SweepJammingDDSInst>." but in my part of implementation above, the signal VphaseAccumulator2(31) is connected to invROM1Doutb :
invROM1Doutb <= VphaseAccumulator2(31);
Click to expand...
Moreover the XST tool shows the warning "<VphaseAccumulator4_31> of sequential type is unconnected in block <SweepJammingDDSInst>." instead of the signal must be connected somewhere thanks to this instruction " VphaseAccumulator4 <= (others => '0');", isn't it ?

Tell me if you need further information (You can find the code of my process as a attachment) View attachment process.txt.
 

This is getting a bit confusing. What is signal RAZAll, and what drives it? What is stepx2?
 

Yes I know that is hard to understand without explanation. First, I made a mistake : RAZAll must be in the sensitive list instead of the signal RAZ. RAZall is just a reset signal triggered by a 125-Mhz-clocked process (in the same module than the process in the attached file). step and stepx2 are also updated inside the 125-Mhz clocked process. stepx2 is just equal to step multiply by 2. I created this signal to limit the multiplication and the addition. In my mind, I think that a multiplication is slower than an addition. It's for this reason that I have those instructions :
VphaseAccumulator2 <= VphaseAccumulator4 + stepX2;
VphaseAccumulator3 <= VphaseAccumulator4 + stepX2 + step;
Click to expand...

instead of

VphaseAccumulator2 <= VphaseAccumulator4 + step * 2;
VphaseAccumulator3 <= VphaseAccumulator4 + step * 3;
Click to expand...

In my process I have 6 stages of pipeline to run at 250 Mhz
 

This usually occurs when internal signals have no affect on an output at the top level. Without them having an effect on the output, why are they even there?
 

First, I made a mistake : RAZAll must be in the sensitive list instead of the signal RAZ.
Click to expand...
Neither of these, at least for the snippet shown in your inital post. All code under if rising_edge(Clock250M) is sensitive to Clock250M only and doesn't need other entries. They are only needed for inputs to asynchronous code.

The problem with code snippets is that we can only comment the code within. But generally, a synthesis tool is pretty good in determining which signals are unused in a design. The other question is, if the warnings are showing actual design problems (e.g. a signal is expected to take different values at some time, but it doesn't) or it's just regular operation.
 

The signals shown as unconnected signals are juste used to store intermediate result wich will be used during the next clock ticks. So, not directly, this signals are an affect on the output signals on the top-levem module because the output signals are updated using several signals which are updated using others signals ... which are updated using the signal shown as unconnected.

Someone has an idea ?

Thanks a lot for all your answers.
 

guetguet said:
The signals shown as unconnected signals are juste used to store intermediate result wich will be used during the next clock ticks. So, not directly, this signals are an affect on the output signals on the top-levem module because the output signals are updated using several signals which are updated using others signals ... which are updated using the signal shown as unconnected.

Someone has an idea ?

Thanks a lot for all your answers.
Click to expand...

Aha!. The synthesis tool has probably found a more compact way of implementing your code, so it got rid of unnecessary signals. You should probably perform a post-synthesis simulation to verify that your output is what you expected. If so, then don't worry about the warnings.
 
guetguet said:
The signals shown as unconnected signals are juste used to store intermediate result wich will be used during the next clock ticks. So, not directly, this signals are an affect on the output signals on the top-levem module because the output signals are updated using several signals which are updated using others signals ... which are updated using the signal shown as unconnected.

Someone has an idea ?

Thanks a lot for all your answers.
Click to expand...

Im with FvM. Without the full code, we have no idea.
 

The signals shown as unconnected signals are juste used to store intermediate result wich will be used during the next clock ticks. So, not directly, this signals are an affect on the output signals on the top-levem module because the output signals are updated using several signals which are updated using others signals ... which are updated using the signal shown as unconnected.
Click to expand...
Sounds like they are just pipline registers. You usually don't get unconnect warnings for pipeline registers that are carrying actual data.

I fear, the discussion still suffers from the snippet problem.
 
Please, find as an attachment a file that contains the entire architecture and its entity. I added several commentaries so that it is easier to understand
View attachment sweep.txt
 

having a quick look over the code, the output appears to only be a load of counters, that are enabled from 1 bit of the phase accumulators.

What I suggest is creating a good testbench. Test this with a set of known test vectors, then compile the design and compare it when the same set of test vectors. If the two tests match, then wheres the problem (other than the superfluous code)?
 
I compiled the design in Altera Quartus and all VphaseAccumulator2 bits are synthesized in gate level. The only synthesis warnings are related to several unconnected in_reg[] bits.
 
thanks, so Why XST tool recognises the signal above as unconnected signals ?
 
  • Like
Reactions: barry

    barry

    barry

    Points: 2
    Helpful Answer Positive Rating
Best you can do right now is: 1) stop worrying about warning A in Quartus vs warning B in ISE. 2) start simulating pronto, to see if your design is functioning the way it should. Because despite this sort of warning there's a fair chance it just works. Assuming ofcourse you didn't make any mistakes. ;)

So best use of time right now would seem to be making a testbench...
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top