Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 36025

Article: 36025
Subject: Re: Xilinx XST vs FPGA Express?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 26 Oct 2001 07:51:59 -0700
Links: << >>  << T >>  << A >>

--------------F7D174BCB1B01A22B32807B8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

This may sound like a highly biased opinion, but bear with me.

We typically use both the PC and Unix based tools in the FPGA Lab to
verify, characterize, and troubleshoot.  As such, we get a good flavor of
the tools, and since we have to use them before you get to, we also
generate a pretty good stream of "bug reports" so that the overall quality
is better when the products are released.

The choice of synthesis tool is not easy.  We have tried to use every
single one sometimes in order to solve some very difficult problems.
Sometimes one is better that the other.  Soemtimes one doesn't work at
all.  Recently, we have a number of excellent results with XST in Virtex
II.

We certainly tell the other synthesis vendors all about our features at
the same time the XST team hears about them, but perhaps the XST team is
motivated to guide the way, and show everyone how it is done.

I would expect ever increasing quality of results by all of the synthesis
vendors with time.

It is a glib answer, but true, which tool is best?  The one that worked.

I am definitely interested in other reports of how the synthesis tools
stack up -- as I find I have to fight all of them sometimes.

Austin
FPGA Lab Manager
Xilinx

David Rogoff wrote:

> Need some opinions:
>
> I've been using ISE3.1/FPGA Express on a PC.  I'm about to upgraded to
> ISE4.1 but I'm not sure which way to go.  There is a Solaris version,
> which would be great in many ways, but there is no FPGA Express for
> Unix, only XST.  So, I'd like information on the performance of XST
> compared to FPGA Express.
>
> Thanks,
>
>  David

--------------F7D174BCB1B01A22B32807B8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David,
<p>This may sound like a highly biased opinion, but bear with me.
<p>We typically use both the PC and Unix based tools in the FPGA Lab to
verify, characterize, and troubleshoot.&nbsp; As such, we get a good flavor
of the tools, and since we have to use them before you get to, we also
generate a pretty good stream of "bug reports" so that the overall quality
is better when the products are released.
<p>The choice of synthesis tool is not easy.&nbsp; We have tried to use
every single one sometimes in order to solve some very difficult problems.&nbsp;
Sometimes one is better that the other.&nbsp; Soemtimes one doesn't work
at all.&nbsp; Recently, we have a number of excellent results with XST
in Virtex II.
<p>We certainly tell the other synthesis vendors all about our features
at the same time the XST team hears about them, but perhaps the XST team
is motivated to guide the way, and show everyone how it is done.
<p>I would expect ever increasing quality of results by<b> all </b>of the
synthesis vendors with time.
<p>It is a glib answer, but true, which tool is best?&nbsp; The one that
worked.
<p>I am definitely interested in other reports of how the synthesis tools
stack up -- as I find I have to fight all of them sometimes.
<p>Austin
<br>FPGA Lab Manager
<br>Xilinx
<p>David Rogoff wrote:
<blockquote TYPE=CITE>Need some opinions:
<p>I've been using ISE3.1/FPGA Express on a PC.&nbsp; I'm about to upgraded
to
<br>ISE4.1 but I'm not sure which way to go.&nbsp; There is a Solaris version,
<br>which would be great in many ways, but there is no FPGA Express for
<br>Unix, only XST.&nbsp; So, I'd like information on the performance of
XST
<br>compared to FPGA Express.
<p>Thanks,
<p>&nbsp;David</blockquote>
</html>

--------------F7D174BCB1B01A22B32807B8--


Article: 36026
Subject: Re: future Xilinx products wish list ...
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 26 Oct 2001 11:13:38 -0400
Links: << >>  << T >>  << A >>
"Tim" <tim@rockylogic.com.nospam.com> wrote in message
news:1003014453.18501.1.nnrp-10.9e9832fa@news.demon.co.uk...
> <hamish@cloud.net.au> wrote
> > Tim <tim@rockylogic.com.nospam.com> wrote:
> > > Maybe the long term plan is to configure/readback the big stuff
> > > via JTAG only - the details of ROM handling can be farmed out to a
> > > PAL.
> >
> > Won't that be painfully slow for large devices?
>
> I guess.  For the XC2V10000 the times work out as
>   JTAG         1000ms  (33MHz, 1-bit)
>   Slave Serial  500ms  (66MHz, 1-bit)
>   SelectMap      60ms  (66MHz, 8-bit)
>
> Since this is a high-speed serial world, and JTAG is usually
> limited to <50MHz (33MHz on Virtex) the future is presumably
> a smart JTAG extension.

I haven't used JTAG for FPGA download yet, but I've heard that it takes much
longer than the configuration bits divided by the JTAG clock rate due to the
protocol overhead. Can anyone with experience using JTAG comment?

Regards,
Jamie



Article: 36027
Subject: Re: How to make an implementable big counter?
From: Graham
Date: Fri, 26 Oct 2001 15:15:40 GMT
Links: << >>  << T >>  << A >>
Jerre

How long a delay do you want and what will be the clock speed of the
counter. If the frequency is secret i.e. (you can't give an exact
figure because it is for a military application) then just give a
figure which is relatively close



On 25 Oct 2001 02:06:39 -0700, duvister@hotmail.com (Jerre) wrote:

