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
Thank you for the pointer. =) The DC-current consumption was that what disturbed greatly. With a quick look at Atmel's ATF1504ASVL the family looks exactly what I've been hoping for with their sophisticated power consumption handling. I made an I/O sampler that uses internal binary counter, RC-clock on digital pins to introduce keyboard-bounce delay, and stores the counter value to a readonly-SPI-module (worked for Xilinx 9572). It has access to 48 VDC/50mA power supply but it is not alone and I am trying to cut the general current consumption level down to increase thresholds. I wonder if Atmel provides hardcopy documents of their CPLD circuits. ++Matti Ruusunen Jim Granville <jim.granville@designtools.co.nz> wrote in message news:3ACE8160.F3@designtools.co.nz... > It depends a lot on your frequency, and on the technology. > All devices have a DC current, and a mA/MHz slope. > As the clock frequency increases, all logic will draw more current. > > We are studying CPLD for LCD drivers, and sub 10uA (typ) is looking > feasible, > in ATF1504ASVL series - at low freqs these draw less than coolrunner, > > So, if you are using these as IO, and not at tens of MHz, look at the > ATF15xx family. > > Also, given CMOS process nature, VERY low Idd will be easier at 3V than > 5V. > > - jg > -- > ======= 80x51 Tools & PLD IP Specialists ========= > = http://www.DesignTools.co.nzArticle: 30426
For a rough estimate go to www.nuhorizons.com
"S. Ramirez" wrote:
> Here is another reason. If you are new to this and haven't contacted
> the disties before, be prepared for a barrage of questions, phone calls,
> hiya doings, questions, phone calls, what are you working on, phone calls,
> questions, how many do you need, questions, phone calls, etc. Until they
> establish clearly what you are working on, what product you need, how many
> of each product you will order and when, and get a design registration in
> place, you will be hounded by these people.
Or they find out that you onbly wnat to spend $1000 now and try to get rid of
you.
Insight germany lied to me, and told me that they had no XC2S samples last
August.
A Xilinx Rep checked the Insight inventory, and found 24 pieces, but Insight
Germany denied.
Then Insight Norway told me about the same 24 pieces in Munich, again Insight
Germany denied.
after repaeting the above with Insight Netherlands suddenly some parts showed
up at a very annoyed
Insight Sales Person.
I only had bad experiences with distributors, but I guess that changes when
you buy a lot.
CU,
Kolja
Article: 30427FOr generating apparent randomness you are entirely correct. In the case of cryptography, it is important to keep the generating function a secret so that the PN sequence can't be easily re-created. If you use a single n bit LFSR, you can determine the polynomial with a small number (IIRC it is n+1) consecutive samples out of it. In the crypto world, you use multiple LFSRs to obfuscate the sequence, not for better apparent randomness, but to make it much more difficult to recover the generating function from the bitstream. Rick Collins wrote: > > I have never read a paper on this, but my bet would be that a > combination of LFSRs is no better than a single LFSR of length equal to > the sum of the lengths of the short LFSRs being combined. I am sure that > the length of the combined sequence would be equal to the product of the > individual lengths and this would be less than or equal to the length of > the single long LFSR sequence. > > I would be willing to bet that there is a simple way to discover the > three LFSRs in this examnple or to discover an equivalent single LFSR > polynomial given a sufficiently long output sequence. > > Ray Andraka wrote: > > > > Actually, as long as you take one bit at a time, the randomness of an LFSR is > > quite good, but the sequencer feedback polynomial as well as the current state > > can be discovered by looking at the most recent bits, which makes it lousy for a > > cryptographic application where knowing the sequence allows one to decipher the > > encypted data. Using 3 LFSRs in combination obfuscates the sequence enough to > > make discovery of the generating function much harder. If it is an encryption > > you are after, then true enough a single LFSR is not sufficient. But the problem > > stems from the ability to infer the polynomial and current state, not from the > > apparent randomness of the bits. > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com > > -- > > Rick "rickman" 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 URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 30428
XCV1000 (without the E suffix) has 32 block Rams, each is a 4Kbit dual port RAM, which you can set up as 1,2,4,8 or 16 bits wide by the corresponding depth to make 4K bits. Each port of each BRAM has its own set of address, data, clock and controls. "Host addressing RAM" has nothing to do with the chip itself, rather how you connect those RAMs to a host, if there even is one, in YOUR design. Richard Martineau wrote: > > the one I'm using has 8Mbytes divided across 4 ram banks i.e. 2Mbytes for > each bank which each start at 0x0 address using the RC1000PP functions > assuming you are using the prototyping board. however, when the host is > addressing the fpga ram it sees it as a continuous block of memory so you > have to use offsets to the start of each ram bank > > Richard > > <sam> wrote in message news:ee70229.-1@WebX.sUN8CHnE... > > does anyone have an idea about the exact amount of onchip ram in a xilinx > virtex XCV1000BG560. > > > > sam -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 30429
Matti Ruusunen wrote: > > Thank you for the pointer. =) The DC-current consumption was that what > disturbed greatly. > > With a quick look at Atmel's ATF1504ASVL the family looks exactly what I've > been hoping for with their sophisticated power consumption handling. I made > an I/O sampler that uses internal binary counter, RC-clock on digital pins > to introduce keyboard-bounce delay, and stores the counter value to a > readonly-SPI-module (worked for Xilinx 9572). It has access to 48 VDC/50mA > power supply but it is not alone and I am trying to cut the general current > consumption level down to increase thresholds. Another tip: For clock generators, at low frequencies we found the HEF4541 the best with a low ~2.1V startup voltage. It draws under 10uA with a 32Khz Xtal, and is available in a small SO14 package, at appx 21c/1K. > > I wonder if Atmel provides hardcopy documents of their CPLD circuits. Yes. -jgArticle: 30430
Dave Vanden Bout wrote: > > Helen Long wrote: > > > I just used DATAIN(23 downto 0) > > however in schematic we only have IPAD(16) & IPAD(8) > > I don't know how to combine them together > > Thanks a lot! > > I don't know what schematic editor you are using, but here is how to do > it with the editor in Xilinx Foundation: > > 1) Attach a bus to an instance of IPAD16 and name it DATAIN[15..0]. > 2) Attach another bus to an instance of IPAD8 and name it DATAIN[7..0]. I think this isn't exactly what Helen is looking for. In the case she needs a 24-bit wide bus, the bus connected to IPAD16 should read DATAIN[23..8]. > > -- > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 30431
Does anyone what the future will be like for Verilog and VHDL ? Wil it be replaced by C/C++ platform ? It looks like Handel C is taking oof. What I am wondering is will DK-1 suite be able to convert the test benches into a supported language as well ? For ASIC conversion, that is.. http://www.infoconomy.com/pages/search/group18585.adp http://isdmag.com/story/OEG20010301S0056 http://www.celoxica.com/news/in_the_news.htmArticle: 30432
I mean, will Verilog and VHDL experts become devalued in the future ? "Compilit" <compilehr@yahoo.com> wrote in message news:9aoga1$qt8$1@taliesin.netcom.net.uk... > Does anyone what the future will be like for Verilog and VHDL ? > > Wil it be replaced by C/C++ platform ? > > It looks like Handel C is taking oof. > > What I am wondering is will DK-1 suite be able to convert the test benches > into a supported > language as well ? For ASIC conversion, that is.. > > http://www.infoconomy.com/pages/search/group18585.adp > > http://isdmag.com/story/OEG20010301S0056 > > http://www.celoxica.com/news/in_the_news.htm > >Article: 30433
I personally think that HDLs will evolve to C eventually, but the real
problem is that HDL is only a part of FPGA design. Just ask anyone in this
newsgroup about all of the problems involved with FPGA design. The majority
of them are not HDL problems. Therefore, one cannot take a programmer
(read: non hardware engineer), teach him/her Handel-C and expect him/her to
simply start cranking out FPGA designs. That person will have to know about
timing problems, metastability, floorplanning and a bunch of other skills
that are commonly required to complete an FPGA design. Essentially, that
person has to be a hardware person.
The first link given below is to an article about Celoxica. It's
obvious that this article was written by a semi-technical person, since
(s)he refers to VHDL as "Verilog HDL." The article to me reads simply as
marketing hype for this new language and tools. I am not saying that they
will not take off, but I doubt that they will unless they can get a
significant amount of us to go that way. I wish the company well, and I am
always looking for new, better and cheaper tools, but my present design flow
and methodology is sufficing quite well.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
"Compilit" <compilehr@yahoo.com> wrote in message
news:9aoga1$qt8$1@taliesin.netcom.net.uk...
> Does anyone what the future will be like for Verilog and VHDL ?
>
> Wil it be replaced by C/C++ platform ?
>
> It looks like Handel C is taking oof.
>
> What I am wondering is will DK-1 suite be able to convert the test benches
> into a supported
> language as well ? For ASIC conversion, that is..
>
> http://www.infoconomy.com/pages/search/group18585.adp
>
> http://isdmag.com/story/OEG20010301S0056
>
> http://www.celoxica.com/news/in_the_news.htm
>
>
>
Article: 30434I don't need Cohen's book for the moment. But still need the 3 books listed below. Got everything else. Will consider computer Arithmetic books. May be I should take some cash offer :-) > "Compilit" <compilehr@yahoo.com> wrote in message > news:99u33j$f7l$1@taliesin.netcom.net.uk... > > I have some EE books for trade. I am in the San Francisco Area. > > > > These all are all in brand new, unnused condition. Some have CD-ROM's > > included that are not yet opened. > > I bought them for a project now currently on hold. > > > > Please search www.abebooks.com or www.powells.com or www.Amazon.com for > good > > deals on these, and get back to me. Please help me to get the books I > need. > > > > The following list are what I currently have extra to be given away: > > > > 1/ Designer's Guide to VHDL by Peter Ashenden > > > http://www.amazon.com/exec/obidos/ASIN/1558602704/qid=985827963/sr=1-3/ref=s > > c_b_4/002-1116465-7214451 > > 2/ VHDL Analysis and Modeling of Digital systems 2ed by Navabi > > > > 3/ Computer Architechiture, and Quantitative Approach. > > > > 4/ Verilog Digital Computer Design. Algorithms into Hardware by Arnold > > > > 5/ Real World FPGA Design with Verilog by Ken Coffman > > > > 6/ VHDL Representation and Synthesis by Armstrong and Gary > > > > 7/ VHDL made easy by Tellering and Taylor > > > > 8/ Verilog HDL by Palnitkar > > > > 9/ Verilog Designer's Library by Zeidman > > > > 10/ Timing Verification (ASIC) by Farzd Nekoogar > > > http://www.amazon.com/exec/obidos/ASIN/0137943482/ref=sim_books/002-1116465- > > 7214451 > > > > 11/ VHDL by Douglas Perry > > > > 12/ VHDL for programmable logic by Kevin Skahill > > > > 13/ Real Time Signal Processing John G. Ackenhusen > > > http://www.amazon.com/exec/obidos/ASIN/0136317715/qid=985827868/sr=1-2/ref=s > > c_b_3/002-1116465-7214451 > > > > 14/ Object Oriented Perl by Conway > > > > 15/ Programming and Customizing PIC controller Predro > > > > 16/ PCI-X System Architecture Mindshare INC > > > > 17/ Application-Specific Integrated Circuits. By Smith > > > > 18/ VHDL for Logic Synthesis by Andrew Rushton > > http://www.amazon.com/exec/obidos/search-handle-form/002-1116465-7214451 > > > > ===================================================================== > > > > > > The following are what I am in desparate need for, I don't mind them in > used > > conditions: > > > > > > > 2/ System-on-a-Chip Verification - Methodology and Techniques > > > http://www.amazon.com/exec/obidos/ASIN/0792372794/qid=985827145/sr=1-4/ref=s > > c_b_5/002-1116465-7214451 > >> > > > 6/PRINCIPLES OF VERILOG PLI > > by Swapnajit Mittra > > http://www.powells.com/cgi-bin/biblio?inkey=4-0792384776-0 > > > > 7/VHDL Coding and Logic Synthesis with Synopsys by Weng Fook Lee > > > http://www.amazon.com/exec/obidos/ASIN/0124406513/qid=985827963/sr=1-6/ref=s > > c_b_7/002-1116465-7214451 > > > > Thank you, > > Peace. > > > > Please click reply to email me. > > > > > >Article: 30435
HDL is not only a part of FPGA design but also a kind of blueprint for all chip design using digital and analog logic. HDL was devised to describe a hardware system effectively. HDL itself is not concerned about timing, metastability and floorplaning of FPGA/ASIC/Full Custom/Semi-Custom design. Thesedays it seems that folks think writing HDL as writing software codes thanks to synthesis tools. However, HDL is not a piece of software code like C/C++ but a truly dedicated language describing hardware. Chung, MA S. Ramirez <sramirez@cfl.rr.com>ÀÌ(°¡) <K0Qz6.55451$Lz6.8753675@typhoon.tampabay.rr.com> ±â»ç¿¡¼ ÀÛ¼ºÇß½À´Ï´Ù... > I personally think that HDLs will evolve to C eventually, but the real > problem is that HDL is only a part of FPGA design. Just ask anyone in this > newsgroup about all of the problems involved with FPGA design. The majority > of them are not HDL problems. Therefore, one cannot take a programmer > (read: non hardware engineer), teach him/her Handel-C and expect him/her to > simply start cranking out FPGA designs. That person will have to know about > timing problems, metastability, floorplanning and a bunch of other skills > that are commonly required to complete an FPGA design. Essentially, that > person has to be a hardware person.Article: 30436
"S. Ramirez" wrote: > I personally think that HDLs will evolve to C eventually, but the real > problem is that HDL is only a part of FPGA design. Just ask anyone in this > newsgroup about all of the problems involved with FPGA design. The majority > of them are not HDL problems. Therefore, one cannot take a programmer > (read: non hardware engineer), teach him/her Handel-C and expect him/her to > simply start cranking out FPGA designs. That person will have to know about > timing problems, metastability, floorplanning and a bunch of other skills > that are commonly required to complete an FPGA design. Essentially, that > person has to be a hardware person. > The first link given below is to an article about Celoxica. It's > obvious that this article was written by a semi-technical person, since > (s)he refers to VHDL as "Verilog HDL." The article to me reads simply as > marketing hype for this new language and tools. I am not saying that they > will not take off, but I doubt that they will unless they can get a > significant amount of us to go that way. I wish the company well, and I am > always looking for new, better and cheaper tools, but my present design flow > and methodology is sufficing quite well. > Simon Ramirez, Consultant > Synchronous Design, Inc. > Oviedo, FL USA I would agree & I would go further even than Simon. Although looking at Handel-C itself it seems that it would do the job it seems that the marketing strategy of these C-based HDL tools companies has very little to do with the technicalities. They are mostly trying to talk to managers and saying: ``Hey guys here are some tools that will allow you to throw away all those expensive, rare h/w types & replace them with off-the-shelf el-cheapo s/w grunts'' The sad thing is my experience of most management types says they will buy it - its what MBA training is all about. Remember these are the same people for who marketing target with their whizzo GUIs [what other purpose do all those screen shots on the Web serve ?]. What I actually don't understand is why the C-based tools are needed ? Verilog is so easy to write that at the pure coding level any reasonably competent C/C++ programmer could pick it up in a couple of days. Then with a couple of years practice they might, if they have the right mentality (*), get to produce h/w that's not an embarrasment to their company. (*) This is not just to do with timing, metastability, etc. My fear here is that s/w types do not have the deep, ingrained, awareness that from day 1, hour 1, minute 1 of design start any mistake they make could be fatal. s/w bug = fix it & put a patch file on the Web, h/w bug = a $250K+ ASIC respin.Article: 30437
Richard Martineau wrote: > hello everybody > > does anyone have a spare minute to tell me where I can get a price list for > Xilinx Spartan 2 range? > > Richard Go to http://www.em.avnet.com and do a search for parts starting with "XC2S". You will get prices for all Spartan2 speed grades and packages. You don't get any large-volume pricing and the small quantity pricing is a few bucks more than what you will get from your distributor, but it will give you an idead of what you will have to pay and the relative prices of various options. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 30438
Thomas Heidel wrote: > Dave Vanden Bout wrote: > > > > Helen Long wrote: > > > > > I just used DATAIN(23 downto 0) > > > however in schematic we only have IPAD(16) & IPAD(8) > > > I don't know how to combine them together > > > Thanks a lot! > > > > I don't know what schematic editor you are using, but here is how to do > > it with the editor in Xilinx Foundation: > > > > 1) Attach a bus to an instance of IPAD16 and name it DATAIN[15..0]. > > 2) Attach another bus to an instance of IPAD8 and name it DATAIN[7..0]. > > I think this isn't exactly what Helen is looking for. > In the case she needs a 24-bit wide bus, the bus connected to IPAD16 > should read DATAIN[23..8]. Yes, you are right. > > > > > > -- > > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 30439
some lines below deleted, sorry if I mis-snipped.... Rick Filipkiewicz <rick@algor.co.uk> wrote...... > "S. Ramirez" wrote: > > I personally think that HDLs will evolve to C eventually, Saying HDLs will evolve to C is like saying humans will evolve to monkeys. >> but the real problem is that HDL is only a part of FPGA design> >> They are mostly trying to talk to managers and saying: > ``Hey guys here are some tools that will allow you to throw away all those > expensive, rare h/w types & replace them with off-the-shelf el-cheapo s/w > grunts'' > > The sad thing is my experience of most management types says they will buy it - > its what MBA training is all about. Remember these are the same people for who > marketing target with their whizzo GUIs [what other purpose do all those screen > shots on the Web serve ?]. > > What I actually don't understand is why the C-based tools are needed ? Verilog > is so easy to write that at the pure coding level any reasonably competent C/C++ > programmer could pick it up in a couple of days. Then with a couple of years > practice they might, if they have the right mentality (*), get to produce h/w > that's not an embarrasment to their company. > > (*) This is not just to do with timing, metastability, etc. My fear here is that > s/w types do not have the deep, ingrained, awareness that from day 1, hour 1, > minute 1 of design start any mistake they make could be fatal. s/w bug = fix it > & put a patch file on the Web, h/w bug = a $250K+ ASIC respin. > I think that if C alone were enough for hardware design, it would have been used instead of Verilog or VHDL. As it turns out, the programmer's model is quite different for one case compared to the other. For C, as with other system programming languages, the focus is on algorithms and data structures used in the one-instruction at a time sequential flow. To support hardware modeling, it was necessary to extend C to allow the programmer to model the passage of time and the execution of statements in concurrent processes. Not that such a thing couldn't be done in C (Verilog is sometimes referred to as "C+-" ;-) , but the C extensions need to be done in a "standard" way, to encourage the support of third-party vendors (cell libraries, verification, synthesis...) Maybe someday we'll have a set of standard libraries that extend some other language to replace Verilog or VHDL. When that happens, we'll still need "domain experts" , i.e., digital hardware savvy types who can use the language to perform the modeling and analysis for which it is intended. There has never been and probably never will be a threat to employment security for hardware types from those who are merely programmers, anymore than physicians are threatened by others who happen to speak English or who have read about medicine in a book somewhere.Article: 30440
I totally agree with you. HDL is for hardware modelling. It is 100% different from what software guys think in C prgramming. It is not that different from schematic drawing of hardware components. If you don't have a good idea about what hardware should be, you can't be a good HDL designer. (designer! not programmer...)Article: 30441
Here's an idea for a C programmer who wants to help out in hardware design. Learn about the PLI. Write some code that helps hw people analyze and report on simulation activity. With the PLI, your C code can be referenced from a simulation as a library object. With some simulators, the library is linked dynamically, so it's not even necessary to rebuild the simulator to take advantage of the nifty new widget you've created for the hardware design and verification community. Even better yet, with the emerging Superlog language, you can inline your C code in Verilog. Who knows, in a a few years, we may be able to inline x86 asm in Verilog.Article: 30442
Ray Andraka <ray@andraka.com> wrote..... > They may be teh wave of the future, always has been, and always will be ;-) Reminds me of so many other "waves of the future" that fail to deliver or become a significant part of mainstream technology, but still manage to hang on with occasional references in EETimes or some other tech pub. Things like Rambus, AI, "expert systems", push technology, JAVA, etc., etc. Of course, it's not the kind of thing you should joke about with anyone who has a vested interest at stake.... Still, I'm amazed at the time and money invested by so many people in so many obviously un-needed product and/or technology ideas. It sometimes seems as though engineering is devolving into an arena of artist-types striving for style-du-jour distinction instead of the old-fashioned community effort with exploration, discovery, and shared skill development that characterized the chip business during the first few decades.Article: 30443
On Sat, 7 Apr 2001 18:46:03 -0700, "Compilit" <compilehr@yahoo.com> wrote: >Does anyone what the future will be like for Verilog and VHDL ? > >Wil it be replaced by C/C++ platform ? > >It looks like Handel C is taking oof. > >What I am wondering is will DK-1 suite be able to convert the test benches >into a supported >language as well ? For ASIC conversion, that is.. > >http://www.infoconomy.com/pages/search/group18585.adp > >http://isdmag.com/story/OEG20010301S0056 > >http://www.celoxica.com/news/in_the_news.htm > These articles make it clear that Celoxica would like Handel-C to take off. Whether it will is another matter. Years ago, I used C (and FORTRAN--remember that?) to do cycle-based simulations of hardware, but gave that up when capable HDLs came along. I'm not saying that C will never evolve in such a way as to supplant current HDLs, but I'm skeptical. If Celoxica and similar companies convince managers that their software people can use a C-like language to design FPGAs, that's tantamount to declaring a guaranteed employment act for FPGA consultants; we'll be cleaning up the mess for years. Bob PerlmanArticle: 30444
Dean, some comments... > I then use the Xilinx Design Manager to generate a bitstream for this > device. > All appears to go well up to here. Did you watch to set the configuration clock to JTAG clock. After the configuration stream is sent, the spartan needs some more clocks to enable IO, disable GTS, release GSR, release DONE, and so on... You have to specify to bitgen which clock to use for this sequence. > > I enter the JTAG programmer. Connect to the cable and initialise the > chain. > The device is detected as being a Virtex XCV100. > I assign the bitstream file I have created to the device. (which is > targeted to an XC2S100_PQ208) > I can get the ID number and the signature/usercode number from the > device. It's perfectly normal the spartan is detected as a virtex device... they all do. > > 'cpu_wrapper(Device1)': Checking boundary-scan chain integrity...done. > 'cpu_wrapper(Device1)': Reading bit-stream file...done. > 'cpu_wrapper(Device1)': Programming device.....done. > 'cpu_wrapper(Device1)': If the security flag is turned on in the > bitstream, > programming status can not be confirmed; otherwise, > programming terminated due to error. > Don't expect to much of JTAG-programmer's error messages.. They point to the wrong error most of the time... hope this helps a bit... JanArticle: 30445
Is there an alternative to Xilink Foundation schematic editor?
I am using a 4000E board with the Xilink Software in my university, but
I need to do some things in home. Can't I use another editor to build my
circuits and then use them with Xilink Software?
Thank you.
Article: 30446>If your FPGA is the PCI Interface, you have no choice than configuring the FPGA >without PC CPU interaction, for example from a FLASHROM that is controled by a >CPLD or small embedded CPU or from one of these expensive configuration PROMs. I mostly agree, but you can cheat if you are debugging (or just have a hacker mentality). Suppose you power up your machine. The FPGA on your PCI card hasn't been configured so your BIOS won't find it when it scans for devices. This assumes you are using a machine with a typical BIOS. Now load your FPGA, say over USB or the printer port. The card is now alive, but the BIOS didn't assign it any addresses so you can't really use it. If you reset your machine (without powering it off) the BIOS will run again and find your card and assign it address space. If you are using a stand alone system, you can assign the addresses yourself. Or if you are writing the BIOS you could add a hook for this case. ... -- These are my opinions, not necessarily my employeers. I hate spam.Article: 30447
Thanks for the comments Jan. I did not have the configuration clock set to JTAG clock. I have done this but it still does exactly the same thing. Is it possible that the order in which the startup stuff is done could affect things? This is quite frustrating. I thought that JTAG programming was supposed to be fairly foolproof. Cheers, Dean Jan Kindt wrote: > Dean, > > some comments... > > > I then use the Xilinx Design Manager to generate a bitstream for this > > device. > > All appears to go well up to here. > > Did you watch to set the configuration clock to JTAG clock. After the > configuration stream is sent, the spartan needs some more clocks to enable > IO, disable GTS, release GSR, release DONE, and so on... You have to specify > to bitgen which clock to use for this sequence. > > > > > I enter the JTAG programmer. Connect to the cable and initialise the > > chain. > > The device is detected as being a Virtex XCV100. > > I assign the bitstream file I have created to the device. (which is > > targeted to an XC2S100_PQ208) > > I can get the ID number and the signature/usercode number from the > > device. > > It's perfectly normal the spartan is detected as a virtex device... they all > do. > > > > > 'cpu_wrapper(Device1)': Checking boundary-scan chain integrity...done. > > 'cpu_wrapper(Device1)': Reading bit-stream file...done. > > 'cpu_wrapper(Device1)': Programming device.....done. > > 'cpu_wrapper(Device1)': If the security flag is turned on in the > > bitstream, > > programming status can not be confirmed; otherwise, > > programming terminated due to error. > > > > Don't expect to much of JTAG-programmer's error messages.. They point to the > wrong error most of the time... > > hope this helps a bit... > > JanArticle: 30448
All your comments are very true - However as a hardware engineer with a large amout of software experiance I feel that a very important point is being missed. VHDL is like programing in assembly language but with some very nice added funtions - you realy do need to undatand the target you are writing for! however 'C' started to change that - a function written for an x86 could be complied for a 6800! What I'm getting at is that there are a lot of out of work C programmers that with some experance of Handel-C are going to cross the border. Not to become hard core hardware enginees but will fill the joinior engineer posts and alike - from there is the opertunity for them to learn new skills and move up the ladder. I see the coming of Handel-C as a was of getting more hardware engineers and lowing the amount of unemployed Softy's. However the problem is that there will be many more people leaving Uni with these skills that don't understand the lower functions of hardware just as is already happening in software - I used to work with a chap that was a very good C programmer that had no idear what a register or a ALU was !? A product of Uni mass production!? And can I also point out that most hardware engineers work with Sotware engineers (or should be) to get the best results. Lets not have a them and us point of view! sometims a different approch is what is needed! At the end of the day if you are good at what you do - why worry - its the hardware chaps that have been blagging there boss for years that are in danger! Cyber_Spook niki wrote: > I totally agree with you. HDL is for hardware modelling. It is 100% > different from what software guys think in C prgramming. It is not that > different from schematic drawing of hardware components. If you don't have > a good idea about what hardware should be, you can't be a good HDL > designer. (designer! not programmer...)Article: 30449
Robert Carney wrote: > Ray Andraka <ray@andraka.com> wrote..... > > They may be teh wave of the future, > > always has been, and always will be ;-) > > Reminds me of so many other "waves of the future" > that fail to deliver or become a significant part of > mainstream technology, but still manage to hang on > with occasional references in EETimes or some > other tech pub. Things like Rambus, AI, "expert > systems", push technology, JAVA, etc., etc. Of > course, it's not the kind of thing you should joke > about with anyone who has a vested interest at > stake.... Still, I'm amazed at the time and money > invested by so many people in so many obviously > un-needed product and/or technology ideas. It > sometimes seems as though engineering is devolving > into an arena of artist-types striving for style-du-jour > distinction instead of the old-fashioned community > effort with exploration, discovery, and shared skill > development that characterized the chip business > during the first few decades. You missed my all-time favourite one of these ``The paper-less office''.
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