EDK : FSL macros defined by Xilinx are wrong

lecroy7200@chek.com wrote:
<snip>
As per our off-line talks, I have gone ahead and rebuilt the design
using slew limited outputs for the two pins in question. I have begun
running my transient tests but it will be a few weeks before I am
convinced this was the problem.

The following link is to my post about the reflected energy causing
possible problems:

http://groups-beta.google.com/group/comp.arch.fpga/browse_frm/thread/1423e577bf37d509/1f921b2ef9ae4542?q=reflected&rnum=3#1f921b2ef9ae4542

The following was taken from a Xilinx app. note.

"For all FPGA families, ringing signals are not a cause for reliability
concerns. To cause such a problem, the Absolution Maximum DC conditions
need to be violated for a considerable amount of time (seconds). "
snip
That's from a Pin-failure viewpoint. - ie energy damage.
They also spec a MAX peak current.

There IS another failure mode, which is the lateral currents that result
from the clamp diodes ( which are actually side-ways transistors ).
It is not easy to KNOW what peak currents you get, especially on cable
or external runs.

At the highest levels, these injection currents cause latch-up, but
there can be lower levels, where operation is compromised, but the
device does not latch up.

Latchup tests are purely "did the SCR trigger?" ones, they do NOT
(AFAIK) ever check to see if the part logically miss-fired in any way.

-jg
 
Kolja Sulimma wrote:

Most likely that's the way to do it. An alternative would be a
hyperbolic CORDIC, also explained by Ray:
http://www.andraka.com/files/crdcsrvy.pdf