>Hello,
>
>In my design I need to make a synchronous counter that counts, let's
>say, till 1000000. (Actual aim for counter is to built in a delay).  I
>do this by the use of integer type signals and with each clock'event I
>add 1 till I reach the wanted 1000000.  When I try to implement this
>in an FPGA it consumes a very high amount of CLBs and it seems very
>disastrous for the maximum reachable clock freq.
>
>If I would use an unsigned type would it differ a lot?
>
>Other tips?
>
>Greetz from a newbie,
>
>Jerre.

Graeme

Article: 36028
Subject: Re: How to make an implementable big counter?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 26 Oct 2001 16:20:50 GMT
Links: << >>  << T >>  << A >>
For long duration timers, there is a much more elegant solution than simply
using a binary counter.  In Xilinx parts, you can use the CLBs as small
shift registers, at up to 17 bits per LUT.   Use these to construct an LFSR
(refer to XAPP 052 for the feedback arrangement).  The LFSR gives you a
very compact counter that can take literally thousands of years to repeat
even with a maximum frequency clock.  Of course, to be useful, you need to
decode a terminal count.  For a periodic duration timer, we can detect the
all '0's state by counting consecutive zeros generated by the LFSR, using a
down counter that gets reloaded with the number of bits in the LFSR each
time a '1' bit comes out of the LFSR.  When that counter reaches zero, your
overall timer has cycled.  The down counter only needs to be long enough to
count the number of bits in the LFSR.  For an extreme example, a 63 bit
LFSR repeats after 2^63-1 clocks, which at 100 MHz is over 2000 years.  In
this case, the down counter only has to count to 63, so it is a mere 6
bits.  By using 62 as the load value and adding a 7th bit, you can use the
7th bit as a the terminal count (goes high when counter counts past zero).
This extreme example of a 2000+ year count duration only occupies about 3
Virtex CLBs.  The clock rate is limited by the minimum pulse width spec for
the SRL'16, so you can basically clock  it as fast as you want without
hitting timing problems.

The LFSR scheme is limited in the duration values it can generate
(basically 2^(n-1) clocks.  In a more typical case, you can use the above
LFSR scheme to generate a clock enable for a more conventional counter at
say, 1 second or 1  minute intervals (you'll probably actually end up with
some fraction of your time unit).



Graham wrote:

> Jerre
>
> How long a delay do you want and what will be the clock speed of the
> counter. If the frequency is secret i.e. (you can't give an exact
> figure because it is for a military application) then just give a
> figure which is relatively close
>
> On 25 Oct 2001 02:06:39 -0700, duvister@hotmail.com (Jerre) wrote:
>
> >Hello,
> >
> >In my design I need to make a synchronous counter that counts, let's
> >say, till 1000000. (Actual aim for counter is to built in a delay).  I
> >do this by the use of integer type signals and with each clock'event I
> >add 1 till I reach the wanted 1000000.  When I try to implement this
> >in an FPGA it consumes a very high amount of CLBs and it seems very
> >disastrous for the maximum reachable clock freq.
> >
> >If I would use an unsigned type would it differ a lot?
> >
> >Other tips?
> >
> >Greetz from a newbie,
> >
> >Jerre.
>
> Graeme

--
--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



Article: 36029
Subject: Bi directional pin
From: sriram_bkr@rediffmail.com (R.Sriram)
Date: 26 Oct 2001 09:39:52 -0700
Links: << >>  << T >>  << A >>
Hi there,
        I am working on interfacing an FPGA to the serial port of
ADSP-2105. How do i use inouts in VHDL. It does not work well with
Simulation. Are there any other solutions.

Thanking in Advance,
R.Sriram

Article: 36030
Subject: Re: S/PDIF interface for FPGA
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Fri, 26 Oct 2001 18:52:14 +0200
Links: << >>  << T >>  << A >>
Robert Staven schrieb:
> 
> The jitter thing is kinda 'religiously' theme for some audio people.

Yes, you should better use twin shielded golden coax cable.
For the power supply ;-)

> But for me, it's ok as long the jitter (to the 'DAC') stays withing
> (the equal to) 1/2 - 1 LSB of my signal.

I think you got something wrong. Jitters does NOT mean an error in the
sampling value, it means an error in sampling TIME.

-- 
MFG
Falk


Article: 36031
Subject: Re: LUT Glitches
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 26 Oct 2001 17:33:26 GMT
Links: << >>  << T >>  << A >>
Bob Perlman <bob@cambriandesign.com> writes:

>On 24 Oct 2001 02:18:47 GMT, gah@ugcs.caltech.edu (glen
>herrmannsfeldt) wrote:

>>Bob Perlman <bob@cambriandesign.com> writes:
>>
>>>You can build glitch filters with tapped delay lines and majority
>>>detection logic, but with an important caveat.  These filters will
>>>eliminate pulses shorter than X ns and pass pulses longer than Y ns,
>>>but X and Y aren't the same number.  In between X and Y, the circuit
>>>can misbehave; there's a range of pulse durations that can produce
>>>glitches at the output of the filter.  
>>
>>>If there were such a thing as a perfect glitch filter, we could build
>>>a metastable-proof flip-flop by filtering out runt pulses.  Were it
>>>that it were.
>>
>>The original question asked about asynchronous logic, which doesn't
>>have a metastability problem.  Asynchronous logic, also called self
>>timed logic, runs as fast as gates can change.  Look up self-timed
>>logic somewhere.

