Memory to synthesize

I have been experimenting with the opensparc code a little bit to try and synthesize with xst. I do not have access to the high dollar tools. The problem I ran into is even with one core enabled the build rapidly chews threw about 2.2G of memory and fails for lack of memory.

How much memory is needed to handle a single core synthesis.

[349 byte] By [brantley123] at [2007-11-26 6:06:42]
# 1

I'm not a Verilog maven, myself, but heard of someone else who encountered memory limitations when working with the OpenSPARC code.The solution was to reduce the amount of memory being simulated -- SRAM cells, if I recall correctly.

(that developer was also going to buy another GB of physical memory for his/her system to speed things up a bit, but s/he got the Verilog compiler or simulator to run just fine after reducing the amount of memory cells in the Verilog code)

I'm sure there are errors in my description, but hopefully it will provide enough of a clue to someone who knows Verilog that they will know where to look to reduce the memory footprint of the Verilog code.

dweaver at 2007-7-6 13:35:41 > top of Java-index,Open Source Technologies,OpenSPARC...
# 2

It's best to synthesize at block or module level, instead of synthesizing

the entire SPARC core or entire chip.

In the OpenSPARC T1 design database, there

are 233 different modules/sub-blocks for which synthesis scripts are provided.

$DV_ROOT/design/sys/synopsys/block.list file has list of these blocks.

The SPARC core itself has 57 different modules/sub-blocks. Also note

that the SRAMs, Cache, TLB etc. are custom blocks and should be either

black boxed during synthesis or you need to provide synthesis models

for these custom blocks based on your physical implementation.

OpenSparc at 2007-7-6 13:35:41 > top of Java-index,Open Source Technologies,OpenSPARC...