1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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

Custom Search

# Messages from 21025

Article: 21025
Subject: Re: Xilinx 1802/4 SPROMs....anyone get them to actually work? - FIXED!!!
From: "Austin Franklin" <austin@dark99room.com>
Date: 3 Mar 2000 16:26:19 GMT
Links: << >>  << T >>  << A >>
Xilinx has duplicated the problem.  They say that when the SPROM is put in
program mode over JTAG, it holds the /CF pin low (which is the mistake)
which they want tied to the FPGA /PROG pin, therefore holding the FPGA in
RESET, and holding the JTAG TAP controller in RESET, so no data gets
through....

The bottom line is, put the SPROM(s) first...or don't hook the /CF pin to
the /PROG pin...just pull /PROG high, and power down/up to load the Xilinx
from the SPROM.

Austin Franklin <austin@da33rkroom.com> wrote in article
<01bf825f$584e1740$207079c0@drt1>...
> Well, it appears to be a Xilinx JTAG programmer problem.  When I cut and
> jump the JTAG chain so the SPROM is before the FPGA, it erases, blank
> checks, programs and verifys fine!
>
> Of course, I specifically asked Xilinx if the chain order mattered, and
was
> told no (and it shouldn't matter), but I guess no one ever tried out the
> simple combination of FPGA->SPROM...
>
>
> Austin Franklin <austin@da33rkroom.com> wrote in article
> <01bf80dc$79ef7580$207079c0@drt1>...
> > Minor update...according to the Xilinx web site, verify doesn't work.
> > Great.  The only way to see if it was programmed is to look at the bit
> > stream (or let it program the FPGA and look for DONE)...but I currently
> get
> > all 1's out of the SPROM...as if it wasn't programmed at all.
> >
> > Also, the JTAG programmer claims it programs the SPROM just fine, and
> that
> > I can erase it just fine, but it fails blank check....  I'm led to
> believe
> > it just isn't programming the 1804 at all...even though it says it did.
> >
> >
> > Austin Franklin <austin@da33rkroom.com> wrote in article
> > <01bf80d1$393e2f00$207079c0@drt1>...
> > > I've got a board with one XCV300 and one SPROM (VQ-44) in a JTAG
chain.
>
> > > The Virtex is first in the chain.  I had an 1802 as the PROM, and it
> gave
> > > me an error when I tried to program it (saying it was read protected,
> and
> > > even erasing it wouldn't help), so Xilinx suggested replacing it with
> an
> > > 1804.  Now I can program the SPROM, but it won't verify, and doesn't
> > appear
> > > to work.
> > >
> > > The Virtex loads just fine over JTAG, and works.  No problems there.
> Has
> > > anyone had similar problems with the 1804, and has anyone gotten one
to
> > > work?  Voltage and pinouts all checkout fine, the JTAG programmer
> > > recognizes it just fine....
> > >
> > > Thanks
> > >
> > >
> > >
> > >
> >
>


Article: 21026
Subject: Re: restrictions due to signal types of Global Clock inputs for Virtex
From: mcgett@xilinx.com (Ed Mcgettigan)
Date: 3 Mar 2000 08:31:55 -0800
Links: << >>  << T >>  << A >>
In article <LFzv4.253$zK5.6244@iad-read.news.verio.net>, George <gzs@clark.net> wrote: > >I have a multi-clock design I am doing in a Virtex XCV1000 device. >All four global clock inputs are used and the I/O bank where one of >the clock inputs enters the chip is SSTL2. Xilinx tells me to make >the clock be an SSTL2 signal. This is no problem. The FAE also tells >me that I should not try to use this particular clock to clock any of >the internal logic of the device, only the IO pads of the banks which >are also SSTL2. > >This is very hard for me to believe. Does anyone know of any type of >restriction on the uses of the global clocks depending on the Select >IO types used for the clock inputs? The information that you were given by the FAE, as you describe it here, is incorrect. There are no restrictions that a clock input source IO standard matches a IOB destination IO standard. The input buffers (including the global clock inputs) can be thought of as simply level translators. In this case translating from an SSTL2 level on the board to the internal levels used in Virtex. Once inside of Virtex (or any device) a '1' is a '1' and a '0' is a '0' regardless of where it came from. As an additional point the Virtex IOBs are configurable on a per IOB basis, not a bank basis as you have implied above. The banks do generate some restrictions however, the VCCO and VREF source must be the same for all IO in the bank. In your case of using SSTL2, this means that the VCCO is 2.5V and the VREF is 1.25V. Any input buffer that doesn't require a VREF or require a VREF of 1.25V may be placed in this bank. Any output buffer that doesn't require a VCCO (GTL, GTL+) or requires a VCCO of 2.5V may be placed in this bank. Ed McGettigan -- Xilinx Inc.  Article: 21027 Subject: Re: ORCA 3T - input/output delay reduction? From: pmueller <pbcmuellerNOpbSPAM@hotmail.com.invalid> Date: Fri, 03 Mar 2000 08:43:17 -0800 Links: << >> << T >> << A >> <simmler@ti.uni-mannheim.de> wrote: >Hi > >I have a design where 4 ORCA 3T125 chips communicate together >( programmed in VHDL ). All four designs should run at arond 20 MHz. >At least the P&R tools calculates that frequency on internal delays. > >But the highest frequency on the board is only 8MHz. >The FPGAs are directly connected by wires, so I think that this >should not be the problem. I think that the PIO blocks which are >programmed as input add an delay block at the >input ( per default ? ) which has to be added to the internal >tPD. And the output is set to slow ( also per default ? ). > >Has anyone an idea what reduces the frequency and does anyone >know how to disable the input delay or change the settings for the PIO >blocks during P&R ( constrains in the CHDL code or in a constrains file >)?? > >Any help is needed. >Thanks in advance. > >H. Simmler We use registers for all inputs/outputs (PIO registers! Explicitely instantiated in VHDL) and can communicate with a OR3T30-6 at 125 MHz with a Fibre Channel Transceiver! Between the FPGAs (OR3T80-6 <=> OR3T30-5, and between OR3T30-6 <=> OR3T30-5 over a PCI connector) we communicate with 62.5 MHz - no problem. P. Muller * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!  Article: 21028 Subject: Re: Extremely fault tolerant strategies From: gdeych@my-deja.com Date: Fri, 03 Mar 2000 18:52:22 GMT Links: << >> << T >> << A >> That sounds very promising. I went searching for those kinds of references yesterday, but without much success. Unfortunatley, ACM's and IEEE's digitial library goes back only till 88 or so. In article <8a3tbssp0dj8m2h0m03mf7g5shelhilesp@4ax.com>, Brian Drummond <brian@shapes.demon.co.uk> wrote: > I wonder if it's worth trawling for information from the vacuum-tube and > mercury delay line days (ACE, EDSAC, LEO etc), the late 40's and very > early 50's. They faced these problems and usually, certainly LEO (Lyons > Electronic Office) did, developed strategies to deal with them ... e.g. > regular checkpointing, running test patterns with over/under voltage to > catch marginal performance, etc. > > As a start I'd search for M.V. (Maurice) Wilkes and see what turns up... > > - Brian > Sent via Deja.com http://www.deja.com/ Before you buy.  Article: 21029 Subject: Synplicity for sale From: 1209@my-deja.com Date: Fri, 03 Mar 2000 18:56:06 GMT Links: << >> << T >> << A >> I heard that Synplicity is for sale and will not IPO. Who do you think will buy them, Cadence??? Sent via Deja.com http://www.deja.com/ Before you buy.  Article: 21030 Subject: Re: BEHAVIOURAL VHDL From: 1209@my-deja.com Date: Fri, 03 Mar 2000 19:16:02 GMT Links: << >> << T >> << A >> You should not infer RAM you should instantiate RAM. Refer to Synplicity App Note: ram_inferencing.pdf "The vendor-specific details regarding 'glue' logic are explained in the Technology implementation Specifics Section. This might result in a non-optimal RAM inplementation. If you want a design that makes the most efficient use of a specific technology's RAM primitive, you must instantiate the vendor-specific RAM primitive." In article <38AE36EE.69B0FB5D@ids.net>, Ray Andraka <randraka@ids.net> wrote: > If you are synthesizing, you should be using RTL level code rather than a > behavioral description. If the behvioral description is even > synthesizable, it is likely not enough information for the synthesizer to > guess at an implementation. > > Synplicity will infer RAMs and ROMs from an RTL integer array. > > ritchie99_uk@my-deja.com wrote: > > > HI ALL, > > > > what's the performance of the actual synthesisers for a behavioural > > vhdl input > > i am looking to target the VIRTEX-E with a behavioural vhdl input, and > > here i don't know which synthesiser(s) is (are) good especially for > > inferring Block Rams and distributed RAMs > > > > i read that "exemplar" infers automatically the BRAM , what about FPGA > > express that come with F2.1i, is it good ??? > > same question for synplify and symplicity ( i hope that it's the right > > spelling ...) > > > > thanks in anticipation > > > > --ritchie > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka > > Sent via Deja.com http://www.deja.com/ Before you buy.  Article: 21031 Subject: Re: SpartanXL route and place From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> Date: Fri, 3 Mar 2000 13:05:24 -0700 Links: << >> << T >> << A >> Keith R. Williams wrote in message ... > >I'll admit to being a novice at FPGA/s and Xilinx in particular, >but I can't have missed this much. I'm doing a board with a >SpartanXL (XCS40XL-256BG) part and a Virtex (will go to -E when I >can get them). I'm using Synplify as the design tool and then >into Alliance. Alliance is taking *forever* to to Place-N-Route. > I started with a 56% or so full device (both Synplify and >Alliance agreed within reason) and then went to wire. After >*hours* it gave up saying that I had hundreds of un-routed nets. >After tweaking the design (it was very crude) down to where I now >have less than 25% used, it still takes *hours* to P&R with >rather unsatisfactory results. I have to put it through the >re-entrant roter to get it to wire at all. I left affter two >hours of this today (it's a PII-333 running NT). This is a >*simple* design. > >1) What the hell am I doing wrong? Is this normal? > >2) If I can extrapolate this to my Virtex (XCV600-FG680, btw) >design, I'll grow foot-long fingernails waiting for routing (if I >don't bite them off first). Is Spartan not routable? Is Virtex >better? (good grief, I hope so!) > >3) Can I make simple changes (pinouts and such) without >re-routing completely? > >4) Or, am I all wet, and pushing the wrong buttons? It would be >nice to be able to tell Alliance to use the re-entrant router >from the beginning, and then go home. > >Oh, my head hurts! I've had full head of grey hair for 20 years, >but me think's it's coming out now! the design I just did in an xcs20xl (tq144) took about five minutes to route on a piii/550 w/384 MB SDRAM. Things to check: 1) Timing constraints. sounds like you might be over-constraining the design. you may not even be aware of this, because synplicity might be sitcking its constraints into your xnf (or whatever the result of the synthesis is). I know that FPGA Express would put an inane number of constraints into the xnf, so I simply stopped letting it do that. Also, p+r should tell you if the current placement isn't expected to meet timing. try using a UCF with nothing (not even pin locs) but a period constraint. 2) maybe you're trying to make it run too fast? 3) maybe you're pushing the wrong buttons. it might be doing many more passes than necessary. do you have any idea whether it's meeting timing? -- a ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu "Money is property; it is not speech." -- Justice John Paul Stevens  Article: 21032 Subject: Re: xilinx synthesis tool From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> Date: Fri, 3 Mar 2000 13:11:11 -0700 Links: << >> << T >> << A >> Sherdyn wrote in message <38bf8335.0@news.cyberway.com.sg>... >Why can't we use it? > >Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in message >news:89mnlc$13nf$1@noao.edu... >> Björn Lindegren wrote in message >> <8AAv4.3428$yw1.7286@nntpserver.swip.net>...
>> >Do Xilinx synthesis tool support std_logic_signed / unsigned?
>>
>> FPGA Express does ('cause it's a Synopys product).  however, you
shouldn't
>> use those libraries.

Because numeric_std is the preferred standard.

--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Money is property; it is not speech."
-- Justice John Paul Stevens


Article: 21033
Subject: Re: ORCA 3T - input/output delay reduction?
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 3 Mar 2000 13:13:19 -0700
Links: << >>  << T >>  << A >>
Harald Simmler wrote in message <38BEA2B4.213A3998@ti.uni-mannheim.de>...
>Hi
>
>I have a design where 4 ORCA 3T125  chips communicate together
>( programmed in VHDL ). All four designs should run at arond 20 MHz.
>At least the P&R tools calculates that frequency on internal delays.

the tools are telling you that the designs run at about 20 MHz?  What is
your desired clock speed?

>But the highest frequency on the board is only 8MHz.

Does that mean that you have an 8MHz oscillator on the board?

>The FPGAs are directly connected by wires, so I think that this
>should not be the problem. I think that the PIO blocks which are
>programmed as input add an delay block at the
>input ( per default ? ) which has to be added to the internal
>tPD. And the output is set to slow ( also per default ? ).
>
>Has anyone an idea what reduces the frequency and does anyone
>know how to disable the input delay or change the settings for the PIO
>blocks during P&R ( constrains  in the CHDL code or in a constrains file
>)??

I don't think I understand your question.

--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Money is property; it is not speech."
-- Justice John Paul Stevens


Article: 21034
Subject: Re: SpartanXL route and place
From: "John Janusson" <jjanusson@nospami-o.com>
Date: Fri, 03 Mar 2000 20:33:48 GMT
Links: << >>  << T >>  << A >>
I did a design last year with a XCS30XL...  My P&R times were fairly short
(normally well less than <10 minutes) for a part that was 95% full...  The
design involved some fairly elaborate DSP stuff and a CPU register interface
(no memories or anything)...  I didn't need the design to run very fast, so
I turned off most of the constraints (pinouts only) feeding the P&R tool.

In my experience with this design, the three things that caused long P&R
times were lack of horsepower and/or memory on the PC (256MB, PII 450MHz,
NT4.0 performed great), inefficient use of FPGA global resources (ie. use
only global clocks and resets, enable flipflops at the right frequency), and
having many constraints on the Xilinx tools (timespecs, routing placement,
etc).   In fact, I found overall P&R performance usually was usually better
if I didn't use constraints (other than pinout constraints).  But again,
this design didn't push any sort of speed limit...

So assuming you have enough memory in your PC and your design effectively
uses global routing resources,  I would guess the problem is that Symplicity
is annotating constraints to the synthesized netlist (EDIF file read by
Xilinx tools).  There should be an option to turn this off in Symplicity...
If you really have to use constraints for performance reasons, enter them
directly (and sparingly) into the Xilinx tool using the constraint editor.

Good Luck,

John

Keith R. Williams wrote in message ...
>
>I'll admit to being a novice at FPGA/s and Xilinx in particular,
>but I can't have missed this much.  I'm doing a board with a
>SpartanXL (XCS40XL-256BG) part and a Virtex (will go to -E when I
>can get them).  I'm using Synplify as the design tool and then
>into Alliance.  Alliance is taking *forever* to to Place-N-Route.
> I started with a 56% or so full device (both Synplify and
>Alliance agreed within reason) and then went to wire.  After
>*hours* it gave up saying that I had hundreds of un-routed nets.
>After tweaking the design (it was very crude) down to where I now
>have less than 25% used, it still takes *hours* to P&R with
>rather unsatisfactory results. I have to put it through the
>re-entrant roter to get it to wire at all.  I left affter two
>hours of this today (it's a PII-333 running NT). This is a
>*simple* design.
>
>1)  What the hell am I doing wrong?  Is this normal?
>
>2)  If I can extrapolate this to my Virtex (XCV600-FG680, btw)
>design, I'll grow foot-long fingernails waiting for routing (if I
>don't bite them off first).  Is Spartan not routable?  Is Virtex
>better?  (good grief, I hope so!)
>
>3)  Can I make simple changes (pinouts and such) without
>re-routing completely?
>
>4)  Or, am I all wet, and pushing the wrong buttons?  It would be
>nice to be able to tell Alliance to use the re-entrant router
>from the beginning, and then go home.
>
>Oh, my head hurts! I've had full head of grey hair for 20 years,
>but me think's it's coming out now!
>
>----
>  Keith
>
>


