[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile



Hi,

On Mon, 16 Jun 2003, Yann Guidon wrote:

> hello,
> 
> Anup Gangwar wrote:
> 
> >Hi,
> >
> >	I have been reading posts on this list for long but have never
> >posted any message myself. In my opinion going for simpler (less R+W
> >ports) RF's will be advantageous from two viewpoints:
> >
> >1. If we stick to at most 2R+2W ports then the CPU could easily work with 
> >FPGA technology a big+ while prototyping.
> >  
> >
> 
> this creates a problem : F-CPU is not meant to use *only* FPGA.
> so if we develop with FPGA in mind (call this a "least common feature 
> problem")
> the design will not exploit all the potential of ASICs.

I agree, however, what I meant to say was that this will be a big plus in
the initial prototyping stage. FPGA's are cheap readily available etc.  
etc. We could increase the ports by one for ASIc but beyond that even the
ASIC RF tech. will fall short of the clock requirements. FUs will be way
too fast. A comparison using High Level Synthesis is out of question,
since most of the RFs are custom designed. I can point to a reference
though:

	http://www.cs.rice.edu/~rixner/rixner_hpca6.pdf

This is a quite exhaustive examination of register organization for 
high-issue processors. We can learn from their experiences and adopt the 
same.

> 
> and after all : even if a 3R2W RF is 3x slower than 1R1W, you're still 
> overlooking something :
> it will *work* ! (look at Don's post).
> 
> the architecture of the RF can be locally modified to maybe allow more 
> cycles
> or better behaviour. If we make it work now, with a full-featured set of 
> features
> (and no compiler constraints) then people will use it happily, even if 
> it is 1 million times
> slower than the latest Intel/AMD horse. Not only will they use it but 
> they will get used
> to the fact that there is few coding constraints.
> 
> >2. The larger the RF the slower it will be.
> >
> The RF has 63 registers that are *at least* 64-bit wide.
> so it's already slow from the start, right ?

The problem is not from the no. of registers but rather from the no. of 
ports. Even if we increase the no. of registers from 64 to 128 it will not 
be as bad as adding another port. 

> 
> > Everyone is breaking up the RF 
> >into smaller chunks (clusters of FUs).
> >
> can you point us to references about "everyone" ?
> 
Sure, here are the architectures which immediately come to my mind:

Sun's MAJC, TiC6x, Intel EPIC (2+ yrs. down the line), Siroyan. The oldest
one is from Digital. One of the Alpha processors had a split RF. However,
both the Alpha's as well as MAJC's RF are compiler transparent. Here is an 
article from Microprocessor Report on Intel's future architecture:

http://www.cs.cmu.edu/afs/cs/academic/class/15740-f02/public/doc/discussions/uniprocessors/ia64/mpr_ia64_demyst_jan98.pdf


> >As per one heuristic estimate the power, delay and max freq grow
> >
> > as atleast N^1.5 where N is the no. of FUs per RF.
> >
> >6. The compiler complexity will not grow too much
> >
> there is a problem here with the "too much" :
> it's not quantifiable if it is not programmed.
> and as you have probably remarked, few people here
> are eager to write code.

I agree, that it is not quantifiable till someone has actually done it.
However, for some time I have been working on developing compilers for
such architectures. But nothing is out as of now, due to all being 
hypothetical architectures.

> 
> >if each of the 
> >individual clusters is connected to the other in a homogeneous fashion. 
> >Though a variety of interconnect strategies are possible.
> >  
> >
> here you propose an architecture where the core is split into "clusters"
> with each a small register set and some "Execution Units".
> right ? (if yes, then it has already been discussed ....)

Sure yes. I will read up the previous posts. Thanks.

> 
> >Regards,
> >  
> >
> read you soon,
> 
> >Anup
> >  
> >
> YG
> 
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
> 

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/