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
The following extract from the Virtex 4 RIO user guide states: */Serialization/* */As in Virtex-II Pro X devices, Virtex-4 also serializes and sends the least significant byte first. This is opposite of the format Virtex-II Pro devices used in sending the most significant byte first./* What does this really mean? Are the v2pro and v4 MGT's incompatible because of this? Will it work if the bit order is reversed before sending or after recieving? JasonArticle: 82576
would agree to 90% to what Antti said, but my experience is: if you only need a small amount off all available Slices - means implementations A,B,C,D on their own - the the tools will use more Slices than they would take having a "fully loaded" FPGA. This could be the case here, too: you need 50% of FFs and 70% of LUTs !?! If - and only if - there's the possibility that 'some' ressources could fit into the same Slice, then your complete design will fit... I'd be interested in the outcome of the story ;-) > I checked your domain name ;) well my advice (based on your numbers) is that > you should take larger FPGA didn't get this one... JochenArticle: 82577
In article <y_qdnVg1FKwRfcDfRVn-2w@buckeye-express.com>, abuse@127.0.0.1 says... > James Beck wrote: > > In article <upWdnTeAPOxSqcDfRVn-sA@buckeye-express.com>, abuse@127.0.0.1 > > says... > > > >>praveen.kantharajapura@gmail.com wrote: > >> > >>>Hi all, > >>> > >>>This is a basic qustion regarding SDA and SCL pins. > >>>Since both these pins are bidirectional these should pins need to be > >>>tristated , so that the slave can acknowledge on SDA. > >> > >> > >> No, both pins are not bidirectional. Only the master device drives the SCK > >>line, and all slaves must leave their SCK's as input. > > > > > > Not true, a slave device can extend a cycle through clock stretching and > > the only way to do that is for the slave device to be able to hold the > > clock line low. > > > > http://www.i2c-bus.org/clockstretching/ > > > > Explain that to a Noob. > > Please. > Click on the link please. That's why I included it, or do you mean you don't understand what the link is explaining?Article: 82578
"Gabor" <gabor@alacron.com> wrote in message news:1113420291.866098.167770@o13g2000cwo.googlegroups.com... > Andy Peters wrote: >> I'm sure others have this problem ... >> >> Is there a tool that'll let one view and hopefully print a schematic >> done in the old Xilinx F2.1i schematic tool? The new stuff doesn't >> want to know about the old stuff, and worse is that you can't even >> install 2.1i on an XP machine. (Yeah, that'll teach me to upgrade.) >> >> I don't want to do anything with this schematic other than view it. >> I'm doing a new board sorta based on an old design, and the new > design >> will of course be in VHDL rather than as a schematic. >> >> Ideas? >> >> -a > > I'm running Xilinx Foundation 4.1i on Windows XP (SP1). It will > read (and convert) 2.1i schematics. I also run ISE 6.1i on the > same machine and can switch back and forth (but not run both > simultaneously) by changing the Xilinx environment variable. > Unfortunately Xilinx and Aldec have parted ways, so I don't > know how you can get a copy of foundation 4.1i now if you don't > already have it. > > Version 4.1i also has the ability to output (structural) VHDL > from your schematics, but it's not very readable and you'll need > to be sure your new environment has the equivalent library > components if you want to build from the VHDL. Quite a few of last years and some of this years text books for Digital Design have copies of 4.1 student version. Quite a few are starting to come with student version 6.3. AlexArticle: 82579
Jason, Thanks. That's very clear. Regards, Roger. "jason.stubbs" <jason.stubbs@gmail.com> wrote in message news:1113484269.095171.254220@l41g2000cwc.googlegroups.com... > Roger, > > The way I understood it, and therefore implemented it was to use a > single linear regulator (LT1963) to power all of the RIO on the FPGA. > If the LR is capable of supplying more than one FPGA's RIO circuitry, > then that is acceptable. As long as all of the RIO supply pins are > individually filtered with ferrite beads (and caps when they are not > embedded), this should work. Under no circumstances should a switching > regulator be used to power the RIO. Also, do not use the same LR that > powers RIO to power the internal logic or IO of the FPGA. > > As you said in your earlier post, a linear reg for RIO, and a seperate > reg for everything else. > > Regards > > Jason >Article: 82580
Reinier wrote:
> I'm looking for a freeware or low cost program do document and
> illustrate the signal processing flow in my FPGA design. I'd like to
> use building blocks like adders, multipliers, memory, busses etc. What
> do you guys use to make some nice looking pictures? I don't want to
> spend days learning Corel Draw or something huge like that.
Open office and dia are the best of the free, but
you will spend many days to get the first
"nice looking picture" out of the printer.
Unless you have a paying audience for your artwork,
consider sketching the block diagram in your notebook
and spend the time you save cleaning up your
source code/schematic and simulation testbench.
-- Mike Treseler
Article: 82581Hi All, I couldn't find any information regarding the price of Xilinx's new TMRTool. Does anybody happen to be interested in knowing the price of this tool? Thanks AmrArticle: 82582
Virtex-II Pro and Virtex-4 MGTs are compatible. This note simply refers to the necessary connections of the parallel TX/RX data bus between the fabric and the MGT. Ed jason.stubbs wrote: > The following extract from the Virtex 4 RIO user guide states: > > */Serialization/* > > */As in Virtex-II Pro X devices, Virtex-4 also serializes and sends the > least significant byte first. This is opposite of the format Virtex-II > Pro devices used in sending the most significant byte first./* > > What does this really mean? > > Are the v2pro and v4 MGT's incompatible because of this? > > Will it work if the bit order is reversed before sending or after > recieving? > > Jason >Article: 82583
We would like to announce the availability of our XEM3001 Xilinx Experimentation Module and accompanying FrontPanel software application and programmer's interface. Our unique software differentiates the XEM3001+FrontPanel from other FPGA systems with a comprehensive API available for C++, Java, and Python under both Linux and Windows. Additionally, a DLL version p rovides easy integration into LabVIEW, Matlab, and any number of third- party tools. The FrontPanel API provides a simple but powerful way to communicate between your PC and an FPGA system at high-speed USB 2.0 rates. The business-card sized (3.5" x 2.0") XEM3001 contains a 400,000-gate Spartan-3 (XC3S400-4PQ208) coupled with a Cypress FX2 USB microcontroller running custom firmware to configure and provide PC/FPGA communication. Peripheral items include a Cypress multi-output PLL for clock generation, four pushbuttons, eight LEDs, JTAG pin access, and three 0.1" headers providing over 80 access pins to the FPGA as well as PLL clock pins. The FrontPanel software application unleashes the flexibility and power of the modest XEM3001. In addition to the system and API support listed above, FrontPanel allows FPGA configuration and virtual instrumentation via a simple, human-readable XML file -- nearly eliminating the need for bulky I/O boards with LEDs, hex displays, buttons, and so on. Applications include test fixtures, rapid prototyping, a controller and turnkey USB interface for vendor evaluation boards, turnkey USB/FPGA module for custom OEM products, and a great learning tool for students and hobbyists. We'd like you to visit our website at http://www.opalkelly.com for more information including an online tutorial and a brief Flash demo of the system. The XEM3001 is available now in our online store for $199.95 with domestic and international shipping. Opal Kelly Incorporated Champaign, IL http://www.opalkelly.comArticle: 82584
Thanks for your responces guys, The problem that I have is that I want to use a specific COTS board (for other unrelated reasons) which has the XC2VP30 FPGA on it, so I need to make an educated decision as to whether I can fit ABC & Ds functionality in the XC2VP30 before I commit to buying it. Otherwise everything gets turned on its head and I will have to find another suitable COTS board with a larger FPGA or get one desinged and built (not going to happen says the boss!!) I am thinking that the only way that I can be sure that ABC & D will fit it to bring together the functionalty in a single design and 'compile' it in the ISE tool. Problem with that is that D is specific to the COTS board and I cannot get hold of D before I buy the board, I think this is called a Catch 22 situation. Cheers Simon P.S. I will keep you posted re. outcome. - Didn't understand about domain name either !!!Article: 82585
Clear it may be, correct it's not. Switching regulators are just fine for RIO, as long as you provide for adequate filtering on the supplies. This may be easier than providing adequate heat sinking for linear regulators. As I said earlier. One big switching regulator for all your 2.5V, proper isolation and filtering to each RIO, Vccaux, each Vcco will work just fine. Sorry, I just get worked up when folks say 'under no circumstances'. It may well be that linear regulators are right for your design, but you should consider the options available to you. Cheers, Syms. "Roger" <enquiries@rwconcepts.co.uk> wrote in message news:R2v7e.781$v82.658@newsfe5-gui.ntli.net... > Jason, > > Thanks. That's very clear. > > Regards, > > Roger. > > "jason.stubbs" <jason.stubbs@gmail.com> wrote in message > news:1113484269.095171.254220@l41g2000cwc.googlegroups.com... > > Roger, > > > > The way I understood it, and therefore implemented it was to use a > > single linear regulator (LT1963) to power all of the RIO on the FPGA. > > If the LR is capable of supplying more than one FPGA's RIO circuitry, > > then that is acceptable. As long as all of the RIO supply pins are > > individually filtered with ferrite beads (and caps when they are not > > embedded), this should work. Under no circumstances should a switching > > regulator be used to power the RIO. Also, do not use the same LR that > > powers RIO to power the internal logic or IO of the FPGA. > > > > As you said in your earlier post, a linear reg for RIO, and a seperate > > reg for everything else. > > > > Regards > > > > Jason > > > >Article: 82586
The BlockRAM (RAMB16_S18) is a synchronous memory. Write data presented to the write interface is accepted and written at the clock edge. Read address is presented to the read interface and accepted at the clock edge; only then can the read data come out. You assign the next state through a CLOCKED state machine. The next state is then assigned to a current state through another clocked block. Typically the next state is assigned in a combinatorial block and registered elsewhere OR the current state is updated within the state machine's clocked case statement. You're doing both. Understanding these issues will get you closer to meeting your expectations. "StuartG" <stuartgalt73@yahoo.com.au> wrote in message news:3c3bafe2.0504140130.61febe0f@posting.google.com... > I'm quite new to FPGA/Verilog and I'm not sure if this is the correct > news group to use for this kind of posting - appologies if I've posted > to the wrong place. > > Anyway, I'm having problems using memory within a FSM. I'm currently > using Xilinx ISE for a VirtexII. I'm trying to use the RAMB16_S18 > memory primitive (SelectRAM). > > I've written a short test which writes the sequence 0, 1, 2, 3 .... > 14, 15 to the RAM in one state, then in another it reads it back. > However, I read back the memory as 15, 0, 1, 2 .... 13, 14. I'm > assuming that the 15 in the first read-back element is from the > previous cycle and hence the whole lot is offset due to a clocking > issue. > > I've truncated the code and copied below: <code snipped>Article: 82587
Ed, So, if I send data from a V2Pro to a V4 the MSB is sent first. when the V4 receives and deserializes the data, the MSB of the V2pro becomes the LSB of the V4? And if I send data from a V4 to a V2Pro the LSB is sent first. when the V2Pro receives and deserializes the data, the LSB of the V4 becomes the MSB of the V2Pro? If the bus order is inverted at one end of the link, everything should be OK? JasonArticle: 82588
Hi All, Someone can generate internal clock inside fpga using IO PAD. Smth like this: IBUF_inst: IBUF port map (I => ClkGenExt, O => ClkGenInt); nClkGenInt <= not ClkGenInt; OBUFT_inst: OBUFT port map (I => nClkGenInt, T => '0', O => ClkGenExt); BUFG_inst: BUFG port map (I => ClkGenInt, O => Clk); Even better, we can use UPAD (unbonded IO PAD, that exist almost in every package). Then we don't need to search for unused IO pin on schematic. Clock freq will be aroud 200 MHz and depends mostly on current drive strenth of OBUFT. Of course, it'll drift with temperature, but for some application it can be usefull. For example, we'd like to reuse some old board for new project and we are missing external oscillator. "Bad" clk is still better then nothing. My question is, due to the advanced ChipSync feature of Virtex4, can we create some kind of stable clk generator in IO PAD with flexible freq range? Second question is about UPAD. I didn't find any on V4FX12FG668. Is it due to specific V4 architecture, or it's not present in smallest device of the family?Article: 82589
"teen" <nkishorebabu123@yahoo.com> wrote in message news:<1113473121.057923.282790@l41g2000cwc.googlegroups.com>... > Hai all, > can you plz let me know the different tools used in industry > for ASIC SYNTHESIS Synopsys Physical Compiler. Cadence Encounter. Magma Blast Create. Synplicity Synplify ASIC. Cheers, JonArticle: 82590
David <david.nospam@westcontrol.removethis.com> wrote in message news:<pan.2005.04.14.08.49.05.962000@westcontrol.removethis.com>... > On Wed, 13 Apr 2005 13:00:07 -0700, Shalin Sheth wrote: > > Is this some sort of FAQ reply for people who want more speed from a > MicroBlaze? I've never used a MicroBlaze or Xilinx (I use Nios II on > Altera chips), but it looks like you almost completely missed the OP's > point - he is not (yet !) interested in the quality of code generated by > the compiler, but is suffering from 24-cycle memory reads on the SDRAM. > This is most likely a problem with the SDRAM controller or its setup. > Perhaps you are getting a full bank + row + column select for every > access, although even then 24 cycles is way too long. I don't know what > sort of tools Xilinx has, and how they compare to Altera's SOPC Builder, > but when I had trouble with my SDRAM (it took 2 cycles per access instead > of 1, during bursts), I tested with a simple setup of a Nios II running > from internal FPGA memory, a DMA component (to easily generate burst > sequences), and the SDRAM controller. Using the debugger, I manually set > the DMA to burst read or write and used SignalTap (ChipScope on Xilinx?) > to view what was happening. That way you are simplifying things as much > as possible to concentrate on the specific problem. Probably a whole lot easier just to run an RTL sim, and see the bus activity. Cheers, JonArticle: 82591
Posted on behalf of Marc: Hello Simon, I'm not where I can post a response to your Usenet posting, but I figured I would email you most of my thoughts... The short answer is that it varies too much from design to design to tell you with 100% certainity if it'll fit, without trying it - but in my experience, your design will almost certainly fit. The long answer is that the tools are somewhat lazy, and that laziness makes slice utilization a very poor indicator of how full the design is. Well, it's a poor indicator until you surpass 99%. Then the tools have to actually start working. Until that point, the tools appear to not worry about minimizing slice usage at all (I assume it does this to improve routability). Said another way, IMO, slice counts tend to be a worst-than-worst-case indicator of utilization. If you can add up slice counts and they still don't reach the slice count of the target device, you are almost guaranteed it will fit (the almost is there because nothing is for certain in engineering until its working!). We have MANY designs, from 2VP7 through 2VP50, to 4VLX25. All but one has slice utilizations approaching 99% and we don't have trouble fitting in any of them. The one exception has 86% slices used (for a design with 70% LUTs used). Across the other designs, max LUT utilization is 86%, and max FF utilization is 75%. That I have seen, LUT or FF utilization tends to be a much better indicator of device utilization, and with modern (V2Pro and V4) devices, I don't usually start even thinking about it until LUTs go over 80% or FF's go over 75%. You are well under ALL these numbers (slice, LUT, or FF). Now, all of this assumes your designs are about the size of what they will be when the project is finished. And as others have pointed out, you will need to gauge the likihood (and estimate the possible size) of any future additions or modifications, even unforeseen ones. Have fun, MarcArticle: 82592
Syms, Thanks again for your input. I was actually intending to use linear LDO regulators in actual fact, as power and heat dissipation aren't an issue. However switching vs linear isn't really my query here. Basically, are you saying that I could supply my 4 RIOs, 4 x 3 Vcco pins and 4 Vccaux pins all from the same 2.5V LDO regulator (AVccaux RIO pins suitably filtered with Ferrite beads and capacitors of course)? Thanks, Roger. "Symon" <symon_brewer@hotmail.com> wrote in message news:425e91bf$1@x-privat.org... > Clear it may be, correct it's not. Switching regulators are just fine for > RIO, as long as you provide for adequate filtering on the supplies. This > may > be easier than providing adequate heat sinking for linear regulators. As I > said earlier. One big switching regulator for all your 2.5V, proper > isolation and filtering to each RIO, Vccaux, each Vcco will work just > fine. > Sorry, I just get worked up when folks say 'under no circumstances'. It > may > well be that linear regulators are right for your design, but you should > consider the options available to you. > Cheers, Syms. > > > "Roger" <enquiries@rwconcepts.co.uk> wrote in message > news:R2v7e.781$v82.658@newsfe5-gui.ntli.net... >> Jason, >> >> Thanks. That's very clear. >> >> Regards, >> >> Roger. >> >> "jason.stubbs" <jason.stubbs@gmail.com> wrote in message >> news:1113484269.095171.254220@l41g2000cwc.googlegroups.com... >> > Roger, >> > >> > The way I understood it, and therefore implemented it was to use a >> > single linear regulator (LT1963) to power all of the RIO on the FPGA. >> > If the LR is capable of supplying more than one FPGA's RIO circuitry, >> > then that is acceptable. As long as all of the RIO supply pins are >> > individually filtered with ferrite beads (and caps when they are not >> > embedded), this should work. Under no circumstances should a switching >> > regulator be used to power the RIO. Also, do not use the same LR that >> > powers RIO to power the internal logic or IO of the FPGA. >> > >> > As you said in your earlier post, a linear reg for RIO, and a seperate >> > reg for everything else. >> > >> > Regards >> > >> > Jason >> > >> >> > >Article: 82593
jason.stubbs wrote:
> Ed,
>
> So, if I send data from a V2Pro to a V4 the MSB is sent first. when
> the V4 receives and deserializes the data, the MSB of the V2pro becomes
> the LSB of the V4?
>
> And if I send data from a V4 to a V2Pro the LSB is sent first. when
> the V2Pro receives and deserializes the data, the LSB of the V4 becomes
> the MSB of the V2Pro?
>
> If the bus order is inverted at one end of the link, everything should
> be OK?
>
> Jason
>
No, it's a byte ordering issue, not a bit ordering issue, so
the order that the bytes are sent or received are different.
V-II Pro V-II Pro X/V-4
1 Byte: [7:0] = [7:0]
2 Byte: [15:8][7:0] = [7:0][15:8]
4 Byte: [31:24][23:16][15:8][7:0] = [7:0][15:8][23:16][31:24]
For example if you want to send the following bytes in the
following order:
Byte 1 = 0xDE
Byte 2 = 0xAD
Byte 3 = 0xBE
Byte 4 = 0xEF
In Virtex-II Pro TX/RXDATA[31:0] would be 0xDE_AD_BE_EF
In Virtex-II Pro X TX/RXDATA[31:0] would be 0xEF_BE_AD_BE
In Virtex-4 TX/RXDATA[31:0] would be 0xEF_BE_AD_BE
Ed
Article: 82594If you have linux/unix -- Xfig is the tool..I have never used any other tool after trying it. You have to spend an hr or so learning it.Article: 82595
Over the last couple of weeks I have tried accessing the web site www.free-ip.com and gotten an error message. Is it mirrored someplace else on the web? I am looking for Free-LIB1, a library of NCO, DAC and PWM parameterized cores in VHDL, which was available at www.free-ip.com. Any information is very appreciated.Article: 82596
"Daniel Florin" <florin@primelec.ch> schrieb im Newsbeitrag news:d3ma49$pm4$1@news.hispeed.ch... > Over the last couple of weeks I have tried accessing the web site > www.free-ip.com and gotten an error message. Is it mirrored someplace else > on the web? > > I am looking for Free-LIB1, a library of NCO, DAC and PWM parameterized > cores in VHDL, which was available at www.free-ip.com. > > Any information is very appreciated. > > I think do have a copy off all of them, I was about to add them as 'imported' project at http://gforge.openchip.org but just havent had time yet :( anttiArticle: 82597
Symon please don't take any offense at this, but this information is wrong and would like lead a designer into a serious issue with their high speed serial links if they were to take your advice. For the record, Xilinx design requirements for the RocketIO supplies are that the supply is sourced from a linear regulator with capacitive filtering as noted in the RocketIO user guides. In addition each RocketIO voltage is to be isolated from the supply with a ferrite bead. Depending upon the family and package type you may also need another cap on the FPGA side of the ferrite bead as noted in the RocketIO user guides. Yes, you can have one supply to be the source for all RocketIO and you do not need to have individual regulators for each RocketIO or for each supply type. We make these requirements for your benefit and link quality across all possible conditions. In the real world, I have seen a few cases where switching power supplies have worked. I have also seen far more cases where they are the root of the problem in a totally dead link or have produced a marginal link. Ed Symon wrote: > Clear it may be, correct it's not. Switching regulators are just fine for > RIO, as long as you provide for adequate filtering on the supplies. This may > be easier than providing adequate heat sinking for linear regulators. As I > said earlier. One big switching regulator for all your 2.5V, proper > isolation and filtering to each RIO, Vccaux, each Vcco will work just fine. > Sorry, I just get worked up when folks say 'under no circumstances'. It may > well be that linear regulators are right for your design, but you should > consider the options available to you. > Cheers, Syms. > > > "Roger" <enquiries@rwconcepts.co.uk> wrote in message > news:R2v7e.781$v82.658@newsfe5-gui.ntli.net... > >>Jason, >> >>Thanks. That's very clear. >> >>Regards, >> >>Roger. >> >>"jason.stubbs" <jason.stubbs@gmail.com> wrote in message >>news:1113484269.095171.254220@l41g2000cwc.googlegroups.com... >> >>>Roger, >>> >>>The way I understood it, and therefore implemented it was to use a >>>single linear regulator (LT1963) to power all of the RIO on the FPGA. >>>If the LR is capable of supplying more than one FPGA's RIO circuitry, >>>then that is acceptable. As long as all of the RIO supply pins are >>>individually filtered with ferrite beads (and caps when they are not >>>embedded), this should work. Under no circumstances should a switching >>>regulator be used to power the RIO. Also, do not use the same LR that >>>powers RIO to power the internal logic or IO of the FPGA. >>> >>>As you said in your earlier post, a linear reg for RIO, and a seperate >>>reg for everything else. >>> >>>Regards >>> >>>Jason >>> >> >> > >Article: 82598
Ed, thanks, now its clear!! BTW, do you know when the Aurora core is going to be available for the V4? Cheers JasonArticle: 82599
Hi Roger, Yes, that's what I'm saying. You will need to pay close attention to layout and filtering. I would not lay out the 2.5V as a plane. A plane couples everything together tightly, which isn't what you want in this case. Route it separately, i.e. star format, from your single LDO, through a ferrite and/or a low value resistor (10s of mOhm), then to any bulk capacitance you need, and then on to each of the sections of your circuit where you need 2.5V. When it gets to the destination, make a mini plane, add X5R ceramic decoupling capacitors to taste! The low value series resistor can save the day when you have any low frequency noise that the ferrite can't attenuate. Also, it's good for measuring current. If you find you don't need it, you can always short it out later! For bulk capacitance, I recommend Panasonic's specialty polymer parts. 5mOhm ESR! http://www.panasonic.com/industrial/components/pdf/eef_xr_1201.pdf In my experience, the Xilinx app. notes are written to provide belt and braces solutions. If you do it their way, it'll work, but remember their app. notes are trying to cover a large number of design variations. They can't consider everyone's different requirements, so it's up to the designer to tailor their own solution. Good luck mate, Syms. "Roger" <enquiries@rwconcepts.co.uk> wrote in message news:5xx7e.823$v82.93@newsfe5-gui.ntli.net... > Syms, > > Thanks again for your input. > > I was actually intending to use linear LDO regulators in actual fact, as > power and heat dissipation aren't an issue. However switching vs linear > isn't really my query here. Basically, are you saying that I could supply my > 4 RIOs, 4 x 3 Vcco pins and 4 Vccaux pins all from the same 2.5V LDO > regulator (AVccaux RIO pins suitably filtered with Ferrite beads and > capacitors of course)? > > Thanks, > > Roger.
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