Article: 21035
Subject: EDA tools
From: "Stan Ramsden" <sramsden@hoflink.com>
Date: Fri, 3 Mar 2000 16:43:44 -0500
Links: << >>  << T >>  << A >>
I am trying to find the best EDA solution for doing FPGA designs.
Any comments on what one thinks is the best:
1-Sythesis tool
2-VHDL Simulator

Thanks

Stan Ramsden
Ramsden Designs
631-956-7720


Article: 21036
Subject: Re: Comment on Atmel AT40K ?
From: Ray Andraka <randraka@ids.net>
Date: Fri, 03 Mar 2000 21:46:00 GMT
Links: << >>  << T >>  << A >>
The Atmel wiring is designed for a carry-save (column ripple) multiplier (that's
what the diagonal routes are for).  A wallace tree is the tree form of the column
ripple, which will reduce the number of adders the signal has to go from input to
output, but the irregular wiring makes it have a considerably slower clock cycle
in a fully pipelined design.  In either case, the overall speed will be limited by
the final column adder.  Since the Atmel device doesn't have a fast carry chain,
you are forced to use relatively expensive carry look-ahead schemes to maintain

The computed partial products multipliers discussed on my website actually use the
4LUT in xilinx part quite efficiently, so much so that the area of such a
multiplier is less than half a column ripple or wallace tree.  You could do the
same in the Atmel, but you'll be limited by the relatively slow ripple carry in
your adder trees.  Faster adders would make it go faster but at considerable area
(which is why you would want to use carry save form in atmel).  The bottom line,
is you actually get less bits per 4-LUT than you do with xilinx or altera because
of the lack of a carry chain.