>I wasn't responding to the original question (this is Usenet, after
>all), but to the comment about building glitch filters from tapped
>delay lines.  Nor was I claiming that self-timed logic was inherently
>susceptible to metastability.

>What do I think of self-timed logic?  Read this:

>http://www.isdmag.com/editorial/2000/feedback0007.html

Sorry for the confusion.  It is sometimes hard to figure which
direction a thread is going in.  OK, I read the editorial, and
the replies to it.  I think I agree with all of them.

One is that the current design tools are designed around synchronous
logic, making it hard to do non-synchronous designs.  (I have never
done a self-timed logic design, but I used to talk about it with people
who had done it.  Otherwise I wouldn't know about it at all.)

It might be, as one reply says, it is like RISC, where the time came
and, after looking for a while in disbelief, everyone finally jumped on.

I was just considering how, without a clock frequency to advertize how
are companies going to convince people that their new processor is the
fastest?  The marketing department might kill anything asynchronous!

I used to hear stories that the PDP-10 was asynchronous, but I have
now found that other PDP-10 stories were false, so that one may be also.

-- glen

Article: 36032
Subject: Re: Probing BGA Designs
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 26 Oct 2001 10:47:58 -0700
Links: << >>  << T >>  << A >>
Don Stauffer wrote:
> 
> Does anyone have experience debugging FPGA designs in BGA packages at
> the board-level? Since there are no pins, what have people found that
> works? Any ideas are greatly appreciated, including advice on DFT at
> the board level (unused I/O routed to test pins, SignalTap/ChipScope,
> etc.).

Have every BGA net (used or not) 
include a probeable pin, feedthru or other
component. 

Have the vendor verify the bare board to the 
netlist before it is loaded. 

   --Mike Treseler

Article: 36033
Subject: Re: S/PDIF interface for FPGA
From: Ray Andraka <ray@andraka.com>
Date: Fri, 26 Oct 2001 17:58:56 GMT
Links: << >>  << T >>  << A >>
Yes, jitter is an error in the sample time, but that translates to an
error in the sampled value..  If it does not, then the jitter is of no
consequence since the sampled signal varies too slowly to be affected by
uncertainty in the sampling time.  If you know the maximu frequency of
your sampled signal and you know the maximum jitter specification, you can
easily compute the worst case amplitude error due to the variations in the
sample time.

This becomes painfully apparent in designs where you are intentionally
undersampling a bandlimited signal.



Falk Brunner wrote:

> Robert Staven schrieb:
> >
> > The jitter thing is kinda 'religiously' theme for some audio people.
>
> Yes, you should better use twin shielded golden coax cable.
> For the power supply ;-)
>
> > But for me, it's ok as long the jitter (to the 'DAC') stays withing
> > (the equal to) 1/2 - 1 LSB of my signal.
>
> I think you got something wrong. Jitters does NOT mean an error in the
> sampling value, it means an error in sampling TIME.
>
> --
> MFG
> Falk

--
--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



Article: 36034
Subject: Re: Bi directional pin
From: "C.Schlehaus" <carlhermann.schlehaus@t-online.de>
Date: Fri, 26 Oct 2001 20:02:05 +0200
Links: << >>  << T >>  << A >>
Hi,

"R.Sriram" <sriram_bkr@rediffmail.com> schrieb im Newsbeitrag
news:b288c584.0110260839.401c62d9@posting.google.com...
> Hi there,
>         I am working on interfacing an FPGA to the serial port of
> ADSP-2105. How do i use inouts in VHDL. It does not work well with
> Simulation. Are there any other solutions.
>

Well normally You delcare the pin as an INOUT (let's assume it's
Pin 'X') and if You want to use it as an Output You write

X <= something;

while using it as an input means

something <= X;

Tristate is normally done by

X <= 'Z';

Of course in simulation this is splitted in two signals, one
acting as Input and the second as Output. Everytime, the pin
is used as output, You have to declare the input signals as
"Undefined", otherwise the simulator would state a "contention".

HTH, Carlhermann



Article: 36035
Subject: Re: How to make an implementable big counter?
From: John_H <johnhandwork@mail.com>
Date: Fri, 26 Oct 2001 18:03:54 GMT
Links: << >>  << T >>  << A >>
Very nicely commented.  The terminal count detector is sometimes overlooked
until implementation.

There's way to provide *any* delay that would add a little overhead, but not a
huge amount.  Use CLB ROMs to establish an initial value in the shift register
that corresponds to the shift register value at your precise time delay before
terminal count.  There's a little extra work to figure out the preload value
but it's very doable.  The math isn't 5 minutes of work (unless you're an
expert on this stuff) but one can produce what the nth shift register value is
after any shift register value in the sequence mathematically to avoid waiting
over 924 years to find what the right value is to preload the 2^63-1 counter
for precisely 2000 years delay.

However it seems your approach of an LFSR prescaler for a much smaller counter
is a better tradeoff of development time versus resources!  Very nice balance
with precision versus magnitude.


Ray Andraka wrote:

