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
One more thing, did you terminate the clock signal at the ADC clock receiver? The ADC doesn't have on board termination from what I see on the datasheet.Article: 139326
On Mar 26, 2:22=A0am, Moazzam wrote: > [...] =A0I don't think that there is any ICAP > in Spartan-3 FPGA. My impression is that the chip itself does have an ICAP block but that there are problems with it do the Xilinx tools don't allow it to be used. In any case, in practice it is not an option. > The only available option is through the JTAG > interface. You could also use the slave parallel or serial programming modes by connecting these ports to other FPGA pins that would could be accessed by the Microblaze processor. The complication would be dealing with the initial configuration, which would have to come through the same port. > I learnt from a post on this group that Spartan-3 may > exhibit some glitchy behaviour during the process of dynamic > reconfiguration, so it is not recommended for partially reconfigurable > designs. There is contradictory information about this on the web, so I don't know what to think. This software tool handles partial reconfiguration on both the Virtex II (and Pro) and the Spartan 3: http://www.recobus.de/ -- JecelArticle: 139327
Here is a sample code, I want to know what should I put in the third line of code in place of X , to read 10 int data from a file stored on sysace flash memory. It is assumed that int is 4 byte long. Should it be 10 since there are 10 integer data, or should it be 40 since there are 40 character data?? Please help int numread; unsigned int readBuffer[10] numread = sysace_fread((char*)readBuffer, 1, X , fptr);Article: 139328
mopra wrote: > Here is a sample code, I want to know what should I put in the third > line of code in place of X , to read 10 int data from a file stored on > sysace flash memory. It is assumed that int is 4 byte long. Should it > be 10 since there are 10 integer data, or should it be 40 since there > are 40 character data?? Please help > > > int numread; > unsigned int readBuffer[10] > numread = sysace_fread((char*)readBuffer, 1, X , fptr); > From the EDK xilfatfs documentation Parameters buffer is a pre allocated buffer that is passed in to this procedure, and is used to return the characters read from the device. size is restricted to 1. count is the number of characters to be read. file is the file handle returned by sysace_fopen. So it's the number of characters, Alan -- Alan Fitch Senior Consultant Doulos – Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.Article: 139329
Hi, Question 1 : I made an EDK design based on Xilinx's microblaze processor. Now i want to use that design as a sub system in a Top VHDL design in ISE. I know it is possible to import the system.xps file and instancite it within the ISE project. I want to know about your ways and methodes to do that. (Importing XPS file , system_stub .. ?) Question 2 : Assuming i succeeded importing the design, I will then use it as a component in a top module Vhdl file alongside other components. Then i will be able to generate the bitstream file of the whole design. My question is: How can i initialize Brams to make them contain the .elf software file in that bitstream file before downloading it in the FPGA. Best regards, Hassen.Article: 139330
On Mar 26, 9:24=A0am, whygee <why...@yg.yg> wrote: > Hello, > > I think that KJ has some valid points, though > they could be stated more clearly. > I'm not in the automotive branch but I know that today, > automakers don't want stock, they work with very short > supplies to reduce costs and risks. > > Hence auto parts makers don't work with a visibility > of more than months, sometimes weeks, > and volumes below the 10K units range. > Too low and short for ASICs, > a fundry needs 6 to 12 weeks at the very least. > > Furthermore, what if a critical element has a bug > that causes accidents ? Does the part maker remakes > masks, then makes new PCBs for the chip ? No. > Recall all the driving units in auto repair shops, > plug a probe on the FPGA and that's all. > It does not make a big difference, which in fact makes > a big difference for the parts maker that > won't have to finance and build new PCB modules wich contains > more than a single $2 chip on it. The issue of supply applies to *any* component in an auto. An ASIC is no different than a brake caliper or a piston ring. The supply does not need to be predicted any better than other parts. As to recalls, bugs in an automotive product are just too expensive to allow if at all possible. The real cost in a recall is the recall itself. When was the last time you put your car in the shop and the labor costs were not the biggest part of the bill? Even if they replace a wiperblade at the dealer it costs you an arm and a leg. Recalls are very infrequent by necessity. That is why auto makers spend a lot of time and money on getting it right the first time. ASICs fit that model very well since *no one* wants to have to pay to redesign one. So a lot of effort has been put into making sure that the ASIC design process allows for getting them right the first time. That is one of the big advantages of prototyping with FPGAs. You have all the flexibility of the FPGA when the design might change and later, once the initial production is underway and the design is proven in the field, the ASIC can be designed in giving the lowest product cost as mandated by high volume manufacturing. > rickman wrote: > > My "opinions" are factual as far as I can tell. =A0Perhaps we have not > > explored all the details, but the economics are clear. > > but incomplete, you only accounted for 1 part of a larger assembly. > and in cars, ASICs are not socketed... > > > Unless the cost is nearly zero, as is the case of having your FPGA > > vendor provide you with an ASIC based on the FPGA bit file. =A0If you > > buy a minimum quantity, they will not charge NRE at all. =A0Your only > > expense is in discussing this with your management and getting a > > signoff. =A0So if you are talking about a product in *high volume* > > production, the trade off is trivial. > > however, high volume is not the norm anymore, as this means huge stocks > and investments that nobody wants to do anymore. And with the current > crisis, no accountant will hear your argument : they will prefer to pay > a bit more per unit, just to not have to buy huge quantities of stuff tha= t they > have no assurance to resell to the automaker... > And by the time you have sold the last ASICs of your stock, > your product is already in rev.2 or 3. Why does high volume require huge stocks and investments? You don't have to buy a million ASIC devices when you place your first order. They are supplied JIT (just in time) as is everything else in the auto industry these days. Your logic here is very out of date with technology and practice. > IMHO the problem is not FPGA but ASICs : > too slow to build, too expensive and too large volumes > for today's markets, despite technical advantages. You have ignored most of what I have written. The development time issue is dealt with by using FPGAs in development and initial production. To say they are "expensive" is ignoring the facts. ASICs have high NRE and low recurring costs. In high volume manufacturing recurring costs dominate by a factor of millions. The technical advantages of ASICs are minimal with today's semiconductor technology. There are not many problems that can't be solved by FPGAs. The only issue is the 2 to 10 times higher unit cost. > > The FPGA companies have explored pretty > > much every single one and have shouted them from the rooftops. > > And I recently heard Actel claiming success (?) in the automotive branch. > I leave the marketspeech analysis as an exercise, > BUT the fact is that they have (some) happy clients. I have no doubt that there are FPGAs in automobiles. I have stated several times that FPGAs will be used anytime that reconfigurability is important. They will also be used any time the volumes are not so high. My point is that because they are not used where the volumes *are* high, the automotive market is not a primary market for FPGA makers. The end result is that FPGA technology is not steered in the direction that optimizes these parts for automotive use. That is the initial point that started this debate of auto use. > > =A0But few auto products ever need upgraded hardware. > > Now think about the Pentium FDIV bug in your brake or injection system. > Think accidents, lawsuits, huge costs for recalling all the cars > and changing the critical element. > Given the complexity and stakes, I believe that the decision > to use FPGA in certain places is not stupid for some bosses. > If the dev team ever tell the CEO that there is this option > (which does not necessarily happens). ***EXACTLY***!!! If they give these issues the attention they deserve they will make sure the bugs are not there in the first place. The cost of fixing a bug like this is virtually nothing compared to the potential cost from liability. Using FPGAs does nothing to prevent the accidents or injury, they do nothing to prevent or mitigate the lawsuits. Using FPGA does little to reduce the expense of a recall. > > It just does not make sense to leave money laying on the > > table. =A0No CEO would do that. > > The CEO may have constraints that you don't know, like time, > availability, projected and actual shipped quantities, whatever... > It depends on a many more parameters than only the unit price > in huge quantities. I remember discussing flying saucers when I was in school. I would present the facts at hand about how the claimed saucers do things that are impossible by the laws of physics as we know them. One of the responses would be that maybe we don't know about the part of the universe they were from or that they discovered things we don't know. Sure, anything is possible, in theory. But unless some facts are presented to show that saucers were real, why should we assume that everything we know is wrong and little green men are watching us? If the CEO has facts at hand that mitigate the cost reduction possible with ASICs, then they will make the decision to stick with FPGAs. I have already stated several times that one clear reason to use FPGAs in volume is when the reconfigurability is important to the product. The quantities shipped are the main qualification stated, so I don't understand what you mean by that. Otherwise, I don't know of any examples of FPGAs being used in large volumes in autos. So I don't see any reason why the FPGA companies will be targeting product development toward auto usage... and I don't believe in flying saucers either. If Martin won't tell us why his company wants to use FPGAs instead of ASICs, then maybe he can at least come back whey they have shipped 250,000 units of a single product and tell us if they are still sticking with FPGAs instead of an ASIC. RickArticle: 139331
On Mar 26, 5:07=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > rickman <gnu...@gmail.com> writes: > > > You miss the point. =A0Flash micros are in production products because > > there is very little price differential with metal layer ROM devices. > > Otherwise the ROM parts would "abound" in high volume products. > > Yes. =A0That wasn't always the case. =A0Things develop. I don't know what you mean by that. Of course they develop. That is why the ROM parts have little price advantage and are not used nearly as often not... flash developed and dropped tremendously in price. If FPGAs find a way to drop in price to a point where there is little cost advantage of using an ASIC, then even in high volume applications the FPGAs will be used. But so far they are still 10x larger and several times more in price than ASICs. > >> By the time these driver assistance features are on the *really* > >> high-volume vehicles FPGAs will be even cheaper than they are now. > > > Yes, and the bean counters at every company will be beating you > > mercilessly to cut every penny from the cost. =A0When you are facing th= e > > loss of a $10M contract because you need to cut the cost by another > > $1, the decision will be made to go with an ASIC. =A0How else are you > > going to cut the cost of this product otherwise? > > > You can say you "know what you are doing", but the economics are what > > they are. =A0If your company sells a high volume product using an FPGA > > instead of an ASIC, when you don't need reconfigurability, you are > > leaving money on the table. =A0Not many CEOs like that idea. > > > Is there some rational for not designing an ASIC for a high volume > > product that is out of development and meets all specs? =A0Don't tell m= e > > you are doing it, tell me *why* you are doing it. =A0Companies make > > mistakes all the time. =A0I would like to know the reason for this > > decision or if it is just a temporary choice and will change as the > > volumes increase. > > I think KJ wrote quite nicely why I'm not going to explain all that in > a public forum - sorry! =A0(And I don't do the lottery, so that's not > likely to change :) I understand. But until I see a product shipping a million units with FPGAs that is not using their reconfigurability as an important feature, I won't believe that any company would ignore a few million dollars that could be had by simply asking the FPGA vendor for their equivalent ASIC device. Enough said? RickArticle: 139332
On Mar 26, 10:08=A0am, VAX9...@gmail.com wrote: > On Mar 20, 7:14=A0pm, James Harris <james.harri...@googlemail.com> > wrote: > > > I have been reportingspamon other groups and, after a long time, the > > senders Google accounts were removed. I think it took about four to > > eight weeks. I send this to reassure that they do seem to take notice > > eventually but patience is required. > > As of today, it seems Google is taking action. The board is much > cleaner now. They seem to have made is easier to report spam as well. A link is provided under "More Options" and the default checkbox is SPAM. All I have to do is to type "spam" in the description and it is accepted. I seem to recall that it used to be a much bigger PITA to report spam. RickArticle: 139333
On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez <pabloalvarezsanchez@gmail.com> wrote: >Hi, > >For several reasons a need very low jitter on some of my outputs. I >was thinking of using LVDS for my I/Os and of course I do not consider >using a clock manager. Do you have an idea of the order of magnitude >of jitter one can get? What fpga would you recomend for a low cost >small design? > >Cheers > >Pablo Here's a signal that has made three independent non-trivial in/out passes through a Spartan3, plus passed through six external SSI CMOS chips. Total jitter of that whole chain is below 20 ps RMS. ftp://jjlarkin.lmi.net/Jitter3.jpg We were fairly impressed. Spartans are like having a few thousand 10KH ECL gates on a $20 chip. JohnArticle: 139334
Can I read from a file as well as write when using sysace functions when accessing data from flash memory. Regards Mohit PrakashArticle: 139335
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com... > On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez > <pabloalvarezsanchez@gmail.com> wrote: > >>Hi, >> >>For several reasons a need very low jitter on some of my outputs. I >>was thinking of using LVDS for my I/Os and of course I do not consider >>using a clock manager. Do you have an idea of the order of magnitude >>of jitter one can get? What fpga would you recomend for a low cost >>small design? >> >>Cheers >> >>Pablo > > > Here's a signal that has made three independent non-trivial in/out > passes through a Spartan3, plus passed through six external SSI CMOS > chips. Total jitter of that whole chain is below 20 ps RMS. > > ftp://jjlarkin.lmi.net/Jitter3.jpg > > > We were fairly impressed. Spartans are like having a few thousand 10KH > ECL gates on a $20 chip. > > John > I've just built a fractional-N synthesizer using a Spartan 3. The reference frequency comes from an LVDS-output crystal oscillator. The VCO frequency is fed into the opposite side of the FPGA using an LVDS-output comparator and the (AD9901 style) PFD output from the FPGA to the loop filter is also LVDS on a third physical side. Inside the FPGA, the VCO divider and reference divider are on local clocks confined to small regions around the pads where they enter. BUFGCE primitives are used to gate the clocks so I only send edges over the global clock network when a divider resets. The AD9901 PFD ensures that the VCO and reference divider outputs are 180 degrees out of phase. Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84 CPLD. It worked quite well, but there was some interation between the VCO and reference frequencies which caused integer-N boundary spurs. I see no trace of these spurs on my new Spartan 3 design, and the phase noise is much lower. I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I haven't finished tweaking things yet. They say don't attempt analogue functions in FPGAs; but it seems to work remarkably well in the Spartan 3, which is fully static when I'm not clocking it.Article: 139336
On Thu, 26 Mar 2009 19:34:22 -0000, "Andrew Holme" <ah@nospam.co.uk> wrote: > >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com... >> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez >> <pabloalvarezsanchez@gmail.com> wrote: >> >>>Hi, >>> >>>For several reasons a need very low jitter on some of my outputs. I >>>was thinking of using LVDS for my I/Os and of course I do not consider >>>using a clock manager. Do you have an idea of the order of magnitude >>>of jitter one can get? What fpga would you recomend for a low cost >>>small design? >>> >>>Cheers >>> >>>Pablo >> >> >> Here's a signal that has made three independent non-trivial in/out >> passes through a Spartan3, plus passed through six external SSI CMOS >> chips. Total jitter of that whole chain is below 20 ps RMS. >> >> ftp://jjlarkin.lmi.net/Jitter3.jpg >> >> >> We were fairly impressed. Spartans are like having a few thousand 10KH >> ECL gates on a $20 chip. >> >> John >> > >I've just built a fractional-N synthesizer using a Spartan 3. The reference >frequency comes from an LVDS-output crystal oscillator. The VCO frequency >is fed into the opposite side of the FPGA using an LVDS-output comparator >and the (AD9901 style) PFD output from the FPGA to the loop filter is also >LVDS on a third physical side. > >Inside the FPGA, the VCO divider and reference divider are on local clocks >confined to small regions around the pads where they enter. BUFGCE >primitives are used to gate the clocks so I only send edges over the global >clock network when a divider resets. The AD9901 PFD ensures that the VCO >and reference divider outputs are 180 degrees out of phase. > >Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84 >CPLD. It worked quite well, but there was some interation between the VCO >and reference frequencies which caused integer-N boundary spurs. I see no >trace of these spurs on my new Spartan 3 design, and the phase noise is much >lower. I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I >haven't finished tweaking things yet. > > >They say don't attempt analogue functions in FPGAs; but it seems to work >remarkably well in the Spartan 3, which is fully static when I'm not >clocking it. > > The Spartan LVDS inputs are pretty good r-r comparators. And you can make lots of good, cheap delta-sigma dacs from an FPGA. You can do cool analog things with FPGAs. You can also get into a heap of trouble. JohnArticle: 139337
Moazzam, Spartan 3 does not support dynamic reconfiguration. AustinArticle: 139338
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez
><pabloalvarezsanchez@gmail.com> wrote:
>
>>Hi,
>>
>>For several reasons a need very low jitter on some of my outputs. I
>>was thinking of using LVDS for my I/Os and of course I do not consider
>>using a clock manager. Do you have an idea of the order of magnitude
>>of jitter one can get? What fpga would you recomend for a low cost
>>small design?
>>
>>Cheers
>>
>>Pablo
>
>
>Here's a signal that has made three independent non-trivial in/out
>passes through a Spartan3, plus passed through six external SSI CMOS
>chips. Total jitter of that whole chain is below 20 ps RMS.
>
>ftp://jjlarkin.lmi.net/Jitter3.jpg
I presume this is without routing the clock through the DCM :-)
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 139339On Thu, 26 Mar 2009 23:02:35 GMT, nico@puntnl.niks (Nico Coesel) wrote: >John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >>On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez >><pabloalvarezsanchez@gmail.com> wrote: >> >>>Hi, >>> >>>For several reasons a need very low jitter on some of my outputs. I >>>was thinking of using LVDS for my I/Os and of course I do not consider >>>using a clock manager. Do you have an idea of the order of magnitude >>>of jitter one can get? What fpga would you recomend for a low cost >>>small design? >>> >>>Cheers >>> >>>Pablo >> >> >>Here's a signal that has made three independent non-trivial in/out >>passes through a Spartan3, plus passed through six external SSI CMOS >>chips. Total jitter of that whole chain is below 20 ps RMS. >> >>ftp://jjlarkin.lmi.net/Jitter3.jpg > >I presume this is without routing the clock through the DCM :-) Yes! One of the three FPGA inputs is in fact a global clock, but it's not multiplied or anything. In another mode, we do double a 40 MHz clock to 80 in a DCM. That adds about 80 ps p-p jitter, because it wiggles alternate 80 MHz clock edges. JohnArticle: 139340
<http://www.latticesemi.com/products/developmenthardware/ developmentkits/machxominidevelopmentkit.cfm> On-line price is $59 On Mar 25, 12:35 pm, News123 <news...@free.fr> wrote: > Lattice seems to have several FPGA development kits. > > Do you have by any chance the reference number of your kit or a URL? > > LittleAlex wrote: > > I just got an FPGA development kit from Lattice - 2200 CLB's, USB > > (FX2) Interface, a software starter kit, and an 8-bit embedded > > processor. > > > $75 including tax & Shipping. > > > Software license expires every 6 months; I'm guessing that they will > > renew it. Software is reminiscent of Xilinx back in the ISE-4.2 days > > (clumsy, but functional). The embedded processor (Mico8) looks -very- > > interesting: if I'm seeing things correctly, they chose 'wishbone' for > > their on-chip bus. > > > ALArticle: 139341
> > I looked at the ADC/FPGA interface with a DSO and there are large > over/undershoots which seem to be caused by significant reflections. > Some past posts that might be useful, regarding the use of other high speed LVDS A/D's lacking driver back termination : http://groups.google.com/group/comp.arch.fpga/msg/85db6dc0bca5c0da http://groups.google.com/group/comp.arch.fpga/msg/95809af82ccbb550 http://groups.google.com/group/comp.arch.fpga/msg/5a8720eec942612e The pdf files referenced in the above posts have now moved here: http://fpgastuff.googlepages.com/oldaolfiles ( Last fall, AOL silently axed the ftp space where I'd been stashing examples for the past decade ) BrianArticle: 139342
rickman <gnuarm@gmail.com> writes: <snip> > > Enough said? > > Rick I think so :) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 139343
hassen.karray@gmail.com writes: > Hi, > > Question 1 : I made an EDK design based on Xilinx's microblaze > processor. Now i want to use that design as a sub system in a Top > VHDL design in ISE. I know it is possible to import the system.xps > file and instancite it within the ISE project. I want to know about > your ways and methodes to do that. (Importing XPS file , system_stub > .. ?) I don't use ISE, I use a command-line flow. I've instanced system.vhd in my top level VHDL file, synthesised the whole thing to an EDF file, then my implementation script brings in the NGCs from XPS and the runs a normal place and route flow. > > Question 2 : Assuming i succeeded importing the design, I will then > use it as a component in a top module Vhdl file alongside other > components. Then i will be able to generate the bitstream file of the > whole design. My question is: How can i initialize Brams to make them > contain the .elf software file in that bitstream file before > downloading it in the FPGA. I added : -bmm <path_to_bmmfile> to my NGDBUILD command line -bd <path_to_elf> to my bitgen command line. HTH, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 139344
samece wrote: > hi all, > Is dynamic reconfiguration of microblaze implemented in a Spartan 3 fpga > kit possible? If so may anyone help me in that area. > > Samece, Yes partial self reconfiguration is possible on Spartan-3! Spartan-3 does not provide an ICAP, but you can simply loop back some I/O pins to an external reconfiguration port. I am using an S3 Board from Digilent where you can simply plug some wires in the B1 connector for looping back a PIO port to the select map interface (no soldering required). By the way, Spartan-3AN, Spartan-3A posses an ICAP port. But: A S3 configuration is not simply overwritten, but (CLB-) columnwise deleted (by executing a snowplow command) and then written in a frame by frame manner. Consequently, routing that is carried out in a currently reconfigured CLB-column is completely cut off. This includes also the top/bottom I/O! This is often ambiguously called 'glitch', but this interruption can take thousands of clock cycles. We have a paper on these issues: “A Communication Architecture for Complex Runtime Reconfigurable Systems and its Implementation on Spartan-3 FPGAs.” Can be found on our project website: www.recobus.de There are also some restrictions using Xilinx tools to design runtime reconfigurable systems. This holds true especially for Spartan-3 Devices. Our tool ReCoBus-Builder (also available on the website) is easy to use and provides capabilities not available in the 'normal' PR flow. Drop us a mail, if your Spartan 3 (-E/A/AN) is not in the device list). Regards DirkArticle: 139345
On Mar 27, 1:55=A0pm, Dirk Koch <dirk.k...@cs.fau.de> wrote: > samece wrote: > > hi all, > > Is dynamic reconfiguration of microblaze implemented in a Spartan 3 fpg= a > > kit possible? If so may anyone help me in that area. > > Samece, > Yes partial self reconfiguration is possible on Spartan-3! > Spartan-3 does not provide an ICAP, but you can simply loop > back some I/O pins to an external reconfiguration port. > I am using an S3 Board from Digilent where you can simply > plug some wires in the B1 connector for looping back a PIO > port to the select map interface (no soldering required). > By the way, Spartan-3AN, Spartan-3A posses an ICAP port. > > But: > A S3 configuration is not simply overwritten, but (CLB-) > columnwise deleted (by executing a snowplow command) > and then written in a frame by frame manner. > Consequently, routing that is carried out in a currently > reconfigured CLB-column is completely cut off. > This includes also the top/bottom I/O! > This is often ambiguously called 'glitch', but this > interruption can take thousands of clock cycles. > We have a paper on these issues: > =93A Communication Architecture for Complex Runtime Reconfigurable > Systems and its Implementation on Spartan-3 FPGAs.=94 > Can be found on our project website: > > www.recobus.de > > There are also some restrictions using Xilinx tools > to design runtime reconfigurable systems. This holds true > especially for Spartan-3 Devices. > Our tool ReCoBus-Builder (also available on the website) > is easy to use and provides capabilities not available > in the 'normal' PR flow. > Drop us a mail, if your Spartan 3 (-E/A/AN) is not in the > device list). > > Regards > > Dirk Dirk Recobus website says only Spartan-3 is supported :( I assumed that this means that Spartan-3A is not supported what made me very sad So whats the real story? Spartan 3A are supported or not? AnttiArticle: 139346
On Mar 26, 12:32=A0pm, hassen.kar...@gmail.com wrote: > Hi, > > Question 1 : I made an EDK design based on Xilinx's microblaze > processor. > Now i want to use that design as a sub system in a Top VHDL design in > ISE. > I know it is possible to import the system.xps file and instancite it > within the ISE project. > I want to know about your ways and methodes to do that. (Importing XPS > file , system_stub .. ?) > If you use the ISE GUI, just add the .xmp file to your project. It should be handled correctly. > Question 2 : Assuming i succeeded importing the design, I will then > use it as a component in a top module Vhdl file alongside other > components. Then i will be able to generate the bitstream file of the > whole design. Once you have added the EDK project to ISE, you will be able to click it in the sources view and find its processes in the window below that. Processes include "View HDL Instantiation Template", which is an easy way to slip the design into your top level source code in ISE. > My question is: How can i initialize Brams to make them contain > the .elf software file in that bitstream file before downloading it in > the FPGA. > After you build the ISE project, you will find a process at the end of the processes window titled "Update Bitstream with Processor Data". This process does what you want. It also runs very quickly, taking much less time than "Generate Program File". > Best regards, > Hassen.Article: 139347
Hi, We are working on a project involving the Igloo part from Actel. We have a 20 MHz clock which may present a stable logic state (either '1' or '0') for up to 150 ns. We don't expect this event to occur very often (not more than once per second). We were thinking of using the PLL of the Igloo part to filter out this unnwanted state of the clock. The characteristics of the PLL are up to 45kHz loop bandwidth (seen in the datasheet). We did a test on an Igloo dev kit (icicle) and the Igloo PLL looses lock. The unwanted event is repeated every 3 ms and lasts 150 ns.The loss of lock is very fast and just before the lock comes back the output clock from the PLL disappears for a few hundred ns. How come regarding the characteristics of the PLL ? Any ideas ? Best regards, JFArticle: 139348
On Mar 27, 9:03=A0am, jfh <jfhas...@club-internet.fr> wrote: > Hi, > > We are working on a project involving the Igloo part from Actel. We > have a 20 MHz clock which may present a stable logic state (either '1' > or '0') for up to 150 ns. We don't expect this event to occur very > often (not more than once per second). We were thinking of using the > PLL of the Igloo part to filter out this unnwanted state of the clock. > The characteristics of the PLL are up to 45kHz loop bandwidth (seen in > the datasheet). We did a test on an Igloo dev kit (icicle) and the > Igloo PLL looses lock. The unwanted event is repeated every 3 ms and > lasts 150 ns.The loss of lock is very fast and just before the lock > comes back the output clock from the PLL disappears for a few hundred > ns. How come regarding the characteristics of the PLL ? Any ideas ? > > Best regards, > > JF A standard PLL attempts to lock continuously to the input signal. So even if the clock comes back at the same phase after the event, the PLL will have slewed its VCO significantly during the event, causing the loss of lock. You can try to compensate for this by reducing the filter bandwidth. However if you know when the clock losses will occur the ideal approach is to use a PLL with hold capability, like those used in the AD988x Analog Flat Panel interface chips from Analog Devices. Those PLL's can "coast" during vertical sync, essentially shutting off the feedback loop while the horizontal sync is interrupted. I'm not familiar with the Actel parts, but Lattice FPGA's have external capacitor pins for their PLL's to allow you to reduce the filter bandwidth. Regards, GaborArticle: 139349
Hi i know has been discussed before ;) if we leave out the vendor supplied ones (including open source like mico32) and the large ones, then my current list: Core Datapath width Spartan-3 slices for small SoC (approx, ISE 10.1 results) ZPU 32 1000 C16 16 1000 i8080 8 1000 L8080 8 450 L8080 8 150 + 1 BRAM for microcode ZPU is stack based so most weird, but it has GCC support C16 has its own assembler/compiler/simulator supplied with source code i8080/L8080 are intel 8080 - I assume there is some C compiler available L8080 (lightweight 8080) not sure if it is correct enogh to run c compiler code I wonder if there are better candidates for each bit-width category microblaze clone could be considered for 32, but i would rather leave such clones out from the table Antti
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