Kolja Sulimma
If I needed high precision or for some reason could not use reasonably
sized look-up tables, I'd consider a hybrid of these two, replacing the
look-up with a CORDIC exp(x) after performing the normalize to strip off
the integer part. The look up method I described in my prior post will
get you plenty of precision for most applications.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
[I've crossposted to comp.arch.fpga, where this question really belongs]

Mark wrote:

We have a particular software system/program
that spends a large fraction of it's time in two or three
particular functions that do lots of trig/geometric and matrix
calculations. Due to the nature of the algorithms they
use, they'll not parallelizable (the computer is a quad cpu box).
Also because the rest of the code depends on the results
from these functions, they are a bottleneck for the rest
of the code that we can split across cpus.

I think I've read that network hardware engineers use
special hardware that allows them to program the hardware
to directly implement code via "Programmable arrays" or something.
What I'd really like is an expansion card that would plug
into the bus and a toolkit so that these few C++ functions
in question would actually be implemented very fast in
hardware and not in software on the unix box. The C++ code
would call the function and the toolkit API would set it
up so that the function call goes to the card, is processed
and the result returned back to the C++ program as the return
looking to the rest of the code like it was done in the app.

I suppose the code for those functions would be dumped in a
binary file on the unix box, then the card would know to
load from the file when instructed to via a api call embedded
in the main application (in a constructor probably). Probably
the toolkit would have a way to define what C++ funcs to
grab to put on the card when the C++ is compiled.

Is this doable? I think Xilinx and other companies make the chips
that do this, but I'm having trouble finding the end companies
that make an actual card we can use.
thanks
Mark
You're going to run into a few problems.

First, FPGAs are programmed (in general) in Verilog/VHDL, not C++.
Anyone know of any real behavioral synthesis from C/C++ tools?

Second, if you're using trig functions, you're going to have to
implement them differently than you would using software. Look up CORDIC
algorithms, for example.

Third, you might not get the speed-ups you expect. It depends on the
chunk of work you're going to offload. It takes a significant amount of
time to dump data to an accelerator card, and then to read the result
back in. It works best if each function call takes a long time to complete.

Fourth, if the code is truly non-parallelizable (i.e. you can't use
SSE2/Altivec and you can't split it across multiple CPUs) then its quite
likely that FPGAs won't help too much. Again, someone more clued in than
me might be able to answer better, but I suspect that the FPUs in the
CPU _MAY_ be better than what you can achieve on a an FPGA (it will
depend on your algorithm etc.)

Out of curiousity, what CPU are you currently using? Also, are you using
double-precision or single-precision FP?

Have you looked at the possibility of speeding up the performance of the
software implementation? In particular, have you looked at how your
trignometric functions are implemented, and whether you can trade
accuracy/precision for perfromance? Unless you're absolutely sure that
the software can't be improved, I wouldn't recommend looking at FPGA
acceleration.
 
On Mon, 04 Apr 2005 11:48:09 -0700, Eric Smith wrote:

Tobias Weingartner wrote:
I doubt it's a matter of patents, but more a matter of licening. The two
are very different beasts.

But if there isn't a patent on an architecture, you don't need a license
to implement it. The purpose of the license is to grant you a right that
was taken away from the patent. If there's no patent, you haven't been
denied the right.
Since this topic has come up, maybe someone could answer this for me:

I've seen publicly available (often open source) cores for other
processors, such as the AVR. Are these sort of cores legal to make,
distribute and use? Supposing I made (from scratch) an msp430 compatible
core for an FPGA - any ideas whether that would be legal or not? I'm
guessing that using the name "msp430" would be a trademark and/or
copyright violation, but if there are no patents involved it should be
okay? Does it make any difference whether it is just used by the
developer, released as an inaccessible part of a closed design, or whether
it is released for free use by others?

mvh.,

David
 
"David" <david.nospam@westcontrol.removethis.com> schrieb im Newsbeitrag
news:pan.2005.04.05.07.04.46.345000@westcontrol.removethis.com...
On Mon, 04 Apr 2005 11:48:09 -0700, Eric Smith wrote:

Tobias Weingartner wrote:
I doubt it's a matter of patents, but more a matter of licening. The
two
are very different beasts.

But if there isn't a patent on an architecture, you don't need a license
to implement it. The purpose of the license is to grant you a right
that
was taken away from the patent. If there's no patent, you haven't been
denied the right.

Since this topic has come up, maybe someone could answer this for me:

I've seen publicly available (often open source) cores for other
processors, such as the AVR. Are these sort of cores legal to make,
distribute and use? Supposing I made (from scratch) an msp430 compatible
its done full soc based on MSP430 compatible core :)
http://bleyer.org/


core for an FPGA - any ideas whether that would be legal or not? I'm
guessing that using the name "msp430" would be a trademark and/or
copyright violation, but if there are no patents involved it should be
okay? Does it make any difference whether it is just used by the
developer, released as an inaccessible part of a closed design, or whether
it is released for free use by others?

mvh.,

David
 
mmkumar@gmail.com wrote:
hi,
in ise, the console window says "synthesis completed" but in the
process for source, it still shows a question mark instead of an
exclamatory mark(excla.. mark for synthesis complete).ans when u click
sysnthesis report , it start the synthesis process all over again..if
any one knows,pls let me know.

~Mack.
I've seen this happen occasionally (ISE 6.3) but performing a dependent
action (like translate after synthesize) does not cause re-synthesis, so
I dont usually care.
 
williams wrote:
Hello Guys,
I had a doubt about the IBUFG and BUFG in xilinx.
1.I have connected clock from oscillator to CLKG IO of the Xilinx. In
this case is it required to instantiate the IBUFG inside my code
also?.
2. The DCM output is already BUFG i think and so is it required to
BUFG again in my code?

Thanks and regards
Williams
If you manually insert BUFGs and IBUFGs, the tools will not try to
insert another one, so put them in to make sure. Otherwise you can find
that later on, when your design becomes more dense, your clock can
suddenly be put onto longlines or even local routing.

-Jim

PS, I think your post belongs only on comp.arch.fpga, the others are for
language specific questions.
 
"Ziggy" <Ziggy@TheCentre.com> wrote in message
news:XYS3e.131292$r55.32410@attbi_s52...
Eric Smith wrote:
. A reproduction of a 486 or base Pentium would
be plenty for what i want to do.
Not being a top authority on soft core I'll still observeve that:

1. Implementing a CISC CPU is much more resource consuming than implementing
a RISC core.
2. x86 is way crazy because of the need to maintain compatibility with the
8086's real mode.

In late 80's Intel made a special version of 386 (385 if I remember right)
that was basically a 368 without the real mode.
It was much cheaper than a 386 but there were no takers: x86 is used so much
only because of the huge volume of written code,
not because it is a good architecture.
If I had to go the CISC way, I'd much rather clone a 68000. Just as much
software written and a considerably better
instruction set.


--
-Alex.
 
On Tue, 05 Apr 2005 09:46:07 +0200, Antti Lukats wrote:

"David" <david.nospam@westcontrol.removethis.com> schrieb im Newsbeitrag
news:pan.2005.04.05.07.04.46.345000@westcontrol.removethis.com...
On Mon, 04 Apr 2005 11:48:09 -0700, Eric Smith wrote:

Tobias Weingartner wrote:
I doubt it's a matter of patents, but more a matter of licening. The
two
are very different beasts.

But if there isn't a patent on an architecture, you don't need a license
to implement it. The purpose of the license is to grant you a right
that
was taken away from the patent. If there's no patent, you haven't been
denied the right.

Since this topic has come up, maybe someone could answer this for me:

I've seen publicly available (often open source) cores for other
processors, such as the AVR. Are these sort of cores legal to make,
distribute and use? Supposing I made (from scratch) an msp430 compatible

its done full soc based on MSP430 compatible core :)
http://bleyer.org/
I'd have been surprised if it hadn't been done, given that the msp430 core
is a solid 16-bit core with a good gcc port and a (relatively) clean
instruction set and programming model. I was, however, more interested in
knowing where such a core stands legally (although I will also have a look
at the core sometime for curiosity - and the site you gave has a few other
interesting links).

