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
I'd like to sell my Xiling Spartan 3AN Starter Kit (almost new and full working). http://www.xilinx.com/products/devkits/HW-SPAR3AN-SK-UNI-G.htm If anyone interested contact me. Thank you. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148601
Hey Related to constraints like period. I have PERIOD constraints on my clocks and related signals have also been placed into TIMEGRPs. Also i mention the duty cycle of clocks here are some numbers there are 2 clocks in the systems. a 50mhz mclk and a 25mhz phy_clk.. The controller interface runs at mclk and is seperated from other logic. i use the following statements to constraint NET "phy_clk" TNM_NET = "phy_clk"; TIMESPEC "TS_phy_clk" = PERIOD "phy_clk" 40 ns HIGH 50 %; NET "mclk" TNM_NET = "mclk"; TIMESPEC "TS_mclk" = PERIOD "mclk" 20 ns HIGH 50 %; Further the TIMEGRPS are TIMEGRP "phy_clk_pads" OFFSET = IN 35 ns BEFORE "phy_clk" ; TIMEGRP "mclk_pads" OFFSET = IN 15 ns BEFORE "mclk" ; TIMEGRP "phy_clk_pads" OFFSET = OUT 35 ns AFTER "phy_clk" ; TIMESPEC "TS_P2P" = FROM "PADS" TO "PADS" 15 ns; so now the controller interface constraints are INST "data_bus<7>" TNM = "mclk_pads"; INST "data_bus<6>" TNM = "mclk_pads"; INST "data_bus<5>" TNM = "mclk_pads"; INST "data_bus<4>" TNM = "mclk_pads"; INST "data_bus<3>" TNM = "mclk_pads"; INST "data_bus<2>" TNM = "mclk_pads"; INST "data_bus<1>" TNM = "mclk_pads"; INST "data_bus<0>" TNM = "mclk_pads"; INST "read_" TNM = "mclk_pads"; INST "cs_" TNM = "mclk_pads"; INST "write_" TNM = "mclk_pads"; SO i dont think that i am missing the constraints. However if u think i am then comment on it plz /////////////////////////////////////////////////////// Related to your comment on flopping signals only once in one clock domain: I am not doing any branching for the first stage of floping which is exaclty the point u made. However i have more flops down the chain just to add delay but that doesnot realy count as a problem. Regards >On Aug 4, 9:23=A0am, "salimbaba" ><a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: >> Hey i am using ise 9.1i for synthesizing my designs for spartan 3 fpgas. = >I >> am facing a very wierd problem. >> My system comprises of 1 xcs400 fpga and an ARM 7 processor. My RTL desig= >n >> is very modular. Here is the problem. >> >> I have a microcontroller interface in my rtl design to communicate with >> arm. other portions of my rtl design are related to some other logic >> implementations.now what happens is that when i change some line of code = >or >> logic in the other modules WHICH ARE IN NO WAY CONNECTED TO CONTROLLER >> INTERFACE, the bit file that is generated causes my processor to crash an= >d >> go into abort conditions. this happens primarily because of contention on >> the data bus of the processor. >> However, i cannot tell why this is happening that a change in logic is so= >me >> very remote part of the design causes the controller interface to >> misbehave. Keep in view that my controller interface is perfected and is >> running perfectly on a couple of other systems.the only difference betwee= >n >> a working bit file and a non working bit file is a small change in some >> other part of the design and it is so small that it may include only a si= >ze >> change of a register. >> >> i have pulled down all unused ios and all other setups are exactly the >> same >> >> Regards =A0 =A0 >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >It's very likely that you are having timing problems. If your design >is >not properly constrained, the timing can vary significantly from run >to run, even for parts of the design that don't change. I assume >you at least have PERIOD constraints on any clocks in the design. >In addition you should constrain inputs and outputs for setup/hold >and clock to out. Alternately turn on the switch in the tools that >says to push all of your I/O flip-flops into the IOB's. This will >cause the timing at the pin interface to be constant from run >to run. There may be cases where you I/O logic cannot be >pushed into the IOB's however, so you need to check for these >and make sure that you have constrained the timing for them >appropriately. > >A good source of information is your post place&route timing >report. Make sure you tell the report generator to add the >data sheet section. This gives you a view into the setup/hold >and clock to out timing of your design as built. See if there >are significant differences between the versions that work >and those that don't. > >Finally another cause of build-to-build design instability is >also caused by timing differences but not in a way that >lends itself to being constrained. If you have any signals >that come in asynchronously or cross clock domains be >sure that for each clock they are only registered in one >flip-flop. Any further logic in that clock domain should use >the output of the same initial synchronizing flip-flop. If >the same async input goes through multiple flip-flops, >those flip-flops can see the signal change on different >clock cycles, and which one sees the signal first can >change from build to build based on the relative routing >delays from the source to the flip-flop D input. > >HTH, >Gabor > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148602
On Aug 5, 7:59=A0am, "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > Hey > > Related to constraints like period. I have PERIOD constraints on my clock= s > and related signals have also been placed into TIMEGRPs. Also i mention t= he > duty cycle of clocks > > here are some numbers > there are 2 clocks in the systems. a 50mhz mclk and a 25mhz phy_clk.. The > controller interface runs at mclk and is seperated from other logic. > > i use the following statements to constraint > > NET "phy_clk" TNM_NET =3D "phy_clk"; > TIMESPEC "TS_phy_clk" =3D PERIOD "phy_clk" 40 ns HIGH 50 %; > > NET "mclk" TNM_NET =3D "mclk"; > TIMESPEC "TS_mclk" =3D PERIOD "mclk" 20 ns HIGH 50 %; > > Further the TIMEGRPS are > > TIMEGRP "phy_clk_pads" OFFSET =3D IN 35 ns BEFORE "phy_clk" =A0; > TIMEGRP "mclk_pads" OFFSET =3D IN 15 ns BEFORE "mclk" =A0; > TIMEGRP "phy_clk_pads" OFFSET =3D OUT 35 ns AFTER "phy_clk" =A0; > TIMESPEC "TS_P2P" =3D FROM "PADS" TO "PADS" 15 ns; > > so now the controller interface constraints are > > INST "data_bus<7>" TNM =3D "mclk_pads"; > INST "data_bus<6>" TNM =3D "mclk_pads"; > INST "data_bus<5>" TNM =3D "mclk_pads"; > INST "data_bus<4>" TNM =3D "mclk_pads"; > INST "data_bus<3>" TNM =3D "mclk_pads"; > INST "data_bus<2>" TNM =3D "mclk_pads"; > INST "data_bus<1>" TNM =3D "mclk_pads"; > INST "data_bus<0>" TNM =3D "mclk_pads"; > INST "read_" TNM =3D "mclk_pads"; > INST "cs_" TNM =3D "mclk_pads"; > INST "write_" TNM =3D "mclk_pads"; > > SO i dont think that i am missing the constraints. However if u think i a= m > then comment on it plz The only way to see if your design is properly constrained is to create a "Verbose" timing report (post P&R) and turn on "Report Unconstrained Paths" for say 100 paths. See if any paths look like they should be constrained. Also enable the "data sheet" section of the timing report. Compare the data sheet numbers (I/O timing) for a working version vs. a non-working version to see if anything looks like it could be causing the problem. Your I/O constraints are quite loose. They only leave 5 ns for setup and clock to Q at the external device. Make sure this is acceptable. Regards, GaborArticle: 148603
Do you have state machines in the design? Are they properly reset with a SYNCHRONOUS reset at the beginning of the day? Using the global async reset is not sufficient. You must provide a reset signal that is synchronous to the state machine's clock. Failure to do this can result in illegal states and erratic behavior. -JeffArticle: 148604
On 8/5/10 2:09 AM, muhammad_umer wrote: > One more thing, i google internet and found some articles, mentioning > EasythPath saves 80% of FPGA cost. so this mean that, for instance, if FPGA > cost $100 then its EasyPath partner will cost $20. Am i correct in my > understanding? No. Though you ARE correct that 100 reduced by 80% is 20. If you go back and look at those articles I think it will say something like easypath "can" save "up to" 80% in the right situation. There are other factors, like how many per year are you going to buy. Like others have said, talk to your xilinx salesman. -JeffArticle: 148605
Thank you all for your helpful responses.
Ultimately I had to write a wrapper to hide the workarounds required to
connect signals to ports of (semantically) different types.
This was after discovering that in:
U1: somedevice
port map ( DIN => std_logic_vector(x),
DOUT => U1DOUT);
Xilinx tools also do not connect 'x' to 'DIN', and fail to warn that the
line is being ignored until 'DIN' is subsequently noted as disconnected...
I must agree with KJ that correctness is defined by compliance to the
standard. Xilinx reminds me more and more of Internet Explorer 6 but
that is a rant for another day.
Thanks again,
Andrew
0xADF
Article: 148606AFAIK, in x86 architectures, io writes will be cache coherent, unless you're setting SNR (no snoop) in the write header by mistake But to me this sounds like a Windows problem. Typically garden variety PC's don't block PCIE accesses, all of the address space is open to a peripheral. Acid test : if you can write to a given physical address from your FPGA, and read the value, you're golden in the physical address domain. So maybe what you think you're reading in your code is not actually getting to the correct physical address. try : write from FPGA card to a physical address read back using FPGA card, see if good. write some known data from windows software read back using FPGA card.Article: 148607
Hello All, I am writing this to seek your guidance in knowing the possible methods/procedures to verify the analytical SEU estmiates for an FPGA designs. To my understanding the way to go about it is beam testing or laser testing. The fault injection methods don't seem to me prudent in this case as we are checking the estimate of soft errors in an FPGA design and not verifying a mitigating methodology ? My second query is related to the method of estimating SEU rate in Xilinx FPGAs. I am utilizing the knowledge obtained from XDL and FPGA Editor to make an estimate of configuration bits used by my design. The problem I am encountering is how to estimate total configuration bits in the nets that are related to "pips". for example it is true that a pip connecting two nodes of a switch will require only one configuration bit, but at the same time each node of the switch is connected to several other nodes. Hence potentially the net may get connected to an irrelevant node (erroneously) due to SEU. And this leads to me the question that what should I do to cope such a scenario in an effort to provide realistic estimate of configuration bits ? Of course what I am doing is with publicly available information from Xilinx and hence it should not cause any legal hitch. Your recommendations would be highly appreciated. Rafay --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148608
Rob Gaddi <rgaddi@technologyhighland.com> wrote: >On 8/4/2010 6:43 AM, Gabor wrote: >> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote: >>> A project I am considering undertaking would require that an FPGA's >>> implementation flow (synthesis through bitgen) be routinely run in a >>> scripted form at customer locations by the end customer, likely a non- >>> engineer. The RTL input can be assumed to be good. All aspects of >>> the vendor tools would be hidden from the end user via scripts or GUI. >>> >>> The stability of the vendor tools are the biggest concern in this >>> project. I am not tied to any vendor. The performance specs are such >>> that almost any current or last generation FPGA could handle the >>> load. >>> >>> I would appreciate hearing your thoughts on which vendor to consider >>> for this application. Unpredictable errors and crashes are something >>> that must be avoided. >>> >>> Thank you in advance. >>> Angie >> >> Having worked with Xilinx tools and devices for many years, I would >> say that it is possible to have very stable results as long as you >> know what to avoid. Generally speaking, a design with one system >> clock and no special feature usage almost never has any issues >> through the tool chain. Start adding too many clock resources >> or other special features and you can run into issues where the >> tools need to be guided to complete the design. I don't know >> enough about your application to say whether Xilinx tools are >> stable enough for your purposes. Whichever chip vendor you >> pick, you will have some things you need to avoid. Only the >> synthesis portion of the tool chain can be de-coupled from the >> chip vendor. It would really help if you had extensive experience >> working with your vendor of choice before going into your own >> tool implementation. Most of the annoying bugs from Xilinx >> are not in the actual synthesis / place / route / build, but in the >> GUI wrapper. I agree. The command line tools seem to work just fine. >> Regards, >> Gabor > >I've had nothing but problems with stability of Xilinx designs, >actually. Routinely in going from one version of the toolchain to the >next, command line options are changed or deprecated, forcing me to >tweak the settings in my Makefile. Right now I'm in the process of >opening a Webcase because a design which, under 12.1, was willing to >respect IOB=FORCE to push some input flip-flops into the ILOGIC cells >for timing reasons, it no longer will under 12.2. IIRC it is possible to install and use several different versions of the Xilinx tools if you use make or batch files. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 148609
On 8/5/2010 12:28 PM, Nico Coesel wrote: > Rob Gaddi<rgaddi@technologyhighland.com> wrote: > >> On 8/4/2010 6:43 AM, Gabor wrote: >>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote: >>>> A project I am considering undertaking would require that an FPGA's >>>> implementation flow (synthesis through bitgen) be routinely run in a >>>> scripted form at customer locations by the end customer, likely a non- >>>> engineer. The RTL input can be assumed to be good. All aspects of >>>> the vendor tools would be hidden from the end user via scripts or GUI. >>>> >>>> The stability of the vendor tools are the biggest concern in this >>>> project. I am not tied to any vendor. The performance specs are such >>>> that almost any current or last generation FPGA could handle the >>>> load. >>>> >>>> I would appreciate hearing your thoughts on which vendor to consider >>>> for this application. Unpredictable errors and crashes are something >>>> that must be avoided. >>>> >>>> Thank you in advance. >>>> Angie >>> >>> Having worked with Xilinx tools and devices for many years, I would >>> say that it is possible to have very stable results as long as you >>> know what to avoid. Generally speaking, a design with one system >>> clock and no special feature usage almost never has any issues >>> through the tool chain. Start adding too many clock resources >>> or other special features and you can run into issues where the >>> tools need to be guided to complete the design. I don't know >>> enough about your application to say whether Xilinx tools are >>> stable enough for your purposes. Whichever chip vendor you >>> pick, you will have some things you need to avoid. Only the >>> synthesis portion of the tool chain can be de-coupled from the >>> chip vendor. It would really help if you had extensive experience >>> working with your vendor of choice before going into your own >>> tool implementation. Most of the annoying bugs from Xilinx >>> are not in the actual synthesis / place / route / build, but in the >>> GUI wrapper. > > I agree. The command line tools seem to work just fine. > >>> Regards, >>> Gabor >> >> I've had nothing but problems with stability of Xilinx designs, >> actually. Routinely in going from one version of the toolchain to the >> next, command line options are changed or deprecated, forcing me to >> tweak the settings in my Makefile. Right now I'm in the process of >> opening a Webcase because a design which, under 12.1, was willing to >> respect IOB=FORCE to push some input flip-flops into the ILOGIC cells >> for timing reasons, it no longer will under 12.2. > > IIRC it is possible to install and use several different versions of > the Xilinx tools if you use make or batch files. > That's actually what I'm doing now on my Linux build machine; the different versions of the Xilinx tools seems to all play fairly nicely there. On my Windows box, versions 11 and higher (FlexLM) get seriously snippy with one another. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 148610
On 08/05/2010 04:43 PM, Rob Gaddi wrote: > On 8/5/2010 12:28 PM, Nico Coesel wrote: >> Rob Gaddi<rgaddi@technologyhighland.com> wrote: >> >>> On 8/4/2010 6:43 AM, Gabor wrote: >>>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote: >>>>> A project I am considering undertaking would require that an FPGA's >>>>> implementation flow (synthesis through bitgen) be routinely run in a >>>>> scripted form at customer locations by the end customer, likely a non- >>>>> engineer. The RTL input can be assumed to be good. All aspects of >>>>> the vendor tools would be hidden from the end user via scripts or GUI. >>>>> >>>>> The stability of the vendor tools are the biggest concern in this >>>>> project. I am not tied to any vendor. The performance specs are such >>>>> that almost any current or last generation FPGA could handle the >>>>> load. >>>>> >>>>> I would appreciate hearing your thoughts on which vendor to consider >>>>> for this application. Unpredictable errors and crashes are something >>>>> that must be avoided. >>>>> >>>>> Thank you in advance. >>>>> Angie >>>> >>>> Having worked with Xilinx tools and devices for many years, I would >>>> say that it is possible to have very stable results as long as you >>>> know what to avoid. Generally speaking, a design with one system >>>> clock and no special feature usage almost never has any issues >>>> through the tool chain. Start adding too many clock resources >>>> or other special features and you can run into issues where the >>>> tools need to be guided to complete the design. I don't know >>>> enough about your application to say whether Xilinx tools are >>>> stable enough for your purposes. Whichever chip vendor you >>>> pick, you will have some things you need to avoid. Only the >>>> synthesis portion of the tool chain can be de-coupled from the >>>> chip vendor. It would really help if you had extensive experience >>>> working with your vendor of choice before going into your own >>>> tool implementation. Most of the annoying bugs from Xilinx >>>> are not in the actual synthesis / place / route / build, but in the >>>> GUI wrapper. >> >> I agree. The command line tools seem to work just fine. >> >>>> Regards, >>>> Gabor >>> >>> I've had nothing but problems with stability of Xilinx designs, >>> actually. Routinely in going from one version of the toolchain to the >>> next, command line options are changed or deprecated, forcing me to >>> tweak the settings in my Makefile. Right now I'm in the process of >>> opening a Webcase because a design which, under 12.1, was willing to >>> respect IOB=FORCE to push some input flip-flops into the ILOGIC cells >>> for timing reasons, it no longer will under 12.2. >> >> IIRC it is possible to install and use several different versions of >> the Xilinx tools if you use make or batch files. >> > > That's actually what I'm doing now on my Linux build machine; the > different versions of the Xilinx tools seems to all play fairly nicely > there. On my Windows box, versions 11 and higher (FlexLM) get seriously > snippy with one another. Give Xilinx time, they'll get the deficiencies in the Linux versions sorted out soon enough -- then your dissimilar versions will have trouble playing together on the Linux box, too! (Kudos to Xilinx, by the way -- the Linux version of their tool set is perking along quite nicely under Ubuntu. Other than having to roll my own driver for the parallel cable, all has worked straight out of the box). -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 148611
which cypress tool is used to read or write the PID,VID in EEPROM in xilinx usb programmer? I want to read the PID,VID from xilinx spartan-3E starter kit how can i do that? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148612
On 06/08/2010 07:03, Tim Wescott wrote: > On 08/05/2010 04:43 PM, Rob Gaddi wrote: >> On 8/5/2010 12:28 PM, Nico Coesel wrote: >>> Rob Gaddi<rgaddi@technologyhighland.com> wrote: >>> >>>> On 8/4/2010 6:43 AM, Gabor wrote: >>>>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote: >>>>>> A project I am considering undertaking would require that an FPGA's >>>>>> implementation flow (synthesis through bitgen) be routinely run in a >>>>>> scripted form at customer locations by the end customer, likely a >>>>>> non- >>>>>> engineer. The RTL input can be assumed to be good. All aspects of >>>>>> the vendor tools would be hidden from the end user via scripts or >>>>>> GUI. >>>>>> >>>>>> The stability of the vendor tools are the biggest concern in this >>>>>> project. I am not tied to any vendor. The performance specs are such >>>>>> that almost any current or last generation FPGA could handle the >>>>>> load. >>>>>> >>>>>> I would appreciate hearing your thoughts on which vendor to consider >>>>>> for this application. Unpredictable errors and crashes are something >>>>>> that must be avoided. >>>>>> >>>>>> Thank you in advance. >>>>>> Angie >>>>> >>>>> Having worked with Xilinx tools and devices for many years, I would >>>>> say that it is possible to have very stable results as long as you >>>>> know what to avoid. Generally speaking, a design with one system >>>>> clock and no special feature usage almost never has any issues >>>>> through the tool chain. Start adding too many clock resources >>>>> or other special features and you can run into issues where the >>>>> tools need to be guided to complete the design. I don't know >>>>> enough about your application to say whether Xilinx tools are >>>>> stable enough for your purposes. Whichever chip vendor you >>>>> pick, you will have some things you need to avoid. Only the >>>>> synthesis portion of the tool chain can be de-coupled from the >>>>> chip vendor. It would really help if you had extensive experience >>>>> working with your vendor of choice before going into your own >>>>> tool implementation. Most of the annoying bugs from Xilinx >>>>> are not in the actual synthesis / place / route / build, but in the >>>>> GUI wrapper. >>> >>> I agree. The command line tools seem to work just fine. >>> >>>>> Regards, >>>>> Gabor >>>> >>>> I've had nothing but problems with stability of Xilinx designs, >>>> actually. Routinely in going from one version of the toolchain to the >>>> next, command line options are changed or deprecated, forcing me to >>>> tweak the settings in my Makefile. Right now I'm in the process of >>>> opening a Webcase because a design which, under 12.1, was willing to >>>> respect IOB=FORCE to push some input flip-flops into the ILOGIC cells >>>> for timing reasons, it no longer will under 12.2. >>> >>> IIRC it is possible to install and use several different versions of >>> the Xilinx tools if you use make or batch files. >>> >> >> That's actually what I'm doing now on my Linux build machine; the >> different versions of the Xilinx tools seems to all play fairly nicely >> there. On my Windows box, versions 11 and higher (FlexLM) get seriously >> snippy with one another. > > Give Xilinx time, they'll get the deficiencies in the Linux versions > sorted out soon enough -- then your dissimilar versions will have > trouble playing together on the Linux box, too! > > (Kudos to Xilinx, by the way -- the Linux version of their tool set is > perking along quite nicely under Ubuntu. Other than having to roll my > own driver for the parallel cable, all has worked straight out of the box). > If you are having trouble with several different versions of the tools installed at the same time, consider running each one within its own virtual machine (I like VirtualBox, but it's a matter of taste). I've done that for other programs that conflict with each other.Article: 148613
On Aug 6, 9:02=A0am, "chinnathurai" <chinnathurai.c@n_o_s_p_a_m.n_o_s_p_a_m.rediffmail.com> wrote: > which cypress tool is used to read or write the PID,VID in EEPROM in xili= nx > usb programmer? > > I want to read the PID,VID from xilinx spartan-3E starter kit how can i d= o > that? =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Hello, download Cypress Suite USB. I've used it to program my Cypress USB controller. You will have to use Control Center or CyConsole, can't remember exactly now.Article: 148614
On 08/06/2010 01:03 AM, Tim Wescott wrote: > On 08/05/2010 04:43 PM, Rob Gaddi wrote: >> On 8/5/2010 12:28 PM, Nico Coesel wrote: >>> Rob Gaddi<rgaddi@technologyhighland.com> wrote: >>> >>>> On 8/4/2010 6:43 AM, Gabor wrote: >>>>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote: >>>>>> A project I am considering undertaking would require that an FPGA's >>>>>> implementation flow (synthesis through bitgen) be routinely run in a >>>>>> scripted form at customer locations by the end customer, likely a >>>>>> non- >>>>>> engineer. The RTL input can be assumed to be good. All aspects of >>>>>> the vendor tools would be hidden from the end user via scripts or >>>>>> GUI. >>>>>> >>>>>> The stability of the vendor tools are the biggest concern in this >>>>>> project. I am not tied to any vendor. The performance specs are such >>>>>> that almost any current or last generation FPGA could handle the >>>>>> load. >>>>>> >>>>>> I would appreciate hearing your thoughts on which vendor to consider >>>>>> for this application. Unpredictable errors and crashes are something >>>>>> that must be avoided. >>>>>> >>>>>> Thank you in advance. >>>>>> Angie >>>>> >>>>> Having worked with Xilinx tools and devices for many years, I would >>>>> say that it is possible to have very stable results as long as you >>>>> know what to avoid. Generally speaking, a design with one system >>>>> clock and no special feature usage almost never has any issues >>>>> through the tool chain. Start adding too many clock resources >>>>> or other special features and you can run into issues where the >>>>> tools need to be guided to complete the design. I don't know >>>>> enough about your application to say whether Xilinx tools are >>>>> stable enough for your purposes. Whichever chip vendor you >>>>> pick, you will have some things you need to avoid. Only the >>>>> synthesis portion of the tool chain can be de-coupled from the >>>>> chip vendor. It would really help if you had extensive experience >>>>> working with your vendor of choice before going into your own >>>>> tool implementation. Most of the annoying bugs from Xilinx >>>>> are not in the actual synthesis / place / route / build, but in the >>>>> GUI wrapper. >>> >>> I agree. The command line tools seem to work just fine. >>> >>>>> Regards, >>>>> Gabor >>>> >>>> I've had nothing but problems with stability of Xilinx designs, >>>> actually. Routinely in going from one version of the toolchain to the >>>> next, command line options are changed or deprecated, forcing me to >>>> tweak the settings in my Makefile. Right now I'm in the process of >>>> opening a Webcase because a design which, under 12.1, was willing to >>>> respect IOB=FORCE to push some input flip-flops into the ILOGIC cells >>>> for timing reasons, it no longer will under 12.2. >>> >>> IIRC it is possible to install and use several different versions of >>> the Xilinx tools if you use make or batch files. >>> >> >> That's actually what I'm doing now on my Linux build machine; the >> different versions of the Xilinx tools seems to all play fairly nicely >> there. On my Windows box, versions 11 and higher (FlexLM) get seriously >> snippy with one another. > > Give Xilinx time, they'll get the deficiencies in the Linux versions > sorted out soon enough -- then your dissimilar versions will have > trouble playing together on the Linux box, too! > > (Kudos to Xilinx, by the way -- the Linux version of their tool set is > perking along quite nicely under Ubuntu. Other than having to roll my > own driver for the parallel cable, all has worked straight out of the box). > Agreed. I have a few versions running great on two separate Fedora machines. One is F13 and one is F12. -- Jason ThibodeauArticle: 148615
On 8/4/2010 11:10 AM, alessandro.strazzero@gmail.com wrote: > With my surprise, the model doesn't work well as in ModelSim and I > don't understand the > reasons. > could you suggest me some guidelines where to search for the > problems ? You might also have a look at the rtl viewer for missing wires or flops. -- Mike TreselerArticle: 148616
On Aug 5, 6:43=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > On 8/5/2010 12:28 PM, Nico Coesel wrote: > > > > > Rob Gaddi<rga...@technologyhighland.com> =A0wrote: > > >> On 8/4/2010 6:43 AM, Gabor wrote: > >>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> =A0 wrote: > >>>> A project I am considering undertaking would require that an FPGA's > >>>> implementation flow (synthesis through bitgen) be routinely run in a > >>>> scripted form at customer locations by the end customer, likely a no= n- > >>>> engineer. =A0The RTL input can be assumed to be good. =A0All aspects= of > >>>> the vendor tools would be hidden from the end user via scripts or GU= I. > > >>>> The stability of the vendor tools are the biggest concern in this > >>>> project. =A0I am not tied to any vendor. =A0The performance specs ar= e such > >>>> that almost any current or last generation FPGA could handle the > >>>> load. > > >>>> I would appreciate hearing your thoughts on which vendor to consider > >>>> for this application. =A0Unpredictable errors and crashes are someth= ing > >>>> that must be avoided. > > >>>> Thank you in advance. > >>>> Angie > > >>> Having worked with Xilinx tools and devices for many years, I would > >>> say that it is possible to have very stable results as long as you > >>> know what to avoid. =A0Generally speaking, a design with one system > >>> clock and no special feature usage almost never has any issues > >>> through the tool chain. =A0Start adding too many clock resources > >>> or other special features and you can run into issues where the > >>> tools need to be guided to complete the design. =A0I don't know > >>> enough about your application to say whether Xilinx tools are > >>> stable enough for your purposes. =A0Whichever chip vendor you > >>> pick, you will have some things you need to avoid. =A0Only the > >>> synthesis portion of the tool chain can be de-coupled from the > >>> chip vendor. =A0It would really help if you had extensive experience > >>> working with your vendor of choice before going into your own > >>> tool implementation. =A0Most of the annoying bugs from Xilinx > >>> are not in the actual synthesis / place / route / build, but in the > >>> GUI wrapper. > > > I agree. The command line tools seem to work just fine. > > >>> Regards, > >>> Gabor > > >> I've had nothing but problems with stability of Xilinx designs, > >> actually. =A0Routinely in going from one version of the toolchain to t= he > >> next, command line options are changed or deprecated, forcing me to > >> tweak the settings in my Makefile. =A0Right now I'm in the process of > >> opening a Webcase because a design which, under 12.1, was willing to > >> respect IOB=3DFORCE to push some input flip-flops into the ILOGIC cell= s > >> for timing reasons, it no longer will under 12.2. > > > IIRC it is possible to install and use several different versions of > > the Xilinx tools if you use make or batch files. > > That's actually what I'm doing now on my Linux build machine; the > different versions of the Xilinx tools seems to all play fairly nicely > there. =A0On my Windows box, versions 11 and higher (FlexLM) get seriousl= y > snippy with one another. > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order Xilinx has been changing how they install their software to make it easier to have multiple versions on Windows machines. Starting with 11.1 (I think) they put each installed version into its own sub- directory under /Xilinx by default. You still need to deal with environment variables. I did this on my machines by replacing the hard coded version in the environment variables with a XIL_VERSION variable. Then I would just change that one when I switched between versions, in this case only running one version at a time. Starting with 12.1, the install no longer sets environment variables. Instead, the entries in the start menu point to a batch file that sets the environment variables for the shell the tools are launched in for that run. I currently have 12.1 and 11.4 running at the same time with out interfering with each other. I have not had any problems related to FlexLM, and in addition to ISE System Edition, I also have ModelSim SE, two versions of HyperLynx and Impulse C all which use FlexLM installed on twenty similar Windows Vista machines using node locked licenses (locked to MAC IDs). I also have a subset of that software running without problems on a few more Windows XP machines that are not similar to the others. I have not tried the floating licenses yet. Your post strongly implies that you are seeing FlexLM problems, is that what you mean when you say the tools get snippy with each other, or did you mean something else? Regards, John McCaskill www.FasterTechnology.com Xilinx Alliance Partner and exclusive Xilinx Authorized Training Provider for eight US states.Article: 148617
Hi Aragorc, You can't set generic parameters for the components in SmartDesign. If you have generic parameters, they have to do that part of the design in HDL and specify any generic parameters in the HDL code. Regards, Joan - you can reach me on Twitter: @Actelcorp or by email at socialmedia@actel.com On Aug 4, 3:20=A0pm, "Aragorc" <Aragorc@n_o_s_p_a_m.hotmail.com> wrote: > Hello > > I need some help for using Actel Libero IDE. > The SmartDesign fonctionnality enable me to design my code as a block > diagramm. > This is a very convenient way to keep global view of my programm. > But I don't know how to set generic parameters with components. I know th= is > is really easy to do with Altera Active HDL, but I can't find the way wit= h > Libero. > Does anyone knows how to use generics with components? > > I hope my question is understable. > Thank you for your help. > +++ > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.comArticle: 148618
All above points are gud. one more point i would like to add. Run Post-Synthesis Simulation or Post-Place-and-Route Simulation on your design (on Xilinx ISE its possible, dont know about other softwares) and check if post-synthesis results are still the same with RTL Simulation Results, if they are not consistent with each other, you need to debug your code again.. if they are consistent, then probablly there are more physical issues as discussed by others regards Ammar >On 8/4/2010 11:10 AM, alessandro.strazzero@gmail.com wrote: > >> With my surprise, the model doesn't work well as in ModelSim and I >> don't understand the >> reasons. >> could you suggest me some guidelines where to search for the >> problems ? > >You might also have a look at the rtl viewer for missing wires or flops. > > -- Mike Treseler > > > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148619
Hello,
For my Masters project, I'm trying to implement a multiplier, and a
MAC where the outputs are calculated per clock cycle and stored in a
text file which can then be used for further processing.
However, both these designs are giving out partial products(I guess
they are partial products) at the output too, before they give the
final result..I've tried changing the codes, changing clock frequency
in testbench etc. but nothing seems to work...
Is there any way to implement a output_ready signal for multipliers/
adders?(I saw a few codes using shifter for rdy, but could not
understand the logic behind it)
I'm using the embedded Mult18X18 in Spartan 3..but do not want to use
the Core generator for MAC(which has a RDY signal) as the code has to
be kept portable.
Code for multiplier is--
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.NUMERIC_STD.ALL;
entity Single_Mul is
Port ( Clk : in STD_LOGIC;
Mul1 : in STD_LOGIC_VECTOR (17 downto 0);
Mul2 : in STD_LOGIC_VECTOR(17 downto 0);
Mul_Res : out STD_LOGIC_VECTOR(35 downto 0));
end Single_Mul;
architecture Behavioral of Single_Mul is
Signal Prod : Signed( 35 downto
0):="000000000000000000000000000000000000";
begin
process(clk)is
begin
if rising_edge(Clk) then
Prod<=signed(Mul1)*signed(Mul2);
end if;
end process;
Prod_Process:Process(prod)
begin
Mul_Res<=STD_LOGIC_VECTOR(Prod);--here I was hoping this process is
invoked only when the --clocked process above is complete...
end process;
end Behavioral;
Code for MAC--
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_STD.all;
entity Mul_Adder is
Port ( MulA : in STD_LOGIC_VECTOR (17 downto 0);
MulB : in STD_LOGIC_VECTOR(17 downto 0);
Multi_Res : in STD_LOGIC_VECTOR(35 downto 0);
MulAdd_Res : out STD_LOGIC_VECTOR(35 downto 0);
Clk : in STD_LOGIC);
end Mul_Adder;
architecture Behavioral of Mul_Adder is
shared variable temp :SIGNED(35 downto
0);--:="000000000000000000000000000000000000";
Signal temp1:SIGNED(35 downto
0):="000000000000000000000000000000000000";
begin
Process(Clk) is
BEGIN
If rising_edge(Clk)
then
temp:=signed(MulA)*signed(MulB);
temp1<=signed(Multi_Res)+temp;
end if;
End Process;
MulAdd_Res_process: Process(temp1)
begin
MulAdd_Res<=STD_LOGIC_VECTOR(temp1);
end Process;
end Behavioral;
Am I doing anything wrong here? Any help in this direction would be
useful
Article: 148620On 7 Aug., 19:14, lastminutepanic <sheetalgandhi...@gmail.com> wrote: > For my Masters project, I'm trying to implement a multiplier, and a > MAC where the outputs are calculated per clock cycle and stored in a > text file which can then be used for further processing. Calculation per clock cycle and storing in file means unnecessary mix of RTL and behavioral in most cases. Per cycle is used for HW, storing in files is pure SW. Are you sure you intend this? > However, both these designs are giving out partial products(I guess > they are partial products) at the output too, before they give the > final result..I've tried changing the codes, changing clock frequency > in testbench etc. but nothing seems to work... Partial products for 12*34 would be 340 and 68. You see intermediate results when not every bit is settled. This means you need to wait until the output is settled. normally you do combinatoric between two register stages and your timing analysis ensures the output is settled before the next clock cycle. But in real hardware you will see some intermediate results even on the output register when having more then one bit. You just need to ensure, that the output settling between first and last bit is small enough for your requirements (often within less than 1 ns). > Is there any way to implement a output_ready signal for multipliers/ > adders?(I saw a few codes using shifter for rdy, but could not > understand the logic behind it) Yes. But I doubt I can teach you this in 2 lines, when you didn't learn this up to now. > library IEEE; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > use IEEE.NUMERIC_STD.ALL; Never mix those two packages without very good reason. It is like left foot on brake an right foot on gas at the same time. > architecture Behavioral of Single_Mul is > Signal Prod : Signed( 35 downto > 0):="000000000000000000000000000000000000"; Initialisations of signals shall be used only with good reason. It masks potential errors. If needed, use (others=>'0') instead of "00..00" > if rising_edge(Clk) then > Prod<=signed(Mul1)*signed(Mul2); > end if; > end process; > > Prod_Process:Process(prod) > begin > > Mul_Res<=STD_LOGIC_VECTOR(Prod);--here I was hoping this process is > invoked only when the --clocked process above is complete... Hopeless. If you move this line between rising_edge(Clk) and end if, you get something like you intended (but one clock cycle latency) regards ThomasArticle: 148621
On 9 Aug., 17:15, Thomas Stanka <usenet_nospam_va...@stanka-web.de> wrote: > > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > use IEEE.NUMERIC_STD.ALL; > > Never mix those two packages without very good reason. =A0It is like > left foot on brake an right foot on gas at the same time. Indeed. Use numeric_std only. > > > architecture Behavioral of Single_Mul is > > Signal Prod : Signed( 35 downto > > 0):=3D"000000000000000000000000000000000000"; > > Initialisations of signals shall be used only with good reason. I don't agree. The initialization should match the hardware. So if you have one of these old fashioned ASIC registers that come up at a random state you initialize them to "U" (which is the default for VHDL) but in modern FPGAs and many ASIC libraries registers have a defined power on state and simulation should reflect that. XST honors the initialization values during synthesis and I expect other tools to do the same. KoljaArticle: 148622
On Aug 9, 3:16=A0pm, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > Initialisations of signals shall be used only with good reason. > > I don't agree. > The initialization should match the hardware. > So if you have one of these old fashioned ASIC registers that come > up at a random state you initialize them to "U" (which is the default > for VHDL) > but in modern FPGAs and many ASIC libraries registers have a defined > power on > state and simulation should reflect that. > Do you think it's still a good idea to have signal initializations to 'match the hardware' in the following contexts as well? - Free running oscillator on the board is input to the FPGA which implies there is no control of the setup/hold time of anything for that very first rising edge of the clock (which then overwrites that initialization anyway)? - Unskilled designer that does not provide any form of hardware reset to their logic. KJArticle: 148623
Hello, Well my code is huge... but the interesting part is.. lets say i have some 10 bit wide signal, and in my logic i clear it when it reaches value 768. Actually its not just signal, its a D flip-flop with a controlling mux, and i load new value or clear it using the Mux... When i was running and synthesizing this code in ISE 9.1 my logic was just fine... but now, with version 10.1 it compiles and synthesizes good... but during debug...i noticed that when that signal reaches value 13... it suddenly goes to 0... (actually it is my FSM which checks if its 768, the through the mux cleares it...and starts whole thing again...) But now, its NOT MY FSM who cleares it before 768...its reset by itself!... very weird... any ideas? p.s. im running same code which compiled and worked well from previous version, without any changes... --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148624
On Aug 9, 10:16=A0pm, "ColdStart" <teslashock@n_o_s_p_a_m.msn.com>
wrote:
> Hello,
>
> Well my code is huge... but the interesting part is.. lets say i have som=
e
> 10 bit wide signal, and in my logic i clear it when it reaches value 768.
>
My reading of what you wrote is that you *asynchronously* clear the 10
bits when those 10 bits happen to reach the value 768. If that's the
case, then you're bound to have trouble.
> Actually its not just signal, its a D flip-flop with a controlling mux, a=
nd
> i load new value or clear it using the Mux...
>
To many uses of the word 'it' and nobody will be clear about just what
'it' is. Less description and more posting of the actual code snippet
would be 10x more useful than what you're trying to describe.
> When i was running and synthesizing this code in ISE 9.1 my logic was jus=
t
> fine... but now, with version 10.1 it compiles and synthesizes good... bu=
t
> during debug...i noticed that when that signal reaches value 13... it
> suddenly goes to 0...
>
Not surprising at all if my first sentence regarding what I think
you're describing is correct.
> (actually it is my FSM which checks if its 768, the through the mux clear=
es
> it...and starts whole thing again...)
>
Starts what whole thing?
> But now, its NOT MY FSM who cleares it before 768...its reset by itself!.=
..
> very weird... any ideas?
>
1. If the logic defining the behavior of the 10 bit thing causes that
10 bit thing to be reset when it reaches a particular value, you've
got some rewriting of the code to do.
2. Could be timing. Have you:
- Setup the timing constraints and run static timing analysis?
Did it pass?
- Is there more than one clock domain in this design?
> p.s. im running same code which compiled and worked well from previous
> version, without any changes...
>
Some things to keep in mind...
- You can't debug a working system. Don't waste time analyzing the
working system, focus on the non-working one as if you didn't know
about the older, working one.
- Sometimes things 'work' although they have latent design issues
still to be uncovered. Whether you should consider yourself 'lucky'
that it was working or 'unfortunate' because you didn't uncover the
problem sooner is up to you to decide.
Feel free to post some actual snippets of code that demonstrate what
you're saying that accurately represent what you're doing. (1)
Kevin Jennings
(1) An example of what I think you're describing (which would be a
problem if it is what you have is)
process(clk, clear)
begin
if (clear =3D '1') then
big_sig <=3D (others =3D> '0');
elsif rising_edge(clk) then
big_sig <=3D big_sig + 1;
end if;
end process;
clear <=3D '1' when (big_sig =3D 768) else '0';
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