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
tom1@launchbird.com (Tom Hawkins) writes: > I've search the net many times, but have never found a good > open-source block diagram editor -- a tool that is not only > invaluable for hardware design, but also very practical for > software applications, especially hard real-time systems. [...] Not sure if this is some technical EE use of the phrase 'block diagram', but if not, I assume you've tried dia? I only played with it for about 5 minutes, but it seemed to do some useful stuff. JohnArticle: 56426
Hi, Is "defparam" is synthesizable or not? I have tried with xilinx XST. But it is giving some errors. So, currently i am passing parameters with #(). Any one used defparam in the design? Regards, MuthuArticle: 56428
Hi, In all Xilinx block RAM Primitives, they have allocated Parity bits (1 per byte) for each locations. If we see the 32bits with RAM, additional 4 bits being provided for the Parity. In most of the cases, we are not using this. This is because, all our RAM is internal, there is not possibility of data corruption. If this is the case, why they have provided that parity bits. Regards, MuthuArticle: 56429
"Jesus Jimenez" wrote in message > designs, so my question is: is it possible? > I'm not too sure what your problem might be, but the answer is yes as I was doing so last year this time (with up to 3 Nios' in a system on apex20ks). I was using Nios 2.0 with Quartus 2.0 and then 2.1. It's been a while but I remember something about a whole lot of (I'm guessing) initialization instructions that have to be carried out, and then your program afterward. If you used the c compiler it just gets worse. So I'd say try simulating for a longer time as a start. you should also take a look at where nios is fetching from.Article: 56430
rk wrote: > > rickman wrote: > > > rk wrote: > >> > >> Bob Perlman wrote: > >> > >> >>There are also FPGAs on the way to Saturn on the Cassini > >> >>spacecraft. > >> > > >> > I'm pretty sure some FPGAs that I RMA'd a while back ended up > >> > going to Pluto. > >> > >> That's probably a bit doubtful as no spacecraft has yet gone to > >> Pluto and none are en route. There is one project that is going > >> to go to Pluto but it's still in the early stages (the early > >> stages can last a while ;-) and hasn't yet had it's Critical > >> Design Review. Perhaps what you RMA'd was for a development > >> project for a mission to project and those sorts of things go back > >> many, many years. > > > > I think you need to reread his message with a smiley (possibly > > winking) at the end. RMA means "Return Material Authorization" and > > is usually used to return defective parts. > > > > Sometimes I think we have too many engineers in this group. ;) > > No, just thought that perhaps he was involved in one of the many Pluto > development projects. > > We of course know that all of the RMA'd parts get sent to Mars. Perhaps you are right. And all the EOL'd parts go to Venus! -- 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: 56431
FE wrote: > > Sorry Peter but I think you can say your product are better because you > have more sales. Most of the time the selection of a part is historical. > What I mean is if a company use fpga supplier Y for their old product, they > have 99% of the chance they will use a fpga supplier Y part for their new > product whatever the technology is the best or not because they have the > tools (no learning curve), they have volume price discount on all fpga > supplier Y parts independently of the volume target of this new project, > they have good relationship with the supplier/rep/distributor, ... > > If people would switch company each time a product from one company is > better then an other, I think you would have been in bankrupt in around 1994 > when you had your 4000 family product with your stupid tool who wasn't able > to route anything against altera 8000 family with it easy tool max+plusII. > > Most of the time, when a company start, they select the designer's known > fpga supplier (not necessarly the best technology) at the startup moment and > stick with it for the rest of their life. Actually I know of many companies that do switch parts depending on even just a few dollars in price. I worked at a telecom test equipment maker who would see which company made parts that would fit a new design. Even if they were already buying a given part for another project, they would still get bids on both their's and the competion's parts. Often this would beat the price down a few more dollars. Or if parts were new, sometimes too new to be available, they would get prices that lost money for the makers until a new process came online which they knew would turn them a profit. Once the new process never came on line and they kept selling the older, more expensive part at the lower price, loosing money, or at least not making much. -- 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: 56432
>I have a question about clock synchronization between multiple boards. >I'm trying to capture data from one board on to another. For this I >will need the clocks to be synchronized, which I'm unable to do. What >would happen if I did the following : > >I connect the outputs from one board to the inputs of the 2nd board. I >run the 2nd board at the same clock speed as the 1st board (but use >the individual board's clocks). Meanwhile, I also take the clk from >board 1 as an input to board 2. Now I try to capture data in board 2 >using clk from board 1 as an enable signal. > >What are the pitfalls using such a design ? How are you going to meet setup/hold with that enable signal? Do you want to transfer data at full speed? Or just occasionally? If just occasionally, then treat the clocks as asynchronous. Run a do-it signal from board 1 to board 2 in parallel with your data word. When the data is ready, flap that wire. It clocks the data into a buffer and sets a ready flag. Run that flag through the normal synchronizer. If you need to run at full speed, then you need a FIFO. Since the clocks are the same frequency the FIFO can be tiny. I think Xilinx has an app note describing this case - or maybe a friend just showed me this trick. I think the min size is 4 words. You start things up running the FIFO half full. That lets you drift a word in either direction and still have a full cycle of setup/hold. -- 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: 56433
"Muthu" <muthu_nano@yahoo.co.in> wrote in message news:28c66cd3.0306041955.76ef7d8d@posting.google.com... > Hi, > > In all Xilinx block RAM Primitives, they have allocated Parity bits (1 > per byte) for each locations. If we see the 32bits with RAM, > additional 4 bits being provided for the Parity. > > In most of the cases, we are not using this. This is because, all our > RAM is internal, there is not possibility of data corruption. > > If this is the case, why they have provided that parity bits. I assume you mean Spartan 3 Block ram. You don't need to use that extra bit for parity you can use it for whatever you like. How about a processor with 9 bit instructions? 9 bit wide ram might just fit your design nicely. Or perhaps 8 bit ram that can be null (as well as 0 ). Perhaps your FFT works well with 9 bits. etc etc You get the idea. Parity is just one use of a bit. RalphArticle: 56434
Hi, I am a graduate student in Electrical and Computer Engineering. I still have 1 more year to graduate. I want to design hardware which has some practical application. I am looking for topics in Digital Design/VLSI on which i can do my final project. Can anyone suggest some related topics? ThanksArticle: 56435
The extra bits turn out to be really convenient in many cases. I've used them often for start-of-packet and end-of-packet flags. If these are intended to be used for parity, I've wondered why Xilinx didn't build in a hard-core parity generator/checker. For high-speed applications, you have to pipeline the parity-check logic, and then use a lot of flops to delay the RAM output. -Kevin "Muthu" <muthu_nano@yahoo.co.in> wrote in message news:28c66cd3.0306041955.76ef7d8d@posting.google.com... > Hi, > > In all Xilinx block RAM Primitives, they have allocated Parity bits (1 > per byte) for each locations. If we see the 32bits with RAM, > additional 4 bits being provided for the Parity. > > In most of the cases, we are not using this. This is because, all our > RAM is internal, there is not possibility of data corruption. > > If this is the case, why they have provided that parity bits. > > Regards, > MuthuArticle: 56436
I use defparams with Synplify. The new Verilog-2001 method of passing parameters by name with the # is nicer, though. -Kevin "Muthu" <muthu_nano@yahoo.co.in> wrote in message news:28c66cd3.0306041946.37cce689@posting.google.com... > Hi, > > Is "defparam" is synthesizable or not? I have tried with xilinx XST. > But it is giving some errors. > > So, currently i am passing parameters with #(). > > Any one used defparam in the design? > > Regards, > MuthuArticle: 56437
I've been studying Galois fields, and I wondered if this branch of mathematics has any other application besides forward correction encoders (and maybe encryption circuitry). Galois lived a long time ago; did he have any use in mind for his fields? Would they just be a curiosity if not for error correction? -KevinArticle: 56438
Followup to: <eiBDa.1133510$S_4.1168146@rwcrnsc53> By author: "Kevin Neilson" <kevin_neilson@removethistextattbi.com> In newsgroup: comp.arch.fpga > > I've been studying Galois fields, and I wondered if this branch of > mathematics has any other application besides forward correction encoders > (and maybe encryption circuitry). Galois lived a long time ago; did he have > any use in mind for his fields? Would they just be a curiosity if not for > error correction? > "Maybe" encryption theory? AES is based on Galois fields, you know... -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: 56439
Followup to: <Xns938FF21F0A61Crk@199.184.165.240>
By author: rk <stellare@NOSPAMPLEASE.erols.com>
In newsgroup: comp.arch.fpga
>
> But you know before it leaves the programmer and gets on the board. The
> reliability after passing programming is quite excellent. If you had to
> test on the board for the 2-3% dropout then that would be bad. As an
> aside, something I've looked into, fault coverage pre-programming for
> antifuse FPGAs can be quite excellent through on-chip test support.
>
Sure. It just means that you have to program (and test) the devices
before board assembly, which isn't possible in all production flows.
Definitely not an issue for everyone, but it is an issue for some
users, and should be kept in mind.
-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-64
Article: 56440"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag news:3EDE1BE7.84B46F73@xilinx.com... > Putting a non-volatile ID number on every chip is not so difficult, but > it must be redable after the device is packaged ( logistic nightmare otherwise). > That readback must be stoppable, otherwise no security. Why shouldn't there be security ? Because somebody can then probe the encryption algorithm with different data until he gets what ? It shouldn't be known what the decrypted bitstream looks like when residing in the FPGA memory cells. > Your suggestion still requires a decryption engine of at least DES > quality, costing silicon area and thus increasing the price for everybody. I doubt that this area cost is significant anymore. And it tends to get more insignificant with time. It's more the cost of designing it / designing the whole system. And it's also Customers really buying it. I suspect that many are talking about it, but much less are really "needing" it. Many here (including me) seem to be an example for this. > > Regarding key length and relative security: > The goal should be to cause a "cost of cracking" of $100 000 or more. Anyway, when this is well done it may get appreciated by cutomers "needing" more security from "bitstream thiefs" trying to avoid "overkill" by putting clumsy batteries on their boards. > unprotected copies). The availability of ever cheaper computer power > (extrapolated over the next several years) means that the encryption > algorithm has to be "pretty good" and the key has to be "pretty long", > and "pretty well hidden" ( no visibly readable fuses ). I agree that a longer key is better, but hidden ? Does my thinking have a fatal mistake here ? > > Just some thoughts, and why this is more complex than just adding a > serial number... And I am no FPGA designer/manufacturer caring about these details. I also have no ambitions to become one. Raymund HofmannArticle: 56441
Hi, I'm now doing ASIC verification using Xilinx V-II FPGAs, the design has too many gated clocks for FPGA's global resources. I know Certify does well on such application, and I want to know is there any other software capable to do the same job.Article: 56442
Hi all,
what do you think is the most efficient multipliers - Ram ratio to
implment good FIR/IIR filters?
I'd assume the multipliers are 18x18, and the ram blocks will be of around
512 locations.
Thanks very much
Article: 56443
Hi Mel,
Unfortunately 6U is no option and the Sundance carrier has a PCI-bridge
device connected to the cPCI-bus.
In our design we use a VHDL PCI core to interface with the cPCI-bus,
directly from the FPGA.
Cheers,
Pete
"Mel" <mels_news@hotmail.com> wrote in message
news:c71e414a.0306041257.1abe4332@posting.google.com...
> Hi,
>
> Sundance do a 3u carrier on which you can plug FPGA daughter cards of
> various sizes (www.sundance.com)
>
> Don't suppose you could go to a 6U rack, as there are a lot of good
> candidates in this format:
> Nallatech do a cPCI 6U carrier with a single XCV2000E and two
> daughtercard sites, each of which can take dual XC2V8000
> daughtercards. (www.nallatech.com)
>
> Mel
>
>
> "Peter Matthijs" <peter.matthijs@verhaert.com> wrote in message
news:<3edda4d4$0$13246$4d4efb8e@news.be.uu.net>...
> > Hi,
> > For the test/debugging of our VHDL designs we're looking for a
development
> > board that has a Xilinx Virtex FPGA directly connected to a compact PCI
> > (cPCI) bus. The board must fit in a 3U 3.3V rack system. The FPGA chip
> > should have at least 1M system gates but if its less then we'll settle
for
> > that.
> > Any research labs that might have this kind of board and are interested
to
> > sell one?
> > If this exists on the market i'm also interested but haven't found it
yet.
> > Thanks,
> > Pete
Article: 56444Hi all, I finally got a short answer back from a representative of SST regarding SPI serial data flashes with a read array command of all '0' or all '1'. I'am pretty shure it would help if other people would ask them as well to provide this cmd for FPGA booting ... below the answer ... have a nice day Markus Here is a partial answer to your question for you: You are right that the read mode command is 03H but it always has been on the 25 series devices. The 45 series which was SST's earlier part which is not a full standard SPI device had FF as the read command. SST is not producing this part in any other densities. However none of the data that our engineers currently have refers to 0x00 as a read command. SST does indeed acknowledge your point that this would be very valuable as a boot device for FPGA. Your comments have been taken seriously and the technical team will discuss internally about this. If there is an answer in the positive from the SST team, we'll be back in touch with you. Thank you for your interest in SST and of course the very astute comments! "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> schrieb im Newsbeitrag news:TBtBa.35461$3t6.555738@news.xtra.co.nz... > I don't know much about Semiconductor processes. But I wonder why it isn't > possible to make FPGA's with some flash memory in there, enough to hold 2x > the bit streams for the FPGA. A little Flash boot section (like CPLDS') of > FPGA could be used to configure the rest of the FPGA from the Embedded > flash. > > This means you can self configure with a protected bitstream, you can use > the flash in your application if you like, etc etc. It also gives you NV > ram in the FPGA which just can't be a bad thing. > > Seems like a simple idea - and a nice setup, is there a big technical > barrier to such a setup? Is it comming? Should I have pateneted it? Are > there already some out there? > > Ralph > > -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 56445
Could you clarify what options you are using for the punctured output. The core can produce a serial or dual output. If the core is working in serial mode you need to handle the control signals on the input carefully as there are 3 bits output for every 2 bits input. If the core is working in dual channel mode, then the data can be input continuously but will come out in blocks of 3 two bit outputs input, ie every 4 bits input to the encoder will produce 3 times 2 bit outputs and the rdy signal is only asserted every 3 out of 3 clock cycles. Beth venex wrote: > Thanks for your aid. > > The rate is 1/2 and with puncturing I obtain 2/3 (The code length is 8 > and puncture code is 11 and 10 (each four bit I keep only the first, > the second and the third). > The bits I have indicated in the message are only a short sample. > > Best regards. > > VenexArticle: 56446
rk, One thing that one manufacturer learned the hard way awhile ago was that if you brag about having your part on the spacecraft before the mission, and the mission does not go well (ie the hatches blow off too soon, it goes out of control, and the payload is lost), you might suddenly not want a lot of attention on whose part it was that was controlling the hatches..... The problem may have nothing to do with the part. It may have been an "act of God" or a design flaw (so who reviewed the VHDL?). The problem might have been present before launch, and no one understood what the test results meant. (Oh, those little lights mean that the hatches blow off now?) Who is to say? It isn't like you have anything left that you can do failure analysis on.....or you can get an RMA. So, when it lands (flys, images, etc) then the bragging might start. Before that, we are all a little gun shy after some spectacularly bad goofs.....that may, or may not have had anything to do with the underlying technology that we provide. A successful mission depends on a massive amount of stuff going right, and absolutely nothing going wrong. Very little of which actually falls under the manufacturers control at all. Austin rk wrote: > Mike Butts wrote: > > > The May 2003 issue of IEEE Spectrum has a nifty and > > detailed article on the exciting British Beagle 2 > > lander hitching a ride on ESA's Mars Express orbiter, > > set to launch soon and arrive in December. > > > > Its robotic arm carries a bunch of instruments and > > other devices. "Discrete electronic interfaces > > between each instrument and the lander would have > > been complex to build and heavy as well. So the > > PAW uses a single interface with a field-programmable > > gate array that can reconfigure itself to match each > > instrument's needs." > > > > Excellent! One of you must be able to tell us more. > > Who's the clever designer? Who's the lucky vendor? > > What device? Rad-hard? Fault-tolerant? Designed > > in what language? Verified how? Bitstreams stored > > where and loaded by what? Can they upload new > > bitstreams from Earth? (Now that's an UPload!) > > What if DONE doesn't go high? > > > > Will this be the first FPGA in Mars space? > > I don't recall if there were any on Mars Pathfinder but there was > definitely an FPGA on Mars Global Survey on the laser altimeter. The > FPGA got put onto the instrument as it was upgraded; the original laser > altimeter was on the ill-fated Mars Explorer. > > There are also FPGAs on the way to Saturn on the Cassini spacecraft. > > > > Most important of all, will they send a paper to > > FPL 2003 or FPGA 2004 or FCCM 2004? > > MAPLD 2003? ;-) > > -- > rk, Citizen, Noooo Yawk > "Sometimes when you connect the dots you get a picture. Other times you > just have a bunch of dots." > -- rk, January 23, 2003Article: 56448
Hi All... I really donīt have any decent knowledge in silicon design, but iīm just wondering... Even in a standard CMOS process, would it be possible to sneak in some antifuse(or similar) bits that are write-only? Maybe something like a public/private key could do the job. The public key could be read from the device, in order to encrypt the bitsteam, but the decryption procces would need the private key, wich is not readable. By the way, I really like the idea of having some level of protection in the lower costs design, but I think they donīt need to be as good as the top of line products... My specific needs are that it canīt be copied by a tecnician in a repair shop. bye... Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3EDE21BD.D1E0129B@xilinx.com>... > Raymund, > > Laser popping of fuses is a well known, and well used technology in low cost > manufacturing, but as a means of keying the device, pretty lousy security. > Imagine just popping the lid and examining the blown holes in the polyamide? > > Basically, remember that we really really really want to do what you are > suggesting, and it isn't for lack of trying, or experimentation, that it isn't > there. > > We have two issues: no good practical low cost secure way to put keys into a > standard CMOS process, and very few customers willing to pay a premium. > > Right now we have the feature in V2 and V2P with the battery backed up RAM. > Cost? One lithium coin cell, (coind cell holder), a diode, and a capacitor (to > prevent memory loss when you replace the battery). Maybe throw in a 1Mohm > resistor in series to help prevent memory loss if someone shorts out the battery > while replacing it. > > Not the best solution (I would love to have NVRAM in standard CMOS, too), but > one that allows folks who absolutely have to have triple DES level encryption to > succeed. > > Austin > > raymund hofmann wrote: > > > "Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag > > news:3EDB8423.29CA2C46@xilinx.com... > > > > > > > > > emanuel stiebler wrote: > > > > > > > But, anybody out here has an idea, why there is no bitstream encryption > > > > on the spartan 3 ? With all this gates & memory, you could do impressive > > > > designs, but to keep them for safe you still have to go to the virtex > > > > chips ... > > > > > > It's really quite simple: > > > The priorities for Spartan are: Low cost first, features and speed second. > > > For Virtex the priorities are reversed. > > > Makes a lot of sense, avoids unproductive overlap, and gives the user a > > > fair choice. Cheap or fancy. There is no free lunch... > > > > > > Now, if encryption were a popular feature in the low-cost market (please > > > tell us), then it would make sense to dedicate some silicon and a pin > > > for the on-chip decryption. > > > > Why don't put a kind of "Host ID/Serialnumber" on the FPGA in some kind of > > "one time programmable" way at Manufacturing the FPGA ? > > I think Intel CPU's already each have different ID's since some time. > > > > I doubt this is a cost/performance penalty like manufacturing a FPGA on a > > flash-process. > > > > This ID can then be used to decrypt a bitstream. > > And the device should accept two kinds of bitstreams: > > Encrypted with it's ID + Unencrypted. > > And this ID should be electronically readeable off the FPGA. > > > > I think it is only a matter of time when one FPGA company starts such a > > thing even for the "low cost" Parts. > > > > Of course will the FPGA Customer have to care about generating individual > > Bitstreams for each device ID of the Part's used, if he wants "security". > > As there often is a MCU with the FPGA(s) on Board there is additional > > flexibility in handling the "design security". > > Or he may choose not to encrypt. > > > > Raymund HofmannArticle: 56449
Maybe something like a image processing hardware, encryption engine, error control and correction systems, High speed arithmetic systems, High speed memory design, etc. Also look at emerging standards. Good luck. Kumaran Priyal wrote: > Hi, > I am a graduate student in Electrical and Computer Engineering. > I still have 1 more year to graduate. > I want to design hardware which has some practical application. > I am looking for topics in Digital Design/VLSI on which i can do my final project. > Can anyone suggest some related topics? > > Thanks
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