Frustration with Vendors!

Kolja Sulimma
Guest

Sat Feb 27, 2010 1:53 pm

On 27 Feb., 03:30, rickman <gnu...@gmail.com> wrote:
I think we can use one of the mid range

Quote:

values that gives a good trade off of edge rate and overshoot. I
couldn't test one value because I made a mistake and programmed two
boards with the same bit file. Unfortunately the missing one is
likely the one we will want to use. So I'll be back with my customer
Monday with another board.

If there are no transmission line effects involved there will be no
overshoot.
If there are transmission line effect involved I believe that you need
something
more reliable than a output drive setting which might show any sort of
variation
from part to part, over temperature, supply voltage and aging.

DCI would be a good solution, but I guess the part you are using is
not supporting
it so you are trying to mimik it with output drive settings.

Quote:

but the new customer design uses a faster FPGA to receive the clock
Clock lines should always be terminated.

I prefer series terminations, but those are hard to implement on an
existing board.
But on a tqfp package it should be possible to patch a parallel 0201
resistor on the receiving
pin to completly get rid of the overshoot even with the fastest slew
rate setting.

Kolja Sulimma

Symon
Guest

Sat Feb 27, 2010 2:59 pm

On 2/26/2010 10:46 PM, -jg wrote:

Quote:

Why is there no simple Spice pathway to allow users do the 'sanity
check' stuff themselves ?

Because Spice models reveal more about the actual structure of the

device than the vendors are prepared to give. The IBIS table based
method keeps this proprietary information hidden.

Syms.

Symon
Guest

Sat Feb 27, 2010 3:13 pm

On 2/27/2010 11:53 AM, Kolja Sulimma wrote:

Quote:

If there are no transmission line effects involved there will be no
overshoot.

Below, please find a LTSpice model with only lumped components that
produces overshoots.

Quote:

Clock lines should always be terminated.

Not always. For example, if the rise time of the clock is longer than a
sixth of the trace delay, you almost certainly don't need to worry about
termination. If the trace delay is longer than the rise time, you almost
certainly do need to worry about it.

http://www.sigcon.com/Pubs/straight/termcraz.htm

HTH., Syms.

Model:-
Version 4
SHEET 1 880 680
WIRE 176 48 96 48
WIRE 336 48 256 48
WIRE 96 96 96 48
WIRE 336 96 336 48
WIRE 96 208 96 176
WIRE 336 208 336 160
FLAG 96 208 0
FLAG 336 208 0
SYMBOL voltage 96 80 R0
WINDOW 3 -16 165 Left 0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V1
SYMATTR Value PULSE(0 1 0 1n 1n 9n 20n)
SYMBOL ind 272 32 R90
WINDOW 0 5 56 VBottom 0
WINDOW 3 32 56 VTop 0
SYMATTR InstName L1
SYMATTR Value 1n
SYMBOL cap 320 96 R0
SYMATTR InstName C1
SYMATTR Value 10p
TEXT 62 266 Left 0 !.tran 100ns

Symon
Guest

Sat Feb 27, 2010 3:20 pm

On 2/27/2010 2:30 AM, rickman wrote:

Quote:

The problem started when we found the original setting produced a
rising edge so slow that it created multiple pulses on a clock line.
The board worked ok in the original chassis, but the new customer
design uses a faster FPGA to receive the clock and had failures.

I expect the actual failure was the newer FPGA occasionally saw the slow
falling edge of the clock as a rising edge. It sounds like your clock
frequency is low, why don't you just build a falling edge glitch filter
in the new FPGA?

Syms.

austin
Guest

Sat Feb 27, 2010 9:27 pm

Re: Spice

I know that hspice has an interface to allow IBIS models to be
declared, and used, with the spice netlist.

I suspect, "real" spice tool vendors expect one to pay for this sort
of feature, which is not part of the free UC Berkeley spice source
code (on which all the free spice versions are 'based.') So, someone
has to code the .model additions to the spice program to deal with the
IBIS data files. Unless they are doing it for fun, they probably wish
to get paid for their work: I would need some monetary motivaion now,
as coding might have been 'fun' when I was 14 years old, but that was
a long time ago.

So, yes Hyperlynx ia not free, and neither is hspice.

If everything used, free? I can not imagine that everyone out there
is using free schematic, free pcb layout, etc. tools!

Someone might be, but that must be the hobby type, or student
(although students usually have free access to dozens of very powerful
tools, if they would only ask their professor!).

