![]() |
|
|
|
#1 |
|
Hi,
I have a question concerning the VHDL description of a bidirectional bus. This bus comes from (goes to) an SRAM which I try to simulate with a corresponding VHDL model. Now I have an INOUT pin at my SRAM-Controller : Sram_data : inout(7 downto 0); Within my SRAM-Controller I have the local signals l_sram_data_out : std_logic_vector(7 downto 0); l_sram_data_in : std_logic_vector(7 downto 0); l_sram_data_out describes the data which I want to write into the SRAM. l_sram_data_out is a registered signal. l_sram_data_in describes the data I want to read from the SRAM. The signal which is responsible for writing to the SRAM or reading out of the SRAM is WE_bar. WE_bar='0' & CS_bar='0' & OE_bar='1' ---> Write to the SRAM WE_bar='1' & CS_bar='0' & OE_bar='0' ---> Read from the SRAM How can I connect l_sram_data_out and l_sram_data_in in a appropriate way to the bidirectional bus? Does l_sram_data_in has to be synchronized? (It is used within the controller in a synchronous environment) I would appreciate any helpful hint. Kind regards André V. ALuPin |
|
|
|
|
#2 |
|
Posts: n/a
|
"ALuPin" <> wrote in message
news: om... > Now I have an INOUT pin at my SRAM-Controller : > Sram_data : inout(7 downto 0); > > Within my SRAM-Controller I have the local signals > l_sram_data_out : std_logic_vector(7 downto 0); > l_sram_data_in : std_logic_vector(7 downto 0); > > l_sram_data_out describes the data which I want to write into the SRAM. > l_sram_data_out is a registered signal. Registered by a clock? > l_sram_data_in describes the data I want to read from the SRAM. You probably don't need this signal. You can read the value of the inout port directly. However, you may decide that it makes the code clearer to have this extra internal signal. > The signal which is responsible for writing to the SRAM > or reading out of the SRAM is WE_bar. > WE_bar='0' & CS_bar='0' & OE_bar='1' ---> Write to the SRAM > WE_bar='1' & CS_bar='0' & OE_bar='0' ---> Read from the SRAM As far as the inout port is concerned, the only important question is: do I want the SRAM to drive a value out through this port? That's easily answered: signal Read_Enable: std_logic; .... Read_Enable <= WE_bar and (not CS_bar) and (not OE_bar); > How can I connect l_sram_data_out and l_sram_data_in > in a appropriate way to the bidirectional bus? l_sram_data_in <= sram_data; -- that's it, input is easy -- Driving a tri-state inout port is the ONLY situation -- where I find conditional signal assignment is useful: sram_data <= l_sram_data_out when Read_Data = '1' else (others => 'Z'); > Does l_sram_data_in has to be synchronized? (It is used > within the controller in a synchronous environment) That depends on your controller. Since the controller is providing the SRAM control signals, it should be fairly easy for you to guarantee that the SRAM's output (read) data is stable and valid at the time when your synchronous controller samples it. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. Jonathan Bromley |
|
|
|
#3 |
|
Posts: n/a
|
>l_read_enable <= l_we_bar and (not l_cs_bar) and (not l_oe_bar);
>l_sram_data_in <= Sram_data; >Sram_data <= l_sram_data_out when l_read_enable = '1' > else (others => 'Z'); One additional thing: l_sram_data_out are the data to WRITE into the SRAM. Is the VHDL code correct concerning that? Rgds Andrés V. ALuPin |
|
|
|
#4 |
|
Posts: n/a
|
"ALuPin" <> wrote in message
news: om... > >l_read_enable <= l_we_bar and (not l_cs_bar) and (not l_oe_bar); > > >l_sram_data_in <= Sram_data; > >Sram_data <= l_sram_data_out when l_read_enable = '1' > > else (others => 'Z'); > > > One additional thing: > > l_sram_data_out are the data to WRITE into the SRAM. > > Is the VHDL code correct concerning that? No, obviously it is not. I understood from your message that this code was to form part of your SRAM model. If the code is to be part of the CONTROLLER, then you will need different behaviour. In particular, you will not be able to infer a data out enable control from the three memory control signals; it would almost certainly cause write-data hold time violations at the SRAM inputs. However, my example correctly shows how to make tri-state enable on an inout port. I guess you can go from there. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. Jonathan Bromley |
|
|
|
#5 |
|
Posts: n/a
|
> In particular, you will not be able to infer a data out enable
> control from the three memory control signals; it would > almost certainly cause write-data hold time violations at > the SRAM inputs. Can you explain what you mean? Thank you very much. Best regards Andrés Vazquez G&D ALuPin |
|
|
|
#6 |
|
Posts: n/a
|
Hello,
I have the same problem. ALuPin, if you have your definitive vhdl code for the SRAM. Please leave it here or if someone has something similar to use a SRAM bidirectional bus... Thanks bittor |
|
|
|
#7 |
|
Posts: n/a
|
Hello,
If have the same problem. Alupin, if you have your definitive design please leave it here. Or if someone has somethind silmilar to control bidirectional port for SRAM... Thanks bittor |
|
![]() |
| Thread Tools | Search this Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| vhdl bidirectional transceiver with enable | qtr | Hardware | 1 | 08-22-2007 06:30 AM |
| vhdl code for bidirectional transceiver | qtr | General Help Related Topics | 0 | 07-05-2007 05:00 PM |