DPRAM issue

Hi, Folks,

I am using a DPRAM with data bus width of 32 bits on both sides of the
RAM. However, the input data at A side is 16 bits. So in order to send
32 bits of data to fill one address of the RAM, I need to use a mux
and introduce a clock cycle of latency into the writing process at A
side. The problems is that mux logic is not scan insertable and the
extra clock cycle latency is not welcome either. So my question is: is
there any nice and dirty tricks in VHDL that can avoid those problems
without changing the RAM?

Thanks in advance.

Ian

ian

ian wrote:
>
> I am using a DPRAM with data bus width of 32 bits on both sides of the
> RAM. However, the input data at A side is 16 bits. So in order to send
> 32 bits of data to fill one address of the RAM, I need to use a mux
> and introduce a clock cycle of latency into the writing process at A
> side. The problems is that mux logic is not scan insertable and the
> extra clock cycle latency is not welcome either. So my question is: is
> there any nice and dirty tricks in VHDL that can avoid those problems
> without changing the RAM?

This actually has nothing to do with VHDL, it is purely a design
question.

Since you mention scan insertion, I'm going to assume you're dealing
with an ASIC, not an FPGA. Your comment about requiring a mux makes no
sense if you're writing from a 16-bit bus to a 32-bit RAM port. This is
actually a de-muxing function. Furthermore, you would normally do this
with a 16-bit register to hold one value until the second value is
available and then write both values together as one 32-bit word. I see
nothing here that should be a problem with scan insertion.

If your DPRAM has separate byte or half-word enables, you could deal
with this by tying the upper and lower halves of the Port A data bus
together and using the byte/half-word enables to control the write. This
would eliminate the latency you mention. If you are doing a standard
cell design, you should be able to ask your vendor to generate you a RAM
with the necessary enables. Otherwise, you _are_ going to have one clock
of latency on the first 16-bit value
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

Tim Hubberstey