Anyone with a business can certainly justify paying for something
useful, that would save them time (or money).

I am a ham radio operator (AB6VU), and I do have my own collection of
useful free stuff, but even I have purchased some of my hobby software
when necessary (but, I will admit, I don't own any hobby software with
more than a $100 price tag).

Austin

Symon
Guest

Sat Feb 27, 2010 9:53 pm

On 2/26/2010 9:31 PM, austin wrote:

Quote:

Been a long time since I posted something like this... with Peter
Alfke retired from Xilinx, I wear a "white hat" all the time now, and
I am nothing but nice, and helpful (no negativity!).

Who are you, and what have you done with Austin?

Syms. Wink

-jg
Guest

Sat Feb 27, 2010 10:56 pm

On Feb 28, 8:27 am, austin <aus...@xilinx.com> wrote:

Quote:

Re: Spice

I know that hspice has an interface to allow IBIS models to be
declared, and used, with the spice netlist.

I suspect, "real" spice tool vendors expect one to pay for this sort
of feature, which is not part of the free UC Berkeley spice source
code (on which all the free spice versions are 'based.') So, someone
has to code the .model additions to the spice program to deal with the
IBIS data files. Unless they are doing it for fun, they probably wish
to get paid for their work: I would need some monetary motivaion now,
as coding might have been 'fun' when I was 14 years old, but that was
a long time ago.

So, yes Hyperlynx ia not free, and neither is hspice.

If everything used, free? I can not imagine that everyone out there
is using free schematic, free pcb layout, etc. tools!

Someone might be, but that must be the hobby type, or student
(although students usually have free access to dozens of very powerful
tools, if they would only ask their professor!).

Anyone with a business can certainly justify paying for something
useful, that would save them time (or money).

I am a ham radio operator (AB6VU), and I do have my own collection of
useful free stuff, but even I have purchased some of my hobby software
when necessary (but, I will admit, I don't own any hobby software with
more than a $100 price tag).

Austin

You've somewhat missed the point.

Xilinx tools are likely to be free to the vast majority of users.

Xilinx PAY their employees to create models, and the tools.

It's simple common sense for Xilinx to do this once, vs hundreds of
users, having to either call xilinx (and so consume man-hours), or
find a solution themselves.

The spice models do NOT have to be full fab-mosfets ones - as you have
mentioned, the device/temperature/voltage variations already swamp
small tool variations.

If someone wanted to get creative, they could do a competition for the
best IBIS to Spice, with two categories ? :
a) The Simplest, and most portable.
b) A higher level of accuracy

Sounds like a good final year project to me...

-jg

-jg
Guest

Sat Feb 27, 2010 11:03 pm

On Feb 28, 2:59 am, Symon <symon_bre...@hotmail.com> wrote:

Quote:

On 2/26/2010 10:46 PM, -jg wrote:

Why is there no simple Spice pathway to allow users do the 'sanity
check' stuff themselves ?

Because Spice models reveal more about the actual structure of the
device than the vendors are prepared to give. The IBIS table based
method keeps this proprietary information hidden.

hmm.. sounds more like spin/deflection than a real reason, to me.

I did find a useful IBIS resource web page here

http://www.mentor.com/products/pcb-system-design/modeling-resources

includes links to many free resources...

(something FPGA vendors could learn from.. ?)

-jg

John_H
Guest

Sat Feb 27, 2010 11:05 pm

On Feb 27, 3:56 pm, -jg <jim.granvi...@gmail.com> wrote:
<snip>

Quote:

If someone wanted to get creative, they could do a competition for the
best IBIS to Spice, with two categories ? :
a) The Simplest, and most portable.
b) A higher level of accuracy

Sounds like a good final year project to me...

-jg

Or the simplest IBIS simulator with single source, single destination,
simple transmission line. Kind of like what Hyperlinx was back when
you could get a free version.

rickman
Guest

Sun Feb 28, 2010 3:32 am

On Feb 27, 8:59 am, Symon <symon_bre...@hotmail.com> wrote:

Quote:

On 2/26/2010 10:46 PM, -jg wrote:

Why is there no simple Spice pathway to allow users do the 'sanity
check' stuff themselves ?

Because Spice models reveal more about the actual structure of the
device than the vendors are prepared to give. The IBIS table based
method keeps this proprietary information hidden.

Syms.