Where Atmel does do pretty well is bit serial arithmetic.  The simple cell makes
it faster than a more complicated cell in the same technology.  Even here, I think
the 40K has been pretty well eclipsed by the smaller geometries of its
competition.  One of the areas is was supposed to compete was on price as compared
to xilinx.  I think even there, it really has little or no advantage when compared
with the spartan families.  As to the embedded RAM, that is a nice touch.  Xilinx
also has that capability using the CLB RAM, which isn't left unused if you don't
need RAM.

Rickman wrote:

> I was following an earlier thread on multipliers IIRC that used a lot of
> non ripple adders. In this type of application, wouldn't the Atmel parts
> do well since they are a finer grained architecture? They should be able
> to provide more bits for the buck since they have a simpler structure
> and lend themselves well to an ordered array with direct interconnect.
> Again, IIRC systolic or array logic is about the only area where they
> show well.
>
> Ray Andraka wrote:
> >
> > My stock answer:  It depends on the application.
> >
> > The 40K's Achilles heel is the fact it has no fast carry logic.  That really
> > cripples its arithmetic performance/density when compared to Xilinx.  If you
> > don't need a carry chain (unfortunately, I can only think of a few
> > applications that don't benefit there), it's not all that bad a device.  I
> > truthfully have not looked at their software in a few years.  I would hope
> > that it has been improved.  Previously they were using Figaro, which was
> > dreadfully slow, especially when you tried to do any edits.  I think they
> > still give away the software for free.  You might test drive it to see what
> > you think.
> >
> > Peter Fenn wrote:
> >
> > > Hi
> > > I am looking for 1st-hand comment from users of Atmel AT40K FPGA tools and
> > > devices.
> > > - What are the shortcomings?
> > > - How does it compare to eg. Xilinx?
> > > - How does architecture rate compared to other FPGA offerings out there?
> > > - What is the "sweet-spot" in terms of price, performance,etc?
> > > - Any other observations / tips appreciated
> > >
> > > Thanks for all your input
> > > Pete Fenn
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email randraka@ids.net
> > http://users.ids.net/~randraka
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> remove the XY to email me.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21037
Subject: Re: SpartanXL route and place
From: Ray Andraka <randraka@ids.net>
Date: Fri, 03 Mar 2000 22:00:35 GMT
Links: << >>  << T >>  << A >>
The XCS40 is equivalent to an XC4020E.  The routing in the 4020E and
4025E is relatively sparse.  The 4KXL and 4KXLA have additional routing
resources to combat this problem.  Additionally, the automatic placement
does not do a very good job.  You can probably get much better results
as well as a much quicker place and route if you floorplan the design.
Historically, lots of people had trouble with the routing in the larger
4KE devices simply because the routing resources are not sufficient for
a reasonably congested randomly placed design.  I haven't seen a
spartan40/4020/4025 design yet that wouldn't route with some
floorplanning and perhaps a little tailoring.  As a first step, you
might look at the placed design in the floorplanner.  Turn on the
routing congestion and see where it is badly congested, then try moving
stuff around to reduce the congestion.

