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

Re: [f-cpu] another DATE report

hi !

nico wrote:
> Yann Guidon a écrit :
> > nico wrote:
> > > Wisbone is very (to much ?) simple.
> > if it's simple, then why do you want to make it more complex than necessary ?
> >
> > > i propose to introduice 3 things :
> > > - a cycle take only one cycle,
> >
> > huh ? a cycle is a cycle, i don't understand what you mean.
> > maybe i should read the wishbone specs more carefully, i have printed it but haven't
> > had enough time to read everything.
> Oups ! i means a read or write cycle take only a clock cycle.(to be
> comparre to the 2 clock cycle from AMBa wich pipeline data and address)

i remember that PI-BUS has a pipelined address-data system, too
(but not multiplexed like PCI ;-D)

> > > - a CAS 2 cycle. 2 consécutives load followed by 2 writes but atomic !
> > > If there is problems, writes could not occur.
> >
> > ugly.
> Nop, absolutely necessary to handel very easly synchronous problem.
> Christophe convince me, if he could resend it's URl about the paper that
> speak about.
> Such technic, in the common case, where there is no collision the only
> lose is this CAS2 instruction, there is no OS call overhead, no task
> switch, nothing. Only 4 atomic transactions ! We must have that !

i agree that CAS-like operations are interesting, no doubt about that.
However, what you propose is uglier than what i heard before, and
you know that we have discussed a lot ;-)

* first, there must be an instruction that supports this kind of
transaction. there is none and this instrruction would block the pipeline.
you couldn't for example "pipeline" the CASes.

* second, probably no device would support this operation. I don't know
how you would like to implement that but F-CPU is not alone in the system
(otherwise there would be no use for an I/O bus :-D) and the other elements
must support the same protocol. If there is only one memory block, ok,
but if other CPUs of a different sort are present, there might be risks.

* third, and more difficult for me (because i'm one of the people who code),
your feature requires a more complex state machine than needed. Generally
such a complex thing is not used 99.95% of the time, so i think it's an
overhead on my shoulders, unless you want to do it.

> > > - maybe things to manage cache L2 (from my point of view L2 is tied to
> > > the DRAM controller, the L1 is tied to the CPU). None caching access for
> > > example to avoid cache trashing.
> > what do you mean by "things to manage cache L2" ? what things ?
> For example, caching or no caching data (imagine the FCPu as the core of
> the Geoforce 8, rendered image didn't need to be cached).
there's a flag in the Load and Store instructions which specify if the
data is to be cached.

> To extend that, i would try to apply distributed memory in some control logic to
> make invalidate some cache line...

if we work with private and public memory spaces, there is no invalidation
logic required.

> > see you soon,
> Yep ! I leave Paris for 1 weeks. Don't blow my mail box !
send me a postcard ;-)

if you go in vacations, take some time to write a white paper about how to
use Wishbone in the most simple case (1 CPU + 1 memory). I'll try to make
that for the VCI interface. Some VHDL code would be nice, too.

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