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
Thorsten Trenz <t.trenz@trenz-electronic.de> wrote in message news:<3E1D3327.8000507@trenz-electronic.de>... > Hello, > > Caleb Hess schrieb: > > I think your problem will be that the Trenz board has the transceiver > > mode pin unconnected (mode 1, for differential input on VPO/VMO) while > > Usselmann's design produces single-ended output requiring mode 0. You > > should be able to fix this by adding a kludge wire to ground from pin > > 1 of the PDIUSBP11A chip. > > Don't do this. > > The mode pin is already connected to gnd, so the transceiver runs in > mode 0. Our Documentation is wrong here (thank you for the hint) and we > will fix it. > This applies to both, TE-XC2Se and TE-BL from TE-XC2S. > > However you never need to add a wire to the board, as you can simply > sort out such things in the fpga. > > best regards > Thorsten I assume Frederic is using the USB 1.1 core. Several issues here: 1) The mode pin on the PDIUSBP11A applies to the input to the transceiver only. The receive side does not change it's behavior regardless of the mode pin setting. 2) The USB 1.1 PHY I provide, allows you to select the mode as well. Regardless of the mode setting on the "Trenz" board, you can change the behavior of the RTL by assigning a 1 or 0 to the "phy_tx_mode" input of the phy. I imitate the behavior of the mode pin on the PDIUSBP11A with the "phy_tx_mode" input. You should set the "phy_tx_mode" to the same value as the mode input on the PDIUSBP11A. 3) On the receive side you need at least the "vp" and "vm" signals, you should be able to use "vp" as the "rcv" signal as well. Hope this helps ! Cheers, rudi ------------------------------------------------ www.asics.ws - Solutions for your ASIC needs - FREE IP Cores --> http://www.asics.ws/ <--- ----- ALL SPAM forwarded to: UCE@FTC.GOV -----Article: 51301
Kuan Zhou <zhouk@rpi.edu> wrote: > I am a newbie in FPGA field.I often heard people are talking about the > power consumption of the clock inside FPGA.What's the main issue of it? > Will the clock line consume lots of power? Yes. The problem in fpga is, that the clock is prerouted to every clockable element, where as in ASIC the clocktree will cover only used cells. So your clocktree will be allways be one of the the largest nets independend of your design even if your using only a hand full of FF. In newer fpgas there might be some technics to gate unused parts of the clocktree, to reduce power. Im not sure if Xilix allready gate unused parts of the clocktree, Actel do in its AX technology. bye ThomasArticle: 51302
David wrote: > Hi, > Does anyone know what is the best choice for an fpga developement kit? > Altera offers this kit for University student : > http://www.altera.com/education/univ/kits/unv-kits.html > I wonder if there are other supplier of boards like this (could be Xilinx > too) that could compete with this. Are there third party manufacturer that > are worth considering? All these offers are comparable. The software usually can be downloaded, at least reduced versions. The programmers can be selfbuilt or purchased. And finally you need some chip on a board. While 150$ is not much you should base your preference based on who is going to help you and who is going to introduce you into this technology. A colleague is best as you'll spent a few feeks at least. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 51303
How can I define a RAM type, initialize it, and initialize more than one copy of such type? e.g. typedef rom unsigned 8 Tab[60]; How to initialize above ram and how to use several instances? Thanks in advance.Article: 51305
Hi all, Another approach (if you really want to use FPGA, why not !) you can use the PicoBlaze 8 bit microcontroller which is free on Xilinx web site and throw some lines of assembler language to make the picoblaze to drive the ADC conversion (I'm assuming an external ADC chip) and drive the LCD signals too. By the way there is a nice software simulator (for free) for the "pic-o'blaze" uC. Aurash Jason Berringer wrote: > Hello All, > > I'm working on a rather trivial project for myself to help me get further > acquainted with FPGAs and VHDL in particular (No I'm not a student, I'm > educating myself, or trying to). > > I'm attempting to build a voltmeter. I'm using an ADC tied to the FPGA and > then eventually I want to output the reading on a LCD display also tied to > the FPGA. I'm a little bit confused as to the steps needed to get from one > end to the other. Firstly my values coming from the ADC are binary values, > so I have to convert them to an integer (I'm assuming) then I have to do > some multiplication and division to get my final result which will be a > fixed point number (again an assumption but I want at least one decimal > place for accuracy). Then this value must be converted somehow so that I can > send it to the LCD. I understand a BCD to hex converter for the display, but > how does one convert say a 16 bit fixed point number to a unit that can be > displayed. > > I would appreciate any pointers or useful links that may help me discover > all of the steps required to do this. I know that there are ICs to do this > already out there, but that isn't any fun, and they won't help me learn > anything. > > Thanks for the help (in advance) > > Jason -- __ / /\/\ Aurelian Lazarut \ \ / System Verification Engineer / / \ Xilinx Ireland \_\/\/ phone: 353 01 4032639 fax: 353 01 4640324Article: 51306
The smallest form factor package, I believe, is chip-scale. In FPGAs the smallest form factor you can get is 12mmX12mm (a chip-scale 144 pin package) which is available for XC2V40, 2V80 and 2V250, and XC2S50E, 100E and 200E. All these support LVPECL. The only device which is equal or smaller than 8mmX8mm are the CPLDs in chip-scale but LVPECL is not supported. --Neeraj "Dar Shan" <sanjosem36@yahoo.com> wrote in message news:632ead4c.0301081808.48eccce4@posting.google.com... > Hello! > > Is there a small (no larger than 8mmx8mm) FPGA/EPLD that can support 4 > or more differential LVPECL interfaces? Appreciate if any reader aware > of such an FPGA/EPLD will post a reply with information. > > Regards > DarshanArticle: 51307
Hello, is it possible to create a clock (multipled by 4) CLK_B by an internal PLL/DLL from an internal clock (creating inside the chip) CLK_A which is available on a global clock net and in phase to a data signal. The new clock must be in phase with the clock on the global net. Routing CLK_A to an IO pin and feed it into a PLL/DLL will cause an unpredictable phase. Is there a possible in any available FPGA devices? I would prefer Altera or Xilinx devices. Thanks in advance, ThorstenArticle: 51308
> The MODE pin should be connected to ground. I was looking at the description > of the USB interface in the TE-XC2Se documentation, where the last paragraph > says that the PDIUSBP11A is set to mode 1. I believe this is what Thorsten > is referring to above. OK but on the TE-BL docs of the TE-XC2S kit,the diagram shows clearly that the mode pin is tied to GND. I think the TE-XC2SE is slightly different. I was wondering if Mr Thorsten was referring to another problem. Thank you for all the answers to my question. FB PS: has anyone practically applied the Mr Rudolf Usselmann's opencore USB project in hardware. If so I would be very interested to see how the interfaces map to real hardware, as the project has very few explanations.Article: 51309
Thomas, Yes, we already turn off the unused trees of the global clock network to save power (two generations old now). Doesn't everyone? As for the clock tree's power consumption being a "large part" of the power, I would encourage you to play with the on line power (excel) estimator spreadsheets and see for yourself what power resources use, if you are so inclined. http://www.xilinx.com/support/techsup/powerest/index.htm (For Virtex II Pro, reduce the predictions by 15 % for all core (1.5V features), leave all IOs the same. Add the 6 mW/100 MHz per 405 PPC's, and the mW's (I don't recall the budget) for the MGTs per their speed.) Austin Thomas Stanka wrote: > Kuan Zhou <zhouk@rpi.edu> wrote: > > I am a newbie in FPGA field.I often heard people are talking about the > > power consumption of the clock inside FPGA.What's the main issue of it? > > Will the clock line consume lots of power? > > Yes. The problem in fpga is, that the clock is prerouted to every > clockable element, where as in ASIC the clocktree will cover only used > cells. > So your clocktree will be allways be one of the the largest nets > independend of your design even if your using only a hand full of FF. > In newer fpgas there might be some technics to gate unused parts of > the clocktree, to reduce power. > Im not sure if Xilix allready gate unused parts of the clocktree, > Actel do in its AX technology. > > bye ThomasArticle: 51310
Thorsten, Virtex II and Virtex II Pro both have the DCM which does exactly that. http://www.support.xilinx.com/publications/products/v2pro/handbook/ug012_ug.pdf starting on page 71. Austin Thorsten Bunte wrote: > Hello, > > is it possible to create a clock (multipled by 4) CLK_B by an internal > PLL/DLL from an internal clock (creating inside the chip) CLK_A which is > available on a global clock net and in phase to a data signal. > > The new clock must be in phase with the clock on the global net. > > Routing CLK_A to an IO pin and feed it into a PLL/DLL will cause an > unpredictable phase. > > Is there a possible in any available FPGA devices? I would prefer Altera or > Xilinx devices. > > Thanks in advance, > ThorstenArticle: 51311
In article <d977c973.0301100620.2e178c26@posting.google.com>, Frederic Bastenaire <fba@free.fr> wrote: > >PS: has anyone practically applied the Mr Rudolf Usselmann's opencore >USB project in hardware. >If so I would be very interested to see how the interfaces map to real >hardware, >as the project has very few explanations. I used the USB1.1 core in a project last fall. We only used 2 bulk endpoints so I can't say we tried it out thoroughly. I packaged it as an OPB peripheral for a Microblaze system, and as such it used about 10% of a XCV800 chip. -- Caleb Hess hess@cs.indiana.eduArticle: 51312
Tullio Grassi wrote: > > > yes, you have to create a project for ISE, implement you design and then > run "Generate Post-Place & Route Static Timing". sorry I meant "Generate Post-Place & Route Simulation model" -- Tullio Grassi ====================================== Univ. of Maryland - Dept. of Physics College Park, MD 20742 - US Tel +1 301 405 5970 Fax +1 301 699 9195 ======================================Article: 51313
I've been using synchronous resets in my designs almost exclusively. Since the dedicated reset line is so slow, you would have to design your system to safely start up when there's a clock cycle (more, perhaps) where part of the chip is still in reset while the rest of the chip is on the first clock cycle out of reset even when the reset signal is externally synchronized to the clock. Without external synchronization, even a fast reset resource would often leave part of the chip reset for an extra clock cycle compared to the rest. Timing analysis is cleaner with synchronous resets. Some FPGA features - like the Xilinx shift registers and distributed RAM - don't like to have resets of any kind making the global use of asynchronous reset structures less desireable. "Dziadek" <dziadek.l@wp.pl> wrote in message news:avlqrk$kmg$1@news.tpi.pl... > Hi, > > I have a choice between synchronous and asynchronous global reset in the > design. In older devices choosing async reset usually lowered resource > utilization due to dedicated async reset input of the CLB. > > How is it now, with Spartan-2 and newer that have sync/async choice for the > dedicated reset input? Which method is recommended? Sync method seems better > (simpler timing management), but maybe there are some dark sides. Can you > share some experience? > > Regards, > DziadekArticle: 51314
"Steve Casselman" <sc@vcc.com> wrote in message news:<OCqT9.900$CZ6.635@newssvr16.news.prodigy.com>... > It all has to do with volume. If the Pro gets in more designs than the V2 > then a larger Pro die will cost less than a smaller V2 die. Here are the cost issues the way that I see them: 1. The Virtex II Pro is .13um, the Virtex II is 0.15um so the Virtex II Pro is a smaller die and will therefore be cheaper, gate-for-gate. 2. FPGA logic is much easier and faster to test than processor logic. You can create test patterns to test every gate pretty quickly in an FPGA. Testing processor logic is more difficult and time consuming. So testing costs will be a bit higher for the Pro. 3. Testing a SerDes at 3.125GHZ costs more than testing a generic LVPECL IO. So, again, testing costs are a bit higher. Will the Virtex II Pro be cheaper? Only Xilinx can say. Our designs use lots of logic and lots of IO. A small amount of logic and IO was sacrificed in the Virtex II Pro to make room for the SerDes and processors. Yes, Peter, we don't have to use the Pro, but the salesman was really pushing it on us, telling us that it is the future of the Virtex line. A point solution is one that solves one specific problem, rather than a large number of problems. Are the SerDes and processor point solutions? You are making a bet on the popularity of SerDes and embedded processors in future designs. My argument is that if you look at the present FPGA users, you will find Gigabit IO and especially embedded processors in a small minority of designs. You've based your entire future line of Virtex on a small percentage of customers. It is a bet, and may pan out. But for me personally, I would have prefered a 0.13um Virtex-II (non-Pro). Probably best of all is to have both. Anyone want to guess how many of Xilinx's customers are using all four 405 embedded processors in an FPGA? My guess is that you could count them on one hand. -tomArticle: 51315
Jon, Did you use the example in the Nios Software Development Reference manual on page 39? If not, you may have forgotten to set the piodirection. --ChrisArticle: 51316
>Are the SerDes and processor point solutions? You are making a bet on >the popularity of SerDes and embedded processors in future designs. My >argument is that if you look at the present FPGA users, you will find >Gigabit IO and especially embedded processors in a small minority of >designs. You've based your entire future line of Virtex on a small >percentage of customers. It is a bet, and may pan out. But for me >personally, I would have prefered a 0.13um Virtex-II (non-Pro). >Probably best of all is to have both. > >Anyone want to guess how many of Xilinx's customers are using all four >405 embedded processors in an FPGA? My guess is that you could count >them on one hand. Would you have said the same thing about block ram a few years ago? Multipliers? My guess is that the CPUs and fast IO will get used more as people get familiar with them. Remember they are free now, if you aren't using them for something else. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 51317
Hi everyone, A few days back I had posted a message about my problems with an asynchronous RAM on my FPGA board. I received a lot of help from group members and I managed to fix my code...well, partly. To refresh the problem, I read/write data to n fro from an asynchronous RAM external to the FPGA on my prototype board. My initial design involves reading 64000 8 bit values from the board and writing 64000 values back. These are done in bursts of 512 values each and then there is a break before the read/write starts again. The async RAM is able to run @ 100MHz according to its specs. The code runs @ 10 MHz. The board clock is @ 40MHz and by using a pll in my FPGA, I run the code @ 10MHz. I have found after having run several runs of my code that approximately 44500 values of the 64000 are read/written correctly. After that something goes wrong and the rest of the values are incorrect. Initially I had problems with all 64K values, but then with some advice from the group, I took two cycles (instead of one) to read and write data from the async RAM and things improved, but only for 45000 values. Any ideas on what could be going wrong ? I checked my code and it is completely synchronous (except for the external RAM). Thanks, PrashantArticle: 51318
All, A very nice platform for FPGAs was developed by UC Berkeley (in cooperation we Xilinx): http://kamsky.eecs.berkeley.edu/calinx/pdf/Manual.pdf I would suggest you contact UCB, or myself, if you are interested in making some for your school. There are many platforms that are much less capable, and perhaps any one of those would be suitable for an introductory level course. Please review: http://www.xilinx.com/univ/index.htm Austin Rene Tschaggelar wrote: > David wrote: > > Hi, > > Does anyone know what is the best choice for an fpga developement kit? > > Altera offers this kit for University student : > > http://www.altera.com/education/univ/kits/unv-kits.html > > I wonder if there are other supplier of boards like this (could be Xilinx > > too) that could compete with this. Are there third party manufacturer that > > are worth considering? > > All these offers are comparable. > The software usually can be downloaded, at least reduced versions. > The programmers can be selfbuilt or purchased. > And finally you need some chip on a board. > While 150$ is not much you should base your preference based on > who is going to help you and who is going to introduce you into this > technology. A colleague is best as you'll spent a few feeks at least. > > Rene > -- > Ing.Buero R.Tschaggelar - http://www.ibrtses.com > & commercial newsgroups - http://www.talkto.netArticle: 51319
Thanks to all the people that have defended my statement. :-) Let me make it even clearer: If you compare the XC2VP7 against the well-known XC2V1000: The P7 has 40 rows by 34 columns, the 2V1000 has 40 rows by 32 columns. The P7 has 4928 slices, and the 2V1000 has 5120 slices, so the difference is 4% in favor of 2V1000 The P7 has 44 BlockRAMs, and the 2V1000 has 40, so the difference is 10% in favor of P7. The 2V1000 has slightly more I/O. That means, the comparison is very close, but the P7 is cheaper than the 2V1000. That means the PowerPC and the eight 3 gigabit transceivers are really FOR FREE ! This is the proverbial progress: smaller geometries due to more advanced processing (130 nm vs 150 nm) make a smaller die and lower cost. So you have a choice, and you either love the PPC and gigabit transceivers, or you just decide on the economics, the package availability and the available I/O. We gladly sell you either part. Peter Alfke, Xilinx Applications Hal Murray wrote: > >It's hard to convince people theses days that an in order, single > >pipeline, small cache processor is effectively free on modern > >silicon. But it is. > > Nice. Thanks. > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam.Article: 51320
Hal, I recently heard that ~50% of new SOC designs had a processor. Anyone wish to confirm or deny? How many designs out there do not have a cpu on the board? How many designs out there could make no use of a processor, if it is 'free'? Hint: just taking care of AGC, zero restoration, restoration, protection swiching, system management, error reporting, all all natural uses of a slave processor. Let the FPGA logic to the extreme packet switching, and let the 405PPC do the "Error 404: can't find web page error message." A long time ago, after the invention of electricity and the electric motor, a motor was considered the most expensive thing, and there was one in the corner of the factory, with lots of leather belts to transfer power to the many machine tools. When the fractional horsepower squirrell cage motor was invented, every tool could have its own motor, and even electric hand tools were invented. The Virtex II Pro is no less a revolution (pun intended) in design. (thats to Erich G. for the analogy) Austin Hal Murray wrote: > >It's hard to convince people theses days that an in order, single > >pipeline, small cache processor is effectively free on modern > >silicon. But it is. > > Nice. Thanks. > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam.Article: 51321
Thomas, your statement is not correct as far as several recent generations of Xilinx parts are concerned. We always distribute the global clock(s) on one or two horizontal "backbones" across the chip, but we gate off any vertical "rib" or "branch" that is not used. This is done automatically without any user intervention. It means that vertically oriented clocked logic draws less power than horizontally oriented one. And the carry structure always groups counters and accumulators vertically. :-) Peter Alfke, XilinxApplications =================== Thomas Stanka wrote: > Yes. The problem in fpga is, that the clock is prerouted to every > clockable element, where as in ASIC the clocktree will cover only used > cells. > So your clocktree will be allways be one of the the largest nets > independend of your design even if your using only a hand full of FF. > In newer fpgas there might be some technics to gate unused parts of > the clocktree, to reduce power. > Im not sure if Xilix allready gate unused parts of the clocktree, > Actel do in its AX technology. > > bye ThomasArticle: 51322
Thanks for the reply, but it turned out to be the PCB. What was odd is that my simple logic design worked but the NIOS implementation of the same design didn't (which is why I didn't think to check the HW). So something is flakey with the FPGA or there's a bad solder or something. At any rate, I've got my custom CPU running on our PCB now. Jon "crob" <crob714@yahoo.com> wrote in message news:cb769f6b.0301100934.1470fe41@posting.google.com... > Jon, > > Did you use the example in the Nios Software Development Reference > manual on page 39? If not, you may have forgotten to set the > piodirection. > > --ChrisArticle: 51323
Prashant wrote:
>
> Hi everyone,
>
> A few days back I had posted a message about my problems with an
> asynchronous RAM on my FPGA board. I received a lot of help from group
> members and I managed to fix my code...well, partly.
>
> To refresh the problem, I read/write data to n fro from an
> asynchronous RAM external to the FPGA on my prototype board. My
> initial design involves reading 64000 8 bit values from the board and
> writing 64000 values back. These are done in bursts of 512 values each
> and then there is a break before the read/write starts again.
>
> The async RAM is able to run @ 100MHz according to its specs. The code
> runs @ 10 MHz. The board clock is @ 40MHz and by using a pll in my
> FPGA, I run the code @ 10MHz.
>
> I have found after having run several runs of my code that
> approximately 44500 values of the 64000 are read/written correctly.
> After that something goes wrong and the rest of the values are
> incorrect.
>
> Initially I had problems with all 64K values, but then with some
> advice from the group, I took two cycles (instead of one) to read and
> write data from the async RAM and things improved, but only for 45000
> values.
>
> Any ideas on what could be going wrong ? I checked my code and it is
> completely synchronous (except for the external RAM).
The issue is not whether the code is synchronous or not. An asynch ram
is not synch by nature. So what you need to pay attention to are the
various timing specs for the address, data and read/write strobes.
Since you are running way slower than what the RAM can do, you should be
able to implement a very simple design to allow reading and writing of
the RAM. I don't know what you were told before, so I will assume
nothing.
The main issue is to keep the address and data stable while the write
strobe is asserted. The other issue is to read the data after it is
stable but before you remove the read strobe. So to make certain that
all of these timing restrictions are met, I would use the 40 MHz clock
and use four clock cycles for a read or a write. Like this, view in a
fixed width font...
| Write | Read |
FPGA Clock --__--__--__--__--__--__--__--__--__--__--_
RAM Addr ====<--addr-stable--><-addr-stable-->======
RAM Data ====<--data-stable-->zzzzzzzzzzzzzzz>======
RAM WR ---------________--------------------------
RAM OE -------------------------________----------
RAM CS ---------________--------________----------
^
FPGA Reads Data |
For a Write cycle, the Address and Data should be output during the
first clock cycle and remain stable for the entire four clock cycles.
The WR strobe should be asserted during the second and third clock
cycles and removed for the fourth clock cycle. This will give you lots
of setup and hold time on your address lines. If you are seeing write
problems, this is most likely where it is.
For a Read cycle, the Address is set up for all four cycles like in a
Write cycle, but the data bus is tristated for all four cycles. The
read strobe should be asserted for the second and third clock cycles.
Since the RAM is very fast you can read the data in the middle of the OE
strobe on the rising edge of the third clock. This will give the FPGA
lots of setup and hold time on the data. Removing the CS and OE at that
start of the fourth clock cycle gives an entire clock cycle for the RAM
output to go tristate to prevent any contention on the data bus.
These timings are very, very conservative given your 10 nS async RAM.
If this does not work, I expect you have a ground bounce or other signal
integrity issue that is double clocking the write strobe and trashing
data after it is written.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 51324> I have another related question about RAM arbiter (sp?). Within your design requirements, you should keep things as simple as possible. For many systems (comparable to yours), one can find a way to interlock the predictable accesses in a fixed scheme. For example, you may designate the first time slot (clock cycle) of 4 to the LCD controller, and the third to general DMA (modules ordered by priority). The other two slots are CPU. If any component doesn't consume its designated slot, it's available to whomever else requests a slot (except maybe LCD, to simplify LCD controller internal timing). The arbiter then merely counts the cycles, grants the slots according to this rule, and gives the remaining slots to any other module who wants them (with a simple priority scheme). On the software side, you can predict exactly which applications will get their slots and which won't. Very few resources are required for this type of arbitration, and it is up to most smaller designs. Even some desktop computers with UMA (unified memory architecture) use similar arbitration for the basic components. Marc
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