Virtex has much richer routing architecture, so I am sure you won't have
similar routing problems with the small virtex devices.  I suspect as
the parts grow larger, they may run into routing restrictions in
auto-placed designs as well.

For the speed of the PAR, the speed and size of your memory is probably
more important than the processor speed.  For example, My office machine
is a dual pentium pro200 with 256MB of fast EDO.  My laptop is a
PIII-366 Tecra with 64MB.  Place and route takes about 8-10 times longer
on the laptop than it does on the slower desktop (and place and route
does not take advantage of multiple processors).

Bottom line: design to the architecture and do some floorplanning paying
attention to the routing congestion.

"Keith R. Williams" wrote:

> I'll admit to being a novice at FPGA/s and Xilinx in particular,
> but I can't have missed this much.  I'm doing a board with a
> SpartanXL (XCS40XL-256BG) part and a Virtex (will go to -E when I
> can get them).  I'm using Synplify as the design tool and then
> into Alliance.  Alliance is taking *forever* to to Place-N-Route.
>  I started with a 56% or so full device (both Synplify and
> Alliance agreed within reason) and then went to wire.  After
> *hours* it gave up saying that I had hundreds of un-routed nets.
> After tweaking the design (it was very crude) down to where I now
> have less than 25% used, it still takes *hours* to P&R with
> rather unsatisfactory results. I have to put it through the
> re-entrant roter to get it to wire at all.  I left affter two
> hours of this today (it's a PII-333 running NT). This is a
> *simple* design.
>
> 1)  What the hell am I doing wrong?  Is this normal?
>
> 2)  If I can extrapolate this to my Virtex (XCV600-FG680, btw)
> design, I'll grow foot-long fingernails waiting for routing (if I
> don't bite them off first).  Is Spartan not routable?  Is Virtex
> better?  (good grief, I hope so!)
>
> 3)  Can I make simple changes (pinouts and such) without
> re-routing completely?
>
> 4)  Or, am I all wet, and pushing the wrong buttons?  It would be
> nice to be able to tell Alliance to use the re-entrant router
> from the beginning, and then go home.
>
> Oh, my head hurts! I've had full head of grey hair for 20 years,
> but me think's it's coming out now!
>
> ----
>   Keith

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21038
Subject: Re: EDA tools
From: muzo <muzok@nospam.pacbell.net>
Date: 03 Mar 2000 17:02:05 EST
Links: << >>  << T >>  << A >>
I am using Verilog but I've heard really good things about Model
Technology simulators.
I have evaluated fpga express, leonardo and Synplify from Synplicity
for Verilog/VHDL synthesis. I bought Synplicity. QOR are excellent
both in terms of size/speed of gatelevel netlist and the speed of the
tool to give these result.
I can recommend Synplify with no reservations.

