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
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
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
<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
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
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
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
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
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
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: 21034I 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
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-7720Article: 21036
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 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/~randrakaArticle: 21037
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/~randrakaArticle: 21038
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
> > > 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/~randrakaArticle: 21040
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/~randrakaArticle: 21041
<!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
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/~randrakaArticle: 21043
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/ Before you buy.Article: 21044
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 > > adjustments. > > 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.comArticle: 21045
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.comArticle: 21046
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/~randrakaArticle: 21047
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. - jgArticle: 21048
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/ > > Madison <madisonfj@uswest.net> wrote in message > 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 lenihan3we@earthlink.net ========================Article: 21049
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
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