VDHL implementation of RAM with serial input and parallel outpout ? thx

- J
- Jimmy
  
  Contact options for registered users
posted
19 years ago

Mon, Jun 21, 2004 4:06 AM

Hi, all,

From the incoming data flow, I will collect a fixed number of data (say 88 samples, each with 8-bit width). I want to use RAM to buffer the incoming data, and after the RAM is filled up with 88 samples, I will output all these 88 samples simultaneously to another buffer to perform further operation. If I don't use RAM, it will be synthesized as D Flip-flop for the incoming data buffer, which is quite resource cosuming. So I want to instantiate as or refer to distributed RAM or Block RAM (using xilinx virtex 2).

But the available RAM seems working this way, one data in and one data out. port( RB_CLK8x : in STD_LOGIC; RB_WREn : in STD_LOGIC; RB_RDEn : in STD_LOGIC; RB_WRAddr : in STD_LOGIC_VECTOR(7 downto 0); RB_RDAddr : in STD_LOGIC_VECTOR(6 downto 0); RB_DataIn : in STD_LOGIC_VECTOR(7 downto 0); RB_Dout: out STD_LOGIC_VECTOR(7 downto 0) );

so how can I input data one by one, and output them in parallel way? Any comments or suggestion will be heartly appreciated.

regards, freedragon

- J
- Jerome
  
  Contact options for registered users
Vote on answer
posted
19 years ago

Mon, Jun 21, 2004 5:03 AM

The solution i suggest to you here is to use a FIFO , which in fact consists in a blockram surrounded by a little manager design. There are plenty of fifo designs available, the best is to go at xilinx.com The use of a fifo is extremly simple , just handle a read signal to pop data and a write signal to push data, just a little trick : in the design where you use teh FIFO, doing things (pop or push data) at CLOCK falling edge simplify even more the things

The data flow in your app is not sufficiently described to allow to choose between a synchronous (data producer & consumer share the same CLK) or asynchrounous (each having his own CLK).

"Jimmy" a écrit dans le message de news:cb5mre$t63$ snipped-for-privacy@hkueee5.eee.hku.hk...

be

out.

- M
- Michael Schöberl
  
  Contact options for registered users
Vote on answer
posted
19 years ago

Mon, Jun 21, 2004 5:46 AM

That would make 704 data-signals between your buffers ... why would you want to do that!? for a fast buffer-to-buffer transfer??

- you could transfer to the next buffer at a faster clock and higher width ... lets say 100MHz and 32Bits would make 220 ns ... still too long?!

- you could switch between input-buffers ... your data-processing works on one of your input-buffers while the second one is filled from your input ... switching between them could be done fast ...

bye, Michael