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 optimiser strips out all redundant logic in EDIF mode. It sounds
like you have a design with no external ports or interfaces declared.
Make sure your design is connected up to something external using the
'interface' command.
e.g.
unsigned 4 x;
interface bus_out() OutBus(unsigned 4 out = x) with pins =
{ "p1", "p2", "p3", "p4"}
James
Thomas Buerner <buerner@lrs.eei.uni-erlangen.de> wrote in message news:<3E281AD7.1AE43249@lrs.eei.uni-erlangen.de>...
> I generated a VHDL output from a HandelC project,
> synthesized it and used the Xilinx tools to map and place and
> route for a XC4010XL. This works fine.
> Then I tried to generate a EDIF netlist with DK1
> but the mapper tells me:
>
> NCD was not produced. All logic was removed from design.
>
> I checked the EDIF and found that no clock port is present.
> Instead a IPAD is the source of the clock signal in the netlist,
> which is removed by the mapper.
>
>
> any hints
>
> thanx
> Thomas
Article: 52551
This comes up from time to time. As long as you don't have processes inside
your UUT that go without a clock from the outside (such as some pll models), you
can stop simulation by causing all the processes to wait indefinitely. Stop the
clocks, and you will stop all clock dependent processes. Here is how to stop
them
process (
begin
if end_sim then
wait;
end if;
clk<='1';
wait for 5 ns;
clk<='0';
wait for 5 ns;
end ;
Then in your stimulus process
if stop_condition
end_sim<=true;
end if;
Frederic Bastenaire wrote:
> Hello,
>
> I am trying to cause a break to occur by executing a VHDL statement, in
> Modelsim (I do not want to use breakpoints, they are not convenient/flexible
> enough IMHO).
> Assert statements are supposed to do something like this, but using severity
> ERROR just prints a message, without stopping, while FAILURE really kills
> Modelsim.
> Are there other ways?
>
> Thank you for your help,
>
> Frederic
> (fba@free.fr)
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 52552Hi Peter, Thanks a lot for your detailed answer. Solution with JTAG port using for caches content loading seems too overcomplicated for the tiny board with only one XC2VP4 installed. Nevertheless information concerning how both data and program caches might be mapped in the PowerPC address space is very important and helpful. I will think further how to use this feature to reduce SelectRAM occupation. Valeri Serebrianski.Article: 52553
Hello, My Synopsys VSS license has expired. Is it possible to use the designware components (which my design eventual ASIC design contains) with Modelsim for simulating my design? I still have the license for Synopsys DC compiler for the synthesis but can I use modelsim for the simulation? SalmanArticle: 52554
On Thu, 13 Feb 2003 10:02:11 +1300, Jim Granville <jim.granville@designtools.co.nz> wrote: >Brian wrote: <snip> >> Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs >> should be able to work at this frequency? (The rise and fall times in >> the data sheet seem to indicate that it should.) Given the symptoms >> I describe, what might the problem be? Some sort of power issue? > > CPLDs typically have a SLEW control bit, so you could check that ? > > The simplest test for what you describe is to lower the 155MHz IP clock >- >if the waveform appears/improves below a certain freq, then yes, you >can confirm that with your settings the CR-II cannot output 155MHz. > > Most chips can clock faster than they can output. > > -jg Jim, thanks for the suggestions. I do have the slew rate set to fast. Also, the waveform does indeed improve as I slow down the clock rate. At about 77 MHz, it's swinging across the full voltage range, but looks horrible (about a 10 percent duty cycle). Once I get the frequency down to around 50 MHz, it looks fine. I was really hoping that someone who's using a Coolrunner II would either tell me that the push-pull I/O just won't go that fast, or that their's works fine at the I/O rates I'm trying. If it just won't go that fast, then I'll use the open drain output or change the rest of my system to accept a lower voltage swing. If others are having no problems outputing signals that fast, then I'll know that I have something fundamentally wrong with my layout and know that I won't be wasting my time trying to debug it....Article: 52555
Brian, From the IBIS sim, it goes that fast (we verify IBIS with silicon). It is possible that you have a early part from the fab, and that it might be in the slow corner of the process. I would open a case on the hotline, as there is no reason why it could not do what you want it to do. One obvious question: you are measuring this with a >1GHz scope and probe, right? Austin Brian wrote: > On Thu, 13 Feb 2003 10:02:11 +1300, Jim Granville > <jim.granville@designtools.co.nz> wrote: > > >Brian wrote: > <snip> > >> Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs > >> should be able to work at this frequency? (The rise and fall times in > >> the data sheet seem to indicate that it should.) Given the symptoms > >> I describe, what might the problem be? Some sort of power issue? > > > > CPLDs typically have a SLEW control bit, so you could check that ? > > > > The simplest test for what you describe is to lower the 155MHz IP clock > >- > >if the waveform appears/improves below a certain freq, then yes, you > >can confirm that with your settings the CR-II cannot output 155MHz. > > > > Most chips can clock faster than they can output. > > > > -jg > > Jim, thanks for the suggestions. > > I do have the slew rate set to fast. > > Also, the waveform does indeed improve as I slow down the clock rate. > At about 77 MHz, it's swinging across the full voltage range, but > looks horrible (about a 10 percent duty cycle). Once I get the > frequency down to around 50 MHz, it looks fine. > > I was really hoping that someone who's using a Coolrunner II would > either tell me that the push-pull I/O just won't go that fast, or that > their's works fine at the I/O rates I'm trying. If it just won't go > that fast, then I'll use the open drain output or change the rest of > my system to accept a lower voltage swing. If others are having no > problems outputing signals that fast, then I'll know that I have > something fundamentally wrong with my layout and know that I won't be > wasting my time trying to debug it....Article: 52556
hi guys,
iam workin on 32 bit alu design using vertex2 fpga chip. in this
i have to design a 16 BY 32 ROM USING "INIT" function. im comin across
lots of warnings indicatin "BLACK BOX".
Wats this "black box".
and how do i remove these warnings and how they affect my design.
thankin u
naveen
Article: 52557How can you reconfig the parts of Virtex II without any current issue? Are you using serial programming or parallel programming?With the configuration data changed in the RAM,you surely have some switching current.I am not sure whether you still have the short current.But seems it will be there too. On Wed, 12 Feb 2003, Austin Lesea wrote: > Rudy, > > It is sure amusing to read all of the conjectures..... > > Now that we are designing our 12th generation FPGA, we are able to control current quite well, > thank you. > > Note: that is 12 successful FPGA designs. You get pretty good at something when you work on > it for that long (and do some experimentation along the way). > > Virtex II and Virtex II Pro have no current surge on power ON, as we found what causes that, > and addressed it. > > As for multi-context FPGAs, they were simply killed by FPGAs with million+ "gates" (who needs > to switch?). As well, with partial reconfiguration in Virtex II and II Pro, you can at any > time reconfigure parts and pieces (with no current issue). > > Austin > > > Rudolf Usselmann wrote: > > > Christian Plessl <plessl@tik.ee.ethz.ch> wrote in message news:<3e47e49e@pfaff.ethz.ch>... > > > Nicholas C. Weaver wrote: > > > > > > > In article <b235lh$n01$03$1@news.t-online.com>, > > > > Florian-Wolfgang Stock <f.stock@tu-bs.de> wrote: > > > >>S. Trimberger, D. Carberry, A. Johnson, J. Wong: A time-multiplexed > > > >>FPGA. In "Proceedings of IEEE Workshop on FPGAs for Custom Computing > > > >>Machines" (April 1997), pp. 22-28 > > > > > > > > This one, a Xilinx design for a multicontext XC4000, was basically > > > > killed as a potential product because context switching draws a LOT of > > > > power, especially in all the interconnect bits, and they envisionsed > > > > multicontext being used to virtualize larger circuits. > > > > > > Do you have any idea, why some multi-context devices are seem to consume a > > > lot of power when context switching? > > > > > > Any idea how the power dissipation related to context switching relates to > > > the power consumed by a 'typical' user application? I understand that a > > > context switch can potentially cause a lot of elements to switch at once, > > > but also a user application might generate quit a lot of signal toggling. > > > > The problem lies in changing the interconnect configuration during > > a "context switch". To fully understand the details you need to look > > at how those switches are implemented: typically some combination of > > pass-gates and buffers. The characteristics are typically so, that > > the actual signal propagation is quick (e.g. low resistance pass-gates > > and very quick buffers), however the turn on and off time are relatively > > slow. So what happens when you change the configuration ? Multiple pass > > gates can be closed at the same time and drive different logic values > > on the bus, creating a short. Count the nuber of interconnects and > > possible shorts, even in the smallest FPGA, and it becomes clear why > > you can cook coffee on them if constantly context switching. (I suspect > > this is the same reason why the "power-on-current" requirement is so > > high.) > > > > Of course the idea of context switching programmable logic is not new, > > I have worked on a proprietary "processor" that had 64 "time slices". > > This was basically an FPGA type of structure with its inputs and outputs > > going through a multilevel register file as well as to an IO ring. It > > was meant to be used as the hart in a Hardware Accelerator, and burned > > about 20 Watts each. (This was in 1995) > > > > Regards, > > rudi > > ------------------------------------------------ > > www.asics.ws - Solutions for your ASIC needs - > > FREE IP Cores --> http://www.asics.ws/ <--- > > ----- ALL SPAM forwarded to: UCE@FTC.GOV ----- > > > > > Regrads, > > > Christian >Article: 52558
In article <Pine.SOL.3.96.1030213113821.24078A-100000@vcmr-86.server.rpi.edu>, Kuan Zhou <zhouk@rpi.edu> wrote: > How can you reconfig the parts of Virtex II without any current issue? >Are you using serial programming or parallel programming?With the >configuration data changed in the RAM,you surely have some switching >current.I am not sure whether you still have the short current.But seems >it will be there too. If I recall (note I may be horribyl wrong) the Xilinx reconfig since Virtex operates by having a shift-chain shift the data down and then the data from the shift-chain is loaded into a column of config bits. Since you are only shifting one chain at a time, even though it can be rather long, the power is not much. The power people were refering to is the "Power on surge", the power required on startup on the Virtex and before, which was a fairly nontrivial amount of current for a short period of time. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 52559
Kuan, That is why we are the leader. We know how to do this (among other things) and others do not. Austin Kuan Zhou wrote: > How can you reconfig the parts of Virtex II without any current issue? > Are you using serial programming or parallel programming?With the > configuration data changed in the RAM,you surely have some switching > current.I am not sure whether you still have the short current.But seems > it will be there too. > > On Wed, 12 Feb 2003, Austin Lesea wrote: > > > Rudy, > > > > It is sure amusing to read all of the conjectures..... > > > > Now that we are designing our 12th generation FPGA, we are able to control current quite well, > > thank you. > > > > Note: that is 12 successful FPGA designs. You get pretty good at something when you work on > > it for that long (and do some experimentation along the way). > > > > Virtex II and Virtex II Pro have no current surge on power ON, as we found what causes that, > > and addressed it. > > > > As for multi-context FPGAs, they were simply killed by FPGAs with million+ "gates" (who needs > > to switch?). As well, with partial reconfiguration in Virtex II and II Pro, you can at any > > time reconfigure parts and pieces (with no current issue). > > > > Austin > > > > > > Rudolf Usselmann wrote: > > > > > Christian Plessl <plessl@tik.ee.ethz.ch> wrote in message news:<3e47e49e@pfaff.ethz.ch>... > > > > Nicholas C. Weaver wrote: > > > > > > > > > In article <b235lh$n01$03$1@news.t-online.com>, > > > > > Florian-Wolfgang Stock <f.stock@tu-bs.de> wrote: > > > > >>S. Trimberger, D. Carberry, A. Johnson, J. Wong: A time-multiplexed > > > > >>FPGA. In "Proceedings of IEEE Workshop on FPGAs for Custom Computing > > > > >>Machines" (April 1997), pp. 22-28 > > > > > > > > > > This one, a Xilinx design for a multicontext XC4000, was basically > > > > > killed as a potential product because context switching draws a LOT of > > > > > power, especially in all the interconnect bits, and they envisionsed > > > > > multicontext being used to virtualize larger circuits. > > > > > > > > Do you have any idea, why some multi-context devices are seem to consume a > > > > lot of power when context switching? > > > > > > > > Any idea how the power dissipation related to context switching relates to > > > > the power consumed by a 'typical' user application? I understand that a > > > > context switch can potentially cause a lot of elements to switch at once, > > > > but also a user application might generate quit a lot of signal toggling. > > > > > > The problem lies in changing the interconnect configuration during > > > a "context switch". To fully understand the details you need to look > > > at how those switches are implemented: typically some combination of > > > pass-gates and buffers. The characteristics are typically so, that > > > the actual signal propagation is quick (e.g. low resistance pass-gates > > > and very quick buffers), however the turn on and off time are relatively > > > slow. So what happens when you change the configuration ? Multiple pass > > > gates can be closed at the same time and drive different logic values > > > on the bus, creating a short. Count the nuber of interconnects and > > > possible shorts, even in the smallest FPGA, and it becomes clear why > > > you can cook coffee on them if constantly context switching. (I suspect > > > this is the same reason why the "power-on-current" requirement is so > > > high.) > > > > > > Of course the idea of context switching programmable logic is not new, > > > I have worked on a proprietary "processor" that had 64 "time slices". > > > This was basically an FPGA type of structure with its inputs and outputs > > > going through a multilevel register file as well as to an IO ring. It > > > was meant to be used as the hart in a Hardware Accelerator, and burned > > > about 20 Watts each. (This was in 1995) > > > > > > Regards, > > > rudi > > > ------------------------------------------------ > > > www.asics.ws - Solutions for your ASIC needs - > > > FREE IP Cores --> http://www.asics.ws/ <--- > > > ----- ALL SPAM forwarded to: UCE@FTC.GOV ----- > > > > > > > Regrads, > > > > Christian > >Article: 52560
One chart in the Coolrunner 2C64 datasheet shows current versus frequency up to 240MHz in the -5 and -7 but the maximum external frequency (for Tsu and Tcko) is 159 or 169 MHz for the -5 device (Two values given). If you have real 155M NRZ data and not a CMI electrical interface (effective 311 MHz NRZ data rate) you should be good with your I/O but keep in mind that the numbers are specified for TTL with extra time required for LVCMOS. I'd look at the timing report generated in the Xilinx design flow (or analyzed separately) to make sure everything looks fine from that perspective. Just one pterm delay can tak up a lot of your clock cycle so those timing analysis numbers are important. The fluctuation around 3.3V is what I'd expect to see for a TTL style signal in a CPDL - the drivers are a little weak at the high voltage so what you're probably seeing is an output that thinks it should be logic high and the noise is feedthrough from the internal voltage rails for your I/O. If you can, try running the device at half speed and see if you still have the logic high. If you're playing with your clock internally, make sure the duty cycle will stay clean. The global clock pulse width high or low is specified for 1.5 ns so you should have plenty of margin. If you're using the internal clock doubling feature (using both clock edges, more precisely), make sure the duty cycle of the clock going in is clean. Good luck! "Brian" <usenet@carlsonclan.com> wrote in message news:rari4vcbt4ldgu3gl16n5hv4tdrf20d6lf@4ax.com... > I'm working on a design that needs to output signals up to 155 MHz. > I'm trying to use a Coolrunner II, but the output doesn't seem fast > enough. > > I'm using 3.3V I/O and when I try to simply output my 155 MHz input > clock, I get a waveform that stays up around 3.3V. It sort of wiggles > a few tenths of a volt at the right frequency, but never even makes it > below 3 V. I've uploaded a crude sketch showing the waveform here: > http://www.fastclan.com/members/griz/155MHz.gif > > I've played around with adding a BUFG and/or an OBUF, but the output > still looks the same. I've also tried using the LVTTL and 33LVCMOS > output types, but again, it always looks the same. The only way I > can get a more or less acceptable output is to us an open drain output > with a *strong* pullup resistor (like 200 Ohms). > > I'm fairly sure that the clock is making it into the part OK, because > I tried putting in a counter to divide down the clock, and those > outputs looked OK. > > Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs > should be able to work at this frequency? (The rise and fall times in > the data sheet seem to indicate that it should.) Given the symptoms > I describe, what might the problem be? Some sort of power issue? > > TIA > -Brian >Article: 52561
This might save you some time and effort: App. Notes http://www.xilinx.com/apps/xapp.htm TechXclusives http://www.xilinx.com/support/techxclusives/techX-home.htm Software Manuals http://toolbox.xilinx.com/docsan/xilinx4/manuals.htm V2 Data Sheet http://www.xilinx.com/partinfo/ds031.htm V2 Users Guide (i.e. Handbook) http://www.xilinx.com/publications/products/v2/ug_pdf/index.htm V2 Pro Data Sheet http://www.xilinx.com/publications/products/v2pro/ds_pdf/ds083.htm V2 Pro Users Guide (i.e. Handbook) http://www.xilinx.com/publications/products/v2pro/ug_pdf/index.htmArticle: 52562
Hi, Has anybody used the newest version of FC2 (3.7.2)?? I just got to try it the other day and its much much faster compared to its earlier versions (compared to 3.6.0). Also looks like retiming has been fixed, I could run a few designs through it which were complaining earlier....I was also surprised that it supported a few vhdl constructs for which the earlier versions used to error out. I'm yet to try it out fully though.... -Nick "Jonathan Bromley" <jonathan@oxfordbromley.u-net.com> wrote in message news:<b1t8of$50p$1$8302bc10@news.demon.co.uk>... > "Ray Andraka" <ray@andraka.com> wrote: > > Synplify does a much better job at mapping RTL to the special features of > > the FPGA. Xilinx's XST does well in that regard too, but it is restricted > > to Xilinx only. > > I don't in any way disagree, but to try to keep the discussion > balanced it might be worth mentioning my experience that Leonardo > Spectrum seems to have the widest understanding of VHDL language > constructs of any synthesis tool. Not necessarily the best quality > of results, though - that's a "your mileage may vary" issue that > you will need to evaluate case-by-case. > > Also, don't try to evaluate these tools just by throwing one > standard piece of "benchmark" code at them to see which gives > the densest/fastest/prettiest result. Each of the major tools > has specific HDL coding styles that it doesn't like and won't > optimise effectively; details differ for each tool. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK > Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: http://www.doulos.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated.Article: 52563
Brian wrote: > > On Thu, 13 Feb 2003 10:02:11 +1300, Jim Granville > <jim.granville@designtools.co.nz> wrote: > > >Brian wrote: > <snip> > >> Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs > >> should be able to work at this frequency? (The rise and fall times in > >> the data sheet seem to indicate that it should.) Given the symptoms > >> I describe, what might the problem be? Some sort of power issue? > > > > CPLDs typically have a SLEW control bit, so you could check that ? > > > > The simplest test for what you describe is to lower the 155MHz IP clock > >- > >if the waveform appears/improves below a certain freq, then yes, you > >can confirm that with your settings the CR-II cannot output 155MHz. > > > > Most chips can clock faster than they can output. > > > > -jg > > Jim, thanks for the suggestions. > > I do have the slew rate set to fast. > > Also, the waveform does indeed improve as I slow down the clock rate. > At about 77 MHz, it's swinging across the full voltage range, but > looks horrible (about a 10 percent duty cycle). Once I get the > frequency down to around 50 MHz, it looks fine. Interesting - That's consistant with a quite different Tplh from Tphl. at appx 80MHz corner, that's ~6ns of skew to 'remove' a whole half cycle. ( Almost like the slew controls are only half working... ) Certainly not normal for a device of that speed class, and I'd go with Austin's suggestion of 'an early part from the fab' :) Have you tried other samples ( even other pins ) ? Tried enabling the slow option, to see it really does get slower again ? I can't see the Pullup helping a sticky hi problem, so it sounds like the open drain bypasses whatever is causing the skew, which again points to an output cell issue ..... -jgArticle: 52564
> more useful were focused on > shortening reconfiguration times. As devices sizes go into the 10 - 100 million gate range you will want to think more along the line of a complete system with OS and other resources. Even in full applications most of the code stays around and just subroutines and processes are swapped in and out. It would be nice to have a 32 bit configuration interface. Todays systems are 8-bit external and 32-bit internal (or 100s of bits if you count a frame as the internal bit length). > Algorithmic programming of fpga's for wild-a$$ genetic search > machines is a great application, but it seems a ways off before > its ready for the masses of programmers writing software that manipulates > hardware in realtime. No I don't believe so. The way it is starting to look is: take an algorithm and a data set and generate a custom piece of hardware for that combination. So take a picture or image and generate a correlator based on that image http://www.doc.ic.ac.uk/~wl/papers/fccm02jg.pdf . This really shows you where reconfigurable computing systems and methodes are headed. > I can see your vision, but with the Xilinx 6000 demise, (too early to market?) > as an example, potential backers of open bitstream fpga architectures > should think long and hard. There is perceived value in having your hardware > designs distributed in a traditional confusticated form, produced and verified > by commodity toolchains (sim,syn,par, and timing). > The real problem with the 6200 was logic size and performance. Someday I believe that we will look at hardware designs as programming and accept that fact that you can disassemble a program if you really want to. While I'm not saying FPGA companies should abandon their current business models they should think about designing a device that is supposed to be programmed and understood by programmers. Some device that understands that it will have to fetch pieces of hardware over and over an OS that understands that computing is both changing hardware and changing software. It seems like every 20 years we start to have break throughs of this kind. In the 60's real computers were programmed by real programmers that programmed in assembly. In the 80's power DSP programmers programmed power applications using only assembly. In the '00's we have creative engineers creating magic using hardware programming tools. In the end clever people found how to capture that expertise and interpret computer languages so average people could do what use to take the top 5% burning the candle at both ends to accomplish. To really do this you need to publish the data so you can have 1000's of people working on it instead of just the people you pay. Imagine if there were no published data on a processor and the tool that company C made only had encrypted files so there was no way someone out side the company could make a compiler. Even if company C produced a great processor, competitor company D that published all the data would win in the market place. This is because other companies and individuals would work to provide tools and might do things company D or C did not think of (like timing driven place and route) and that would make a difference. But of course I'm just one dude with a dream. This kind of stuff will only come around when companies C and D have customers that want this and customers won't want it till it is proven and .... Opps I 'm back where I started.. Cheers Steve SteveArticle: 52565
Peter Alfke wrote: > This might save you some time and effort: > > App. Notes > http://www.xilinx.com/apps/xapp.htm > <snip> Thanks. Maybe not as tech as http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Platform+FPGAs but much, much more useful. (The above URL is for the V-II home page)Article: 52566
Paul, We have performed testing on the Terminator Technology feature and found it to offer robust performance even in a noisy environment. For example, we have tested it with various I/O standards and found that even with high numbers of switching I/Os, the device met the I/O specifications (VIL, VIH, and so forth). The reference resistor is 10x the termination value to minimize the DC current consumption of the circuit that controls the actual impedance level. As mentioned above, this solution offers good resistance to noisy environments. Greg Steinke gregs@altera.com Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3E3EC447.14A10F9A@xilinx.com>... > Paul, > > Since they chose a reference value of 10X, it makes their solution 10 > times more sensitive to noise, cross talk, ground bounce, and vcc > bounce. I would be interested to hear if their solution is fussy, or > difficult to use. > > Even if the rumor is unconfirmed, we can say that we chose reference > resistors of 1X to prevent just such problems. > > Austin > > Paul Martek wrote: > > > Has anyone used the terminator technology in Altera Stratix FPGA's? > > Did it work? Was it reliable? I had heard some third hand news > > describing a problem configuring the terminator resistance value from > > the RUP/RDN pins. > > > > PaulArticle: 52567
Wayne, Here is what has happened. The problem is that dual-purpose IO/VREF pins (whose primary function in the pin table is I/O) that are unused in the design are listed as GND in the pin file generated by Quartus II. The asterisk to mark it as an unused I/O pin is missing, therefore, it appears to be a dedicated GND pin. But in fact it is not a dedicated GND pin. A future version of Quartus II will add the asterisk to denote that it is an unused I/O pin, to be connected to ground since it is unused, and not a real GND pin. Please note that the actual VCC and GND pins on the device are shown correctly. You would only have a problem here if you had connected the IO/VREF pin to GND but later wanted to use it as an IO in your design. Sincerely, Greg Steinke gregs@altera.com "Wayne" <bigwayne@techie.com> wrote in message news:<b0s1fs$27h@netnews.proxy.lucent.com>... > FYI, > > Has anyone started designing with Altera Cyclone? > > I just learned that there are some pin changes made between > what was in Quartus 2.1 and Quartus 2.2 for the EP1C12 device. > > Regards, > WayneArticle: 52568
Regarding LEON-2, can anybody tell me the differences between versions 1.0.10 and 1.0.11-XST? Obviously the 1.0.11 version is intended for synthesis with Xilinx XST, but what are the specific differences that that necessitates? Thanks! JoshP "Ray Andraka" <ray@andraka.com> wrote in message news:3E3EAD37.7C89ABD0@andraka.com... > There is also a free 68HC11 core from green mountain and a PIC 5x compatible > core on opencores.com. There are links to both on my website. > > "Nicholas C. Weaver" wrote: > > > In article <3E3E8826.5070208@agh.edu.pl>, > > Ernest Jamro <jamro@agh.edu.pl> wrote: > > >I am interested in implementing a (soft) microprocessor core on Virtex > > >just for education purposes (and latter on maybe, to use it in some > > >applications). There are a lot of them available (e.g. OPENCORES). > > >I do not know which one is the best choice. > > > > > > The microprocessor core should: > > >1) be free and open - its architecture should be well described so it > > >would be easy to learn how it works and allows to simulate each part of > > >the microprocessor or even observe the real time microprocessor's > > >signals by ChipScope or Internal Logic Analyser (OpenCores). (It would > > >be nice if the microprocessor has a WISHBONE compatible external bus) > > > > > >2) Rather quick - to show the modern microprocessor architectures - > > >pipelining, possible branch prediction, VLIW and superscalar execution, > > >and working with high frequency (comparable to e.g. microBlaze) > > > > You won't get this, especially in an opencore. Microblaze is very > > highly optimized and finely pipelined, so it operates in a much higher > > frequency when compared with other options. > > > > >Is it better to use a free core or to buy a commersial one (e.g. > > >microBlaze), as free cores are not well tested and described and/or > > >analysising their internal structure might take too much time. > > > > If you want free, look at Leon, its a GPLed synthesized sparc. Not > > that fast (~20-25 MHz on a Virtex), and not that small (~6000 LUTs), > > but free and fully synthesized. > > > > -- > > Nicholas C. Weaver nweaver@cs.berkeley.edu > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 52569
All, I have it on good authority (ie the folks who know!) that early fab lots had slower than allowed IO transistor performance. Please open the case on the hotline for prompt resolution. Austin Jim Granville wrote: > Brian wrote: > > > > On Thu, 13 Feb 2003 10:02:11 +1300, Jim Granville > > <jim.granville@designtools.co.nz> wrote: > > > > >Brian wrote: > > <snip> > > >> Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs > > >> should be able to work at this frequency? (The rise and fall times in > > >> the data sheet seem to indicate that it should.) Given the symptoms > > >> I describe, what might the problem be? Some sort of power issue? > > > > > > CPLDs typically have a SLEW control bit, so you could check that ? > > > > > > The simplest test for what you describe is to lower the 155MHz IP clock > > >- > > >if the waveform appears/improves below a certain freq, then yes, you > > >can confirm that with your settings the CR-II cannot output 155MHz. > > > > > > Most chips can clock faster than they can output. > > > > > > -jg > > > > Jim, thanks for the suggestions. > > > > I do have the slew rate set to fast. > > > > Also, the waveform does indeed improve as I slow down the clock rate. > > At about 77 MHz, it's swinging across the full voltage range, but > > looks horrible (about a 10 percent duty cycle). Once I get the > > frequency down to around 50 MHz, it looks fine. > > Interesting - That's consistant with a quite different Tplh from Tphl. > at appx 80MHz corner, that's ~6ns of skew to 'remove' a whole half > cycle. > > ( Almost like the slew controls are only half working... ) > > Certainly not normal for a device of that speed class, > and I'd go with Austin's suggestion of 'an early part from the fab' :) > > Have you tried other samples ( even other pins ) ? > > Tried enabling the slow option, to see it really does get slower again > ? > > I can't see the Pullup helping a sticky hi problem, so it > sounds like the open drain bypasses whatever is causing the skew, > which again points to an output cell issue ..... > > -jgArticle: 52570
Ahh, good. But did you check to see how much jitter is introduced into a signal when the feature is used in the presence of noise? I hope you did, and found that the jitter added was small. Austin Greg Steinke wrote: > Paul, > We have performed testing on the Terminator Technology feature and > found it to offer robust performance even in a noisy environment. For > example, we have tested it with various I/O standards and found that > even with high numbers of switching I/Os, the device met the I/O > specifications (VIL, VIH, and so forth). > > The reference resistor is 10x the termination value to minimize the DC > current consumption of the circuit that controls the actual impedance > level. As mentioned above, this solution offers good resistance to > noisy environments. > > Greg Steinke > gregs@altera.com > > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3E3EC447.14A10F9A@xilinx.com>... > > Paul, > > > > Since they chose a reference value of 10X, it makes their solution 10 > > times more sensitive to noise, cross talk, ground bounce, and vcc > > bounce. I would be interested to hear if their solution is fussy, or > > difficult to use. > > > > Even if the rumor is unconfirmed, we can say that we chose reference > > resistors of 1X to prevent just such problems. > > > > Austin > > > > Paul Martek wrote: > > > > > Has anyone used the terminator technology in Altera Stratix FPGA's? > > > Did it work? Was it reliable? I had heard some third hand news > > > describing a problem configuring the terminator resistance value from > > > the RUP/RDN pins. > > > > > > PaulArticle: 52571
http://www.aldec.com/IP_Services/available_cores.htm "TI" <anglomont@yahoo.com> wrote in message news:18a34598.0302021646.308dc61c@posting.google.com... > Can smbdy please point me to a link or just give and estimate > how much does the stuff like :rake receiver, 8051 core, costs? > regards > TIArticle: 52572
Hi,
Are you shifting one bit into the column per cycle or shift the
whole chain into the column per cycle?
Anyway, this kind of programming is slow.What if the people needs fast
reconfiguration?
Does "power on surge" means when start up the Virtex part needs more
power?
sincerely
-------------
Kuan Zhou
ECSE department
On Thu, 13 Feb 2003, Nicholas C. Weaver wrote:
> In article <Pine.SOL.3.96.1030213113821.24078A-100000@vcmr-86.server.rpi.edu>,
> Kuan Zhou <zhouk@rpi.edu> wrote:
> > How can you reconfig the parts of Virtex II without any current issue?
> >Are you using serial programming or parallel programming?With the
> >configuration data changed in the RAM,you surely have some switching
> >current.I am not sure whether you still have the short current.But seems
> >it will be there too.
>
> If I recall (note I may be horribyl wrong) the Xilinx reconfig since
> Virtex operates by having a shift-chain shift the data down and then
> the data from the shift-chain is loaded into a column of config bits.
>
> Since you are only shifting one chain at a time, even though it can be
> rather long, the power is not much.
>
> The power people were refering to is the "Power on surge", the power
> required on startup on the Virtex and before, which was a fairly
> nontrivial amount of current for a short period of time.
> --
> Nicholas C. Weaver nweaver@cs.berkeley.edu
>
>
Article: 52573Hi, I know Xilinx is the leader in the FPGA field.But I can't attend the FPGA 2003 conference.I got a poster accepted.Otherwise I may talk to you in the conference. What causes "power on surge"?I guess it's because the pass gates are not powered up simultaneouly. sincerely ------------- Kuan Zhou ECSE department On Thu, 13 Feb 2003, Austin Lesea wrote: > Kuan, > > That is why we are the leader. We know how to do this (among other things) and others do not. > > Austin > > Kuan Zhou wrote: > > > How can you reconfig the parts of Virtex II without any current issue? > > Are you using serial programming or parallel programming?With the > > configuration data changed in the RAM,you surely have some switching > > current.I am not sure whether you still have the short current.But seems > > it will be there too. > > > > On Wed, 12 Feb 2003, Austin Lesea wrote: > > > > > Rudy, > > > > > > It is sure amusing to read all of the conjectures..... > > > > > > Now that we are designing our 12th generation FPGA, we are able to control current quite well, > > > thank you. > > > > > > Note: that is 12 successful FPGA designs. You get pretty good at something when you work on > > > it for that long (and do some experimentation along the way). > > > > > > Virtex II and Virtex II Pro have no current surge on power ON, as we found what causes that, > > > and addressed it. > > > > > > As for multi-context FPGAs, they were simply killed by FPGAs with million+ "gates" (who needs > > > to switch?). As well, with partial reconfiguration in Virtex II and II Pro, you can at any > > > time reconfigure parts and pieces (with no current issue). > > > > > > Austin > > > > > > > > > Rudolf Usselmann wrote: > > > > > > > Christian Plessl <plessl@tik.ee.ethz.ch> wrote in message news:<3e47e49e@pfaff.ethz.ch>... > > > > > Nicholas C. Weaver wrote: > > > > > > > > > > > In article <b235lh$n01$03$1@news.t-online.com>, > > > > > > Florian-Wolfgang Stock <f.stock@tu-bs.de> wrote: > > > > > >>S. Trimberger, D. Carberry, A. Johnson, J. Wong: A time-multiplexed > > > > > >>FPGA. In "Proceedings of IEEE Workshop on FPGAs for Custom Computing > > > > > >>Machines" (April 1997), pp. 22-28 > > > > > > > > > > > > This one, a Xilinx design for a multicontext XC4000, was basically > > > > > > killed as a potential product because context switching draws a LOT of > > > > > > power, especially in all the interconnect bits, and they envisionsed > > > > > > multicontext being used to virtualize larger circuits. > > > > > > > > > > Do you have any idea, why some multi-context devices are seem to consume a > > > > > lot of power when context switching? > > > > > > > > > > Any idea how the power dissipation related to context switching relates to > > > > > the power consumed by a 'typical' user application? I understand that a > > > > > context switch can potentially cause a lot of elements to switch at once, > > > > > but also a user application might generate quit a lot of signal toggling. > > > > > > > > The problem lies in changing the interconnect configuration during > > > > a "context switch". To fully understand the details you need to look > > > > at how those switches are implemented: typically some combination of > > > > pass-gates and buffers. The characteristics are typically so, that > > > > the actual signal propagation is quick (e.g. low resistance pass-gates > > > > and very quick buffers), however the turn on and off time are relatively > > > > slow. So what happens when you change the configuration ? Multiple pass > > > > gates can be closed at the same time and drive different logic values > > > > on the bus, creating a short. Count the nuber of interconnects and > > > > possible shorts, even in the smallest FPGA, and it becomes clear why > > > > you can cook coffee on them if constantly context switching. (I suspect > > > > this is the same reason why the "power-on-current" requirement is so > > > > high.) > > > > > > > > Of course the idea of context switching programmable logic is not new, > > > > I have worked on a proprietary "processor" that had 64 "time slices". > > > > This was basically an FPGA type of structure with its inputs and outputs > > > > going through a multilevel register file as well as to an IO ring. It > > > > was meant to be used as the hart in a Hardware Accelerator, and burned > > > > about 20 Watts each. (This was in 1995) > > > > > > > > Regards, > > > > rudi > > > > ------------------------------------------------ > > > > www.asics.ws - Solutions for your ASIC needs - > > > > FREE IP Cores --> http://www.asics.ws/ <--- > > > > ----- ALL SPAM forwarded to: UCE@FTC.GOV ----- > > > > > > > > > Regrads, > > > > > Christian > > > > > >Article: 52574
In article <Pine.SOL.3.96.1030214004835.24511A-100000@vcmr-86.server.rpi.edu>, Kuan Zhou <zhouk@rpi.edu> wrote: >Hi, > Are you shifting one bit into the column per cycle or shift the >whole chain into the column per cycle? It's a shift chain, so the addition is however many bits/bytes per clock cycle. Once the chain is full, it is transfered to config bits. Again, this is just what I recall. > Anyway, this kind of programming is slow.What if the people needs fast >reconfiguration? You don't use Xilinx or Altera. Or you limit your reconfiguration to just LUT contents and use SRL16 mode. > Does "power on surge" means when start up the Virtex part needs more >power? power-on surge is the problem the Virtex 1 had where the startup required a conisderable amount of current to properly start up when first powered. This power is only required during startup, not during normal operation. Virtex II fixed this problem. -- Nicholas C. Weaver nweaver@cs.berkeley.edu
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