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
Muzaffer Kal <kal@dspia.com> wrote in message news:<mgh50v8k78sd8vg2bo3apva6jjv29adgq7@4ax.com>... > On 19 Dec 2002 21:49:26 -0800, muthu_nano@yahoo.co.in (Muthu) wrote: > > >Hi, > > > >If the multicycle path constrain is not iserting any FFs in the logic. > >why should we use them? It is quite obivious that, we are telling the > >synthesis and Place and route tools not to take the actual combination > >delay between the FF1 and FF2. > > Multi-cycle paths generate a relaxed constraint for the path in > question. If your clock period is 10ns and if you set a multi-cycle > path with a property of 2, then the logic between the two flops can > take 20ns WITHOUT inserting the pipeline flops. you mean to say, only for timing analysis and report generation > If you can really > guarantee and maintain MC constraints it can help save area and meet > timing but as there is no direct relationship between the RTL and the > property they can get out of sync, meaningless or worse plain wrong as > design changes. How the area is saved here? For timing also, the time period of actual clock is assume as double. who is going to gain with these? What is the use of generating mearly a report with out taking the actual time period between the FFs. I guess, unless otherwise we insert a FF in the middle; it is useless. > MC paths usually become a maintenance problem. Avoid them if you can, > document really well if you can't. > > Muzaffer Kal > > http://www.dspia.com > ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 50826
Stan Lackey wrote: > Yes, I have found that it's much easier to create the RTL such that there > are no MCPs, than to deal with them. Eliminates the possibility of human > error, too. > IIRC a poster on this topic some while back (*) saying that what he does, in the case where multi-cycle paths are unavoidable, is to put a HEAVILY DOCUMENTED #delay in the RTL which is say 50% longer than the clock period. Adding to this it seems that any multicycle path should then be defined in the synthesis control file (e.g. the .sdc fir Synplify) and passed to the Xilinx tools via an NCF rather than directly in a UCF. But even with some Perl hacking to relate the two it all rapidly degenerates into chaos. So I do agree that, in general, MC path constraints are a dangerous path to wander down and should really only be used as temporary scaffolding, to be removed before the design is released. (*) For the benefit of Alan Fitch this is normally shortened to APOTTAWB :-).Article: 50827
Muthu wrote: > > Muzaffer Kal <kal@dspia.com> wrote in message news:<mgh50v8k78sd8vg2bo3apva6jjv29adgq7@4ax.com>... > > On 19 Dec 2002 21:49:26 -0800, muthu_nano@yahoo.co.in (Muthu) wrote: > > > > >Hi, > > > > > >If the multicycle path constrain is not iserting any FFs in the logic. > > >why should we use them? It is quite obivious that, we are telling the > > >synthesis and Place and route tools not to take the actual combination > > >delay between the FF1 and FF2. > > > > Multi-cycle paths generate a relaxed constraint for the path in > > question. If your clock period is 10ns and if you set a multi-cycle > > path with a property of 2, then the logic between the two flops can > > take 20ns WITHOUT inserting the pipeline flops. > > you mean to say, only for timing analysis and report generation > > > If you can really > > guarantee and maintain MC constraints it can help save area and meet > > timing but as there is no direct relationship between the RTL and the > > property they can get out of sync, meaningless or worse plain wrong as > > design changes. > > How the area is saved here? For timing also, the time period of actual > clock is assume as double. who is going to gain with these? What is > the use of generating mearly a report with out taking the actual time > period between the FFs. > > I guess, unless otherwise we insert a FF in the middle; it is useless. I am not sure, but it sounds like you might not understand what multicycle constraints are for. There are times when it is preferrable to construct logic in a long, slow path instead of pipelining a fast path. For example, if you are receiving data over an interface, you need a clock at the interface rate to collect the data. However there may be processing of that data which is done on the block and only needs to be complete before the next block arrives. To pipeline this logic may require more resources than to allow it the full block time. In order to allow this logic block the extra time which will let the tool use slower routes multi cycle constraints are used. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 50828
I find they are ok as long as people stay in their lanes and pedestrians don't get in the way. JonArticle: 50829
I am in the process of troubleshooting a design targeted on an XC4000XL device. I would like to be able to use the Hardware Debugger (version 3.3.08i) that came with Foundations 3.1 to perform some readback of my design. I have recompiled my design with the Readback block and the module is placed along with the readback trigger, data and readback in progress lines. I wish to perform readback using the internal CCLK so I am not using the CLK input to the module.<br> <br> I wish to use my Xchecker cable with the hardware debugger. I have a couple issues currently with my setup. First, according to answer record #1845, the Xchecker can be used for readback debugging with XC4000E configurations of size 250k or less. My bit stream meets the size limitation (it is ~176k), however the device is an XC4000XL. From reading the 4000 series guide though my interpretation was that the XC4000XL is a lower voltage version of an XC4000E with more IOBs. Is the cable compatible with XL as well? Also, we do not have the 3.3v adapter.<br> <br> To get around the 3.3v adapter problem I have done the following:<br> <br> For inputs to the FPGA from the Xchecker (the readback trigger) I use a voltage divider to lower the 5v trigger to 3.3v and then pass it into the FPGA test point.<br> <br> For outputs from the FPGA (readback data) I connect the testpoint to an external buffer that senses 3.3v as a high and latches the output to 5v that the Xchecker needs.<br> <br> My setup uses four Xchecker connnections: VCC, GND, RD, RT. I do not use the FPGA configuration capability of the Debugger software and Xchecker cable for two reasons – the signals from/to the FPGA are not accessible and I load my bit stream in hex form via software interfacing with the motherboard for the FPGA. My results so far in the Hardware Debugger have been that after readback I am told that only zero's were readback from the device.<br> <br> Note that I have been successfull in testing various functions of the FPGA and I am pretty sure that I should *not* be reading back all zeros.<br> <br> Thanks for any help<br> <br> AEArticle: 50831
"chris mc c" wrote: > > I have searched the archives for this one but couldn't find the answer > I was looking for. > You need Google practice. My search turned up pointers to app notes and even source code. http://groups.google.com/groups?as_q=gray%20fifo&as_ugroup=comp.arch.fpga&as _drrb=b&as_mind=1&as_minm=1&as_miny 02&as_maxd &as_maxm=12&as_maxy=2002 Paul.Butler@ni.comArticle: 50832
A qualifier to the responses the OP has received so far. The design will
run at that speed provided the input clock has no jitter on it. Earlier
versions of the tools would set the specified constraint as a minimum and
would provide a routed solution that many times would b e significantly
better. The v4.1 and later tools router is lazy, so you will only beat your
constraint by a couple hundred ps in many cases. If you look at the
resulting routing, you might be appalled at what the router has done.
Unfortunately there is no easy fix other than setting the constraints
higher, and even then the resulting route is quite sloppily done.
Phil Hays wrote:
> ed wrote:
>
> > I am doing a desing that's supposed to run at a 100Mhz in a Virtex-II.
> > Is it good desing practice to run the synthesis and PAR tool with
> > higher frequency constraints (ie: 120Mhz)? Or can I assume that if the
> > PAR tool says a design
> > meets the 100Mhz constraints, the desing CAN and WILL run at a 100Mhz?
>
> PAR needs to be run at the design frequency. Don't forget to also
> constrain your I/O timing with offset = in every input other than clock,
> offset = out for every pin output, and both for every I/O. See:
>
> http://toolbox.xilinx.com/docsan/xilinx5/manuals.htm
>
> Example that might go into your design.ucf:
>
> # NET “pad_net_name” OFFSET = {IN|OUT} “offset_time” [units]
> {BEFORE|AFTER} “clk_name” [TIMEGRP “group_name”];
>
> NET "TXD" OFFSET = OUT 17 NS AFTER CLK;
>
> After PAR claims that the design fits and meets all timing, running
> static timing TRCE and looking at the unconstrained paths can be very
> valuable. If it needs a constraint, figure one out. Look at any
> constraint with "0 items analyzed" carefully to make sure it is checking
> what you need it to. This can happen with some automatically generated
> constraints, so don't panic. Example command:
>
> TRCE -v 10 -u 100 designname
>
> Synthesis tools, on the other hand, may need set to a frequency other
> than the design frequency, especially when you get to doing designs that
> push the limits of the parts and/or tools. As a beginner, put this in
> the back of your brain, and don't try to use it yet. When (not if) you
> get a situation where the synthesis tool is mucking with your design in
> a bad way remember it.... And if you do this, don't forget to disable
> the synthesis from sending the fake timing to PAR.
>
> --
> Phil Hays
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 50833I have been seeing an interesting group of job posts for an FPGA supercompuer startup for the Bioinformatics industry. The positions apparently requires a Phd from only the best 5 US schools so that rules me out. Seems to be a new team, location in NY city, maybe SJ or SD. goto \/ and enter FPGA and look at Cybercoders, 2 pages, 8 positions. http://seeker.dice.com/seeker.epl?rel_code=1102&op=2 Also a google on schrodinger (sitemap, careers..) looks remarkably similar as do posts on a no of other job sites! Good luck hunting!Article: 50834
Note that Stan labels the bits 0...15 ( like a good digital designer should). But most of the literature labels them 1...16, just to confuse you... Peter Alfke ============================= Stan Lackey wrote: > The 16-bit LFSR has taps at bits 15, 14, 12 and 3 (16, 15, 13 and 4 using > one-based numbering.) There could be a shift register for the 9 bits 4 thru > 12, and the rest in 7 flops. The eqn for 17 bits is a little friendlier, > it has taps at 16 and 13, that would be 3 flops and 14 shift register > stages. -StanArticle: 50835
Thanks for the great advice, Phil!
ed
Phil Hays <SpamPostmaster@attbi.com> wrote in message news:<3E02ADE5.6FE0C6B1@attbi.com>...
> ed wrote:
>
> > I am doing a desing that's supposed to run at a 100Mhz in a Virtex-II.
> > Is it good desing practice to run the synthesis and PAR tool with
> > higher frequency constraints (ie: 120Mhz)? Or can I assume that if the
> > PAR tool says a design
> > meets the 100Mhz constraints, the desing CAN and WILL run at a 100Mhz?
>
> PAR needs to be run at the design frequency. Don't forget to also
> constrain your I/O timing with offset = in every input other than clock,
> offset = out for every pin output, and both for every I/O. See:
>
> http://toolbox.xilinx.com/docsan/xilinx5/manuals.htm
>
>
> Example that might go into your design.ucf:
>
> # NET "pad_net_name" OFFSET = {IN|OUT} "offset_time" [units]
> {BEFORE|AFTER} "clk_name" [TIMEGRP "group_name"];
>
> NET "TXD" OFFSET = OUT 17 NS AFTER CLK;
>
>
> After PAR claims that the design fits and meets all timing, running
> static timing TRCE and looking at the unconstrained paths can be very
> valuable. If it needs a constraint, figure one out. Look at any
> constraint with "0 items analyzed" carefully to make sure it is checking
> what you need it to. This can happen with some automatically generated
> constraints, so don't panic. Example command:
>
> TRCE -v 10 -u 100 designname
>
>
> Synthesis tools, on the other hand, may need set to a frequency other
> than the design frequency, especially when you get to doing designs that
> push the limits of the parts and/or tools. As a beginner, put this in
> the back of your brain, and don't try to use it yet. When (not if) you
> get a situation where the synthesis tool is mucking with your design in
> a bad way remember it.... And if you do this, don't forget to disable
> the synthesis from sending the fake timing to PAR.
Article: 50836Austin, Including more points along a multi-cycle path makes it more specific and hence easier to manually verify that you haven't accidentally excused a real single cycle path from making timing work. The real problem with multi-cycle paths is that a multi-cycle path replaces the fully automatic and exaustive checking in the timing analyser with error prone manual analysis. As someone else points out later in this thread, your multi-cycle path specification may be correct when you put it in, but later design changes can invalidate it. - Ken Austin Lesea wrote: > Ken, > > Just one comment on multi-cycle path contraints. I have found that if you > use them, you must use the "from" "through" and "to" form (all three) in > order not to confuse the tools (with no 'wild cards'). If you don't specify > all three (and carefully), the constraints may actually be lessened, instead > of tightened where intended. > > Is this your experience as well? > > Austin > > > > Ken McElvain wrote: > > >>Muthu wrote: >> >> >>>Hi, >>> >>>I Have 2 Flip Flops (FF1 and FF2). The actual combination logic delay >>>in between these FFs are 10ns. Say i have defined a path between FF1 >>>and FF2 as a multicycle path in synplify_pro synthesis. >>> >>>Here is my questions regarding this? >>> >>>1. Will the synplify_pro tool will put an additional FF between these >>>FF1 and FF2? or it will simple assume that the dealy between these >>>Flip-Flops are 5ns. >>> >>It will increase the available time for paths between FF1 and FF2 >>according to the number of cycles you specify. >> >> >>>2. I know that, this multicycle path information will be passed to the >>>Place and Route tool. what the place and route tool will do? >>> >>The same thing. >> >> >>>will it put some FFs in between ? or this is simply for timing report >>>generation? >>> >>No logic change is implied by a multi-cycle path specification. >> >> >>>Thanks in advance >>> >>>Best regards, >>>Muthu >>> >>> >Article: 50837
Ray Andraka wrote: > Basically what I've been saying...the SRL16 is the biggest advantage the > virtex lines have over Altera's Stratix. Don't let that capability fall > by the wayside just because your tier 1 customers are not using it. > The tier 1 customers are probably using it and don't know about it. I often see designs where our tools automatically map to them. > > > Peter Alfke wrote: > > >>I'll forward this to our software tools management. >>It is nice to hear that superior hardware feature still mean a little >>something... >> >>Peter Alfke >>============================ >>Russell wrote: >> >> >>>I need a linux version of webpack with a gui >>>that works. If it wasn't for spartan-II devices >>>with distributed ram (SRL16) and some floorplanning >>>ability, i'd be using altera now. >>> > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > > >Article: 50838
Phil Hays wrote:
> ed wrote:
>
>
>>I am doing a desing that's supposed to run at a 100Mhz in a Virtex-II.
>>Is it good desing practice to run the synthesis and PAR tool with
>>higher frequency constraints (ie: 120Mhz)? Or can I assume that if the
>>PAR tool says a design
>>meets the 100Mhz constraints, the desing CAN and WILL run at a 100Mhz?
>>
>
> PAR needs to be run at the design frequency. Don't forget to also
> constrain your I/O timing with offset = in every input other than clock,
> offset = out for every pin output, and both for every I/O. See:
>
> http://toolbox.xilinx.com/docsan/xilinx5/manuals.htm
>
>
> Example that might go into your design.ucf:
>
> # NET "pad_net_name" OFFSET = {IN|OUT} "offset_time" [units]
> {BEFORE|AFTER} "clk_name" [TIMEGRP "group_name"];
>
> NET "TXD" OFFSET = OUT 17 NS AFTER CLK;
>
>
> After PAR claims that the design fits and meets all timing, running
> static timing TRCE and looking at the unconstrained paths can be very
> valuable. If it needs a constraint, figure one out. Look at any
> constraint with "0 items analyzed" carefully to make sure it is checking
> what you need it to. This can happen with some automatically generated
> constraints, so don't panic. Example command:
>
> TRCE -v 10 -u 100 designname
>
>
> Synthesis tools, on the other hand, may need set to a frequency other
> than the design frequency, especially when you get to doing designs that
> push the limits of the parts and/or tools. As a beginner, put this in
> the back of your brain, and don't try to use it yet. When (not if) you
> get a situation where the synthesis tool is mucking with your design in
> a bad way remember it.... And if you do this, don't forget to disable
> the synthesis from sending the fake timing to PAR.
This is why Synplify has a "-route" adjustment to clock specifications
which is an extra squeeze adjustment that is taken into account during
synthesis but not passed on to P&R. It can also be specified on paths
starting or ending at specific registers. Synthesis can get the logic
delays right, but routing delay has a lot of noise in it unless you use
physical synthesis.
>
>
>
Article: 50839>I have two binary counters in different clock domains which i want to >compare. Is it possible to convert to gray code, synchronise into the >other clock domain using double sync flip-flops and then convert >synchronised gray code back to binary to perform the comparison (e.g. >=, >, <)?. Can incorrect results occur on the comparison outputs even >though the counter was synchronised using gray codes. That problem has been discussed a lot in the context of building FIFOs. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 50840
> > In the interests of creeping featurism, a 10-bit A/D converter would > > be interesting, and room for 200 32-bit bins. The 2.5MHz sampling rate > > seems to be perfectly adequate. > > 10 bit at 2.5 MHz are a little bit too much for this approach. But I've done > this ADC in a very simple manner: using FPGA output for the switch, RC for > integration and a comperator. It works fine for lower resolution and > frequency. Of course you could use the comparator in the IOBs of the newer FPGA families, but you need Austin Leseas permission for that. He holds a patent on that design. (US0006246258B1) Maybe you could use a 7-Bit Sigma-Delta DA which can be build at the desired speeds and use the resistor ladder design from the patent to sample the voltage difference with 3-Bit accuracy to achieve the 10-Bits that you require. Kolja SulimmaArticle: 50841
Hi, I have a question about the Xilinx Routing Tools. Assuming we can find some broken interconnections such as single lines, is there anyway to guide the Xilinx tools not to use those faulty components while we do the routing? Thanks! WeifengArticle: 50842
>I agree with Jim Granville that it's a really bad idea to leave nWR >asserted continuously. Are you pulsing nCS? Usually, you expect >a SRAM to perform a write to its internal storage on the rising >edge of (nWR OR nCS). If both are held asserted (low) then >it's not at all clear what will happen. Possibly you get a >write taking effect when the address changes, but it's very >uncertain and very bad practice. If you don't meet the setup/hold times on the address during a write, it can write something anywhere. You might be able to argue that it will only write things that look like the data (assuming that meets setup/hold) and that it won't write to addresses specified by the address bits that don't change. I don't think the spec sheet will say anything about that. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 50843
Hi group, I have a question is that possible to have a DLL (board level looping) in a PLL loop? The purpose is to use the advantage of the DLL AND the programmable frequency of the PLL? Does anyone do this before?Article: 50844
Hi, I'm sorry, I may not have been very clear on the details of my complete process. Here goes: Step 1 : Program FPGA to read data from serial port and write to the external RAM. I described this in details in my previous post. My feeling is that this part is getting done correctly. I do keep the write signal asserted all the time, but the chip select signal deasserts itself when no writing is being done. 64,000 words are written to the external RAM. Step 2: In a similar process as above, I reprogram the FPGA to read data from the external RAM and write to the serial port of the PC. This data is then checked on the PC and found to be exactly the same as what was written to the RAM in step 1. So I write 64,000 words in step 1 and then read all 64000 words in step 2. The reading/writing happens once every 346 cycles (115.2KHz) @ 40MHz in the FPGA. Alternate Step 2 : I program the FPGA to run my 'design code' which reads data from the external RAM and uses it to produce the required outputs. This time 64 values are read in 64 cycles from the external RAM for every run of my 'design code'. Thus the design code will run for 1000 runs before all 64000 values are used from the external RAM. It is during the alternate step 2, when I read 64 words in 64 cycles @ 40MHz, that some of the data read is found to be erroneous. Thanks, PrashantArticle: 50845
Weifeng Xu wrote: > Hi, > I have a question about the Xilinx Routing Tools. Assuming we can > find some broken interconnections such as single lines, is there > anyway to guide > the Xilinx tools not to use those faulty components while we do the > routing? > We do not sell faulty parts. If you find something originally broken, return the part and get a new one. Peter AlfkeArticle: 50846
"Prashant" <prashantj@usa.net> schrieb im Newsbeitrag news:ea62e09.0212201207.82e34a7@posting.google.com... > Step 1 : Program FPGA to read data from serial port and write to the > external RAM. I described this in details in my previous post. My > feeling is that this part is getting done correctly. I do keep the > write signal asserted all the time, but the chip select signal > deasserts itself when no writing is being done. 64,000 words are > written to the external RAM. > > Step 2: In a similar process as above, I reprogram the FPGA to read > data from the external RAM and write to the serial port of the PC. > This data is then checked on the PC and found to be exactly the same > as what was written to the RAM in step 1. ??? Do you really RECONFIGURE the FPGA?? You mean, you pull PROGRAM low to reset the configuration, download a new configuration via serial/JTAG mode and run the second configuration to read the data from the SRAM? Sound dangerous. The IOS go tristate when PROGRAM is pulled low, so who is driving CS, RD, WR to the SRAM? There are at least EXTERNAL pull-ups required. -- MfG FalkArticle: 50847
--------------49D346999AA4B263B130B882
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Seems somewhat limiting, but then it is an employer's market more or
less. It would rule me out too, as well as the few people I know to be
very strong in both FPGAs and computer arithmetic/DSP.
John Jakson wrote:
> I have been seeing an interesting group of job posts for an FPGA
> supercompuer startup for the Bioinformatics industry. The positions
> apparently requires a Phd from only the best 5 US schools so that
> rules me out. Seems to be a new team, location in NY city, maybe SJ
> or SD.
>
> goto \/ and enter FPGA and look at Cybercoders, 2 pages, 8 positions.
>
> http://seeker.dice.com/seeker.epl?rel_code=1102&op=2
>
> Also a google on schrodinger (sitemap, careers..) looks remarkably
> similar as do posts on a no of other job sites!
>
> Good luck hunting!
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 50848
The likelihood of you finding such a fault is fairly low, the parts are
tested fairly hard before shipping. Nevertheless, it is possible for
certain faults to go undetected (I don't think route segments fall in
that category though). There are no direct controls on the router to
avoid specific routing tracks, however you could play some games with
FPGA editor to get there (a very painful path).
Weifeng Xu wrote:
> Hi,
> I have a question about the Xilinx Routing Tools. Assuming we can
> find some broken interconnections such as single lines, is there
> anyway to guide
> the Xilinx tools not to use those faulty components while we do the
> routing?
> Thanks!
>
> Weifeng
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 50849
I am aware of some of those customers that purposely turn off the inference of
the SRL16's because of a misguided (IMHO) attempt of having 'generic RTL
code'. Many of the others don't get SRL16's because they put resets on all of
the flip-flops, which keeps synplify from inferring the SRL16, whether it is
intentional or not. I do know that I use the SRL16's much more extensively
than most users (I've got designs where 70% of the LUTs used are SRL16's).
Ken McElvain wrote:
> Ray Andraka wrote:
>
> > Basically what I've been saying...the SRL16 is the biggest advantage the
> > virtex lines have over Altera's Stratix. Don't let that capability fall
> > by the wayside just because your tier 1 customers are not using it.
> >
>
> The tier 1 customers are probably using it and don't know about it. I
> often see designs where our tools automatically map to them.
>
> >
> >
> > Peter Alfke wrote:
> >
> >
> >>I'll forward this to our software tools management.
> >>It is nice to hear that superior hardware feature still mean a little
> >>something...
> >>
> >>Peter Alfke
> >>============================
> >>Russell wrote:
> >>
> >>
> >>>I need a linux version of webpack with a gui
> >>>that works. If it wasn't for spartan-II devices
> >>>with distributed ram (SRL16) and some floorplanning
> >>>ability, i'd be using altera now.
> >>>
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
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