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.

difference between Xilinx core generator and Language Template in ISE for BRAMs

Status
Not open for further replies.

eshbonzie

Junior Member level 3
Joined
Aug 16, 2010
Messages
29
Helped
16
Reputation
32
Reaction score
13
Trophy points
1,283
Activity points
1,721
hey guys,

I am trying ti implement a BRAM of any size as a first step...after reading for a while I knew that this can be done from the Xilinx Core generator where I can specifiy exactly what type of memory I want with write and read widths. However I also found a language template inside the ISE itself where I can use ready made template for the memory implementation.

I am convinced more with the Core generator, however I tried both and synthesized. The synthesis report for the core generator generated memory didn't include any BRAM details

Device utilization summary:
---------------------------

Selected Device : 5vlx110tff1136-1


Slice Logic Utilization:

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 0
Number with an unused Flip Flop: 0 out of 0
Number with an unused LUT: 0 out of 0
Number of fully used LUT-FF pairs: 0 out of 0
Number of unique control sets: 0

IO Utilization:
Number of IOs: 168
Number of bonded IOBs: 0 out of 640 0%

Specific Feature Utilization:

---------------------------
Partition Resource Summary:
---------------------------

No Partitions were found in this design.

---------------------------

while the synthesis report for the language template memory included BRAM information and it was mentioned

Device utilization summary:
---------------------------

Selected Device : 5vlx110tff1136-1


Slice Logic Utilization:

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 0
Number with an unused Flip Flop: 0 out of 0
Number with an unused LUT: 0 out of 0
Number of fully used LUT-FF pairs: 0 out of 0
Number of unique control sets: 0

IO Utilization:
Number of IOs: 112
Number of bonded IOBs: 112 out of 640 17%

Specific Feature Utilization:
Number of Block RAM/FIFO: 1 out of 148 0%
Number using Block RAM only: 1

Number of BUFG/BUFGCTRLs: 2 out of 32 6%

---------------------------
Partition Resource Summary:
---------------------------

No Partitions were found in this design.

---------------------------

Am I misunderstanding something? if both ways are valid to implement BRAMs, then what is the difference between them?

any help would be appreciated.

Eshbon
 

you need to do the implemenation. I think there may also be some way to manually tell synthesis about the resource utilization of the coregen cores. at a minimum, you can tell the synthesizer the maximum number of block rams it can infer from HDL.

the coregen cores are usually netlists, and are not put into the design until the translate phase. to synthesis, they are black boxes.

I'm not sure if the generally buggy "read cores" option will help here. "read cores" is an option that reads in coregen cores and attempts to perform hierarchy crossing optimizations with them. This sometimes leads to build errors though.

--edit -- my point is that MAP will provide you with the actual usage statistics. Synthesis only provides an estimate.
 

In the core generator page, I think you have an option called "Resource utilization" where you can see the amount of resources which will be used by the BRAM / or any other core.See that.
Core generator try to optimize and place the BRAM inside your FPGA based on the paramters you give in the GUI screen.But still you have limited control here on actual hardware components used. But if you use language templates you can select the BRAM blocks available and instantiate them individually.If you need a 4k*4 BRAM and say you have only 2k*4 BRAM's in your particular FPGA.Then you can cascade two such RAM's and use it. This is little bit complicated than core generator.But as permute said the optimizations can be done on a global level(the optimization is not done individually for each instantiation).
 

Thank you both for your replies. However I guess my main problem was that I used the core generator software first(not through the ISE) to create the BRAM and then I opened the created BRAM in ISE which some how was the problem!. The solution I found was to use the ISE directly to create the BRAM.

in ISE:
Project->New Source->IP(CORE Generator & Architecture Wizard)

this solved my problem, as when I synthesized I finally got

Specific Feature Utilization:
Number of Block RAM/FIFO: 1 out of 148 0%
Number using Block RAM only: 1
Number of BUFG/BUFGCTRLs: 2 out of 32 6%

My question now if you might have an answer for it is why is it only mentioning 148 available Block RAMs.

Im using a Virtex 5 FPGA where it is stated in the data sheet that it has 296 (18Kb) or 148 (36Kb) Block RAMs. It is also mentioned that

"Block RAMs are fundementally 36 Kbits in size, each Block can be used as two independent 18-Kbits blocks"

I created a 18Kb Block RAM(this was mentioned in the last step of the GUI Screen of the core generator), However the result in the report was 1 out 148(which ofcourse I assume are the 36 Kb Block RAMs available).

Does this mean that even if I create a 18 Kb Block RAM it still consumes a 36 Kb Block RAM on the FPGA?
 

Somewhat. its similar to when a single register is used within a slice. the slice is counted as being used, but additional logic could be packed into the slice in a different build.

The tools might avoid packing 18k BRAMs into the same 36k BRAM in order to meet timing constraints. The BRAMs are fairly sparse, which makes routing difficult. thus an available BRAM might be chosen to be close to the logic it connects to. this results in 2 partially used BRAMs, as opposed to 1 fully used BRAM. Had only 1 BRAM been used, there would need to be more routing between the BRAM and some of the logic it connects to. The tools will determine this. As the design fills up, more and more BRAMs will start getting shared.

Also, fifo's are a bit special. The logic for fifos can use a 18k or 36k BRAM, but you don't get to use 296 18k fifo's. you get 148 fifos, which can be 18k or 36k. An 18k fifo can share a BRAM with an 18k BRAM though.

I would guess if you added the .xco file from coregen, XST would have known about the resource usage. From what I recall, ISE can use the .xco file to get information about a given core.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top