Prev: Altera LP6 Logic Programming Card - Supplier
Next: XUPV5-LX110T, DDR2, and EDK (10.1 to be precise)
From: Peter Alfke on 13 Dec 2009 12:42
On Dec 13, 6:10 am, Symon <symon_bre...(a)hotmail.com> wrote:
> Jonathan Bromley wrote:
> > On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke
> > <al...(a)sbcglobal.net> wrote:
>
> >> In short:
> >> changing a SINGLE lut input will NEVER generate a glitch.
>
> > Nice to know, and - thinking about the likely structures
> > for the guts of a LUT - perfectly reasonable.  Thanks.
>
> > However.... can all other manufacturers of LUT-based
> > FPGAs make the same promise?  Again, *probably* yes;
> > but would you bet your life/reputation/fortune on it?
>
> Hi Jonathan,
> Think about it this way. If you deliberately wanted to make the output
> of a 2^N to 1 mux glitch if only one select input changes, how would you
> do it?
> Cheers, Syms.

It can be done:
Suppose both data inputs are High, while you change the select input
from High to Low.
Suppose the deselect path is faster than the select path, then you
will see a Low glitch on the output.
The OP's concern is legitimate, but I had investigated and found out
and documented several times:
A mux implemented in a single Xilinx LUT does not have this problem,
since it uses pass transistors, and the internal capacitance "bridges"
the change-over.

I would assume that the other big FPGA company does it the same way.
They are just not as forthcoming with helpful information.
Peter Alfke
From: KJ on 13 Dec 2009 15:36
On Dec 13, 12:42 pm, Peter Alfke <al...(a)sbcglobal.net> wrote:

> The OP's concern is legitimate,

But, as is usually the case with these types of queries, it's
indicative of either a flawed design approach or choosing to make your
own life more difficult. The OP concern over performance that
prompted the query was after deliberately choosing to use a much lower
performance mode of operation than what was available...if you choose
to use a screwdriver to pound in nails when a hammer is available,
then why concern yourself with the performance differences between
between Phillips, Torx, or flat blade?

>
> I would assume that the other big FPGA company does it the same way.
> They are just not as forthcoming with helpful information.

I seem to recall that company A has documented this as well. I seem
to recall running across it...but doubt that I would ever have a need
to make use of that little tidbit of info.

Kevin Jennings
From: KJ on 13 Dec 2009 19:40
On Dec 13, 4:18 pm, "dlopez" <d...(a)designgame.ca> wrote:
>
> I would have to disagree with you here. There are two modes of operation
> for this chip:
> a) Synchronous: One channel at ~25MB/s.
> b) Asynchronous: Two channels of max ~10MB/s.
>
> This means that the two modes are somewhat similar in terms of performance,

They don't seem that similar to me...

> if one can achieve close to this maximum of 10MB/s.

and it comes with a caveat.

> ...makes software and
> hardware developpement and architecture much easier.

I accept that there may be a benefit to your decision here, the price
being some amount of performance. As I mentioned in the first post is
you have to do the analysis to see if the performance that you can get
from async is acceptable or not. If it isn't, then making
"developpement (sic) and architecture much easier" is a moot point.

>
> This sounds like a reasonnable decision, if I can live with the
> asynchronous performance. In fact, I can, given I stay close to the 10MB/s.

Maybe ask what are the actual system consequences to 8...or 9? So
much performance has already been left on the table already (30 MB/sec
USB sustained system is achievable with other chips and designs).

> I'm trying to find a circuit that will allow me to stay close to this,
> without running at 500GHz, since I'm in a Spartan 3. Maybe 50M or 100M
> would be good.
>

If I recall the spec numbers correctly, you need to guarantee a 50 ns
pulse width and 33 ns dead time. Allowing 5 ns for Tco and another 5
ns for Tsu for the round trip means you need to generate a 60 ns
pulse. An 80 MHz clock (12.5 ns period) would allow you to generate a
62 ns pulse with 37 ns dead time. Two synchronizing flops adds 25 ns
for a total of 124 ns or an 8 MHz rate. Since ultimate performance is
not your goal, cutting development time is (and that's fine, it can
result in getting product sooner), getting 8 MHz out of this
particular async interface is not too bad.

KJ
From: Kolja Sulimma on 14 Dec 2009 10:41
On 13 Dez., 22:18, "dlopez" <d...(a)designgame.ca> wrote:
> I would have to disagree with you here. There are two modes of operation
> for this chip:
> a) Synchronous: One channel at ~25MB/s.
> b) Asynchronous: Two channels of max ~10MB/s.

Assuming that the 25MB/s limit is not from the FIFO but from the USB
source as another poster hinted and the FIFO has 60MB/s bandwidth:
c) 25MB/s when writing 16 bit words to the fifo where the first byte
of the word indicates which stream it belongs to and the 2nd byte is
the stream data.
This is extremely simple to decode on the FPGA side, uses the simpler
synchronous interfaces and allows up to 256 streams.

Kolja Sulimma

From: johnp on 14 Dec 2009 11:26
On Dec 14, 7:41 am, Kolja Sulimma <ksuli...(a)googlemail.com> wrote:
> On 13 Dez., 22:18, "dlopez" <d...(a)designgame.ca> wrote:
>
> > I would have to disagree with you here. There are two modes of operation
> > for this chip:
> > a) Synchronous: One channel at ~25MB/s.
> > b) Asynchronous: Two channels of max ~10MB/s.
>
> Assuming that the 25MB/s limit is not from the FIFO but from the USB
> source as another poster hinted and the FIFO has 60MB/s bandwidth:
> c) 25MB/s when writing 16 bit words to the fifo where the first byte
> of the word indicates which stream it belongs to and the 2nd byte is
> the stream data.
> This is extremely simple to decode on the FPGA side, uses the simpler
> synchronous  interfaces and allows up to 256 streams.
>
> Kolja Sulimma

One thing to consider for the performance is ... can the software
stack really push/pull
data from the USB at these rates. My company has achieved sustained
30MB/sec over
USB using a Cypress FX2, but the s/w driver and application s/w was
non-trivial. In addition,
not all USB host chips are created equal. We saw quite a disparity in
performance caused
by the host USB controller.

So, if the OP is really concerned about 20MB/sec throughput, I hope he
checks that the s/w
drivers won't be his bottleneck.

John Providenza
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Altera LP6 Logic Programming Card - Supplier
Next: XUPV5-LX110T, DDR2, and EDK (10.1 to be precise)