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
Take a look at circuit #4 at http://support.xilinx.com/support/techxclusives/6easy-techX37.htm good luckArticle: 55676
Wong wrote: > Here's the code. Its fine with the functional simulation but after > P&R, I have the problems as mentioned. Thanks. The glitches are coming from your combinational outputs. Consider getting rid of next_state and the combinational process. and putting all the code into a single case of current_state in the synchronous process elsif clause. That would give you synchronous outputs by default. -- Mike TreselerArticle: 55677
Peter Alfke <peter@xilinx.com> writes: > Silicon is one tough material ! The 125 or even 150 degree limit is > more a plastic package issue than a silicon issue. I have helped > down-hole ( oil-drilling) applications where our chips functioned (with > relaxed performance) for many weeks at 175 degree ambient, and the user > was pushing for 200 degrees. They used Xilinx FPGAs, Z80 uPs, SRAMs and > even some analog stuff "down there". This worked, but we never > guaranteed it. Using plastic- or ceramic-packaged parts? Were the parts pre-screened for high-temperature operation before use in the final application?Article: 55678
"Isabel" <isabel25@cuhk.edu.hk> wrote in message news:3EC357B3.7050504@cuhk.edu.hk... > I am going to programme a 8x8 shared-buffer memory routing switch, and I > am using Verilog on Xilinx Webpack 5.1i. > > However, I encounter the following problem: > > NgdBuild:755 - Line line_no in 'filename': Could not find net(s) > 'net_name' in the design. To suppress this error use the -aul switch, > specify the correct net name or remove the constraint. Sounds like there is a net specified in a UCF file that has been optimized out of the design. Try removing that net from the UCF file, or use the -aul switch!Article: 55679
This is a stupid question, and maybe it's not the right place to post....BUT I'm wondering if there exists a line of fast (> 133 Mhz) Fifos with capacity on the order of 8-16Mbits. I know I can use a generic memory and implement the controller myself, but I'm just wondering if I can get away with being lazy. Thanks, LisArticle: 55680
IDT seem to be the king of that realm. Click on http://www.idt.com/products/fifo.html If you need strange things ( like asynchronous operation, or different width between read and write), you can always "knit your own" with an FPGA and a standard SRAM. Peter Alfke ==================== Lis Hu wrote: > > This is a stupid question, and maybe it's not the > right place to post....BUT I'm wondering if there > exists a line of fast (> 133 Mhz) Fifos with capacity > on the order of 8-16Mbits. I know I can use a generic > memory and implement the controller myself, but > I'm just wondering if I can get away with being lazy. > > Thanks, > LisArticle: 55681
This was many years ago (XC3000 and XC4000 days). Might have been ceramic packages, which were more prevalent in those days. Definitely no prescreening or other special help, but the customers were very happy. Customers were usually located either in Texas, or in Paris (France) or in Norway... In those days, configuration was more tricky and sensitive, so they did not reconfigure in the bowels of the earth. Their attitude was: "I have no other choice, I love you if it works". Would be nice if all customers were that grateful... BTW, did you read the news that some scientists want to drop an "intelligent ball" to the center of the earth, or at least deep into the magma, floating down surrounded by hundreds of kilotons of liquid iron. Not such a friendly FPGA application... :-) Peter Alfke ================================ Eric Smith wrote: > > Peter Alfke <peter@xilinx.com> writes: > > Silicon is one tough material ! The 125 or even 150 degree limit is > > more a plastic package issue than a silicon issue. I have helped > > down-hole ( oil-drilling) applications where our chips functioned (with > > relaxed performance) for many weeks at 175 degree ambient, and the user > > was pushing for 200 degrees. They used Xilinx FPGAs, Z80 uPs, SRAMs and > > even some analog stuff "down there". This worked, but we never > > guaranteed it. > > Using plastic- or ceramic-packaged parts? Were the parts pre-screened > for high-temperature operation before use in the final application?Article: 55682
Followup to: <3EC3BE88.EE8C08A8@xilinx.com> By author: Peter Alfke <peter@xilinx.com> In newsgroup: comp.arch.fpga > > Silicon is one tough material ! The 125 or even 150 degree limit is > more a plastic package issue than a silicon issue. I have helped > down-hole ( oil-drilling) applications where our chips functioned (with > relaxed performance) for many weeks at 175 degree ambient, and the user > was pushing for 200 degrees. They used Xilinx FPGAs, Z80 uPs, SRAMs and > even some analog stuff "down there". This worked, but we never > guaranteed it. > Well, let's be clear about this... There are a few places where thermals come into play: a) The packaging, obviously. b) Thermal stress. This is a dTj/dt issue more than a Tj issue. The main problem with thermal stress is that it can cause the silicon, metal layers, and package pads to crack apart. c) Metal mobility. The aging of the chip goes up exponentially with temperature. And yes, modern silicon chips do age. Thus, when specifying a maximum temperature, semiconductor manufacturers have to take into account the lifetime of the part. The oil-drilling customer probably doesn't care if the parts wear out after 3 months, but most electronic customers would be pissed as hell. d) Temperature-dependent electrical properties. As the temperature increases, resistance goes up, and the ground state population of electrons and holes goes up exponentially. This will generally cause circuit malfunction, but not damage. For CMOS, running at a slower speed helps. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 55683
Once I have time to upgrade my current box from '98 (which I trust) to XP or 2K (neither of which I trust), which change is planned for a week or two from now, I'll undoubtedly switch to whatever the current freeware (WEBPACK?) is. I'm probably done with buying software from XILINX, though. What my problem here has been is an unwillingness of the software to implement constraints clearly spelled out in the User Constraint File (UCF), which I'd have thought would have precedence over defaults that are hidden where you can't see 'em. It's taken me almost two weeks to get this EVB (and it's not the board's fault!) to produce output. Not even a simple buffer which puts out a clock coming in on a global clock pin was trivial to make appear, and it still doesn't routinely work. Multiple compiles (RERUN ALL) of the same source seemingly produces arbitrarily different output, though it just as frequently produces the same, but erroneous, output. What I used to test the entry system was a set of equations that I wanted to ABEL from PALASM, easily accomplished via the @alternate directive, but that quickly fell apart as I (not an ABEL expert) couldn't figure out how to port the case statements that represent a couple of muxes. Subsequently I simply used ECS to enter the little test circuit in schematic form. Doing this in PALASM for a 24-pin PAL took less than half a day including the time to build a board and assemble it. I've gotten the thing to work on the EVB, though all bets are off if I have to reprogram the board again. I've been frustrated somewhat by the software's unwillingness to implement constraints such as PULLUP ( which apparently conflicts with the hidden "KEEPER" attribute) and my own inability to distinguish between FAST slew on the output and SLOW slew rate, which appears to differ only by a nanosecond or two, but that's probably because of the absence of a realistic load. The 1.2 volts of overshoot/undershoot and half volt of ringing (3.3-volt I/O) are probably because of the long traces leading to the connector pins. Since we've talked I guess we agree that there really isn't a good ground reference on the board to which one can attach probes, etc. That and the lead lengths to the connectors are probably the only problems with the board itself, and, aside from, maybe, providing a good ground reference, I doubt the EVB could have been done much better. I appreciate the help offerred by the several folks who've contacted me via email. It's been enlightening. I'm sure some of you have been amused with the 'scope display pic's I sent. Nevertheless, I'm still frustrated about the state of the software. If any of our software guys offerred to release something that behaved as peculiarly as this, my boss would probably take 'em out back and shoot 'em. That's just a culture thing, though. Richard Erlacher "Mark Ng" <markn@xilinx.com> wrote in message news:3EC284EA.80994B92@xilinx.com... > Hi Dick - > > Make sure you are using 5.2i with Service Pack 2. > > The versions that you mentioned (i.e. 4.2 and 5.1) have known bugs. Your > issues should be solved with 5.2 SP2. > > Let me know if you continue to have problems... > > Thanks! > Mark > > Richard Erlacher wrote: > > > I have implemented what amounts to a pretty simple design in the EV-module > > that XILINX was giving away late last year to promote their CoolRunner-II > > CPLD's. This isn't a bad board and it seems easy enough to use, BUT (and > > that's what so frequently comes up with XILINX software) the software > > doesn't seem, quite, to get the job done. There is a very rich feature set > > associated with this CPLD family, and their pricing is not too bad, but the > > ISE software doesn't seem to want to implement the functions correctly, or > > even consistently from download to download. > > > > Has anybody else had such problems, or any experience to the contrary with > > this series, and, specifically, with the last two versions (v4.2, v5.1) of > > the ISE software? > > > > I've got lots of details, but won't bore the group with the specifics. > > > > thanx, > > > > Dick >Article: 55684
H. Peter Anvin wrote: > > Followup to: <3EC3BE88.EE8C08A8@xilinx.com> > By author: Peter Alfke <peter@xilinx.com> > In newsgroup: comp.arch.fpga > > > > Silicon is one tough material ! The 125 or even 150 degree limit is > > more a plastic package issue than a silicon issue. I have helped > > down-hole ( oil-drilling) applications where our chips functioned (with > > relaxed performance) for many weeks at 175 degree ambient, and the user > > was pushing for 200 degrees. They used Xilinx FPGAs, Z80 uPs, SRAMs and > > even some analog stuff "down there". This worked, but we never > > guaranteed it. > > > > Well, let's be clear about this... > > There are a few places where thermals come into play: > > a) The packaging, obviously. > > b) Thermal stress. This is a dTj/dt issue more than a Tj issue. The > main problem with thermal stress is that it can cause the silicon, > metal layers, and package pads to crack apart. <snip> Plus there is a special stress case, in passing thru 100'C, where the moisture in the package turns to steam. This is why most packages come dry-packed, to reduce the stress caused by the reflow cycle. Close to everything that's shipped has to at least pass down a soldering line, so must tolerate > 240'C, albeit briefly. -jgArticle: 55685
Richard Erlacher wrote: > > Once I have time to upgrade my current box from '98 (which I trust) to XP or > 2K (neither of which I trust), which change is planned for a week or two > from now, I'll undoubtedly switch to whatever the current freeware > (WEBPACK?) is. I'm probably done with buying software from XILINX, though. > > What my problem here has been is an unwillingness of the software to > implement constraints clearly spelled out in the User Constraint File (UCF), > which I'd have thought would have precedence over defaults that are hidden > where you can't see 'em. > > It's taken me almost two weeks to get this EVB (and it's not the board's > fault!) to produce output. Not even a simple buffer which puts out a clock > coming in on a global clock pin was trivial to make appear, and it still > doesn't routinely work. Multiple compiles (RERUN ALL) of the same source > seemingly produces arbitrarily different output, though it just as > frequently produces the same, but erroneous, output. What I used to test > the entry system was a set of equations that I wanted to ABEL from PALASM, > easily accomplished via the @alternate directive, but that quickly fell > apart as I (not an ABEL expert) couldn't figure out how to port the case > statements that represent a couple of muxes. Subsequently I simply used ECS > to enter the little test circuit in schematic form. Doing this in PALASM > for a 24-pin PAL took less than half a day including the time to build a > board and assemble it. I've gotten the thing to work on the EVB, though all > bets are off if I have to reprogram the board again. > > I've been frustrated somewhat by the software's unwillingness to implement > constraints such as PULLUP ( which apparently conflicts with the hidden > "KEEPER" attribute) <snip> Most CPLD sw creates a fitter report file (.RPT), and a Fuse file (.JED). I'd save these from two different sessions, then compare the HW results with the file contents. That will nail down if it's SW or HW that's driving the erratic changes. The fuse files are low level, but ASCII so can be compared. The RPT files have (hopefully) full and accurate info on how the design mapped, and it should also report the NETT constraint, so you can figure out which is winning, or if it is even seeing your's. -jgArticle: 55686
Richard Erlacher <richard_no_junk_mail_4_me at idcomm.com> wrote: : Once I have time to upgrade my current box from '98 (which I trust) to XP or : 2K (neither of which I trust), which change is planned for a week or two : from now, I'll undoubtedly switch to whatever the current freeware : (WEBPACK?) is. I'm probably done with buying software from XILINX, though. I run Webpack with Linux/Wine. No need for XP beside wine emulating XP :-) *) : What my problem here has been is an unwillingness of the software to : implement constraints clearly spelled out in the User Constraint File (UCF), : which I'd have thought would have precedence over defaults that are hidden : where you can't see 'em. Constaints work for me ( pin placement, setting slew rate). With the relativ fixed timing model, however timing constraints probably won't help much. Either the logic can be implemented with the speed you need and the way you write it, or not, but timing constraints won't help for a CPLD. : It's taken me almost two weeks to get this EVB (and it's not the board's : fault!) to produce output. Not even a simple buffer which puts out a clock : coming in on a global clock pin was trivial to make appear, and it still : doesn't routinely work. Multiple compiles (RERUN ALL) of the same source : seemingly produces arbitrarily different output, though it just as : frequently produces the same, but erroneous, output. What I used to test : the entry system was a set of equations that I wanted to ABEL from PALASM, : easily accomplished via the @alternate directive, but that quickly fell : apart as I (not an ABEL expert) couldn't figure out how to port the case : statements that represent a couple of muxes. Subsequently I simply used ECS : to enter the little test circuit in schematic form. Doing this in PALASM : for a 24-pin PAL took less than half a day including the time to build a : board and assemble it. I've gotten the thing to work on the EVB, though all : bets are off if I have to reprogram the board again. I can't imagine that any schematic entry for pure logic is mostly fun. When I tried to implement some module in ECS for better documentation, I nearly got crazy. Take the time to learn HDL, keeping the structure of the target hardware in mind. It probably will pay off. : I've been frustrated somewhat by the software's unwillingness to implement : constraints such as PULLUP ( which apparently conflicts with the hidden : "KEEPER" attribute) and my own inability to distinguish between FAST slew on : the output and SLOW slew rate, which appears to differ only by a nanosecond : or two, but that's probably because of the absence of a realistic load. The : 1.2 volts of overshoot/undershoot and half volt of ringing (3.3-volt I/O) : are probably because of the long traces leading to the connector pins. Keep in mind that you can use either KEEPER or PULLUP on one chip, but not together. I've learnd the hard way too. How do you measure overshoot/undershoot? Remember to ground the probe as short as possible to a good ground, or otherwise you get a false indication. Try with the SLOW attribute if ringing really bugs that design. For me, the .tim Timing report reports 4 ns more delay for a -7 device. : Since we've talked I guess we agree that there really isn't a good ground : reference on the board to which one can attach probes, etc. That and the : lead lengths to the connectors are probably the only problems with the board : itself, and, aside from, maybe, providing a good ground reference, I doubt : the EVB could have been done much better. A multilayer board with a dedicated ground layer and probe attach points would help. : I appreciate the help offerred by the several folks who've contacted me via : email. It's been enlightening. I'm sure some of you have been amused with : the 'scope display pic's I sent. : Nevertheless, I'm still frustrated about the state of the software. If any : of our software guys offerred to release something that behaved as : peculiarly as this, my boss would probably take 'em out back and shoot 'em. : That's just a culture thing, though. At least the webpack people are responsive to error reports. I've seen other behaviour in other cases... Bye *) Webpack/Linux/Wine is not for the faint hearted... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 55687
As sophisticated electronics find their way more and more out of air-conditioned offices and living rooms into uglier environments, like factories, telephone posts, automobiles, airplanes and spacecrafts, it is high time that the manufacturers and the user community both develop a better understanding of thermal issues. There is still a lot of wishful thinking and naďvite on both sides of the aisle. What is the meaning of the a in Ta? Ambient, where? The chip is never affected by Ta, only by Tj. How are these two related? What's the max power to be dissipated? How accurate is Theta case-to-ambient? Is every parameter guaranteed for 20-year continuous worst-case operation? Should it be? How's about thermal cycling that used to bother power transistors? 20-W integrated circuits are a reality, 50 W is on the horizon, perhaps 100 W later. Heat-pipes? Evaporative cooling? Peltier? Who is interested in facing all the ugly ramifications, some of them expensive, and take the problems head-on? These things deserve more attention, and less blissful neglect. The user must also accept the burden for part of the solution... Peter Alfke, speaking for himself.Article: 55688
In article <3EC413DA.FF1F85F4@xilinx.com>, Peter Alfke <peter@xilinx.com> wrote: >20-W integrated circuits are a reality, 50 W is on the horizon, perhaps >100 W later. Heat-pipes? Evaporative cooling? Peltier? Who is interested >in facing all the ugly ramifications, some of them expensive, and take >the problems head-on? Well, some of these are being tackeled by Intel out of necessity. The latest IA64 burns 135 watts (and 90 amps!) peak, the HP Itanium boxes use custom designed heatsinks and carefully engineered airflow patterns. Likewise, Shuttle has developed passive heatpipe-based heatsinks, as have some notebook manufacturers, mostly to save space and allow higher-volume, lower-velocity heatsink fans. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 55689
Hello, What would be the simplest and smallest CPU core for an FPGA ? I saw a lot of cores that mimic existing controllers but I would not mind to have something simpler. Low LE count is my goal. Anybody had similar objectives? Any ideas ? Would somebody point me in the right direction ? Thanks. Luis Cupido. P.S. - The application is logic intensive (a very large correlator) however the system output happens only once every second. Using logic for the output processing become tremendously big, a total waist of resources for something that happens only once every second.Article: 55690
In article <3EC3FC59.5F38E97B@xilinx.com>, Peter Alfke <peter@xilinx.com> wrote: >BTW, did you read the news that some scientists want to drop an >"intelligent ball" to the center of the earth, or at least deep into the >magma, floating down surrounded by hundreds of kilotons of liquid iron. >Not such a friendly FPGA application... :-) Mostly a paper exercise, as it does require both a lot of iron and a 7 megaton nuke. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 55691
On Thu, 15 May 2003 15:52:51 -0700, lc wrote: > Hello, > > What would be the simplest and smallest CPU core for an FPGA ? I saw a > lot of cores that mimic existing controllers but I would not mind to > have something simpler. Low LE count is my goal. > > Anybody had similar objectives? Any ideas ? Would somebody point me in > the right direction ? > > Thanks. > > Luis Cupido. > > P.S. - The application is logic intensive (a very large correlator) > however the system output happens only once every second. Using logic > for the output processing become tremendously big, a total waist of > resources for something that happens only once every second. If its for a Xilinx FPGA take a look at the KCPSM/PicoBlaze. It's quite small but still very usable, main limitation is 256 max instruction unless you want to do program memory bank switching... PCWArticle: 55692
Hi, PicoBlaze from Xilinx should fit your need. It's the smallest and simplest CPU core for a FPGA. Göran lc wrote: > Hello, > > What would be the simplest and smallest CPU core for an FPGA ? > I saw a lot of cores that mimic existing controllers > but I would not mind to have something simpler. > Low LE count is my goal. > > Anybody had similar objectives? Any ideas ? > Would somebody point me in the right direction ? > > Thanks. > > Luis Cupido. > > P.S. - The application is logic intensive (a very large correlator) > however the system output happens only once every second. > Using logic for the output processing become tremendously big, > a total waist of resources for something that happens only once > every second.Article: 55693
Followup to: <3EC413DA.FF1F85F4@xilinx.com>
By author: Peter Alfke <peter@xilinx.com>
In newsgroup: comp.arch.fpga
>
> What is the meaning of the a in Ta? Ambient, where? The chip is never
> affected by Ta, only by Tj. How are these two related? What's the max
> power to be dissipated? How accurate is Theta case-to-ambient?
>
You almost certainly know this just as well as I do, but for the
people who don't:
Thermals can be modelled using the same rules as electrical circuits,
since the law for thermal flow are very similar to Kirchhoff's Laws
for electricity. The main difference is that a heat source can
actually create heat (from other forms of energy), whereas there is no
way to create charge, of course. However, this is easily compensated
for by modelling the non-heat energy flow as an incoming current from
"ground" (ambient).
The most variables (units) you need to switch is:
voltage (V) <-> temperature (K)
current (A) <-> heat flow (W)
charge (C) <-> heat (J)
resistance (ohm) <-> thermal resistance (K/W)
capacitance (F) <-> heat capacity (J/K)
... and so on. Note also that power is determined entirely by the
heat flow ("current").
A typical steady-state (DC) model of a simple component without
active cooling could look something like:
Rjp Tp Rpa
Tj +-------/\/\/\-----+-----/\/\/\----+ Ta
| |
/^\ |
\|/Pj |
| |
+----------------------------------+
|
AMBIENT
(GND)
Thus, Tj = Ta + Pj(Rjp + Rpa).
Rjp is the thermal resistance from junction to package exterior; Rpa
is the thermal resistance from package to ambient. The latter is
affected by heat sinks and convection, the former is not.
This also means that if you need to lower Tj below Ta + Pj Rjp,
passive cooling (including fans) is no longer acceptable. Either Ta
must be lowered (by dumping heat to a cooler "ambient") or some kind
of heat pumping (such as phase-change or Peltier cooling) needs to be
applied.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Article: 55694In article <3EC422C8.567380EA@Xilinx.com>, Goran Bilski <Goran.Bilski@Xilinx.com> wrote: > >PicoBlaze from Xilinx should fit your need. >It's the smallest and simplest CPU core for a FPGA. I'm curious, why do they offer a PicoBlaze for Coolrunner but not for XC9500? Their comparison charts don't make those product lines look too different, beyond power consumption. -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 55695
"lc" <cupido@kkk.mail.ua.pt> wrote in message news:1053038695.922327@newsfront2... > Hello, > > What would be the simplest and smallest CPU core for an FPGA ? > I saw a lot of cores that mimic existing controllers > but I would not mind to have something simpler. > Low LE count is my goal. > > Anybody had similar objectives? Any ideas ? > Would somebody point me in the right direction ? > > Thanks. > > Luis Cupido. > > P.S. - The application is logic intensive (a very large correlator) > however the system output happens only once every second. > Using logic for the output processing become tremendously big, > a total waist of resources for something that happens only once > every second. CPU is a very loose term. I would say a counter and a table in block ram would be your smallest CPU, with the bits from the block ram driving whatever processes need to run. RalphArticle: 55696
Nicholas C. Weaver wrote: > > In article <3EC413DA.FF1F85F4@xilinx.com>, > Peter Alfke <peter@xilinx.com> wrote: > > >20-W integrated circuits are a reality, 50 W is on the horizon, perhaps > >100 W later. Heat-pipes? Evaporative cooling? Peltier? Who is interested > >in facing all the ugly ramifications, some of them expensive, and take > >the problems head-on? > > Well, some of these are being tackeled by Intel out of necessity. The > latest IA64 burns 135 watts (and 90 amps!) peak, the HP Itanium boxes > use custom designed heatsinks and carefully engineered airflow > patterns. > > Likewise, Shuttle has developed passive heatpipe-based heatsinks, as > have some notebook manufacturers, mostly to save space and allow > higher-volume, lower-velocity heatsink fans. I've seen some impressive numbers on Silicon Carbide based semiconductors :) -jgArticle: 55697
"Ben Jackson" <ben@ben.com> wrote in message news:U3Wwa.896193$S_4.913293@rwcrnsc53... > In article <3EC422C8.567380EA@Xilinx.com>, > Goran Bilski <Goran.Bilski@Xilinx.com> wrote: > > > >PicoBlaze from Xilinx should fit your need. > >It's the smallest and simplest CPU core for a FPGA. > > I'm curious, why do they offer a PicoBlaze for Coolrunner but not for > XC9500? Their comparison charts don't make those product lines look > too different, beyond power consumption. I curious what purpose it actually serves??? Why would you want to use an expensive CPLD and external flash to perform less functions than a $1 micro controller? RalphArticle: 55698
Hi Mike, Yes, you are right to synchronize the outputs. But its still glithcy as the problem is not originate from this issue. It should be the P&R delays of the primitives in the FPGA. I think I needs tech support from the FPGA vendor. Thanks Mike. Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3EC3D03E.20100@flukenetworks.com>... > Wong wrote: > > > Here's the code. Its fine with the functional simulation but after > > P&R, I have the problems as mentioned. Thanks. > > The glitches are coming from your combinational outputs. > > Consider getting rid of next_state and the combinational process. > and putting all the code into a single case of current_state > in the synchronous process elsif clause. > > That would give you synchronous outputs by default. > > -- Mike TreselerArticle: 55699
Ralph Mason wrote: > > "Ben Jackson" <ben@ben.com> wrote in message > news:U3Wwa.896193$S_4.913293@rwcrnsc53... > > In article <3EC422C8.567380EA@Xilinx.com>, > > Goran Bilski <Goran.Bilski@Xilinx.com> wrote: > > > > > >PicoBlaze from Xilinx should fit your need. > > >It's the smallest and simplest CPU core for a FPGA. > > > > I'm curious, why do they offer a PicoBlaze for Coolrunner but not for > > XC9500? Their comparison charts don't make those product lines look > > too different, beyond power consumption. > > I curious what purpose it actually serves??? > > Why would you want to use an expensive CPLD and external flash to perform > less functions than a $1 micro controller? > > Ralph I can think of a few, but none rank as 'commercial deployment' :) a) To prove it can be done ( viz marketing asked for it ) b) To test a tool flow c) As an education/teaching example -jg
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