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
On 13 Sep 2006 03:29:29 -0700, "Peter Kampmann" <peter.kampmann@googlemail.com> wrote: >Hi, A further comment on my previous post... Putting this... > Number of BRAMs: 78 out of 136 57% together with this... >ERROR:Place:665 - The design has 106 block-RAM components of which 4 >block-RAM components require the adjacent > multiplier site to remain empty. suggests you can parallel two 18-wide BRAMs to make a 36-wide BRAM for the 4 problem BRAMs, without running out of resources. - BrianArticle: 108576
Peter Kampmann wrote: > Hi, > > after Developing connection my custom peripheral to the OPB-Bus, I > tried to download my Design to the FPGA. > The custom Design including the Bus needs 87% of my FPGA (Virtex2Pro30 > 896-7). > The device summary is as follows: > > =========================================================== > > Device utilization summary: > --------------------------- > > Selected Device : 2vp30ff896-7 > > Number of Slices: 12131 out of 13696 88% > Number of Slice Flip Flops: 14472 out of 27392 52% > Number of 4 input LUTs: 15191 out of 27392 55% > Number of IOs: 109 > Number of bonded IOBs: 96 out of 556 17% > Number of BRAMs: 78 out of 136 57% > Number of MULT18X18s: 136 out of 136 100% > Number of GCLKs: 1 out of 16 6% > > > =========================================================== > > In the next step, I tried to download the design. > > In my first try, the system consisted of the following parts: > > In my last try, of consists of the following parts: > > http://www.student.uni-oldenburg.de/peter.kampmann/deuI.jpg > http://www.student.uni-oldenburg.de/peter.kampmann/report_DEUI.pdf > > > the Synthesis of the design aborts with the following message: > > ERROR:Place:665 - The design has 106 block-RAM components of which 4 > block-RAM components require the adjacent > multiplier site to remain empty. This is because certain input pins > of adjacent block-RAM and multiplier sites share > routing ressources. In addition, the design has 136 multiplier > components. Therefore, the design would require a > total of 140 multiplier sites on the device. The current device has > only 136 multiplier sites. > > After that, I removed the RS232 from the design and tried again. > > Finally, I moved all components from the PLB to the OPB Bus, where > possible, that gives: > > http://www.student.uni-oldenburg.de/peter.kampmann/deuIII.jpg > http://www.student.uni-oldenburg.de/peter.kampmann/report_DEU.pdf > > And the following error: > > ERROR:Place:665 - The design has 84 block-RAM components of which 2 > block-RAM components require the adjacent multiplier > site to remain empty. This is because certain input pins of > adjacent block-RAM and multiplier sites share routing > ressources. In addition, the design has 136 multiplier components. > Therefore, the design would require a total of 138 > multiplier sites on the device. The current device has only 136 > multiplier sites. > > Has anybody experienced the same problem? Does anyone have a solution > for that, without building a smaller design? The FPGA has 136 > multipliers and 136 Block RAMs, does that mean you cannot use all > multipliers when you design a complete system with PowerPCs etc? > The issue is that when the block Ram is used in the 36 bit wide mode it shares pins with the multiplier (IIRC it is the high 18 bits of the BRAM DO are connected to one of the multiplier inputs), thus if the multiplier is used it must take its inputs from those block ram bits. You can avoid the issue by using a narrower aspect ratio for the BRAM (18,9,4,2, or 1 bit wide), or by not using all the multiplier sites (each multiplier is co-located with a BRAM). Since you require all the multipliers on the chip, you don't have the luxury of being able to use the BRAM in the 36 bit wide mode. you have two choices: 1) change your BRAM usage to avoid using the 36 bit wide mode of the BRAMs, or 2) eliminate some of the multipliers from the design by either time sharing other multipliers or by performing some of the multiplies in the fabric rather than with the embedded multipliers.Article: 108577
skyworld wrote: > Hi Ray & Kolja, > thanks for your reply. The advice is very helpful, but the question is > that the code is for ASIC design and is frozen. I just migate the code > to FPGA to check its function. So do you have any suggestion on how to > setup constraints? something like DC do in ASIC design? thanks > Did you not put any timing constraints on the design? If so, then you need to review the user's guide on timing constraints and add them to the design. Note however, that timing constraints just tell the tools what you require the timing to be. It doesn't mean the tools will be able to place and route the design to meet your timing constraints. If you already have the timing constraints on the design, then you need to start digging into the design to find out where the failing paths are, and address those paths either by relaxing constraints, hand placing and possibly hand routing them, or by revising the logic to reduce the number of combinatorial levels the signal has to pass between flip-flops. For high fanout signals, you can also consider duplicating logic to reduce the fanout. In general, you are not going to achieve ASIC speeds with an FPGA without carefully crafting your design to the FPGA architecture. An ASIC design dropped into an FPGA with no changes will never meet the potential performance of the ASIC implementation of the design if done on a feature size similar to that of the FPGA.Article: 108578
Ray Andraka wrote: > > ...thus if the > multiplier is used it must take its inputs from those block ram bits. > To clarify: if both the block RAM and multiplier are used at a site, and the block Ram has 36 bit outputs, the multiplier must use those outputs as its input.Article: 108579
David Ashley wrote: > Weng Tianxiang wrote: > > David Ashley wrote: > > > >>Weng Tianxiang wrote: > >> > >>>Hi Daniel, > >>>It is very interesting to learn there is a ring bus structure over > >>>there. > >> > >>Weng, > >> > >>It occured to me that your circuit was identical to the ring > >>buffer one. N users each had a fifo going to the DDR. > >>Then there was one stream coming out of the DDR, so > >>it's (N+1) interfaces. But then you said each user needs > >>its own fifo so it can store + forward data from the DDR. > >>So you've got 2N interfaces effectively. The new fifos are > >>just moved into the user's realm and not part of the DDR > >>controller. > >> > >>My point is the same circuitry exists in both cases. You've > >>just exercised some creative accounting :). > >> > >>-Dave > >> > >>-- > >>David Ashley http://www.xdr.com/dash > >>Embedded linux, device drivers, system architecture > > > > > > HI David, > > I am really surprised to what you recognized. > > > > They are totally different. > > > > This is ring topology: > > > > A --> B --> C --> D > > ^ -----------------------| > > > > This is my topoloty: > > > > A --> E --> | --> A > > B --> E --> | --> B > > C --> E --> | --> C > > D --> E --> | --> D > > > > Weng > > > > Right, ok I didn't understand what ring topology was, sorry. > Snip out my reference to ring topology then but my observation > still goes. E is the DDR, right? Anyway you don't show the > fifos associated with ABCD on the right side. > > -Dave > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architecture Hi David, Yes, every component has a read fifo internally. I don't have to show them in the interface. They are not the part of interface. 1. We are talking about how to implement a multiple DDR controller interface; 2. We are talking about its performance efficiency; 3. We are talking about the minimum number of wires of the DDR controller interface; An individual read fifo for each component will give designers a freedon or a buffer to isolate many differences among DDR and compoments. For example, they may use different clocks, different data rate and so on. WengArticle: 108580
Ray, Your response below appears to imply that you have been able to achieve ASIC performance with FPGA implementations. As this goes against my intuition, could you elaborate? I assume you would be comparing an ASIC implemented in a larger, slower process to an FPGA in the state-of-the-art process? Thank you, Stephen > In general, you are not going to achieve > ASIC speeds with an FPGA without carefully crafting your design to the > FPGA architecture. An ASIC design dropped into an FPGA with no changes > will never meet the potential performance of the ASIC implementation of > the design if done on a feature size similar to that of the FPGA.Article: 108581
Jacques GENIN wrote: > Gabor a =E9crit : > > It's been a long time since we've used 4000 series parts here, > > but we have had a similar issue with Virtex (original) parts. It > > turns out the bad lots were counterfeit. If you got these parts > > from a franchised Xilinx distributor, your parts are most likely > > not counterfeit. In that case I would suggest attempting to > > return them and to open a web case with Xilinx as well. > > > > However if you got them through a part > > broker, which is common for older parts like these, it is > > possible that they are counterfeit. In the case of the > > counterfeit Virtex parts, the actual parts were marked > > with the Xilinx part number and logo, but the chips inside > > had no resemblance at all to the part marked, and in fact > > caused a direct short from +3.3V to ground on our boards. > > > > Good Luck, > > Gabor > > > Effectively, I got those parts from a broker. > I do not think they are counterfeit because they have a part > of the behaviour I expect from "good" components. They do > not seem to be dumb stones in packages. > Anyway, I'm OK : when buying obsolete parts, one must be > more and more carefull ! > > Thanks, anyhow > Jacques Woww...I 've seen virtex parts doing the configuration properly in master mode (CCLK, PGM, INIT...), but DONE never goes high, it took a while to figure out the part was a counterfeit, cost for corrections is far beyond one could expect :(Article: 108582
Jim, Thanks. I remember back when Virtex first offered SSTL and HSTL we had to look around for devices that did this. I am happy to see a whole line of components spring up to support termination voltage busses. We certainly were not first with SSTL and HSTL interfaces, but 9 years ago it just had not taken off yet, I suspect. The term DDR regulator seems to have come from DDR-SRAM being the number one reason to need a regulator that can both source, and sink current. Austin Jim Granville wrote: > Austin Lesea wrote: > >> Jim, >> >> DDR regulator? I must have missed this new term. >> >> Do you have an example?| > > Sure, Go to Linear or Maxim's web sites, and search for DDR regulator. > These target the Vtt terminations on DDR memory busses, and they can > source and sink current. > > -jg >Article: 108583
"DONE did not go high" Could also describe a piece of toast at the end of a JTAG cable. The I package in question could be completely empty, and, yes, "DONE did not go high" There is a sequence of events (CCLK, INIT, etc.) that should be present if the part is really a Xilinx part inside that package. Please provide more information, as "DONE did not go high" doesn't provide enough information to even tell if there is a die in the package. I am sure there are those here on the newsgroup who would like to help, but with just the one symptom, everyone is placing bets the part is counterfeit. Sorry. AustinArticle: 108584
I think the linux kernel file (zmage.elf) which is precompiled (ie if you are using reference design ) contains the ethernet in it. SO if you want to work without ethernet you will have to disable the ethernet option in the linux config file,recompile the kernel and also remove it from the mhs/mss file and then try. Anonymous wrote: > I have a memec mini-module board. I've loaded and run the reference design > and I am able to boot all the way into the Linux prompt. However, my design > doesn't need ethernet so I deleted it. Now it doesn't even run the code in > the initial BRAM successfully. I've traced the code and it seems to end up > at the _exit crt function. (BTW, is there a way to get the c symbols in > XMD?) > > Any ideas why removing the ethernet would clobber the system to the point > that even the uart doesn't work? > > Thanks, > ClarkArticle: 108585
To cut a long story short, Xilinx is the one to blame. Their pthread_mutex_lock implementation in xilkernel_v3 is somewhat broken. If a mutex is locked by thread 1 when pthread_mutex_lock() is called by thread 2, thread 2 is suspended and added to the wait queue of the mutex. On release of the mutex the first thread in the wait queue is unblocked. Depending on the time slice thread 1 may run on and aquire the mutex since it is free. This happens in my case due to the tight loop. Now comes thread 2 into action. It's unblocked and thus set to run when the time slice of thread 1 ends. Thread 2 is blocked inside pthread_mutex_lock_basic(), defined in "EDK\sw\lib\bsp\xilkernel_v3_00_a\src\src\ipc\mutex.c", by a call to process_block(). When process_block() returns thread 2 aquires the mutex _without_ checking if it is really free, which is not true in my case since thread 1 has locked it immediately after freeing it. Best regards AndreasArticle: 108586
rickman wrote: >>http://en.wikipedia.org/wiki/Shift_Register_Look_Up_Table >... > How do you get the wikipedia corrected? I clicked the link on the SRL > page to the FPGA page and then on through to the partial > re-configuration page at... > > http://en.wikipedia.org/wiki/Partial_re-configuration > > This page says "In current versions of software, Xilinx supports > partial reconfiguration on Spartan 3...". I am pretty certain that > this is not supported in Spartan 3. I have requested that this be > supported in Spartan 3 since they came out and I still have not seen it > appear. > > Am I wrong, or is the wikipedia wrong? > You can correct the wikipedia article yourself, click on the "Edit this page" tab on the top, make your edits, then save. You might want to create an account if you don't have one already. There is no guarantee wikipedia is correct. Witness the fact that I only learned what an SRL was last night, and here I am writing an "encyclopedia" article on the subject :). The thing was, I went to wikipedia first to find SRL, and nothing came up. So I went to google, found a page, then went back and updated wikipedia, in case other people turn there first. That's what wikipedia's all about. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108587
stephen.craven@gmail.com wrote: > Ray, > > Your response below appears to imply that you have been able to achieve > ASIC performance with FPGA implementations. As this goes against my > intuition, could you elaborate? > > I assume you would be comparing an ASIC implemented in a larger, slower > process to an FPGA in the state-of-the-art process? > > Thank you, > Stephen > What I am trying to say is that the performance will fall far short of the ASIC if you try to use the same design with an FPGA as you use with the ASIC. The only way to get even close is to design to the FPGA architecture, and that means heavily pipelining the design, limiting logic ore or less to 4 input functions, and taking advantage of FPGA macro structures like the memory and multipliers. The majority of the ASIC designs I have seen have far too few pipeline stages to be able to use the FPGA near the top of its performance envelope. Many if not most of those have targetted ASIC performance that is within the means of an FPGA of similar vintage, but that won't happen without completely redesigning it with the FPGA architecture in mind.Article: 108588
Hi, does anyone have any experience of using xilinx platform studio with the following characteristics 1) microblazed based platform 2) one of the peripherals exists only in edif format, as this block was built using handel C previously (thus I have create the necessary mpd files and bbd files in the data directory of the pcores/<peripheral>/data directory how to do VHDL behavioral simulation with such a scenario using modelsim in such a case? does anyone have any example or any knowhow on how to do this? thanks! ChristopherArticle: 108589
Hi,
I've some trouble with NIOS II PIO interrupts and need some help.
The pio port is configured as follows:
Width= 2 bits
Both input and output ports (not tri-state)
Synchronously capture: Rising Edge
IRQ= edge sensitiv
I dont want to use HAL to keep the code size small, that's why I use
alt_main.
static void AudioCodecInISR(void* context, alt_u32 id) {
volatile int inChL = 0;
inChL = IORD_ALTERA_AVALON_PIO_EDGE_CAP(CodecIRQRegBase);
/* Reset the Button's edge capture register. */
IOWR_ALTERA_AVALON_PIO_EDGE_CAP(CodecIRQRegBase, 0);
}
int main (void) __attribute__ ((weak, alias ("alt_main")));
int alt_main (void)
{
void * context;
alt_irq_init(ALT_IRQ_BASE);
IOWR_ALTERA_AVALON_PIO_IRQ_MASK(CodecIRQRegBase, 0x3);
/* Reset the Button's edge capture register. */
IOWR_ALTERA_AVALON_PIO_EDGE_CAP(CodecIRQRegBase, 0x0);
/* Register the interrupt handler. */
alt_irq_register( CodecIRQRegBase, context, AudioCodecInISR );
while (1)
{
}
return 0;
}
Does anybody has any clue where the bug is?
Thanks,
Horst
Article: 108590Brian Drummond wrote: > On 12 Sep 2006 07:45:19 -0700, "kits59@gmail.com" <kits59@gmail.com> > wrote: > > > > >Brian Drummond wrote: > >> On 11 Sep 2006 12:58:57 -0700, "kits59@gmail.com" <kits59@gmail.com> > >> wrote: > >> > > >> Something else must be the problem : check clocks, resets, is your bRAM > >> mapped to cover the boot address (FFFFFFFC for the PPC405), there are no > >> "Warning: unbound component" messages when ModelSim loads the design > >> etc? > >> > >> - Brian > > > >The funny thing that I should probably state is that the entire system > >was simulating perfectly fine under EDK 7.2. The bRAM is mapped > >correctly so that the starting values are where they expect them to be. > > Ah. > > I haven't tried porting a design to 8.x from 7.x yet, but had bad > experiences running 6.x projects under 7.1. > > Did you use the "import earlier version" tool when moving to 8.1? > Did it ask you if you wanted to upgrade any cores, or report that it had > to, because some of the earlier cores were no longer supported? > Sometimes the updated cores are incompatible with the earlier ones, and > the innocuous "update" breaks the design in hard-to-find ways. > > I confess I never DID get to the bottom of one such "upgrade" on a > demonstration app, I didn't find out exactly how the upgrade had broken > it - it was easier to simply ask the vendor to supply a 7.1 version! > > If I HAD to fix it, I'd try using the original cores, or (if not > possible) I'd check the logs of the first build in 8.1, and check all > port connections, and see if the register definitions (and address maps) > had changed between versions... > > I wonder if Xilinx have fixed the "import from earlier versions" > problems with EDK 8.1? Anyone have experience of this transition? > > - Brian It did attempt to update some cores. I'm investigating the changes now. I'm also trying to get my hands on the 7.2 installation disks I was using so that I can attempt the problem there. But that doesn't mean that I'm giving up on getting 8.1 to simulate correctly. JonArticle: 108591
Austin Lesea wrote: > "DONE did not go high" > > Could also describe a piece of toast at the end of a JTAG cable. > Agree, those pieces could be anthing, but working > The I package in question could be completely empty, and, yes, > > "DONE did not go high" > > There is a sequence of events (CCLK, INIT, etc.) that should be present > if the part is really a Xilinx part inside that package. > I wouldn't buy that. However, one might be thinking why did they bother to have an "intelligent statemachine" in a fake? > Please provide more information, as "DONE did not go high" doesn't > provide enough information to even tell if there is a die in the package. > Sorry, no more information > I am sure there are those here on the newsgroup who would like to help, > but with just the one symptom, everyone is placing bets the part is > counterfeit. > You bet.Article: 108592
Pardon the newbie question, but I'm still at sea in Xilinx's tools. I have an EDK license, and a BaseX ISE license, but I'm looking for a development flow [for instructional purposes] that will use just Webpack in conjunction with open-source tools. Sure, I can build gcc & gdb for uBlaze, but what connectivity options are there to get gdb talking over JTAG to the core? If the method will work with Xilinx's USB JTAG adapter, that is gravy - but not necessary. It's acceptable to buy or make a third-party adapter.Article: 108593
Thanks all for your replies. Peter, Austin, I will be using voltage regualtors from national semiconducter and so I posted my question to one of the national engineers. I posted a quoted passage from xilinx database answer which says that xilinx recommends a parallel resistor for power regualtion purposes. He recommended using a diode rather than a parallel resistor and he doesnt understand why xilinx prefers using a parallel resistor, although a diode is more power efficient. You can read our conversition here: http://wwwd.national.com/national/powermb.nsf/8178b1c14b1e9b6b8525624f0062f= e9f/ea579526ac937540882571e60071f60a?OpenDocument Peter Alfke schrieb: > The resistor value is a compromise between speed and current forced > into the pin. > The driver output impedance is probably below 10 Ohm. With a total load > capacitance of 30 pF that creates an output time constant of 300 ps, > pretty fast. > With a 1 kilohm resistor directly attached to the FPGA pin, that pin > has a capacitance of 10 pF. Times 1 kilohm that is a time constant of > 10 ns, which is too slow in some cases, but probably fast enough in > your case. And it limits the per-pin current forced into the FPGA to > about 2 mA. > > The regulator usually cannot absorb current flowing backwards, so you > must make sure that the current maintains its direction when the > largest number of interfaces is High. > When the current reverses direction, the voltage would rise, and might > destroy the FPGA (unlikely, but possible). > These are some of the nitty-gritty considerations that pay your (and > my) salary... > Peter Alfke > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > jidan1@hotmail.com wrote: > > Thank you Austin and Peter for you replies. > > > > I still have 2 questions > > > > 1)a) So, you suggest using a 1k ohm serial resistor to interface the 5V > > signal to 2.5V input. May I know how you came to this number? > > b) For the 5V -> 3.3V interface, xilinx application suggests a > > Rser=3D300Ohm. Should I also replace this with a Rser=3D1kohm? > > > > 2)Why use a parralell resistor to the voltage regulator and waste power > > to handle the reverse current. Why not just add a reverse biased > > schotkey diode from the output to the input of the voltage regulator? > > > > Austin Lesea schrieb: > > > > > jidan, > > > > > > Peter makes a good point: if the resistance is too low, then you are > > > injecting current into the 2.5 V supply, and it may begin to drift up, > > > and out of regulation. > > > > > > One way to avoid that, and to avoid any rail supply being driven above > > > its intended output, is to balance the injected current with a simple > > > resistor across the power supply, present all the time. > > > > > > So, if you think you will inject 100 mA worst case into the 2.5V rail, > > > then plan on having a load of at least 100 mA on the 2.5 volt supply. > > > If the 2.5 volt supply has a minimum normal load of 50 mA, then you w= ill > > > need an additional 50 mA load, just in case. 2.5V/.05=3D50 ohms (51 = ohms, > > > nearest 5% value). > > > > > > All this because regulators are good at regulating a load, but incapa= ble > > > of regulating when you source current into there output terminal. > > > > > > Austin > > > > > > Peter Alfke wrote: > > > > jidan1@hotmail.com wrote: > > > >> Hi, > > > >> > > > >> I would like to configure a spartan-3 FPGA with an 5V CMOS > > > >> microcontroller. I have read xilinx database answer regarding how = to > > > >> make 3.3V I/O input pins 5V tolerant with a serial resistor (300Oh= m). > > > >> > > > >> 1) Can also the confg. dedicated pins made 5V tolerant through a s= erial > > > >> resistor although they are powered from 2.5V? (I calculated this a= n I > > > >> came to Rser=3D220OHM) > > > >> 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's is > > > >> (VCCO=3D3.3V) is 2.9V. Do I need level-shifters to drive my =B5C? = If yes, > > > >> what IC's would you recommend? > > > >> > > > >> Regarding 1: > > > > I would use 1 kilohm. No need to push more current than necessary. > > > > Regarding 2: > > > > You quote worst-case numbers that assum lowest Vcc on the FPGA and > > > > higest possible Vcc on the uP. > > > > Keep the FPGA fed with at least 3.2 V, and you will see that same > > > > voltage on the output (this is CMOS !), and keep the uP Vcc slightly > > > > below 5V. > > > > But you will not have much noise immunity. > > > > Peter Alfke > > > >Article: 108594
Hello, On Mon, Sep 11, 2006 at 12:10:38PM -0700, funkrhythm wrote: > PORT hard_temac_0_GMII_TX_EN_0_pin = hard_temac_0_GMII_TX_EN_0, DIR = > O xst complained when trying to set the direction to output for mii, so I set it to input. Now I want to try sending some IP packets accross the wire, but both xilnet and lwip insist on using either opb_ethernet or -lite. Are there any adjusted versions for one of these? -- GPG-Key 1024D/E32C4F4B | www.gnupg.org | http://enigmail.mozdev.org Fingerprint = 9C03 86B5 CA59 F7A3 D976 AD2C 02D6 ED21 E32C 4F4B Mit freundlichen Gruessen | Kun afablaj salutoj (www.esperanto.org) May the tux be with you. :wq 73Article: 108595
I'm not sure that you get what is going on with the parallel resistor. When the input is driven above the rated voltage of the input, the clamp diodes pass current to the Vccio pin. This current should not be allowed to flow back to the power converter, not because it may damage the power converter, but because a rise in the Vccio voltage may damage the FPGA. Adding a diode across the regulator only clamps the voltage to the INPUT voltage of the regulator and depending on that voltage level may not protect the FPGA at all. Xilinx has no way of knowing what voltage you are feeding to your voltage regulator input, so they can't recommend the parallel diode as a general method of dealing with this current from the IOs. If the diode works for your design with your regulator voltages, then you should be ok. But be sure to check the voltages all around and that it will not exceed any of the ratings on the FPGA or the regulator. BTW, what happens to the input voltage to the regulator if current flows back to that input? The current ultimately has to find a path to ground. If the input source can not handle the reverse current then you have not solved the problem. jidan1@hotmail.com wrote: > Thanks all for your replies. > Peter, Austin, > > I will be using voltage regualtors from national semiconducter and so I > posted my question to one of the national engineers. I posted a quoted > passage from xilinx database answer which says that xilinx recommends a > parallel resistor for power regualtion purposes. He recommended using a > diode rather than a parallel resistor and he doesnt understand why > xilinx prefers using a parallel resistor, although a diode is more > power efficient. > You can read our conversition here: > http://wwwd.national.com/national/powermb.nsf/8178b1c14b1e9b6b8525624f006= 2fe9f/ea579526ac937540882571e60071f60a?OpenDocument > > > Peter Alfke schrieb: > > > The resistor value is a compromise between speed and current forced > > into the pin. > > The driver output impedance is probably below 10 Ohm. With a total load > > capacitance of 30 pF that creates an output time constant of 300 ps, > > pretty fast. > > With a 1 kilohm resistor directly attached to the FPGA pin, that pin > > has a capacitance of 10 pF. Times 1 kilohm that is a time constant of > > 10 ns, which is too slow in some cases, but probably fast enough in > > your case. And it limits the per-pin current forced into the FPGA to > > about 2 mA. > > > > The regulator usually cannot absorb current flowing backwards, so you > > must make sure that the current maintains its direction when the > > largest number of interfaces is High. > > When the current reverses direction, the voltage would rise, and might > > destroy the FPGA (unlikely, but possible). > > These are some of the nitty-gritty considerations that pay your (and > > my) salary... > > Peter Alfke > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > jidan1@hotmail.com wrote: > > > Thank you Austin and Peter for you replies. > > > > > > I still have 2 questions > > > > > > 1)a) So, you suggest using a 1k ohm serial resistor to interface the = 5V > > > signal to 2.5V input. May I know how you came to this number? > > > b) For the 5V -> 3.3V interface, xilinx application suggests a > > > Rser=3D300Ohm. Should I also replace this with a Rser=3D1kohm? > > > > > > 2)Why use a parralell resistor to the voltage regulator and waste pow= er > > > to handle the reverse current. Why not just add a reverse biased > > > schotkey diode from the output to the input of the voltage regulator? > > > > > > Austin Lesea schrieb: > > > > > > > jidan, > > > > > > > > Peter makes a good point: if the resistance is too low, then you a= re > > > > injecting current into the 2.5 V supply, and it may begin to drift = up, > > > > and out of regulation. > > > > > > > > One way to avoid that, and to avoid any rail supply being driven ab= ove > > > > its intended output, is to balance the injected current with a simp= le > > > > resistor across the power supply, present all the time. > > > > > > > > So, if you think you will inject 100 mA worst case into the 2.5V ra= il, > > > > then plan on having a load of at least 100 mA on the 2.5 volt suppl= y=2E > > > > If the 2.5 volt supply has a minimum normal load of 50 mA, then you= will > > > > need an additional 50 mA load, just in case. 2.5V/.05=3D50 ohms (5= 1 ohms, > > > > nearest 5% value). > > > > > > > > All this because regulators are good at regulating a load, but inca= pable > > > > of regulating when you source current into there output terminal. > > > > > > > > Austin > > > > > > > > Peter Alfke wrote: > > > > > jidan1@hotmail.com wrote: > > > > >> Hi, > > > > >> > > > > >> I would like to configure a spartan-3 FPGA with an 5V CMOS > > > > >> microcontroller. I have read xilinx database answer regarding ho= w to > > > > >> make 3.3V I/O input pins 5V tolerant with a serial resistor (300= Ohm). > > > > >> > > > > >> 1) Can also the confg. dedicated pins made 5V tolerant through a= serial > > > > >> resistor although they are powered from 2.5V? (I calculated this= an I > > > > >> came to Rser=3D220OHM) > > > > >> 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's = is > > > > >> (VCCO=3D3.3V) is 2.9V. Do I need level-shifters to drive my =B5C= ? If yes, > > > > >> what IC's would you recommend? > > > > >> > > > > >> Regarding 1: > > > > > I would use 1 kilohm. No need to push more current than necessary. > > > > > Regarding 2: > > > > > You quote worst-case numbers that assum lowest Vcc on the FPGA and > > > > > higest possible Vcc on the uP. > > > > > Keep the FPGA fed with at least 3.2 V, and you will see that same > > > > > voltage on the output (this is CMOS !), and keep the uP Vcc sligh= tly > > > > > below 5V. > > > > > But you will not have much noise immunity. > > > > > Peter Alfke > > > > >Article: 108596
JJ, most voltage regulator can only drive current into the load. They cannot regulate the voltage when the current flows"backwards" into the regulator. (But, as mentioned, there are some "DDR" regulators that can source and sink,) Yhe National guy looked at this as a regulator protection question, and answered accordingly. He did not understand the real issue, that we need to prevent the regulator output from going higher than specified, even when the current is reversed. The primitive cure is a bleeding resistor to ground, as Austin suggested. A more sophisticated solution is a "bidirectional" regulator, apparently called DDR regulator as described in this thread. If you have a EE degree, this should really be clear by now... Peter Alfke, Xilinx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D jidan1@hotmail.com wrote: > Thanks all for your replies. > Peter, Austin, > > I will be using voltage regualtors from national semiconducter and so I > posted my question to one of the national engineers. I posted a quoted > passage from xilinx database answer which says that xilinx recommends a > parallel resistor for power regualtion purposes. He recommended using a > diode rather than a parallel resistor and he doesnt understand why > xilinx prefers using a parallel resistor, although a diode is more > power efficient. > You can read our conversition here: > http://wwwd.national.com/national/powermb.nsf/8178b1c14b1e9b6b8525624f006= 2fe9f/ea579526ac937540882571e60071f60a?OpenDocument > > > Peter Alfke schrieb: > > > The resistor value is a compromise between speed and current forced > > into the pin. > > The driver output impedance is probably below 10 Ohm. With a total load > > capacitance of 30 pF that creates an output time constant of 300 ps, > > pretty fast. > > With a 1 kilohm resistor directly attached to the FPGA pin, that pin > > has a capacitance of 10 pF. Times 1 kilohm that is a time constant of > > 10 ns, which is too slow in some cases, but probably fast enough in > > your case. And it limits the per-pin current forced into the FPGA to > > about 2 mA. > > > > The regulator usually cannot absorb current flowing backwards, so you > > must make sure that the current maintains its direction when the > > largest number of interfaces is High. > > When the current reverses direction, the voltage would rise, and might > > destroy the FPGA (unlikely, but possible). > > These are some of the nitty-gritty considerations that pay your (and > > my) salary... > > Peter Alfke > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > jidan1@hotmail.com wrote: > > > Thank you Austin and Peter for you replies. > > > > > > I still have 2 questions > > > > > > 1)a) So, you suggest using a 1k ohm serial resistor to interface the = 5V > > > signal to 2.5V input. May I know how you came to this number? > > > b) For the 5V -> 3.3V interface, xilinx application suggests a > > > Rser=3D300Ohm. Should I also replace this with a Rser=3D1kohm? > > > > > > 2)Why use a parralell resistor to the voltage regulator and waste pow= er > > > to handle the reverse current. Why not just add a reverse biased > > > schotkey diode from the output to the input of the voltage regulator? > > > > > > Austin Lesea schrieb: > > > > > > > jidan, > > > > > > > > Peter makes a good point: if the resistance is too low, then you a= re > > > > injecting current into the 2.5 V supply, and it may begin to drift = up, > > > > and out of regulation. > > > > > > > > One way to avoid that, and to avoid any rail supply being driven ab= ove > > > > its intended output, is to balance the injected current with a simp= le > > > > resistor across the power supply, present all the time. > > > > > > > > So, if you think you will inject 100 mA worst case into the 2.5V ra= il, > > > > then plan on having a load of at least 100 mA on the 2.5 volt suppl= y=2E > > > > If the 2.5 volt supply has a minimum normal load of 50 mA, then you= will > > > > need an additional 50 mA load, just in case. 2.5V/.05=3D50 ohms (5= 1 ohms, > > > > nearest 5% value). > > > > > > > > All this because regulators are good at regulating a load, but inca= pable > > > > of regulating when you source current into there output terminal. > > > > > > > > Austin > > > > > > > > Peter Alfke wrote: > > > > > jidan1@hotmail.com wrote: > > > > >> Hi, > > > > >> > > > > >> I would like to configure a spartan-3 FPGA with an 5V CMOS > > > > >> microcontroller. I have read xilinx database answer regarding ho= w to > > > > >> make 3.3V I/O input pins 5V tolerant with a serial resistor (300= Ohm). > > > > >> > > > > >> 1) Can also the confg. dedicated pins made 5V tolerant through a= serial > > > > >> resistor although they are powered from 2.5V? (I calculated this= an I > > > > >> came to Rser=3D220OHM) > > > > >> 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's = is > > > > >> (VCCO=3D3.3V) is 2.9V. Do I need level-shifters to drive my =B5C= ? If yes, > > > > >> what IC's would you recommend? > > > > >> > > > > >> Regarding 1: > > > > > I would use 1 kilohm. No need to push more current than necessary. > > > > > Regarding 2: > > > > > You quote worst-case numbers that assum lowest Vcc on the FPGA and > > > > > higest possible Vcc on the uP. > > > > > Keep the FPGA fed with at least 3.2 V, and you will see that same > > > > > voltage on the output (this is CMOS !), and keep the uP Vcc sligh= tly > > > > > below 5V. > > > > > But you will not have much noise immunity. > > > > > Peter Alfke > > > > >Article: 108597
<zwsdotcom@gmail.com> schrieb im Newsbeitrag news:1158166558.646779.276900@e63g2000cwd.googlegroups.com... > Pardon the newbie question, but I'm still at sea in Xilinx's tools. > > I have an EDK license, and a BaseX ISE license, but I'm looking for a > development flow [for instructional purposes] that will use just > Webpack in conjunction with open-source tools. > > Sure, I can build gcc & gdb for uBlaze, but what connectivity options > are there to get gdb talking over JTAG to the core? > > If the method will work with Xilinx's USB JTAG adapter, that is gravy - > but not necessary. It's acceptable to buy or make a third-party adapter. > MicroBlaze itself can only be used as per license agreement, eg you must own EDK copy in order to use Microblaze. so if you want to go around and use it without the license then you can only use some of the 3 availabe microblaze open-source clones. none of them has any jtag debugging included so you are limited to init the brams with data2mem tool, and then optionally with custom tool. as of debugging you may get it going by having some gdb-stub in the microblaze clone system and writing your own gdb server AnttiArticle: 108598
Andreas, It is indeed a bug. Thanks for taking the time to track this. I have attached a naive fix (which will not avoid starvation). The fix should appear in EDK 9.1i. thanks, Vasanth "Andreas Hofmann" <ahofmann@ti.cs.uni-frankfurt.de> wrote in message news:ee98h5$hiu$1@tantalos.rbi.informatik.uni-frankfurt.de... > To cut a long story short, Xilinx is the one to blame. Their > pthread_mutex_lock implementation in xilkernel_v3 is somewhat broken. > > If a mutex is locked by thread 1 when pthread_mutex_lock() is called by > thread 2, thread 2 is suspended and added to the wait queue of the > mutex. On release of the mutex the first thread in the wait queue is > unblocked. Depending on the time slice thread 1 may run on and aquire > the mutex since it is free. This happens in my case due to the tight loop. > > Now comes thread 2 into action. It's unblocked and thus set to run when > the time slice of thread 1 ends. Thread 2 is blocked inside > pthread_mutex_lock_basic(), defined in > "EDK\sw\lib\bsp\xilkernel_v3_00_a\src\src\ipc\mutex.c", by a call to > process_block(). When process_block() returns thread 2 aquires the mutex > _without_ checking if it is really free, which is not true in my case > since thread 1 has locked it immediately after freeing it. > > Best regards > AndreasArticle: 108599
Hello, currently I try to install the Platform cable USB under Linux. The machine is a Core 2 Duo E6600 with an Intel 795XBX-based board. I use Centos4.4/i386 (so something similar like RHEL4) with ISE 8.1i SP3. The Platform Cable USB is the Low Power version. I compiled the drivers for the 2.6 kernel like described in the Answer Record. I also got the newest firmware (v 1023) from the ftp servers. When I start impact the cable gots recognized. Firmware v. 1023 is loaded from disk (as shown at the console) and auto-recognition also finds my USB Platform Cable. dmesg output seems fine, both kernel modules are loaded. So far so good... But then: Impact then tells that the FW-Version of the Cable is 1023, CPLD version is 0006 and CPLD is 0000. But it wants to update the firmware version in its 10-to-30-minute upgrade-odysse, which is an action I don't understand since the firmware is up to date. This happens all the time I start Impact... After flashing the "new" FW and some cups of coffee later, scanning for the JTAG-Chain on a ML410 takes forever and I usually quit Impact. While scanning, it prints some ...Version 0000... and so on at the console. Anyone got an Idea? Please don't tell to switch to Windows (everything works under XP 32bit, so no bad Cable), since we currently only have XP-x64 for this machine which is not supported by the Xilinx-Tools... Christian.
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