Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Using BRAM by infering and by using IP

Status
Not open for further replies.

rafimiet

Member level 5
Joined
May 21, 2015
Messages
94
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Activity points
2,364
In zedboard, we have 140 block RAMs which can be used in following configurations(a few given here) as per the user guide:
DEPTH WIDTH SIZE
1024 18 18kb
2048 18 36kb
There are many more configurations as well.
My understanding is: When using IP, we need to use the whole of the depth and the whole of the width. But when inferring with a user code, a block ram can have any width(less than or equal to max allowed) and any depth(less than or equal to max allowed).
Is that true?
Also what is the difference between DEVICE MACROs and DEVICE PRIMITIVES?
 

When you generate IP, it will give you access to that specific IP and all of the ports available. If you wanted, you can just tie the address/data bits low so they dont do anything. This is what would happen if you used an inefficient infered BRAM.
Infered BRAMs are generally prefered, especially in Xilinx, as it is far more portable than the generated IP. Altera doesnt have so much of an issue because while you can generate IPs, altera gives the user control of a library of "megafunctions" that can be instantiated and constrained within the HDL code, as well as infered IP.

Device macros would be an IP block that doesnt map directly to a single base primitive. eg. a ram from the IP generator that required several BRAMs and some logic to meet the user required size.
A primitive would be individual registers, BRAMs, DSPs etc.
 

I understand the point here
If you wanted, you can just tie the address/data bits low so they dont do anything. This is what would happen if you used an inefficient infered BRAM.
But when I use a BRAM of (depth = 256) width=11 bits and width=18 bits, the implementation results show different resource utilization. Practically, the resources utilized should have been the same. Please make be understand?
 

Device macros would be an IP block that doesnt map directly to a single base primitive..

From what I can tell, this is not accurate. the device macros are just wrappers around the single bram primitives to be a little more generic, but without anything that might need code-gen. Some versions of ISE did not work well with VHDL due to unconstrained ports and assumed (N-1 downto 0) dimensions. (the ports would be commonly tied to "0000", which defaults to 0 to N-1)
 

I understand the point here

But when I use a BRAM of (depth = 256) width=11 bits and width=18 bits, the implementation results show different resource utilization. Practically, the resources utilized should have been the same. Please make be understand?

Is it actually using a BRAM, or has the smaller ram mapped to LUTRAM?
 

I understand the point here

But when I use a BRAM of (depth = 256) width=11 bits and width=18 bits, the implementation results show different resource utilization. Practically, the resources utilized should have been the same. Please make be understand?

is this for a larger design? BRAM _site_ utilization is a bit misleading. It doens't specify if a BRAM _site_ uses both BRAM18s, or cannot use a FIFO18+FIFO18 config, or if the tools had wanted to use a BRAM for something else but decided against it.
 

Is it actually using a BRAM, or has the smaller ram mapped to LUTRAM?
The resources used Post-Implementation at depth = 65536, width = 11 are as follows:
BRAM = 22
IO = 79
BUFG = 1
The resources used Post-Implementation at depth = 65536, width = 18 are as follows:
BRAM = 36
IO = 101
BUFG = 1

- - - Updated - - -

It doens't specify if a BRAM _site_ uses both BRAM18s, or cannot use a FIFO18+FIFO18 config, or if the tools had wanted to use a BRAM for something else but decided against it.
In #7, the results for only for a TRUE DUAL PORT RAM, no extra logic has been synthesized. Also my design doesn't need FIFO configuration
 

The resources used Post-Implementation at depth = 65536, width = 11 are as follows:
BRAM = 22
IO = 79
BUFG = 1
The resources used Post-Implementation at depth = 65536, width = 18 are as follows:
BRAM = 36
IO = 101
BUFG = 1

SOunds reasonable. Looks like 2*width BRAMs using 1 bit wide BRAMs. There will be some logic there for ram muxing.
When you ask for a very deep ram, it usually defaults to using 1 bit wide data width.
 

When you ask for a very deep ram, it usually defaults to using 1 bit wide data width.
Would one address get me 11 bits from 11 locations of the RAM then(in one clock cycle)?Is that possible?
 

It will have all 22 rams connected in parrellel to the same address bus, with each bit of the data bus connected to a different ram. So yes, you access all of them in a single clock cycle as they are working in parrallel.
 
yes, using deep ram, like 64k deep (not the 256 you originally stated) will use 1b wide rams to avoid external muxes as much as possible. IIRC, the 7-series allows 2 BRAM36 to be cascaded which means you could get the 11 bit, 64k ram using no external muxes.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top