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
Hi Symon. You know why you do it, but I suppose you are also aware of the performance and the money you leave on the table by "designing to the lowest common denominator". Cheers Peter AlfkeArticle: 90551
Peter,
It may be he (Symon) has no choice (about designing using generic
features only).
Where I once worked, there was a policy that everything HAD to have a
second source, no exceptions allowed.
As you recall, the agreement with AT&T by Xilinx allowed for a second
source. It was that agreement that "allowed" me to design in my first
FPGA. This was the time when "second source" was a popular catch-word
with purchasing groups, and business tyoes.
I imagine that havinf a second source was a breakthrough for many other
designers at the time, as well, who were prohibited from using the most
advanced technology by this fad.
However, once designed in, the "second sourced" FPGA became a required
standard component for every board after that.
At no time did they (purchasing) ever even ask AT&T (and after, then
Lucent) for a quote: it seems that qualifying another vendor (through
the components engineer) was "too expensive."
Absurd? Yes.
So, the 'bean-counters' got their way ("must have two sources") and the
components engineers got their way ("don't bother me with another vendor").
I happen to agree with you, then as well as now, the generic approach
(was) is less efficient, and therfore more expensive.
Austin
Article: 90552Peter Alfke wrote: > Hi, Jim.. > We stopped after a week because we were satisfied. In one week, we > proved 10e14, it would take 10 weeks to prove 10e15, and 2 years to > prove 10e16. Diminishing returns...But we definitely did NOT stop > because we found an error. No cheating on my watch! > > For some strange reason (fixed in "Virtex-5") there is a > one-clock-pulse latency for FULL. I suggest using ALMOST FULL instead. > FULL is not as important as EMPTY, since a properly designed system > should never overflow the FIFO, whereas it might be nice to empty it > completely. (I often use the savings-account analogy). Wow! They pay you so much you have to worry about overflow of your saving account ?! ;) -jgArticle: 90553
Greetings, I posted this in comp.cad.synthesis. That group doesn't have much traffic. We are looking into doing a rapidchip with LSI. I would like to hear from anyone who has done a rapidchip. I'm interested in all aspects of the process with emphasis on hidden cost, "Oh you wanted timing analyses done? Well that's another 5 grand". Also how many iterations did you have to go thru with them doing the detail layout? Did they met the device delivery schedule? It looks like thier toolset does a prelimanary place and route on the customer's platform then the database is handled over to LSI for detail place and route. How long did LSI spend on detail place and toute in order to get to tape out? I understand that the time spent is dependent on the quality of the RTL, clock frequency, margin in the design, IP quality, and how many clocks. Also what was the test scan coverage obtained? I've done ASICs in the past with LSI and found them to be real stickers for process which is good. Also we have had a quote in the past with cost associated with the distributor. Did you have to pay engineering fees to the distributor? Also since we haven't done an ASIC in a few years here our synthesis license has expired. I am considering Amplify RapidChip physical synthesis from Synplicity. Anybody have a comment on that? Are these question more appropriate for John Cooley's DeepChip web site? I did a search there but came up pretty empty. Thanks in advance for any information you may share. Regards JerryArticle: 90554
That's exactly the point. You want to be able to move to another bank or leave town, and get your last cent or penny out of the account. But you really don't worry about overflow. I know you understood... And you are right.: The pay is o.k, considering the fun I am still having... PeterArticle: 90555
"austin" <austin@xilinx.com> wrote in message
news:diun5a$lnm3@xco-news.xilinx.com...
> Peter,
>
> It may be he (Symon) has no choice (about designing using generic features
> only).
>
> Where I once worked, there was a policy that everything HAD to have a
> second source, no exceptions allowed.
>
> As you recall, the agreement with AT&T by Xilinx allowed for a second
> source. It was that agreement that "allowed" me to design in my first
> FPGA. This was the time when "second source" was a popular catch-word
> with purchasing groups, and business tyoes.
>
> I imagine that havinf a second source was a breakthrough for many other
> designers at the time, as well, who were prohibited from using the most
> advanced technology by this fad.
>
> However, once designed in, the "second sourced" FPGA became a required
> standard component for every board after that.
>
> At no time did they (purchasing) ever even ask AT&T (and after, then
> Lucent) for a quote: it seems that qualifying another vendor (through the
> components engineer) was "too expensive."
>
> Absurd? Yes.
>
> So, the 'bean-counters' got their way ("must have two sources") and the
> components engineers got their way ("don't bother me with another
> vendor").
>
> I happen to agree with you, then as well as now, the generic approach
> (was) is less efficient, and therfore more expensive.
>
> Austin
>
I was in the exact same predicament. Everything had to have second
sources -- AT&T was the reason we went with the Xilinx 3090's. We used a
ton of the old XC3090-100PPG175's (or something like that). We also used a
ton of the AT&T version as well. The AT&T's typically ran a bit more $ but
seemed to be more available at the time.
We stopped requiring second sources when the board component count was down
to not much more than half a dozen IC's. At this point, it was easier to
redesign the board with new technology than to search for alternates.
Luckily, we were never stiffed by Xilinx regarding part availability for old
parts. Last year, we had a special request to remanufacture a set of boards
we put out of production years ago. Each had two XC3090's on it - I was
quite surprised at how easily we were able to find unused XC3090's after all
this time.
And how can anyboty forget the routed signal delays thru the old 3000 series
of parts?!?! I did a whole lot of hand routing back in those days. Not
much need for that anymore, thankfully. I can't exactly imagine hand
routing a XCV3200E anyways...
-- Ed
Article: 90556dlharmon wrote: > > For the Xilinx part, ISE Webpack is available for GNU/Linux. They > only claim to support only RHEL, but I got it running on Debian. > It does seem slower than the Windows version, but it is better than > using WINE. Actually the only slow thing about it is the GUI. > The only thing that really sucks is my new dual Opteron system that cannot run the Webpack because it is 32-bit and my system is 64-bit. And no, the 32-bit emulation does not work. Frustrating. -SteveArticle: 90557
In most datacomm applications, filling a buffer can be caused by network congestion, so to prevent dropped packets, you'd want to correctly detect FIFO full, and backpressure accordingly. "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1129501822.643986.219070@f14g2000cwb.googlegroups.com... > Hi, Jim.. > We stopped after a week because we were satisfied. In one week, we > proved 10e14, it would take 10 weeks to prove 10e15, and 2 years to > prove 10e16. Diminishing returns...But we definitely did NOT stop > because we found an error. No cheating on my watch! > > For some strange reason (fixed in "Virtex-5") there is a > one-clock-pulse latency for FULL. I suggest using ALMOST FULL instead. > FULL is not as important as EMPTY, since a properly designed system > should never overflow the FIFO, whereas it might be nice to empty it > completely. (I often use the savings-account analogy). > > Yes, using the fabric to implement the FIFO controller might limit the > speed to 250 MHz. > The reasons for the "hard" FIFO controller were: > Higher performance, guaranteed reliable operation without user > involvement, and saving fabric resources as well as power consumption. > The same reasoning will be used for future "hard" subfunctions. It's > the best way to increase speed, functionality, and user-friendliness. > How else can we improve by a factor 2 or even more? > Peter Alfke >Article: 90558
The Virtex-4 has a FULL flag that is synchronous with the write clock (obviously, the read clock does not care) but the FULL flag is activated one clock period late. (The EMPTY flag, synchronous with the read clock does not have this latency, it gets activated by the same clock edge that read the last valid data. Doing that right and fast is the art of asynchronous FIFO design...)) I claim that it is easy to use the ALMOST FULL flag, since the exaxt max capacity of a FIFO is not critical. Set it for 1020 for a 1024-deep FIFO, and you will never be bothered by the latency, you actually get an early warning... Peter AlfkeArticle: 90559
Steven J. Hill wrote: > dlharmon wrote: >> >> For the Xilinx part, ISE Webpack is available for GNU/Linux. They >> only claim to support only RHEL, but I got it running on Debian. >> It does seem slower than the Windows version, but it is better than >> using WINE. Actually the only slow thing about it is the GUI. >> > The only thing that really sucks is my new dual Opteron system that > cannot run the Webpack because it is 32-bit and my system is 64-bit. > And no, the 32-bit emulation does not work. Frustrating. > > -Steve I've got round this for the few remaining apps that don't play nice on my 64 bit system by building a chroot with the appropriate stuff in it and mounting /home back underneath. Bit messy, but it does all work. There's some good instructions for how to do this on a Debian system in the "Using an IA32 chroot to run 32bit applications" part of: https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html - DerekArticle: 90560
Hi This question has probably been asked a 1000 times. So here it is for 1001st time. How do I go about implementing an adc to a fpga? Hopefully someone can give me some areas to start in. Some links, reference materials, code etc. What are the most commonly interfaced adc's, and the buses they use? I currently am working with a spartan 3s 1500mb development board, and using the xilinx edk. Im new to the area, but need to learn about interfacing asap. thanks -- ---------------------------------------------- Posted with NewsLeecher v3.0 Final * Binary Usenet Leeching Made Easy * http://www.newsleecher.com/?usenet ----------------------------------------------Article: 90561
hi, im using chipscope pro core inserter to prepare my design for analysis. in my project i have two top level entities. core inserter works fine with one of them but does not work with the other one. for the one which is not working properly, it does not show any signals in the design in the dialog box which is used to assign signals to probes. Although i set Keep Hierarchy property in sysnthesis properties, it even does't show the design Hierarchy within this dialog. please help me on this. Thank you CMOSArticle: 90562
Regarding analog-to-digital converters, there are two important parameters you have to consider first: Accuracy ( = number of bits), and speed (number of conversion per second) Accuracy can be 4 bits to 20 bits, and conversion rate can be between 1 kHz and 1 GHz. There is a lot of room for different types of interfaces... Peter AlfkeArticle: 90563
Basically its for industrial sensors, like thermocouples, 0-10v, -5v-5v, 0-5v, 0-20ma, 4-20ma sensors. -- ---------------------------------------------- Posted with NewsLeecher v3.0 Final * Binary Usenet Leeching Made Easy * http://www.newsleecher.com/?usenet ----------------------------------------------Article: 90564
Very interesting!! 24 K Gold plating, how about brittleness and the associated reliability? `onmArticle: 90565
Hi Kolja Kolja Sulimma schrieb: > backhus wrote: > >> Hi Robert, your first idea appears often in a designers mind, >> because it works so well in simulation. But in synthesis the tool >> is not executing your code, only analyzing it and looking for >> synthesizable parts. The rest of the code will be ignored in the >> best case or gives you errors and warnings. > > > Actually the synthesis tools execute some of your code: Expressions > are evalutated, for and generate loops unrolled, etc. I see a difference between execution and evaluation. - execution is taking input values and producing outputs. - evaluating is calculating the right connections (and logic etc.) between inputs and outputs. (There are probably more accurate definitions available) > In principle there is nothing that prevents the synthesis tools to > execute processes that are only activated once to determine the > result. I agree to that. As long as we are discussing the above problem of initializing RAMS/ROMS from files this would be a nice feature for the next VHDL Standard. > Also, logic that converts text to integers can be described by an rtl > netlist and with a little luck redundancy removal will boil it down > to a lookup table. RTL... Please dont! I'd rather like an evaluation of a static expression (I hope I said this right) which costs no hardware. If format conversion would actually create (and use) logic elements , guess what will happen: Thousands of beginners will post questions like "I have created a bunch of counters with integers and the tool synthesizes them to a million gates..." :-) Also: If you create actual logic for converting the contents of a file to some binary representation which will be executed at runtime of the chip how will you provide access to that file? Imagine the consequences, and if that really is what designers are asking for. > Opening files can be handled similar to an "include" statement. For initialisation purposes I would welcome it. > But this will not happen before a flip-flop with enable can be > written as: if rising_edge(clk) and enable='1' then .... which still > is not understood by most synthesis tools. Especially cheap/free tools from chipvendors. I think Synopsys, Mentor or Cadence tools will understand it and create the right logic for every target architecture. Limiting tools to a style dependant subset may be somewhat annoying, because it affects the tool independance of the source code, but then if only full lrm-compliant synthesis tools would be allowed, could any company give them away for free. It's a matter of money her. > At last years GI workshop there was a paper that used XML/XSLT to > convert a load of "unsynthesisable" VHDL constructs into code that > even XST considers to be synthesizable. Most of these transformations > were really simple. Apparently the tool vendors settled years ago on > what should be synthesizable and what shouldn't and now are too lazy > to push that border. I confess, I don't know this paper. But have you taken a look at the synthesizable sources created by these tools (I assume they are creating VHDL as an output in the end) ? Would it really be so hard to write in that codestyle for yourself? How about the synthesized results? Synthesizable is not always identical to useable. Maybe the sources will become more elegant to read... Can you provide a link to that paper. It's an interesting topic. In conclusion I might say that VHDL is under continuous development, which unfortunately is a very slow process.Article: 90566
I have to go and do some real work (you know, the stuff that brings in money), but I'll look at the specifics later. One other thing - are you using them in parallel ( so you access data from the devices at the same time) ? Cheers PeteSArticle: 90567
pingboypulsar@hotmail.com wrote: > Basically its for industrial sensors, like thermocouples, 0-10v, -5v-5v, 0-5v, 0-20ma, 4-20ma sensors. Go to www.analog.com www.maxim-ic.com www.national.com www.linear.com www.ti.com Look for A/D converters, and every data sheet you choose, based on desired ADC operation, will include detailed interface information. Common busses are i2c, SPI, Parallel CMOS, Parallel LVDS. SPI is the simplest, with lowest pin count, but in the region of 1Msps it becomes too slow, and above that parallel busses are used. On really fast ( 2GHz+) ADCs, bus expanders are used, so 2Gsps@8bits fans-out to 500Msps@32bits, where it can (just) feed into a FPGA. -jgArticle: 90568
thanks for that info. So what is the best approach to learning how to do this? Is it possible to elaborate a bit more on this "..so 2Gsps@8bits fans-out to 500Msps@32bits, where it can (just) feed into a FPGA..." Cheers! -- ---------------------------------------------- Posted with NewsLeecher v3.0 Final * Binary Usenet Leeching Made Easy * http://www.newsleecher.com/?usenet ----------------------------------------------Article: 90569
Sorry, had been on conference last week. Parallel port is on a laptop, JTAG is 3.3v powered, connects to CESYS.com Xv2ddr module (Xc2v1000-456-5 plus xc18v04 prom) all run on 3.3. IMPACT gives me only a (nonexistent) multilink as choice, par3/4 are grayed out. Installation record says parallel cables drivers installed, no further details. IMPACT doesn#t recognize cable II in config-detect. Somethings wrong or missing in setup. How do I postinstall old cables ? no choice in installing from cd. Ciao, klausArticle: 90570
pingboypulsar<spamoff>@hotmail.com wrote: > thanks for that info. > > So what is the best approach to learning how to do this? > > Is it possible to elaborate a bit more on this "..so 2Gsps@8bits > fans-out to 500Msps@32bits, where it can (just) feed into a FPGA..." > > Cheers! I think you'll find that everyone is directing you to information on interfacing an FPGA to a separate ADC. It is very hard, and not worth the effort to create a high performance ADC using the FPGA fabric. Instead using an external ADC is the best option. If you really need an ADC integrated into some IC with extra logic, you'd have to look into utilising an ASIC. Though there might be an FPGA out there with a custom ADC block integrated into it, it's not the norm however. BevanArticle: 90571
Yes i wish to interface to an external adc. Sorry if that was not clear. Hopefully the interfacing to an external adc is not too complicated. I wish to be able to connect industrial sensor(s) to an adc, and then acquire the value to the fpga for further processing. Maybe its better to use an asic or something else for interfacing an adc. I need to find out these things. Regards. -- ---------------------------------------------- Posted with NewsLeecher v3.0 Final * Binary Usenet Leeching Made Easy * http://www.newsleecher.com/?usenet ----------------------------------------------Article: 90572
Is there a way to use chipscope with a card which works with an old XChecker cable?Article: 90573
Thanks for your time Pete, I do appreciate it - as I mentioned, these share no signals, I wanted to keep it simple. I will be combining them to form a 32-bit bus inside the FPGA, but outside, no shared signals. With that in mind, should I be using special pins for the SDRAM CLK signals? I have never used an SDRAM core, so I don't know what clock it is expecting on the input, and if I should use a special CLK pin on the output. I have 2 oscillators on board that go to the Cyclones PLLs, and one more that goes to a DPCLK pin. These are pretty much the last thing I have left to route, so any advice will be appreciated!Article: 90574
On 17 Oct 2005 12:36:15 GMT, kd (pingboypulsar<spamoff>@hotmail.com) wrote: >Hopefully the interfacing to an external adc is not too complicated. > >I wish to be able to connect industrial sensor(s) to an adc, and >then acquire the value to the fpga for further processing. Maybe its >better to use an asic or something else for interfacing an adc. I >need to find out these things. So, where's the hard part? You choose an external ADC based on the analog requirements - sampling rate, precision, aperture jitter, analogue bandwidth, and so on. You will probably find a lot of devices that meet your needs, so you must then refine the choice based on package size, cost, and complexity of the digital interface. Since you are doing industrial sensing stuff, I guess the data rate will be fairly low and it is probably sensible to choose a device with a serial interface (SPI or similar) because this will give you a smaller ADC package, use fewer pins on the FPGA, and make the circuit board layout much easier. OK, now you start to read the ADC data sheet carefully to decide what its digital data interface looks like. Now you have a straightforward digital design problem that can easily be solved in your FPGA. Use the FPGA to generate the ADC's clock (probably divided-down from your system clock), copy control register values out to the ADC, and read conversion results back. It's almost trivially easy. It would get harder if any of the following conditions applies: 1) Sampling rate of any one ADC is greater than about 50M samples/sec 2) Very large number of analogue inputs 3) Very high precision requirements (more than about 14 bits) 4) Need to maintain some special timing relationship between ADC sampling and something else, such as the activity of a DSP device Go away and try it. If you have trouble with some part, come back here and I'm sure someone will try to help. The rather vague nature of the responses so far has been directly related to the rather vague nature of your request :-) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
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