core for an FPGA - any ideas whether that would be legal or not? I'm
guessing that using the name "msp430" would be a trademark and/or
copyright violation, but if there are no patents involved it should be
okay? Does it make any difference whether it is just used by the
developer, released as an inaccessible part of a closed design, or whether
it is released for free use by others?

mvh.,

David
 
"Ziggy" <Ziggy@TheCentre.com> schrieb im Newsbeitrag
news:Yww4e.13712$Vx1.3133@attbi_s01...
Alex Freed wrote:
"Ziggy" <Ziggy@TheCentre.com> wrote in message
news:XYS3e.131292$r55.32410@attbi_s52...

Eric Smith wrote:
. A reproduction of a 486 or base Pentium would
be plenty for what i want to do.


Not being a top authority on soft core I'll still observeve that:

1. Implementing a CISC CPU is much more resource consuming than
implementing
a RISC core.
2. x86 is way crazy because of the need to maintain compatibility with
the
8086's real mode.

In late 80's Intel made a special version of 386 (385 if I remember
right)
that was basically a 368 without the real mode.
It was much cheaper than a 386 but there were no takers: x86 is used so
much
only because of the huge volume of written code,
not because it is a good architecture.
If I had to go the CISC way, I'd much rather clone a 68000. Just as much
software written and a considerably better
instruction set.


But in todays world, does anything actually use
the 'real mode' on an x86 chip?

Though i do agree that the 68k is a much better
chip, the x86 has a larger 'generic' software
base.

I think the 68k has been done however.. I just
dont remember where i saw that at.
something is at opencores not sure how useabe it is

antti
 
Alex Freed wrote:
"Ziggy" <Ziggy@TheCentre.com> wrote in message
news:XYS3e.131292$r55.32410@attbi_s52...

Eric Smith wrote:
. A reproduction of a 486 or base Pentium would
be plenty for what i want to do.


Not being a top authority on soft core I'll still observeve that:

1. Implementing a CISC CPU is much more resource consuming than implementing
a RISC core.
2. x86 is way crazy because of the need to maintain compatibility with the
8086's real mode.

In late 80's Intel made a special version of 386 (385 if I remember right)
that was basically a 368 without the real mode.
It was much cheaper than a 386 but there were no takers: x86 is used so much
only because of the huge volume of written code,
not because it is a good architecture.
If I had to go the CISC way, I'd much rather clone a 68000. Just as much
software written and a considerably better
instruction set.


But in todays world, does anything actually use
the 'real mode' on an x86 chip?

Though i do agree that the 68k is a much better
chip, the x86 has a larger 'generic' software
base.

I think the 68k has been done however.. I just
dont remember where i saw that at.
 
"David" wrote ...

its done full soc based on MSP430 compatible core :)
http://bleyer.org/


