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
The SDF is applied to the backannotated Verilog. Thanks for your indication about GTS, but it seems that your response has been stopped by something / someone, you are going to...? Thanks for any help GioArticle: 89301
Duane; Thanks for the info on ROC. I'm going to try it out; hopefully the synthesis tool and Xilinx M1.5i router will handle it (I'm using the tools "of the time"). I'll post later today, after I review the outputs of the two tools. Regards, Bob Duane Clark wrote: > Bob Myers wrote: > > I have converted an old Xilinx schematic design into VHDL. However, > > I'm running into a problem with how to implement the GSR function > > properly. > > > > I'm used to having an external reset line feed one of the pins, that > > could be specified to Leonardo 4.22 as the global_sr signal. This > > design, however, used an internally generated pulse from the > > configuration section to pulse the registers. > > > > The method I use in VHDL to implement the GSR is to instantiate within > the design a ROC primitive (which is in the Xilinx unisim library). All > of the Xilinx tools for many years have understood that this net is the > GSR, and I would assume that Leonardo would too. ROC simply outputs a > reset pulse of a few 100nS, just like the real GSR. > > -- synthesis translate_off > library UNISIM; > use UNISIM.VCOMPONENTS.ALL; > -- synthesis translate_on > > ... > component roc > port ( > O : out std_logic > ); > end component; > > ... > roc_e: roc > port map( > O => RESET > );Article: 89302
Hi! I think it is possible to write a conceptional placer and router. A lot of the Xilinx FPGA-architectures (the principal components) are described in the appropriated documentations. To develop a placer and router, that will be able to produce the configurationdata for a fpga will be very difficulty, because the structure and meaning of the configurationdata is not documented in all details. greetings, SvenArticle: 89303
have archived my project manually (without using ise) and restored it. now, ecs tells me to update every macro instance. when i do so (option: update all schematic files)ise is getting very, very slow. i tried to exit and restart but it will not solve the problem... it happens both on 6.1.03i and webpack 7.1.04i.Article: 89304
Hi there,
I'm having problems trying to use Xilkernel on a XPS system designed to
work on a Virtex-II Pro FPGA with MicroBlaze processor.
I am testing with a very simple code that is supposed to launch only one
process and then terminate. The problem is that after launching
xilkernel_main and initializing parameters the system isn't launching
the process indicated in the static_pthread_table parameter.
I have no errors compiling and I have tried changing some xilkernel
parameters but I can't really see what is failing.
Here is the definition of xilkernel in the MSS file:
--------------------------------------------------------
BEGIN OS
PARAMETER OS_NAME = xilkernel
PARAMETER OS_VER = 3.00.a
PARAMETER PROC_INSTANCE = microblaze_0
PARAMETER systmr_dev = opb_timer_1
PARAMETER stdin = RS232
PARAMETER stdout = RS232
PARAMETER config_time = true
PARAMETER n_prio = 6
PARAMETER config_sema = true
PARAMETER max_sem = 4
PARAMETER config_msgq = true
PARAMETER num_msgqs = 1
PARAMETER config_bufmalloc = true
PARAMETER config_debug_support = true
PARAMETER verbose = true
PARAMETER enhanced_features = true
PARAMETER config_kill = true
PARAMETER static_pthread_table = ((capture_main,1))
PARAMETER mem_table = ((4,30),(8,20))
END
----------------------------------------------------------
Here is the application C code:
----------------------------------------------------------
#include "xmk.h"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <os_config.h>
#include <sys/process.h>
#include <pthread.h>
#define UART_BAUDRATE (115200)
static pid_t spid;
static pthread_t tid;
static pthread_attr_t attr;
void* sum(void *arg);
int main ()
{
microblaze_enable_interrupts();
xil_printf("Before xilkernel_main...\r\n");
xilkernel_main ();
xil_printf("After xilkernel_main...\r\n"); //Never reaches this point
}
void* capture_main (void *arg)
{
int ret;
pthread_attr_init (&attr);
xil_printf("Before launching the process...\r\n");
ret = pthread_create (&tid, &attr, (void*)sum, NULL);
if (ret != 0) {
xil_printf ("-- ERROR (%d) launching process...\n", ret);
return;
}
ret = pthread_join (tid, NULL);
xil_printf("After launching process...");
}
void* sum (void *arg)
{
int a = 1, b= 2, c=3;
xil_printf("a + b = %d\r\n",(a+b));
xil_printf("a + c = %d\r\n",(a+c));
xil_printf("b + c = %d\r\n",(b+c));
}
-----------------------------------------------------------
And here is the program output:
-------------------------------------------------------------
Before xilkernel_main...
XMK: Start
XMK: Initializing Hardware...
XMK: Initializing PIT device.
XMK: System initialization...
XMK: Enabling interrupts and starting system...
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
.........
.........
.........
-------------------------------------------------------------
and carries on like that forever.
I can't really see what is going wrong so that's why I'm posting the
message to this group hoping that somebody with more experience using
xilkernel with MicroBlaze processor could help me out.
Any help would be greatly appreciated.
Thanks in advance,
Adrian.
Article: 89305
On Mon, 12 Sep 2005 10:16:35 +0100, Jon Schneider wrote:
> I've got my design talking to some (Kingston) KVR133X64/1G SDRAM
> modules and running at only 66MHz, doing some simple testing (the
> data=address or maybe data={address,address}) and have found some funnies.
>
> There are a few dozen single bit errors. There are also several
> locations that come back with some F digits (as if the cells just
> don't exist). Also they are mid-burst as much as not which indicates
> it isn't a timing problem.
>
> I have done testing on different FPGAs with different SDRAM modules
> and the errors definitely go with the modules and are quite
> repeatable.
>
> I have checked the refresh timing and it's good.
>
> Is Kingston SDRAM really that bad ? The fact they are made of
> repainted Infineon chips such that you can't read the original part
> number makes me suspicious that these might not be the real
> thing. They claim 100% testing but I wonder what they do with modules
> tested as bad. Is it because the FPGA can keep memory busy in a way a
> processor can't ? Should I speed up the refresh ? We intend to try
> some Micron parts anyway.
>
> Jon
I'd suspect your design before I'd suspect the modules especially if it's
more then one module that's failing. Have you simulated the design using
the Micron DRAM models? The Micron models do a very good job of checking
that you've met all of the timing requirements. DRAMs have a lot timing
requirements, not just set up and hold and refresh intervals, but things
like precharge times, RAS to RAS times on the same bank, ...
Article: 89306
On Mon, 12 Sep 2005 10:16:35 +0100, Jon Schneider <jon@jschneider.tenreversed> wrote:
>I've got my design talking to some (Kingston) KVR133X64/1G SDRAM
>modules and running at only 66MHz, doing some simple testing (the
>data=address or maybe data={address,address}) and have found some funnies.
>
>There are a few dozen single bit errors. There are also several
>locations that come back with some F digits (as if the cells just
>don't exist). Also they are mid-burst as much as not which indicates
>it isn't a timing problem.
>
>I have done testing on different FPGAs with different SDRAM modules
>and the errors definitely go with the modules and are quite
>repeatable.
>
>I have checked the refresh timing and it's good.
>
>Is Kingston SDRAM really that bad ? The fact they are made of
>repainted Infineon chips such that you can't read the original part
>number makes me suspicious that these might not be the real
>thing. They claim 100% testing but I wonder what they do with modules
>tested as bad. Is it because the FPGA can keep memory busy in a way a
>processor can't ? Should I speed up the refresh ? We intend to try
>some Micron parts anyway.
>
>Jon
Errors which are apparently 'static' can be due to artifacts of the relative numbers of
address/data lines /banks active/transitioning at the time - noise, ground bounce etc. Might be
interesting to try different data patterns & see if the errors move.
If refresh is WAY out of spec (or not happenning at all) it could be that, however as the refresh
interval is specced over the entire temp range I wouldn't expect to see refresh-related failures
until it was out of spec by a very big margin.
Article: 89307
What about signal integrity? impedance matching?
Aurash
Hiding in Plain Sight wrote:
>On Mon, 12 Sep 2005 10:16:35 +0100, Jon Schneider wrote:
>
>
>
>>I've got my design talking to some (Kingston) KVR133X64/1G SDRAM
>>modules and running at only 66MHz, doing some simple testing (the
>>data=address or maybe data={address,address}) and have found some funnies.
>>
>>There are a few dozen single bit errors. There are also several
>>locations that come back with some F digits (as if the cells just
>>don't exist). Also they are mid-burst as much as not which indicates
>>it isn't a timing problem.
>>
>>I have done testing on different FPGAs with different SDRAM modules
>>and the errors definitely go with the modules and are quite
>>repeatable.
>>
>>I have checked the refresh timing and it's good.
>>
>>Is Kingston SDRAM really that bad ? The fact they are made of
>>repainted Infineon chips such that you can't read the original part
>>number makes me suspicious that these might not be the real
>>thing. They claim 100% testing but I wonder what they do with modules
>>tested as bad. Is it because the FPGA can keep memory busy in a way a
>>processor can't ? Should I speed up the refresh ? We intend to try
>>some Micron parts anyway.
>>
>>Jon
>>
>>
>
>I'd suspect your design before I'd suspect the modules especially if it's
>more then one module that's failing. Have you simulated the design using
>the Micron DRAM models? The Micron models do a very good job of checking
>that you've met all of the timing requirements. DRAMs have a lot timing
>requirements, not just set up and hold and refresh intervals, but things
>like precharge times, RAS to RAS times on the same bank, ...
>
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 89308This is a known issue in ISE 6.3i and was partially fixed in 7.1i if you are using timing driven packing and placement, turn off "register duplication". if this does not help, turn off "timing driven packing and placement" if this still does not help, try turning "keep_hierarchy" to "yes" Vladislav <stud_lang_jap@yahoo.com> wrote in message news:1126521312.596289.275800@z14g2000cwz.googlegroups.com... > Hello Guys, > > I am facing fatal error when i am synthesizing my RTL code. The same > code gets synthesized in synplify but not in ISE 6.3i. > I tried my luck for finding the answer in xilinx site but found no > information about. > > FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:1.13 - This > application has discovered an exceptional condition from which it > cannot recover. > > Has anyone faced this type of problem. Can you please suggest how can i > solve this problem. > > Thanks and Regards > Williams >Article: 89309
On Sun, 11 Sep 2005 20:07:38 -0700, Adam Megacz <megacz@cs.berkeley.edu> wrote:
>All I care about is speed (aka propagation delay), size, and the
>ability to map my "virtual CLBs" efficiently. I only need to program
>the device once. Given those (admittedly unusual) constraints, I'm
>trying to evaluate what's out there. Additionally, most of my stuff
>will be QDI self-timed, so clock distribution innovations aren't a big
>feature for me.
And previously
>I'm mainly curious about whether or not the speed advantages will
>continue on newer processes. In theory, an antifuse should have less
>capacitance than an SRAM-based pip, giving you lower propagation
>delays and hence higher clock rates. It looks like this was probably
>true doing a 150nm-to-150nm comparison of the Axcellerator versus
>FPGAs made on a similar generation of process technology.
There has never been a time that Anti-fuse based FPGAs have had a
speed advantage over "SRAM"* based FPGAs. Not from Actel, not from
Quicklogic, not from Crosspoint, and not from Xilinx. At any given
time, the underlying technology process node for Anti-fuse devices is
at least 1 generation and sometimes 2 generations behind the
tecnhology for the "SRAM" based parts. The only time performance
leadership has been claimed is in marketing material. When comparisons
have been made with similar process nodes, they represent product
availability that differs by a year or two. By the time Actel had a
150nm process that yielded, X and A were at 120nm or below.
The real speed killer for Anti-fuse is what they never talk about in
their comparisons. They always show the size of the Anti-fuse versus
the "SRAM" pass transistor (or pass gate) and say the far smaller
size leads to lower capacitance and therefore higher speed. This is
true. What they fail to mention is that to program the Anti-fuse
they need a pair of power transistors either side of the Anti-fuse
to sink enough current through the fuse to program it. They are big,
capacitive, at the end of long shared wires, and they are still there
after programming is done. The size of these transistors is so big,
that they kill most of the area advantage that came from the Anti-
fuses being small.
*: I use quotes around "SRAM" because although the FPGAs are referred
to as SRAM for their configuration memory, it would be far more
accurate to call it an array of latches loaded from a shift register.
>Does anybody have a general feel for whether or not Actel (or any
>other vendor) is going to bring out a new generation of antifuse fpgas
>on a newer process (90nm)? Or has this device style basically been
>shelved as only a specialty item for people who are ultra-sensitive to
>soft errors above all other factors?
The other big problem for the Anti-Fuse folks is that they have a
hard time getting the attention of the high volume leading edge
foundaries. They end up at second tier foundaries that are willing to
do the special stuff for Anti-fuse, but then the usually do not yet
have the leading process node available.
>However, I have to believe that the antifuse stuff requires a special
>process/fab, and that fab isn't going to be doing anywhere close to
>the volume that a strictly-CMOS fab would. That in turn drives up
>prices or else forces compromises that affect performance (in order to
>bring down costs).
Exactly right.
>So, ultimately, I'm wondering how this will play out. Obviously any
>comments at this point are pure speculation, but I'd appreciate
>speculation from somebody who knows more about this stuff than myself.
Although you say (up the top) that you only want to program the device
once, your project is architecture exploration. This is really helped
by being able to try lots of different things. I think I wrote about
this previously: http://tinyurl.com/bvbvz
Philip Freidin 1992 in comp.arch (on FPGA based algorithm accelerators)
>A real key observation is:
>
> The extremely quick prototype time to try an algorithm on one of these
> reconfigurable boards, to play with it, to profile it, and analyse the
> results, allows for exploration of the algorithm space in a manner never
> possible before. I have spoken with most of the above groups, and all
> have reported that the realy impressive speedups come when the you have
> enough hardware that is reconfigurable, that you can focus on trying
> multiple different approaches to a given problem. There are no costs
> involved in reconfiguring one of these boards (other than the time it
> takes to dream up a new algorithmic approach, and then implement it).
> It does not surprise me that these boards of "slow" FPGAs can outperform
> full custom chips designed for specific applications. The algorithm
> space is usually very large, and for computationally intense applications
> it may not be possible to do enough simulations to find which algorithm
> is best before commiting to build the full custom chip.
Philip Freidin
Crusader against Anti-Fuse FPGAs since 1989 :-)
Article: 89310I am trying to load a EDK design in modelsim for simulation.I can successfully compile the files but when I try to simulate the project, I get the following error. # Loading /home/simulation_library/simtemp/unisim.ppc405(ppc405_v) # ** Warning: (vsim-3479) Time unit 'ps' is less than the simulator resolution (1ns). # Time: 0 ns Iteration: 0 Region: /system/ppc405_0/ppc405_0_ppc405_i # Loading /home/simulation_library/simtemp/unisim.ppc405_swift_bus(ppc405_swift_bus_v) # Loading /home/simulation_library/simtemp/unisim.ppc405_swift(smartmodel) # Loading /home/downloads/modelsim5.8d/modeltech/linux/libsm.sl # ** Error: Failed to find LMC SmartModel libswift entry in project file. # ** Fatal: Foreign module requested halt. # Time: 0 ns Iteration: 0 Instance: /system/ppc405_0/ppc405_0_ppc405_i/ippc405_swift/ppc405_swift_inst File: /home/Xilinx/smartmodel/lin/wrappers/mtivhdl/smartmodel_wrappers.vhd # FATAL ERROR while loading design # Error loading design I have followed the Xilinx website answer links and followed the steps exactly. http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14019&BV_SessionID=@@@@2016379493.1126544090@@@@&BV_EngineID=cccgaddfilefmdjcefeceihdffhdfkf.0 I can run the command vsim unisim.ppc405 successfully. But when I try to simulate any other project from EDK I get the above mentioned error.Article: 89311
Robert wrote: > Hi! > > Has anyone successfully used opencores PCI in FPGA desings? > > I have seen this question posted a few years ago and I would like to > see if there are new answers to it. We have used it in a Xilinx V2 3000, and are going to use it in a V4FX60. There is a mail list for the PCI core at opencores, and it is archived at the web site. You might want to ask this question there, or search the archive to see if it has already been asked. Regards, John McCaskillArticle: 89312
In article <dfusn3$gr33@cliff.xsj.xilinx.com>, austin <austin@xilinx.com> wrote: >Adam, > >I think you have it well understood. > >I am sure there is work on better and smaller efuse technologies, as >even non-fuse based FPGAs may use fuses (for redundancy). Also, ASICs >and ASSPs use fuses for redundancy, repair, and setting bias voltages. > >A big fuse cell is a pain in the neck. Smaller is better. > >However, right now Actel has a bigger problem: the issue of their fuses >blowing on their parts (see NASA/JPL advisory notice 'do not use') due >to SI issues (large overshoot/undershoot on IOs). I've found notes saying 'the MODE pin must be grounded, and if you've ever powered up a flight item with an Actel FPGA with the MODE pin un-grounded you must replace all FPGAs on the board', dating from 1995; haven't seen anything about this 'bigger problem'. Though I'm a hobbyist, and wouldn't buy one-shot chips unless they were a couple of orders of magnitude cheaper than equal-performance reprogrammable equivalents. TomArticle: 89313
Nitesh wrote: > ** Warning: (vsim-3479) Time unit 'ps' is less than the simulator > resolution (1ns). # Time: 0 ns Iteration: 0 Region: > I have followed the Xilinx website answer links and followed the > steps exactly. Your simulator resolution is NOT set to 1ps as the instructions say in step 1, and the libswift.dll-entry is obviuosly missing (step 4). So either you did not follow the steps exactly, or something else is wrong. What file did you edit? Remember that changes in the modelsim.ini in the modelsim-directory don't affect projects created earlier. In the *.MPF (I think) of every project, the entire set of settings valid upon creation of the project is saved. If you change your modelsim.ini, the different settings do not apply if you load an older project. So what you really have to do is edit the MPF of your project. cu, SeanArticle: 89314
"GaLaKtIkUs™" <taileb.mehdi@gmail.com> wrote: >Is there a way to write a placer and router for Xilinx FPGAs. Or the >FPGA technology is closed at this level ?? You could write a placer using the "User Constraint File) or .ucf. -- Phil Hays to reply solve: phil_hays at not(coldmail) dot com If not cold then hotArticle: 89315
"Giox" <giovanniparodi79@yahoo.it> wrote: >The SDF is applied to the backannotated Verilog. The pre-route Verilog? Or the post-route Verilog? -- Phil Hays to reply solve: phil_hays at not(coldmail) dot com If not cold then hotArticle: 89316
The note regarding JTAG signal coupling is in the MAX II Errata sheet and applies only to the EPM1270 ES devices in the T144 package. The details of that are explained in the errata. This TDO/TCK coupling was corrected in the production EPM1270 devices (non-ES). You should check errata sheet to make sure this isn't related to your problem. The security bit does not prevent the device from being re-programmed nor does it prevent the part from being ID'd. A device with security bit set cannot be stand alone verified nor can it be examined/readback. The readback data on a secured MAX II part will read back as if the device were blank. If security bit is set, you can still re-program the device with a new design/POF. I tried it on a couple EPM1270 MAX II dev kits and it works okay. -Joe DArticle: 89317
how can you reduce the number if IOBs a design uses during synthesis? thanks -- Geoffrey Wall Masters Student in Electrical/Computer Engineering Florida State University, FAMU/FSU College of Engineering wallge@eng.fsu.edu Cell Phone: 850.339.4157 ECE Machine Intelligence Lab http://www.eng.fsu.edu/mil MIL Office Phone: 850.410.6145 Center for Applied Vision and Imaging Science http://cavis.fsu.edu/ CAVIS Office Phone: 850.645.2257Article: 89318
Hi, I've read through the archives for notes and hints on installing ISE 7.1i for Linux. I got curl, portmap, motif, etc all installed. The installer now comes up. However, when I enter in the Registration ID, it keeps telling me that it's invalid. Does ISE 7.1i use the same install code for Windows as it does for Linux? A Xilinx rep told me they are the same. Any help would be appreciated. This is very frustrating! Ram.Article: 89319
"geoffrey wall" <wallge@eng.fsu.edu> wrote in message news:dg4n2j$dqk$1@news.fsu.edu... > how can you reduce the number if IOBs a design uses > during synthesis? > > thanks Specify fewer input/output ports in the top level of the hdl file or schematics.Article: 89320
Thanks sean. I had to edit the mpf file since the project file was created before the changes to the modelsim.ini were made.It worked. NiteshArticle: 89321
Hi, To get started with Microblaze, I'm attempting to do a simple filtering application on audio, real-time. Audio is CD-quality, 44.1 kHz, 16-bits. I'm trying to handle multiple audio streams (8 to start with). I'm thinking about buffering 16 samples per channel. I'm trying to figure out what structures to use to facilitate data transfer of the audio samples from on-board memory into the filtering structure I'm trying to create. If this were a normal processor, I would use DMA to transfer from the external memory to a FIFO and do the processing. What should I consider doing with Microblaze? Create an OPB master to transfer from memory controller to an internal FPGA FIFOs? Use an FSL? Suggestions are appreciated. Ram.Article: 89322
Ram <r_fpga_dev@yahoo.com> wrote: > Does ISE 7.1i use the same install code for Windows as it does for Linux? > A Xilinx rep told me they are the same. At least my Linux version did. But I never tried the Windows version before. Are you talking about the product key you get by mail after registering your product at Xilinx's website? It's not the code on the box you have to enter in the installer, it's the one you'll get online. HTH -- mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver Wer braucht 'ne Maus, wenn er 'ne Tastatur hat? (Sebastian Linser)Article: 89323
Ram <r_fpga_dev@yahoo.com> wrote: > Hi, Hi! > To get started with Microblaze, I'm attempting to do a simple filtering > application on audio, real-time. Audio is CD-quality, 44.1 kHz, 16-bits. > I'm trying to handle multiple audio streams (8 to start with). I'm > thinking about buffering 16 samples per channel. You're talking about eight audio channels. This sounds pretty much like a mixer console ;) Are you sure you really want to use a Microblaze? Perhaps a DSP would better fit your job. I guess there are also DSP-SoftIP-cores available at Xilinx's. > I'm trying to figure out what structures to use to facilitate data > transfer of the audio samples from on-board memory into the filtering > structure I'm trying to create. You mean you don't want to write the filter in C-Code which would run as normal code on the Microblaze? If not, you can simply use your normal stack- and heap-commands from C: just initialize a pointer to some off-stack-memory-area and use it like you'd do on normal CPUs (without malloc). The Microblaze is a 32bit-RISC-CPU which has supporting tools like a C-compiler (mb-gcc) and even some kind of OS (if desired). AFAIK it is possible to run Linux on the Microblaze (or the xilinx-kernel). So to say: the Microblaze can handle offchip-memory via a OPB-sdram-controller (at least that's the way on my S3-Starterkit) > What should I consider doing with Microblaze? Create an OPB master > to transfer from memory controller to an internal FPGA FIFOs? If you don't want to do the processing with the Microblaze but use your own VHDL-filters instead, then it would be probably the best to create an OPB-slave, perhaps with interrupt support. In this case you can think of your filter as a PCI-audio-processing-card, except that you replace PCI by OPB ;) But what would be your Microblaze's purpose anyway? -- mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver Dass der MCSE eine Qualifikation ohne Wert ist, ist mir auch klar. (Detlef Bosau in dcoulm)Article: 89324
Ram, The xchecker cable has not been supported in any version of Xilinx software since 1999 (Release 4.1i) The latest software will work with either the Xilinx Parallel Cable IV or the Xilinx Platform Cable USB on Linux. As you might guess from the names, the former is a parallel port connected cable and the latter a USB port cable. The performance of either cable will be a substantial improvement over the xchecker cable. You can check out more details and pricing information on the Xilinx web site: http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=PRODUCTS&sSecondaryNavPick=Design+Tools&key=HW-USB http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=PRODUCTS&sSecondaryNavPick=Design+Tools&key=HW-PC4 Ram wrote: > Hi, > > I have an old Xilinx XChecker Serial cable which has served me well. > Apparently (not that I can tell) and unfortunately, it is not supported in > the newer ISE 7.1i tools. > > Which cable do you guys suggest to use? My only real restriction is that it > needs to work with Linux / Linux versions of the ISE 7.1i tools. USB > cables seem too flaky, but maybe that's changed? > > I'm also wondering if I should consider the Chameleon POD which can emulate > many useful JTAG adaptors. > > Ideas? > > Thanks. > RAM
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