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
(someone wrote) >>>x = R*cos(fi) >>>y = R*sin(fi) (someone wrote) > 'fi' is uknown to me, I can compute it with 'gx' & 'gy', since they are > vector coordinates. So it would be: atan2(gy,gx). x=R*gx/sqrt(gx**2+gy**2) y=R*gy/sqrt(gx**2+gy**2) two multiplies, a sqrt and two divides should be a lot easier than atan2, cos, sin. -- glenArticle: 128151
Actualy looking to do usb+microcontroller+cpld or usb+ microcontroller ip in fpga LOOKING FOR PARTNERSHIP IN DEVELOPMENT OF THIS UNIT WWW.ONECARDCONNECT.COM CEO@ONECARDCONNECT.COM a couple of good sites Get your feet wet in the smart card arena http://www.redbooks.ibm.com/abstracts/sg245239.html CLICK ON THE LOWER LINK FOR THE .PDF FOR SOC(SYSTEM ON CHIP) FOR A SECURE MICROCONTROLLER IN THE LINK BELOW: http://scholar.google.com/scholar?hl=en&lr=&cluster=2494623305716384420 BELOW IS A SECURITY EVALUATION OF A PHILIPPS SECURE MICROCONTROLLER www.commoncriteriaportal.org/public/files/epfiles/0312b.pdf Here are some ip cores (the heart of the secure microcontroller is the cryptography) http://www.cryptovision.com/en/products/cryptographic-libraries/cv-actlibrary-vhdl.html http://www.ipcores.com/DES1core.htm http://www.cryptography.com/technology/dpa/licensing.html Link below of .pdf of major attacks that can be done on chips and what to do to improve them, the interest being that the smartcard microcontroller being secure is of essence. http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdfArticle: 128152
On Wed, 16 Jan 2008 10:22:39 -0800, austin <austin@xilinx.com> wrote: >G. > >How one starts the configuration process is a different problem that how >the device after configuration, starts up. > >The first problem is often caused by people "not trusting" the internal >Power On Reset circuits in the FPGA: bad. We spend an immense amount >of time making sure the POR circuits work under all sequences, and all >ramps from 2us to 50ms. Mess with this, and then you have to do all the >engineering for three power supplies to make it work at least as well as >we already did. Not a smart move. Why would anyone want to re-invent >this wheel? There are a few reasons why you would want to re-invent that wheel in a practical product: 1. "all ramps from 2us to 50ms" It may be impossible to guarantee the 50ms end of that, particularly in mains powered circuits. If there is a slow brownout, an external reset generator with accurate thresholds *will* result in a more reliable design. 2. I find that my designs rarely contain just an FPGA. I have a whole host (sorry about the pun) of items on the board that need to be reset at the same time. 2b. Sometimes (particularly when I have a host processor on the board that configures the FPGA) I want to have different parts of the board reset based on different criteria. 3. I also have extra voltage rails that need to be monitored, and these rails aren't connected to the FPGA. An external reset generator is required to monitor those rails. If FPGAs had an on-die reset generator that - was guaranteed to work for all ramp rates - was guaranteed to work for non-monotonic ramps - could monitor 3-4 additional voltages - had a guaranteed 2% voltage tolerance or better - had threshold voltages I can set (or determine by resistor ratios) - had a dedicated reset output to drive other parts of the board, I would use it. Until then, I will use cheap, reliable, external reset generator devices. Regards, Allan >After the product has loaded the configuration, and has completed the >start-up sequence, then everything is in a known state, so a reset isn't >even required (it is implicit in the starting values you placed in the >registers in your VHDL or verilog code, and was part of the loaded >bitstream). > >If at some time later, you want to return to a 'known good state', which >we will call "reset" for no better reason than it describes the action >you want to take, then the applications note (or the old Tech X) details >all kinds of ways to do this, that work. > >AustinArticle: 128153
On Jan 16, 8:44=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > On Jan 16, 8:19=A0am, Anuja <thakkar.an...@gmail.com> wrote: > > > The Quartus II handbook says that its Incremental compilation feature > > has the ability to iterate rapidly during the design and debugging > > stages. What exactly does this mean? > > It means that your build times using Quartus will be quicker because > it won't redo things that haven't changed. =A0So instead of a 20 minute > build, maybe it takes only 2. > > > Is this feature similar to Partial Reconfiguration offered by Xilinx? > > They are entirely different things. > > KJ Thanks buddy. You are of great help.Article: 128154
On Jan 15, 7:32=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > Slight correction to previous post. =A0Instead of > > =A0 =A0 =A0RetVal.Real :=3D (a.real * b.real - a.imag * b.imag)(a'range); > =A0 =A0 =A0RetVal.Imag :=3D (a.real * b.imag + b.real * a.imag)(a'range); > > It should be > > =A0 =A0 =A0RetVal.Real :=3D (a.real * b.real - a.imag * b.imag) > (a.real'range); > =A0 =A0 =A0RetVal.Imag :=3D (a.real * b.imag + b.real * a.imag) > (a.imag'range); > > KJ Thanks a bunch. I will try this out.Article: 128155
On Thu, 17 Jan 2008 13:26:53 +1100, Allan Herriman <allanherriman@hotmail.com> wrote: >On Wed, 16 Jan 2008 10:22:39 -0800, austin <austin@xilinx.com> wrote: > >>G. >> >>How one starts the configuration process is a different problem that how >>the device after configuration, starts up. >> >>The first problem is often caused by people "not trusting" the internal >>Power On Reset circuits in the FPGA: bad. We spend an immense amount >>of time making sure the POR circuits work under all sequences, and all >>ramps from 2us to 50ms. Mess with this, and then you have to do all the >>engineering for three power supplies to make it work at least as well as >>we already did. Not a smart move. Why would anyone want to re-invent >>this wheel? > >There are a few reasons why you would want to re-invent that wheel in >a practical product: > >1. "all ramps from 2us to 50ms" >It may be impossible to guarantee the 50ms end of that, particularly >in mains powered circuits. If there is a slow brownout, an external >reset generator with accurate thresholds *will* result in a more >reliable design. > >2. I find that my designs rarely contain just an FPGA. I have a >whole host (sorry about the pun) of items on the board that need to be >reset at the same time. > >2b. Sometimes (particularly when I have a host processor on the board >that configures the FPGA) I want to have different parts of the board >reset based on different criteria. > >3. I also have extra voltage rails that need to be monitored, and >these rails aren't connected to the FPGA. An external reset generator >is required to monitor those rails. > > >If FPGAs had an on-die reset generator that >- was guaranteed to work for all ramp rates >- was guaranteed to work for non-monotonic ramps >- could monitor 3-4 additional voltages >- had a guaranteed 2% voltage tolerance or better >- had threshold voltages I can set (or determine by resistor ratios) >- had a dedicated reset output to drive other parts of the board, > >I would use it. Until then, I will use cheap, reliable, external >reset generator devices. > > >Regards, >Allan P.S. I apologise if that sounded overly critical. Still, I think my points are valid for the sorts of boards I design. Regards, AllanArticle: 128156
Does anyone have a copy of Forte Design (CynApps) opensource Cynlib? I appreciate if you can send me a copy. -- AmalArticle: 128157
On Jan 16, 8:44 am, KJ <kkjenni...@sbcglobal.net> wrote: >On Jan 16, 8:19 am, Anuja <thakkar.an...@gmail.com> wrote: >>The Quartus II handbook says that its Incremental compilation feature >>has the ability to iterate rapidly during the design and debugging >>stages. What exactly does this mean? >It means that your build times using Quartus will be quicker because >it won't redo things that haven't changed. So instead of a 20 minute >build, maybe it takes only 2. >>Is this feature similar to Partial Reconfiguration offered by Xilinx? >They are entirely different things. Maybe not. Partial reconfiguration might involve rerunning Quartus to compile a new design. Incremental compilation would speed up the process, and also guarantee that the part that wasn't supposed to change actually didn't change. (Or at least make it more likely.) -- glenArticle: 128158
Dear All, As an assignment I have to design a CCD Sensor based FPGA digital Camera. However, the Camera will be exposed to XRAY (It will be placed behind an Imaging Intensifier). Does anybody know how XRAY affects the electronic circuits (The CCD Sensor and the FPGA ). What type of noise should I expect and what should I do to prevent it. Thanks in advanceArticle: 128159
>1. "all ramps from 2us to 50ms" >It may be impossible to guarantee the 50ms end of that, particularly >in mains powered circuits. If there is a slow brownout, an external >reset generator with accurate thresholds *will* result in a more >reliable design. That's the reason that jumped out at me. There is an easy way to get ugly brownouts. Just turn a system back on shortly after you turn it off. (Been there, done that.) Brownouts are ugly. Basically, you need the power-watcher system to generate a reset before the power goes out of spec. The power-up reset generator just doesn't cover that. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 128160
Paul A long shot - try talking to your local Avnet/Silica as Avnet took over Insight Memec a couple of years ago. Memec in it's various forms did a lot of development boards. John Adair Enterpoint Ltd. - Home of Drigmorn1. The Low Cost FPGA Development Board. On 16 Jan, 21:04, Paul Price <p...@logicvision.com> wrote: > We are using a number of these boards but do not have the > documentation for them and need to make some changes. =A0Any information > on where we could get the userguide would be welcomed. =A0We've tried > contacting a number of different vendors, etc. with no luck > > The markings on the board > > Insight > VIRTEX-E REFERENCE BOARD > PART # =A0 =A0:_________ REV-B > SERIAL # : __________ > > Both the part # and Serial # are blank > > It uses a Virtex XCV600E FPGAArticle: 128161
On 17 Jan, 08:03, recoder <kurtulmeh...@gmail.com> wrote: > Dear All, > =A0As an assignment I have to design a CCD Sensor based FPGA digital > Camera. However, the Camera will be exposed to XRAY (It will be placed > behind an Imaging Intensifier). Does anybody know how XRAY affects the > electronic circuits (The CCD Sensor and the FPGA ). What type of noise > should I expect and what should I do to prevent it. > =A0Thanks in advance Can bits be flipped? Do you need a RadHard FPGA? Cheers, JonArticle: 128162
>Dear All, > As an assignment I have to design a CCD Sensor based FPGA digital >Camera. However, the Camera will be exposed to XRAY (It will be placed >behind an Imaging Intensifier). Does anybody know how XRAY affects the >electronic circuits (The CCD Sensor and the FPGA ). What type of noise >should I expect and what should I do to prevent it. > Thanks in advance > How about: http://www.google.com/search?hl=en&q=%22effects+of+x-rays%22+%22electronic+circuits%22 Advice - buy "Space Class" devices. This will probably be from Actel.Article: 128163
On Jan 17, 2:03=A0am, recoder <kurtulmeh...@gmail.com> wrote: > Dear All, > =A0As an assignment I have to design a CCD Sensor based FPGA digital > Camera. However, the Camera will be exposed to XRAY (It will be placed > behind an Imaging Intensifier). Does anybody know how XRAY affects the > electronic circuits (The CCD Sensor and the FPGA ). What type of noise > should I expect and what should I do to prevent it. > =A0Thanks in advance A little bit of lead foil goes a long way. Depends on how much XRAY I imagine. Be careful.Article: 128164
recoder wrote: > Dear All, > As an assignment I have to design a CCD Sensor based FPGA digital > Camera. However, the Camera will be exposed to XRAY (It will be placed > behind an Imaging Intensifier). Does anybody know how XRAY affects the > electronic circuits (The CCD Sensor and the FPGA ). What type of noise > should I expect and what should I do to prevent it. > Thanks in advance Ever consider using a phosphor plate to turn the x-rays into visible light first?Article: 128165
"John_H" <newsgroup@johnhandwork.com> wrote in message news:tJmdnUfZyuv8_BLanZ2dnUVZ_tjinZ2d@comcast.com... > recoder wrote: >> Dear All, >> As an assignment I have to design a CCD Sensor based FPGA digital >> Camera. However, the Camera will be exposed to XRAY (It will be placed >> behind an Imaging Intensifier). Does anybody know how XRAY affects the >> electronic circuits (The CCD Sensor and the FPGA ). What type of noise >> should I expect and what should I do to prevent it. >> Thanks in advance > > Ever consider using a phosphor plate to turn the x-rays into visible light > first? Hi John, I guess that's what the OP means. http://en.wikipedia.org/wiki/X-ray_image_intensifier Maybe! I would've thought that would stop the X-rays. I guess Austin will give his SEU spiel soon. That'll teach the OP! ;-) Cheers, Syms.Article: 128166
Allan, OK, I do not disagree. I just wished to point out that we have already done an immense amount of work, and the only reasons why you would need an external reset are those you bring up. AustinArticle: 128167
Hall, Good point: we do cover some brown-out, but that can only be done only so well (there is no way to be precise enough to cover all possible brown-out scenarios). There are power supply regulator chips that provide a "power good" signal, and if brown-out is possible (as in: you can not specify your primary power supply quality) then you will need a "power good" signal from your power supply. See "power central" for vendors that Xilinx approves, and works with. Many of these have products with "power good" features. http://www.xilinx.com/products/design_resources/power_central/ AustinArticle: 128168
X-ray, Has no effect on the device, except that (eventually) the total dose will accumulate, and the Vt of the devices will begin to shift, and eventually, the device will fail. This is unlike a CCD, which may register 'hits' and display noise. Only neutrons, or protons, with LET of 1 Mev have enough energy to create charge clouds, and change bits: http://www.xilinx.com/products/silicon_solutions/market_specific_devices/aero_def/capabilities/aero_def_app.htm Contact your local Xilinx FAE to find out about X-Ray dose (how long it can "take it."). At some dose level, that usage becomes ITAR restricted (people use stuff this hard to build nuclear bombs, or operate in the presence of nuclear explosions) so you will no longer be able to buy, or use, such parts, unless the US State Department permits you to do so. I suspect for your application, our commercial parts are more that "hard" enough. X-rays, after all, are just photons, and they just do not pack enough energy to affect even the MGTs in our parts, and certainly do not affect the logic and memory. AustinArticle: 128169
Spiel? X-rays are just wimpy little photons .... SEUs are caused by cosmic rays (heavy ions, like iron, gold, etc with LET's of > 100 MeV) that create neutron showers with energies beyond 1000 MeV. AustinArticle: 128170
On Jan 17, 5:59 am, Amal <akhailt...@gmail.com> wrote: > Does anyone have a copy of Forte Design (CynApps) opensource Cynlib? > > I appreciate if you can send me a copy. > -- Amal Hi i have this one: cynlib.1.2.1.source.tar.gz (3,876,003bytes) I'll check the licensing issues (if i can pass it to you or not). But, first of all, is this version OK for you? And what about the company, it might be best if you asked them about the legality of this. Kind regards Nikolaos KavvadiasArticle: 128171
On Jan 17, 2:03 am, John Adair <g...@enterpoint.co.uk> wrote: > Paul > > A long shot - try talking to your local Avnet/Silica as Avnet took > over Insight Memec a couple of years ago. Memec in it's various forms > did a lot of development boards. > > John Adair > Enterpoint Ltd. - Home of Drigmorn1. The Low Cost FPGA Development > Board. > > On 16 Jan, 21:04, Paul Price <p...@logicvision.com> wrote: > > > > > We are using a number of these boards but do not have the > > documentation for them and need to make some changes. Any information > > on where we could get the userguide would be welcomed. We've tried > > contacting a number of different vendors, etc. with no luck > > > The markings on the board > > > Insight > > VIRTEX-E REFERENCE BOARD > > PART # :_________ REV-B > > SERIAL # : __________ > > > Both the part # and Serial # are blank > > > It uses a Virtex XCV600E FPGA- Hide quoted text - > > - Show quoted text - Speaking to your Avnet/Silica FAE is a good idea. Another option is to visit the Avnet Design Resource Center, which archives documentation and reference designs for all of the Avnet and Memec boards, even the obsolete ones, like this one. Go to www.em.avnet.com/drc then select SUPPORT FILES AND DOWNLOADS button. Select Xilinx as the manufacturer. Scroll to find the Xilinx(R) Virtex(tm)-E Development Kit and click the page symbol on the right. https://www.em.avnet.com/common/filetree/0,2740,RID%253D0%2526CID%253D4908%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526LID%253D32232%2526PVW%253D%2526PNT%253D%2526BID%253DDF2%2526CTP%253DSTA,00.html BryanArticle: 128172
On Jan 17, 12:03 am, recoder <kurtulmeh...@gmail.com> wrote: > Dear All, > As an assignment I have to design a CCD Sensor based FPGA digital > Camera. However, the Camera will be exposed to XRAY (It will be placed > behind an Imaging Intensifier). Does anybody know how XRAY affects the > electronic circuits (The CCD Sensor and the FPGA ). What type of noise > should I expect and what should I do to prevent it. > Thanks in advance Is it internal flash or external flash? If anything, flash would be the weakest link.Article: 128173
Hi I have an VHDL core that is sythesizeable with the following tools Synopsys Design Compiler Cadence Encounter RTL Compiler Until now I was using XST for sythesis and it seems when I try to run sythesis for the VHDL core with XST I get a bunch of errors. The convenient thing with Xilinx was the Chipscope which allows the on-chip debugging. So I wonder if the tools mentioned at the beginning also support this kind of on-ship debugging? Or could I sythesise the design with the ICON and ILA with the Synopsis or Cadence RTL compiler and then use CHIPscope. Does anyone have tried that? Many thanks PhilippArticle: 128174
On 17 Jan, 18:39, Philipp <Philip...@hotmail.com> wrote: > Hi > > I have an VHDL core that is sythesizeable with the following tools > > =A0 =A0Synopsys Design Compiler > =A0 =A0Cadence Encounter RTL Compiler > > Until now I was using XST for sythesis and it seems when I try to run > sythesis for the VHDL core with XST I get a bunch of errors. The > convenient thing with Xilinx was the Chipscope which allows the on-chip > debugging. So I wonder if the tools mentioned at the beginning also > support this kind of on-ship debugging? Or could I sythesise the design > with the ICON and ILA with the Synopsis or Cadence RTL compiler and then > use CHIPscope. Does anyone have tried that? Do you have Xilinx .libs for DC or RC? Cheers, Jon
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