"Stan Ramsden" <sramsden@hoflink.com> wrote:

>I am trying to find the best EDA solution for doing FPGA designs.
>Any comments on what one thinks is the best:
>1-Sythesis tool
>2-VHDL Simulator
>
>Thanks
>
>Stan Ramsden
>Ramsden Designs
>631-956-7720
>
>


Article: 21039
Subject: Re: SpartanXL route and place
From: Ray Andraka <randraka@ids.net>
Date: Fri, 03 Mar 2000 22:05:10 GMT
Links: << >>  << T >>  << A >>
>
>
> Virtex and Virtex-E devices have very rich routing resources.
> Some engineer told here that he achieved more than 90%
> routing resource usage of Virtex. I know another engineer
> personally who showed me that their team have successfully
> used 94% routing resources of Virtex XCV1000.

If they are using that much of the Virtex routing resource, they've done
something wrong.  On the otherhand, I kinda suspect you really mean they
used 94% of the CLBs.  That is quite doable in both virtex and spartan
devices.  Virtex may very well route without any floorplanning,
depending on the design.  Spartan most likely will not route with that
kind of utilization in the larger devices without floorplanning.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21040
Subject: Re: BEHAVIOURAL VHDL
From: Ray Andraka <randraka@ids.net>
Date: Fri, 03 Mar 2000 22:15:41 GMT
Links: << >>  << T >>  << A >>
Synplicity works just fine inferring the RAM for altera and xilinx, and it
is a heck of a lot more readable.  Now, when I need to also RLOC (place) the
RAM, then I'll instantiate it, otherwise I infer it.

1209@my-deja.com wrote:

> You should not infer RAM you should instantiate RAM.
> Refer to Synplicity App Note: ram_inferencing.pdf
>
> "The vendor-specific details regarding 'glue' logic
> are explained in the Technology implementation Specifics
> Section. This might result in a non-optimal RAM inplementation.
> If you want a design that makes the most efficient use
> of a specific technology's RAM primitive, you must
> instantiate the vendor-specific RAM primitive."
>
> In article <38AE36EE.69B0FB5D@ids.net>,
>   Ray Andraka <randraka@ids.net> wrote:
> > If you are synthesizing, you should be using RTL level code rather
> than a
> > behavioral description.  If the behvioral description is even
> > synthesizable, it is likely not enough information for the synthesizer
> to
> > guess at an implementation.
> >
> > Synplicity will infer RAMs and ROMs from an RTL integer array.
> >
> > ritchie99_uk@my-deja.com wrote:
> >
> > > HI ALL,
> > >
> > > what's the performance of the actual synthesisers for a behavioural
> > > vhdl input
> > > i am looking to target the VIRTEX-E with a behavioural vhdl input,
> and
> > > here i don't know  which synthesiser(s) is (are) good especially for
> > > inferring Block Rams and distributed RAMs
> > >
> > > i read that "exemplar" infers automatically the BRAM , what about
> FPGA
> > > express that come with F2.1i, is it good  ???
> > > same question for synplify and symplicity ( i hope that it's the
> right
> > > spelling ...)
> > >
> > > thanks in anticipation
> > >
> > > --ritchie
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email randraka@ids.net
> > http://users.ids.net/~randraka
> >
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21041
Subject: BOOKS ON FPGA
From: SPG <spg19@hotmail.com>
Date: Fri, 03 Mar 2000 23:34:39 +0100
Links: << >>  << T >>  << A >>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<a href="http://scientificpublishers.virtualave.net">SCIENTIFIC PUBLISHERS
GUIDE</a>
<p><a href="http://scientificpublishers.virtualave.net">ALL THE SCIENTIFIC
PUBLISHERS IN A SINGLE LINK</a>
<p><a href="http://scientificpublishers.virtualave.net">http://scientificpublishers.virtualave.net</a></html>


