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
Simon Bilodeau <sbilodo@videotron.ca> wrote in message news:Ta_85.317$VQ6.1085@wagner.videotron.net... > Is it normal to have 200 ohms resistance between TCLK and TMS and between > TCLK and TDI pins directly on the chip? > > I saw that those pins influence each other because the programmer's pins > can't get enough current on IC's pins (the programmer works well alone) and > I didn't see anything special that could make a short on the board. No it's not right. Alun CamdigitalArticle: 23776
See http://support.xilinx.com/techdocs/5638.htm Jens Popp wrote: > Hi, > > does anybody know what this is? It happens when I try to invoke a Syntax > Check/ Synthesis of Verilog Code in Foundation. > > Initialize DPM... > > Checking license... > > License check OK. > > Source: G:\FNDTN\ACTIVE\PROJECTS\CPU\mux16.v. > Create project... > DPM Error: Project creation/opening failed.Ausnahmefehler des Servers. > > Thanks > -- > > Jens Popp > Institut fuer Rechnerstrukturen > Universitaet Siegen > Hoelderlinstr.3 > D-57068 Siegen > Germany > > TEL +49 271 740 2376 > FAX +49 271 740 2473 > mailto:popp@rs.uni-siegen.de -- ***************************** Anna M. Acevedo Xilinx University Program 2100 Logic Drive San Jose, CA 95124 PH: (408) 879-5338 FAX: (408) 879-4780 Email: anna.acevedo@xilinx.com http://www.xilinx.com/programs/univ.htm *****************************Article: 23777
Robert Posey wrote: > > rickman wrote: > > > > Robert Posey wrote: > > > > > > Rickman wrote: > > > > > > > > > > >You could get 100% coverage of I/O and Macro cells fairly > > > easily with special load modes, and even get 100% coverage of logic in each > > > cell at considerably more expense. Getting 100% coverage of the RAM in the > > > part would be a little harder, if not impossible. > > > > I don't understand why this is hard. RAM is easy to test by loading and > > testing patterns. Each bit can be independently tested with simple > > patterns. The bits can be tested against the neighbors with more complex > > patterns. The largest array of RAM in a Xilinx part is 4K bits. > > Certainly this is not time exhaustive to test? > > The question is how can you access it, to test a memory to 98% using a > venerable March II takes about 4 patterns, at 8 memory accesses per-cell, > per-pattern. According to their website, XILINX XC4000XV has over > 270,000 RAM bits. If you are using Serial Access mode, that means you have > to perform 270Kx4x8 ~= 8 Megabit Reads and Writes which I admit is not > impossible, takes awhile. That only gives you 98% coverage of all hard and > soft faults. I over-estimated how many RAM cells there where, so it is doable > even through the serial port. I not well versed in the the RAM cell accessing > methods, but if its not random this number would go way, way up. Of course for > to detect stuck at faults the number of patterns should be far less. You can't > test individual RAM Bits, it must always be against its neighbors, to catch all > even hard faults. The classic alternating A's and 5's only detects 1/2 the > data bit faults, and tests only 1 address line. I am by no means saying that > you can't get upper 90's coverage, but you can't get 100% detection on anything. > > > > > > How could you test all > > > the possible BIT leakage combinations in a reasonable time. You can test the > > > configuration RAM for a given operational load fairly well by reading back the > > > down load, but this is by no means a 100% coverage. If you have a RAM Cell > > > that floats, it may return the correct value part of the time. Then you have > > > the issue that all the RAM and Logic Cells have the potential to leak to > > > any cell that is close to in some manner. RAMs have faults that cause certain > > > memory cells to change for a correct 0 to a 1, only when all surrounding > > > cells are also 1's. > > > > This is true for standard memory such as SRAMs. But the configuration > > memory is made of D FFs and are not co-located with memory from the > > other CLBs. So you don't have the same test problems that you have with > > SRAM. > To really know, you have to look at how isolated each piece is on the actual > die. If the RAM cells are embedded in the logic, then the logic states may > cause unwanted changes or the reverse. It is likely you are somewhat less > likely to have this problem in FPGA, than other Memories. > > > > > But that is not normally what we mean when we talk about coverage of > > test sets. We assume a much simplified failure model and test against > > that. Other failure modes need to be tested separately. So we would need > > a different set of test vectors to test against quantum fluctuations in > > the sub-space field. ;) > > Hey for Reagen's Star Wars program to have worked, they would have had to > detect and correct for those on the fly to get the 100's million part system to > work. :) Most of the difference is the location of the testing. My tests run > over a large temperature range, and on systems exposed to radiation (hopefully > just in space). If you read NASA pages on FPGA's you will find that they > feel the need to recheck the program load in the FPGA's periodically during > operation to correct Single Event Upsets of RAM Cells. In Space Applications, > this is a real problem, and you can be fairly sure your system won't work > for long if you don't handle this issue. There is also a severe shortage of > IC Test Machines on the battle field, thus all test support is in system. > I am well aware of what test coverage means in most of the commercial world, > but the original 100% poster was quoting someone from the defense industry that > has a well defined concept of failure detection that is based on failure rate, > and includes soft and hard failures. > > Robert Posey Yes, I agree that no system can be tested 100% for all possible failures. But what is your point? I did not see anywhere in the original post that this was a "defence industry" test issue. The thread started out asking about tools to insert scan chain registers. I was tying to make the point that by making use of the reconfiguration capabilities the parts could be tested just as well (to 100% by normal "stuck at" fault measures) without adding extra test logic in the FPGA. But I will always agree when someone tells me that a system can not be shown to work by testing. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23778
Andy Peters wrote: > > Jens Hildebrandt wrote in message > <39658097.32F7DDE9@e-technik.uni-rostock.de>... > > > > > >Andy Peters wrote: > >> > >> Kai Schulze wrote in message <3964734C.D088118F@ee.nec.de>... > >> >Hi, > >> > > >> >I'm working with a XILINX XC40250XV and I have following problem: > >> > > >> >There is an signal input port and a internal clock should be generated > >> >from this signal. > >> >How can I push synopsis to create the internal clock buffer for this > >> >internal clock automatically. > >> >Is there at all a way to say "synopsis do this". > >> > >> If that signal is connected to only flip-flop clocks, the tool should > infer > >> the proper global buffer. > >> > >As far as I know Synopsys, this is done only for external clock inputs > >(i.e. inputs that drive only flip-flops or that are explicitly set to > >pad-type "clock") > >For internally generated clocks like the divided-by-X or multiplied-by-Y > >or gated-by-Z input clock etc. you have to instantiate a BUFG clock > >buffer (for XC4k) and set a dont_touch attribute to it. > >BTW,in that case, if you use the timing constraint "clock" for that > >signal you have to define it for the buffer output signal as the Xilinx > >tools don't propagate such a constraint through a clock buffer. > > Actually, with FPGA Express v3.3, if you create a divided clock, a la: > > clkdiv : process (fastclk, reset) is > begin > if reset = 0 then > slowclk <= '0'; > elsif rising_edge(fastclk) then > slowclk <= not slowclk; > end if; > end process clkdiv; > > and you then use slowclk for flops only, it WILL instantiate a clock buffer > and that buffer's output will drive your slow-clocked flops clock inputs. > Unfortunately, the tool gives the output of that buffer a stupid name (such > as N3012) so every time you synthesize, you have to figure out hat the new > name of the slow clock net is and edit your P+R constraints accordingly. > > If anyone knows a way to apply a period constraint to flops clocked by the > derived clock without having to figure out what the clock net is called, I'd > love to hear it. > -- a > ----------------------------------------- > Andy Peters Wouldn't instantiating a clock buffer be a good way to apply a period contraint? -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23779
rickman wrote: > > Robert Posey wrote: > > > > rickman wrote: > > > > > > Robert Posey wrote: > > > > > > > > Rickman wrote: > > > > > > > > > > > > > > >You could get 100% coverage of I/O and Macro cells fairly > > > > easily with special load modes, and even get 100% coverage of logic in each > > > > cell at considerably more expense. Getting 100% coverage of the RAM in the > > > > part would be a little harder, if not impossible. > > > > > > I don't understand why this is hard. RAM is easy to test by loading and > > > testing patterns. Each bit can be independently tested with simple > > > patterns. The bits can be tested against the neighbors with more complex > > > patterns. The largest array of RAM in a Xilinx part is 4K bits. > > > Certainly this is not time exhaustive to test? > > > > The question is how can you access it, to test a memory to 98% using a > > venerable March II takes about 4 patterns, at 8 memory accesses per-cell, > > per-pattern. According to their website, XILINX XC4000XV has over > > 270,000 RAM bits. If you are using Serial Access mode, that means you have > > to perform 270Kx4x8 ~= 8 Megabit Reads and Writes which I admit is not > > impossible, takes awhile. That only gives you 98% coverage of all hard and > > soft faults. I over-estimated how many RAM cells there where, so it is doable > > even through the serial port. I not well versed in the the RAM cell accessing > > methods, but if its not random this number would go way, way up. Of course for > > to detect stuck at faults the number of patterns should be far less. You can't > > test individual RAM Bits, it must always be against its neighbors, to catch all > > even hard faults. The classic alternating A's and 5's only detects 1/2 the > > data bit faults, and tests only 1 address line. I am by no means saying that > > you can't get upper 90's coverage, but you can't get 100% detection on anything. > > > > > > > > > How could you test all > > > > the possible BIT leakage combinations in a reasonable time. You can test the > > > > configuration RAM for a given operational load fairly well by reading back the > > > > down load, but this is by no means a 100% coverage. If you have a RAM Cell > > > > that floats, it may return the correct value part of the time. Then you have > > > > the issue that all the RAM and Logic Cells have the potential to leak to > > > > any cell that is close to in some manner. RAMs have faults that cause certain > > > > memory cells to change for a correct 0 to a 1, only when all surrounding > > > > cells are also 1's. > > > > > > This is true for standard memory such as SRAMs. But the configuration > > > memory is made of D FFs and are not co-located with memory from the > > > other CLBs. So you don't have the same test problems that you have with > > > SRAM. > > To really know, you have to look at how isolated each piece is on the actual > > die. If the RAM cells are embedded in the logic, then the logic states may > > cause unwanted changes or the reverse. It is likely you are somewhat less > > likely to have this problem in FPGA, than other Memories. > > > > > > > > But that is not normally what we mean when we talk about coverage of > > > test sets. We assume a much simplified failure model and test against > > > that. Other failure modes need to be tested separately. So we would need > > > a different set of test vectors to test against quantum fluctuations in > > > the sub-space field. ;) > > > > Hey for Reagen's Star Wars program to have worked, they would have had to > > detect and correct for those on the fly to get the 100's million part system to > > work. :) Most of the difference is the location of the testing. My tests run > > over a large temperature range, and on systems exposed to radiation (hopefully > > just in space). If you read NASA pages on FPGA's you will find that they > > feel the need to recheck the program load in the FPGA's periodically during > > operation to correct Single Event Upsets of RAM Cells. In Space Applications, > > this is a real problem, and you can be fairly sure your system won't work > > for long if you don't handle this issue. There is also a severe shortage of > > IC Test Machines on the battle field, thus all test support is in system. > > I am well aware of what test coverage means in most of the commercial world, > > but the original 100% poster was quoting someone from the defense industry that > > has a well defined concept of failure detection that is based on failure rate, > > and includes soft and hard failures. > > > > Robert Posey > > Yes, I agree that no system can be tested 100% for all possible > failures. But what is your point? > > I did not see anywhere in the original post that this was a "defence > industry" test issue. The thread started out asking about tools to > insert scan chain registers. I was tying to make the point that by > making use of the reconfiguration capabilities the parts could be tested > just as well (to 100% by normal "stuck at" fault measures) without > adding extra test logic in the FPGA. It was in the second post on my list, but its not important. > > But I will always agree when someone tells me that a system can not be > shown to work by testing. > > -- > > Rick Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 23780
rickman wrote in message <396646B2.838BBDFA@yahoo.com>...
>Andy Peters wrote:
>> Actually, with FPGA Express v3.3, if you create a divided clock, a la:
>>
>> clkdiv : process (fastclk, reset) is
>> begin
>> if reset = 0 then
>> slowclk <= '0';
>> elsif rising_edge(fastclk) then
>> slowclk <= not slowclk;
>> end if;
>> end process clkdiv;
>>
>> and you then use slowclk for flops only, it WILL instantiate a clock
buffer
>> and that buffer's output will drive your slow-clocked flops clock inputs.
>> Unfortunately, the tool gives the output of that buffer a stupid name
(such
>> as N3012) so every time you synthesize, you have to figure out hat the
new
>> name of the slow clock net is and edit your P+R constraints accordingly.
>>
>> If anyone knows a way to apply a period constraint to flops clocked by
the
>> derived clock without having to figure out what the clock net is called,
I'd
>> love to hear it.
>Wouldn't instantiating a clock buffer be a good way to apply a period
>contraint?
Oh, absolutely it would. But "it would be nice if I didn't have to do
that." I mean, I'm not sure why the tool feels the need to give the
post-BUFGLSed net a bizarre name, esp. since, for input clock pins, it names
the buffered version something obvious such as sysclk_BUFG.
Actually, since the period constraint is applied to the pin before the
global buffer, whyizzit different for derived clocks?
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"A sufficiently advanced technology is indistinguishable from magic"
--Arthur C. Clarke
Article: 23781
Can anyone point me towards (or e-mail me) a copy of the Xilinx 6200
data sheets. Xilinx no longer makes them available (as far as I could
find anyway) but they'd be invaluable for the research that I'm involved
with.
Many thanks in advance
Steve
Steve Oldridge
steveo@ece.ubc.ca
University of British Columbia M.A.Sc. Student
Article: 23782
Alan Hu wrote:
> In article <395714B0.F9A192B6@opencores.org>,
> Jamil Khatib <khatib@opencores.org> wrote:
> >Hi,
> >Could you please mention some good universites in Canada "English
> >speekers area" to continue my graduate studies in the Reconfigurable
> >Computing and its EDA feilds.
> >
> >Please email me at khatib@opencores.org
> >
> >Thanks in advance
> >Jamil Khatib
> >
>
> University of Toronto is the default high-profile Canadian university,
> and they do have cool stuff going on in EDA and reconfigurable computing.
>
> UBC has great EDA research (including reconfigurable computing), too,
> plus we have better weather, better skiing, better hiking, ... :-)
>
> --Alan Hu
I'd have to agree with Alan... UBC has a great FPGA group, and we're
looking into reconfigurable computing, although the research is just
preliminary right now. We've got students looking into both
FPGA/Microprocessor combinations as well as FPGA/ASIC groupings. As far as
U of T, I looked into it when I was deciding where to do my Masters, but I'm
a West Coast boy through and through. The style of life and the weather out
here can't be beat. That and Steve is one of the best profs I've ever met.
Best thing to do is talk to the group heads. Over here that'd be Steve
Wilton (http://www.ece.ubc.ca/~stevew/) and I'm not sure who now runs U of T
but their site is (http://www.eecg.toronto.edu/EECG/RESEARCH/FPGA.html). If
you've got any other questions about UBC from a student's perspective you
can e-mail me at the address below. Best of luck and let me know how it
goes because I'll probably be looking for a place to do a PhD in a year or
two...
Cheers
Steve
Steve Oldridge
steveo@ece.ubc.ca
M.A.Sc. Student ~ University of British Columbia
http://www.ece.ubc.ca/~steveo/
Article: 23783rickman wrote: > Robert Posey wrote: > > > > Rickman wrote: > > > > > > I disagree that you can't get 100% coverage for test. I am sure that Xilinx > tests every chip they make 100%. Since the chip is fully > programmable, I doubt that they needed to design in special test circuitry or > modes. Certainly this may take more than a single bit file. But I am sure that you > can test every transistor, every wire and every connection in a Xilinx FPGA if you > need to do that. > > > Its an absolute fact you can't get 100% coverage of all the possible failure > modes of an FPGA. > > Perhaps we need to qualify this statement. Certainly you can never get > 100% coverage for ALL modes of failure. There are time variant failures the can > never be detected by test unless you get lucky. I was referring to "stuck at" > faults. These are the ones that can be systematically analyzed and accounted for > and are most common. Less common are the "shorted" faults where two nodes are > shorted together. Shorted faults do not result in a defined behavior. When shorted > and driving different states, two nodes may drive a high, a low or an indeterminate > value which has very poorly defined behavior (failing sometimes and not others). So > "shorted" faults can not be systematically analyzed. You can see these faults by looking at the Icc levels. This generally falls under the heading of IDDQ testing. IDDQ testing definitely adds to the fault coverage and while there is some overlap with stuck-at testing, is complementary. ---------------------------------------------------------------------- rk History will remember the twentieth stellar engineering, ltd. century for two technological stellare@erols.com.NOSPAM developments: atomic energy and Hi-Rel Digital Systems Design space flight. -- Neil Armstrong, 1994Article: 23784
rickman wrote:
< major snippage >
> I did not see anywhere in the original post that this was a "defence
> industry" test issue. The thread started out asking about tools to
> insert scan chain registers. I was tying to make the point that by
> making use of the reconfiguration capabilities the parts could be tested just as well
> (to 100% by normal "stuck at" fault measures) without adding extra test logic in the
> FPGA.
I believe that the original poster was using Actel FPGAs with antifuse technology. For a
reprogrammable device, the situation can in fact get more complicated for 100% stuck-at
testing. For example, you must show that each individual configuration logic bit can be
set. You must also show that each individual pass transistor is capable of controlling
it's connection - being both open and closed.
Complicating things further is demonstrating that other architectural features do not
have any stuck-at faults. For example, programmable delays (found in the I/O modules of
some FPGAs) and DLLs quickly come to mind.
- - - - - - - - - - - - - - -
> But I will always agree when someone tells me that a system can not be
> shown to work by testing.
Very much agreed. One can not test in reliability. I have seen many people declare
their systems bug free only to fail later, when environmental conditions change, a new
batch of parts come in, or Mr. Murphy comes home from vacation.
Have a nice evening,
----------------------------------------------------------------------
rk History will remember the twentieth
stellar engineering, ltd. century for two technological
stellare@erols.com.NOSPAM developments: atomic energy and
Hi-Rel Digital Systems Design space flight. -- Neil Armstrong, 1994
Article: 23785
Hi,
We've updated our FPGA Internet resources at:
http://www.eg3.com/WebID/soc/fpga/net-rsrc/blank/hot-list/a-z.htm
Our goal for the summer is to look for free demo's, code, free seminars,
etc. - non-commercial stuff, either from vendors (yet not that
sales-oriented) or elsewhere on the Net. If you know of something that we
do not index, please email pr@eg3.com.
Thanks.
--
Best regards,
Jason McDonald
Senior Editor
jmcdonald@eg3.com
------------------------------
http://www.eg3.com
eg3.com: window on the electronic design world
2.1 million hits per month - 150,000+ users:
tel: 408-938-9150 fax: 408-938-9155 email: inquiry@eg3.com
audience:
* software and hardware design engineers
* programmers * oem decision-makers
* management and chief executive officers
categories:
* applied computing * dsp * embedded chips
* embedded software * embedded systems
* industrial computing * internet
* mcu/mpu * realtime * news * hi-tech marketing
Article: 23786I want to study VHDL with MaxPlus2 9.x. But I don't know to download. Please known me the FTP address or so.Article: 23787
Or use Xilinx's Coregen. They have a pipelined divider with various options. Regards, Allan Redenbaugh "Kate Atkins" <kate.atkins@siraeo.noldckspam.co.uk> wrote in message news:962637629.2771.0.nnrp-08.9e98b847@news.demon.co.uk... > Hi Dan > > Take two binary numbers. > Divide one by the other using pencil and paper. > Turn what you just did into logic. > > Last time I did it there was a compare, a subtract and a shift. How long you > keep going round the loop depends on how much accuracy you need. > > Of course there may be better ways! > > Kate > > Dan <daniel.deconinck@sympatico.ca> wrote in message > news:2xI75.21849$W35.537179@news20.bellglobal.com... > > Hello, > > > > I am looking for 16 bit integer division. (I need to calculate averages) > > > > I just hope for a tip on technique. I do not need high speed. > > > > I use Xilinx. > > > > Sincerely > > Dan DeConinck > > > > > > > > >Article: 23788
Steve Oldridge wrote ...
>Can anyone point me towards (or e-mail me) a copy of the Xilinx 6200
>data sheets. Xilinx no longer makes them available (as far as I could
>find anyway) but they'd be invaluable for the research that I'm involved
>with.
> Many thanks in advance
> Steve
Hi !!!
You can find PDF-file at :
http://dec.bournemouth.ac.uk/drhw_lib/archive/xc6200.pdf
A nice site about Reconfigurable Computing theme.
Dmitry
Article: 23789Hi, "webber" <cslim@dreamwiz.com> schrieb im Newsbeitrag news:AAH95.7$ZV4.1180@news.hananet.net... > I want to study VHDL with MaxPlus2 9.x. > But I don't know to download. > Please known me the FTP address or so. Their baseline software is available @ http://www.altera.com Greetings, CarlhermannArticle: 23790
UNIVERSITY OF ABERDEEN CENTRE FOR ENVIRONMENTAL & INDUSTRIAL IMAGING This multi-disciplinary research centre represents expertise in such areas as computational image analysis, pattern recognition, holography and instrumentation. There is experience in a wide range of imaging modalities and application areas, and an extensive network of links with industry. The work is supported by state of the art computational and imaging equipment. RESEARCH STUDENTSHIP Applications are invited from UK/EU nationals for a three year PhD Studentship. The student will work on aspects of the representation of image information, with an emphasis on multiscale techniques and compression. The immediate application area will be in the imaging of deepsea marine life. Project supervision will be joint between the Departments of Engineering and Zoology. The techniques developed will have relevance to other environmental and industrial applications of interest to the Centre. The work will provide experience in computational imaging, compression techniques, and embedded systems engineering. The funding of the studentship covers UK/EU tuition fees and a maintenance grant equivalent to standard Research Council rates (UKP 6800 for 2000-01). Applicants should have a good first degree (equivalent of UK 1st class or upper second) in computational, physical, engineering or mathematical science. Informal enquiries may be directed to Dr Alastair Allen, telephone: +44 1224 272501, fax: +44 1224 272497, e-mail: a.allen@abdn.ac.uk Application forms: Postgraduate Office, Department of Engineering, Fraser Noble Building, University of Aberdeen, Aberdeen, AB24 3UE, UK. Tel: +44 1224 272513. Fax: +44 1224 273895. Email: pgoffice@eng.abdn.ac.ukArticle: 23791
Robert Binkley wrote: > Simon, > > We answered that one too. > > MS Excel spreadsheets for the Spartan-II pin-out tables (seven files zipped > together) can now be found on Xilinx's web site at the following URL: > > http://www.xilinx.com/products/spartan2/s2_pin.zip > > There will be no page links for another week yet. After downloading, you > can save the excel files as text files with different delimiters (see > included readme file). Please let me know if you have any questions. > ... and when will the same files appear for Virtex, VirtexE, ViretxII., XC4K, SpartanI, XC95K etc. If you manage to get all of these on the Web in almost electronically readable [still have manually dump the .csv files from Excel] Perl parseable form Xilinx will have achieved an industry first far more pratically important than the first GigaGate FPGA.Article: 23792
Rick Filipkiewicz wrote: > > Robert Binkley wrote: > > > Simon, > > > > We answered that one too. > > > > MS Excel spreadsheets for the Spartan-II pin-out tables (seven files zipped > > together) can now be found on Xilinx's web site at the following URL: > > > > http://www.xilinx.com/products/spartan2/s2_pin.zip > > > > There will be no page links for another week yet. After downloading, you > > can save the excel files as text files with different delimiters (see > > included readme file). Please let me know if you have any questions. > > > > ... and when will the same files appear for Virtex, VirtexE, ViretxII., XC4K, > SpartanI, XC95K etc. > > If you manage to get all of these on the Web in almost electronically readable > [still have manually dump the .csv files from Excel] Perl parseable form Xilinx > will have achieved an industry first far more pratically important than the > first GigaGate FPGA. Isn't it amazing how simple it can be to please customers? You just give them what they want! :) -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23793
begin 666 ommom.jpg
M_]C_X``02D9)1@`!`0$`8`!@``#_VP!#`!`+#`X,"A`.#0X2$1`3&"@:&!86
M&#$C)1TH.C,]/#DS.#=`2%Q.0$1713<X4&U15U]B9VAG/DUQ>7!D>%QE9V/_
MVP!#`1$2$A@5&"\:&B]C0CA"8V-C8V-C8V-C8V-C8V-C8V-C8V-C8V-C8V-C
M8V-C8V-C8V-C8V-C8V-C8V-C8V-C8V/_P``1"`#<`=D#`2(``A$!`Q$!_\0`
M'P```04!`0$!`0$```````````$"`P0%!@<("0H+_\0`M1```@$#`P($`P4%
M!`0```%]`0(#``01!1(A,4$&$U%A!R)Q%#*!D:$((T*QP152T?`D,V)R@@D*
M%A<8&1HE)B<H*2HT-38W.#DZ0T1%1D=(24I35%565UA96F-D969G:&EJ<W1U
M=G=X>7J#A(6&AXB)BI*3E)66EYB9FJ*CI*6FIZBIJK*SM+6VM[BYNL+#Q,7&
MQ\C)RM+3U-76U]C9VN'BX^3EYN?HZ>KQ\O/T]?;W^/GZ_\0`'P$``P$!`0$!
M`0$!`0````````$"`P0%!@<("0H+_\0`M1$``@$"!`0#!`<%!`0``0)W``$"
M`Q$$!2$Q!A)!40=A<1,B,H$(%$*1H;'!"2,S4O`58G+1"A8D-.$E\1<8&1HF
M)R@I*C4V-S@Y.D-$149'2$E*4U155E=865IC9&5F9VAI:G-T=79W>'EZ@H.$
MA8:'B(F*DI.4E9:7F)F:HJ.DI::GJ*FJLK.TM;:WN+FZPL/$Q<;'R,G*TM/4
MU=;7V-G:XN/DY>;GZ.GJ\O/T]?;W^/GZ_]H`#`,!``(1`Q$`/P#J****\,]`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHJGJ]_\`V9ILUWY?F^7CY<XSD@=<
M>]-)MV0-V+E%)D>O?N??%9TFM6T5C=W3)+LM)?*D7`W$@@9'/3D52A)]">9&
ME12<@9/0'!(Z?XT<X'')Z>]39CYD+13)ID@A>61@(XU+L?0#G^E9L6L.T.FE
M[;;-?-\L6_[J=2^<<X7!QUYJHTY2V$Y)&K12<XR>./UH)QGV_P#U5/*[[#NA
M:*3G'^?SZT=CUXZT6870M%)R/K_/_/UJI<WWV?4K*T\K<+GS/GW8"[5W?C34
M6W9!=%RBDS@\D<?AZ?X_RI>G7UQUQ2LPN@HI.>.V?7USC_/X4#D#!Z\46?8+
MH6BD_#&?7C'YU7L[V.],_E*X\B9H6##^(>GYC&<4U%O8+HLT5#<R31B(PP";
M=(%?YPNQ>[<]<>E2Y_\`K=.>_K[T<K"Z%HI.<=#CV&:.?\\TM]@NA:*ANYS;
M6<UQLW>4C.5!ZX!./TI+.<W5E;W&W;YL:OMSG&1G&<57([7871/12<]*/QY]
M_P#/%39A="T4G/\`B.X_SZ4=!D\#J21@#_/]:$KA="T4G(ZC%&<`FBS"XM%)
MSGIW_P`\T=3Q].F?ZYI\K"Z%HJG>7PM[JTMU3S);I\``XVJ.6;/MZ=ZMY(Z_
MKV^M'*[7%S(6BDSTR0,GO_GFCG(_S^OXTK,=T+12>GO5;3[Z/4;..ZA#*DF<
M!@,C!(Z?AUI\K"Z+5%(3@\_SHYS@CGT'^?\`(Q2LPNA:*3_/_P!>JVHWT>G6
M,EW,KM&F,A1SR<=^.XIJ+>E@NBU12?R[<4M*S3L.X4444@"BBB@`HHHH`***
M*`"BBB@`HHHH`****`"L?Q;_`,BW=_\``/P^=>:V*K:A8QZC9R6LK.J28R4(
M!X(/?Z5=-\LDQ25T8QTZ#3?$6E"V,@:=9EF=I"3)A<C.3Z\UB7&E62Z+J]P(
M?WMO>-'$VYCM4,HQC.#UZUV<]E%<7UM=.S;[??L`(P=RX.?R[54ET"TE:\#2
MSB.[SYD0D^0,2#N`]<@'_P"M75&LENS)Q90U/3;9=2T2QC#16_[\;4D()!&2
MNX\\\C\<58TZWBTSQ!-86@(MY;83["Q(5@VWCZCD_0=JBU#23+>Z3`7NY8HQ
M-ON"Q+H2`5)8=.<8^E:>G:9%IS3.LD\\LY!>2=]S-@8`SCMS1*2Y=P293U>)
M;'0TT^P_=?:)!;1<DA=YR<Y]1N^F126\4<WB'RXP%@TRW6.-6/(=QUSW&T8.
M3VJZFEQC[)YMQ<3_`&1BZ^<X;>3T+?3MZ5+:64=J\\BL[R7$F]W<C=TP%!]`
M.GI4^T2B[;CY3CX+*&#P@FK)O-[$P:.0N?W>)0.!TQ]1WK7_`+.ATSQ'I?V4
MR!YA,)Y-[%I2%!YY]>:T/[$MCHO]D^9*8>S;AN/S;O3%6)[**XO+:Y=G\RWW
M[`I&#N&#FCVVOWBY3CK:TO-4M6OTTJ22ZF<NEVEV$"-G@!.P&,8/OSTQL:I`
M;W4M!AO`\;R)(9E1L'[@)7/IP1UZ5<E\/VSW$SK<W<23,6D@2;;&Q/4$=><5
M<DT^![JTN!E#:!A$B8"@,NTC'MQTJI54]@Y3#L='LYM4U*P='-E;&-HX!(=N
M]D&6/.2?EX^IJC90B^A\.13R2;6^T`E7VDJ/X<]1G&/I760644%[<W:L_F7&
MS>#@A=HP,50/AJS-M:0&6X`M-_ELK;6RQSG('8X(^E"K*^K_`*L#BR/3H(M,
MU^;3[0%;:2V$^PL6"L&V\>G')SZ#M6!;VE[J=J]\NER27,\A9+M;L)L;=P`O
M8`C'/Y],=;IVF0Z>9I%DFFEF(,DD[[V(`X!X],_G59_#ULUQ(XN;N..5BTL*
M381\_>R.N#1&M!-ARLH2V7]H^(((]25E_P"):CS1JVT%MV""0>@/\AUJM<:<
MMC)<2:CIUW-!&Q%O=03%S#&.57:6X"C/)XS^O2)801Z@MXF5D6#[.%4@*JYS
MQ^'%5KG1+:XG>03W,*R',D44VV.4]RP]2.M"K*XG!]"]:NLMK$Z2-(K1@B0C
MEN.">`._2N,FT^VM]"UR>*+;+'=M;J=Q.$#H=O7]3Z5V)M%,]O(DCQK""%BC
M.$8$8P1W`[50G\/VDK78,]PD=T<R1+(-H.X,2`0>25_6IISA&XY1;*>IZ;:Z
M>-.-NK[Y+^'?([$LY&[DY[G/^<4U--MM1\2:NMVKR(GDXCWE5)*=3@\GT[<G
MU%;=Y8QWI@\TL/(F690IZLN<`\=.:R/[)-WK^IS2/=6P/E>7-`Q0NNS#`'H1
MD+^55&::O>P-%/S9/[)_LWS#Y8U+[%YFX^9Y>?7IG'?I[=*NQV5OHVNV45@I
MCBO(Y$EC+DJ=HW!N3][G'/KTK1_LBU_LC^R_F-OMVG#<YSG/Y\TW3](AL;EK
MG[1<W,Q0)YEQ)OPN<X'I2]K%WM_PX<K,)-/M]1\/76L7'F?;)4ED+AR-N,C:
M.<;<#H>?Z=#H_.CV/'_+O'G!_P!D>U5)_#EI/+.3/=K%.S.\*S?(6/?'KGG\
M*NQ6*1&S"33;;5=BH'&UQ@#YAW/&?QJ:DXR5@46C#33X-9DU.]NIC%-!<-'%
M*K_+"J`8;!/3U_3%37$$>IZO:6%Y+]HMXK/S]RM@2L2%W'!Y&.>/SQ5N]T"T
MO;IYI)IU\T+YL:RX6;;T+#_/2I[[28+U8,/-;-!GRC;ML*@C&T'IV'Y57M8Z
M!RLYW45^QZ7KFGQ9\BV>%XLL24WD$@9Z#]?<U9N='MK76=.MX#*JW8E2Y<.=
MTH4*V"<\`D=L5J#0K4Z3+I_F3LD[^8\A<%W8D'))X[#\JM3V44][:W3,WF6V
M[8`1@[A@Y_\`K4W6C=68<O<S-"@CL]6U:T@W+;Q&$HNXD+N0DGGN3BDUZV2Z
MUW1X)2ZH_G;MK;"1M&5SZ'&/Q-:L%E'!?7-TC-YEQLW`D8&T8&/U_*L?4-(,
ME[I-MYEU+#&)M]P6.Y"1E6+#ISC'TJ5)2G?^M@:=K#%":)J-];6"_N?L)N5C
M=B0KKD8&3G!`Y'7\*R[73]0-M;7EII;F[RLPNFO`?,[G<,]#SQU_7/5:=ID>
MG-,Z2SS23$&229]S-@<#.![_`)U4A\.6D15?M%T]LK;OLSRYBZY`(],\U:K1
MNQ<C8Y?],\4,W)CL80J`\$/(,Y&.OR\'WZ#BL/3M(MI/"7]H,9?M42.\4@D(
M\O:Q(`[`<$_C[UU5K9QVKSRJSO)/(9'9CECZ`8'0#I7/Z/X=CGTF$73WD+-G
MSK?S"BN0QP2I]@OY4HS7+N#B[DK*NMZC8V]\,P?81=,B.RAG)QR>O';O_*HT
MM[E8-9TG37=/(:-X#YAS\PW%0?3C@>_)-;>I:9%J+0NTD\,L))CD@?:P!&",
M^_\`GK3;?2+2&PEM'5YXIF+RF4[F<G^(GUX'Y9I>UA8?*S'TV&QAO5LY+&ZT
M^2X1T>(REX9AW&_G)`YR,8/%5--@L+?PK;W$RW.;F0(Z6['=<$.P"=?3TQT]
M:Z&STB*UN!</<7-U*H(5KB3?LSU"^F>/RJ!?#MHMLT"W%T(_,62,";_4,"3\
MGIU/7/;TJO;1;#E9G:#']F\1R1164MC"]KO$+R$[_GP&(R<'!(QVP?6H8M.@
MU#PY<ZO/YGVR5)9"ZN0%QD;<9QC"]#SBMVST6VL[I;F.:=IRI1Y)'W&13C&[
M/88&,8Z"N>O+5I?M"#3-52YN&)-NKAK<2-T8L/3AO8\=!51DI.Z)=T36UC#J
M&IV$-QN,7]DQLR*Y4.0>`<>^#^%5[J"(>%]6CP2MI?LL`+D[!N48'J/F/'X]
M:Z2QTM+9K>>1_P!_%:K;,%/R8&"2,C.<T-H]LUG>6LC2&.ZE,KY8`JQQR#[8
MS4NM'F*Y6RU:VL-E;I;VR;(DSM&2>I)[\U/4-G;_`&6V2'S99=N</*VYCDYZ
M_C4U<<G>5S2*L%%%%24%%%%`!1110`4444`%%%%`!1110`4444`%%%%`!111
M0`G;':@<=.*6B@`_3Z4444`)_+TI?Q-%%`!^-%%%`!1]***0"8]A2_G113`*
M***`"CD=***`$Q2T44`%%%%`!1UHHH`/QHQ110`?UH^M%%`!VQVH[8[>E%%"
MT`3%+^)HHH`*.V***`$P#VI:**`"BBB@`H]J**`#%'2BB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
,B@`HHHH`****`/_9
`
end
Article: 23794Whether it is possible to reprogram MAX7000S on ByteBlaster if JTAG pin will be used for I/OArticle: 23795
In Xilinkx Appnote XAPP058 it says it requires a "Xilinx Data Memory". Is that just static RAM? Thanks EricArticle: 23796
> Oh, absolutely it would. But "it would be nice if I didn't have to do > that." I mean, I'm not sure why the tool feels the need to give the > post-BUFGLSed net a bizarre name, esp. since, for input clock pins, it names > the buffered version something obvious such as sysclk_BUFG. > > Actually, since the period constraint is applied to the pin before the > global buffer, whyizzit different for derived clocks? I wonder how you could apply some UCF constraints to the output of Synopsys FPGA Express. I think you don't have a schematic view option of the synthesis output, then you have to search the XNF or EDIF file, for example, to apply clock-domain constraint or special constraints. You have to know the signal name and if the tool generates a different name for each pass, it is overkill to deal with. Synplify has a graphical technology view, which enables us to generate UCF constraints very fast. Utku -- I feel better than James Brown.Article: 23797
Does anyone know a good source (& part number) for a 6-pin (power & ground + 4 JTAG signals) 'header' that can handle the flying leads of the Xilinx JTAG pod(s)? -- ============================== William Lenihan lenihan3weNO@SPAMearthlink.net ==============================Article: 23798
Jens Popp wrote:
> till now we run our lab (3rd & 4th semester) with the xilinx design flow
> from cadence. Unfortunately Europractice does not longer support this
> design flow.
>
> So I'm searching for a new design environment. I've tested Xilinx
> Foundation and found it quite good, but only aviable for Windows. The
> Solaris version (Alliance) hasn't the required features.
Hi Jens,
you could try FPGA Advantage from Mentor. We also dropped Cadence half
a year ago, and so far, the tools run fine. It's a package of
Renoir (Design Entry: block, FSM, flowchart, truth table editors),
Modelsim (Verilog/VHDL simulator), and
Leonardo Spectrum (FPGA/ASIC synthesis).
We are running them on Solaris.
There are some nice demo videos on the Mentor site, just have a look
at them.
A very good feature is the crossprobing between all tools. We will
use them together with the Alliance software.
There is a University package of 5 license for each tool for 10kDM.
If you're interested, i could give you the email/phone of a good
distributor.
Lars
--
Address: University of Mannheim; B6, 26; 68159 Mannheim, Germany
Tel: +(49) 621 181-2716, Fax: -2713
email: larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/
Article: 23799
Andy Peters wrote:
>
> Jens Hildebrandt wrote in message
> <39658097.32F7DDE9@e-technik.uni-rostock.de>...
> >
> >
> >Andy Peters wrote:
> >>
> >> Kai Schulze wrote in message <3964734C.D088118F@ee.nec.de>...
> >> >Hi,
> >> >
> >> >I'm working with a XILINX XC40250XV and I have following problem:
> >> >
> >> >There is an signal input port and a internal clock should be generated
> >> >from this signal.
> >> >How can I push synopsis to create the internal clock buffer for this
> >> >internal clock automatically.
> >> >Is there at all a way to say "synopsis do this".
> >>
> >> If that signal is connected to only flip-flop clocks, the tool should
> infer
> >> the proper global buffer.
> >>
> >As far as I know Synopsys, this is done only for external clock inputs
> >(i.e. inputs that drive only flip-flops or that are explicitly set to
> >pad-type "clock")
> >For internally generated clocks like the divided-by-X or multiplied-by-Y
> >or gated-by-Z input clock etc. you have to instantiate a BUFG clock
> >buffer (for XC4k) and set a dont_touch attribute to it.
> >BTW,in that case, if you use the timing constraint "clock" for that
> >signal you have to define it for the buffer output signal as the Xilinx
> >tools don't propagate such a constraint through a clock buffer.
>
> Actually, with FPGA Express v3.3, if you create a divided clock, a la:
>
> clkdiv : process (fastclk, reset) is
> begin
> if reset = 0 then
> slowclk <= '0';
> elsif rising_edge(fastclk) then
> slowclk <= not slowclk;
> end if;
> end process clkdiv;
>
> and you then use slowclk for flops only, it WILL instantiate a clock buffer
> and that buffer's output will drive your slow-clocked flops clock inputs.
> Unfortunately, the tool gives the output of that buffer a stupid name (such
> as N3012) so every time you synthesize, you have to figure out hat the new
> name of the slow clock net is and edit your P+R constraints accordingly.
<snip>
Well, seems to be one more reason to convince my Synopsys admin to
install a newer version, since with our current synopsys_1998_08 tools
no clock buffers are inferred for derived clocks. I just checked it out
with the following design:
entity clkbuftest is
port(clk: in std_logic;
reset: in std_logic;
data: in std_logic_vector(7 downto 0);
sl_dat: out std_logic_vector(7 downto 0);
fst_dat: out std_logic_vector(7 downto 0)
);
end clkbuftest;
architecture behav of clkbuftest is
SIGNAL sl_clk: std_logic;
begin
divider: process(clk, reset)
begin
if (reset = '1') then
sl_clk <= '0';
elsif (clk'event and clk = '1') then
sl_clk <= not sl_clk;
end if;
end process;
sl_ff: process(sl_clk, reset)
begin
if (reset = '1') then
sl_dat <= (others => '0');
elsif (sl_clk'event and sl_clk = '1') then
sl_dat <= data;
end if;
end process;
fst_ff: process(clk, reset)
begin
if (reset = '1') then
fst_dat <= (others => '0');
elsif (clk'event and clk = '1') then
fst_dat <= data;
end if;
end process;
end behav;
The only BUFG component inferred is that for the clk-input.
May be this is due to the older version of my Synopsys tools or are
there some extra configurations needed in the .synopsys_dc.setup file?
Jens
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