inout to input ports connections

[xtcx]

ok fine, so when you connected directly the "gdata" inout from DSP to PLB inout port through direct mapping, you received error, "Signal connected to Multiple buffer" while synthesizing, Am I right?.

---------- Post added at 17:52 ---------- Previous post was at 17:51 ----------

Later when you connected through an FSM using enable control, you got 2 clk delay between switching to input and output, right?....

So these two are you problem, have we cornered the case?.

---------- Post added at 18:05 ---------- Previous post was at 17:52 ----------

Well, now that what I understand from this is you received error when you directly mapped the gdata inout from DSP to PLB inout "Signal connected to multiple buffer".
Then you tried using enable logic, it solves the error, but however inserts 2 clk delay.

So this is your problem?....

 

[itmr]

ok fine, so when you connected directly the "gdata" inout from DSP to PLB inout port through direct mapping, you received error, "Signal connected to Multiple buffer" while synthesizing, Am I right?.

---------- Post added at 17:52 ---------- Previous post was at 17:51 ----------

Later when you connected through an FSM using enable control, you got 2 clk delay between switching to input and output, right?....

So these two are you problem, have we cornered the case?.

---------- Post added at 18:05 ---------- Previous post was at 17:52 ----------

Well, now that what I understand from this is you received error when you directly mapped the gdata inout from DSP to PLB inout "Signal connected to multiple buffer".
Then you tried using enable logic, it solves the error, but however inserts 2 clk delay.

So this is your problem?....

yes you right - i got the error when direct mapping and when i solve the error with the enable 2 clock delay inserts.
now i plan to have just 2 clocks delay and got 4 probably...
thats my problem

---------- Post added at 09:23 ---------- Previous post was at 09:19 ----------

Please be clear. Are you trying to use the inout port internally or is it to connect to an external device?

if its internally - STOP DOING IT NOW. you should have separate in and out ports.

There is no requirement to use a state machine on an inout, you just handle the data as you need. If you need a state machine then ok. You only need to drive 'z' when opposite end drives its enable signal (which will be an input to this block).

hi
i am sorry but i dont understans what you mean in " handle the data as you need " would you please explain it - i mean how can i handle the data without any enable?

 

[xtcx]

i am sorry but i dont understans what you mean in " handle the data as you need " would you please explain it - i mean how can i handle the data without any enable?

I believe he means to say that you don't really need a state machine logic just to handle the enable, though you could use that, but why wasting on tat while you can so with some simple if-else statements.

 

[FvM]

In my view, describing the multiple driver enable problem as a multiplexer can help to clarify the requirements for the internal enable signals. I already mentioned that you may want to control the multiplexer completely asynchronously, deriving the enable combinationally from processor address and read/write signals.

As also discussed, the enable timing is only a (minor) part of the problem. The data source will be still a synchronous process and it's response time must be counted in terms of clock cycles.

 

[xtcx]

What control signal do you revcieve from DSP for the inout enable?. How do you enable and what is the net name of the control pin for the write\read mode for the gdata inout pin?.

logic like this for a simple handsoff

IF( io_en = '0') THEN
   gdata  <= "ZZZZZZZZ";
   out_sig<= gdata;
ELSE
   gdata   <= in_sig; 
   out_sig <= gdata;
END IF;

This is a code submitted by you I guess, where do you get this io_en?. From DSP or did you generate through some address decoding from DSP?.

You are properly releasing the bus using enable, however I beleive only the master in system will be able to take control. And between that, you did not tell what type of application this is.

I think this logic is much more straight forwarded in using that FSM or other glue logics.

---------- Post added at 13:54 ---------- Previous post was at 13:46 ----------

In my view, describing the multiple driver enable problem as a multiplexer can help to clarify the requirements for the internal enable signals. I already mentioned that you may want to control the multiplexer completely asynchronously, deriving the enable combinationally from processor address and read/write signals.

As also discussed, the enable timing is only a (minor) part of the problem. The data source will be still a synchronous process and it's response time must be counted in terms of clock cycles.

What do you mean to say by asynchronously?. Much like a combo process without a synchronous clock driving it. So when there is no clk, selection(enable) happens instantly without much delay (as with clock based) for inout tristate. But I believe doing like this asynchronously could sometime hit the timing of datapath esp when latching into inout bus, hence spoiling the data at times. Correct me if wrong....

---------- Post added at 13:55 ---------- Previous post was at 13:54 ----------

but this method solves his problem too :wink:

 

[itmr]