Article: 21042
Subject: Re: EDA tools
From: Ray Andraka <randraka@ids.net>
Date: Sat, 04 Mar 2000 01:36:28 GMT
Links: << >>  << T >>  << A >>
For synthesis I'd select either Synplicity or Exemplar.  Both do a good
job, and they seem to stay pretty well up with each other in
capability.  FPGA Express seems to lag a bit behind.

Modelsim is pretty much the standard for simulation.  Aldec's HDL
environment is a little nicer, especially if you are learning VHDL.  It
has a pretty nice VHDL editor and extensive tutorial/language guides
etc.  Modelsim is pretty much just a simulator.  Aldec's pricing is
lower than modelsim as well, so I think you get alot of value for the
money.  Last year there were a number of constructs that aldec didn't
handle well, but they have been very responsive to fixing those.  The
version 3.6 software is pretty good.  Both modelsim and aldec offer 20
day free trials which can be downloaded from their websites.

Stan Ramsden wrote:

> I am trying to find the best EDA solution for doing FPGA designs.
> Any comments on what one thinks is the best:
> 1-Sythesis tool
> 2-VHDL Simulator
>
> Thanks
>
> Stan Ramsden
> Ramsden Designs
> 631-956-7720

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21043
Subject: Need help w/ Dual Port Ram
From: gweinreb@gwinst.com
Date: Sat, 04 Mar 2000 02:48:53 GMT
Links: << >>  << T >>  << A >>
I am working on a project where I need to interface a processor to dram,
and am thinking about putting an fpga (and later, an asic) between the
two, and putting 16 dma channels in the dram that can move data to and
from dram and another auxiliary bus that does not touch the processor.  I
think this frga will take 1200 flip flops or so, and 160 pins.  The fpgq
would have 32 data lines and 32 addr lines that attach to the processor,
and 32data and 32addr lines that attach to the dram.  The fpga also has
to implement a dram controller.

* What is a good fpga that would do this (160pin, 1200 flip flop, 15ns)?

* What does the part cost (ballpark) in 1K quantities?

* How much would this cost in asic form (ballpark), both one time nre and
10K quantity price?

* Is there another way to do this?

* Is there anyone out there that I can hire to help with this? First, I
would hire the person for 1 day to do a sketch of a rough design?  How
much is reasonable to pay for a design like this?

Thanks, gweinreb@gwinst.com

Sent via Deja.com http://www.deja.com/

Article: 21044
Subject: Re: New name: DLLs, PLLs and videotape...
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 03 Mar 2000 22:50:46 -0500
Links: << >>  << T >>  << A >>
Don Husby wrote:
>
> Rickman <spamgoeshere4@yahoo.com> wrote:
> > I am jumping into this thread rather late, but I think the point of the
> > DLL is not the taps themselves, but that they can be used without a VCO.
> > Is that correct? If you still have a VCO it seems to me that you don't
> > get rid of all of the analog circuitry.
>
> Instead of a fully-analog VCO, the lucent chips implement a
> Voltage-Controlled delay line.  Again, this seems to offer the best
> of both worlds:
> Tap selection sets the coarse frequency- easy to implement becuse there
> are fewer taps, and you don't need to match path delays to the nearest
> picosecond.
> Fine adjustments are made within a limited linear range- easy to implement
> because you can implement it with the same transistors that you use for
> the digital part.  You don't need to use extreme analog design rules.

I read what you are saying, but it does not fit with my understanding of
VCOs and PLLs. If you are controlling a frequency by using a variable
delay, then the delay adjustment must be very, very fine.

I think that there is enough left out of your explanation that I am not
really getting it. I also don't see how an analog control is then mixed
with the digital delay to control VCO frequency.

> > I also don't think that tolerance is a problem with the digital delay
> > taps. I expect that they don't have to be held tightly to an exact
> > value, but they simply need to be kept to a small value to allow fine
>
> You have to make sure that the delay from tap N is not greater than the
> delay from tap N+1.  If you're talking a few picoseconds per tap, and
> hundreds of taps, this is not easy.

If you are using a delay line, then it will be monotonic by design. No
need for extreme control.

> > These delays are in the feedback path and any tolerance
> > variation would be corrected for just like an analog non-linearity.
>
> Not true.  See above.

I don't see anything above discussing this. I was referring to your
comment about fully digital delays needing to be extremely well matched.
I still don't see how a variation in step size would affect things. As
long as it is monotonic, it will be corrected for in the feedback loop.

--

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 21045
Subject: Re: Comment on Atmel AT40K ?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 03 Mar 2000 23:17:17 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
>
> The Atmel wiring is designed for a carry-save (column ripple) multiplier (that's
> what the diagonal routes are for).  A wallace tree is the tree form of the column
> ripple, which will reduce the number of adders the signal has to go from input to
> output, but the irregular wiring makes it have a considerably slower clock cycle
> in a fully pipelined design.  In either case, the overall speed will be limited by
> the final column adder.  Since the Atmel device doesn't have a fast carry chain,
> you are forced to use relatively expensive carry look-ahead schemes to maintain
> your clock cycle.

