[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] Something new to play with :)
Michael Riepe wrote:
> On Tue, Sep 25, 2001 at 01:30:31AM +0200, Yann Guidon wrote:
> > > > > Speed: 66MHz (optimized for speed, no special tricks)
> > > > wow :-)
> > > > what is the fastest thing you have synthesised for this device ?
> > > That's nothing -- the multiplier was faster :)
> > > But I'm quite satisfied with that result.
> > does that mean that you have something better in mind ? :-)
> It means: 66 MHz is pretty good (for an FPGA). Although, know you
> mentioned it... I *may* be able to do even better ;)
i *knew* it ;-) i knew that you had something in mind and i know that
it is possible to do better (hence my personal research)
> > > > > Utilization: 30%
> > > > wow :-/
> > > > How big is it btw ?
> > > The multiplier also took something like 30%. The SHL EU is very
> > > space-consuming...
> > yep. From the other mail i wrote, i might come from the wires
> > (which btw make P&R more difficult in a 2D frame).
> Or the number of cells required for the muxes. There are four of them
> for every bit, approximately -- and since left-shifts and right-shifts
> are handled separately, that number is doubled once more. That is,
> there are 512 multiplexers with 8...12 inputs. But that's nothing
> compared to the Xbar ;)
i don't think that the Xbar will be extremely annoying.
Comparatively, it's not tough : there are already 8 inputs when only a few
units are present. If there are more units, it goes up but not madly.
This is 2*64-bits of course but i think it fits "right" into the pipeline
> > > > > btw. the muxes are quite huge :) FPGA architectures usually have some
> > > > > problems with complex multiplexer structures.
> > > > this is why i prefered to use 4-in muxes :-)
> > > Too big for most FPGAs. All you can do with 4-input cells is a 2:1 mux.
> > read my other mail that answers to Richard. This puts the pressure
> > on the decoder, OTOH. With some smart thinking it maybe be possible
> > to find a suitable trade of between the cascade of OR and the decoder
> > complexity.
> I guess my 2nd stage decoder is already pretty simple. Took me quite a
> while to find a solution that does not suffer from extreme elephantiasis ;)
> > > > Can you track where the critical datapaths are located ?
> > > I guess it's in the control logic for stage 2.
> > ggggrrrrrr i'll have to look at the sources :-)
> Good idea ;)
let's add an optical output to my flying calf first :-P
> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/