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
As I know ,in spartan 2e fpga ,There is no bufgmux,and I want to use clock mux in the design,can some give me some advice.If I can use a general mux to mux the two input clock and make the output clock use the global routing resource?Article: 100851
Lars wrote: > You must install the driver for the cable first. See: > http://www.altera.com/support/software/drivers/dri-bb-2k.html > /Lars > Thanks, that what I did. Even though it once was installed. Must have slipped off then. Anyway, it works now, thanks to all. ReneArticle: 100852
Hallo, I would store some variables of my software into lmb memory. I have added a section .lmb using "generate linker script" to the linker. I have added the following lines to my software: #define __lmb__ __attribute__((aligned(32),section(".lmb"))) Xuint16 __lmb__ acq_analog_matrix[32][16]; (a global variable) The software is compiled without reporting errors, but when I load the code into my system it doesn't function. Instead it function correctly in this way: Xuint16 acq_analog_matrix[32][16]; Why can't I store a matrix into lmb bram? Many Thanks MarcoArticle: 100853
Joseph Samson wrote: > I just got off the phone with my webcase CAE. He says that the next > version of PLB_TEMAC (v3) will be released with 8.1 SP2, which was > actually supposed to be today. It has RGMII and other features. I managed to get my webcase CAE to look at MM's webcase answer. They all seem to be in agreement now that RGMII will be included in PLB_TEMAC in the EDK 8.2 SP2 release, which is expected in September 2006. --- Joe Samson Pixel VelocityArticle: 100854
Hi Florian, Do I understand correctly that I need to implement DDR registers missing in the TEMAC core even if I choose the second method (modifying the core)? If that is true then there is actually not much difference between using the design in XAPP692 and modifying the core... Thanks, /MikhailArticle: 100855
All- I had posted before about XST not generating correct netlist for comparisons inside nested loop code within an always block. The code is of this form: always @( a[0], a[1], a[2], ... ) begin for (i=0; i<32; i++) begin for (j=0; j<32; j++) begin if (a[j][4:0] == i) begin if (a[j][28:27] == 2'd2) <-- comparison b1[i][j] = 1'b1; else b2[i][j] = 1'b1; end else begin b1[i][j] = 1'b0; b2[i][j] = 1'b0; end end end end What I found for the following ways to do the innermost comparison: if (a[j][28:27] == 2) <--- crashes XST if (a[j][28:27] == 2'd2) <--- doesn't crash XST, but generates incorrect netlist if (((a[j][28:27] & 32'h03000000) >> 28) = 2) <--- generates correct netlist, works Results were the same whether I used while loops (see XST answer records 22625 and 22066) or used a genvar for the outer loop (outside the always block). This is with XST 7.1i. From the answer records about XST issues with loop code, I might guess this problem could persist a while, possibly through 9.1i or longer. I thought I would put this up for future reference, in case anyone else runs into the same thing. -JeffArticle: 100856
The problem might go away sooner if this was submitted as a web case! I know of *no* authors of EDA tools that want incorrect logic in their code. Usability is one thing, bad results are another. "Jeff Brower" <jbrower@signalogic.com> wrote in message news:1145458398.983530.256720@i40g2000cwc.googlegroups.com... > All- > > I had posted before about XST not generating correct netlist for > comparisons inside nested loop code within an always block. The code > is of this form: > > always @( a[0], a[1], a[2], ... ) begin > > for (i=0; i<32; i++) begin > > for (j=0; j<32; j++) begin > > if (a[j][4:0] == i) begin > > if (a[j][28:27] == 2'd2) <-- comparison > > b1[i][j] = 1'b1; > > else > > b2[i][j] = 1'b1; > end > else begin > b1[i][j] = 1'b0; > b2[i][j] = 1'b0; > end > end > end > end > > What I found for the following ways to do the innermost comparison: > > if (a[j][28:27] == 2) <--- crashes XST > > if (a[j][28:27] == 2'd2) <--- doesn't crash XST, but generates > incorrect netlist > > if (((a[j][28:27] & 32'h03000000) >> 28) = 2) <--- generates correct > netlist, works > > Results were the same whether I used while loops (see XST answer > records 22625 and 22066) or used a genvar for the outer loop (outside > the always block). > > This is with XST 7.1i. From the answer records about XST issues with > loop code, I might guess this problem could persist a while, possibly > through 9.1i or longer. I thought I would put this up for future > reference, in case anyone else runs into the same thing. > > -Jeff >Article: 100857
The DCM output is specified up to 450 MHz. The maximum PowerPC clock is 400 MHz. The "Toggle Frequency (for export control)" is 1050 MHz. Minimum clock period to meet address write cycle time is specified as 1.25 ns (800 MHz). Where do you find 200 MHz as a limit of this silicon from the data sheet? "Ken Reeves" <reeves@beeblebrox.org> wrote in message news:e246e3$ggd$1@news1.cse.ohio-state.edu... > Hi, > > I'd like to know how a manufacturer arrives at the max clock rate of a > particular speed grade of a device? For example, if we have the Xilinx > Virtex-II Pro XC2VP50 FPGA with speed grade 7 parts, how's the max limit > of 200 MHz fixed? If I build a design for which I make sure that all > stages complete under, say 4ns, for the XC2VP50, I would benefit if I can > clock the FPGA at 250 MHz. What issues would prevent a higher clock rate > from being allowed? > > Also, if it's based on various calculations, how do you end up with so > round figures as 200 MHz or 400 MHz? > > Thanks.Article: 100858
Right. In other words, your timespecs will (likely) come off the clock lines so you will want separate clocks. The issue is the IO. Board vendors are starting to get the hang of banking memory IO properly. Most are still clueless about it on other buses. Invariably your IO for the project will overlap banks, leading to conflicts....Article: 100859
Hi Martin thanx a lot for that reply. It was lot useful. i have one more question for you. have created my *.Xdl file and i have and i am actually trying to move the design to a new location. btw i am using a VIRTEXII FPGA. the xdl file read as follows: inst "XLXI_1/counter_out1<3>" "SLICE",placed R2C1 SLICE_X1Y77, so this inst is at row 2 and column 1, i just tried to move to a new location like say same row i.e. row 2 but column 30, and i saved it and tried to convert it back to a *.ncd file. NOW, i am getting some errors while converting back. At the command promt i typed xdl -xdl2ncd <designfile>.xdl <design file>.ncd Is this rite??????? was my changing the places of the inst wrong??? How do we modify the placement...do i have to change the slice location too ... please help me ....i am in dire need to move the design to a new location by modifying the XDL file.Article: 100860
Hi all, I am working with a Xilinx Virtex4 and I have troubles with the "after configuration" state of the FPGA. I search on the Xilinx web site and on the web but the only thing I fond was the module called STARTUP_VIRTEX4 that in my understanding is used only to put the registers in the defaut state but not to determine the initial state. I think that putting initial statements both in the source code or in the constrain file is not a good solution because the project is changing day by day and maintain such a thing does not seem to me really handy. I had some experience with the Spartan3 family and there a module calle ROC was provided in order to tell the implementation software that the initialisation value for all the registers connected to that net was the one those registers were assigned in the rest condition. Does anyone of you know if a way exsists to direclty code in the VHDL the value after configuration? Pushing a button after configuration is possible but no really elegant, so I was wondering if someone knows of a circuit able to generate a reset pulse at power up (after configuration) without knowing the initial status. It will be the best soltution because it would not be FPGA family or technology dependent. Any suggestion is really apprecheated. Regards, AndreaArticle: 100861
Thanks for your response, This code snippet is actually a structural representation of my actual code (which is much more complex). I am experiencing some strange behaviour where although 'input_signal' is only held high for one clock cycle (by another process, but using the same clock) the 'output_signal' is asserted twice, or so it appears. I was wondering if the structure of my code (and my coding style) would cause this situation to occur. It only appears to present itself on 'real-hardware' in the 'simulator' I cannot repeat the strange behaviour. Regards, SimonArticle: 100862
Hi Mikhail, yes, you have to implement the DDR registers. The PLB_TEMAC core includes a PLB to TEMAC interface (PLB-IPIF with FIFO etc and IPIF to TEMAC) and the embedded TEMAC. Now you have to route the signals from the TEMAC to the external PHY by yourself. For this you should read the Virtex4-TEMAC documentation (UG074). Use the PLB_TEMAC to connect the hard TEMAC to the PPC and do the rest yourself. In the UG074 are BUFG used for some CLIENT_TX and CLIENT_RX signals. The BUFGs are not used in the hard_temac core !! Have fun FlorianArticle: 100863
If you're working with XST, you may be able to use initial statements for both simulation *and* synthesis. The only other way to avoid the issues is to go with an asynchronous reset. <sabatini@tiscali.nl> wrote in message news:1145463849.775664.254770@j33g2000cwa.googlegroups.com... > Hi all, > > I am working with a Xilinx Virtex4 and I have troubles with the "after > configuration" state of the FPGA. > > I search on the Xilinx web site and on the web but the only thing I > fond was the module called STARTUP_VIRTEX4 that in my understanding is > used only to put the registers in the defaut state but not to determine > the initial state. > > I think that putting initial statements both in the source code or in > the constrain file is not a good solution because the project is > changing day by day and maintain such a thing does not seem to me > really handy. > > I had some experience with the Spartan3 family and there a module calle > ROC was provided in order to tell the implementation software that the > initialisation value for all the registers connected to that net was > the one those registers were assigned in the rest condition. > > Does anyone of you know if a way exsists to direclty code in the VHDL > the value after configuration? > > Pushing a button after configuration is possible but no really elegant, > so I was wondering if someone knows of a circuit able to generate a > reset pulse at power up (after configuration) without knowing the > initial status. It will be the best soltution because it would not be > FPGA family or technology dependent. > > Any suggestion is really apprecheated. > > Regards, > > AndreaArticle: 100864
Hi Jonh, tanks for your suggestion. I am not using XST but only ISE to generate the bit file and Synopsys FPGA Design compiler to generate the netlist. The asynchronous reset is fine with me expecially if do not have to push a button. Any idea how to implement this? Regards, AndreaArticle: 100865
<simon.stockton@baesystems.com> wrote in message news:1145466216.810985.131360@t31g2000cwb.googlegroups.com... > Thanks for your response, > > This code snippet is actually a structural representation of my actual > code (which is much more complex). I am experiencing some strange > behaviour where although 'input_signal' is only held high for one clock > cycle (by another process, but using the same clock) the > 'output_signal' is asserted twice, or so it appears. I was wondering if > the structure of my code (and my coding style) would cause this > situation to occur. It only appears to present itself on > 'real-hardware' in the 'simulator' I cannot repeat the strange > behaviour. > Hi Simon, Is it in a device with a soft logic analyser available like Chipscope? Are any of the inputs asynchronous to the clock? Cheers, Syms.Article: 100866
Hi everyone, I hope someone @Xilinx will read this. In the new EDK 8.1 the FSL access macros have changed name. And they also introduced _interruptible versions. Theses are defined in ${EDK_HOME}/sw/lib/bsp/standalone_v1_00_a/src/microblaze/mb_interface.h The definitions for getfsl_interruptible and cgetfsl_interruptible are correct. But the ones for putfsl_interruptible and cputfsl_interruptible are incorrect. For example putfsl_interruptible is : #define putfsl_interruptible(val, id) \ asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \ "addic\tr18,r0,0\n\t" \ "bnei\tr18,1b\n" \ : "=d" (val) :: "r18") and it should be : #define putfsl_interruptible(val, id) \ asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \ "addic\tr18,r0,0\n\t" \ "bnei\tr18,1b\n" \ :: "d" (val) : "r18") Obviously val is a input in the case of a 'put' and not an output. Another related question : In my code, when a replace all non _interruptible versions by their _interruptible counter parts, it doesn't behave as excpected anymore ... Does theses version require some hw support ? Sylvain PS: I know I should submit a webcase but when I try to login I just get "Server Error" ... and so I obviously can't even submit a webcase about my problem of being unable to log in into the webcase ...Article: 100867
andrewfelch@gmail.com wrote: > When I switch to optical recognition I will have perhaps 1,000 > reference vectors that will be much smaller, only about 1kilobit each > or so. Since these reference vectors could fit in block ram I could > see 16 terabit per second on that project. If one takes a nanosecond to read a kilobit, that is still only 1 terabit per second. In any case, doing the ands will probably not take much longer than it takes to read the data. Counting the bits is more interesting. Putting the fpga on the front side bus would probably allow a helpful data rate. As you said you were going to try, assembly is a better next choice than an fpga.Article: 100868
Hi, I am just starting to checkout Xilinx 7,1 and its EDK. Running under Solaris 10 I can't launch the GUI, it coredumps. Anyone been using that under Solaris 10 and can help? /michaelArticle: 100869
I would like to disable the input signal keeper on a XC9572 CPLD but the inputs still have the keeper even if the "FLOAT" option is set in the fitter properties JEDEC files are different (1 bit) when keeper or float option is specified but device always has keepers enabled... Do XC9572XLs really have the capability to turn off the input keeper? Where is this documented (not the datasheet...) Peter WallaceArticle: 100870
Dioptre wrote: > Question: Is it possible / feasible / easy to implement a design on an > FPGA such that > two or more circuits are guaranteed not to share any part of the FPGA > hardware? > > The application is this: I have redundant inputs and redundant outputs > - I wish to use a single FPGA, but maintain the redundancy. I am > concerned only with safety, not with reliability, so complete failure > of the FPGA is not an issue. > > My concern is that the two circuits, whilst specified independently, > would end up optimised and sharing gates, thus compromising the > independence. The technical answer is yes. The practical answer is no. Seriously, think about it for a moment. In the meantime, let me relay a problem that afflicts new PLC (programmable logic controller) designers. In many safety critical systems, there is a master stop switch. This switch *should* stop everything where it is, and leave the system in a safe place. Many people often make this master stop switch an input to their PLC - which works great, until the PLC fails - which happens. The bottom line? The system is only as safe as the PLC - and there are situations where the system will not react as expected. Likewise, placing redundant designs in a single FPGA will likely suffice for most situations, but should either the support components or the FPGA itself crap out - both designs will fail. If this is a space application, where you may have to deal with SEU events (single event upsets) or worse - consider that a single bit change to the FPGA configuration memory may render the entire device unusable, especially if that bit controls a common element. Long story short, if it is critical - use two parts. If it's life-safety (or space qualified) critical - use three parts and implement a voting scheme. If it's not - just do the design once, in a single FPGA. As long as you have done the correct job in design, odds are fairly good that both will fail in the same manner, at approximately the same time, anyway. (this is what happened to a particularly unlucky Arianne rocket - look it up) If you really want to get retentive, you can do what NASA does (or used to do). Implement the function independently three different times to the same spec - then load the three implementations on to three separate parts. This way, the odds of all three failing at the same time are exceedingly low, and you can tolerate a lot more.Article: 100871
Could you be a bit more specific? Are you attempting to configure from the micro, or just make the FPGA a peripheral? If you just need a peripheral, simply write one - and connect the signals appropriately. From this perspective, the FPGA is just a blank sheet on which you can build circuits. All that is critical is to define the pinout and connect the micro accordingly. If you are looking to configure the FPGA from the micro as well, then you will need to consult the datasheet for the device you are using. Most have a parallel configuration port option (given enough pins), but you will need to configure the device to accept data that way - usually by means of mode select pins. For Altera parts, you can use a .ttf (tabular text format) and just feed the data in bytewise. You will need to connect the 8-bit configuration port to the micro's data bus, and connect the control signals appropriately. It's actually not that bad, and I've seen designs where FPGA's get configured over PCI by way of a PCI -> LB bridge chip.Article: 100872
As a former senior design project lab instructor, let me give you a few hints. 1) Make it simple. You don't have time to debug unnecessary crap. I've seen great projects that would have earned A's had they been completed - yet get C's because the students bit off more than they could chew, and got stuck debugging unnecessary problems. This is an important skill later, as well. Nobody wants to explain that a product will ship late because some engineers "toy" broke something, and forced a long, unnecessary, and expensive debugging cycle. 2) If you don't absolutely need it - don't worry about it. That's why I asked if you really need configurable logic. FPGA's are neat, and in some cases, invaluable - but if all you are doing is controlling a serial device and an LCD - unnecessary. They add complexity, and design time, without offering much in return. On the other hand, they do allow you to do true system-on-a-chip designs. The S3 or S3E starter kits are great for this, because they are entirely self-contained. I would suggest you look at opencores.org. I am using the Plasma MIPS processor in a design of my own, and you can cross-compile with either Windows or *nix based compilers. If you have (or can get) the full Xilinx EDK, Microblaze is a very nice soft processor, and you get a full development environment. Keep in mind, an FPGA will present an additional set of design problems on top of all the others you have. Specifically, you must make sure your design can make timing, your pin-out must match what is expected by the rest of the system, and code debugging becomes more complex than just "recompiling". You now have to generate a new bitstream, and upload it to the target everytime you make a change. (EDK helps a lot here) 3) C#, to my knowledge, is limited to a very few platforms, and as a previous poster noted, none of them are microcontrollers. I'm not anti-Microsoft, but .net was not intended for embedded computing. If you can't use a PC (running Windows) as your controller, and must use a micro, I would use C and/or assembly. It gets the job done, and you can get free cross compilers to almost any platform known to man. Yes, you can write C programs targetting Atari 400/800's and Commodore 64's if that's your thing. 4) If you are planning to graduate this Spring, I would suggest hoofing it. Debugging always takes an order of magnitude more than the initial development - no matter how careful you were in the design phase. Something about Murphy's law I think... Finally, if you are set on using an FPGA, consider using finite state machines (FSM) instead of a full processor. You would be amazed at how much you can accomplish. I've done designs with reasonably complex user interfaces with little more than an FSM and a ROM. Your application practically screams for a well-designed FSM. Remember, software is essentially a FSM executed on another FSM (the CPU). Any software function, including recursion, can be fully reproduced in hardware. The opposite is not true.Article: 100873
bjzhangwn wrote: > As I know ,in spartan 2e fpga ,There is no bufgmux,and I want to use > clock mux in the design,can some give me some advice.If I can use a > general mux to mux the two input clock and make the output clock use > the global routing resource? This is the second time I can refer someone to Peter's nice article, "Six Easy Pieces": Search the Xilinx website, when you find it, look at the sixth piece. Here's a code snippet: Clk_A_Proc: process( Clk_A ) begin if FALLING_EDGE( Clk_A ) then Use_Clk_A <= not Select_Clk_B and not Use_Clk_B; end if; end process; Clk_B_Proc: process( Clk_B ) if FALLING_EDGE( Clk_B ) then Use_Clk_B <= Select_Clk_B and not Use_Clk_A; end if; end process; Clock <= ( Clk_A and Use_Clk_A ) or ( Clk_B and Use_Clk_B ); Plug this into a design, set the device to an S3E, and the tools do what you expect. Be careful of the final routing though...if the routing of either of the Use_Clk_X signals exceeds half a clock period, you could generate a glitch when switching.Article: 100874
Michael Hennebry wrote: > Putting the fpga on the front side bus > would probably allow a helpful data rate. Speaking of which, has anyone come out with a commercial version of Pilchard or TKDM type approach yet? Simple, I think elegant, idea: FPGA(s) on a DIMM stick that sits in main memory.
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