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
I've had the same trouble with modelsim and 'BEL' if it is not declared in the architecture where it is used. Never got to the bottom of why it was no good in a package. Declare it locally and it should be OK. Stewart Cobb wrote: > I've been trying to construct some RPM's in VHDL (thanks > to Ray Andraka for inspiration!). > > The problem I'm having comes when I try to do a functional > simulation in ModelSim. > ModelSim doesn't like the "BEL" constraint. I get errors > like the following: > > # WARNING[10]: m2s.vhd(139): Making two objects with the > name "bel" directly visible via use clauses results in a > conflict, neither object is made directly visible.(LRM > Section 10.4) > # ERROR: m2s.vhd(139): Attribute bel has not been > declared. > > The line numbers refer to lines like this: > > attribute BEL of m2s_LUT : label is bel_luts(bel_i); > > What I /think/ is going on is that the attribute name > "BEL" conflicts with name of the character 'bel' (seventh > character in the enumerated type "character"). > Type "character" is part of the "std" library which is (by > definition!) always loaded. > I would think these names should be in separate > namespaces, but ModelSim apparently thinks otherwise, and > quotes the VHDL Language Reference Manual ("LRM Section > 10.4") in its error message to prove its point. > > Xilinx XST seems to treat these as > separate namespaces, and doesn't notice a conflict. > > So what can I do about this? > > I can't rename the attribute, because then the Xilinx > mapper won't recognize the constraint. > > I could move the BEL constraint from the VHDL source to a > UCF file -- but I've been trying very very hard to move > all the constraints to VHDL for portability, and that > would be a step backwards. > > I can't rename the character 'bel', > because it's part of the IEEE standard (and probably a > mil-spec to boot). It's also the historic ASCII name for > that character, and changing it would confuse a lot of > people. > > I can give up functional simulation, and just rely on > post-PAR simulation. I'd rather not do that, because I'm > depending on functional simulation to debug some of my > more complex RPM macros, which disappear after synthesis. > > If the problem were with XST and not Modelsim, I could > surround the offending lines with "-- synthesis > translate_off" constructs. But instead I have lines that > XST needs to see and ModelSim needs to ignore. Is there a > "-- modelsim translate_off" construct? > > The best solution I can think of is for Xilinx to provide > an additional constraint named, say, "XBEL", that works > the same way as the existing BEL constraint. But for that, > I'd have to wait for Xilinx to agree and then implement > it. > > Any suggestions for what to do in the meantime? > > Cheers! > --Stu -- --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, 1759Article: 56301
Thanks, Ray! That did it. I guess the problem is that "things" in packages are defined (LRM) to share a namespace, but "things" in individual files have a different namespace. Odd, but that seems to be the way it works. Thanks again for the tip. Cheers! --StuArticle: 56302
On Mon, 02 Jun 2003 10:48:53 -0700, Peter Alfke <peter@xilinx.com> wrote: >And please no jokes about the California power crisis of 2 years ago. >That was not due to lack of power, but due to greedy >managers/manipulators and stupid politicians... No, that was due to stupid enviromentalists who would rather have mice than air conditioning and cold beer ;)Article: 56303
We classify it as both hardware(FPGA itself and associated gates) and software(VHDL level listing and programming data stream) Joe Gallegos Ray Andraka wrote: > Perhaps, but it is different from the more traditional software in that there > are concurrency and timing issues that do not apply for traditional software. > The design flow is hardware, the result is perhaps software. For that reason, > it does make sense to differentiate it. I am constantly fighting the problems > introduced by people treating the FPGA contents as software when they do their > designs, and we see a fair amount of the results of that mentality here too. If > for no other reason than to avoid that leap, I think it is prudent to call it > something other than software. > > Steve Casselman wrote: > > > I have always called it software. Since 1986. FPGAs are a kind of computer > > chip with a very strange programming model. The programming model was > > created by hardware engineers who were concerned about current spikes during > > programming. They were not concerned about reprogramming the device so much > > as just programming it the first time. They did not really care about > > programming parts of the device although that is starting to become more > > important as you get really large devices with embedded processors and > > internal programming ports. > > > > In the end it is software. It is based on sram it is updatable at any time. > > It can be stored on a disk or delievered over a network. > > > > It is software.. > > > > Steve > > > > "Joe Frese" <joefrese@hotmail.com> wrote in message > > news:c176b8c2.0305211126.6e642649@posting.google.com... > > > I've got a question of terminology for the group: is FPGA design > > > generally classified as hardware, firmware, or neither? Most of the > > > designs I've worked on have served to interface firmware with > > > hardware. It seems that firmware engineers like to think of FPGA > > > designs as more firmware, and that hardware engineers like to think of > > > FPGA designs as more hardware. As an FPGA developer, though, I'm of > > > the mind that the unique design considerations of the technology > > > justify a new and separate category . . . > > > > > > A coworker suggested the term "coreware," but apparently that's a > > > registered trademark of LSI Logic. Is there another term with the > > > -ware suffix commonly used to refer to code (VHDL, Verilog, or > > > otherwise) intended to be implemented in an FPGA? > > > > > > Joe > > -- > --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, 1759Article: 56304
"B. Joshua Rosen" <bjrosen@polybus.com> wrote in message news:<pan.2003.06.02.18.57.46.805141.2430@polybus.com>... > ModelSim support has returned to HDLmaker as of version 6.6.1. HDLmaker is > an open source Verilog/VHDL hierarchical code generator for FPGAs and > ASICs. > > HDLmaker is available free of charge from Polybus Systems at > > http://www.polybus.com/hdlmaker/users_guide/ I just checked this website and found out that it supports the Xilinx XC4000e series. Does this implies that I will be able to synthesize my old design and use the Free Xilinx implementation tool complete the process? JacquesArticle: 56305
Still a dead issue -- Even at 1 Mhz edge speeds will remain a problem -- the key is 'edge' speeds Rene Tschaggelar wrote: > At 10MHz clock the thing would be technically doable. > The original poster never mentioned the usual 200MHz+. > A do-your-own 68000 cpu kind of. > > Rene > > Peter Alfke wrote: > > Let's look at this from the inside out. > > Your 800k-gate FPGA chip will measure about 7 x 7 mm. (I remember that > > the XC2V6000 die is about 21 x 21 mm, and you want about 8 times less in > > area, about 3 times less on each side. We can argue about gate count > > metrics, but this will be close.) > > If you stuff this little chip of less than 300 mil on-a-side into a big > > 40-pin package with 600 mil width, 100 mil pin spacing, and 2 inch > > total length, (I remember those things well) you inevitably end up with > > some very long bonding wires or lead-frame metal runs, once you get away > > from the nice central pins (which should be dedicated to Vcc and ground) > > The worst wires will be an inch or even 30 mm long, and their inductance > > will be totally unacceptable for modern fast output transitions. And > > don't even mention wire-wrap... > > > > So, the 40-pin DIP is a dead issue for modern circuits, even if FPGA > > vendors wanted to cater to the small market for very low > > pin-to-logic-ratio devices.Article: 56306
For Peter Alfke et.al. I have an issue with Xilinx dropping support on their new tools on legacy devices -- For example Xilinx continues to offer militarized XC4005 devices but their current ISE s/w does NOT support these devices(ie. routing). Hence, one is forced to used the old XACT(crica 1990's) tool set. What's up? Ray Andraka wrote: > Hmm, Not sure you can get it anymore if you don't already have it. Ask > your FAE for a copy. No, I don't believe 5.2 supports the Spartan I's. The > problem with 4.2's router is it makes every path a critical path, so although > you can see which path(s) fail timing, fixing those may not fix the > underlying problem. > > email_address@message.end wrote: > > > Ray, > > > > What is v3.3sp8, and how do I get it? > > > > I can't use ISE-5.2 with a 5V Spartan, can I? > > > > Thanks, > > Gary. > > > > On Sun, 01 Jun 2003 21:59:04 GMT, Ray Andraka <ray@andraka.com> wrote: > > > > >Use v3.3 sp8 instead. The router in 4.x is lazy. FWIW, I've had some > > >good results so far with 5.2 sp3. Seems Xilinx has fixed many of the > > >problems I saw with the 4.2 router (Thank you). > > > > > >email_address@message.end wrote: > > > > > >> Hi all, > > >> > > >> Xilinx ISE is giving me fits. I could swear that it hates me! This > > >> is version 4.2i, by the way. Version 5 does not support the part I'm > > >> using. > > >> > > >> Here's what's happening: > > >> > > >> The design is very close to -not- meeting the speed requirement, which > > >> is 50 MHz. > > >> > > >> If, when ISE runs, it does 'improving timing' passes, the speed comes > > >> out at 50.314 MHz. If it does not run these passes, I get 47.246 > > >> > > >> The problem is, I can't figure out how to get it to run these passes! > > >> Some times it does, some times it doesn't. The help file tells me to > > >> check an option box, but that box doesn't exist! > > >> > > >> Please, how do I turn this option on? Right now, ISE is stuck in the > > >> mode where it does not run these cleanup passes. :( > > >> > > >> And, if someone has a tutorial-like document for guiding place and > > >> route, I would like to see it. Basically, I want to 'suggest' to P&R > > >> that certain (Verilog) modules belong in certain haves of the chip. > > >> > > >> Much Appreciated, > > >> Gary > > >> gwhelbig-at-yahoo-dot-com > > -- > --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, 1759Article: 56307
jetmarc wrote: > > > The other problem, is that a little flash ram is not so little: 2.5 > > Mbytes. > > Why don't FPGA chips support compressed bitstreams? Some do. > I recently did a such a thing in software (on a self-reconfiguring SoC). > The original bitstreams were in the range of 500 kbytes, and compressed > down to only 16-25 kbytes. I left out all framing information and then > used LZ77 and Huffman encoding. About 200 bytes of assembler code are > necessary to reconstruct the original bitstream. 20:1 sounds very high compression, esp of 'design' not 'empty' FPGA. > Now that FPGAs even DES-encrypt their bitstreams, one should really > think they have enough resources to support compression, too! We did some trials with Run Length Encoding, which has very low silicon cost, and compressions at the low end of the scale, but still usefull. A FPGA vendor could take a more focused path (Skewed RLE), plus take some bitstream care to further assist compression - but it's all engineering time, and also likely to affect release schedules. -jgArticle: 56308
Peter Wallace wrote: > > The SST 45LF010 (1Mb) has an all ones read command so it will connect with > only one inverter as glue, alas it is the last of it kind, the later (and > larger) 25 series parts have an 03 (ISTR) read command so they need a > $.80 PIC or tiny CPLD helper, still cheaper than anything from X or A... > Markus Meng wrote: > > That's the way it is. I am jst wondering why SST or ST or others do not jump > on this train by simply changing the command for the read array mode to > something like all '0' and all '1'. They would not CHANGE the command, but there is certainly a 'glaringly obvious' case for an ALIAS code of all 1's to start a Read-all. Besides system loaders, there are other applications that would benefit from clock-only dump of the serial memory - trivial silicon cost, for a bigger market footprint. Send an email to SST/ST/Atmel to suggest it ! -jgArticle: 56309
Paul Leventis wrote: > > > Just my $0.02 worth. I did a project using MaxPlus2 a couple years > > ago. We were pushing density on a 10K100A part and also needed speed on > > a portion of it. We found that the placement the tools were using could > > not be understood by us. When we tried using constraints, we found that > > as often as not, we were working against the tool rather than helping > > it. So constraints are not an easy tool to use effectively. > > It is hard to improve the push-button placement results through constraints, > and I'm pretty sure it's impossible to beat the router's results. For 10K > and 20K, applying region constraints can help, as a human can sometimes > figure out how to partition their design to fit the hard routing hiearchy > boundaries in these parts better than the placer. In the case of Stratix > and Cyclone, it is much harder since there are no longer any hard > boundaries. For very regular/datapath designs (hi Ray) with short critical > paths, relative placement constraints can still be beneficial. > > Many times that users experience optimization success through the > application of placement constraints, this is purely due to random noise -- > if the placer seed is swept across the before- and after-designs, any > advantage often disappears. This is a good thing... it means that > push-button compile is doing a good job. > > Note: The application of placement and routing back-annotation in order to > preserve the performance of a previously successful fit is still _very_ > valuable in many designs. It allows one to move a design from one version > of Quartus to another, or to make small changes to a design without > affecting the rest of it. Not to mention the important version control, and even EMC approval, issues. This 'statistical nature' of 'similar-but-not-the-same' results has to be a real concern to the 'engineering' side of design. I can imagine it would get interesting explaining this to a ISO-9001 consultant, or even a large companies quality manager. -jgArticle: 56310
"Bram van de Kerkhof" <bvdknospam@oce.nl> wrote in message news:<1054561920.762580@news-ext.oce.nl>... > Hello, > > I'm looking for an evaluation board of the Virtex 2 (actually for the > Spartan 3 but as there are none available i will have to verify on the > Virtex 2) > I want to verify a ddr-sdram and 300 Mb's lvds link design. Two avaluation > boards is also ok (one for ddr and one for lvds). > > Who has some idea's ? > > Yours Bram > > -- > ================================================== > Bram van de Kerkhof > > OCE-Technologies BV > Building 3N38 > > St. Urbanusweg 43, > Venlo, The Netherlands > P.O. Box 101, 5900 MA Venlo > ================================================== > Direct dial : +31-77-359 2148 > Fax : +31-77-359 5473 > ================================================== > e-mail : mailto:bvdk@oce.nl > ================================================== > www : http://www.oce.nl/ > ================================================== AVNET has a Virtex 2 evaluation board kit (XC2V1500) that costs $1,000. I have purchased the XC2V4000 board kit ($2,500). I have had problems programming the XC2V4000 board MCM module ( Flash Module), but they are Xilinx software problems. The board is well designed and works OK. It includes a DDR-SDRAM interface to a PCI bus. I did not use the DDR SDRAM or the PCI bus. I did interface the AVNET 857T board to the AVNET XC2V4000 board. The Memec board may be less trouble due to use of the configuration PROMs. Bill HannaArticle: 56311
Hi, Does anyone know of any bidirectional 5V to 3.3V level converters? Thanks,Article: 56313
ADI Sharc processors (8 - 21065s), Xilinx FGPA. ADI tools to talk to the Sharcs. I didn't do any work with the FPGA so I can not comment on the FPGA tools. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3EDA52FC.138FC0B2@yahoo.com... > KG7HF wrote: > > > > Generally, it's OK to put various devices in a single chain. You simply > > have to use a configuration tool to describe the JTAG chain to the debugger > > so that it knows where the device you are trying to debug lies in the chain. > > Part of the description is the number of devices, and the size in bits of > > the instruction register. The debugger will ignore all the other devices > > by using the bypass instruction and placing them in bypass mode. This > > allows the debugger to "focus" on the device in the chain you are trying to > > debug. > > What devices have you used in a scan chain together? What tools did you > use to talk to these devices? > > > -- > > 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: 56314
"Antti Lukats" <antti@case2000.com> wrote in message news:80a3aea5.0305270412.307530aa@posting.google.com... > Hi > > latest Xilinx iMpact doesnt seem to support the old style Parallel III > cable any more, and it seems there is no way to get the bitstream > into Spartan - the iMpact generated STAPL file does not work with JAM > player 2.3 gives bound error. > > We just received some Spartan II evaluation boards only to find out that > there are no means to get them configured. > I've got a Spartan II part on a PCI eval board. Multilinx/USB works fine, P-III cable fails to raise Done at the end. 5.2.02i software. The P-III cable is marked 5 volt only, so I just assumed the 3.3 volts at the JTAG connector wasn't enough. But I see an Answer Record 8096 saying it should work at 5, 3.3, and 2.5 volts. My experience with programming cables is you just keep trying different things until something works, and hope it still works tomorrow. failure info for P-III cable: Boundary-scan chain validated successfully. Validating chain... Boundary-scan chain validated successfully. '2':Programming device... done. INFO:iMPACT:579 - '2': Completed downloading bit file to device. INFO:iMPACT:580 - '2':Checking done pin ....done. '2': Programming terminated, Done did not go high. PROGRESS_END - End Operation. Elapsed time = 4 sec. =>Article: 56315
You're talking about 'Foundation 3.3i', right? Yes, I have a copy. I'll try to find the service packs -somewhere-. Oddest thing: I moved the source to another (the client's) system, and exactly the same source synthesized with a 10% greater Fmax. And it ran the clean-up passes whether it needed to or not. I installed the software on both systems, and the service pack (3) came from the same CD-ROM. Somewhere there's a difference between the two installs, and it is making a big difference. Looks like I have a ton of tool-chain debugging to do. :( This is making 'Brand-A' look better and better every day. ;) Do you have any tips on making the location constraints work work 4.2i? I tried it according to the manual's definition, and it barfed all over them. I tried to locate a macro into one half of the chip, and it insisted that I was trying to put it into the I/O cells, and gave up. Thanks Again, Gary. On Mon, 02 Jun 2003 14:26:43 GMT, Ray Andraka <ray@andraka.com> wrote: >Hmm, Not sure you can get it anymore if you don't already have it. Ask >your FAE for a copy. No, I don't believe 5.2 supports the Spartan I's. The >problem with 4.2's router is it makes every path a critical path, so although >you can see which path(s) fail timing, fixing those may not fix the >underlying problem. > > >email_address@message.end wrote: > >> Ray, >> >> What is v3.3sp8, and how do I get it? >> >> I can't use ISE-5.2 with a 5V Spartan, can I? >> >> Thanks, >> Gary. >> >> On Sun, 01 Jun 2003 21:59:04 GMT, Ray Andraka <ray@andraka.com> wrote: >> >> >Use v3.3 sp8 instead. The router in 4.x is lazy. FWIW, I've had some >> >good results so far with 5.2 sp3. Seems Xilinx has fixed many of the >> >problems I saw with the 4.2 router (Thank you). >> > >> >email_address@message.end wrote: >> > >> >> Hi all, >> >> >> >> Xilinx ISE is giving me fits. I could swear that it hates me! This >> >> is version 4.2i, by the way. Version 5 does not support the part I'm >> >> using. >> >> >> >> Here's what's happening: >> >> >> >> The design is very close to -not- meeting the speed requirement, which >> >> is 50 MHz. >> >> >> >> If, when ISE runs, it does 'improving timing' passes, the speed comes >> >> out at 50.314 MHz. If it does not run these passes, I get 47.246 >> >> >> >> The problem is, I can't figure out how to get it to run these passes! >> >> Some times it does, some times it doesn't. The help file tells me to >> >> check an option box, but that box doesn't exist! >> >> >> >> Please, how do I turn this option on? Right now, ISE is stuck in the >> >> mode where it does not run these cleanup passes. :( >> >> >> >> And, if someone has a tutorial-like document for guiding place and >> >> route, I would like to see it. Basically, I want to 'suggest' to P&R >> >> that certain (Verilog) modules belong in certain haves of the chip. >> >> >> >> Much Appreciated, >> >> Gary >> >> gwhelbig-at-yahoo-dot-comArticle: 56317
On 2 Jun 2003 09:00:05 -0700, billh40@aol.com (Bill Hanna) wrote: >email_address@message.end wrote in message news:<sjmkdvo9n34acge8qne98kh6dsbundm8up@4ax.com>... >> Hi all, >> >> And, if someone has a tutorial-like document for guiding place and >> route, I would like to see it. Basically, I want to 'suggest' to P&R >> that certain (Verilog) modules belong in certain haves of the chip. >> >> Much Appreciated, >> Gary >> gwhelbig-at-yahoo-dot-com > > Create a User Constaint File and set the 50MHz clock period constraint to 20 ns. > Add the UCF to the Implement properties. > >Bill Hanna Hi Bill, Frequency constraints I can do. It's -location- constraints that aren't working. Gary.Article: 56319
"Soft Hardware"? "H. Peter Anvin" <hpa@zytor.com> wrote in message news:bbfvra$ug$1@cesium.transmeta.com... > Followup to: <3EDAE3D1.D3C52713@yahoo.com> > By author: rickman <spamgoeshere4@yahoo.com> > In newsgroup: comp.arch.fpga > > > > So in summary, you consider firmware/software to be *any* alteration of > > any form that can be performed on hardware as long as it is not > > permanent, right? > > > > Where do you draw the line between software/firmware and simple > > programming of registers? Many application specific, standard product > > (ASSP) chips do pretty much nothing until they are setup by configuring > > the various registers in the chips. This is not a lot different from > > the typical sort of software/firmware that is programmed into a CPLD or > > even a flash MCU. I have seen ASSP chips that have a manual on usage > > that is easily as large as an MCU. > > > > How do you distinguish ASSP chips from FPGAs in regards to the > > programming? Is the configuration of ASSP chips also called > > software/firmware? > > > > Yes, and that is not just me, either. In fact, a lot of these kinds > of chips require the driver to upload firmware, which sometimes > trigger copyright concerns. This is a common discussion topic on the > Linux Kernel mailing list, and it's *always* referred to as firmware. > > -hpa > -- > <hpa@transmeta.com> at work, <hpa@zytor.com> in private! > "Unix gives you enough rope to shoot yourself in the foot." > Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 56320
On Mon, 02 Jun 2003 17:24:11 -0400, Jacques athow wrote: > "B. Joshua Rosen" <bjrosen@polybus.com> wrote in message > news:<pan.2003.06.02.18.57.46.805141.2430@polybus.com>... >> ModelSim support has returned to HDLmaker as of version 6.6.1. HDLmaker >> is an open source Verilog/VHDL hierarchical code generator for FPGAs >> and ASICs. >> >> HDLmaker is available free of charge from Polybus Systems at >> >> http://www.polybus.com/hdlmaker/users_guide/ > > I just checked this website and found out that it supports the Xilinx > XC4000e series. Does this implies that I will be able to synthesize my > old design and use the Free Xilinx implementation tool complete the > process? > > Jacques HDLmaker isn't a synthesis tool, it writes hierarchical Verilog or VHDL, generates pad rings, synthesis scripts and place and route constraint files. It can still generate pad rings and constraint files for 4000 series devices but you would still need a synthesis tool that understood the devices and an old version of the Xilinx tools. The latest version of HDLmaker no longer puts out the .cst files that were used by the old XACT tools but the early versions of the current tool family (1.x or 2.x) had support and for 4000 series devices and the .ucf constraint file format (which HDlmaker does generate) so the constraint file put out by the current version are compatible with those early rev Xilinx tools.Article: 56321
Mark Schellhorn <mark@seawaynetworks.com> wrote in message news:<Y6KCa.1870$V77.177463@news20.bellglobal.com>... > parallel_case is used to tell the synthesis tool that it needn't worry about > priority of one case item over another because they are exclusive by design. > Consider this potential RTL code for a one-hot state machine: > > case (1'b1) // parallel_case > R_state[0] : do_something; > R_state[1] : do_something_else; > R_state[2] : do_another_thing; > endcase > > I know that by design, only one bit of my R_state vector will ever be hot. The > synthesis tool, however, doesn't know this and will build a priority decoder > unless I tell it that the cases are exclusive (parallel). > > If the case statement itself is exclusive, i.e. > > case (R_state[1:0]) > 2'b00 : do_something; > 2'b01 : do_something_else; > default : do_another_thing; > endcase > > then no parallel_case directive is needed. There is another directive called > infer_mux that can be used if the target technology library contains multiplexor > cells that the synthesis tool will not infer by default. It can be used to force > the tool to use these mux cells rather than building a mux out of gates, which > may or may not be desireable depending on your synthesis objectives. > > Mark Hi Mark, Nice explaination. My question is , Case doesn't imply MUX by default? Should we have synthesis directive //Parallel_case Regards, MuthuArticle: 56322
Austin Lesea wrote: > > Rick, > > Actually, the bonuses were good, the profit sharing adequate, and the fact > that we had 0 layoffs, quite pleasant. > > Who else can say that they were: profitable, kept all of those inventive > people happy, made lots of useful products for lots of customers (and sold > them profitably), had no layoffs, and improved customer services, and > introduced new products besides? > > No one. > > Sorry. Cheap shot on your part. But Peter is correct: the market decides, > and it has voted overwhelming for our solutions. Sorry if you feel it was a cheap shot. But I felt that Peter's comment was a cheap shot. As to the specifics of Xilinx economics, I can't seem to get to any data at Yahoo at the moment so I can't speak from facts, but I follow Xilinx stock and I remember seeing some pretty red ink flowing over the last two years. Why else would the price drop from $90 per share to under $15? As to the market, the fat lady has not sung. I like Xilinx products. I think they are pretty good, although not perfect. But there are new chips from the competion all the time and the competition is more than just Altera. I am finding the new Lattice parts to be very, very interesting. That does not take anything away from the advantages of the Xilinx parts. But it does present some new options offered by no one else that I can find. Sometimes I think the image projected here for Xilinx is a bit smug. I am sorry if that offends you. I understand that your paycheck comes from Xilinx and you are one of their biggest cheerleaders. But once in awhile you and less often Peter cross a line when talking about the competition. Boosting your products is one thing, but trying to tell us what is wrong with the competition is not anyone's forte. Often I find that the "facts" given in such a discussion are just plain wrong. A good example of of uneven comparison is the way that you often compare the difficulty of making custom chips at current process technology vs. buying FPGAs. This is apples to oranges since a given design that can be done on an FPGA can be done on a chip much smaller on a process two years old. The NRE of such a design will be much less than using "current" technology and will still give a lower cost than FPGAs. I have yet to see you reply to a posting which brings up these facts. This is not germane to the issue discussed above, but illustrates my point about uneven discussions. I don't wish to have an argument with you. I am just giving my opinion. I hope you understand that. -- 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: 56323
Yes, Peter, the whole industry was down and Xilinx is no exception. So why did you claim that "all these companies so small and/or doing so poorly"? I didn't think you were gloating, but I also don't think it was a reasonable assessment of the technology. I felt your comment was a cheap shot. I seem to recall some of your past postings where you mention that you don't like to discuss the competition because doing so makes it look like you are taking cheap shots, or something similar. That is exactly how it looked to me. I gave a much longer reply to Austin because I feel he projects an image here that is a bit stronger in knocking the competition. As I said there, I like Xilinx products and I forgot to mention that I also like their support. I expect to be using the Spartan 3 in a new design shortly. But no technology is "perfect". The rational that you gave about company size is not valid. There are new chips out that have not seen their chance at the market place. But I can tell you that Xilinx is losing some sockets to them. My design has replaced two Coolrunner parts with the Lattice parts. I thought the Coolrunners were perfect for the job. But Xilinx would not come down on price on one and they put the part in too large a package for the other. I am sure I am not the only engineer who sees the advantages of some of the new flash parts, even compared to the FPGAs. BTW, Xilinx FPGAs were never considered for these sockets because none of the current families have 5 volt tolerance. Seems that is making a comeback these days. So I hope you can take my comments in the sense they were intended, not as an insult or argument, but as a comment on what I am reading here. Peter Alfke wrote: > > Rick, that's a cheap shot. The whole industry is down... > But at least we did not lay off anybody, unlike some of our competitors. > > I was not gloating, just pointing out that there must be a fly in the > ointment with all those glorious technologies that were mentioned. > > Peter Alfke > ===================== > rickman wrote: > > > > > > I remember a time when Xilinx stock was over 90. Last time I checked it > > was still below 30. I bet there are some very unhappy investors out > > there still. > > > > How was *your* bonus last year? ;) > > > > -- > > > > 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 FAX -- 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: 56324
On 2 Jun 2003 21:22:58 -0700, muthu_nano@yahoo.co.in (Muthu) wrote: > >My question is , Case doesn't imply MUX by default? Should we have >synthesis directive //Parallel_case Verilog is specified similarly to C in that the entries in the case statement are compared to the case expression one by one and if there is a matching entry it is used. In this sense, case defines a priority selector. If you want to enforce parallel case (which may or may not generate smaller and/or faster hardware) you need to ask specifically. In my opinion the best practice is to use if/else if construct for priority and case for parallel select so that you can add parallel_case by default to all case statements. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations
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