I'd have been surprised if it hadn't been done, given that the msp430 core
is a solid 16-bit core with a good gcc port and a (relatively) clean
instruction set and programming model. I was, however, more interested in
knowing where such a core stands legally (although I will also have a look
at the core sometime for curiosity - and the site you gave has a few other
interesting links).

And the msp430 is a simplified version of the pdp-11. Unlicensed?
 
Antti Lukats wrote:
"Ziggy" <Ziggy@TheCentre.com> schrieb im Newsbeitrag
news:Yww4e.13712$Vx1.3133@attbi_s01...

Alex Freed wrote:

"Ziggy" <Ziggy@TheCentre.com> wrote in message
news:XYS3e.131292$r55.32410@attbi_s52...


Eric Smith wrote:
. A reproduction of a 486 or base Pentium would
be plenty for what i want to do.


Not being a top authority on soft core I'll still observeve that:

1. Implementing a CISC CPU is much more resource consuming than

implementing

a RISC core.
2. x86 is way crazy because of the need to maintain compatibility with

the

8086's real mode.

In late 80's Intel made a special version of 386 (385 if I remember

right)

that was basically a 368 without the real mode.
It was much cheaper than a 386 but there were no takers: x86 is used so

much

only because of the huge volume of written code,
not because it is a good architecture.
If I had to go the CISC way, I'd much rather clone a 68000. Just as much
software written and a considerably better
instruction set.



But in todays world, does anything actually use
the 'real mode' on an x86 chip?

Though i do agree that the 68k is a much better
chip, the x86 has a larger 'generic' software
base.

I think the 68k has been done however.. I just
dont remember where i saw that at.


something is at opencores not sure how useabe it is

antti



I think you saw the 6800 core.. i dont think there is a 68000 core
unless i missed something, which is always possible.
 
"Ziggy" <Ziggy@TheCentre.com> schrieb im Newsbeitrag
news:jOx4e.13997$Vx1.6361@attbi_s01...
Antti Lukats wrote:
"Ziggy" <Ziggy@TheCentre.com> schrieb im Newsbeitrag
news:Yww4e.13712$Vx1.3133@attbi_s01...

Alex Freed wrote:

"Ziggy" <Ziggy@TheCentre.com> wrote in message
news:XYS3e.131292$r55.32410@attbi_s52...


Eric Smith wrote:
. A reproduction of a 486 or base Pentium would
be plenty for what i want to do.


Not being a top authority on soft core I'll still observeve that:

1. Implementing a CISC CPU is much more resource consuming than

implementing

a RISC core.
2. x86 is way crazy because of the need to maintain compatibility with

the

8086's real mode.

In late 80's Intel made a special version of 386 (385 if I remember

right)

that was basically a 368 without the real mode.
It was much cheaper than a 386 but there were no takers: x86 is used so

much

only because of the huge volume of written code,
not because it is a good architecture.
If I had to go the CISC way, I'd much rather clone a 68000. Just as
much
software written and a considerably better
instruction set.



But in todays world, does anything actually use
the 'real mode' on an x86 chip?

Though i do agree that the 68k is a much better
chip, the x86 has a larger 'generic' software
base.

I think the 68k has been done however.. I just
dont remember where i saw that at.


something is at opencores not sure how useabe it is

antti



I think you saw the 6800 core.. i dont think there is a 68000 core
unless i missed something, which is always possible.
http://www.opencores.com/projects.cgi/web/k68/overview

68K
but as said I have not evaluated it, so not sure how useable it is

antti
 
Antti Lukats wrote:
"Ziggy" <Ziggy@TheCentre.com> schrieb im Newsbeitrag
news:jOx4e.13997$Vx1.6361@attbi_s01...

Antti Lukats wrote:

"Ziggy" <Ziggy@TheCentre.com> schrieb im Newsbeitrag
news:Yww4e.13712$Vx1.3133@attbi_s01...


Alex Freed wrote:


"Ziggy" <Ziggy@TheCentre.com> wrote in message
news:XYS3e.131292$r55.32410@attbi_s52...



Eric Smith wrote:
. A reproduction of a 486 or base Pentium would
be plenty for what i want to do.


Not being a top authority on soft core I'll still observeve that:

1. Implementing a CISC CPU is much more resource consuming than

implementing


