Range of all Machine Model and Mem Hierarchy parameters

Usage of VEX tools

Range of all Machine Model and Mem Hierarchy parameters

Postby AlexSusu » Tue Feb 22, 2005 10:10 pm

Could you please tell me what are the possible values for all the MM-parameters. Below I am pasting all the MM-parameters that were dumped by the VEX compiler (for 1 cluster architecture)

-width parameter --> no of clusters: can only be 1,2 or 4

RES: IssueWidth 4
RES: Alu.0 4
RES: Mpy.0 2
REG: $r0 63
REG: $b0 8
REG: $b1 8
RES: MemLoad 2
RES: MemStore 2
RES: MemPft 1
RES: CopySrc.0 1
RES: CopyDst.0 1
RES: Memory.0 1

Also, if I am not asking too much, I would like to know what are the possible values for all Memory-Hierarchy parameters. I am pasting a sample vex.cfg file:

CoreCkFreq 500
BusCkFreq 200
lg2CacheSize 15
lg2Sets 2
lg2LineSize 5
MissPenalty 25
WBPenalty 22
lg2StrSize 9
lg2StrSets 4
lg2StrLineSize 5
StrMissPenalty 25
StrWBPenalty 22
lg2ICacheSize 15
lg2ICacheSets 0
lg2ICacheLineSize 6
ICachePenalty 30
NumCaches 1
StreamEnable FALSE
PrefetchEnable TRUE
LockEnable FALSE
ProfGranularity 1.000000

I would like to mention that I have learned from the previous topics on the forum the following things:

- no_of_ALUs/cluster has to be ALWAYS >=4 (it is a constraint in the VEX compiler). If one wants to model an architecture with x (x<4) ALUs/cluster he has to give
RES: IssueWidth x
RES: Alu.0 4

- IssueWidth should be >= no_of_all_ALUs_in_all_clusters + no_of_all_MPYs_in_all_clusters, otherwise the processor has more functional units that it can use on a cycle.

- one can specify starting with VEX version 3.38 the Issuewidth for each cluster. For example:
RES: IssueWidth 4
RES: IssueWidth.0 2
RES: IssueWidth.1 2

Thank you.
Alex Susu

Postby frb » Wed Feb 23, 2005 9:55 am

Here are some of the limitations, I am not entirely sure what the upper bound (N) is; I don't believe the compiler itself has bounds, but definitely there will be some weird side effects (memory, etc.) if you try extreme combinations. A value of N = 64 ough to work, but I wouldn't go much beyond that.

The simulator has a limit of 128 ops per instruction (which I could grow, if anyone can show me a case of an application that can exploit that....)

RES: IssueWidth: 1 ... N
RES: Alu.0: 4 ... N (see note 1)
RES: Mpy.0: 1 ... N
REG: $r0: 16 ... 128 (see note 2)
REG: $b0: 1 ... 8
RES: MemLoad: 1 ... N
RES: MemStore: 1 ... N
RES: MemPft: 1 ... N
RES: CopySrc.0: 1 ... N
RES: CopyDst.0: 1 ... N
RES: Memory.0: 1 ... N

Note 1: The only reason why you need 4 ALUs is because you need to be able to have resources for an ASM4 operation (which takes up 4 "ALU" slots). If you know what you are doing, you can prevent the compiler from stopping throug the configuration options
CFG: Warn 0
CFG: Quit 0
f you have some ASM operation, the compiler may crash later on, though. I'll see if I can put out a version with a few more checks for this case in the near future.

Note 2: I think that even 10 registers would do, but 16 is defintely a safer lower bound. If you recall the VEX ABI, you need 8 regs for function calls/returns and 1 stack pointer, so 10 would be pushing it a bit.

Concerning the simulation parameters, the system doesn't really impose any limit, you'll have to use common sense to avoid configurations that are meaningless, but pretty much any combination (that fits in the host memory) should do.

-- Paolo
Posts: 62
Joined: Thu Nov 12, 2009 3:44 pm

Return to VEX Tools

Who is online

Users browsing this forum: No registered users and 1 guest