Re: [f-cpu] Re: FC0 XBAR

[Yann Guidon <whygee@f-cpu.org>]

hi !

Juergen Goeritz wrote:
> On Thu, 2 Aug 2001, Yann Guidon wrote:
> > > > Juergen Goeritz wrote:
> > > > > On Wed, 1 Aug 2001, Yann Guidon wrote:

> > > > now the problem is when the written register is the same as the read register.
> > > > gut feeling tells me that the signal couldn't propagate fast enough.
> > > > some kind of bypass could become necessary.
> > >
> > > Yes, but write usually is at least one cycle delayed, isn't it?
> > it depends, but it doesn't solve the problem : the delay only "moves"
> > the problem from one cycle to another...
> 
> You could use a dual port RAM. Those are usually capable of
> two accesses in a single clock cycle. This gets more of a
> problem if two ports are not enough though.

any register set today is close to multiported RAM...
I have seen 8-port configurable SRAM in an ASIC, for example.

> > > So the compiler could take care of not using the same register
> > > as source in the next instruction(s) that must be written to
> > > first. But this implies that you know exactly how the pipeline
> > > is constructed and how it works inside the compiler.
> > this is not considered : the compiler and the binaries should
> > be independent from the microarchitecture (at least, have a minimal
> > compatibility). introducing such a constraint on the compiler is
> > not desirable and not easy either...
> Didn't you tell me before that the compiler has to take
> special care of the architecture or was it just for vector
> processing?

the compiler is  recommended to take care of the architecture,
but the CPU MUST be able to handle any combination of instructions
in the program flow. otherwise, anybody (user rights) could generate
"wrong" codes and make the machine break. or viri. you get the taste.

> > we CAN detect when the bank is accessed both for read and write.
> > we can even delay the instruction that does that (but it's not desirable).
> > however, on some cases it might be that the hardware doesn't need
> > such a measure. it depends too much on the silicon characteristics...
> 
> It seems to be only necessary in the case of register clash,
> i.e. same register used for read and write the same clock. In
> this case it could be possible - just thinking - to do a wrap
> from write to read data, so that the register is only accessed
> for write but the write data is also passed to the read bus?

this means that we add yet another level of multiplexing in the critical
datapath. I'm a bit annoyed by this. i think that i will find a decent
solution, but i don't know which, yet.

> > > > i'll analyse this issue when C will be transformed into VHDL.
> > > Do you simulate the register accesses as well?
> > i start from the idea that the hardware CAN read and write the same data.
> > it is easier to handle because there is no special case.
> > i could then add a 1-cycle write latency feature, in the future,
> > but it makes the instruction decode/issue more complex...
> Me won't go for latency - me want it simple :-)
YG wants it simple, but working acurately :-P
as long as i can, i'll find problems at the C level.

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