a RISC core.
2. x86 is way crazy because of the need to maintain compatibility with

the


8086's real mode.

In late 80's Intel made a special version of 386 (385 if I remember

right)


that was basically a 368 without the real mode.
It was much cheaper than a 386 but there were no takers: x86 is used so

much


only because of the huge volume of written code,
not because it is a good architecture.
If I had to go the CISC way, I'd much rather clone a 68000. Just as

much

software written and a considerably better
instruction set.



But in todays world, does anything actually use
the 'real mode' on an x86 chip?

Though i do agree that the 68k is a much better
chip, the x86 has a larger 'generic' software
base.

I think the 68k has been done however.. I just
dont remember where i saw that at.


something is at opencores not sure how useabe it is

antti




I think you saw the 6800 core.. i dont think there is a 68000 core
unless i missed something, which is always possible.


http://www.opencores.com/projects.cgi/web/k68/overview

68K
but as said I have not evaluated it, so not sure how useable it is

antti




Wonder how i missed it.. tks
 
Hi everybody!

Does somebody found a solution. I have the same problem

MArtin
 
In article <qhpsxanzti.fsf@ruckus.brouhaha.com>, Eric Smith wrote:
But if there isn't a patent on an architecture, you don't need a license
to implement it. The purpose of the license is to grant you a right that
was taken away from the patent. If there's no patent, you haven't been
denied the right.
No, you are wrong. I do not need a patent on my IP in order for me to
license it to you. It's called copyright.

--
[100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
 
I wrote:
But if there isn't a patent on an architecture, you don't need a license
to implement it. The purpose of the license is to grant you a right that
was taken away from the patent. If there's no patent, you haven't been
denied the right.
["from the patent" was supposed to read "by the patent"]

Tobias Weingartner wrote:
No, you are wrong. I do not need a patent on my IP in order for me to
license it to you. It's called copyright.
You can't copyright an idea. You can only copyright a specific expression
of an idea.

If you invent a new processor architecture, and publish the architecture
specifications, copyright does not prevent me from designing my own
processor compatible with your specifications. This is a very well-
established principle of US copyright law, and AFAIK the copyright
laws of most other countries work similarly.

If you published Verilog code for your core, that could be copyrighted,
and I wouldn't be able to use your Verilog code without a license,
though I could still write my own.

On the other hand, patents *do* protect ideas. If you patent a feature
of your processor architecture, I can't use it without a license. If
you have a patent that doesn't apply to the architecture, but only to
a feature of your implementation (e.g., your Verilog design), I could
either license that patent or try to figure out a different way to
implement the architecture that didn't infringe your patent. For instance,
if your processor architecture had an (unpatented) multiply-by-37
instruction, but you have a very clever patented multiply-by-37 circuit,
and I didn't want to license your patent, I could still design my
own processor compatible with your architecture by using a different
(probably less clever) multiply-by-37 circuit.
 
"Alex Freed" <alexf@mirrow.com> writes:
"Ziggy" <Ziggy@TheCentre.com> wrote in message
news:XYS3e.131292$r55.32410@attbi_s52...
Eric Smith wrote:
. A reproduction of a 486 or base Pentium would
be plenty for what i want to do.
Careful with those quotes/attributions! Eric Smith didn't say
any such thing!
 
What if you route an IBUFG input pin to a regular BUF?...will the tools
still treat it as global clock?


"Jim George" <send_no_spam_to_jimgeorge@gmail.com> wrote in message
news:J8udnYxr4psU1s_fRVn-1w@comcast.com...
williams wrote:
Hello Guys,
I had a doubt about the IBUFG and BUFG in xilinx.
1.I have connected clock from oscillator to CLKG IO of the Xilinx. In
this case is it required to instantiate the IBUFG inside my code
also?.
2. The DCM output is already BUFG i think and so is it required to
BUFG again in my code?

Thanks and regards
Williams

If you manually insert BUFGs and IBUFGs, the tools will not try to
insert another one, so put them in to make sure. Otherwise you can find
that later on, when your design becomes more dense, your clock can
suddenly be put onto longlines or even local routing.

-Jim

PS, I think your post belongs only on comp.arch.fpga, the others are for
language specific questions.
 

Welcome to EDABoard.com

Sponsor

Back
Top