> The LFSR scheme is limited in the duration values it can generate
> (basically 2^(n-1) clocks.  In a more typical case, you can use the above
> LFSR scheme to generate a clock enable for a more conventional counter at
> say, 1 second or 1  minute intervals (you'll probably actually end up with
> some fraction of your time unit).


Article: 36036
Subject: Re: Bi directional pin
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 26 Oct 2001 11:11:23 -0700
Links: << >>  << T >>  << A >>
"R.Sriram" wrote:
> 
> Hi there,
>         I am working on interfacing an FPGA to the serial port of
> ADSP-2105. How do i use inouts in VHDL. 

To drive a tri-state pin, you need a
port of type inout,
an enable signal and
a driving signal.

Here is a typical driving process:

databus_io <= mux_sig when oe_n = '0' else (others =>'Z');

   --Mike Treseler

Article: 36037
Subject: Re: S/PDIF interface for FPGA
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Fri, 26 Oct 2001 20:16:01 +0200
Links: << >>  << T >>  << A >>
Ray Andraka schrieb:
> 
> Yes, jitter is an error in the sample time, but that translates to an
> error in the sampled value..  If it does not, then the jitter is of no
> consequence since the sampled signal varies too slowly to be affected by
> uncertainty in the sampling time.  If you know the maximu frequency of
> your sampled signal and you know the maximum jitter specification, you can
> easily compute the worst case amplitude error due to the variations in the
> sample time.

Right, but that was not quite the point here. It was about driving a DAC
with a jittery clock, which cases FM and so distortions. In the HIGH-end
HIFI voodoo scene, this is heavyly discussed ;-)
I dont know how serious this problem is, and I also didnt make any
investigation about the theoretical aspects.
Anyone got some basic numbers?
How much does a jitter of lets say 10ns affect the audio quality when
sampling (RECONSTRUCTING) at 44.1kHz (22.6 us period, so 10ns is just
0.04% timing error)

-- 
MFG
Falk


Article: 36038
Subject: Re: LUT Glitches
From: Neil Franklin <neil@franklin.ch.remove>
Date: 26 Oct 2001 23:32:56 +0200
Links: << >>  << T >>  << A >>
gah@ugcs.caltech.edu (glen herrmannsfeldt) writes:
>
> It might be, as one reply says, it is like RISC, where the time came
> and, after looking for a while in disbelief, everyone finally jumped on.

Everyone except Intel, who makes 90% of all PC-sized processors :-).


> I was just considering how, without a clock frequency to advertize how
> are companies going to convince people that their new processor is the
> fastest?  The marketing department might kill anything asynchronous!

Switch to real app level benchmarks, like SPEC?

AMD is already trying to do this, because their Athlon design is lower
clock/power than Intels P4.


> I used to hear stories that the PDP-10 was asynchronous, but I have
> now found that other PDP-10 stories were false, so that one may be also.

The earlier PDP-10s CPU models (166, KA-10) were hardwired async, they
then switched to hardwired sync (KI-10) and later to microcoded sync
(KL-10 and KS-10).

Data from:

http://www.inwap.com/pdp10/models.txt

Year announced          1964    1967    1972  1978    cancel  1994
CPU type                166     KA      KI    KS      KC      XKL-1
Clock speed nanoseconds Async   Async   110   50      Fast    30

Year announced          1974    1974    ?78?    1981   1976    ?78?    1976    ?78?    ?81?    ?84?
CPU type                KL-A    KL-B    KL-D    KL-E   KL-C    KL-D    KL-C    KL-D    KL-E    KL-R
Model-B backplane ucode No      No      Yes     Yes    No      Yes     No      Yes     Yes     PW
Clock speed nanoseconds 40      40      33      33     40      33      40      33      33      33


P.S. I am working (hobby, so slowly) on cloning the KI-10 in an Spartan-II:

http://neil.franklin.ch/Projects/PDP-10/


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery

