EDK : FSL macros defined by Xilinx are wrong

Jim Thompson wrote:

On 25 Nov 2006 15:05:26 -0800, "PeteS" <PeterSmith1954@googlemail.com
wrote:

Jim Thompson wrote:

[snip]

You have it wrong, it's...

Those that can, do.

Those that can't, flip burgers.

Those that can't flip burgers, work check-out at Fry's Electronics.

Those that can't work check-out at Fry's Electronics, teach.

Those that can't teach, become managers.

Those that can't manage, they hang out on S.E.D hiding behind some
hideous nom de plume.

...Jim Thompson

Amusing

I was actually being serious for a moment. Teachers (as opposed to
lecturers) must have a fire inside if they are actually _teachers_. The
best teachers _are_designers, for that reason. I was not always the
most popular, but I was always the most respected.

I happen to respect your abilities (not that I always say so) because I
know what design takes; indeed I am a designer, of boards not chips. Do
you know what it takes to _really_ teach? (that's not a rhetorical
question).

Cheers

PeteS

I taught at a school for technicians from around 1964 until 1974.

And I've given numerous lectures and seminars (I wrote AND taught all
the ICE analog stuff years ago).

I even substituted for Barry Gilbert, when he took ill in 1986 (?,
yep, checked my old passport)), teaching a week-long seminar at the
Royal Melbourne Institute of Technology, teaching bipolar chip design
alongside Willy Sansen, who taught the CMOS stuff.

I offered to teach for free at Scottsdale Community College, but was
turned down... no "teacher's certificate" :-(

And I agree with you, teachers have the "fire". I am where I am now
because of teachers with "fire"... I particularly still fondly
remember Evelyn Truchovesky, my 8th grade Algebra teacher ;-)

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.
I have taught technicians (two year programs and 9 month programs - no,
not that sort of 9 month program) professionally, and the reason they
were successful (at least in part) was because I had (still have) a
fire inside, or so I like to think.

My point about teaching in general is we are (whether we want to or
not) teaching whoever works for us ;)

Let's make sure it's a good education :)

Cheers

PeteS
 
On 26 Nov 2006 16:14:31 -0800, "PeteS" <PeterSmith1954@googlemail.com>
wrote:

Jim Thompson wrote:

[snip]

And I agree with you, teachers have the "fire". I am where I am now
because of teachers with "fire"... I particularly still fondly
remember Evelyn Truchovesky, my 8th grade Algebra teacher ;-)

...Jim Thompson
[snip SIG for non-compliant news client :-]

I have taught technicians (two year programs and 9 month programs - no,
not that sort of 9 month program) professionally, and the reason they
were successful (at least in part) was because I had (still have) a
fire inside, or so I like to think.

My point about teaching in general is we are (whether we want to or
not) teaching whoever works for us ;)

Let's make sure it's a good education :)

Cheers

PeteS
There can be a side benefit... I hired my best technician-class
student. He ended up working for me for 30 years, changing employers
every time I did, worked for Widlar for a few months in 1968 when I
moved from Cupertino back to Phoenix... best technician I've ever
seen, plus he acted as my secretary, cleaning up all my hand-scrawled
drawings, and I still have them to this day ;-)

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.
 
Jim Thompson wrote:
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
You seem to have some analog credentials. Maybe you could divert some
of this thread to answer a question about switched cap voltage
converters.

Where I am currently working we need to convert a wide battery voltage
range to typical circuit voltages, such as 5, 3.3, etc. volts. The
battery voltage varies from 7 to 17 typically. We can used inductive
switchers for this, but it is in a radio and we prefer not to use
these. They are also not so efficient when running at low currents, at
least the ones we can buy as chips. By low I mean <100 mA.

Remembering a chip I had almost used once, it had occured to me that a
switched cap regulator could efficiently convert in a variety of exact
ratios down to a voltage just above the required output and an LDO
could properly regulate to the final voltage for an overall efficiency
that could be a lot better than an inductive switcher. I outlined some
of the capacitor and switch topology to get the various ratios and
determined the input voltage ranges and calculated efficiencies. It
looked pretty good on paper. But then I tried to consider the power
required to drive the various FETs to make the circuit operate and it
looked like it would require a lot of current to drive the gates.

Am I right in thinking that this is where the circuit looses
efficiency? I did my calcs based on the capacitance of the gate. This
seemed to be roughly constant over a lot of parts I looked at that
could handle 100 ma to 1000 ma. Could this be dealt with better in an
ASIC with on chip FETs?

The chip I had seen that did this was a part from TI that only worked
with input voltages up to 5.5 or so. I have not found anything that
works with the higher voltages we need. Any ideas?
 
