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

Spartan 3 TRISTATE2LOGIC XST : Urgent!

Status
Not open for further replies.
C

cmos babe

Full Member level 4
Joined
Jan 15, 2005
Messages
209
Helped
11
Reputation
22
Reaction score
0
Trophy points
1,296
Location
Dubai
Activity points
1,897
xst:2042

Hi all, I need your help.
The problem I'm struggling with is as follows:
I have a simple datapath design that consists of an ALU,a Register File,IR,PC..etc
but there's this module that's causing the problem which is the SWITCH .. According to the design , the switch is used to interface with the RAM's bidirectional databus , so it contains of an input port,an output port, and a bidirectional part connected to RAM.

Every part of the design was synthesized alright without any problems. The problems started when I wanted to create the toplevel design that will include all these components. In begining, I created an INOUT signal in the toplevel's entity so i connect the bidirectional signal of the switch to it, the file gets synthesized but I get a warning of that the tristates in the switch get replaced by pullups! :lol:

WARNING:Xst:2042 - Unit bidire: 32 internal tristates are replaced by logic (pull-up yes): dbus_a<0>, dbus_a<10>, dbus_a<11>, dbus_a<12>, dbus_a<13>, dbus_a<14>, dbus_a<15>, dbus_a<16>, dbus_a<17>, dbus_a<18>, dbus_a<19>, dbus_a<1>, dbus_a<20>, dbus_a<21>, dbus_a<22>, dbus_a<23>, dbus_a<24>, dbus_a<25>, dbus_a<26>, dbus_a<27>, dbus_a<28>, dbus_a<29>, dbus_a<2>, dbus_a<30>, dbus_a<31>, dbus_a<3>, dbus_a<4>, dbus_a<5>, dbus_a<6>, dbus_a<7>, dbus_a<8>, dbus_a<9>.
Click to expand...

Then after trying million things ,I went to xilinx.com and found this :
For Spartan-3/-3E and Virtex-4 designs, 3-states are not replaced by logic. What are the reasons this might occur?


Solution 1:
There are 4 situations where XST is not able to replace a 3-state by logic:

1. The 3-state is connected to a black box.
2. The 3-state is connected to the output of a block, and the hierarchy of the block is preserved.
3. The 3-state is connected to a top-level output.
4. The "tristate2logic" constraint is set to "no" on the block where 3-states are placed or on the signals to which 3-states are connected.
Click to expand...
But like you see in the warning , the tristates get converted to logic, but this logic is pullups! situations 1 and 4 aren't what's causing the problem.. Does it seem like #3 is what's causing the warning? I put the RAM unit inside the toplevel and connected it to the switch and still got warnings and errors about "multisource" .. Anyways , I hope you understand my problem..
 

warning:xst:2042

The purpose of 3-state buffers is to allow tying OUTPUTs together. In the case of a bidirectional bus, the second OUTPUT comes from offchip.

It serves no purpose to connect a 3-state output to inputs only (no other outputs). You may as well have the buffer always enabled, or eliminated. The pullups are inserted to ensure internal signals are digital. True high-impedance (tristate) outputs can turn some internal transistors into power hungry analog devices.

The principle is "don't disable an input with a 3-state buffer". Gate it (with AND or OR) to produce a digital idle state, or use a register to selectively capture it.

If what you are trying to do is interface to a bidirectional bus, here's an example of using INOUT ports and Z-states...

Code: 
-- DATABUS is an INOUT port

-- Select a register to read using appropriate read-enable signal
-- NOTE:  The output buffers of the external data supplier must also be
--   driven into the Z state.
-- The synthesis tool will generate 3-state buffers.
DATABUS <= REG1_OUT when REG1_READ_EN = '1' else "ZZZZZZZZ";
DATABUS <= REG2_OUT when REG2_READ_EN = '1' else "ZZZZZZZZ";

-- You can use DATABUS directly as input.
-- The following will set DATABUS_ZERO to "true" whenever DATABUS is 0,
--   regardless of where the zero came from (e.g., it can come from REG1_OUT).

DATABUS_ZERO <= '1' when DATABUS = X"00" else '0';

-- Update registers using appropriate write-enable signal.
-- Use registers to "capture" input data.

U_REG1: process (clk)
begin
   if rising_edge(clk) then
      if REG1_WRITE_EN = '1' then
         REG1_OUT <= DATABUS;
      end if;
   end if;
end process;

U_REG2: process (clk)
begin
   if rising_edge(clk) then
      if REG2_WRITE_EN = '1' then
         REG2_OUT <= DATABUS;
      end if;
   end if;
end process;
 

    C

    cmos babe

    Points: 2
    Helpful Answer Positive Rating
xilinx xst:2042

Yes tkbits ,I'm using the tristates so that the datapath can communicate with the memory. The output of the datapath are data from the register file , and inputs are instructions and data from memory. So, tristate is needed because two ouputs are connected to same bus (memory output, datapath output) ...

I used the following code :

ENTITY bidire IS
PORT( en: IN std_ulogic;
dbus_c: INOUT std_logic_vector(31 DOWNTO 0);
dbus_a: OUT std_logic_vector(31 DOWNTO 0);
dbus_b: in std_logic_vector(31 DOWNTO 0));

--attribute tristate2logic: string;
--attribute tristate2logic of bidire: entity is "yes";
END bidire;
ARCHITECTURE behv OF bidire IS
BEGIN
PROCESS(en,dbus_b,dbus_c)
BEGIN

IF ( en = '1' ) THEN
dbus_a <= dbus_c;
dbus_c <= (OTHERS => 'Z');
ELSE
dbus_c <= dbus_b;
dbus_a <= (OTHERS => 'Z');

END IF;
END PROCESS ;
END behv;
Click to expand...

dbus_a and dbus_b should be connected to datapath inputs/outputs, dbus_c is connected to RAM data lines. Note that I will use block ram not offchip ram.


EDIT: <==========

I Found out what's causing the problem ! it's this line :
dbus_a <= (OTHERS => 'Z');

Which is unnecessary! :oops: :oops: Thanks for help tkbits
 

internal tristates are replaced by logic

Allow me to rewrite this so that I can "see the hardware". It might not be valid VHDL.
Code: 
ENTITY bidire IS 
PORT( en: IN std_ulogic; 
dbus_c: INOUT std_logic_vector(31 DOWNTO 0); 
dbus_a: OUT std_logic_vector(31 DOWNTO 0); 
dbus_b: in std_logic_vector(31 DOWNTO 0)); 
END bidire; 

ARCHITECTURE behv OF bidire IS 
BEGIN 
  dbus_a <= dbus_c when en = '1' else (others => 'Z');
  dbus_c <= dbus_b when en = '0' else (others => 'Z');
END behv;
Click to expand...
I see no obvious problems here, so what I'm guessing is that at higher levels, dbus_a connects only to inputs, no outputs. If dbus_a will be a signal that has other outputs attached to it, then you will need to add a second output, at the higher level, to make the warnings go away.

If dbus_a will always be the sole output for each instance of this signal, then eliminate the 'Z' state for dbus_a to make the warning go away.

If this module will be used both ways, with dbus_a either being the sole output of a signal, or tied with other output signals, then you will just have to live with the warnings.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top