That is not fully accurate, even if it is many vendors' party line.
Yes, if they create the spice model by describing their actual circuit
in the spice model, it can be reverse engineered. But just like they
generated an IBIS file which only describes the behavior of the IO
port, they can describe the same behavior in a spice model. In fact,
I found one program from Intusoft that will convert an IBIS file into
a spice model. But it has two problems. One is that it generates
only one version of spice code that is not compatible with the spice
program that I use. The other is that it does not work with all
versions of IBIS (including the newest one) so that it won't convert
all IBIS files. Those are both pretty big limitations, but it shows
that a spice model can be created that does not give away proprietary
information.

The vendors simply feel that their customers don't "need" spice
models. That goes back to exactly "who" their customers (or main
customers) really are. The FPGA vendors cater to the comms markets
who buy a lot of FPGAs and also buy the really high end, super
expensive FPGAs. Those guys pretty much don't mind spending $5k on a
tool that gets used a handful of times per year. We smaller
customers, who don't have the cash to spend on a tool that merely
reduces the vendor's inconvenience, prefer using open source tools
that are very well supported, like LTspice, over commercial tools that
are expensive and often poorly supported.

Rick

rickman
Guest

Sun Feb 28, 2010 3:32 am

On Feb 26, 11:25 pm, -jg <jim.granvi...@gmail.com> wrote:

Quote:

On Feb 27, 3:30 pm, rickman <gnu...@gmail.com> wrote:

If Xilinx had an appropriate
part, I likely would have used it. But it is hard to find any FPGAs
in 100 TQFP packages, much less Flash based ones.

Which Flash FPGA in 100 pins did you select?
Actel seem to have good coverage there, and we are about
to trial a ProASIC nano.
Actel also look to be releasing an ARM variant next week.

-jg

Lattice XP3C in the TQ100 package. I much prefer leaded packages for
several reasons and the TQ100 was the largest that would fit on the
board. It also was the smallest I could get. My only other choice
was various BGA type packaging or the really fine pitch QFN devices.
Another reason that most of the non-leaded devices were less than
optimal is that they mostly have more I/Os and so cost more. I could
have used a 256 pin part, but the price is nearly double! Right now I
would love to have the higher gate count I can get in that package,
but I will make do with 3k LUTs.

Rick

rickman
Guest

Sun Feb 28, 2010 4:43 am

On Feb 27, 6:53 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

Quote:

On 27 Feb., 03:30, rickman <gnu...@gmail.com> wrote:
I think we can use one of the mid range

values that gives a good trade off of edge rate and overshoot. I
couldn't test one value because I made a mistake and programmed two
boards with the same bit file. Unfortunately the missing one is
likely the one we will want to use. So I'll be back with my customer
Monday with another board.

If there are no transmission line effects involved there will be no
overshoot.
If there are transmission line effect involved I believe that you need
something
more reliable than a output drive setting which might show any sort of
variation
from part to part, over temperature, supply voltage and aging.

DCI would be a good solution, but I guess the part you are using is
not supporting
it so you are trying to mimik it with output drive settings.

but the new customer design uses a faster FPGA to receive the clock

Clock lines should always be terminated.
I prefer series terminations, but those are hard to implement on an
existing board.
But on a tqfp package it should be possible to patch a parallel 0201
resistor on the receiving
pin to completly get rid of the overshoot even with the fastest slew
rate setting.

Kolja Sulimma

Yes, SI is a complex issue and often simple solutions fail. But in
this case, I am confident we can make it work by controlling the edge
rate. Let's face it. If the device only fails because the edge is
stretched out to 40 ns, I expect we can find a happy medium that works
well even with variation between parts. So far, every edge rate we
have tested, other than the worst case slow, seems to make the board
work. I am going to shoot for one of the faster options which should
give us lots of margin on the current problem as long as we don't get
serious overshoot.

The board does have provision for a series termination. But that is
no magic bullet either. There is a connector about an inch from the
output pin which will produce a reflection that can cause some issues
for faster edge rates regardless of the termination.

I am sure this will work just fine. My only issue is that I had to do
a lot more work investigating this issue than I would have if I simply
had the information I had requested, not to mention the time I spent
fruitlessly trying to get the information.

Rick

rickman
Guest

Sun Feb 28, 2010 4:59 am

On Feb 27, 9:20 am, Symon <symon_bre...@hotmail.com> wrote:

Quote:

On 2/27/2010 2:30 AM, rickman wrote:

