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
In article <3BC6EA86.82FC088B@andraka.com>, Ray Andraka
<ray@andraka.com> writes
>A comparator is relatively slow, and uses nearly as many LUTs as a
>counter. For FPGAs, a better solution is to use two counters: a frame
>counter to set the period (constant) and a second duty cycle counter. The
>TC on the frame counter loads the duty cycle counter and sets an RS
>flip-flop. The TC on the duty cycle counter (a downcounter) resets the RS
>flip-flop. The TC is the carry out on both counters, so uses no additional
>logic. If both counters are downcounters, you can program the period as
>well as the duty cycle.
There is another approach. No comparator, no counter. Needs an adder
with a carry-in and carry-out, but that's no big deal. Its internal
register is one bit wider than the PWM demand input. The really
interesting thing about this implementation is that it minimises the
low-frequency components in the PWM output waveform, thus making
output filtering a bit easier.
It has two other neat features that make it better than standard PWM
for many applications. FIrst-off, the output updates immediately
when you change the demand input - you don't have to wait for a
complete PWM cycle to elapse. Second, you get the full range of
demand: for a 4-bit input, 0000 would give permanently-off and
1111 would give permanently-on.
Try it in simulation, with a reasonably small (4-bit?) input...
Think Bresenham's algorithm, first-order delta-sigma, binary
rate multiplier.....
---------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity PWM is
port (
clk, rst: in std_logic;
D: in std_logic_vector;
Q: out std_logic
);
end;
architecture distributed_pulses of PWM is
signal acc: unsigned (D'LENGTH downto 0); -- one bit bigger than D
begin
Q <= acc(D'LENGTH); -- the carry bit provides PWM output
process (clk, rst)
begin
if rst = '1' then
acc <= (others => '0');
elsif rising_edge(clk) then
acc <= ('0' & acc(D'LENGTH-1 downto 0)) -- all but the carry
+ unsigned(D) -- input demand
+ acc(D'LENGTH downto D'LENGTH); -- the carry bit
end if;
end process;
end;
---------------------------------------------------------
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 35651
Don Husby wrote:
>
> You'd think a simple 56-bit counter would be no
> problem. The code below should synthesize to
> 1 logic level using 56 LUTs, 56 FFs and a carry chain.
> Instead, Synplicity adds an extra 57 LUTs and an extra
> level of logic.
>
What Synplify version/ FPGA / target frequency are you using?
I've seen results like this before, where Synplify seems to
"try too hard" to hit a speed target, replacing a simpler
implementation with a more complex one as you pass a certain
frequency constraint, particularly when long carry chains are
involved.
Taking your counter code:
`define CNT_MSB 55
module Cnt56(K, CE, R, Out);
input K, CE, R;
output [`CNT_MSB:0] Out;
reg [`CNT_MSB:0] Q;
assign Out= Q;
always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;
endmodule
And tweaking counter size/target frequency, gives:
Synplify Synplify
CNT_MSB Frequency LUT count
__________________________________________
55 77 57
55 78 110
31 95 33
31 96 46
31 122 46
31 123 83
when using Synplify 6.2.4 & XCV600E-6.
Below a certain target frequency, it does hit about 1-LUT per
bit, albeit without using the sync. reset.
You could probably fake Synplify out by putting a dummy
frequency or multicycle constraint on the counter, then nuke
it from the .ncf file before running the back-end tools.
Brian
Article: 35652Dies ist eine mehrteilige Nachricht im MIME-Format. --------------93029E34D87DBD6AD60FC94C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo usergroup, in our lab we are working with a PCB assembled with a Virtex 1000 E BGA device. For a bigger FPGA design we want to replace this by a Virtex 2000E BGA (means to take of the 1000E and resolder the 2000E). Has anybody experience on that? Is it possible and what company inside Germany can do that job? It is clear to us that this is a risk. Thanks in advance. Juergen Otterbach --------------93029E34D87DBD6AD60FC94C Content-Type: text/x-vcard; charset=us-ascii; name="juergen.otterbach.vcf" Content-Transfer-Encoding: 7bit Content-Description: Visitenkarte für Juergen Otterbach Content-Disposition: attachment; filename="juergen.otterbach.vcf" begin:vcard n:;Juergen Otterbach x-mozilla-html:FALSE version:2.1 email;internet:juergen.otterbach@t-online.de x-mozilla-cpt:;65535 fn:Juergen Otterbach end:vcard --------------93029E34D87DBD6AD60FC94C--Article: 35653
Andrew Brown schrieb: > > You can't be seriously saying "Hello World" is an appropriate use of C++ No. > But VHDL is a very structured language which should make larger designs Yes. > easier. (lets not start he VHDL/verilog war here). ;-) -- MFG FalkArticle: 35654
Well, the companies seem to focus on patents. The list of patents shown on the Altera MaxPlus2 splash screen is rather long. Assuming a lousy patent lawyer costs 3 times more than a decent engineer, it is obvious that there a few reources left to write a useable tool. Then on the other hand the market for those kind of software is not that big. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com Don Husby wrote: > > > > Which brings me to my point: > High level, abstract synthesis will never work well. I realize > this is an extreme statement, but if today's synthesizers can't > do better than a factor of 2 for really simple code, it's > hard to imagine a synthesizer in the near future that can > compile complex code efficiently.Article: 35655
The one wish I had regarding these parts was the CLK input to have a schmitt trigger on it. I have designed several complicated waveform generators, each containing 32 or 64 FPGAs (XC3k and XC4k devices). I had enormous problems distributing the config clock around these boards, which were IBM PC full-size with devices both sides. Loads of decoupling, 6 layers (incl. VCC and GND planes), very careful tracking, you name it. The config clock input is extremely sensitive to risetime. Too slow, it won't work, too fast and it cannot be distributed to many devices. I vaguely recall that it has to be faster than 20ns, and driving it from a 74HC output was too slow.Article: 35656
BGAs are soldered in vapor phase at 220++ degrees. You're expecting a robot in there to lift your component off ? Hard to imagine. However unsoldering everything should be simple - insert it upside down and let gravity work for you. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com Juergen Otterbach wrote: > > Hallo usergroup, > in our lab we are working with a PCB assembled with a Virtex 1000 E BGA > device. > For a bigger FPGA design we want to replace this by a Virtex 2000E BGA > (means to take of the 1000E and resolder the 2000E). > > Has anybody experience on that? Is it possible and what company inside > Germany can do that job? > It is clear to us that this is a risk. > > Thanks in advance. > Juergen OtterbachArticle: 35657
Forget it unless you've got all the necessary kit (robotics etc). BGA's are a nightmare to remove, and even worse to replace - very unreliable. Not too sure if there are many companies willing/able to do this kind of work, but if there are it won't be cheap. Would it not be better to get some kind of adapter board made up? "Rene Tschaggelar" <tschaggelar@dplanet.ch> wrote in message news:3BC74422.710CB0E6@dplanet.ch... > BGAs are soldered in vapor phase at 220++ degrees. > You're expecting a robot in there to lift your component off ? > Hard to imagine. > However unsoldering everything should be simple - insert it > upside down and let gravity work for you. > > Rene > -- > Ing.Buero R.Tschaggelar - http://www.ibrtses.com > > > > > Juergen Otterbach wrote: > > > > Hallo usergroup, > > in our lab we are working with a PCB assembled with a Virtex 1000 E BGA > > device. > > For a bigger FPGA design we want to replace this by a Virtex 2000E BGA > > (means to take of the 1000E and resolder the 2000E). > > > > Has anybody experience on that? Is it possible and what company inside > > Germany can do that job? > > It is clear to us that this is a risk. > > > > Thanks in advance. > > Juergen OtterbachArticle: 35658
I would think that a built-in crystal oscillator port would be a great option. Also, I personally would like to see real LVPECL (i.e.suitable for single ended LVPECL inputs) with real LVPECL levels. Also packages with pins (SMT pins are OK but not those ball grid arrays) for those who are using FPGA's as a short production run (read PROTOTYPE) device. Theron HicksArticle: 35659
Ray Andraka <ray@andraka.com> wrote in message news:<3BC6E69A.23A907BF@andraka.com>... > Right. Did you also have an explicit global reset? No. I've given up trying to use GSR, except for post-PAR simulations. Although GSR is a completely different issue, it seems to me that it would almost be trivial to implement it using the syntax for variable initialization. VHDL allows a signal (register) to be initialized when declared. Verilog has the "initial" construct. It should be fairly easy to infer GSR from these, and it would make simulation agree with synthesis.Article: 35660
Hello This is a concern to me, Can you provide an on-line reference to this document? Regards, Gerry. In article <99e2931.0110120320.49cf9aba@posting.google.com>, M. Praekelt <martp@hotmail.com> writes >Hello, >as I read in comp.arch.embedded most i186 and i486 derivates build by >AMI are discontinued. >Now we got an announcement that this is the case also for a great >bunch of MACH circuits produced for LATTICE in AMDs FAB 14 (which is >intended to be closed). >The list of devices in the PDF document spans 8 pages and contains >PALCE PALLV devices, MACH1xx, MACH 2xx, MACH4xx M4-xx and M5-xxx >devices! > >Last order is 31 dec 2001 and last delivery 31 dec 2002!!!! > >I have posted this using another mail server a day ago, but I havent >seen it up to now. >I apologize if this message is reaching you twice. > >Perhaps we are the only ones around using this old-fashioned >programmable devices.... > > >BTW: On http://www.latticesemi.com/products/mature/index.cfm >you cannot read **anything** about this up to now (12 oct 2001, 11:20 >UT) -- Regards, Gerry www.robot-electronics.co.ukArticle: 35661
Arthur Sharp wrote >I'm after a small (credit card size or not a lot larger) FPGA prototype Ray Andraka <ray@andraka.com> wrote in message news:<3BC6EADF.19E7A24C@andraka.com>... >> Annapolis Micro has one too(PCMCIA). Hold onto your wallet though. What form factor are you looking for exactly?, the Nallatech PCI boards can carry Dime modules that you can design for. Insite also has some low cost PCI/Dime compatible boards but PCI license is an issue. I think they have a $350 board (-PCI core), with PCI core in the Spartan2 200. I saw Annapolis Micro at Embedded Show in Boston, they reminded me that though the idea of compact card form is neat, the PCMCIA Laptop standard simply can not provide the juice needed to do anything really cool. The card is normally a virtex 300 I think it is available for $1k but you can't fill it with high speed logic & get enough juice from the socket. Although much bigger parts could replace the 300, still not enough juice. Any PCMCIA design would have to be slow. Also there was and maybe are DIMM type cards around but not available. Nuron was doing these but seems to have disappered (and was extremely expensive anyway). Also I think PSU (Penn State I think) has a project, it was posted here 2 months or so ago (Aug 16) but they told me no commercial plans. I would think DIMM modules would also have the same power issues as PCMCIA. Looks like most of the smaller boards (XESS etc) are for tiny Spartans etc. There are also PC104 boards (APS I think) that have virtex 800 Just some ideas John JaksonArticle: 35662
Consider adding a two flop Clk2 synchronizer on the output of your Reg1. Then you can just check static timing on Clk2 and ignore Clk1. --Mike TreselerArticle: 35663
We are here... We do appreciate getting small examples that demonstrate potential improvements. In general there is no need to go to the effort to produce the structural form. All we need is a short description of what we missed - "You should have used the synch reset instead of building it in logic in front of the flip-flop". We have a large queue of improvements sorted by a function of how common they are, how much gain we are likely to get and how hard they are to implement. This doesn't mean that you shouldn't bother to tell us about your desired improvement. Even if we already have it in our queue, you are bumping our notion of how common the problem is. The best way to send us such a test case is via email at support@synplicity.com Please put both "QOR" and the target FPGA in the subject to help us route it. The FPGA synthesis development team is pretty large. Thanks, Ken McElvain, CTO Andrew Brown wrote: > I think synplify and all other vendors should have a simple process for > improving synthesis aldorithms. If we can provide them with source - the > output from their tool and a 'structural' source which is a 'better' > implementation, they should ensure future versions of their tool can > optomise the design. Granted this is complicated by design requirements > such as GSR and other resets in this case - but if we supply simplified > example code they should beable to improve their engine. To be fair to > them - it's damn hard to imagine situations your engine isn't good at off > the top of your head so you can improve it. > > Anyone from synplify out there??? > > A. > > >Article: 35664
Juergen Otterbach wrote:
>
> Hallo usergroup,
> in our lab we are working with a PCB assembled with a Virtex 1000 E BGA
> device.
> For a bigger FPGA design we want to replace this by a Virtex 2000E BGA
> (means to take of the 1000E and resolder the 2000E).
Removing and replacing a BGA device is not
a problem for any manufacturing facility
with a BGA rework station.
Of course, you have to throw the old part away.
Without the proper equipment and skills
however, you may well destroy the board.
--Mike Treseler
Article: 35665Yes to all of those - I would love to see the Virtex programmable termination feature (I forget the marketing name) enhanced to support - WITHOUT external resistive dividers - LVDS and PECL I/O, and to support programmable DIFFERENTIAL termination as well. Well, I can wish, can't I? For prototypes, and for some types of production, I would be content with being able to buy BGAs from Xilinx or via distros pre-soldered to BGA-socket/adapter thingies such as http://www.mill-max.com/products/bga/bga.htm rather than having to deal with getting this done myself. This would be an optional service that could simplify things for a lot of people, I think. To solve the slow global reset problem, how about circuitry on each clock buffer that could disable it during reset, then synchronously re-enable it N clocks after end of reset, where N is programmable (0 for no delay), up to some reasonable maximum sufficient to accomodate the reset recovery time and max clock rate. Or some simpler scheme that would accomplish the same thing. Theron Hicks wrote: > > I would think that a built-in crystal oscillator port would be a great > option. Also, I personally would like to see real LVPECL (i.e.suitable > for single ended LVPECL inputs) with real LVPECL levels. Also packages > with pins (SMT pins are OK but not those ball grid arrays) for those who > are using FPGA's as a short production run (read PROTOTYPE) device. > > Theron Hicks -- Tom Burgess Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3Article: 35666
Hello there,
The past few days I have been trying to come up with a way to describe a
generic pulse generator in Verilog (or VHDL) using shift registers. What I
would like it to do is to take an arbitrary pulsetrain as a parameter (for
example "100110") and then generate this pulse train repeatedly from an
incoming clock signal. However, each bit in the pulse train corresponds to
half an incoming clockcycle! I came up with the following scheme to do this:
I implement two rotating shift registers (A and B) of three bits wide, one
that is sensitive to the positive clock edge and one on the negative. I
initialise one with the even bits of the pulse train ("101") and one with
the odd ("010") and I let them run on the incoming clock.
Then I generate a signal from the incoming clock, which simply follows this
clock (using two flip flops, one positive and one negative edge sensitive),
and I use this signal to either choose the output of shift register A or
shift register B and this is then the output of the whole circuit.
However, the output of this circuit is going to be used as a clock which
feeds other circuits, so it should be glitch free. This is not always the
case in my present design (I think). Is there some way to make my design
glitch free? As the output changes on both positive and negative clock edge,
I can´t put a simple register on the output :-( And I prefer not to use
PLL´s or DLL´s (which may be used to generate the double clock frequency to
make everything sensitive to the positive clock edge only).
Any help is greatly appreciated!
Regards,
Johan Ditmar
Article: 35667In article <99e2931.0110120320.49cf9aba@posting.google.com>, M. Praekelt <martp@hotmail.com> wrote: >Hello, >as I read in comp.arch.embedded most i186 and i486 derivates build by >AMI are discontinued. >Now we got an announcement that this is the case also for a great >bunch of MACH circuits produced for LATTICE in AMDs FAB 14 (which is >intended to be closed). >The list of devices in the PDF document spans 8 pages and contains >PALCE PALLV devices, MACH1xx, MACH 2xx, MACH4xx M4-xx and M5-xxx >devices! > >Last order is 31 dec 2001 and last delivery 31 dec 2002!!!! > >I have posted this using another mail server a day ago, but I havent >seen it up to now. >I apologize if this message is reaching you twice. > >Perhaps we are the only ones around using this old-fashioned >programmable devices.... > > >BTW: On http://www.latticesemi.com/products/mature/index.cfm >you cannot read **anything** about this up to now (12 oct 2001, 11:20 >UT) ----------------------------------- Read the URL you posted: -- Lattice says: "The product families on this page have been classified as "Mature" as they have been superceded by product families which utilize our more advanced process technologies required to meet the design needs of today's system logic designers. Unless a Mature Family has been formally upgraded via our Product Change Notification procedure (highlighted with an *), Lattice will continue to support all existing business for these Mature products. There are no near-term plans to obsolete any of these Mature product families. Designers working on new designs are strongly encouraged to evaluate the alternative product families listed in the "Use for New Designs" column." -- -Steve -- -Steve Walz rstevew@armory.com ftp://ftp.armory.com/pub/user/rstevew -Electronics Site!! 1000 Files/50 Dirs!! http://www.armory.com/~rstevew Europe Naples, Italy: ftp://ftp.unina.it/pub/electronics/ftp.armory.comArticle: 35668
"Mike Treseler" <mike.treseler@flukenetworks.com> wrote > Juergen Otterbach wrote: > > > > Hallo usergroup, > > in our lab we are working with a PCB assembled with a Virtex 1000 E BGA > > device. > > For a bigger FPGA design we want to replace this by a Virtex 2000E BGA > > (means to take of the 1000E and resolder the 2000E). > > Removing and replacing a BGA device is not > a problem for any manufacturing facility > with a BGA rework station. > > Of course, you have to throw the old part away. AFAIK you can 're-ball' the old part. Though this may not be worth the trouble - how much are 1000Es these days?Article: 35669
Another point of view... I disagree on the dual-use of pins. Please put ALL the config, etc, pins on the VCCAUX supply. I.E. on non-banked balls. I guess we could also have an option to connect some of these to the logic matrix. The V2 lineup is so much better than the 4K/Virtex arrangements, but it is still annoying to have config spread between VCCAUX and whatever voltages banks 4 and 5 are set at. Maybe the long term plan is to configure/readback the big stuff via JTAG only - the details of ROM handling can be farmed out to a PAL. "Eric" <erv_NO_SPAM@sympatico.ca> wrote in message news:3BC1CA87.BD87F36E@sympatico.ca... > Hi, > > Talking about pins that could be used for user IO after configuration, there is : > > - M0 M1 M2 : According to the data sheet (Spartan II, page 13), the state > of these pins is only required to be valid on the Low to High transition of INIT > (not very clear, would seem more logical if they had a setup time). > No matter the exact timing, they obviously are only required at a precise point > during configuration and are useless except at that time. > After configuration, I see no reason why they could not be used as IO. > > - HSWAP_EN (Virtex II) > Same as M0 .. M2 > > - CCLK : Obviously, it have no function after configuration is complete, and in most > apps, I end up connecting it to another IO pin (when configuration is bit banged by a > processor, CCLK is usually connected to some kind of address decoding, and it is > used after configuration as a "Chip Select" input). > Here too, I can't see any reason for not using it as an IO > > - TDI TDO TMS TCK > In previous series (at least Spartan), these could be used as IO if the boundary scan > function was not required. I miss these 4 pins (even if I screwed up once with them > and could not properly configure the chip because of random data being fed to them). > With proper care, they are great as IO too. > > - DONE. > Here too, as Rob Finch said, I can't see why it's not a user IO after configuration. > > - PROGRAM. > > Obviously, this pin can't be used as an input, but it could be used as an Open drain output. > Hiz : Well, does nothing ... > Low : If properly latched / delayed /cleared, can be used to trigger self reconfiguration. > This self reset can be used to restart without using external logic when a faulty condition > is detected (or whenever the designer want to reboot the device). > > ------ > > Also, as Geoffrey G. Rochat stated, I miss both HDC and LDC pins too. > > Another pin that might be very useful (if Master Parallel mode goes back) would be a "TDC" > pin that would toggle during configuration. > Here's how it would work : > Initially, it would be a high impedance (or high level) pin, but if the configuration fail, > it would go to "0" and start toggling each time the configuration fails. > > The use would be to connect it to an address pin of the configuration ROM in systems that > require the FPGA to start even in case of a failed configuration download. > > That way, the FPGA would attempt to start from the potentially corrupted configuration > data, detect the bad CRC and restart from the original "fail-safe" configuration. > > This fail-safe mode is needed as soon as a potentially unreliable update must be made > (such as remote/modem update), at the expense of a doubled configuration rom size. > > In applications that don't need the functions, it's very rare not to be able to find > any pin in the design that can be either pulled high, or low, or toggled during > configuration with no adverse effect. > > ------ > > These changes would help mostly with low pin count packages where these ten user IO pins > could certainly be put to good use, and since this is all programmable, it would all be > backward compatible (except HDC / LDC) for users who don't need them. > > Also, not loosing pins used for configuration would allow for even more configuration options > without loosing more user pins (and/or increasing the number of Power/GND pairs without > decreasing the useable pin count). > > Éric. > > --------------------------------- > > Rob Finch wrote: > > > I agree with the original poster's comments. > > > > Also, it would be nice if the 'done' signal were available to a user > > programmable pin in addition to it's regular pin. (Perhaps it could be > > tri-state isolated from the user pin after configuration). That way, it > > could be used in address decoding for an eprom shared between configuration > > bits and microprocessor code. Might save some external gates. > > > > Rob > > http://www.birdcomputer.ca/ >Article: 35670
The 18k Block RAM matches up with the 18 x 18 multipliers... so if in filtering algorithms (MAC) functions are more efficient if the RAM matches the multipliers. This, of course is only for the Virtex II product family. In the Virtex, Virtex E, Virtex EM and Spartan II (soon Spartan IIe) products the Block RAM size is 4k (and there are no multipliers in these families. Those are my thoughts. sma Gautam wrote: > Xilinx uses 18K Block RAMs in its FPGAs & Altera uses 4K Block RAMs. > What are the advantages & disadvantages of each of them from the Users > perspective?Article: 35671
Falk Brunner wrote: > I mean, when the "Hello World" takes 100 Kb in C++, THIS IS REALLY CRAP. Aw, c'mon. You're talking about what happens when you use Visual C++ to write a WINDOWS version of "Hello, World." Write a short hello.cpp for your linux box, that runs on the command line, and tell me how big it is. -andyArticle: 35672
Jeff Cunningham wrote: > > Austin Franklin <austin@dar87kroom.com> wrote in message > news:ts7f3mcvi2r3e5@corp.supernews.com... > > I know this is "controversial" but this kind of crap just really "irks" > > me... > > Indeed. > > If I recall correctly, I saw something like this when installing the xilinx > free tools - was it the XST synthesis tool; or maybe it was the free version > of ModelSim? Though what I remember is that the prohibition was on > "publishing" any benchmark results, as in posting to usenet; I can't see how > emailing results to one person would even be in violation of that assinine > license clause. Uh oh! The person who posted Synplify's results for that 56-bit counter problem is in line for an ass-whooping! -aArticle: 35673
Is there any documentation on how to program a Xilinx XC18V00 configuration prom? I don't want to use SVF (or I would need multiple copies of the bitstream in my code. One to program the XC18V00 and one to program the FPGA) JDrive is not written with porting in mind. (not even the comments are portable) I already have code to drive JTAG. It should just be a matter of sending the right command and then sending the data. I have already read XAPP053. Is the XC18V00 programming algorithm documented anywhere? Alan Nishioka alann@accom.comArticle: 35674
Gerald Coe wrote: > > Hello > > This is a concern to me, > Can you provide an on-line reference to this document? Lattice have just modified the links, and added these two http://www.latticesemi.com/lit/docs/pcns/010a_01.pdf http://www.latticesemi.com/lit/docs/appnotes/cpld/tn1007.pdf This details the affected devices, including those that will require PCB redesigns. -jg > In article <99e2931.0110120320.49cf9aba@posting.google.com>, M. Praekelt > <martp@hotmail.com> writes > >Hello, > >as I read in comp.arch.embedded most i186 and i486 derivates build by > >AMD are discontinued. > >Now we got an announcement that this is the case also for a great > >bunch of MACH circuits produced for LATTICE in AMDs FAB 14 (which is > >intended to be closed). > >The list of devices in the PDF document spans 8 pages and contains > >PALCE PALLV devices, MACH1xx, MACH 2xx, MACH4xx M4-xx and M5-xxx > >devices! > > > >Last order is 31 dec 2001 and last delivery 31 dec 2002!!!! > > > >I have posted this using another mail server a day ago, but I havent > >seen it up to now. > >I apologize if this message is reaching you twice. > > > >Perhaps we are the only ones around using this old-fashioned > >programmable devices.... > > > > > >BTW: On http://www.latticesemi.com/products/mature/index.cfm > >you cannot read **anything** about this up to now (12 oct 2001, 11:20 > >UT) > > -- > Regards, Gerry > www.robot-electronics.co.uk
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