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
z80@ds2.com (Peter) writes: > >I'm keen on learning the real reasons behind > >the apparent Windows orientation of the EDA industry. > > Because nearly everybody has a PC running windoze. There is also But why is that ? Because you *must* have Windows to run the SW which is available for Windows only. > nothing much wrong with NT4, reliability-wise. I can't comment on that for I don't have a Windows machine :-) Rickman <spamgoeshere4@yahoo.com> writes: > Perhaps there is a third choice which simply has to do with marketing > and cost. If I had the choice of selling one system to say 40% of the > market or increasing my market share to, say 45%, by selling two systems > and doubling my development costs, I think I would choose the one > platform approach. Well, this explains why would a company go Windows only and ask good money for the Windows SW. However, when you have a Windows version *and* a unix version (that is, dev. cost is doubled) then what's the business behind giving away the Windows version (which costed you a lot) and not doing the same with unix ? If you want increased chip sales, then you would give away the unix one too - every chip sold creates money. In fact, you would port the unix version to Linux (this would cost you virtually nothing), put on your web site with big red letters screaming NO SUPPORT - AS IS or YOU CAN PURCHASE SUPPORT FOR LOTS OF $$$ (which is already the case with the downloadable Windows version anyway) thus selling even more chips (Linux die-hards will all buy *your* chips for you are the only one supporting them). It ain't happening, somehow. > My guess is that in the last 3 years or so, the vendors are seeing that > customers who at one time were Unit die-hards, are now willing to use > Windows. Because they have to. Vendors (IMHO) don't *see* the situation, they *create* it. Last year on DAC on the Linux vs. NT shootout (which turned to a unix vs. NT one) the audioence seemed to very much favour unix over NT - of course they may have been a very biased audience. > I would also expect that a lot of potential Windows customers > would not be willing to go to Unix. This is probably true. > Whenever the vendors are asked about Linux versions of their software, > they say they will do it when the customer demand is there. The bottom > line is that they will sell what customers are most likely to buy. Well, if they are asked about it, then there must be some demand ? Customers buy what they are sold. You want to buy a gray hat. You ring the vendor, they say they do not make gray ones, you should buy a blue one. You *need* that hat, so you buy the blue one. The hat vendor can see that hat sales is not hurt by selling blue ones only (all in all, everybodey buys a hat) so they will tell everyone who rings them about gray (or green or red) hats, that the customer demand is blue, buy that one. They will because they have no choice. If they are very desperate, they can go to the other hatshop, which would sell them the same blue hat with an albeit not grey, but yellow or brown overcoat, for 3 times as much. > I would also point out that Unix development is more expensive. The > machines cost more, the software costs more, and perhaps the developers > cost more (not sure about this last one). Well, not necessarily true. A PC running unix costs the same as a PC running NT, an Alpha costs the same running either. Machines which cost more may not run NT (for Microsoft does not supply NT for them) but it is not the problem with the machine, it's a problem with NT. The development software cost is a non-issue. On one hand, you have a plethora of free tools for the unix world, (which, incidently, have been ported to Windows) but even if you didn't, a multi-billion dollar company would not choke on the one-off cost of buying the devtools. Whether a compiler is more expensive for unix than it is for Windows, I don't know, maybe. Still, I don't think that price differences would be so high that a big EDA company couldn't fork it out. Since Linux came up: well, I don't want to go into a Linux vs. NT argument, USENET is full of it anyway. However, it is a fact that Linux supports all architectures NT does plus a lot more, the system comes for free, all the dev. tools come for free and even some commercial unix vendors support (or anounced that they will support) running Linux binaries on their native version of unix. These all mean that doing Linux development is actually cheaper than Windows. In addition, I fail to understand why a C programmer who can program say a synthesis engine under windows would be much cheaper than one which can crank out the same C code under unix. GUI-wise I doubt that X would be inherently harder to work with than the Windows GUI or that it would be less supported by GUI-generators and stuff. I might be wrong, of course. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 16501
Hi David, Good Observations. Yes the Carry chains do run from the bottom to the top of the device. The reason for Data pins on the left and right side enhance the use of Tristate busses which like to use the long line resource on the row. The idea of having LSB down and MSB up needs to fit what you plan to do with the data in your design. Since you mentioned DSP applications I imagine that you will use the carry chain and since that is a vertical LSB down MSB up path your data should stick to that allignment. I would also consider putting control signals on the top and bottom of the device. And lastly any clock signal or other high fanout signal I would place on the top or bottom of the die if you are not using a global buffer for that signal. This will allow the software to assign one of the low skew routing resources to that net. I would look at the Select I/O application note for guidelines on SSO. Best Regards Terry David Langmann wrote: > > Hello, > > I'm in the position of laying out a board with the data flow in the FPGA > more or less known, but with the algorithms yet to be thought out (to be > honest). > > Looking at the Virtex data sheet, I see Cin (carry in) coming in from the > bottom and C-out (carry out) coming out the top. > > Does this actually correspond to the geometry of the chip ie are the carry > lines going from the bottom of the chip to the top? > > I read somewhere that data busses should be connected to the row pins. Does > all this mean that the data bus pins should be placed in ascending order > along the side of the chip with D0 (LSB) at the bottom and the MSB at the > top? > > Thanks very much, > > David Langmann > david@dalanco.comArticle: 16502
On Wed, 19 May 1999 20:18:31 -0400, "Adam J. Elbirt" <aelbirt@nac.net> wrote: >Anyone seen an M1.5 crash caused by a page faulting error? I seem to be >running into it fairly often lately when the tools run the par >executable. > >Adam > Adam, I hope you have solved it by now, but just in case.. Place & route was crashing for me as well. It turned out that I had a typo in my pin placements in the .ucf file -two pins with the same number. 'Still think that a GPF is a bit of a severe error warning! I had similar problems but in the map and trce modules (of course just before a deadline). But this time it was after I had installed MSVC6.0 which shipped with a buggy msvcrt.dll. Fortunately good old MS had posted a 'Service Pack' (aka. bug fix) and this fixed the problem. Hope this is of help -maybe posting the contents of the error dialog (fortunately the contents can be selected and copied using <Ctrl> C) and anything written to the par log file. Cheers, ++Simon Simon Goble simon-g@media-city.com (The '-'s should be extracted for the valid address)Article: 16503
Hi, I would like to know if there are any companies working on reconfigurable chips adhering to RAW standards proposed at MIT. Although there are many work on Reconfiguarble FPGA chips, I am not very sure about any implementation of RAW architecture or any varient of that currently. Any related information is welcome. Thanking in advance. Lalit --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---Article: 16504
On Wed, 19 May 1999 16:51:04 -0500, Tom McLaughlin
<tomm@arl.wustl.edu> wrote:
>All,
>
>I've looked at all of the manuals and finally decided to ask the list.
>I want to assign the pads for my XCV1000 devices and assign I/O
>standards to those pads such as LVTTL, LVCMOS, drive strength and such.
>I am using Leonardo and cannot find an attribute to do this. I can find
>attributes to assign slew rate and such, but not what kind of pad it
>is!!!
>
>Help as I am tired of looking at the manuals.
>
>TBM
>
Tom,
Can understand your frustration -I happened upon them buried in the
'Dynatext' Libraries Guide. You can then instantiate them in your top
level module eg.
module BigChip (
wait_p
);
input wait_p;
IBUF_GTL WAIT_ (.O(wait_w), I(wait_p));
endmodule // BigChip
The whole list of them is most easily found in the
\fndtn\verilog\src\UNIVIRTEX directory which you have to 'tell'
Leonardo to use as a library.
(Of course you probably want to put more in your XC1000 :-)
++Simon
Simon Goble
simon-g@media-city.com (The '-'s should be extracted for the valid address)
Article: 16505SE NECESITAN PERSONAS PARA PROCESAR EMAILS!!! Trabaja en casa 10-30 horas por semana, tiempo parcial o tiempo completo. Ganancias basadas en el esfuerzo del tiempo que quieras emplear. Puedes ganar desde $2,000 hasta $6,000 por mes o más. Esto no es MLM, y no te cuesta nada para empezar. Este es un legitimo negocio que puedes trabajar desde tu propia casa, practicado por miles de personas alrededor del mundo. Todo lo que necesitas es una computadora con acceso a E-mail, y tu puedes comenzar a ganar un dinero residual antes de fin de mes. Para más información, contacta a la siguiente dirección " mail to: rectv@ciudad.com.ar " y escribe "HISPA98" en la subject line de su mensaje. No tienes nada que perder y mucho que ganar, vamos anímate. Tu éxito es nuestro éxito. Indícame por favor, en qué sitio has leído este anuncio. Gabriel Tello González / CEVINE ATLANTICO Mail To: rectv@ciudad.com.arArticle: 16506
Austin Franklin wrote: > > I just thought of one SMALL problem... I don not believe Virtex supports 5V > PCI??? XAPP 133 (dated Oct 21, 1998) claims so. Is it incorrect? -- Phil Hays "Irritatingly, science claims to set limits on what we can do, even in principle." Carl SaganArticle: 16507
hi all I'm looking for a program that translates C into VHDL. I know there is at least one around and its name is AIRT Builder, but can't find who makes it. thanks EnricoArticle: 16508
Peter Lang wrote: > > Hi all, > i heard about the frequence doubling in the new virtix family. > But what I need if not twice the frequnce but nearly 20 times the input > clock frequence. > I now have a crazy idea: > Maybe it is possible to implement a Delayline with normal > CLBs and routing. By changing the numbers of CLB a signal is > travelling through an feed it back inverted it must be possible > to adjust the frequence like with a DCO. > > Has anybody experience with thing like that > please let me know > thanks peter How about another crazy idea? Use a Lucent OR3T part that will let you PLL with a 64x multiplier. You can program the frequency by changing the divsors. Two divisors are multiplied (and a third divided) with each one being programmable to integers 1 through 8. X x Y / Z = a lot of frequencies. But you won't get frequency adjustment by changing a delay line. You would have to use a divider somewhere. Adding a delay adjustment will only adjust the clock phase. -- 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: 16509
Rickman wrote: [...what is a thread...what is a process...] A process conceptually maps to a single task or program. For example, a web browser is typically a process, as is a spreadsheet, etc. Traditional operating systems typically take good care to ensure that processes don't interfere with each other unintentionally. This is achieved, for example, by allocating separate memory spaces to each process. Resources obtained from an operating systems (such open files or sockets) are also typically held on a per-process basis. A process, thus, is best viewed as a cohesive task, along with all of the system resources required to fulfil the task. Processes don't share data unless they explicitly take steps to do so. Where an operating system doesn't take good care to protect processes from other rogue (read badly programmed) processes, the OS is flaky (Windows 3.1, for example). A thread, on the other hand is a linear sequence of machine instructions executed in a consistent environment. The 'consistent' environment is (typically?) that of a thread's process. Each thread belongs to a process, and each process has one or more threads (of execution). Threads within the same process share the same address space as part of the process environment. A web browser process, for example, might spawn a new thread for each window. In this manner, each window runs independently, although they all have access to the same environment data. Using threads can simplify a programming task. /Processors/ multitask any number of threads belonging to any number of processes. Thread-switching between threads of the same process is typically cheap, but thread-switching between threads of different processes is typically expensive, since the environment, including memory-mapping has to be swapped. This is a performance problem for traditional OS's where the kernel is implemented as a separate process. [Plug] Operating systems, however, can be better implemented by using a safe object model, rather than memory protection, in order to ensure data protection between processes. See http://www.jbed.com, for an example. With this approach, all executable content is forced to adhere to strongly-typed memory access, so it is literally impossible for any /object/ to interfere with with other /object/ without explicit cooperation. This achieves a far finer grained protection than process-level protection, since it ensures safety of memory writes /within/ a process, as well as between processes. Furthermore, with a safe object model, there is no need for heavy-weight memory protection between processes - in fact, objects from different processes can be safely scattered randomly through memory. So process switching win an OS based on a safe object model cna be made as quick as thread-switching. Think about it RolandArticle: 16510
brian_n_miller@yahoo.com wrote: > rolandpj@bigfoot.com wrote: > > > > [JIT:] why not do the same thing, but right down to the hardware, > > rather than down to machine code. What you need, however, is a > > general compiler from a high-level language (Java bytecode?) to > > fpga gates. > > Which function or aspect of JVM operation would most benefit > from reconfigurable hardware? (The aim is) performance, of course. JVM is just an example. RolandArticle: 16511
brian_n_miller@yahoo.com wrote: > rolandpj@bigfoot.com wrote: > > > > I like to to view the problem as an extension of HotSpot/JIT. > > ... Why not do the same thing, but right down to the hardware? > > Reliability. If an FPGA fails to reconfigure itself properly, > then how to recover? (I've gone public, due to no private response.) Forgive my innocence, but why is this perceived to be a problem? The hardware must work. If it doesn't, then the approach is unfeasible. Why is this any different from "If a processor executes an instruction incorrectly, then how to recover?" It might be the case that reconfigurability is flaky at the moment but this just has to be fixed to make dynamic reconfigurability viable. RolandArticle: 16512
The A|RT's web site is: http://www.frontierd.com/ I was wondering how good are the translators from languages like C to syntesizable HDLs. What about nested loops, the variety of C data types, dynamic structures and arithmetic operators? I think the C developer has to cope with lots of restrictions. Has anybody used this tool? Eduardo. Enrico Migliore wrote: > > hi all > I'm looking for a program that translates C into VHDL. > I know there is at least one around and its name is AIRT Builder, > but can't find who makes it. > > thanks > EnricoArticle: 16513
In article <374AD218.4B346478@disca.upv.es>, Tximo <jgracia@disca.upv.es> writes >Hi all, > >I am trying to synthsise a design with Xilinx Foundations F1.5, with >some inputs and outputs. I have a constraint file to locate every >signal in a pin, but I get the error message: > >ERROR:baste:263 - The LOC constraint "P68" (a IOB location) is not valid >for > symbol "linea_lect.PAD" (pad signal=linea_lect), which is being >mapped to the > following site types: > CLKIOB > >My signal is fixed at PIN 68, a normal IOB, but the synthesis tool map >the signal to a clock, and I don't know why. > >Anyone has any idea? > >Thanks to all for reading my message and sorry for my english. > Which synthesis tool are you using? -- Alan Fitch DOULOS, Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK Tel: +44 (0)1425 471 223 Email: alan@doulos.com Fax: +44 (0)1425 471 573 ** Visit THE WINNING EDGE www.doulos.com **Article: 16514
> In article <374AD218.4B346478@disca.upv.es>, Tximo > <jgracia@disca.upv.es> writes > >Hi all, > > > >I am trying to synthsise a design with Xilinx Foundations F1.5, with > >some inputs and outputs. I have a constraint file to locate every > >signal in a pin, but I get the error message: > > > >ERROR:baste:263 - The LOC constraint "P68" (a IOB location) is not valid > >for > > symbol "linea_lect.PAD" (pad signal=linea_lect), which is being > >mapped to the > > following site types: > > CLKIOB > > > >My signal is fixed at PIN 68, a normal IOB, but the synthesis tool map > >the signal to a clock, and I don't know why. > > > >Anyone has any idea? > > > >Thanks to all for reading my message and sorry for my english. > >Article: 16515
Hi all, I am trying to synthesize a VHDL design in the Xilinx Demonstration Board using Xilinx Foundations F1.5. This board has a XC3020A-PC68 and a XC4010E-PC84, although I am only using the XC4010E-PC84. In my design, I have a clock line, and my problem is that I want to assign this clock line to a Global Buffer (GCLK), but I don't know how. Anyone can help me? Thanks in advance.Article: 16516
Hi, I'm using Viewlogic's FPGA express (V3.00) for VHDL synthesis and I'd really like to see the synthesised result in schematic form, at least at the pre-fitted stage, so that I can develop a VHDL coding style appropriate for synthesis - I'm neither a VHDL or FPGA guru. I don't have Viewlogics VISTA tool, which might be just the ticket, so instead I'm wondering can I do it with Viewlogic's EDIF converter (EDIF -> WIR) and its VIEWGEN utility ( WIR -> SCH)? Alternatively, do any of the FPGA vendor's fitting tools (Maxplus 11 etc) provide a schematic view of the input EDIF file? Incidentally, is a schematic-viewer an essential tool in an HDL -> FPGA environment, or can seasoned designers dispense with it? regds Mike --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---Article: 16517
A|RT Builder is commercialized by Frontier Design. go to http://www,frontierd.com to find a local distributor regards, herman beke Enrico Migliore <fatti2@iol.it> wrote in message news:374B8808.2B29F70A@iol.it... > hi all > I'm looking for a program that translates C into VHDL. > I know there is at least one around and its name is AIRT Builder, > but can't find who makes it. > > thanks > EnricoArticle: 16518
In article <7igj45$h1l$1@nnrp1.deja.com>, <micheal_thompson@my-dejanews.com> wrote: >I don't have Viewlogics VISTA tool, which might be just the ticket, so >instead I'm wondering can I do it with Viewlogic's EDIF converter (EDIF >-> WIR) and its VIEWGEN utility ( WIR -> SCH)? > Yes, at least when targeting Xilinx, since FPGA express generates xnf you have to run the xnf2wir to generate a wir file and then can run viewgen on that. I can't remember if xnf2wir was supplied by viewlogic, or it was a Xilinx program. Viewgen does a poor job of generating readable schematics though. >Incidentally, is a schematic-viewer an essential tool in an HDL -> FPGA >environment, or can seasoned designers dispense with it? > The big problem with these tools is visibility into what they are generating. With FPGA Express I use various approaches to get around the tools lack in this area. Minor coding changes can cause the tools to have a noticeable change in amount of generated logic so I like to look early in the coding to verify that it is generating logic that makes sense. I also had problems with the old Aurora? with it generating incorrect logic but haven't seen that with FPGA Express. I tried to get an evaluation copy of VISTA but didn't manage to. With the poor quality of generated schematics I wasn't about to pay something like $5000 (more than viewdraw) to find out that it also useless on any appreciable amount of logic like viewgen. Its also irritating that we used to have that capability for free. I have written a program which read the XNF file to give me information on levels of logic etc and probably will extend that to be able to give equations for all registers to give me the information I need. I suspect this will be better than trying to follow a computer generated schematic.Article: 16519
Hello, does anybody have any information about the leakage current of xilinx spartan I/O pins going beyond the 10ua databook limit? I want to use pins for ~analog functions (dont call it abuse), so I looked for analog parameters, and found some reasonable information about on-resistance in application notes, but no leakage current data. best regards - Ruediger Becker, GermanyArticle: 16520
In article <3744ADBA.9E5F4A96@yahoo.com>, Rickman <spamgoeshere4@yahoo.com> wrote: > know that I have often been frustrated by the lack of a ready hardware > platform that has what I need. Often if it just had some hardware on it > that I could program, then I would have been able to do a lot more with In my experience, product limitations are analog or power supply related more than something I can put into an FPGA. > > > Is this a useful feature for a DSP board? Has anyone designed custom > it. That is why I am building this board. I think there will be a number > of people who would like to use the DSP in conjunction with a good FPGA. Sounds like you've already made up your mind :-) > using a Lucent ORCA part instead of a Xilinx part. It would appear that Altera, last I checked, had free software for entry-level parts like EPF8282A. Plus their software works and is easy to use. Good luck, -rajeev- --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---Article: 16521
rolandpj@bigfoot.com wrote: > > Why is this any different from "If a processor executes an > instruction incorrectly, then how to recover?" If my PC locks up, I reboot it. Can I do the same with reconfigurable chips? > It might be the case that reconfigurability is flaky at the > moment but this just has to be fixed to make dynamic > reconfigurability viable. I won't hold my breath. --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---Article: 16522
rolandpj@bigfoot.com wrote: > > (The aim is) performance, of course. JVM is just an example. *yawn* But which functions or aspects of JVM operation would clearly benefit from reconfigurability. If we can't provide specifics, then I'll assume the applicability of reconfigurability to bytecode execution is more a warm fuzzy dream than an avenue worthy of investigation. Science demands skepticism. Time spent pondering reconfigurable bytecode execution is likely wasted while the mainstream continues to advance the speed and capacity of static chips. --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---Article: 16523
Enrico Migliore wrote: > > hi all > I'm looking for a program that translates C into VHDL. > I know there is at least one around and its name is AIRT Builder, > but can't find who makes it. > > thanks > Enrico C Level Design also makes such a beast: http://www.cleveldesign.com Cheers, Michael Barr P.S. No affiliation. Never even used the product.Article: 16524
> Austin Franklin wrote: > > > > I just thought of one SMALL problem... I don not believe Virtex supports 5V > > PCI??? > > XAPP 133 (dated Oct 21, 1998) claims so. Is it incorrect? They may claim it does....but.... They don't provide a VCCIO pin, which is to be used for the clamp diodes...and it can't technically meet spec if they don't. PLX has the same problem with the 9054...it's a 3.3V part, with no VCCIO pin... Any PCI interface that is NOT 5V powered, and is used in a 5V environment, has to have VCCIO...and same is true for any other voltage variants... Austin
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