Synthesizer selected unintended Qual port RAM

Status
Not open for further replies.
S

SharpWeapon

Member level 5
Joined
Mar 18, 2014
Messages
89
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Visit site
Activity points
705
Hello,

I was planning to have Dual port RAM while writing the following code, yet the synthesizer selected a Quad port RAM for the same code. First of, I don't understand why it selected the Quad port, as I am specifying only two ports of data writing at the same time. Second, Incase the synthesizer has the right to do anything how can I force it to use only Dual port RAMs?

Thanks! 

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Writing: process(CLK)
    begin 
        if(CLK'event and CLK='1')then 
            if(en='1')then 
                ramMem(to_integer(unsigned(memAddressWriteA)))<=inputA;
                ramMem(to_integer(unsigned(memAddressWriteB)))<=inputB;
                memAddressWriteA<=STD_LOGIC_VECTOR(unsigned(memAddressWriteA) + 2);
                memAddressWriteB<=STD_LOGIC_VECTOR(unsigned(memAddressWriteB) + 2);
                if(to_integer(unsigned(memAddressWriteA))=(nPt-2))then 
                    startReading<='1';
                end if;
            end if;
        end if;
    end process;
 
 
 
Reading: process(CLK_Fast)
    begin 
        if(CLK_Fast'event and CLK_Fast='1')then 
            if(en='1')then
                if(startReading='1') then
                    memAddressOrigFull<=STD_LOGIC_VECTOR(unsigned(memAddressOrigFull) + 1);
                    memAddressOrig<=STD_LOGIC_VECTOR(unsigned(memAddressOrig) + 1);     
                    output<=ramMem(to_integer(unsigned((memAddressReadRever))));
                end if;                                         
            end if;
        end if;     
    end process;
 

Basically we both used the same way, except that he make a single process for each writing port. In my case I write to both ports in one process, better I guess.
The synthesizer is giving me the following advice, even after I bring the asynchronous address counters inside the process, doesn't make sense to me:
Code: 
The following registers are absorbed into accumulator <memAddressWriteB>: 1 register on signal <memAddressWriteB>.
The following registers are absorbed into accumulator <memAddressWriteA>: 1 register on signal <memAddressWriteA>.
The following registers are absorbed into counter <memAddressOrigFull>: 1 register on signal <memAddressOrigFull>.
The following registers are absorbed into counter <memAddressOrig>: 1 register on signal <memAddressOrig>.
INFO:Xst:3218 - HDL ADVISOR - The RAM <Mram_ramMem> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features. If you have described an asynchronous read, making it synchronous would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines.
 

Also your code is a quad port...
SharpWeapon said:
In my case I write to both ports in one process, better I guess.
Click to expand...
You have two write ports on CLK and two read ports on CLK_Fast, which I'm sure isn't what you intended. That is why the processes are separated, your solution is definitely not better.

The point here is using a single process may not be interpreted correctly by the tools. You should use a proven coding style, unless your intention is "experimenting" on "science project" code. Before you keep going down this slippery slope try using the style on the blog and see if it works.

Regards

- - - Updated - - -

FYI, In case it's not clear...
A true dual port RAM has two independent ports that have a set of clock/address/read_data/write_data/controls signals. So trying to have both reads and both writes on different clock domains doesn't work as a dual port RAM.
 
I have two write ports and one read port. I designed it such that I will write in both write ports at the CLK and read on CLK_Fast.

I also tried it as suggested by the code you gave me, making two different processes for each writing port, it is still Qual port.
 

Actually your design has two simple dual ports (i.e. 1. a write port, 2. a read port).

A dual port RAM:

Port A:
Read and write on clock domain of port A

Port B:
Read and write on clock domain of port B

That is a dual port RAM anything else that doesn't perform the reads and the writes on the same clock domain will require more ports.

So the blog post uses the same clock for both the read and write for each port, which makes it dual port RAM.
 
Last edited:
I understood that, I have another module which has one write port(CLK) and two read ports(CLK2), which was synthesized perfectly as a Dual port. Here the only d/c is that, I have two write ports(CLK) and one read port(CLK_Fast). So, what I can see is writing can't be done to the two ports at same clock right? But there should be some way that we can write to the RAM, in the way I wrote the code.
 
Last edited:

Are you absolutely sure it's a single dual port for both read ports (that can't be done in any FPGA family that I know of)

You're dual port RAM for the 1-write, 2-read might 2x bigger than you would expect as it's probably writing to two RAMs so you can independently read from both read ports at different addresses. Implementation wise it's probably just made two separate dual ports that share the same write logic.

In the case of the two write ports and a common read port you have to have a quad or three port memory to implement that, as you are supposed to be writing to independent addresses and reading data from the single port. I'll have to think about how that could be implemented using block RAMs. I'm not sure it's possible. The difficulty is in the need to keep the two RAMs coherent with each other as you need to allow for simultaneous writes to different addresses and still be able to read the RAM at the same time.
 
You are right, I synthesized the module alone, it is implemented as a two Dual port(But at least It was implemented using BRAM).

I agree, it seems not easy to keep both RAMs coherent. May be I have to think another way of doing it. May you come across an idea, let me know please. Thanks!
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…