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
Thanks for the Link! I found there VHDL-Listing's for Block codes. Unfortunatly isn't it exactly what I'm looking for. What I'm going to build is an encoder/decoder for a convolutional Code. So I'm still grateful for further information. Edwin Naroska schrieb: > > You may take a look at the following link: > > Viterbi encoder/decoder for the (22,8,6) block code: > http://www-ee.eng.hawaii.edu/~pramod/ee628/viterbi.html > > -- > EdwinArticle: 20476
I am a xilinx user and am having problems in the mapping stage(the second one) of implementation. actually i dunno where to keep my "map.exe" file. the problem actually surfaces in the third stage of the implementation i.e. routing. if i could somehow figure out where is Xilinx looking for the map.exe file i could do the needful. the error message is: "ERROR:baspw:110 - Cannot find Input file "map.ncd". Please verify that your paths and permissions are properly set for this file." if any1 has some helpful advice, i will be grateful to the same. even if u don't have anything to offer, i thank u nonetheless for having the patience to read out my problem. * Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping. Smart is BeautifulArticle: 20477
Hi Folks I'd like to load the Boundary_Scan Identification_Register of my XCS40 into a internal Register of my Spartan itself. Does anyone know how I can do this during startup? I don't want to set up a whole JTAG interface. thanks ffArticle: 20478
Try the ARC: http://www.arccores.com/ JohnArticle: 20479
Which version of s/w are you running. From what you describe it sounds to me that you are running script mode, and need to verify that your %Xilinx% environment and path is correctly set Just type 'set' at the prompt to find out. Map should be in the %xilinx%/bin/nt directory, and produces a map.ncd file for PAR. Check the script is not calling it something else... Hope this helps, if not then open a case with the Xilinx holtine (hotline@xilinx.com) Regards, Dave Hawke Xilinx UK. Manan wrote in message <03000ec8.68ccfe94@usw-ex0108-061.remarq.com>... >I am a xilinx user and am having problems in the mapping >stage(the second one) of implementation. actually i dunno >where to keep my "map.exe" file. the problem actually >surfaces in the third stage of the implementation i.e. >routing. if i could somehow figure out where is Xilinx >looking for the map.exe file i could do the needful. > >the error message is: > >"ERROR:baspw:110 - Cannot find Input file "map.ncd". Please >verify that your > paths and permissions are properly set for this file." > >if any1 has some helpful advice, i will be grateful to the >same. >even if u don't have anything to offer, i thank u >nonetheless for having the patience to read out my problem. > > >* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping. Smart is BeautifulArticle: 20480
Hi Pradeep, In line 8 use: compute:process(xin1,xin2) instead of: compute:process(xin1,xin2) is and you should be OK. CatalinArticle: 20481
Hi Bjorn, You cannot assign values to the same signal (KLAR) in two different processes (COUNT_machine and FEMTON_machine). It is like connecting together the outputs of two flip-flops. CatalinArticle: 20482
Tom, To add a very short conclusion to the very good description made by Rick and to directly answer your questions: 1) Yes, the DONE pins of all dasy-chained FPGAs must be connected together. If you do not do that, once one FPGA is configured and its own DONE pin goes high, its DOUT pin (connected to the DIN pin of the next FPGA) becomes a general purpose I/O and no bitstream will come out of it - all FPGAs downstream will not configure 2) Yes again, all INIT pins must be connected together. All FPGAs go trough an initialisation phase (INIT low) and the master must wait for all slaves to release INIT before starting the configuration. INIT is bidirectional for this reason. Also holding INIT low during power on or PRGM low puts the FPGA in JTAG configuration mode If all slaves are identical you can consider connecting them in parallel to the master - this will substantially reduce your configuration time (and the size of your PROM). You still have to tie together all DONE and INIT pins Catalin Rickman wrote: > Tom McLaughlin wrote: > > > > All, > > I've read the Xilinx docs until I can't stand it anymore. From my > > interpretation, they contradict themselves.....please help. We are > > building a prototype system that is a chasis system with 17 boards. We > > want to put a board in the system that holds the PROMs for the FPGAs as > > there are several boards that are the same and we don't want to have to > > put PROMS on the identicle boards. One board in a set will define the > > FPGA on that board as the master and the rest will be slave. We are > > planning to use the 1800 series proms from Xilinx. We believe that > > CCLK, DONE, INIT, DATA, and PROGRAM have to be connected between the > > master FPGA and the PROM. Okay, program only if we are going to use it, > > but we are. We know that CCLK and DATA have to go to the slaves, but: > > > > 1) Does DONE of the slaves have to be connected? > > 2) Does INIT of the slaves have to be connected? > > > > In one diagram, INIT is connected to all of the devices connected and in > > another only the master. > > > > I think we can just put pullups on the DONE signals of the slaves??? > > > > Can someone explain why INIT is a bidirectional signal??? > > > > Thanks for the help...anyone done this before??? > > > > TomArticle: 20483
Hello, I am simulating a chip using an IKOS hardware accelerator. I have two IKOS boards, each with a capacity of 512K primitives. Without the backannotation, the chip maps itself on these two boards, but with the backannotation, some primitives are missing. This is because nets delays consume some primitives. So I am looking for a script able to process a sdf file in order to merge the nets delays on the receiving cell delays. I know this is not clean for spike processing because the propagation mode on net is transport and the propagation mode on cell is inertial, but it is better than nothing. Regards Jean-Marc AllardArticle: 20484
Hi Mark, Hi Rick, Another often ignored problem with the global async reset is that not only can your flip-flops start at different clock edges (very bad for finite state machines) but they can also go metastable if reset is really asynchronous to clock. A metastable flip-flop connected to more than one other flip-flop can have different values in different places at the same time (even worse for FSMs). This problem is also cured by the suggestions Rick made. One other often used solution is to pass the asynchronous reset signal trough at least two flip-flops (making it synchronous and solving the metastable recovery problem at the same time) and using this signal to synchronously start the critical flip-flops in your design. The asynchrous reset can then be safely connected to GSR and reset all flip-flops. This is very similar to Rick's microcontroller solution except you do not need a microcontroller. In all cases making sure that control signals are in their inactive state during reset is always a very good idea. Catalin Rickman wrote: > Mark Luscombe wrote: > > > > Hi, > > > > I am trying to work out a satifactory method for resetting a > > synchronously design Virtex running at 74MHz. > > > > Now, the reset signal needs to be synchronised with the 74MHz clock > > and the propagation delay from this to the CLB and IOB DFFs needs to > > be less than 13ns to ensure that all registers within the device at > > reset on the sam clock edge. > > > > Xilinx seem to have been telling people not to use the GSR net, as it > > is too slow, but it does seem a pity not to use it, and use extra > > routing and CLB inputs for a global reset. > > > > It seems as though the STARTUP_VIRTEX component can accept a USER_CLK > > input, i.e. the 74MHz, so is this a good solution ? > > Also, this component has a GSR input for an external reset signal, > > does anybody know if this is also synchronised with the USER_CLK input > > ? > > The device is configured in 8-bit parallel with CCLK which is related > > to the 74MHz. > > > > What have other designers done in this situation. > > > > Cheers, Mark. >Article: 20485
Hi Teik-Ming, There is nothing to stop you defining your own "rol" function if you are missing a certain flavor. You can call it "rol" to overload the existing operator or give it a different name. Catalin Alan Fitch wrote: > In article ?Pine.OSF.3.95.1000210225125.25643A-100000@plato.ucs.mun.ca?, > TeikMing Goh ?ming@morgan.ucs.mun.ca? writes > ?Hi All, > ? > ?Can someone tell me what library I should use in order to use ROL > ?operation(rotate left)? I used LIBRARY IEEE, use ieee.std_logic_1164.all > ?and use ieee.std_logic_arith.all, but I got syntax error on that. > ?Thank you > ? > ?Regards > ?Teik-MingArticle: 20486
How would I go about programming 2 xilinx fpga's on a single board? Would I need 2 separate EEPROM chips(ATMEl) or just one? How would I go about doing it with a microprocessor 8051 or 860? What would I need to do this? Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20487
Excellent description.....I wish you would write an app note on this.....yeah, I've seen the Xilinx app notes, but they are a bit criptic...at least for me anyway. Perhaps I didn't describe our design clearly as the responses seemed to assume we were daisy chaining the FPGAs together. We are not....at least by my definition of daisy chaining. For example, on the PROM board we will have a PROM that contains a bitstream for the XBAR FPGA only. There are 9 XBAR FPGAs all on different boards. So, we want to program these in parallel with one being the master and the other 8 being slaves. If I understand the posts correctly, INIT and DONE do need to be connected on the slaves as well as the master. We will do this same thing with several other FPGAs and are trying to figure out how many signals will be traveling down the backplane. If we could get away with not sending INIT and DONE to the slaves, it would be best, but I guess not. We are hoping to use the 1800 series proms from Xilinx, use the JTAG interface to program the PROMs and kick off the config cycle. This way we don't have to socket the PROMs and don't have to pull the boards out when changing the bitstreams. Is this nuts or what....probably we should socket the PROMs just in case. Any more thoughts??? Thanks again, TomArticle: 20488
Tom Burgess wrote in message <38A35E12.DE1CC4F8@hia.nrc.ca>...
>The newer parts are amazing all right. Even a slow XLA should give
>12.5 - (1.5 Tcko + 1.5? route + 3.0 Tgls + 0.7 Tecck) = 5.8 ns margin.
>If we were talking about ye olde 4000 series of 5+ years ago, then "worry"
>might have been the right word.
Well, the part I'm using is a Spartan XL-4. I've decided to not worry about
it!
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 20489
Peter Alfke wrote in message <38A33051.7E751035@xilinx.com>...
>
>
>Tom Burgess wrote:
>
>> <snip>. This also applies to Peter's suggestion of distributing a 40 MHz
CE,
>> in which case you have to worry about meeting CE setup times back in the
80 MHz domain.
>> It looks like derived clocks will be much easier to deal with in the
Virtex/Spartan 2 family.
>>
>
>I made the assumption that meeting the 80 MHz set-up time with a global net
( plus divider delay)
>would be no problem.
>One gets spoiled with the newer parts, like Virtex-E:
>clock-to-Q = 1ns, Tilo = 0.5 ns, Tsu = 1 ns,
>plus of course routing which is also very fast.
>100 MHz designs are not difficult anymore.
>
>And the DLL lets you divide the clock without intoducing any delay between
the two clock domains.
>Neat stuff !
Peter,
Had the Spartan-II been available six months ago when I started down this
route, I would've chosen it! OK, you just have to add that other voltage
regulator. That would make three power supplies on the board!
Actually, the reason I did the divide-by-two clock in the first place was
because I put a 32-deep by 16-wide FIFO in the part, and the CORE datasheet
told me that the FIFO wouldn't run at 80 MHz. And I thought about it some
more, and realized that most of the design didn't need to run at 80 MHz.
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 20490
elynum@my-deja.com wrote in message <881ajg$c3l$1@nnrp1.deja.com>...
>How would I go about programming 2 xilinx fpga's on a single board?
>Would I need 2 separate EEPROM chips(ATMEl) or just one? How would
>I go about doing it with a microprocessor 8051 or 860? What would I
>need to do this?
the Xilinx manuals have a fairly-decent explanation of how to configure more
than one device.
With a serial PROM, one of your devices is the "master," the other is the
"slave." The configuration pins for each device need to be set
appropriately. Connect CCLK on the master to CCLK on the slave and the
PROM's clock pin. The master will source CCLK and accept the PROM's data on
its DIN pin. The master will shift the data out its DOUT pin, so you should
connect the master DOUT to the slave DIN. DONEs get tied together and
pulled up.
If you want to configure from a CPU, you'd use the slave parallel mode for
the first chip and slave serial for the second. Again, see the manual for
the exact interconnects.
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 20491On Fri, 11 Feb 2000 15:41:36 GMT, elynum@my-deja.com wrote: >How would I go about programming 2 xilinx fpga's on a single board? >Would I need 2 separate EEPROM chips(ATMEl) or just one? How would >I go about doing it with a microprocessor 8051 or 860? What would I >need to do this? > > >Sent via Deja.com http://www.deja.com/ >Before you buy. It depends on your needs; there are lots of ways to do it. If your fpgas are small, you can use one sufficiently large serial (EE)PROM; the first fpga in series with the other(s) will pass on the data after it has taken its configuration information. I've done this in the past where I had ~10 fpgas on one board. (I had to have several PROMs, but the whole deal was daisy-chained.) I haven't used the parallel mode, but I'm sure Xilinx has an application note on their web site to cover programming via microprocessor. JasonArticle: 20492
Thanks, guys! What would the benefits be to using a serial eeprom over an microprocessor or vice versa to program the fpgas? Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20493
Thanks, guys! What would the benefits be to using a serial eeprom over an microprocessor or vice versa to program the fpgas? In article <38a4455e.1374478796@cnn.exu.ericsson.se>, Jason.Wright@ericsson. (Jason T. Wright) wrote: > On Fri, 11 Feb 2000 15:41:36 GMT, elynum@my-deja.com wrote: > > >How would I go about programming 2 xilinx fpga's on a single board? > >Would I need 2 separate EEPROM chips(ATMEl) or just one? How would > >I go about doing it with a microprocessor 8051 or 860? What would I > >need to do this? > > > > > >Sent via Deja.com http://www.deja.com/ > >Before you buy. > > It depends on your needs; there are lots of ways to do it. If your fpgas > are small, you can use one sufficiently large serial (EE)PROM; the first > fpga in series with the other(s) will pass on the data after it has taken > its configuration information. I've done this in the past where I had ~10 > fpgas on one board. (I had to have several PROMs, but the whole deal was > daisy-chained.) > > I haven't used the parallel mode, but I'm sure Xilinx has an application > note on their web site to cover programming via microprocessor. > > Jason > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20494
Hi, "Geoffrey G. Rochat" <geoff@pkworks.com> schrieb im Newsbeitrag news:8806th$eaa$1@news.kersur.net... ... > I tried an early Verilog/VHDL compiler for Max+Plus II from > Altera several years ago, but at the time it was Not Yet Ready For > Production. Things may have changed, but I've not checked. We are using the VHDL Entry of Max+PLUSII for our designs and are already producing. ALTERA's support for VHDL has been extended, but their support of the VHDL standard has lacks. Some contructs are not usable, so you have to programm sometimes a workaround. My latest information is, that ALTERA is doing some renew of their VHDL tool with better implementation of the IEEE standards. Greetings from Germany, CarlhermannArticle: 20495
Hi Tom, If I understand well your problem all your FPGAs reequire the same bitstream. In this case you do not have to daisychain them. The FPGA with PROM should be in master serial mode, all others in slave serial mode. Connect all FPGA INIT pins together and to the reset pin of XC1800 (add a 4.7K pullup resistor). All PRGM pins should be tied together (probably to your board master reset). All slave FPGA CCLK pins and the serial PROM CCLK pin should be tied to the master FPGA CCLK pin. All FPGA DIN pins (including the master) should be connected to the serial PROM DOUT pin. The master FPGA DONE pin should be connected to the serial PROM CE (and another 4.7K pullup resistor). In this case you do not have to tie all DONE pins together - if you connect an LED and a current limiting resistor to VCC for each DONE pin you will have an indicator of successful configuration for each FPGA. You need then only four signals between boards (PRGM, DONE, CCLK and DIN). The only drawback of this solution is that after configuration DIN and INIT pins become general purpose I/Os that have limited use because they are connected between all FPGAs. This is an unorthodox way to configure multiple identical FPGAs from a singel serial PROM and is not described in the Xilinx DataBook. You do not need (or want) a socket for the serial PROM. Regards, Catalin Tom McLaughlin wrote: > Excellent description.....I wish you would write an app note on > this.....yeah, I've seen the Xilinx app notes, but they are a bit > criptic...at least for me anyway. > > Perhaps I didn't describe our design clearly as the responses seemed to > assume we were daisy chaining the FPGAs together. We are not....at least by > my definition of daisy chaining. For example, on the PROM board we will have > a PROM that contains a bitstream for the XBAR FPGA only. There are 9 XBAR > FPGAs all on different boards. So, we want to program these in parallel with > one being the master and the other 8 being slaves. If I understand the posts > correctly, INIT and DONE do need to be connected on the slaves as well as the > master. We will do this same thing with several other FPGAs and are trying > to figure out how many signals will be traveling down the backplane. If we > could get away with not sending INIT and DONE to the slaves, it would be > best, but I guess not. > > We are hoping to use the 1800 series proms from Xilinx, use the JTAG > interface to program the PROMs and kick off the config cycle. This way we > don't have to socket the PROMs and don't have to pull the boards out when > changing the bitstreams. Is this nuts or what....probably we should socket > the PROMs just in case. > > Any more thoughts??? Thanks again, > TomArticle: 20496
"Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> writes: > Had the Spartan-II been available six months ago when I started down this > route, I would've chosen it! OK, you just have to add that other voltage > regulator. That would make three power supplies on the board! Only three? Let me know when you have 5V, 3.3V, 2.5V, 2.05V, 1.8V and some +/- 12V... Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 20497
Catlin, Thanks for spelling it out for me. I got this idea from the Xilinx app note, "XC1800 series of in-system programmable configuration PROMs v1.3." On page 10 of the app note in figure 5(a) it shows master mode configuration. It also shows that data line and cclk line going to "Optional Slave FPGAs with Identical configurations." It doesn't show the other signal connections to the slave FPGAs this is where my confusion started. Now, if you look at the app note, "Virtex FPGA series configuration and readback," it only shows the master/slave configuration with the FPGAs daisy chained and in this case DONE, PROGRAM, INIT etc are all tied together. Anyway, I think I understand now. Thank you again for all the help. Sometimes it's better to talk these things out with someone rather than reading the app notes over and over. TomArticle: 20498
Hello, One of the FPGA we are using (Xilinx, XCV300) sometimes has a small hickup. I would like to invite your opinion on where I should look first. The Design: A memory controller unit that fetches a packet from the SRAM, feeeds the apcket into a FIFO. The last byte of the packet is marked with a special bit. Ojn the others side of the FIFO a packet processor massages every byte, and puts them back into another FIFO, the last byte still marked. The memory controller then outputs the result to the memory again. The problem: On _some_ boards, in _elevated temperature_, a problem occur _after a while_. The output data gets out of sync with the input data, i.e. it is stored in the buffer that belongs to the output buffer of the _next_ input packet. This out of synch then continues. Where to start looking? We suspect an erroneus flag in the FIFO, so that an extra packet delimiter is inserted in output FIFO. Some extra info: Synchronous design, all flops and FIFO on rising edge only. STA suggest 45 Mhz max freq., but we only run at 33 MHz. STA reports 96% covered by constraints. The packet processing half of the design can be with another, similar entity, and then the problem disappear. Simulation shows no problem, even after P&R and with SDF. What do you think? A problem with the part going out of spec? or is it our VHDL-code that hides some ugly stuff? Comments welcome! Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 20499
Tom McLaughlin wrote: > We know that CCLK and DATA have to go to the slaves, but: > > 1) Does DONE of the slaves have to be connected? Yes. XC4000 has a length count at the head of the bitstream, which makes sure that all devices in a chain become active together. In a Virtex chain, this same result is achieved by tying all the ( open drain ) DONE pins together, so the devices become active when the last one in the chain is ready. DONE is a more important signal in Virtex than it was in XC4000. > > 2) Does INIT of the slaves have to be connected? Yes, and also to the RESET input of the SPROM. INIT being Low indicates that the device is not ready to receive CCLK ( or will not generate CCLK, if a master). It indicates housekeeping and "housecleaning" activities, like sequential clear of the configuration store. As an input, it allows other devices ( by pulling low) to stop the master from starting CCLK. As SPROM reset input, it keeps the SPROM reset until the last moment, right before the beginning of configuration. This avoids any screw-ups even when Vcc behaves in an erratic way. > > > In one diagram, INIT is connected to all of the devices connected and in > another only the master. should be to all devices in the chain, if you really want to be safe. > > > I think we can just put pullups on the DONE signals of the slaves??? One pull-up is enough, but with Virtex you *have* to tie DONEs together ( with XC4000 there is no need ) > > > Can someone explain why INIT is a bidirectional signal??? I just did that above. > > > Thanks for the help...anyone done this before??? Yes, your design is not that exotic. I would, however, suggest to take a careful look at the -potentially very long- CCLK distribution networks. It *IS* a clock input, and as such very ( *VERY* ) sensitive to double-clocking. Many, if not most, configuration problems are due to reflections on unterminated and sloppily routed CCLK line. The driver rise/fall time may be very fast, so use a fast scope... Peter Alfke, Xilinx Applications
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