dual-write port BRAM with XST/Webpack

You cannot infer dual-port BRAM with Webpack, but you can instantiate primitives. See

Karl Olsen

A fifo-like controller requires one read-only port and one write-only port. Such a two port description infers the "true dual port BRAM" just fine, but with the extra read and write controls tied off. As an added benefit, the description is portable across vendors. Related posting:

-- Mike Treseler

XST can't infer it but you can instatiate the primitives instead.

have a look at:

-Lasse

But this description only works if you have a common clock. The OP has asked for separate read/write clocks.

I have never seen an example of inferrence of a dual port RAM with separate clocks. I can write a VHDL description of one by using a shared variable for the RAM. But I have not found a synthesizer that supports shared variables.

Try this one. -- Mike Treseler

--_________________________________

library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all;

entity dual_port_ram is generic ( WIDTH : integer := 32; DEPTH : integer := 10 ); port ( w_clk : in std_logic; w_en_in : in std_logic; w_addr_in : in std_logic_vector(DEPTH-1 downto 0); w_data_in : in std_logic_vector(WIDTH-1 downto 0);

r_clk : in std_logic; r_addr_in : in std_logic_vector(DEPTH-1 downto 0); r_data_out : out std_logic_vector(WIDTH-1 downto 0) ); end entity;

architecture xilinx of dual_port_ram is

type memory_type is array (natural range ) of std_logic_vector(WIDTH-1 downto 0); signal memory : memory_type(2**DEPTH-1 downto 0);

signal r_addr_int : std_logic_vector(DEPTH-1 downto 0);

begin

write : process(w_clk) begin if w_clk'event and w_clk = '1' then if w_en_in = '1' then memory(to_integer(unsigned(w_addr_in)))

Ok, this is dual port, but I meant one that was fully dual port with write on both ports. The Xilinx dual port rams in the Virtex and later parts (IIRC, the Spartan3 for sure) have both read and write on each port. Being able to write to a common RAM from two processes is not supported in VHDL as far as I am aware. Using a shared variable seems to work in simulation, but is not synthesizable.

Please correct me (further) if I am mistaken.

"rickman" schrieb im Newsbeitrag news: snipped-for-privacy@yahoo.com...

At the end, I prefer to instanciate such tings anyway. Much easier, predictable, portable. Why bother with semi-intelligent synthesis tools?

Regards Falk

My point was that a pseudo dual port is all you need for a fifo and that a fifo-based controller would solve the OP's problem.

"A fifo-like controller requires one read-only port and one write-only port. Such a two port description infers the "true dual port BRAM" just fine, but with the extra read and write controls tied off. As an added benefit, the description is portable across vendors. "

I realize that. Reread the above.

You are mistaken. I tested the two-clock version on Leonardo for Xilinx and on modelsim Maybe you could try it on XST and post the result.

My examples do not use a shared variable, nor did I recommend one.

-- Mike Treseler

Sorry to waste your time. I suppose vhdl synthesis is a little off-topic for this group.

-- Mike Treseler

But your examples do not write to the ram from both clock domains. I understand that you are referring to block ram used as a fifo, but my comments were intended for a fully dual port block ram with write capability on both ports. Assigning a value to the RAM from two processes is where the problem lies, but maybe I am mistaken. Please show me a working example that has two write ports. I have a design I would like to use it in.

ram_access : process (clk1, clk2) beg>>

I am not sure I understand. Instantiation is not portable at all... The reason that I prefer to infer logic is to increase portability. I try to use block rams in ways that will work across vendors. So if I can infer them, I don't need multiple source files for different vendors. Or when I need modes that are not compatible I use GENERATE statements to select a vendor specific version, still inferred if possible.

Sorry. I didn't read this carefully. That is correct. Multiple processes can read a ram signal, but only one can drive it. My examples had one read-only process and one read/write.

See Jim Lewis's posting for the single process version. I have not tested this, but I will on Monday. In the single process case, it should be possible to use a normal variable for the RAM array.

Note that design using a dual clock, dual write enable ram is not complete until 1.synchronization and 2.arbitration of writes to the same location is worked out. That is why I prefer the synchronous fifo approach.

-- Mike Treseler

Smily missing?? ;-)) There was no offence intended. But it sounded to me like a little bit academic discussion.

Regards Falk

"rickman" schrieb im Newsbeitrag news: snipped-for-privacy@yahoo.com...

Why not? If you move to another target technology (lets say from brand A to X), you simply replace the RAMs and you are done. Especially when you are going to use brand specific features, like DLL, PLL DPS blocks etc. to get max. performance and also make it reasonable portable, you should try to isolate the brand specific blocks as much as possible to make it easier to replace them in another target. Right?

But for now its still a more or less big hassle with the tools, isnt it?

Regards Falk

Yes, I agree for a FIFO the simpler read port, write port block ram is preferred and is all that is needed for a FIFO. But the OP was asking for a way to infer a dual port block ram with write on both ports. He was not asking about FIFOs. I think the FIFO was mentioned as a way to interface a separately clocked interface to a single clock, dual port block ram.

I dug through all this a few weeks ago and both Xilinx and Altera say that there are no means to infer true dual port, dual clock block rams at this time.

I guess we define portability differently. I have not considered that changes to the code are in the realm of "portable", but I guess there are "degrees" rather than it being an absolute.

Only for a few features that are very different across vendors or things like these true dual port memories that are not inferred. I don't instantiate registers or logic even though they are slightly different between vendors. For example, I am optimizing my current design by telling the tool specifically how to map the logic to LUTs. But I am not instantiating any LUTs. I am breaking the logic into 4 input expressions and assigning a "keep" attribute to the signal. I expect that all tools supporting devices with 4 input LUTs will properly infer the LUTs that I want, so this is fully portable without code changes.

"rickman" schrieb im Newsbeitrag news: snipped-for-privacy@yahoo.com...

Me too.

Regards Falk

Seems a bit strange. Why is a 2 port RAM that can read and write on both ports that much more complicated to recognize than a 2 port RAM that can only read on one port and write on the other?