Synthesis

[tmanickam]

I'm trying to implement a DPRAM with bit write capability in ISE 14.1 (targetted for the Kintex series)

But ISE is not able to synthesise it properly and is stuck. Even if it is not able to infer block RAMs I expect the tool to infer a proper distributed RAM. Below is the verilog code that I implemented(read comments below) - same code repeats for portB as well. I can add else conditions, provided it doesn't add more logic. The same coding style infers a bit write capable SRAM - I've not done a gate level simulation of the same; so not sure about the functional correctness of the same - could look into the schematic to see if xst understood it properly. I tried both "infer block/distributed RAMs" option.

Any idea on how to get this fixed ..?

assign douta = radata;    //output read data

always @ (posedge clk)

begin//{

 radata <= mem[addra];  //port A read data decoding

end//}

always @ (posedge clk)

begin//{

if(~csna & ~wena)      //when chip select and write enable - both active low are present

begin//{

 for(a=0; a<dw; a=a+1)    //for each bit in the incoming write data

 begin//{

  if(~wenabit[a])               //active low bit write enable

   mem[addra][a] <= dina[a];  //take the corresponding bit in data into memory

 end//}

 end//}

end//}

[eteam00]

From within the ISE navigator shell, you can access the ISE Language Templates by clicking on the light-bulb icon.

Navigating Verilog > Synthesis Constructs > Coding Examples > RAM > BlockRAM > Dual Port >

yields this template for single clock, 1 write port, 1 read port RAM:

   parameter RAM_WIDTH = <ram_width>;
   parameter RAM_ADDR_BITS = <ram_addr_bits>;

   (* RAM_STYLE="BLOCK" *)
   reg [RAM_WIDTH-1:0] <ram_name> [(2**RAM_ADDR_BITS)-1:0];
   reg [RAM_WIDTH-1:0] <output_data>;   

   <reg_or_wire> [RAM_ADDR_BITS-1:0] <read_address>, <write_address>;
   <reg_or_wire> [RAM_WIDTH-1:0] <input_data>;

   //  The following code is only necessary if you wish to initialize the RAM
   //  contents via an external file (use $readmemb for binary data)
   initial
      $readmemh("<data_file_name>", <rom_name>, <begin_address>, <end_address>);

   always @(posedge <clock>) begin
      if (<write_enable>)  <ram_name>[<write_address>] <= <input_data>;
      <output_data> <= <ram_name>[<read_address>];
   end

-- Bob Elkind

[tmanickam]

Appreciate the response. But as I mentioned the issue is not about inferring a true DPRAM or a simple DPRAM.

I'm able to infer both types of dpram without the bit write capability.

The issue itself is getting the bit write support for the data. (where one some of the bits get written and the rest remain unmodified)

[rcingham]

Read, Modify, Write.

Therefore not single clock cycle access.

[tmanickam]

It is not a read modify write operation.

The write mask becomes mux select for Data in.

   _____________

   |                              |

    ----|\                       |

         |  \     _____     |

         |   |---| D   Q|----

    --- |  /     |          |

data |/ |     |>        |

            |

  -------    

write mask

[bassman59]

---

tmanickam wrote:

It is not a read modify write operation.

The write mask becomes mux select for Data in.

   _____________

   |                              |

    ----|\                       |

         |  \     _____     |

         |   |---| D   Q|----

    --- |  /     |          |

data |/ |     |>        |

            |

  -------    

write mask

---

Yes, it is a read-modify-write, although your model of the recirculating mux (basically how a clock-enabled flip-flop works) is the right idea. In order for that recirculating mux to work, you have to address the memory in order read the original value. 

Assume for the moment that your memory is eight bits wide. What you want to do, then, is to instantiate or infer eight one-bit-wide memories. The bits in your write mask (which is equal to the bus width, eight bits) are then used as the write enables for each bit. 

got it?

[eteam00]

Yes, it is a read-modify-write

I agree with tmanickam, on principle (perhaps not on implementation, however).

You should be able to infer what is essentially a 1-bit wide read/write (distributed) RAM.

The notion that the 1-bit wide RAM is an 8-bit wide RAM with per-bit write mask can be a higher-level abstraction.

-- Bob Elkind

[tmanickam · Accepted solution]

Yes, functionally speaking it is a two clock process, that can be done only with a pipeline.

Decode the read address, take the data, modify the bits, decode the write address and then write it back.

I don't understand the architecture complexities/limitations of xilinx FPGAs; but if the hardware fabric has inbuilt support, the irrelevant data bits could be "cut-off" from reaching the particular memory cell in an array of 8/16/32/64 bits.

The write mask could determine which memory cells in the block RAM actually get written and the rest could either not see the write signal or may be the clock could gated. I don't know how feasible this method is, but I don't think it should be impossible - probably not many applications have a single clock bit write requirement.

Since the SRAM got synthesised with bit write capability, I interpreted it as the memory cells having this kind of an inbuilt arrangement in place.

Can the moderator close this thread - my question is probably an invalid one.

Thanks for all your replies.

[bassman59]

---

tmanickam wrote:

I don't understand the architecture complexities/limitations of xilinx FPGAs; but if the hardware fabric has inbuilt support, the irrelevant data bits could be "cut-off" from reaching the particular memory cell in an array of 8/16/32/64 bits.

The write mask could determine which memory cells in the block RAM actually get written and the rest could either not see the write signal or may be the clock could gated. I don't know how feasible this method is, but I don't think it should be impossible - probably not many applications have a single clock bit write requirement.

Since the SRAM got synthesised with bit write capability, I interpreted it as the memory cells having this kind of an inbuilt arrangement in place.

---

The architecture of the BRAM enables the engineer to trade off width vs depth. Also, some families (I know nothing about Kintex because as far as I'm concerned, I can't buy so so I won't worry about it) allow for byte write enables when the BRAMs are used as 32 bit wide memories.

But none of them have inherent bit-write-masking capabilities. But the way around this is, as I said, to simply write code such that you'll infer eight single-bit-wide memories, and since each memory has its own write enable, that's your mask. Of course, this means that you need to have enough BRAMs in the device to do what you want. If you're in a Spartan 3AN-50 with only three BRAMs, this sort of thing is not possible.