The key words here are "relatively expensive". In an architecture that
is rich in small logic blocks, the "expense" of the carry look-ahead
scheme is not so bad. I believe that the only way in which Atmel falls
down is that they are not really as cheap per gate as some of the chips
you get from Xilinx or Lucent. I have not tracked Atmel for quite some
time, but this was true a few years ago.

But if I put on my economist's hat and "assume that all gates cost the
same", then won't the Atmel parts do a better job in this situation
since the small logic blocks should waste fewer gates implementing the
carry-save and carry look-ahead logic. I guess that depends on how
clever you are at mapping the problem onto the various archetectures.

Putting my engineer's hat back on, I can't say if this really results in
a faster design for the bucks since I don't have the timing data on the
Atmel chips, or the vast resources to draw on that you have in past
designs with the Xilinx chips.

> The computed partial products multipliers discussed on my website actually use the
> 4LUT in xilinx part quite efficiently, so much so that the area of such a
> multiplier is less than half a column ripple or wallace tree.  You could do the
> same in the Atmel, but you'll be limited by the relatively slow ripple carry in
> your adder trees.  Faster adders would make it go faster but at considerable area
> (which is why you would want to use carry save form in atmel).  The bottom line,
> is you actually get less bits per 4-LUT than you do with xilinx or altera because
> of the lack of a carry chain.

Yes, I saw your other posts on this. But the smaller LUT of the Atmel
chips likely change the tradeoffs in this area. If I had the time, I
would dig into your web site and apply the techniques to the Atmel
architecture.

> Where Atmel does do pretty well is bit serial arithmetic.  The simple cell makes
> it faster than a more complicated cell in the same technology.  Even here, I think
> the 40K has been pretty well eclipsed by the smaller geometries of its
> competition.  One of the areas is was supposed to compete was on price as compared
> to xilinx.  I think even there, it really has little or no advantage when compared
> with the spartan families.  As to the embedded RAM, that is a nice touch.  Xilinx
> also has that capability using the CLB RAM, which isn't left unused if you don't
> need RAM.

I would not argue this at all. To be honest, I am very surprized that
Atmel is still in FPGAs at this point. It just seems that they don't
compete well with the "big boys". But I believe they are leveraging
their MCU designs with combined products now.

--

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 21046
Subject: Re: Comment on Atmel AT40K ?
From: Ray Andraka <randraka@ids.net>
Date: Sat, 04 Mar 2000 05:06:05 GMT
Links: << >>  << T >>  << A >>
I forgot to mention what is arguably Atmel's strongest point:  Atmel's architecture, as
well as the software is well ahead of the rest for doing partial reconfiguration.  The
architecture supports it well.

Rickman wrote:

> Ray Andraka wrote:
> >
> > The Atmel wiring is designed for a carry-save (column ripple) multiplier (that's
> > what the diagonal routes are for).  A wallace tree is the tree form of the column
> > ripple, which will reduce the number of adders the signal has to go from input to
> > output, but the irregular wiring makes it have a considerably slower clock cycle
> > in a fully pipelined design.  In either case, the overall speed will be limited by
> > the final column adder.  Since the Atmel device doesn't have a fast carry chain,
> > you are forced to use relatively expensive carry look-ahead schemes to maintain
> > your clock cycle.
>
> The key words here are "relatively expensive". In an architecture that
> is rich in small logic blocks, the "expense" of the carry look-ahead
> scheme is not so bad. I believe that the only way in which Atmel falls
> down is that they are not really as cheap per gate as some of the chips
> you get from Xilinx or Lucent. I have not tracked Atmel for quite some
> time, but this was true a few years ago.