The problem started when we found the original setting produced a
rising edge so slow that it created multiple pulses on a clock line.
The board worked ok in the original chassis, but the new customer
design uses a faster FPGA to receive the clock and had failures.

I expect the actual failure was the newer FPGA occasionally saw the slow
falling edge of the clock as a rising edge. It sounds like your clock
frequency is low, why don't you just build a falling edge glitch filter
in the new FPGA?

Syms.

That is not my FPGA, it is my customer's. But he did just that to
investigate the issue before he had scope'd the line and found the
slow edge. He had explored other possibilities first, likely because
this module works in the original system so it wan't the first
suspect. This is not an extremely fast clock. It is a programmable
rate up to 6.144 MHz (half the ref clock of 12.288 MHz). As an input
to my FPGA, I would not be using it as a clock, but rather I would
sample it with a system clock at a higher rate and detect the edge to
use it as an enable for the data and cross it into the system clock
domain. This all by itself would eliminate the noise issue.

In fact, in an unrelated design, my customer told me he has an FPGA
design with 90 clocks and was having trouble with the tools making it
all work!!! I explained to him how to sample the slower clocks with a
single system clock to transport signals across clock domains and I
think he is going to do that.

Rick

rickman
Guest

Sun Feb 28, 2010 5:08 am

On Feb 27, 2:27 pm, austin <aus...@xilinx.com> wrote:

Quote:

Re: Spice

If everything used, free? I can not imagine that everyone out there
is using free schematic, free pcb layout, etc. tools!

Someone might be, but that must be the hobby type, or student
(although students usually have free access to dozens of very powerful
tools, if they would only ask their professor!).

Yes, there are no useful free tools in the world. That is why no FPGA
companies provide tools that run under a free, open source OS like
Linux. ;^)

Quote:

Anyone with a business can certainly justify paying for something
useful, that would save them time (or money).

IF it saved them time and money. Why would you expect that to be true
of all paid tools? Even if there is a time savings, isn't there a
tradeoff? Is the tool worth the price? The price is not just the
money. I have to use a licensed tool for FPGA development and it has
been more than once I spent a lot of time just working around license
issues, which always seem to occur on Friday afternoon when I plan to
work over the weekend!

If I had a choice, I would never use another commercial tool again.
But some tools are just not available... yet.

Maybe the world is not the way you seem to see it???

Rick

rickman
Guest

Sun Feb 28, 2010 5:11 am

On Feb 27, 3:56 pm, -jg <jim.granvi...@gmail.com> wrote:

Quote:

On Feb 28, 8:27 am, austin <aus...@xilinx.com> wrote:

Re: Spice

I know that hspice has an interface to allow IBIS models to be
declared, and used, with the spice netlist.

I suspect, "real" spice tool vendors expect one to pay for this sort
of feature, which is not part of the free UC Berkeley spice source
code (on which all the free spice versions are 'based.') So, someone
has to code the .model additions to the spice program to deal with the
IBIS data files. Unless they are doing it for fun, they probably wish
to get paid for their work: I would need some monetary motivaion now,
as coding might have been 'fun' when I was 14 years old, but that was
a long time ago.

So, yes Hyperlynx ia not free, and neither is hspice.

If everything used, free? I can not imagine that everyone out there
is using free schematic, free pcb layout, etc. tools!

Someone might be, but that must be the hobby type, or student
(although students usually have free access to dozens of very powerful
tools, if they would only ask their professor!).

Anyone with a business can certainly justify paying for something
useful, that would save them time (or money).

I am a ham radio operator (AB6VU), and I do have my own collection of
useful free stuff, but even I have purchased some of my hobby software
when necessary (but, I will admit, I don't own any hobby software with
more than a $100 price tag).

Austin

You've somewhat missed the point.

Xilinx tools are likely to be free to the vast majority of users.

Xilinx PAY their employees to create models, and the tools.

It's simple common sense for Xilinx to do this once, vs hundreds of
users, having to either call xilinx (and so consume man-hours), or
find a solution themselves.

The spice models do NOT have to be full fab-mosfets ones - as you have
mentioned, the device/temperature/voltage variations already swamp
small tool variations.

If someone wanted to get creative, they could do a competition for the
best IBIS to Spice, with two categories ? :
a) The Simplest, and most portable.
b) A higher level of accuracy

Sounds like a good final year project to me...

-jg

Ahhhh... someone who understands me! Thanks.

Rick