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
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 Alfke, Xilinx ApplicationsArticle: 20451
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: 20452
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: 20453
Hi all, Has anyone implemented the Run-length encoding and the HUFFMAN coding in FPGA any related work about the vectorial quantiser ... thanks in advance Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20454
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. regards, tom Peter Alfke wrote: > > 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 Alfke, Xilinx Applications -- Tom Burgess -- Digital Engineer National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.ca Office: (250) 490-4360 Switch Board: (250) 493-2277 Fax: (250) 493-7767Article: 20455
Yes, you are right. There is a bunch of press about stuff that isn't realizable. Both Altera and Xilinx get into little spats about every little thing. We can do partial re-programming, and then the other says they can too, even though neither of them can. They put the hooks into the hardware but neither can get the software algorithm to do it. The devices are getting very very large and not that expensive. The biggest changes in the past couple of years is of course the size but more importantly, speed, SRAM, and DLL (PLL like delay locked loop). All of the IP and buy our cores and this and that, I don't buy it! Mike anurag wrote: > Hi, > > There's a lot of talk on IP for FPGAs - ( tons of articles can be found > on this at EET, EDTN, Optimagic....etc. sites). The > reconfigurable-silicon concept does look very powerful & attractive ! > The question is " What level of functional complexity can exactly be > achieved on the currently available FPGAs ? " > > The designs that I've come across so far are ,at best, complex > independent functional blocks ie; FIR/IIR filters, Veterbi > codecs....etc. I've yet to come across a full fledged system level > design on an FPGA - something like (say) a design where a FPGA can be > instantly reconfigured to be a MP3 codec in one mode and a soft modem in > another. Another ex. I cld. quote is a FPGA behaving as one of the > wireless air interface standards ie; GSM/TDMA/CDMA ( in other words - a > S/W radio ) depending on the core downloaded on it (an ASIC from > Motorola exactly does this ! ) > > What I'm trying to get at is that all this seems to be theoritically > possible but I haven't seen any working design yet ! Even the ref. > examples at the Xilinx site are mostly glue-logic designs. SO, can the > examples quoted above be realised on a FPGA ( assuming that the required > no. of gates are available ) ? > If not (since it's possible theoritically) what cld. be the primary > reason for this ? > > Any comments wld. be appreciated ! > > Thanks........Anurag > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 20456
I've had the same problem. What you need to do is remove the "xor" statement and do the following: Old statement: A = B xor C; New statement: A = ( (B AND (NOT C)) OR ((NOT B) AND C) ); This seemed to work in MaxPlusII, Foundation and the Warp tool. Mike Pradeep Rao wrote: > Hi, > I am using the following code to XOR two bytes. I am able to simulate it > using Active HDL(3.1) and seems to work, but when I use Warp I get the > following error while compiling : > > C:\warp\bin\WARP.EXE -q -e10 -w100 -o2 -yga -fO -fP -v10 -dC371 -pCY7C371-14 > 3JC -b byte_xor.vhd > VHDL parser (C:\warp\bin\vhdlfe.exe V4 IR x95) > Setting library 'work' to directory 'lc371' > ---------------------------------------- > Compiling 'byte_xor.vhd' in 'C:\WARP\EXAMPLES\Pradeep'. > VHDL parser (C:\warp\bin\vhdlfe.exe V4 IR x95) > Library 'work' => directory 'lc371' > Linking 'C:\warp\lib\common\work\cypress.vif'. > byte_xor.vhd (line 8, col 30): (E56) Expected FUNCTION, but got IS > Error occurred within 'PROCESS' at line 8, column 16 in byte_xor.vhd. > byte_xor.vhd (line 8, col 30): (E10) Syntax error at/before reserved symbol > 'is'. > ---------------------------------------- > WARP done. > > Here's my code : > ----------------------- > entity bytexor is > port (xin1,xin2 : in bit_vector(0 to 7); > xout : out bit_vector(0 to 7)); > end entity bytexor; > > architecture behave of bytexor is > begin > compute:process(xin1,xin2) is > begin > for index in 0 to 7 loop > xout(index)<= xin1(index) xor xin2(index); > end loop; > end process compute; > end architecture behave; > ------------------------------------------------ > I'd be glad if someone could help me out. > Thanks, > Pradeep RaoArticle: 20457
I aggree the Xilinx recommendation is overkill. I use one 10uF, two or three 1uF tantalums per board per power plane. For the Virtex 300 I use eight .01uF ceramic caps on each of its two power supplies. The fpga runs at 125 MHz with lots of simultaneous switching. If you can afford good power/ground planes, don't worry about getting the caps directly adjacent to the power pins of the fpga. What you should be doing is AC coupling together the ground and power planes. For the ultimate in high frequency decoupling it's possible to use "buried capacitance layers" imbedded directly into the board. These are power/ground layers placed very close together in the board stack up. Avoid creating islands in the ground or power planes as these will only degrade signal integrity. -- Pete Dudley Arroyo Grande Systems John Janusson <jjanusson@nospami-o.com> wrote in message news:fZIl4.1502$wR.121291@news.flash.net... > Hello: > > I have read XAPP158 (Powering Virtex FPGAs > http://www.xilinx.com/xapp/xapp158.pdf) and found the following > recommendations: > > > VCCINT -> Guideline > ------------------- > 0.1 uF -> One per VCC > 47 uF -> Four per device (XCV50 - XCV300) > 470 uF -> One per device > > 470uF!!! In my experience, this seems excessive, even after reading the > disclaimer in Answers record #777 > (http://support.xilinx.com/techdocs/777.htm)... I was planning on following > the guidelines sans 470uF cap. It's a low power design in a XCV100 running > at mostly 4 to 32 MHz... > > Can others comment on power related issues in Virtex parts, particularly > related to decoupling and startup??? > > Thanks... > > John > >Article: 20458
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: 20459
Mary, We have used these similar Lattice devices at my company in the past, and although I was not involved, the design flow was apparently a nightmare. I beleive it was Exemplar to an EDIF to their fitter. This was a while ago and things may be different now. At my bosses recommendation, follow on projects have used the MAX7000 series, Exemplar, and the Atera Max Plus II fitter. This has gone very smoothly for us. However, I have always had a soft spot for Cypress, because I have used their tool quite succcessfully for many PAL devices. In my most recent design, I used a MAX7128. At the final hour, someone in our company brought in Cypress for a technical overview, and I brought up the fact that I could not get the design to compile under their tool, in a comparable device. In a very short order, they fixed my design to make it compile with their tool in the appropriate device, but I was so close to committing to etch that I could not make a change in the final hour. I believe the change was to convert resets to synchronous. In truth, I have not had the time to dig into what they did for my design. All that said, If you have access to the high end tools like Exemplar (I guess they call it differently now) the Altera flow works well, and is not so restrictive on VHDL style. The Warp tool is a little more restrictive. If you only are going to use the WARP tool because of economics, be careful and if you have problems, give their applications team a chance to help you out. They do stand behind their products and will help. I think Altera has a great product, and Cypress is an Underdog. Sometimes it is worth considering the Underdog. Another thing to consider is that the Altera tools do little optimization (that's why we use Exemplar) and Cypress' tool does. Good Luck. Clyde Mary Frantz wrote: > We have been using Lattice CPLD's (ispLSI1024, ispLSI2064, etc.) in the > past with Synopsis software and are dissatisfied with the performance of > both. Our designs are generally quite simple (glue logic and > registers). Does anyone have a recommendation either for or against > Altera (MAX7000 family) using MAXBaseline or MAXPlus, and Cypress (Ultra > 37000 family) using Warp 5.2? Any known hardware or software prolems? > > Thanks in advance. > Mary FrantzArticle: 20460
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??? > > Tom This is not really simple stuff, but once you get the hang of it, it is not too bad. It is very confusing at first though, partly because several of the signals are dual purpose and some are shared. One thing you really should consider is using a small micro on your common board and having it download all of the FPGAs individually. This will not be slower than the chained serial method and will be much easier to debug except for the added complexity of writing the code for the microprocessor. Chained FPGA configuration is a bit like Christmas tree lights. If you have a problem configuring any one, none of them will start up, including the master! This can be a pain to debug, especially with the shared signals. But the part that will be simpler with a micro is the fact that you can update each of the FPGA bit files individually. In the chained mode, you will have to generate one large bit file each time you change any of the individual bit files. I feel that this is not worth the small effort it takes to program a small microprocessor to download the FPGAs separately. It is also quite a bit easier to debug if you have a problem with any one FGPA. But you still need to understand how all of the signals work. I had planned to write a description of this and post it on my web site, but other events took priority. I will catch up with it someday. Peter Alfke offered to proofread it when I got it done. So here is a start. The PRGM- signal normally is tied together on all of the FPGAs, regardless of the mode you are using to configure them. The main reason you would want to make these separate signals is if you want to be able to load any of them without loading them all. The PRGM- signal will start the configuration process when asserted low. The INIT- signal (which should be wired together from all FPGAs if using a daisychain config) is pulled low by the FPGAs. When PRGM- released high, the FPGAs run through at least one more config reset cycle and then release INIT-. Because INIT- is open collector, all chips have to release INIT- for it to go high. If you are configuring the FPGAs with separate data and clocks, then the INIT- signals can also be separate. Once INIT- is high, you can start clocking the data out. The CCLK should not be clocked by a free running clock. The clock edges are counted by the FPGA and must match the count contained within the bit file. There are a lot of details associated with clocking the data. You have to supply the right number of clocks without no clocks coming before the beginning of the data. Further, you will have to provide some number of extra clocks at the end with the data high. This number depends on how the bit file is specified for the synchonization of the DONE, the internal GSR being released, the release of the IO tristate control and the end of the data configuration. This is all specified to the program that builds the bit file. It is a bit complex. I always use the default which I believe uses three extra clocks. I think you can add some extra clocks beyond the ones required at the end without hurting anything. When fully configured the DONE signal is released high by the FPGAs. This is also an open collector signal which can be tied together between the different FPGAs. The FPGA will not go through the final steps of activating the IOs and releasing the internal GSR signal until the DONE signal is high. This is part of what you can specify when making the bit file. Tying the DONE signals together from the different FPGAs will allow them to all start running together. Again, I don't normally bother with this, but it depends on your application. The proper synchonization also depends on whether you control the final steps with the CCLK signal or some other user supplied clock. This gets a bit more complex as you try to assure proper release of the GSR signal for your synchronous logic which is a whole discussion in itself. I think I have hit the main points. I am sure that others will be posting more details that I have missed or may have gotten incorrect. But as I said, I think that it would be easier to debug initially and maintain by separate configuration of the different FGPAs whether done with a micro or PLD or other logic. But that is just my opinion. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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: 20461
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. This is a subject that is often discussed here. What you describe with using a user clock for startup is one way to do it. That should work if the GSR net is fast enough to operate within your clock cycle. Another way to use the GSR which does not depend on sychronized release of the GSR is to make sure that all of the inputs to your various FSMs or other sychronous logic are in a state that will not cause the machines to make a state change. For example if the FSMs reset to an IDLE state, then make sure that none of the inputs that let the machine leave the IDLE state are asserted. Then even if the GSR is released on different clock cycles for different FFs, it will not matter. Or use a couple of delay FFs to generate (from the GSR) a separate, synchronized input to the FSMs which will delay state changes from this initial state until it releases. This net will not need to go to all of the FFs in your design and can be routed much faster. Another method which is similar to this last one is to have a separate, external reset signal which is controlled by a micro or other logic. This will only be released well after the config is complete and is synchrnized to the clock. As in the last method, this reset will not need to go to every FF in the FPGA and so can be routed more quickly. The GSR is nice in that it puts every FF into a known state and it is asynch so it does it NOW! But releasing it can be a problem. A second, more limited reset is a good way to get the FPGA started on the right foot. I can't remember other ways that have been described, but I am sure there are some. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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: 20462
Paul Mondello wrote: > > I have an application where I would like to be able to remotely re-program a > FLASH configuration PROM (XC18V00). The PROM and FPGA reside on an expansion > card inside a PC. > > Basically I would like to be able to download a new FPGA configuration file > to the Host over the network, re-program the Flash PROM, and then > re-configure the FPGA with the new code. The FPGA will be connected to an > embedded processor which will handle the task of interfacing to the Host via > the PCI bus and passing the configuration bits to the FPGA, which will then > have the task of re-programming the Flash, I'm guessing through the JTAG > port. At that point the embedded processor will force the FPGA to > reconfigure. > > Does anyone have any experience or ideas on how to do this? We basically > want a "simple" way to download feature changes and/or bug fixes to the FPGA > without having to remove the board from the PC. > > Thanks in advance for any help you can provide. > > -Paul > > P.S. I have read a little about "Xilinx Online" and think that this method > is more complicated than what we need. This is not really an answer to your question, but if you have an embedded processor on board, why not program the FPGA from the processor and let the processor manage the flash directly? You can get byte wide or 16 bit wide flash which is very easy to program from a processor without JTAG, 12 volts or any other hassles. They are large enough (> 1 MB) that you can even keep the processor code in it with multiple FPGA loads. I don't know how expensive the XC18V00 is, but you can get 1 MB of flash for about $5 to $10 depending on quantity. Programming the FPGA as if it were a peripheral is not hard. The asynch peripheral mode is easy and just as fast as serial mode. I believe there is also a parallel mode which is faster than the other modes. It lets you clock in a byte at a time without waiting for it to be serialized. What do you think? Do you really need to use the JTAG and programming the Flash via the FPGA? -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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: 20463
Hi, The shift operators (sll,srl,sla,sra,rol,ror also xnor and many other constructs) are not provided in VHDL-87 standard, only in VHDL-93, I suppose that's it. Hope this helps, ----------------- = Domagoj = ----------------- TeikMing Goh <ming@morgan.ucs.mun.ca> wrote in message news:Pine.OSF.3.95.1000210225125.25643A-100000@plato.ucs.mun.ca... > 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-Ming > > > >Article: 20464
I've had excellent results with Max+Plus II using the included AHDL for many years. It's a nice package if using a (decent) proprietary language is acceptable to you. The free Baseline package does not support timing-driven compilation (last I checked) which is a bit of a bother for FPGAs; I've not tried it with CPLDs - but the price sure is right! 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. I've not had the opportunity to use Warp, but people who have used it haven't complained to me about it. If you run some tests to make your decision please post the results, as you bring up some very interesting questions.Article: 20465
Hi Folks, I am using Foundation 2.1i-SP4 to target XC4k series. I am having difficulties with 'RLOC_RANGE' property. I am using schematic design entry. I attach a property 'RLOC_RANGE=Rr1Cc1:Rr2Cc2' on a symbol if I wanted it to be placed between Rows r1 and r2, and Columns c1 and c2. However, when I map the design, I do not get what I expect. This directive seems to be toatally ignored. Has anybody anybody out there used this property? How did it work for you? I appreciate your help.Article: 20466
Hi Folks, I am using Foundation 2.1i-SP4 to target XC4000. I am having problems using the 'RLOC_RANGE' property. I am using schematic design entry. I attach the property 'RLOC_RANGE=Rr1Cc1:Rr2Cc2' to a symbol in order to place it between Rows r1 and r2, and between Columns c1 and c2. However, when it maps, it does not give what I expect. It seems that it is ignoring this directive. Has anybody out there used this property? How did it work for you? I appreciate your help.Article: 20467
Hi Folks, I am using Foundation 2.1i-SP4 to target XC4000. I am having problems using the 'RLOC_RANGE' property. I am using schematic design entry. I attach the property 'RLOC_RANGE=Rr1Cc1:Rr2Cc2' to a symbol in order to place it between Rows r1 and r2, and between Columns c1 and c2. However, when it maps, it does not give what I expect. It seems that it is ignoring this directive. Has anybody out there used this property? How did it work for you? I appreciate your help.Article: 20468
> I aggree the Xilinx recommendation is overkill. > > I use one 10uF, two or three 1uF tantalums per board per power plane. For > the Virtex 300 I use eight .01uF ceramic caps on each of its two power > supplies. The fpga runs at 125 MHz with lots of simultaneous switching. > > If you can afford good power/ground planes, don't worry about getting the > caps directly adjacent to the power pins of the fpga. What you should be > doing is AC coupling together the ground and power planes. > > For the ultimate in high frequency decoupling it's possible to use "buried > capacitance layers" imbedded directly into the board. These are power/ground > layers placed very close together in the board stack up. The last two things are exactly what I mean with bideband decoupling. A very good AC coupling over the whole frequence range (requires a filter design) and very close power layers (we're using 68um, the last boards has 50um distance between the layers). > > Avoid creating islands in the ground or power planes as these will only > degrade signal integrity. If you will separate the ground plane the design would !!! NOT !!! work !!!!. Please don't do this! The separation of the VCC plane is just neccessary for two purposes: 1. The possible max decoupling frequency depends on the size of the area. If you decrease the area, you increase the maximun decoupling frequency (physical law). Our program calculates up to 1 GHz. 2. If you have analog and digital parts on one PCB it is much better to seperate the power planes. It's the same for "rough" digital logic (as FPGA's) and "sensible" logic (as SDRAM's). But this is not absolutely neccessary. > > -- > Pete Dudley Best regards, Andreas HeinerArticle: 20469
In article <87utdq$k27$1@nnrp1.deja.com>, bjorn_lindegren@my-deja.com wrote: > Hi using Xilinx foundation2.1i. (xc9536 vq44-15) > > Writing a VHDL program and recive an error > message: > The net'/ver1/klar' has more than one driver. > > All of our variables are STD_LOGIC. > > Thankful for help. > > Björn Lindegren, Christian Jerkeborg > > library IEEE; > use IEEE.std_logic_1164.all; > > use IEEE.std_logic_arith.all; > use IEEE.std_logic_unsigned.all; > > library SYNOPSYS; > use SYNOPSYS.attributes.all; > > entity fyren1 is > port (CLK: in STD_LOGIC; > OSC: in STD_LOGIC; > RESET: in STD_LOGIC; > KLAR: inout STD_LOGIC; > START: inout STD_LOGIC); > end; > > architecture fyren1_arch of fyren1 is > > -- SYMBOLIC ENCODED state machine: COUNT > type COUNT_type is (KLART, OSC0, OSC1, OSCSTART); > signal COUNT: COUNT_type; > > -- SYMBOLIC ENCODED state machine: FEMTON > type FEMTON_type is (S1, S2); > signal FEMTON: FEMTON_type; > > begin > --concurrent signal assignments > > COUNT_machine: process (CLK) > --machine variables declarations > variable COUNTER: INTEGER range 0 to 100; > > begin > > if CLK'event and CLK = '1' then > if START='1' then > COUNT <= OSCSTART; > COUNTER:=0; > KLAR<='0'; > else > case COUNT is > when KLART => > KLAR<='1'; > if COUNTER<=3 then > COUNT <= OSC0; > KLAR<='0'; > end if; > when OSC0 => > COUNTER:=COUNTER+1; > if OSC='1' then > COUNT <= OSC1; > KLAR<='0'; > elsif COUNTER=3 then > COUNT <= KLART; > end if; > when OSC1 => > if OSC='0' then > COUNT <= OSC0; > KLAR<='0'; > end if; > when OSCSTART => > KLAR<='0'; > if OSC='1' then > COUNT <= OSC1; > KLAR<='0'; > end if; > when others => > null; > end case; > end if; > end if; > end process; > > FEMTON_machine: process (CLK) > > begin > > if CLK'event and CLK = '1' then > if RESET='1' then > FEMTON <= S1; > KLAR<='0'; > START<='1'; > START<='0'; > else > case FEMTON is > when S1 => > START<='0'; > if KLAR<='1' then > FEMTON <= S2; > KLAR<='0'; > START<='1'; > end if; > when S2 => > START<='0'; > if KLAR<='1' then > FEMTON <= S1; > KLAR<='0'; > START<='1'; > end if; > when others => > null; > end case; > end if; > end if; > end process; > > end fyren1_arch; > > Sent via Deja.com http://www.deja.com/ > Before you buy. > The signal KLAR is driven in boths processes, with the result that (theoreticely) on the same clock egde one would like to set it to high, and the other to low. During simulation this is no problem, since KLAR is from type STD_LOGIC which is a resolved type, and from such collisions (simply speaking) a new resulting value is calculated. On an architecture like the XC9500 CPLDs the synthesizer can not resolve this type of conflict and requires that any signal is driven from exactly one process. You have to modify your design this way. Hope this helps -- Klaus Falser Durst Phototechnik AG I-39042 Brixen Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20470
> ERROR:basut - Boundary scan chain has been improperly specified. Please > check your configuration and re-enter the boundary-scan chain information. > Boundary-scan chain validated unsuccessfully. > ERROR:basut - : The boundary-scan chain has not been declared correctly. > Verify the syntax and correctness of the device BSDL files, correct the > files, > reset the cable and retry this command. > > Have you any suggestions ? Have you tried downloading the latest BSDL file from the Xilinx web site? This worked when I had a similar problem with a Spartan device. Leon -- Leon Heller, G1HSM Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824 Email: leon_heller@hotmail.com Web: http://www.geocities.com/SiliconValley/Code/1835 Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20471
try here: http://www.xilinx.com/products/xaw/mp3/index.htm there are some links at the bottom of the web page. anurag <anurag@earthling.net> wrote in message news:87ph56$ogj$1@nnrp1.deja.com... > Hi, > > wld. appeciate if anyone cld. point out to MP3 and Wavelet codec > implemented on a FPGA...if any ? > > Thanks...... > > AK > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 20472
In article <87vrg6$jdt$1@news.vsnl.net.in>, Pradeep Rao <pradeeprao@planetmail.com> writes >Hi, >I am using the following code to XOR two bytes. I am able to simulate it >using Active HDL(3.1) and seems to work, but when I use Warp I get the >following error while compiling : > >C:\warp\bin\WARP.EXE -q -e10 -w100 -o2 -yga -fO -fP -v10 -dC371 -pCY7C371-14 >3JC -b byte_xor.vhd >VHDL parser (C:\warp\bin\vhdlfe.exe V4 IR x95) >Setting library 'work' to directory 'lc371' >---------------------------------------- >Compiling 'byte_xor.vhd' in 'C:\WARP\EXAMPLES\Pradeep'. >VHDL parser (C:\warp\bin\vhdlfe.exe V4 IR x95) >Library 'work' => directory 'lc371' >Linking 'C:\warp\lib\common\work\cypress.vif'. >byte_xor.vhd (line 8, col 30): (E56) Expected FUNCTION, but got IS >Error occurred within 'PROCESS' at line 8, column 16 in byte_xor.vhd. >byte_xor.vhd (line 8, col 30): (E10) Syntax error at/before reserved symbol >'is'. >---------------------------------------- From the error, it looks like Warp doesn't support VHDL '93, or you haven't enabled VHDL '93. In VHDL '87, you have to leave out the 'is', i.e. -- VHDL '87 process(xin1, xin2) begin --VHDL '93 process(xin1, xin2) is So probably, Active HDL is set to accept 1993 syntax, and Cypress Warp is set to accept VHDL 1987 syntax. If you leave out the 'is', it is compatible with both VHDL 1987 and VHDL 1993. kind regards Alan -- Alan Fitch DOULOS Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK Tel: +44 (0)1425 471 223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471 573 ** Visit THE WINNING EDGE www.doulos.com **Article: 20473
In article <87v2gi$2enp$1@noao.edu>, Andy Peters <apeters.Nospam@nospam. noao.edu.nospam> writes >bjorn_lindegren@my-deja.com wrote in message ><87utdp$k24$1@nnrp1.deja.com>... >>Hi using Xilinx foundation2.1i. (xc9536 vq44-15) >> >>Writing a VHDL program and recive an error >>message: >>The net'/ver1/klar' has more than one driver. >> >>All of our variables are STD_LOGIC. >> >[snip code] > >You drive the signal klar from more than one process. > >-- 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 > > > Also, you've used "if klar <= '1'" when I would guess you meant "if klar = '1'" in the code below regards Alan P.S. This is nothing to do with the error message, I just noticed it! FEMTON_machine: process (CLK) begin if CLK'event and CLK = '1' then if RESET='1' then FEMTON <= S1; KLAR<='0'; START<='1'; START<='0'; else case FEMTON is when S1 => START<='0'; if KLAR<='1' then ---??? FEMTON <= S2; KLAR<='0'; START<='1'; end if; when S2 => START<='0'; if KLAR<='1' then ---??? FEMTON <= S1; KLAR<='0'; START<='1'; end if; when others => null; end case; end if; end if; end process; end fyren1_arch; -- Alan Fitch DOULOS Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK Tel: +44 (0)1425 471 223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471 573 ** Visit THE WINNING EDGE www.doulos.com **Article: 20474
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-Ming > > > > ROL is in NUMERIC_STD, but it only works on type UNSIGNED, not on STD_LOGIC_VECTOR. e.g. library IEEE; use IEEE.STD_LOGIC_1164.all, IEEE.NUMERIC_STD.all; entity ... architecture... signal U, UU : UNSIGNED(7 downto 0); signal V, VV : STD_LOGIC_VECTOR(7 downto 0); begin ... UU <= U ROL 1; -- for std_logic_vector, use concatenation VV <= V(6 downto 0) & V(7); kind regards Alan -- Alan Fitch DOULOS Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK Tel: +44 (0)1425 471 223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471 573 ** Visit THE WINNING EDGE www.doulos.com **
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