The 40K isn't all that rich in small logic blocks.  The 40K cell is basically a 4LUT and
flip-flop, or about a half CLB in 4K if you ignore the H lut and carry stuff.  The 4lut
can split into a pair of 3 LUTs to do arithmetic sort of like the altera cell (with the
same problems I've noted here regarding the altera cell for arithmetic apps) If you look
at the number of 4LUTs and FFs, it is not all that great a difference.  A 40K20 has
32x32 cells/registers.  compare that with a 4025 which also has 32x32 cells, but it's
cells each have 2 registers, 2 4LUTs, a 3 LUT and a dedicated carry chain.  The 4025
clearly has more than double the logic of a 40K20.  A closer comparison is the 4013(
spartan XCS30 ), which is a 24x24 array of these cells or 1152 flip-flops and 4 LUTs and
576 3 LUTs plus carry chains.

Years ago I used the Atmel 6K devices in numerous applications that couldn't be touched
with the contemporary xilinx parts, simply because of the large number flip-flops
(AT6010 had an 80x80 array of cells, each with a FF and what amounted to a half adder
with some muxes).  Those cells were extremely fast for their time, and the densities
were two or more times the competition.  Design was a bit of a bitch though, because the
cell didn't cover all 2 input logic functions, and even fewer 3 input.  DeMorgan became
a good friend in those days.  I don't miss the long hours of careful hand layout and
permutations of logic to make it all fit.  The 40K architecture was at least in part
motivated by the desire to get away from that hand route, but it came at a price of
bigger and slower cells, which meant a lot less of them.

>
>
> But if I put on my economist's hat and "assume that all gates cost the
> same", then won't the Atmel parts do a better job in this situation
> since the small logic blocks should waste fewer gates implementing the
> carry-save and carry look-ahead logic. I guess that depends on how
> clever you are at mapping the problem onto the various archetectures.

A 4-lut is a 4-lut is a 4-lut.   You won't see much a difference in number of 4LUTs if
you restricted your xilixn design to also only use the 4LUTs and not the H-LUTs or carry
chain.

>
>
> Putting my engineer's hat back on, I can't say if this really results in
> a faster design for the bucks since I don't have the timing data on the
> Atmel chips, or the vast resources to draw on that you have in past
> designs with the Xilinx chips

The AT40K cells speeds aren't much different than the xilinx 4KE cell speeds.

>
>
> > The computed partial products multipliers discussed on my website actually use the
> > 4LUT in xilinx part quite efficiently, so much so that the area of such a
> > multiplier is less than half a column ripple or wallace tree.  You could do the
> > same in the Atmel, but you'll be limited by the relatively slow ripple carry in
> > your adder trees.  Faster adders would make it go faster but at considerable area
> > (which is why you would want to use carry save form in atmel).  The bottom line,
> > is you actually get less bits per 4-LUT than you do with xilinx or altera because
> > of the lack of a carry chain.

Allow me to correct myself slightly here.  In arithmetic mode, you get similar density
as the altera cell by virtue of the splitting of the cell, but you fall victim to the
same shortcomings I've mentioned numerous times concerning altera's architecture.

>
>
> Yes, I saw your other posts on this. But the smaller LUT of the Atmel
> chips likely change the tradeoffs in this area. If I had the time, I
> would dig into your web site and apply the techniques to the Atmel
> architecture.
>
>
> > Where Atmel does do pretty well is bit serial arithmetic.  The simple cell makes
> > it faster than a more complicated cell in the same technology.  Even here, I think
> > the 40K has been pretty well eclipsed by the smaller geometries of its
> > competition.  One of the areas is was supposed to compete was on price as compared
> > to xilinx.  I think even there, it really has little or no advantage when compared
> > with the spartan families.  As to the embedded RAM, that is a nice touch.  Xilinx
> > also has that capability using the CLB RAM, which isn't left unused if you don't
> > need RAM.
>
> I would not argue this at all. To be honest, I am very surprized that
> Atmel is still in FPGAs at this point. It just seems that they don't
> compete well with the "big boys". But I believe they are leveraging
> their MCU designs with combined products now.
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> remove the XY to email me.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21047
Subject: Re: New name: DLLs, PLLs and videotape...
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 04 Mar 2000 18:33:45 +1300
Links: << >>  << T >>  << A >>
Rickman wrote:
>
> Don Husby wrote:
> >
> > Rickman <spamgoeshere4@yahoo.com> wrote:
> > > I am jumping into this thread rather late, but I think the point of the
> > > DLL is not the taps themselves, but that they can be used without a VCO.
> > > Is that correct? If you still have a VCO it seems to me that you don't
> > > get rid of all of the analog circuitry.
> >
> > Instead of a fully-analog VCO, the lucent chips implement a
> > Voltage-Controlled delay line.  Again, this seems to offer the best
> > of both worlds:
> > Tap selection sets the coarse frequency- easy to implement becuse there
> > are fewer taps, and you don't need to match path delays to the nearest
> > picosecond.
> > Fine adjustments are made within a limited linear range- easy to implement
> > because you can implement it with the same transistors that you use for
> > the digital part.  You don't need to use extreme analog design rules.

Maybe, but what happens when such a system hits the Analog (fine) Limit,
and needs another notch on the digital (coarse) control ?

The resulting 'phase shock' could trigger more, downstream ?

<snip>
> >
> > You have to make sure that the delay from tap N is not greater than the
> > delay from tap N+1.  If you're talking a few picoseconds per tap, and
> > hundreds of taps, this is not easy.
>
> If you are using a delay line, then it will be monotonic by design. No
> need for extreme control.

From this discussion, it sounds like there are more than two
solutions, and maybe the best qualifier is not VCO vs DLL, but
whether the system has an analog control voltage ( and thus, a
filter, and a lock, or acquisition time spec ).

Both VCO ( Voltage Controlled Oscillator ) and VCD ( Voltage controlled
Delay ) would have this feature, of Analog loop control.

A tapped delay line can lock in a couple of ways, the simplest
is a D ff and a GoLeft-GoRight control.
This must by nature have phase jitter of the Delay LSB.

- jg

Article: 21048
Subject: Re: Testbenches
From: William LenihanIii <lenihan3we@earthlink.net>
Date: Sat, 04 Mar 2000 07:48:30 GMT
Links: << >>  << T >>  << A >>
Try Janick Bergeron's new book "Writing Testbenches: Functional Verification
of HDL Models" Kluwar Avademic Publishers @2000.

Mark Harvey wrote:

> also try Stefan Doll's verification course at :
>  http://www.i2.i-2000.com/~stefan/vcourse/html/
>
> news:38927C20.36CA5CB9@uswest.net...
> > I am seeking a source of comprehensive information on building
> > testbenches for programmable logic simulations.  The reference material
> > I presently have (both instructional texts and software documentation)
> > give this matter very light treatment.  Are there books which cover
> > testbenches exclusively or at least have thorough coverage of the topic?
> >
> > Thanks and Best Regards,
> >
> > Frank Madison
> >

--
========================
William Lenihan
========================


Article: 21049
Subject: I need an advice here pls!
From: "Erez Mozes" <mozman@netvision.net.il>
Date: Sat, 4 Mar 2000 14:27:57 +0200
Links: << >>  << T >>  << A >>
hi all u nice people
im erez
i want to learn about soc (system on chip)
i want to knew what area (fpga or asic)
and which company (altera, lattice, xilinx or elese u recommend?)

thank u all!!

my email is
mozman@walla.co.il

bye