DPRAM issue

[ian]

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

 

[Tim Hubberstey]

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