Article: 36039
Subject: Cloning someone else's IP core
From: kevinbraceusenet@hotmail.com (Kevin Brace)
Date: 26 Oct 2001 14:44:43 -0700
Links: << >>  << T >>  << A >>
I will like to know what happens when someone designs a compatible IP
core of someone else's IP core?
The design techniques used for designing such a compatible IP core
will not be analysing a netlist, but designing a compatible IP through
publically available information like a third party specification
(IEEE or a trade group specification), the vendor's (the vendor who
made the original IP core you are trying to clone) manual, or other
files or data that can be obtained publically (say, without hacking
into the vendor's computer) through vendor's website.
The reason I am asking this question is because various PLD companies
have IP cores available for trial with fairly detailed technical
information made available upon signing up for their trial program
(which is free).
Isn't it possible that someone might try to clone their IP cores?
If so, does the PLD vendors have a way to stop it?
        It looks like already a company called AMI Semiconductor
cloned Xilinx's LogiCORE PCI IP core according to this EE Times
article.

http://www.eetimes.com/story/OEG20010907S0103


Here is the actual product page for AMI Semiconductor's Xilinx
compatible PCI IP core.

http://www.amis.com/trans/xilinx-pci.cfm


Despite the fact the AMI Semiconductor cloned Xilinx's PCI IP core, it
looks like Xilinx hasn't taken any legal action against AMI
Semiconductor.
Does that mean that the IP core vendor has no way from stopping
someone from cloning their IP cores?



Regards,



Kevin Brace (don't respond to me directly, respond within the
newsgroup)

Article: 36040
Subject: Re: Cloning someone else's IP core
From: "Ulf Samuelsson" <ulf@atmel.REMOVE.com>
Date: Fri, 26 Oct 2001 23:56:48 +0200
Links: << >>  << T >>  << A >>
"Kevin Brace" <kevinbraceusenet@hotmail.com> skrev i meddelandet
news:cc7b0b5f.0110261344.42cd95bf@posting.google.com...
> I will like to know what happens when someone designs a compatible IP
> core of someone else's IP core?
> The design techniques used for designing such a compatible IP core
> will not be analysing a netlist, but designing a compatible IP through
> publically available information like a third party specification
> (IEEE or a trade group specification), the vendor's (the vendor who
> made the original IP core you are trying to clone) manual, or other
> files or data that can be obtained publically (say, without hacking
> into the vendor's computer) through vendor's website.


You can stop someone from legally cloning You
by getting Patents, and prepare to defend them.
Then it will be very very expensive.

Obviously they will try to get at You, for violating their patents,
and a cross-license agreement will follow.

Pure IP companies like RAMbus/ARM may be hard to get at
but RAMbus has been losing in court lately.

Another method is to ensure that you can copyright the design.
Some people think that a serial protocol which needs a copyright notice
from the legal vendor to work would be hard to copy since it violates
some original authors rights.

--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.




Article: 36041
Subject: Re: How to make an implementable big counter?
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 26 Oct 2001 21:59:43 GMT
Links: << >>  << T >>  << A >>
John_H <johnhandwork@mail.com> writes:

>Very nicely commented.  The terminal count detector is sometimes overlooked
>until implementation.

>There's way to provide *any* delay that would add a little overhead, but not a
>huge amount.  Use CLB ROMs to establish an initial value in the shift register
>that corresponds to the shift register value at your precise time delay before
>terminal count.  There's a little extra work to figure out the preload value
>but it's very doable.  The math isn't 5 minutes of work (unless you're an
>expert on this stuff) but one can produce what the nth shift register value is
>after any shift register value in the sequence mathematically to avoid waiting
>over 924 years to find what the right value is to preload the 2^63-1 counter
>for precisely 2000 years delay.

If you want a really really long count you could do this recursively.
Use an LFSR based counter to count the successive zeroes of the first
LFSR counter.  

-- glen

Article: 36042
Subject: Re: Cloning someone else's IP core
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 26 Oct 2001 15:10:35 -0700
Links: << >>  << T >>  << A >>
Kevin Brace wrote:
> 
> I will like to know what happens when someone designs a compatible IP
> core of someone else's IP core?

If they write their own source code, I expect it would be ok.

> It looks like already a company called AMI Semiconductor
> cloned Xilinx's LogiCORE PCI IP core according to this EE Times
> article.
> http://www.eetimes.com/story/OEG20010907S0103

The article describes a core netlist conversion where the
customer didn't own the source code. 
This is a good example of why you want to get the
source code if you buy a core.

> Here is the actual product page for AMI Semiconductor's Xilinx
> compatible PCI IP core.
> 
> http://www.amis.com/trans/xilinx-pci.cfm
> 
> Despite the fact the AMI Semiconductor cloned Xilinx's PCI IP core, it
> looks like Xilinx hasn't taken any legal action against AMI
> Semiconductor.
> Does that mean that the IP core vendor has no way from stopping
> someone from cloning their IP cores?

AMI is selling their own source code here.
This is no different than AMI second-sourcing an IC.

        --Mike Treseler

Article: 36043
Subject: Re: Cloning someone else's IP core
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 26 Oct 2001 15:14:36 -0700
Links: << >>  << T >>  << A >>
kevinbraceusenet@hotmail.com (Kevin Brace) writes:
> I will like to know what happens when someone designs a compatible IP
> core of someone else's IP core?
> The design techniques used for designing such a compatible IP core
> will not be analysing a netlist, but designing a compatible IP through
> publically available information like a third party specification
> (IEEE or a trade group specification), the vendor's (the vendor who
> made the original IP core you are trying to clone) manual, or other
> files or data that can be obtained publically (say, without hacking
> into the vendor's computer) through vendor's website.
[...]
> Despite the fact the AMI Semiconductor cloned Xilinx's PCI IP core, it
> looks like Xilinx hasn't taken any legal action against AMI
> Semiconductor.
> Does that mean that the IP core vendor has no way from stopping
> someone from cloning their IP cores?

In the United States, there are four main forms of intellectual property
protection:  trademark, copyright, patent, and trade secret.  If the
cloning doesn't infringe any of these, there is generally no ground for legal
action.

Note that trade secrets do not protect from reverse engineering, only
from unauthorized disclosure of the secret by someone privy to it.

-Eric

Disclaimer:  I am not a lawyer.

Article: 36044
Subject: Re: DSP on FPGA Opinions Needed->Earn $100
From: Dave Millman <dsp@tactics.com>
Date: Fri, 26 Oct 2001 15:37:59 -0700
Links: << >>  << T >>  << A >>
Thanks for the quesiton, Ray! The telephone interview will last 15-30 minutes.

Ray Andraka wrote:

> And how long is the inteview.  If it is an all day thing (extreme example, I
> know) it is hardly worth the stipend you are offering.
>
> Dave Millman wrote:
>
> > An EDA company is researching user's requirements for implementing DSP
> > on FPGAs. If you have completed a signal processing design on FPGAs, or
> > are now working on one, we'll pay you $100 to participate in a telephone
> > interview.
> >
> > During the interview, we will ask you to discuss:
> >
> >    * How many DSP on FPGA designs you have done
> >    * Why you chose to use FPGAs instead of standard DSP chips
> >    * What tools are you using and how well they are working
> >    * How current tools could be improved
> >
> > If you are interested, send an email to dsp@tactics.com with this
> > information:
> >
> >    * Your name
> >    * The phone number to reach you
> >    * The best time to reach you at that phone number
> >
> > If you have any questions, please feel free to send them to the same
> > address. PLEASE DO NOT RESPOND ON THE NEWS GROUP!
> >
> > In return for your time and opinions, we will send $100 to all
> > participants who complete the interview. We are an engineering market
> > research firm that has been retained by an EDA company to help them
> > develop new tools. Your opinions will be delivered straight to the team
> > developing the new product. In the end, the result will be better tools
> > that work the way you want them to.
> >
> > Thank you for your time.
>
> --
> --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


Article: 36045
Subject: Re: Cloning someone else's IP core
From: Kolja Sulimma <kolja@sulimma.de>
Date: Sat, 27 Oct 2001 00:51:29 +0200
Links: << >>  << T >>  << A >>
There were some legal battles in the past concerning the PC-Bios API, the
Apple II kernel API and so on. In many countries the bottom line is that an
API or an ISA are never protected by copyright and are usually not
patentable.
This means, that you can at any time write an IP-core that looks from the
outside like an Xilinx PCI Core. Or you can build a CPU that is instruction
set compatible to some other CPU.

Of course your are not allowed to copy any internal structures from the
original vendors implementation because these are copyrighted. That where
"clean room development" come into use. You hire someone who has never seen
the original implementation and let him implement the API that you give him.
This way nobody can claim that some code was copied.

If a vendor want's to prevent you from doing this he will try to patent a
lot of implementation tricks. This way youre implementation is likely to be
inferior because you are not allowed to use these ways of implementing the
product.
A good example for this is Arithmetic Coding. The original IBM patent has
expired, but IBM holds patents on a dozend codec implementations and data
structures.

For your example of the Xilinx-PCI core you are pretty much free to do what
you want, because you automatically obtain a license to all PCI related
patents of all SIGPCI members when you purchase a PCI-vendor ID.

The same is true if you want to build for example a MIPS or ARM compatible
CPU. The ISAs are not protected. Both companies hold a lot of patents to
protect there concepts, but most of them are invalid as there exists prior
art. And for the remaining on or two instruction  you can use illegal
instruction exeptions.

BUT!
Xilinx really oes not care whether you reimplement theire core as long as
you are using Xilinx chips to instantiate it.
A company like ARM that lives from nothing but theire IP will take any steps
to prevent you from building a compatible core. It is hard to go against a
dozen lawyers no matter how right you are.

Kolja Sulimma


Ulf Samuelsson wrote:

> "Kevin Brace" <kevinbraceusenet@hotmail.com> skrev i meddelandet
> news:cc7b0b5f.0110261344.42cd95bf@posting.google.com...
> > I will like to know what happens when someone designs a compatible IP
> > core of someone else's IP core?
> > The design techniques used for designing such a compatible IP core
> > will not be analysing a netlist, but designing a compatible IP through
> > publically available information like a third party specification
> > (IEEE or a trade group specification), the vendor's (the vendor who
> > made the original IP core you are trying to clone) manual, or other
> > files or data that can be obtained publically (say, without hacking
> > into the vendor's computer) through vendor's website.
>
> You can stop someone from legally cloning You
> by getting Patents, and prepare to defend them.
> Then it will be very very expensive.
>
> Obviously they will try to get at You, for violating their patents,
> and a cross-license agreement will follow.
>
> Pure IP companies like RAMbus/ARM may be hard to get at
> but RAMbus has been losing in court lately.
>
> Another method is to ensure that you can copyright the design.
> Some people think that a serial protocol which needs a copyright notice
> from the legal vendor to work would be hard to copy since it violates
> some original authors rights.
>
> --
> Best Regards
> Ulf at atmel dot com
> These comments are intended to be my own opinion and they
> may, or may not be shared by my employer, Atmel Sweden.


Article: 36046
Subject: Synplicity Ver. 7.0 Mapper Error
From: abhijeet@netcontinuum.com (Abhijeet)
Date: 26 Oct 2001 16:13:11 -0700
Links: << >>  << T >>  << A >>
I see the following error while running Synplicity Version 7.0

"netlist.c:1266 Error: hookup: conn already connected"

This error shows up during the mapper stage of synthesis. No
compilation warnings or errors are seen.

Does anyone know what this means and needs to be done to overcome it?

-Abhijeet

Article: 36047
Subject: Re: qpsk clock recovery
From: tsan@altera.com (Tony San)
Date: 26 Oct 2001 16:45:47 -0700
Links: << >>  << T >>  << A >>
Altera has a NCO Compiler with a reference design for an clock recovery PLL.

Here is the link :
http://www.altera.com/products/ip/altera/m-alt-ncocompiler.html


Tony

eric.jacobsen@ieee.org (Eric Jacobsen) wrote in message news:<3bc5c220.319255559@news.earthlink.net>...
> On 11 Oct 2001 05:12:33 -0700, eas@bi.net.tr (eas) wrote:
> 
> >"Bhaskar Thiagarajan" <bhaskart@my-deja.com> wrote in message news:<9q1sqq$loqqh$1@ID-82263.news.dfncis.de>...
> >> Clock recovery is a very important part of receivers and is discussed pretty
> >> much in every communications text. There are various methods to perform this
> >> function, but some of the common methods are well described (Ray just
> >> described one using PLLs).
> >> If you want to perform this block in real time at that kind of data
> >> rates...FPGAs/ASICs are your only choice. But if you can store a large
> >> amount of data and post process this, you can probably do this on a DSP.
> >> Search for key words like clock recovery, Costas Loop, etc. I doubt if you
> >> will find detailed examples of implementation other than descriptions on how
> >> this is typically done.
> >> --
> >> Cheers
> >> Bhaskar
> >> Note: I do *not* check the listed email address.
> >> 
> >
> >OK. Now I have to ask some question:
> >1. Where can I find the basic building blocks examples to perform the
> >clock recovery in FPGA?
> 
> Can't help ya there.
> 
> >2. Some texts explain clock recovery for NRZ data, How should I
> >process IQ data to put in a suitable form?
> 
> You need to find a suitable phase detector for your data, but it only
> needs to be applied to either I or Q, not necessarily both.
> 
> >3. I read a text that DPLL is suitable for data rates <10Mbps. Is this
> >true?
> 
> It depends on the implementation.   Usually a DDS (aka NCO) is used to
> generate the recovered clock, and if the input system clock to the DDS
> is not sufficiently higher than the symbol rate, you may wind up with
> an unacceptably jittery output clock.   Since it is not uncommon to
> clock DDS blocks, even in FPGAs, at hundreds of MHz now, it shouldn't
> be tough to go well beyond 10Mbaud.  How high you can get will still
> depend on your implementation.
> 
> 
> Eric Jacobsen
> Minister of Algorithms, Intel Corp.
> My opinions may not be Intel's opinions.
> http://home.earthlink.net/~ejacobsensprint

Article: 36048
Subject: Re: fir filter
From: tsan@altera.com (Tony San)
Date: 26 Oct 2001 16:48:48 -0700
Links: << >>  << T >>  << A >>
Altera's FIR compiler automatically generates serial, and multi-bit
serial fir filters which run at 240 MHz on 20KC silicon and over
300MHz on Altera's Mercury devices.

Here is the link :
http://www.altera.com/products/ip/altera/m-alt-fir-compiler.html

Tony

renaux <renaux.jacky@wanadoo.fr> wrote in message news:<2001929-165035-699438@foorum.com>...
> just posting a message sent to kuldeep 
> 
> 
> Hi 
> Personnally I think this architecture is a very easy one for 
>   building files 
>   updating coefficients ( during debug and later updating ) 
> 	as not routing is needed just reload a new set 
> 
> serial arithmetic
> 	for your case I undestand 12bits * 16Mhz is = 192 Mhz 
> 	why not to build up 2 RAMs one for odd bits , the second for 
> 	even bits and add the 2 results : means running 2 sets in parrallel
> 	at 6*16 => 96Mhz this is not a big deal any more . The 2 tables will
> 	have the same content , just a matter on how you feed the addresses
> 	In case you want to run slower .... use 4 RAMS and running 1/4 the speed 
> 	and add the results ....... you might go down to have 1 RAM per bit running
> 	at 16 Mhz each but you will need 12 RAMS    this is not what obviously I would
> 	recommand as every today ASIC can run 100Mhz systemm clock 
> take care 
> 	just be be sure you run least significant bit first, you must add succesivelly
> 	the partial product (from the ram) and add it to the accumulated product 
> divided
> 	by 2 (right shift ) but on the last cycle you must substract as the MSB is 
> 	addressing the ram ( 2's complement )
> 	as you right shift the accumulated result you can the feed a shift register in
> 	order to end up with a full scale result 
> 
> coefficients (5 in this exemple )  
> 
> non symetrical  
>  you need 5 shift registers ( which can also be a RAM) 
>     reg5 <= (reg4(0) & reg5(11 downto 1));  
>     reg4 <= (reg3(0) & reg4(11 downto 1));  
>     reg3 <= (reg2(0) & reg3(11 downto 1));  
>     reg2 <= (reg1(0) & reg2(11 downto 1));  
>     reg1 <= (data_in & reg1(11 downto 1));
>     address_ram <= (reg5(0) & reg4(0) & reg3(0) & reg2(0) & reg1(0) );
> 
> symetrical 
>  
>   usually ( coeff 1 = coeff 5 , coeff2  = coeff 4)
>   you still need 5 shift registers and group the coefficients by 
>   coefficients value
> 
> 
>     reg5 <= (reg4(0) & reg5(11 downto 1));  
>     reg4 <= (reg3(0) & reg4(11 downto 1));  
>     reg3 <= (reg2(0) & reg3(11 downto 1));  
>     reg2 <= (reg1(0) & reg2(11 downto 1));  
>     reg1 <= (data_in & reg1(11 downto 1));
>     
>     add1 <= reg5(0) + reg1(0) + carry1;	
>     add2 <= reg4(0) + reg2(0) + carry2;
> 
> --   this is a carry save type adder  
> --   carry1 and carry2 are saved from the previous cycle try to 
> --   configure add1 and add2 as 2 bits lsb is the add result 
> --   and msb is carry
>  
>    address_ram <= ( reg3(0) & add2 & add1 );  
> 
> -- which requires half bits addresses (in case odd coefficients )
> 
> but you must take in account the 13nd carry ( add1 and add2 ) then 
> requiring 1 more cycle ( you should consider 14 bits and then running at
> 14/2 * 16 Mhz  
> 
> 14 bits is fine as if you run one more cycle and pad zero as 13 and 14 bits into
> the shift registers , you will not have to reset carries at each new cycles
> 
> RAMS 
> 
>   as you have 65 coefficients you'll need 32 bits addresses RAM which is very 
> large
>   even in ASIC , you must split into smaller blocs ( if you only have 1K* Y RAM ,
>  then 
>   you'll need 4 of them  )     
>   How about Y ( RAM output bus ) it depends on number of coefficients inputs and 
> 
>   coefficients size ( if you have 11 bits coefficients , and 10 bits addresses 
>   the largest value is when all addresses are '1' in theory the output is 
> 10+11=21 bits
>   BUT ..... is it the largest partial products ? not necessary it depends the 
> values 
>   some might be negative ... try to calculate the largest value ( excel is fine 
> for )
>   and then optimize the RAM size sometime it is not necessary as it is design 
> dependant 
> 
> Speed 
> 
>   at 100Mhz you must take care of initialisations and the accumulator must be 
> cleared
>   every cycle . There is 3 options (at least for me ) 
> 	1- add one more cycle to clear the accumulator  
>       2- add one more cycle and add the ram content + zero ( this is not an 
> accumulation
>          cycle ) 
> 	3- using one more register . The last cycle instead to store the adder output 
>          you store it to a register which keep the cycle result while you clear 
> the 
>          accumulator 
> 
> Squeleton
> 
>     reg5 <= (reg4(0) & reg5(11 downto 1));  
>     reg4 <= (reg3(0) & reg4(11 downto 1));  
>     reg3 <= (reg2(0) & reg3(11 downto 1));  
>     reg2 <= (reg1(0) & reg2(11 downto 1));  
>     reg1 <= (data_in & reg1(11 downto 1));
>     
>     add1 <= reg5(0) + reg1(0) + carry1;	
>     add2 <= reg4(0) + reg2(0) + carry2;
> 
>     address_ram <= ( reg3(0) & add2 & add1 );  
> 
>     from 1 to last_cycle_clock-1
>         adder_out   <= accumulator/2 + ram_out;
>         accumulator <= adder_out;
>     last_cycle_clock 
>         adder_out <= accumulator/2 - ram_out;
>         result <= adder_out;
>         accumulator <= '0'; 
> 
> 
> I hope its help do not hesitate to contact me 
> 
>    regards    
>    
> 
> 
> -----Message d'origine-----
> De : Kuldeep [mailto:kkdeep@lycos.com]
> Envoyé : jeudi 27 septembre 2001 15:52
> À : renaux.jacky@wanadoo.fr
> Objet : RE: fir filter
> 
> 
> Hi jacky ,
>    Thanx for reply. This seems to be good architecture as i can tradeoff 
> throughput with hardware . Fully serial approach will not work for me as my 
> input data is coming at 16Mhz, 12-bit wide. That means i need clock of 192MHz 
> (16x12) which i can't afford .correct me ..so i will go for some mix of serial -
> parllel approach.
>   i have two doubts: 
>  quoting a line from ur reply :
> 1."you better add coefficient before feeding the partial products table"
> Here do u mean adding inputs (for which coeffcient happen to be same) before 
> feeding the partial product table? Plese elaborate further how can i take 
> advantage of symmetrical coeffcients.
> 2. i have odd number (65) coeffcients. Each LUT take 4 coeff. so where will the 
> last coeff go?? should i use 1 LUT for this single coeff.
> 
> thanx and regds 
> Kuldeep
> 
> renaux <renaux.jacky@wanadoo.fr> wrote in message news:<2001925-184146-
> 543341@foorum.com>...
> > Hi 
> > 
> > I would suggest you read an excellent paper on distributed arithmetic 
> > where part of the calculation is done before running while the remaining 
> > is done during the run 
> > 
> > go to http://www.andraka.com/ ,  DSP with FPGA and distributed arith 
> > 
> > this is intended to fpga , but using a case statement it can be targetted to
> > any technology . in addittion , using a ram as table would simplify the 
> > FIR filter implementation : a tap per add line , and output bus is as wide as 
> > sum of coefficients values ( if 16   12 bits coefficients => 4+12 bits bus )
> > do not miss the fact which is coefficients are symetrical you better add 
> > coefficient before feeding the partial products table ) 
> > 
> > do not hesitate to drop me a mail in case it is not clear enough 
> > 
> > regards , jacky 
> > 
> > ------
> > User of http://www.foorum.com/. The best tools for usenet searching.
> 
> 
> 
> 
> Make a difference, help support the relief efforts in the U.S.
> http://clubs.lycos.com/live/events/september11.asp
> 
> ------
> User of http://www.foorum.com/. The best tools for usenet searching.

Article: 36049
Subject: Re: Probing BGA Designs
From: "AME" <AME3141592@yahoo.com>
Date: Fri, 26 Oct 2001 17:11:11 -0700
Links: << >>  << T >>  << A >>
"Ben Popoola" <o.m.popoola@sussex.ac.uk> wrote in message
news:3BD93B77.2037E2E3@sussex.ac.uk...

>    I suggested that you learn about the JTAG interface of IC's. A good
> place to start is the texas instruments web site (www.ti.com) and look
> for the downloadedable book ' The JTAG Primer' there.

Can you provide a link to this document?  A search for "the jtag primer"
returns nothing.

Thank you,

-Martin






Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search