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
Folnar, The DCM delay lines themselves operate from a band gap reference whose output is tuned to have the reverse slope of the delay vs. temperature (patented technique, PTC bandgap to offset delay). What happens is that as the delay increases as temperature increases, the voltage increases to cancel. And the same for cold (voltage goes down as the temperature goes down). Then the taps of the delay line are part of the feedback loop that is actively trying to keep the skew from CLKIN to CLKFB identically 0. As long as all clock signals use the global clocks (which are matched, and have very good delay vs. temperature and voltage behavior), everything should work to the specifications (basically +/- 100 ps over process, voltage, and temperature for phase accuracy of a DCM). The phase shift is always calculated to be some percentage of a period (as XXX parts in 256), which is how many taps fit into one clock pulse. As the taps are changed, they are changed for the phase offset as well by solving for the correct tap to take the shift from, so that over voltage, temperature, process, the shift in phase is kept exact (to +/- 1 tap). Using the CLKFB externally also takes the IOB, and any external components out of the loop (or more accurately puts them in the feedback loop to account and correct for them). It is extremely unlikely (probably impossible) that one DCM is +100 ps, and the other is -100 ps. Since they are identical cells, their errors would tend to track together (for the deterministic parts). The random error is always +/- a delay line tap, so for two becomes +/- 2 delay line taps. That is likely, and quite probable that one zigs when the other zags (effecting a two tap difference). Clocks are not intended to go through doubles, hexes, or long lines, and definitely not through CLB LUTs, so if you are doing that, you are all on your own. Austin folnar wrote: > We currently have a Spartan 3 FPGA in our design. In our design, we are > using two DCM's specifically. One is driving an off-chip ADC and the > other is driving an FPGA register (which registers the data coming back > from the off-chip ADC). One clock is manually phase-shifted at > synthesis relative to the other clock to resolve clock skew issues > between the ADC processing of the data and the output of the ADC being > latched into the register. The clock signal to the ADC can be > phase-shifted to bring the overall timing within constraint. > > > > This setup works so far, but the question is whether it will continue > to work as the FPGA temperature changes, and over variations between > different chips or slight variations in the voltage supplies. The DCM > driving the ADC is physically placed far from the pin which it drives. > The routing from DCM to pin is accomplished via hex lines and > combinational logic. Are there any general rules which are capable of > predicting the sensitivity of propagation delay to temperature, > voltage, and chip variations? >Article: 103601
This is what I had sent dirctly to the poster, a few days ago. Maybe it's of general interest: First I have to warn you about using a DCM output as ADC clock. Experts agree that the ADC clock should be as jitter-free as possible, and a DCM output has significant jitter, which costs you dearly in raising the ADC noise floor. I shudder thinking about the jitter = noise you feed into the ADC. Regarding the more benevolent aspect of delay change: Delay increases with temperature. in some cases delay is proportional to the absolute (Kelvin) temperature. In some cases it is more stable. I think you can measure it, and more conveniently: Build a ring oscillator (feedback with a single inversion) of equivalent snippets of delay and LUTs, and then measure the frequency as function of temperature. You get tremendous resolution and thus accuracy. My advice, give the ADC a clear clock, then use the DCM to adjust the phase. And minimize routing and gating. Peter Alfke Xilinx ApplicationsArticle: 103602
Mike,
You're correct, but the synthesizer must _recognize_ whether two or
more cases overlap (i.e. if they are not mutually exclusive). If it
cannot prove they are ME, then it must include (keep) the priority
logic. In other words, priority is assumed for an if-then-else
statement until proven otherwise.
Another way to imply priority (which the synthesizer can remove if it
recognizes ME conditions) is to use an exit statement inside an if
statement in a loop:
for i in reg'range loop
if addr = i then
reg(i) <= data;
exit; -- should not make any difference, except for sim speed
end if;
end loop;
An example of where this gets messy is if you are pre-decoding the
address a clock cycle early, then using the decoded strobes to enable
reads or writes to a set of registers. You know the decoded strobes
are ME, but does the synthesizer know it? It would be nice if we could
define a standare mutex function inside an assertion statement, and the
synthesis tool could recognize/accept that as proof that the strobes
(or any set of conditions) were ME.
This is also an excellent application of retiming, since you could
simply delay (register) the address a cycle, then decode and enable
read/write in one cycle using the (ME) delayed address. Then let the
synthesis retiming push the pre-decoding back a cycle for you (if
necessary).
Andy
Mike Treseler wrote:
> Andy wrote:
>
> > If-then-else statements
> > do imply priority,
> ... if (and only if) two or more cases overlap.
>
> Otherwise, excellent posting.
>
> -- Mike Treseler
Article: 103603Hi EDK experts, I was wondering how are the TCL scripts sitting in each of the pcores/xxxx/data directories supposed to be used? I am trying to modify a core and would like to understand whether I have to run the script manually? I tried running xps -nw -scr xxxx.tcl, but it wouldn't do anything... Thanks, /MikhailArticle: 103604
Jim Wu wrote: > FWIW, my ISE8.1 installation has libPlXil_Legal.so in > $XILINX/xilinx/bin/lin64 on my RedHat EL3 64-bit machine. Strange... It's not there on my machine... I'll do a reinstall tomorrow, maybe it'll show up... cu, SeanArticle: 103605
Dave Farrance skrev: > Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote: > > >In comp.arch.fpga Dave Farrance <DaveFarrance@omitthisyahooandthis.co.uk> wrote: > >> I'll use another USB port for that, and I'll put together a transceiver > >> board to handle the signal-levels so that I can route the raw data > >> stream directly to the FPGA I/O. Such a USB interface would be > >> speed-limited, but I'm not worried about that. > > > >The interface is not only speed limited, but also missing needed > >functionality, at least for USB2. USB+ and USB- need to be evaluated in many > >ways, not possible with a normal FPGA input. There are chips implementing the > >physical access (UTMI). > > Thanks. I see. If I built an transceiver board myself, it'd have to be > for USB 1.1 with a basic transceiver chip such as the MAX3346E which > I'd run at low speed. I have managed to solder 14-pin TSSOP packages to > prototype boards in the past, although I'd rather find a DIP chip if I > could. > > -- > Dave Farrance If it is a just for fun hack kinda thing you don't need a transciever. I've implemented the opencores usb core in an FPGA using just two normal IOs and a pullup connected to a usb connector and a little fpga logic to simultate the phy. got as far as getting plugged and enumerated on windows, never used it for anything though -LasseArticle: 103606
Andy wrote:
> You're correct, but the synthesizer must _recognize_ whether two or
> more cases overlap (i.e. if they are not mutually exclusive). If it
> cannot prove they are ME, then it must include (keep) the priority
> logic. In other words, priority is assumed for an if-then-else
> statement until proven otherwise.
Yes, of course, but if
*I* know that cases A, B cannot overlap,
it is up to *me* to exclude special coverage
of the (A and B) case in my description,
if I want to save the gates.
I would say:
___________________
...
if A then
do_A_thing;
endif;
if B then
do_B_thing;
endif;
...
___________________
I see coding an if-then-else for this
example as a logical error on *my* part,
even though there is no functional difference.
-- Mike Treseler
Article: 103607Hi, I have an old asic prototype that was initially done using ise5.1 and a virtex2, I'm now moving to a virtex4 so I've moved to ise8.1i, initially targeting virtex2 the design has five clks only one of them is really critical with a fanout of about 6000, ise5.1 recognized all the clks and put them on global nets. ise8.1i warns that the clk signal has non-clk connections (it does the clk goes to an io for a debug interface) and it cannot fit it to a clk template or something along those lines and puts the critical clk on local routing and the design fails is there a trick to getting ise8.1i to recognize the clock net? regards, -LasseArticle: 103608
Ron wrote: > As a retired computer programmer of 35+ years who has only recently > taught myself Verilog during my retirement (as a hobby), I vastly prefer > Verilog to what I've seen of VHDL. I dont unstand what you are saying, Ron. You are a Verilog novice and don't know VHDL. You may have 35+ years of "experience", but that doesn't make you more credible in this particular context > On the other hand, most of my programming was "down to the metal" device > drivers and realtime embedded systems work, so it was very important for > me to be able to easily deal with hardware interfaces and to know > exactly what code the compiler (if used at all) generated so I could > have strict control over the timing of things. I was overjoyed when the > C programming language came along because it maps very well to the > computer architectures of most machines and allowed me to use a high > level language instead of assembly language even when doing > bit-twiddling things such as device drivers (I had used assembly and > Pascal up until then). The transition from C to Verilog was almost > totally painless once I figured out this new concept of "wires" ;-) > because of the similarity between the two languages - at least as far as > the low level operators and general design philosophy of the languages go. If your C and Verilog are very close to each other, then something is very wrong. Ignoring the HW vs SW-mind, yes the syntax is kind of resembling. But after 35+ years you should be able to learn any syntax in a day or two? Do you seriously mean that you choose Verilog over VHDL because you couldn't learn to write "AND" instead of "&"? (BTW, I am a C programmer by trade. Wondering my favourite HDL? read on then...) > > The thing that bothers me most about abstract computer languages such as > COBOL, Lisp, ADA, and I will include VHDL in this category) is that the > hardware the design is implemented on is *not* abstract at all - it is *Everything* is abstract, at some level and with some distance... If you haven't seen it yet, its because you are playing with tiny designs (knowning your answer here, I counter: yes, you can still fill a large FPGA with a tiny design). And for gods sake, how did you - as a software guy - missed the big "abstraction wave" during the 90s? > composed of bits and bytes and elementary operations an ALU can perform, > and so if I care anything at all about performance I like to use a > relatively low level language. You said you prefer C over assembler. Well, same thing here. Please read up on behavioural-but-still-synthesizable-code. Given the current state of synthesis tools, I prefer to write code at a higher level and let Synplify/DC/Leonardo/Quartus/Blast/Palace do their magic. Somehow, I don't feel like doing multimillion-gate designs at transistor level. > > I think it's rather amusing that whenever I do a new Verilog design, I > usually begin by coding the algorithm in the Maple computer language. > Maple is a very high level arbitrary precision language that can do > symbolic algebra, calculus, differential equations, etc. It may be a > surprising choice as a design language for Verilog, but it works quite > well because Maple allows me to do pretty much whatever I want without Now you are contradicting yourself. I use C-based languages (C/C++/Java/C#/..) to prototype. I may use Matlab when I do DSP, but thats another story. > regard to implementation specifics. When I wrote the Verilog > implementation of Lenstra's Elliptic Curve Factoring method (ECM), I > started by writing a Maple program from the algorithm described in a > textbook, and then gradually decomposed each of the higher level > operations into simpler operations until I had something that could be > implemented easily in Verilog. :-) I know VHDL, Verilog and SystemC plus a few more (there were tons of other languages during the PAL/PLD-era). And believe me, they are all pretty much the same, SPECIALLY AT LOW-LEVEL! >From my experience, people recommending language V1 over another language V2 do it because they don't know language V2. Given that VHDL is a bit harder to learn, you hear a lot of this from the Verilog-Only camp. And then you have the ASIC people who love to hate VHDL. But Austin and Peter say ASIC is dying, and given that they are one of world largest AISC shops I assume they know what they are talking about :) Ok back to the subject, if you are serious about HW design, you MUST know at least VHDL and Verilog. Well, unless you never ever use IP-blocks, which is a whole another discussion...Article: 103609
MM wrote: > Hi EDK experts, > > I was wondering how are the TCL scripts sitting in each of the > pcores/xxxx/data directories supposed to be used? I am trying to modify a > core and would like to understand whether I have to run the script manually? > I tried running xps -nw -scr xxxx.tcl, but it wouldn't do anything... > > > Thanks, > /Mikhail You do not need to run the scripts manually, EDK runs them for you. In the MPD file for the core you are modifying, there will be a line like this: OPTION xxx_PROC = name_of_routine_in_tcl_file. xxx_PROC will be one of about six different types of routines the EDK understands. There is a very small amount of documentation on a few of them in the "Platform Specification Manual" in the EDK documentation. This is the manual that describes the MPD, etc. file formats. You can get a lot of examples of how the tclfiles are used by looking though the cores that come with EDK. If you grep the *.mpd files for _PROC, you will get a list of all the cores that are using TCL files, and you will see what different types of _PROC routines are used. You will also find a lot of TCL files to use as examples. The ChipScope files are interesting to look through because they show how to use the ELABORATE_PROC routine to use CoreGenerator to create a core from within EDK. You can also use the tcl files to create a core level UCF file. You use this with the RUN_NGCBUILD option in the MPD file to cause the core to be synthisized by itself and the constraints incorporated into its netlist, then that netlist to be used when the chip level netlist is created. There are some examples of this some where in the EDK cores if you grep for RUN_NGCBUILD in the cores that use tcl files. Last night I was trying to figure out how to get XST to use an XCF constraint file when I build a core on its own. I can generate the XCF file, but I can not figure out how to tell XCF to use it. There is a *.scr file that gets created for each core in the synthesis directory of the project, but I can not figure out how to modify it at the right time of the build. Has anyone else figured this out? Regards, John McCaskill.Article: 103610
Good point, but just for grins, let's turn this around into a read, rather than a write: If a then data <= a_thing; end if; if b then data <= b_thing; end if; There is still an implied priority of B over A which, without explicitly coding an and-or tree, is pretty difficult to code with no priority implied. In other words, the priority is still implied by the order, but in your case it can be resolved without knowledge of the mutual exclusivity of the conditions if the resulting actions are independent (i.e. do_a and do_b can both be done at the same time). Another way I have coded it is like a tri-state bus, then told the synthesis tool to convert tri-states to muxes. It assumes the tri-state enables are mutually exclusive. Andy Mike Treseler wrote: > Andy wrote: > > > You're correct, but the synthesizer must _recognize_ whether two or > > more cases overlap (i.e. if they are not mutually exclusive). If it > > cannot prove they are ME, then it must include (keep) the priority > > logic. In other words, priority is assumed for an if-then-else > > statement until proven otherwise. > > Yes, of course, but if > *I* know that cases A, B cannot overlap, > it is up to *me* to exclude special coverage > of the (A and B) case in my description, > if I want to save the gates. > > I would say: > ___________________ > ... > if A then > do_A_thing; > endif; > > if B then > do_B_thing; > endif; > ... > ___________________ > I see coding an if-then-else for this > example as a logical error on *my* part, > even though there is no functional difference. > > -- Mike TreselerArticle: 103611
All, Lately I got a database of ICs, analog, digital, etc. market research. It allows you to ask questions like: "Who are the top 5 digital logic IC companies, in order of 1 to 5, and how did they fare compared to last year (2005 vs 2004)" Intel +27.2% up from last year to 10.3% of market Qualcomm up 7.5% with 5.4% of market Broadcomm up 10.4% with 5.4% nVidia up 23.8% with 4.4% and ATI up 6% with 4.4% Which makes those top 5 with only 29.8% of the total market, but with $14.21 billion in revenues from all Logic ICs. This is everyone. Us included. But, since that is not so narrow as just ASICs, I then narrowed it to Logic ASICs: IBM down 8% with 15.7% of market Fujitsu down 3.8% with 10.7% NEC down 26.8% with 9% of market Toshiba even with 6.4% of market and Agere down 3.1% with 6.3% of market Which makes for 48.1% of the market, which comprises $5.9 billion (total logic ASIC here is $12.34 down 7.2% from last year. Looking at PLDs alone (no surprises here): Xilinx up 3.7% with 50.3% Altera up 7.6% with 33.1% Lattice down 7.1% with 6.4% Actel up 7.8% with 5.5% and QuickLogic up 6.7% with 1.5% Which makes these 5 with 96.8% of a $3.17 billion market, which overall grew 3.6% over last year. Hmmm. Logic ASIC ~4X PLD's ...that's interesting. So, what happens when you combine the Logic ASIC with the PLD markets, and look at them together? IBM down 8% with 12.4% Xilinx up 3.7% with 10.5% Fujitsu down 3.8% with 8.4% Altera up 10.6% with 7.2% and NEC down 26.8% with 7.1% A combined 45.7% of the total market, which accounts for $7.13 billion. Conclusion: So, if you are wondering if you should learn verilog or VHDL, the figures really say you should know both. Well. Really well. AustinArticle: 103612
Austin Lesea (austin@xilinx.com) wrote: : All, : So, if you are wondering if you should learn verilog or VHDL, the : figures really say you should know both. Well. Really well. (Going of on a tanget here from the bulk of Austin's posting...!) Hah. I get a bit bored seeign the repetative 'Should I learn VHDL or Verilog' questions. Both are a bit more nebulous than most software languages people learn, in that everyone's synthesis or simulation tools implement different parts of the language spec for different purposes, and ultimatly most people on CAF use them to describe what they want a CPLD/FPGA to do. Chuck in the mess of things like VHDL attributes and Verilog comments being used to pass (vendor / technology) specific hints to the synthesiser... When that's the case what you really need to know is what you want the device to do, how the device works best, and the intersection between the two. If you've got half a clue about that and are competent in any computer language then VHDL/Verilog become little more than a preference for a syntax (other than generate + attributes etc. in rare cases.) And both could be much better. Much much better. Oh well... cdsArticle: 103613
Austin Lesea wrote: > All, > > Lately I got a database of ICs, analog, digital, etc. market research. > > It allows you to ask questions like: > > "Who are the top 5 digital logic IC companies, in order of 1 to 5, and > how did they fare compared to last year (2005 vs 2004)" > > Intel +27.2% up from last year to 10.3% of market > Qualcomm up 7.5% with 5.4% of market > Broadcomm up 10.4% with 5.4% > nVidia up 23.8% with 4.4% > and > ATI up 6% with 4.4% > > Which makes those top 5 with only 29.8% of the total market, but with > $14.21 billion in revenues from all Logic ICs. This is everyone. Us > included. > > But, since that is not so narrow as just ASICs, I then narrowed it to > Logic ASICs: > > IBM down 8% with 15.7% of market > Fujitsu down 3.8% with 10.7% > NEC down 26.8% with 9% of market > Toshiba even with 6.4% of market > and > Agere down 3.1% with 6.3% of market > > Which makes for 48.1% of the market, which comprises $5.9 billion (total > logic ASIC here is $12.34 down 7.2% from last year. > > Looking at PLDs alone (no surprises here): > > Xilinx up 3.7% with 50.3% > Altera up 7.6% with 33.1% > Lattice down 7.1% with 6.4% > Actel up 7.8% with 5.5% > and > QuickLogic up 6.7% with 1.5% > > Which makes these 5 with 96.8% of a $3.17 billion market, which overall > grew 3.6% over last year. > > > Hmmm. Logic ASIC ~4X PLD's ...that's interesting. > > > So, what happens when you combine the Logic ASIC with the PLD markets, > and look at them together? > > IBM down 8% with 12.4% > Xilinx up 3.7% with 10.5% > Fujitsu down 3.8% with 8.4% > Altera up 10.6% with 7.2% > and > NEC down 26.8% with 7.1% > > A combined 45.7% of the total market, which accounts for $7.13 billion. > > > Conclusion: > > So, if you are wondering if you should learn verilog or VHDL, the > figures really say you should know both. Well. Really well. .. and learn Quartus, as Altera's growth is well above Xilinx's ? :) Indeed, Xilinx's growth seems to be well below the average of the top 5 in this sector ? In one table above, you have Altera as appx 2x Xilinx growth, but in another shows ~3x - is that because the first table excludes their hardcopy ASICs ? The second table also shows a larger Altera (lower ratio Xilinx:Altera) so something extra seems to be included here, that is missing in what you call PLDs alone ? -jgArticle: 103614
Jim, Any snapshot of just the last year, at the calendar year mark, can be safely ignored if you try to get too much from it. If you take the last five years, then maybe you get to see the average trend (which is evident when you look at the overall market share -- hard to get to 50+% without actually showing some pretty impressive growth...). That Altera is (still) ~33% is also not lost on anyone. The whole market has more $$$, so we all show growth in $$$, even if some of us are not really gaining market share. A quick review of "How to Lie with Numbers" would prove instructive to anyone who wanted to spin the data to their advantage. That said, I have my own bias, and the way I chose to post the numbers could be considered highly biased (not intentionally, really). So, the whole reason for the post was to show that 2004 vs 2005 was a generally good year for PLD suppliers compared with digital ASIC suppliers. It was also to show that PLDs are about 1/5th the total logic market, so VHDL and verilog are pretty useful to know. AustinArticle: 103615
"Austin Lesea" <austin@xilinx.com> wrote in message news:e643rf$nq415@xco-news.xilinx.com... > bh, > > We are actively working with many military contractors on packaging. > > And, they have been tested, and they don't fare well. All our packages > breath. If they get conformal coated, then any moisture inside is > trapped. If they could bake before coat, potentially this works ... but > the tests continue. > > Then when the heat is on, they POP if they adsorbed any moisture (even > through the coating). > > This is not unique to Xilinx, but an industry wide problem with all flip > chip packages today. > > In the FPGA business we have the distinction of making the largest die > in the industry. > > In the lobby of the IDA building > http://www.ida.org/ > there area series of posters of pcbs. Center in many of them is a > Xilinx FPGA. These posters caught many by surprise, as in most recent > systems, there is a Xilinx FPGA. (Even the military had no idea how > pervasive FPGAs have become) > > Coatings are typically used where there is no protection from the > environment at all. Many systems provide environmental protection at > the box level. The problem is that the boxes, while not having any air-flow in the box, do have pressure vents that allow air-pressure to adjust. In some cases (like boxes with PCMCIA cards) they even have drain holes to allow moisture and dust to 'drain'. Practically all of the systems I've seen recently (including those with FPGAs) have conformal coatings. I suspect many do a 4-hour bake at 125C to force out any moisture before applying the conformal coat, which if the proper coating is used and applied properly should stop any moisture transfer. How does the underfilling effect moisture venting? -bh > > There are some packages which are qualified for coating (hermetic), but > they are either too small for our die, or they have not been qualified > for our use, yet. > > Austin > > bh wrote: > > Xilinx app note XAPP426 v1.3 (March 2006) indictes that: > > "Xilinx has no experience or reliability data on flip-chip BGA packages > > on board after exposure to conformal coating." > > > > WTFO ? > > > > How is it possible with Xilinx being so tight with Military > > developers that they haven't tested their parts under the > > conditions which nearly all military boards are produced? > > > > What am I missing? Have they been sworn to secrecy? :-)) > > > > -BH > > > > > >Article: 103616
On Tue, 06 Jun 2006 14:02:18 -0700, langwadt wrote: > > Dave Farrance skrev: > >> Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote: >> >> >In comp.arch.fpga Dave Farrance <DaveFarrance@omitthisyahooandthis.co.uk> wrote: >> >> I'll use another USB port for that, and I'll put together a transceiver >> >> board to handle the signal-levels so that I can route the raw data >> >> stream directly to the FPGA I/O. Such a USB interface would be >> >> speed-limited, but I'm not worried about that. >> > >> >The interface is not only speed limited, but also missing needed >> >functionality, at least for USB2. USB+ and USB- need to be evaluated in many >> >ways, not possible with a normal FPGA input. There are chips implementing the >> >physical access (UTMI). >> >> Thanks. I see. If I built an transceiver board myself, it'd have to be >> for USB 1.1 with a basic transceiver chip such as the MAX3346E which >> I'd run at low speed. I have managed to solder 14-pin TSSOP packages to >> prototype boards in the past, although I'd rather find a DIP chip if I >> could. >> >> -- >> Dave Farrance > > > If it is a just for fun hack kinda thing you don't need a transciever. > I've implemented the > opencores usb core in an FPGA using just two normal IOs and a pullup > connected > to a usb connector and a little fpga logic to simultate the phy. > got as far as getting plugged and enumerated on windows, never used it > for anything though > Got VHDL? Thanks! RichArticle: 103617
Austin Lesea wrote: > Jim, > > Any snapshot of just the last year, at the calendar year mark, can be > safely ignored if you try to get too much from it. > > If you take the last five years, then maybe you get to see the average > trend (which is evident when you look at the overall market share -- > hard to get to 50+% without actually showing some pretty impressive > growth...). That Altera is (still) ~33% is also not lost on anyone. The > whole market has more $$$, so we all show growth in $$$, even if some of > us are not really gaining market share. I was wondering why the Altera results differed in two areas, but Xilinx's did not. Did the report not clarify that, or was it a typo ? > A quick review of "How to Lie with Numbers" would prove instructive to > anyone who wanted to spin the data to their advantage. That said, I > have my own bias, and the way I chose to post the numbers could be > considered highly biased (not intentionally, really). > > So, the whole reason for the post was to show that 2004 vs 2005 was a > generally good year for PLD suppliers compared with digital ASIC suppliers. Yes, and an even better year for Foundries, who some could consider the ultimate 'ASIC suppliers' :) > > It was also to show that PLDs are about 1/5th the total logic market, so > VHDL and verilog are pretty useful to know. Did those numbers include OnSemi/Philips/TI etc standard logic devices ? -jgArticle: 103618
Hi all,
I'm making research on Hardware Evolution and has bought a
Development Board named DS-BD-V4LX25LC REVISION 2(VIRTEX-4 LC inside)
of Memec Design. I learned that Delon Levi developed the API on Virtex
4 FPGA, and i need it urgently on the academic research(i declare that
it would be use on academic research only). Would you please tell me
where can I get a copy of the API or tell me the email address of
Delon Levi? Eager for your help, thank you
Article: 103619Hi: does anyone know if I set IOBDELAY=BOTH in virtex-II. what's the delay value in the input path? It seems there is no constraint for virtex-II to set the correct delay value. (in vertex-4 there is such constraints) bests qyshengArticle: 103620
hi, Vivian Thanks a lot for your help! Your suggestions do help me a lot! I will try your methords, if there is any advance, I will tell you! Again, many many thanks! sincerely NickyArticle: 103621
hi, Vivian In your reply you mentioned that > My suggestion would be to start off using the xilinx xtclsh program, a > library is provided with ChipScope called tcljtag.tcl what is xtclsh program? Can you give me more information about it? Many thanks! sincerely NickyArticle: 103622
Hi Andy,thanks a lot for your response. Andy wrote: > First, your code (both versions) will create latches, not registers. > You need a clock edge specification: > > if rising_edge(clk) then > -- decode/assignment statements go here > end if; > I am using address decoding logic irrespective of the Clock i.e based on that particular address., i am implementing read and write functionalities.If i need a edge, could I use the /ARE low or /AWE low i.e if falling_edge(AWE) -- decoding end if; Please clarify..Article: 103623
langwadt@ieee.org wrote: >Dave Farrance skrev: >> Thanks. I see. If I built an transceiver board myself, it'd have to be >> for USB 1.1 with a basic transceiver chip such as the MAX3346E which >> I'd run at low speed. I have managed to solder 14-pin TSSOP packages to >> prototype boards in the past, although I'd rather find a DIP chip if I >> could. > >If it is a just for fun hack kinda thing you don't need a transciever. >I've implemented the >opencores usb core in an FPGA using just two normal IOs and a pullup >connected >to a usb connector and a little fpga logic to simultate the phy. >got as far as getting plugged and enumerated on windows, never used it >for anything though Thanks. I'll bear that in mind. Actually, I've just remembered that there are cheap tssop-to-dip adaptors available, which are easy to solder. Just run some solder along the pins, and wick off the excess with solder-braid. I'll probably use a pre-built interface like the Enterpoint one mentioned elsewhere in this thread, though. -- Dave FarranceArticle: 103624
Somebody please help me on this issue.... I am not able to compare the registers now.... please help
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