[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] Re: FC0 XBAR



On Thu, Aug 02, 2001 at 12:24:43PM +0200, Yann Guidon wrote:
> ho and welcome in the list,
> 
> Juergen Goeritz wrote:
> > On Wed, 1 Aug 2001, Yann Guidon wrote:
> > > could it be possible to switch this discussion on the main
> > > english f-cpu list ?
> > Sure!
> cool :-)
> other people will be able to participate and help.

Other people (like me) first have to catch the thread and see what the
heck is going on :(

[...]
> > > i am aware of this. I have no idea of how the synthesiser will
> > > modify the datapath, it could end up worse than what is written.
> > > i know that there are some nasty surprises awaiting us.

I've already had some of these... and I'm afraid there will be more.

> > > > > > > However, i don't know if it is possible to read and write the
> > > > > > > same register in a single clock cycle.
> > > > > > That should work, because LEON has a similar strategy for read
> > > > > > and write of the registers, one read port and one write port.
> > > > > ?
> > > >
> > > > The SPARC architecture describes a register set that provides
> > > > read and write to the register bank in a single cycle since
> > > > its a pipelined architecture capable to execute an instruction
> > > > each cycle.
> > >
> > > 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...

IMHO, reading and writing "in the same cycle" means that *by the end
of the cycle* (when the clock signal rises) the new data is stored in
the register, while the reader gets a copy of its *previous* contents
at the same time.

> > 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...
> 
> 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...

If there is a read-after-write dependency, we have to a) bypass the
result of the first instruction (if the result arrives in time) or b)
delay the second instruction (if bypassing is not possible or the result
ist NOT ready).

> > > 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...
[...]

The same *data* or the same *register*?  The former needs a bypass
(or 1-cycle delay), the latter doesn't.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/