What control signal do you revcieve from DSP for the inout enable?. How do you enable and what is the net name of the control pin for the write\read mode for the gdata inout pin?.

logic like this for a simple handsoff

IF( io_en = '0') THEN
   gdata  <= "ZZZZZZZZ";
   out_sig<= gdata;
ELSE
   gdata   <= in_sig; 
   out_sig <= gdata;
END IF;

This is a code submitted by you I guess, where do you get this io_en?. From DSP or did you generate through some address decoding from DSP?.

You are properly releasing the bus using enable, however I beleive only the master in system will be able to take control. And between that, you did not tell what type of application this is.

I think this logic is much more straight forwarded in using that FSM or other glue logics.


i got from the DSP rd_en and wr_en and from these signals i generate the oe

if rd_en = '1' then
oe <='1'

if wr_en='1' then
oe<='0'

that not seems to make problem because i generate the oe in the top and pass it to all the ip as sensitive FSM signal and then the ip fsm behave accordingly

i must use the oe as synchronize signal - based on system demand.

my main problem starts from the need of feed the inout port with 'z' when use as input.
i will try to explain better - while write - i need to sample the gdata into temporary reg , put 'z' in the gdata - and then in the next clock i need to pass the temporary register to the ip local data bus.
and while read data i need to pass the data from the ip local data bus to temporary register and in the next clock i need to upload the temporary register to the gdata




when IDLE =>


if wr_en ='1' then --DETECT WRITE
MAIN_FSM<= RD_WR_MODE;
oe <='0';
temp_data_out <= GLOBAL_DATA_BUS;
GLOBAL_DATA_BUS<= (others =>'Z');
end if;

if rd_en ='1' then --DETECT READ
MAIN_FSM<= RD_WR_MODE;
oe <='1';
end if;


if local_rd_en ='0' and local_wr_en ='0' then

local_data_direction_en <='Z';
end if;



when RD_WR_MODE =>

if oe ='0' then -- WRITE MODE

CASE ( GLOBAL_ADRESS_BUS (23 downto 12)) IS


when x"800" => mem_CS <= '1';

mem_ip_offset _addr <= GLOBAL_ADRESS_BUS(15 DOWNTO 0);
mem_ip_local_data <= temp_data_out;

.
.
.

else -- local_data_direction_en = 1 -- READ MODE


CASE ( GLOBAL_ADRESS_BUS (23 downto 12 )) IS


when x"800" => mem_CS <= '1';

mem_ip_offset _addr <= GLOBAL_ADRESS_BUS(15 DOWNTO 0);
temp_data_in <= mem_ip_local_data;

MAIN_FSM<= UPLOAD_READEN_TO_GLOBAL_DATA_BUS;






.
.
end case.

when UPLOAD_READEN_TO_GLOBAL_DATA_BUS =>
GLOBAL_DATA_BUS <= temp_data_in;


and case;

offcourse i need to add delay state to enable the ip to valid the data and then samole it im the top level but i hope that this code will demonstrate my problem well..

 

[FvM]

i must use the oe as synchronize signal - based on system demand

Which demand?
You apparently decided to translate the DSP bus to a synchronous local bus. This would be strictly necessary, if the local bus needs to be shared with FPGA internal data transfers, which hasn't been mentioned yet. Otherwise, the bus can be kept asynchronous up to the interface of the individual IPs.

 

[itmr]

Which demand?
You apparently decided to translate the DSP bus to a synchronous local bus. This would be strictly necessary, if the local bus needs to be shared with FPGA internal data transfers, which hasn't been mentioned yet. Otherwise, the bus can be kept asynchronous up to the interface of the individual IPs.

its system demand to synchronize the rd_en and the _w_en and as well to synchronize the oe.
but i will try to leave the oe doesnt synchronize with the system and maybe start the ips processes earlier and valid the to the gdata earlier...i will think about it
thank you

 

[itmr]

its system demand to synchronize the rd_en and the _w_en and as well to synchronize the oe.
but i will try to leave the oe doesnt synchronize with the system and maybe start the ips processes earlier and valid the to the gdata earlier...i will think about it
thank you

thank u all i solved the problem - it looks good - synthesis and simulation looks good to
i will explain later and attach my code

 

[xtcx]

Oh...that's Great

Share your results\method. It might help others when viewing your thread for solution.

Cheers

 

[itmr]

Hi all
One of tbe solution that i found is to direct the data throught tristate buffers ( others => 'z')
I will attach the code later