PeteS wrote:
[Can't post the a.b.s.e. from google which is what I am limited to
until tomorrow night]

I get tired of the insult <-> insult phase of threads (usually found in
any thread exceeding 40 posts, so this one started early) but I am
reminded of Godwin's law ;)

These folk are armed with keyboards and a news account; do not attempt
to approach them; call the authorities and stay well clear ;)

Just kill file any cartoon character you see posting on a newsgroup.


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
 
austin wrote:

I always enjoy reading patents that claim to eliminate metastability.

Seems that the patent office has never figured this one out: they did
make it a law that perpetual motion machines are not patentable, but
there is no such restriction for metastability "eliminators" (all of
which don't work!).
I first heard about metastability in a discussion about the PDP-10
(KA10), which apparently had no metastability problem. The solution
to metastability is asynchronous logic (also called self-timed logic).

That doesn't seem to have convinced very many people, though.

-- glen
 
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:NO-dnQz0batcbvLYnZ2dnUVZ_rOdnZ2d@comcast.com...
austin wrote:

I always enjoy reading patents that claim to eliminate metastability.

Seems that the patent office has never figured this one out: they did
make it a law that perpetual motion machines are not patentable, but
there is no such restriction for metastability "eliminators" (all of
which don't work!).

I first heard about metastability in a discussion about the PDP-10 (KA10),
which apparently had no metastability problem. The solution
to metastability is asynchronous logic (also called self-timed logic).

That doesn't seem to have convinced very many people, though.

-- glen

Hi Glen,
Are you joking around? If not, I'll bite.

I challenge you to design a metastability free traffic light controller from
'metastability solved' asynchronous logic. The lights are at a crossroads
out in the sticks with low traffic volume. They are nomally both set RED
until a car comes along. The lights then go GREEN in the direction from
which a vehicle comes from. Make sure your logic doesn't go metastable when
two cars arrive simultaneously from two orthogonal directions. Your
controller must work no matter with whatever time difference the two cars
arrive, and must work on EVERY occasion for EVERY car arrival timing
scenario. Even one mistake in the lifetime of the universe is FAR, FAR too
often for this junction!

Good luck, Syms.

p.s. I'm really in two minds about posting this, these threads grow like
wildfire, and I don't want to be the arsonist. Needless to say, asynchronous
design is NOT the 'solution' to metastability. Metastability always has a
non-zero probability.
 
glen herrmannsfeldt wrote:

I first heard about metastability in a discussion about the PDP-10
(KA10), which apparently had no metastability problem. The solution
to metastability is asynchronous logic (also called self-timed logic).
The D-flop is also an asynchronous circuit.

-- Mike Treseler
 
Mike Treseler wrote:
glen herrmannsfeldt wrote:

I first heard about metastability in a discussion about the PDP-10
(KA10), which apparently had no metastability problem. The solution
to metastability is asynchronous logic (also called self-timed logic).

The D-flop is also an asynchronous circuit.

-- Mike Treseler
It's amusing that there is, in the strictest sense, no such thing as a
completely synchronous circuit.

Indeed, it is the asynchronous nature of a FF that is the root cause of
metastability ;)

Cheers

PeteS
 
"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:4tb8veF13bjqqU1@mid.individual.net...
glen herrmannsfeldt wrote:

I first heard about metastability in a discussion about the PDP-10
(KA10), which apparently had no metastability problem. The solution
to metastability is asynchronous logic (also called self-timed logic).

The D-flop is also an asynchronous circuit.

Mike,
That's a much better reply than mine! Thanks.
Cheers, Syms.
 
Hi Could you please tell me how did you program the FPGA from the FX2 processor ?

I need the flow(ie binary i need to generate for the FPGA), and the FX2 processor code if possible.

rgds bijoy
 
On 2006-12-04, bijoy <pbijoy@rediffmail.com> wrote:
Hi Could you please tell me how did you program the FPGA from the FX2 processor ?

I need the flow(ie binary i need to generate for the FPGA), and the FX2 processor code if possible.
Hi. Take a look at http://inisyn.org/src/xup/ if you want to configure
a Xilinx FPGA from the FX2 processor.

/Andreas
 
Symon wrote:

(snip on asynchronous (self timed) logic)

I challenge you to design a metastability free traffic light controller from
'metastability solved' asynchronous logic. The lights are at a crossroads
out in the sticks with low traffic volume. They are nomally both set RED
until a car comes along. The lights then go GREEN in the direction from
which a vehicle comes from. Make sure your logic doesn't go metastable when
two cars arrive simultaneously from two orthogonal directions. Your
controller must work no matter with whatever time difference the two cars
arrive, and must work on EVERY occasion for EVERY car arrival timing
scenario. Even one mistake in the lifetime of the universe is FAR, FAR too
often for this junction!
I went back to see what I wrote before. I didn't say that it never went
metastable, only that it wasn't a problem. I was told that sometimes
one would see the console lights stop for a little while until the
metastability was resolved. For the traffic light I would expect a
possible delay from when the cars arrived until one of the lights
turned green. As long as both lights can't turn green at the same time,
you are still safe.

But current FPGAs are not very well designed for self timed logic. All
the flip-flops are completely useless! It has been many years since I
thought about actual designs (when KA-10's were around).

-- glen
 
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:9KydnQ6z6aBF_efYnZ2dnUVZ_rKvnZ2d@comcast.com...
Symon wrote:

(snip on asynchronous (self timed) logic)

I challenge you to design a metastability free traffic light controller
from 'metastability solved' asynchronous logic. The lights are at a
crossroads out in the sticks with low traffic volume. They are nomally
both set RED until a car comes along. The lights then go GREEN in the
direction from which a vehicle comes from. Make sure your logic doesn't
go metastable when two cars arrive simultaneously from two orthogonal
directions. Your controller must work no matter with whatever time
difference the two cars arrive, and must work on EVERY occasion for EVERY
car arrival timing scenario. Even one mistake in the lifetime of the
universe is FAR, FAR too often for this junction!

I went back to see what I wrote before. I didn't say that it never went
metastable, only that it wasn't a problem. I was told that sometimes one
would see the console lights stop for a little while until the
metastability was resolved. For the traffic light I would expect a
possible delay from when the cars arrived until one of the lights
turned green. As long as both lights can't turn green at the same time,
you are still safe.

Hi Glen,
Weeeelll, yes and no! I was just trying to make a point that there is a
finite probability that the lights will stay red until the drivers drop dead
of old age. Not exactly safe! Nearly, but not exactly. :) Likewise, the
PDP-10 console lights _could_ stop for months.
So, I would respectfully disagree with your statement that "The solution to
metastability is asynchronous logic (also called self-timed logic).".
Furthermore, the implication that synchronous design is any worse than
asynchonous design I think is not true. As Mike said in his post, "The
D-flop is also an asynchronous circuit.".
But current FPGAs are not very well designed for self timed logic. All
the flip-flops are completely useless! It has been many years since I
thought about actual designs (when KA-10's were around).

-- glen

Right, I agree you make a good point that FPGAs are not the route to take
for asynchronous logic circuits.
Best regards, Symon.
 
Symon wrote:

(snip)

Weeeelll, yes and no! I was just trying to make a point that there is a
finite probability that the lights will stay red until the drivers drop dead
of old age. Not exactly safe! Nearly, but not exactly. :) Likewise, the
PDP-10 console lights _could_ stop for months.
So, I would respectfully disagree with your statement that "The solution to
metastability is asynchronous logic (also called self-timed logic).".
Furthermore, the implication that synchronous design is any worse than
asynchonous design I think is not true. As Mike said in his post, "The
D-flop is also an asynchronous circuit.".
There is also a finite probability that all the air molecules in
the room will move to the other half of the room. Like metastability
the solution is also exponential.

If you have a mechanical traffic controller, cams springs and such,
then it might last that long. Electrical I don't think so.

Not so long after I learned about metastability, among others
that the lower probability of getting to the metastable state
the longer it stays when it gets there, I was in a shower with
a valve with a spring to turn off when you release it. It would
turn such that it would go over the cam to the other side.
I managed to get it to stop right on top, the metastable state,
long enough to finish a shower.

-- glen
 
nospam wrote:
(someone wrote)
What about injecting noise in the FF feedback loops which is small
enough not to alter their (static)performance, but large enough to drive
the feedback loops (and maybe schmitt triggers) into clipping and thus
their stable state ?

It is an idea I proposed before, without any claim that it would reduce the
occurence metastable states only that it would reduce their duration.
As I understand it, the area under the (probability of going metastable)
vs. (time staying metastable) tends to be constant. It might be that
you can change the distribution enough to make it more useful.

-- glen
 
Hi,
I updated the GTKWave for Win32 port I am maintaining. It's at 3.0.18
now. The missing cygwin dll problem is fixed.

http://www.dspia.com/gtkwave.html
 
mk wrote:
Hi,
I updated the GTKWave for Win32 port I am maintaining. It's at 3.0.18
now. The missing cygwin dll problem is fixed.

http://www.dspia.com/gtkwave.html
Great job. Thanks.

We will use it as viewer of our new Open Logic Analyzer based on the
JTAGkey + FPGA .

Best regards,
Laurent
www.amontec.com
 

Welcome to EDABoard.com

Sponsor

Back
Top