Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
--------------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. 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. 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. <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? 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. I'm about to upgraded to <br>ISE4.1 but I'm not sure which way to go. There is a Solaris version, <br>which would be great in many ways, but there is no FPGA Express for <br>Unix, only XST. So, I'd like information on the performance of XST <br>compared to FPGA Express. <p>Thanks, <p> David</blockquote> </html> --------------F7D174BCB1B01A22B32807B8--Article: 36026
"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, JamieArticle: 36027
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. GraemeArticle: 36028
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
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: 36030Robert 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 FalkArticle: 36031
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. -- glenArticle: 36032
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 TreselerArticle: 36033
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: 36034Hi, "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, CarlhermannArticle: 36035
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
"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 TreselerArticle: 36037
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 FalkArticle: 36038
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 RobberyArticle: 36039
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"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
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. -- glenArticle: 36042
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: 36043kevinbraceusenet@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
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, 1759Article: 36045
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
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? -AbhijeetArticle: 36047
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/~ejacobsensprintArticle: 36048
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
"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:
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