FPGA Central

On May 11, 4:39*pm, pe...@xilinx.com wrote:
> On May 11, 4:04*pm, Mark <m...@cacurry.net> wrote:
>
>
>
>
>
> > On May 11, 1:29*pm, pe...@xilinx.com wrote:
>
> > > I am surprised about the interest in write_first vs read_first.
> > > The read output during a write operation came really about as an
> > > afterthought. ("It's easy, theportis already there, so it costs
> > > nothing").
> > > But why do you want to read from the same location that you are
> > > writing to?
>
> > For "READ_FIRST" it makes sense. *Your reading an old value and
> > the same time your updating a new value. *For us it's an image
> > processing algorithm, where pixels are going into a line buffer.
> > We needed line[n-1] pixel value now (the READ data), along with
> > the current value (the WRITE data). *On the next line the
> > previously written data is now line[n-1], repeat. *So the
> > address of the READ, and WRITE are ALWAYS the same (the column
> > address). *So (depending on how you count things) this consumes
> > one RAMport.
>
> > > Especially when you are reading what you already know, since you
> > > simultaneously are writing it (which was the original mode).
> > > Then we found that read-before-write was an easy modification, and
> > > more valuable.
>
> > I agree, "WRITE_FIRST" has more limited utility. *I didn't know
> > the history that was the only available mode previously.
>
> > > But still: why do you read from the write address, when you have a
> > > separate readportwith its own dedicated addressing available?
>
> > Yes, Xilinx has "TrueDualPort", but I'd rather
> > code to the minimum that I need in tech independant manner,
> > and let the tool build from what's available.
>
> > If the tool can't build it I'd rather it barf and quit, rather
> > than just build something willy-nilly that doesn't match the
> > description. *(okay, a bit snarky - I guess I'm still a little
> > sore over all that time in the lab debugging an XST issue...)
>
> > --Mark
>
> Mark, there are clearly several different ways to implement your
> design: singleportwith read-before-write (the most elegant way),
> ordual-portwith duplicated offset addressing,
> or even time-sequenced read-then-write, time permitting.
> It is frustrating to know that it can be done, but not be able to do
> it.
> Maybe you expect the synthesizers to be more versatile and smarter
> than they really are.

I'm not asking the synthesis tool to optimize across multiple
solutions.

A time-sequenced read-then-write would be an architecture change that
certainly outside the scope of a synthesis tool.

Inferring "Read_First" vs. "Write_First" behaviour correctly is quite
easily within the scope of the tool.

I just wanted to warn folks to check their template results closely
in the log files for these inferred RAMS. I was bitten, and
don't want others to repeat.

--Mark