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
kolja@prowokulta.org writes: >In article <39B6B196.A9326D1B@xilinx.com>, > Phil James-Roxby <phil.james-roxby@xilinx.com> wrote: >> > Officiall the bitsream is not disclosed to prevent the distruction >> > of the device by short circuit connections, which is allegedly >> > checked by JBits. (snip) >> Actually, JBits doesn't check short circuit connections, though you >> could write a DRC checker using the JBits API if you were concerned >> about it. Since JBits gives you full access to all the configurable >> resources within a device, if you want to blow up a Virtex, go ahead. >So, then I can not the why you should keep the bitstream secret? >I would like to do self reconfiguration from the FPGA so I do >not have Java around in that environment. >JBits will help a lot with reverse engineering but a disclosed >bitstream format would be easier. Personally, I believe that they should, too. I was once working on a project like that, but not now. It is my understanding that in this case, and with the right NDA, you can get the information. The project I was working on mostly needed the location of the LUT data, and they will almost tell you that when they explain readback. (Pretty much I would have needed to load different data into ROMs in different places. I might have needed to change the carry logic, but no routing changes. But then I didn't get to do that project.) -- glenArticle: 25351
A couple of points on this thread: 1. Xilinx is currently working on a new pwr/gnd routing algorithm and we have scheduled it to be released in service pack 4. The new algorithm improves the runtime for pwr/gnd routing significantly. 2. With respect to putting in constraints that are "impossible" to meet to just see how fast your design will go I'd like to explain a new feature in 3.1i called auto-timespec which should considerably enhance this flow for Virtex and related families (Virtex-E). Here is a snippet from the online documentation about auto timespecs "When automatic timespecing is invoked, PAR analyzes the design for clock nets and attempts to increase the frequency of clocks. If you were to increase the clock frequency using a timing-driven flow, you would perform multiple runs of PAR with progressively higher frequencies. Each run would require you to increase the frequency specifications on clocks in your design. PAR would attempt to meet these specifications, not improve on them. You might continue to increase the frequency specifications until PAR can no longer meet them. At this point, your design would achieve optimal clock frequency. In contrast, automatic timespecing allows you to achieve good clock frequency results in the shortest possible time." If you are trying to determine what are the limits of performance for your design, one possible methodology would be to run PAR in auto-timespec mode. Run trace (the static timing analysis tool) to get the clock frequencies of the resulting design. Use that frequency as a baseline for the clocks and try to put in constraints approximately 10-15% higher to see how far PAR can really go. Please look in the documentation for all the details on how to invoke this flow. Hope that helps. Rajeev > 3.1 does seem to fix that problem. One bugger with 3.1 is if the placement > isn't going to meet timing, it spends an awful long time trying a little harder > before it gives up. That's a bit of a bugger if you are trying to push > something to see how fast it'll go as opposed to meet timing for a particular > target. If your placement makes meeting timing relatively easy, the tool runs > very quickly...I've got a very full 97%)XCV400 that's placing and routing in > under 5 minutes, with all the datapahth stuff but not control logic > floorplanned. > > Johan Petersson wrote: > > > > Hi Richard, > > > > All I can say is that the problem does not remain in > > 3.1i, which improves par times enormously! > > > > Johan, > > email vhdl_ninja@yahoo.com > > > > news@rtrussell.co.uk wrote: > > > > > > The problem of very slow routing of PWR/GND nets is > > > supposed to be fixed in 2.1i Service Pack 6, but I > > > am still suffering from it (running the Unix tools > > > on a Sun Ultra 10 workstation). An XCV600 is taking > > > about 8 hours to build, of which over 7 hours is the > > > PWR/GND routing (all signals are successfully routed > > > in under 40 minutes). Does the problem remain in SP6, > > > or is this a specific issue related to the use of the > > > Unix version ? > > > > > > Richard. > > > http://www.rtrussell.co.uk/ > > -- > -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 or http://www.fpga-guru.com Rajeev Jayaraman, Ph.D Manager, Place/Route/Timing Tools FPGA Implementation Tools Group Xilinx Inc.Article: 25352
Dear Anthony; At least some years ago this information was a closely kept secret. Xilinx only discovered it to selected customers who signed a NDA. The official reason was not to protect devices against mis-configuration, was to protect the intellectual property of the design. However, it is not difficult to play with the Xilinx tools and reverse engineer some of the bitstream of the XC3000A devices, and the partial dynamical reconfiguration capability can be very useful in embedded systems. With some extra programming effort, it can be even done "at the fly", keeping the bitstream only in ROM/FLASH memory segments and not spending extra RAM for buffers. Here are some hints, based on my past experience on the matter. I did it many years ago, so I apologize for any mistake caused by my bad memory. BACKGROUND: The bitstream overhead format (bit count, headers, etc) is well document in Xilinx documents. The payload is the undocumented part. The payload is transferred to the static RAM on the FPGA in the configuration process. The bits in the static RAM control the state of different FPGA resources (routing switches and CLB configuration). To dynamically change the state of routing switches is a difficult problem. It means to move the place/routing process to run time instead of FPGA compile time, so I never tried it. However, it is easy to dynamically change the CLB configuration, especially the lookup table (LUT). Each CLB has an associated 32-bit LUT. Each bit corresponds to one of the 32 product terms of the single 5-bit input function, or to the two 16 product terms of the two 4-bit input functions. I believe (not sure) the logic used was positive, so the null function (output always zero) had all the 32 bits to zero, the unity function (output always one) had the 32 bits at one, and the single product term functions had a single bit at one. The 32 bits of a given LUT are *not* located in consecutive positions of the bitstream, but their offsets from LUT base address are the *same* for all the CLBs, so once discovered the values for one CLB, you have the values for all of them. THE PROCESS AT FPGA DESIGN TIME: Assume you want to reconfigure a 5-bit combinatorial function and that you use schematics and not VHDL. Put any dummy or default logic gates into the schematic in substitution of the real functions (are going to change in run time anyway). Add to your schematic a CLBMAP symbol for the function. For reasons explained latter, it is advisable to use a well known and normalized name for the CLBMAP (something like prefixing it with two underscores). THE PROCESS AT RUN TIME: When you configure the FPGA and find the "reconfigurable" bits in the bitstream, substitute them by the ones computed at run time. To locate the position in the bitstream of a given (CLB, product term) pair you only have to know a) The base address of the CLB LUT in the bitstream and b) The offset of the product term from the LUT base address. So you only need a couple of small tables: - One for the CLB LUT base address (one position for each CLB) - One for the product term offsets (32 positions) THE PROCESS AT REVERSE ENGINEERING TIME: To fill the values of the tables you can manually edit the FPGA, put well chosen patterns into the LUTs, generate some bitstreams and check the differences with some file-compare utility. For the test, you can configure all the CLBs LUTs with null functions (are always false, and the LUT bits are zero) and use that bitstream as a baseline. Then, to fill the offsets table, take a LUT and configure it. Iterate with the 32 possible 5 bit functions that have a single product term. The resulting bitstreams will have changed a single bit when compared with the baseline. To fill the base address table, take an input function. Iterate all the LUTs into a FPGA and configure them with the function. The function with the minimum offset (0) would be nice. THE PROCESS AT FPGA COMPILE TIME: The problem here is that every time the place/route process runs, it can put your CLBMAP logic at different coordinates and can also swap the input signals. The first solution could be to lock the CLB coordinates and the signal ordering in the FPGA schematic, and then your software will see those values as constants. But this can be undesirable restriction, as does not allow the placer/router to optimize the results. A better (and more elaborate) approach is the following: 1- To scan (at FPGA compile time) several intermediate text files (the netlist and the LCA routed ones). 2- Look for the "magical" two underscores to find the names of reconfigurable CLBs. 3- Look for its input signal names and store them. 4- Look for the signals names and compute the permutations caused by the router. 5- Create a C/ASM file with the coordinates of the involved CLBs and the signals ordering. This file can be considered as an "addendum" of the bitstream, and can also contain it. 6- Compile and link the file as you would do with the normal bitstream. For steps 1 to 5 we wrote some specific utilities. The process can be fully automated with a make file, and then does not have to impose any extra burden to the people involved in the FPGA and software build process. POSSIBLE ENHANCEMENTS: - To configure other CLB bits than the LUT ones, as the clock polarity. - I remember that the table for base address is not really needed, because there is a regularity that can be exploited. The base address can be calculated from the coordinates of the CLB in the FPGA. It was something like multiply one of the coordinates by a constant, and adding to the result a constant dependent on the other coordinate. Hope this info helps you. To get more details I would have to dig deep into very old notes. Juan-Luis Lopez Spain Note: My email domain address has an anti-spam word (REMOVETHIS).Article: 25353
That seems a little convoluted but it's probably just that my coffee ran out this morning. Being an ex-schematic weenie, I've been using an approach that mirrors how I did RLOCs in schematics. It lets you hierarchically assign placement just like we did with the schematics. For example the code below is a snippet for a placed two's complementer. itoa is a homegrown an integer to ascii string conversion that does essentially the same thing as 'image because synplicity doesn't know what 'image is. In this case, the instantiation of this component also needs an RLOC on it with the slice declared because the slices can only be declared once in the hierarchy. (Who else finds this slice thing a real PITA!) I know this works in synplicity, and since it doesn't use anything specific to synplicity (other than for the inside the fmap_xor2 component that is), it should mostly work under other tools as long as user attributes are supported. begin ax<=resize(signed(a),width); --construct from primitives so placement can be included c(0) <=neg; L:for i in 0 to width-1 generate constant rloc_str : string := "R" & itoa((width-1)/2-(i/2)) & "C0"; signal l,s: STD_LOGIC;--_VECTOR(width-1 downto 0); attribute RLOC of U1 : label is rloc_str; attribute RLOC of U2 : label is rloc_str; attribute RLOC of U3 : label is rloc_str; attribute RLOC of U4 : label is rloc_str; begin U1: fmap_xor2 port map( --invert input when neg = '1' a=> ax(i), b=> neg, z=> l); U2: MUXCY port map ( --and add 1 O => c(i+1), CI => c(i), DI => '0', S => l ); U3: XORCY port map ( O => s, CI => c(i), LI => l ); U4: FDCE port map ( Q => q(i), D => s, CLR=>Global_reset, CE => ce, C => clk ); end generate L; end Virtex_struct; husby@my-deja.com wrote: > > For VHDL, I find it's useful to do all of the floorplanning via > a single function of the form: (Please excuse VHDL errors, I'm > writing this without a VHDL reference) -- -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 or http://www.fpga-guru.comArticle: 25354
RLOCs are OK, but I find a global view of the floorplanning to be a little more flexible. For example, if you have a wide data path that flows through many columns of logic, adders, memories, etc, you can quickly move the entire path just by changing a few parameters. You could, for example, run the carry chains up instead of down (or if you use Lucent chips, you could rotate whole blocks and run the carries left-to-right and run the tristate busses up and down). Or you can play games like: What if I insert an empty row between bits 15 and 16 of the data path? It might slow the carry chains down, but the placer could put some of my tight control logic in there and it might make better use of some of the half-length metal lines if I can get bit 16 across that boundary. I also adopted my VHDL method from my schematic methodology where I implemented the same function with an "algorithmic floorplanning language" for schematics. Like you, I still lobby for better schematic support, but have to accept that VHDL is the current bandwagon. (Actually, this new company I'm working at wants to use SystemC! Even more convoluted text to describe simple concepts, but at least it knows what a clock is.) Ray Andraka <ray@andraka.com> wrote: > That seems a little convoluted but it's probably just that my coffee ran out > this morning. Being an ex-schematic weenie, I've been using an approach that > mirrors how I did RLOCs in schematics. It lets you hierarchically assign > placement just like we did with the schematics. For example the code below is a > snippet for a placed two's complementer. itoa is a homegrown an integer to > ascii string conversion that does essentially the same thing as 'image because > synplicity doesn't know what 'image is. In this case, the instantiation of this > component also needs an RLOC on it with the slice declared because the slices > can only be declared once in the hierarchy. (Who else finds this slice thing a > real PITA!) > I know this works in synplicity, and since it doesn't use anything specific to > synplicity (other than for the inside the fmap_xor2 component that is), it > should mostly work under other tools as long as user attributes are supported. > > begin > ax<=resize(signed(a),width); > > --construct from primitives so placement can be included > c(0) <=neg; > L:for i in 0 to width-1 generate > constant rloc_str : string := "R" & itoa((width-1)/2-(i/2)) & "C0"; > signal l,s: STD_LOGIC;--_VECTOR(width-1 downto 0); > attribute RLOC of U1 : label is rloc_str; > attribute RLOC of U2 : label is rloc_str; > attribute RLOC of U3 : label is rloc_str; > attribute RLOC of U4 : label is rloc_str; > begin > U1: fmap_xor2 port map( --invert input when neg = '1' > a=> ax(i), > b=> neg, > z=> l); > > U2: MUXCY port map ( --and add 1 > O => c(i+1), > CI => c(i), > DI => '0', > S => l ); > > U3: XORCY port map ( > O => s, > CI => c(i), > LI => l ); > > U4: FDCE port map ( > Q => q(i), > D => s, > CLR=>Global_reset, > CE => ce, > C => clk ); > end generate L; > > end Virtex_struct; > > husby@my-deja.com wrote: > > > > For VHDL, I find it's useful to do all of the floorplanning via > > a single function of the form: (Please excuse VHDL errors, I'm > > writing this without a VHDL reference) > > -- > -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 or http://www.fpga-guru.com > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25355
hi all, I tried to have such connection (through the edif file) IPAD-IBUF-BLOCK I am getting this error, " try to redefine the connection of a certin port " whenever i don't insert the IPAD, the edif file is accepted, even that block port is external ? any clue? -- Karen W ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Man stays wise as long as he searches for wisdom, As soon as he thinks he has found it, he becomes a fool. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sent via Deja.com http://www.deja.com/ Before you buy. Sender: eric@ruckus.brouhaha.comArticle: 25356
--------------7CE468A475D17E5248325F53 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Alain, "High" is a relative term. Please read the following to see the differentiation between large high performance FPGAs, and small lower performance FPGAs. 'Luck" is also a relative term, and I can assure you, that luck has nothing to do with it. Two years ago we recognized that the larger devices were requiring significant (greater than 1 ampere) of start up current, and we addressed the issue, along with all older family members, and devised the Power On Ramp Up Current Capacity specification for the power supplies, and modified new designs as appropriate and put in place tests for older family parts. If you are buying the Commercial part (C), it is not specified below 0 C. If you are buying the Industrial part (I), the specifications apply down to -40 C. For many years (at my previous employer), I bought and used commercial parts in telecom applications for -40 C use, but I tested all systems and boards at -45 C in the production process before shipping to satisfy the contract with the telephone companies. How much money did I save? Probably none! By the way, I spent 20+ years in telecom transmission systems design in fiber, radio, and metallic systems. If you notice, some Industrial family parts require more startup current at lower temperatures. At very low temperatures, the transistors are very strong, and very fast. This leads to larger currents than would otherwise be observed at 0 degrees centigrade. Once we identify the sources of these currents, we tend to remove them from future designs. We are not usually concerned with currents less than 1 ampere in the largest devices, as operational currents are often greater. Spartan Family parts have their own requirements, and strive for much much lower currents (see individual member data sheets). The process is different for Spartan wafers, and it can be optimized for other parameters. Additionally Spartan devices usually have an opportunity to be re-designed for the addition of the power down feature, and other power saving features. Spartan is often the favorite choice in many low power telecom applications due to this extra design effort. We do not require our own special power supply ICs like DSPs and uProcessors, and plan to continue to interface with the widest range of ramp on times and behavior power supplies possible. Austin Alain Cloet wrote: > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:39B7CD44.B9D9F57F@yahoo.com... > > I must say that I am floored by this information. All the time I have > > been using Xilinx parts, I have never been aware of the high current > > required for startup. I guess I was lucky that the systems I worked on > > had plenty of power for startup. > > > I could imagine it either, but when I was told of the startup problems at > low temperature it was my first guess. I'm not a designer, so I wasn't > aware that after boot the FPGAs consumed so less ofter startup - the whole > 3.3 part of the board (which is mainly just the three XL4013XL-parts and > some capacitors near the power) consumes after startup approx. 50 mA. The > whole boot thing takes from 500µs to 5 ms depending on the temperature, so > you can't possible notice this if you don't measure this intentionally... > > In a test of the startup power with a external power source with a max of 5 > A (!) it's still possible to see that the voltage doesn't go up in a > regulated way - in other words: the 3 parts & the capacitors (which, of > course, have their influence as well with fast power-up) would have taken > more than 5 A if it were possible...(at -40C, and more than half an hour > unpowered) > > Under relative normal condition the former regulator could make it (even > though the voltage didn't went up in a continuous way) at room temperature, > but under the maximum stressed specs of the board - at -40C for more than 30 > minutes unpowered (so really cold, even internally) and a supply voltage of > 4V5 - it didn't... In the measurements it showed oscillating of the voltage > even at -20C (due to the current limiting of the regulator), but the core of > FPGA - my guess again - got warm enough to start. Also at -40C a supply > voltage of 5V2 made it possible to boot... > > Thanks for all the reactions, > Alain --------------7CE468A475D17E5248325F53 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Alain, <p>"High" is a relative term. Please read the following to see the differentiation between large high performance FPGAs, and small lower performance FPGAs. <p>'Luck" is also a relative term, and I can assure you, that luck has nothing to do with it. Two years ago we recognized that the larger devices were requiring significant (greater than 1 ampere) of start up current, and we addressed the issue, along with all older family members, and devised the <i>Power On Ramp Up Current Capacity</i> specification for the power supplies, and modified new designs as appropriate and put in place tests for older family parts. <p>If you are buying the Commercial part (C), it is not specified below 0 C. <p>If you are buying the Industrial part (I), the specifications apply down to -40 C. <p>For many years (at my previous employer), I bought and used commercial parts in telecom applications for -40 C use, but I tested all systems and boards at -45 C in the production process before shipping to satisfy the contract with the telephone companies. How much money did I save? Probably none! By the way, I spent 20+ years in telecom transmission systems design in fiber, radio, and metallic systems. <p>If you notice, some Industrial family parts require more startup current at lower temperatures. At very low temperatures, the transistors are very strong, and very fast. This leads to larger currents than would otherwise be observed at 0 degrees centigrade. Once we identify the sources of these currents, we tend to remove them from future designs. We are not usually concerned with currents <b>less than 1 ampere</b> in the largest devices, as operational currents are often greater. <p>Spartan Family parts have their own requirements, and strive for much much lower currents (see individual member data sheets). The process is different for Spartan wafers, and it can be optimized for other parameters. Additionally Spartan devices usually have an opportunity to be re-designed for the addition of the power down feature, and other power saving features. Spartan is often the favorite choice in many low power telecom applications due to this extra design effort. <p>We do not require our own special power supply ICs like DSPs and uProcessors, and plan to continue to interface with the widest range of ramp on times and behavior power supplies possible. <p>Austin <p>Alain Cloet wrote: <blockquote TYPE=CITE>"rickman" <spamgoeshere4@yahoo.com> wrote in message <br><a href="news:39B7CD44.B9D9F57F@yahoo.com">news:39B7CD44.B9D9F57F@yahoo.com</a>... <br>> I must say that I am floored by this information. All the time I have <br>> been using Xilinx parts, I have never been aware of the high current <br>> required for startup. I guess I was lucky that the systems I worked on <br>> had plenty of power for startup. <br>> <br>I could imagine it either, but when I was told of the startup problems at <br>low temperature it was my first guess. I'm not a designer, so I wasn't <br>aware that after boot the FPGAs consumed so less ofter startup - the whole <br>3.3 part of the board (which is mainly just the three XL4013XL-parts and <br>some capacitors near the power) consumes after startup approx. 50 mA. The <br>whole boot thing takes from 500µs to 5 ms depending on the temperature, so <br>you can't possible notice this if you don't measure this intentionally... <p>In a test of the startup power with a external power source with a max of 5 <br>A (!) it's still possible to see that the voltage doesn't go up in a <br>regulated way - in other words: the 3 parts & the capacitors (which, of <br>course, have their influence as well with fast power-up) would have taken <br>more than 5 A if it were possible...(at -40C, and more than half an hour <br>unpowered) <p>Under relative normal condition the former regulator could make it (even <br>though the voltage didn't went up in a continuous way) at room temperature, <br>but under the maximum stressed specs of the board - at -40C for more than 30 <br>minutes unpowered (so really cold, even internally) and a supply voltage of <br>4V5 - it didn't... In the measurements it showed oscillating of the voltage <br>even at -20C (due to the current limiting of the regulator), but the core of <br>FPGA - my guess again - got warm enough to start. Also at -40C a supply <br>voltage of 5V2 made it possible to boot... <p>Thanks for all the reactions, <br>Alain</blockquote> </html> --------------7CE468A475D17E5248325F53--Article: 25357
"Elftmann" <elftmann@pacbell.net> writes: > All good points. Issues that ASIC designers have faced forever. When > companies such as Juniper, RedBack, Nexabit/Lucent, Cisco, etc.... > go to the investment community, they are not highlighting their FPGA > designs, they are highlighting their ASIC designs. > Which only proves that complex designs can be done correctly the first time > and EXACTLY correct the very FIRST time. Or the second or third time. When they talk to outsiders, they don't usually discuss how many spins it took. (Except for rare cases when they brag that it only took one.) Obviously they all try fairly hard to get it right the first time, but it doesn't always happen.Article: 25358
"Tim" <topedm@ms11.hinet.net> writes: > I'm seeking a FPGA/CPLD device for my project. Would anyone let me know if > the cypress Delta39K chips are available now, and who carry this product ? I've been told that the 39K100 will sample to "select customers" in 4Q2000.Article: 25359
This is a multi-part message in MIME format.
--------------1D863A72AA1FFC0756E671D8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
LUT data is simple to reverse engineer, just extremely tedious.
Using the FPGA Editor, put a LUT in a particular location, with
a simple equation in place..say:
R1C1.F = 0
Save the design, compile the bitstream, use it for reference.
Next change the equation:
R1C1.F = !F1*!F2*!F3*!F4
(uh, I think the 3000 series labelled the inputs A, B, C, D, but
you get the idea)
Compare the two bitstreams, and the difference will tell you
where the bit for the product term !F1*!F2*!F3*!F4 resides.
Next, use:
R1C1.F = F1*!F2*!F3*!F4
and repeat the comparison to find out where the bit for
F1*!F2*!F3*!F4 is.
Do this for all 16 bits and you've decoded that LUT.
(Do a few more LUTS and you may detect a pattern.)
But this is a painful process. I did it once for a 3000
series design where I needed to fit a compact yet
programmable video timing generator. Never again!
And not being interested in developing development
tools (I only wanted to make compact/versatile counters)
I never did attack the routing bits.
The technique of modifying the bitstream to change
the LUTs worked well. Then the 4000 family came along,
and the LUTs were turned into RAM, and as long as you
could waste a LUT and use the Dual port, it no longer
was necessary to modify the bitstream, the LUT could be
programmed in place rather than in the bitstream.
glen herrmannsfeldt wrote:
>
{other stuff snipped]
> The project I was working on mostly needed the location of the LUT
> data, and they will almost tell you that when they explain readback.
> (Pretty much I would have needed to load different data into ROMs
> in different places. I might have needed to change the carry logic,
> but no routing changes. But then I didn't get to do that project.)
>
> -- glen
--------------1D863A72AA1FFC0756E671D8
Content-Type: text/x-vcard; charset=us-ascii;
name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
filename="jsmith.vcf"
begin:vcard
n:Smith;John L.
tel;work:858-320-4102
x-mozilla-html:FALSE
url:http://www.visicom.com
org:Visicom;Imaging Products
adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA
version:2.1
email;internet:jsmith@visicom.com
title:Principal Engineer
x-mozilla-cpt:;30864
fn:John L. Smith
end:vcard
--------------1D863A72AA1FFC0756E671D8--
Article: 25360Hi Everyone, Xilinx is hiring! In addition to being the leader in the programmable logic industry, we also have one of the happiest work forces in the Silicon Valley (stock options, work/life balance, stock options, tuition reimbursement, stock options...Did I mention stock options?). Please review our current software related job openings at http://www.xilinx.com/hr/reqpost.htm#Software Engineering . Feel free to respond online to any of our openings, or email your resume to craigm@xilinx.com. Thanks, Craig Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25361
Does anyone know how to implement the GSR for virtex using the Orcad simulator. I know how to do it using Viewlogic H gsr c L gsr c Thanks, -- Stan Ramsden Ramsden Designs 631-956-7720 sramsden@hoflink.comArticle: 25362
In article <39B7E6C9.8395CD2F@xilinx.com>, > gives you nothing over just copying the bitstream and calling that > reverse engineering. Far better would be to determine the owner of > the IP and go steal their filing cabinet. I did not mean to reverse engineer IP. That is in many cases more expensive than developing it yourself. (For examnple, you can not reuse it for another FPGA) I was talking about reverse engineering the bitstream format to be able to replace JBits by my own code. As Steve Trimberger and others pointed out, this is not very hard to do for most of the FPGA. And documentation about the LCA format for example has been around for a long time. > As for self-reconfiguration from the FPGA, I suggest you look at the > work-horse of reconfigurable computing,the XC6200 and the work of Adam You sell XC6200? Make me an offer. How does the cost per gate compare to spartan-II? Xilinx is "discussing whether the configuration port will be made available internally to the FPGA in Virtex-II". A Bitstream documentation might be usefull in that case. CU, Kolja Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25363
So, what is the smart method of delaying Virtex configuration? I need to keep Virtex non-configured for an arbitrary time. The config mode can vary - master or slave. Previous data sheets have specified that PROGRAM can be held low to make a delay, but the latest data sheet (2.2) does not mention it - I think it means this method is not recommended. Now you say that keeping INIT low can make the chip consume plenty of current = make hot. What to do? Let it start configuration and wait infinitely for CCLK (slave) or configure with random data until it stops due to checksum error? Henryk Cieslak Becker Elektronic Polska Austin Lesea wrote in message <39B7BF1E.B24BE76F@xilinx.com>... >Alain, > >We recently (> 1 year ago) implemented a Power On Ramp Up current specification >for all parts. We have not gone all the way back to the original 4K family, but >the data sheet now specifies the current capacity of the power supply required >for clean out and startup prior to configuration. > >I would recommend that 1 amp be allowed for each older part (4K, 4KE). > >I know the 4KXL, and all subsequent parts are characterized AND TESTED. > >There are also things you can do which make this start up current worse. A >generally rising voltage, that rises no faster than 2 milliseconds, and no >slower than 50 milliseconds, and starts from near 0 Vdc (< 300 mV) is always the >best way to go. Starting from a voltage around 450 mV to 700 mV from a >previously configured part, or holding INIT to prevent configuration, or passing >through the POR trip point and then going below the POR trip point, are common >causes of higher currents. > >In all cases, check the latest website data sheet. An example is here: > >http://www.support.xilinx.com/partinfo/ds005.pdf > >page 2 of 16 > >For parts that have virtually no current requirement at starup, use the 4KXLA, >4KXV, SpartanXL, or contact your sales office and FAE for assitance in >selection. > >Austin Lesea >IC Design, Xilinx > >Alain Cloet wrote: > >> "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message >> news:8p6288$5k7$2@noao.edu... >> > Alexandr V Shuvalov wrote: >> > >> > > Which voltage regulators ICs are commonly used to power supply Xilinx XL >> > > and other low voltage (3.3-2.5v) devices? >> > >> > I used a National LM3940IS-3.3 to drop a VME 5V supply down to 3.3V @ 1 >> > A. >> > >> Can you power-up several Xilinx-FPGA's with this element ; or is there a >> work-around ? >> >> We had this problem recently (not completelly solved), and the most recent >> idea is to supply 3 Xilinx FPGA's with one National LM3940 (other version : >> WG ?). >> >> The element we used before had a fast power-up time which caused the FPGA >> (4013) to take up to 1 A, and the regulator couldn't give 3A (it went ok a >> normal temperature, but in a cold phase at -40C it didn't go). >> >> Can the LM3940 do the job ? >> >> TIA, >> Alain >Article: 25364
And then came virtex with the SRL16E's. That makes reprogramming the luts..well...almost too easy! "John L. Smith" wrote: > > The technique of modifying the bitstream to change > the LUTs worked well. Then the 4000 family came along, > and the LUTs were turned into RAM, and as long as you > could waste a LUT and use the Dual port, it no longer > was necessary to modify the bitstream, the LUT could be > programmed in place rather than in the bitstream. > -- -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 or http://www.fpga-guru.comArticle: 25365
This is from Ray Andraka's web site: http://www.andraka.com/distribu.htm Choose the right C's and you got your DCT. CU, Kolja In article <0d7t5.793$EW.854037@nnrp6.proxad.net>, "Seb C" <Seb@stien.bizland.com> wrote: > Hi, > > I'm interested by pictures compressions, especially DCT, and if someone know > how to do a DCT into an FPGA, i take all what you have !! Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25366
Please Ignore.Article: 25367
Hi all, I trying to synthesize an old design written in verilog (which is not my cup of tea, I use VHDL). This design instantiate some module, but I want to use a new version of this module, written in VHDL. How do I do this? I am using Synplify 6.0, which should support mixed language source files, but it complains that the referenced module can not be found. I know that the module name is not declared in any verilog file anymore, but when the vhdl file with the corresponding entity name is compiled into the library work, I supposed that Synplify should be able to plug that compiled entity name into the place where the module name is referenced, but I can not figure out how to do it. Maybe I trying the impossible here? Thanks for any help. ThomasArticle: 25368
--------------729D5D0462F71FF8CA870A85 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Henryk, The INIT holdoff warning applies to 4K only. It does not apply to Virtex, and Virtex architecture derivatives. I am sorry for the confusion. In 4K, holding INIT and preventing clean out does not make the device HOT -- it may be that the 4K device is in contention from the Vcc not going down below a few hundred millivolts, and then the Vcc returns, and the 4K device is in a partially configured state, and drawing current. So the device is already HOT and getting hotter, and INIT prevents the clean out. Again, Virtex, Virtex E, Spartan2 do not have this behavior. The design is such that the means of contention that were caused by memory contents which occurred in 4K do not exist in Virtex. Austin Henryk Cieslak wrote: > So, what is the smart method of delaying Virtex configuration? I need to > keep Virtex non-configured for an arbitrary time. The config mode can vary - > master or slave. > Previous data sheets have specified that PROGRAM can be held low to make a > delay, but the latest data sheet (2.2) does not mention it - I think it > means this method is not recommended. > Now you say that keeping INIT low can make the chip consume plenty of > current = make hot. > What to do? Let it start configuration and wait infinitely for CCLK (slave) > or configure with random data until it stops due to checksum error? > > Henryk Cieslak > Becker Elektronic Polska > > Austin Lesea wrote in message <39B7BF1E.B24BE76F@xilinx.com>... > >Alain, > > > >We recently (> 1 year ago) implemented a Power On Ramp Up current > specification > >for all parts. We have not gone all the way back to the original 4K > family, but > >the data sheet now specifies the current capacity of the power supply > required > >for clean out and startup prior to configuration. > > > >I would recommend that 1 amp be allowed for each older part (4K, 4KE). > > > >I know the 4KXL, and all subsequent parts are characterized AND TESTED. > > > >There are also things you can do which make this start up current worse. A > >generally rising voltage, that rises no faster than 2 milliseconds, and no > >slower than 50 milliseconds, and starts from near 0 Vdc (< 300 mV) is > always the > >best way to go. Starting from a voltage around 450 mV to 700 mV from a > >previously configured part, or holding INIT to prevent configuration, or > passing > >through the POR trip point and then going below the POR trip point, are > common > >causes of higher currents. > > > >In all cases, check the latest website data sheet. An example is here: > > > >http://www.support.xilinx.com/partinfo/ds005.pdf > > > >page 2 of 16 > > > >For parts that have virtually no current requirement at starup, use the > 4KXLA, > >4KXV, SpartanXL, or contact your sales office and FAE for assitance in > >selection. > > > >Austin Lesea > >IC Design, Xilinx > > > >Alain Cloet wrote: > > > >> "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message > >> news:8p6288$5k7$2@noao.edu... > >> > Alexandr V Shuvalov wrote: > >> > > >> > > Which voltage regulators ICs are commonly used to power supply Xilinx > XL > >> > > and other low voltage (3.3-2.5v) devices? > >> > > >> > I used a National LM3940IS-3.3 to drop a VME 5V supply down to 3.3V @ 1 > >> > A. > >> > > >> Can you power-up several Xilinx-FPGA's with this element ; or is there a > >> work-around ? > >> > >> We had this problem recently (not completelly solved), and the most > recent > >> idea is to supply 3 Xilinx FPGA's with one National LM3940 (other version > : > >> WG ?). > >> > >> The element we used before had a fast power-up time which caused the FPGA > >> (4013) to take up to 1 A, and the regulator couldn't give 3A (it went ok > a > >> normal temperature, but in a cold phase at -40C it didn't go). > >> > >> Can the LM3940 do the job ? > >> > >> TIA, > >> Alain > > --------------729D5D0462F71FF8CA870A85 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Henryk, <p>The INIT holdoff warning applies to 4K only. It does not apply to Virtex, and Virtex architecture derivatives. <p>I am sorry for the confusion. <p>In 4K, holding INIT and preventing clean out <b>does not make the device HOT</b> -- it may be that the 4K device is in contention from the Vcc not going down below a few hundred millivolts, and then the Vcc returns, and the 4K device is in a partially configured state, and drawing current. So the device is already HOT and getting hotter, and INIT prevents the clean out. <p>Again, Virtex, Virtex E, Spartan2 do not have this behavior. The design is such that the means of contention that were caused by memory contents which occurred in 4K do not exist in Virtex. <p>Austin <br> <p>Henryk Cieslak wrote: <blockquote TYPE=CITE>So, what is the smart method of delaying Virtex configuration? I need to <br>keep Virtex non-configured for an arbitrary time. The config mode can vary - <br>master or slave. <br>Previous data sheets have specified that PROGRAM can be held low to make a <br>delay, but the latest data sheet (2.2) does not mention it - I think it <br>means this method is not recommended. <br>Now you say that keeping INIT low can make the chip consume plenty of <br>current = make hot. <br>What to do? Let it start configuration and wait infinitely for CCLK (slave) <br>or configure with random data until it stops due to checksum error? <p>Henryk Cieslak <br>Becker Elektronic Polska <p>Austin Lesea wrote in message <39B7BF1E.B24BE76F@xilinx.com>... <br>>Alain, <br>> <br>>We recently (> 1 year ago) implemented a Power On Ramp Up current <br>specification <br>>for all parts. We have not gone all the way back to the original 4K <br>family, but <br>>the data sheet now specifies the current capacity of the power supply <br>required <br>>for clean out and startup prior to configuration. <br>> <br>>I would recommend that 1 amp be allowed for each older part (4K, 4KE). <br>> <br>>I know the 4KXL, and all subsequent parts are characterized AND TESTED. <br>> <br>>There are also things you can do which make this start up current worse. A <br>>generally rising voltage, that rises no faster than 2 milliseconds, and no <br>>slower than 50 milliseconds, and starts from near 0 Vdc (< 300 mV) is <br>always the <br>>best way to go. Starting from a voltage around 450 mV to 700 mV from a <br>>previously configured part, or holding INIT to prevent configuration, or <br>passing <br>>through the POR trip point and then going below the POR trip point, are <br>common <br>>causes of higher currents. <br>> <br>>In all cases, check the latest website data sheet. An example is here: <br>> <br>><a href="http://www.support.xilinx.com/partinfo/ds005.pdf">http://www.support.xilinx.com/partinfo/ds005.pdf</a> <br>> <br>>page 2 of 16 <br>> <br>>For parts that have virtually no current requirement at starup, use the <br>4KXLA, <br>>4KXV, SpartanXL, or contact your sales office and FAE for assitance in <br>>selection. <br>> <br>>Austin Lesea <br>>IC Design, Xilinx <br>> <br>>Alain Cloet wrote: <br>> <br>>> "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message <br>>> <a href="news:8p6288$5k7$2@noao.edu">news:8p6288$5k7$2@noao.edu</a>... <br>>> > Alexandr V Shuvalov wrote: <br>>> > <br>>> > > Which voltage regulators ICs are commonly used to power supply Xilinx <br>XL <br>>> > > and other low voltage (3.3-2.5v) devices? <br>>> > <br>>> > I used a National LM3940IS-3.3 to drop a VME 5V supply down to 3.3V @ 1 <br>>> > A. <br>>> > <br>>> Can you power-up several Xilinx-FPGA's with this element ; or is there a <br>>> work-around ? <br>>> <br>>> We had this problem recently (not completelly solved), and the most <br>recent <br>>> idea is to supply 3 Xilinx FPGA's with one National LM3940 (other version <br>: <br>>> WG ?). <br>>> <br>>> The element we used before had a fast power-up time which caused the FPGA <br>>> (4013) to take up to 1 A, and the regulator couldn't give 3A (it went ok <br>a <br>>> normal temperature, but in a cold phase at -40C it didn't go). <br>>> <br>>> Can the LM3940 do the job ? <br>>> <br>>> TIA, <br>>> Alain <br>></blockquote> </html> --------------729D5D0462F71FF8CA870A85--Article: 25369
Hi, I'm looking for VHDL (conversions) functions supporting the IEEE 754 floating point standard. To be more specific, I want to convert variables of type "real" to the IEEE 754 floating point format (single precision, 32-bit), and vice versa. In addition, I would greatly appreciate anyone who could direct me to the (lastest version of) the (proposed?) VHDL MATH package. Best regards, Jaap MolArticle: 25370
Hi There is a new free online adult personal ads site at www.twisterz.co.uk <http://www.twisterz.co.uk> , please visit and post your details and a photo if you wish. Regards Mr Twisterz bDpDgEqBArticle: 25371
Pls ignore - my server not working For Email remove "NOSPAM" from the addressArticle: 25372
Well, not exactly. DCT is the summation y[k]= c[k] sum_N(x[k]cos(pi*(2n+1)*k/2N)) You can use distributed arithmetic, but it is a bit more complicated than just setting the constants because the 'constant' is a function of k and n. kolja@prowokulta.org wrote: > > This is from Ray Andraka's web site: > http://www.andraka.com/distribu.htm > > Choose the right C's and you got your DCT. > > CU, > Kolja > > In article <0d7t5.793$EW.854037@nnrp6.proxad.net>, > "Seb C" <Seb@stien.bizland.com> wrote: > > Hi, > > > > I'm interested by pictures compressions, especially DCT, and if > someone know > > how to do a DCT into an FPGA, i take all what you have !! > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -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 or http://www.fpga-guru.comArticle: 25373
I really hate to ask silly questions like this, but I hate calling the distros because once you tell them you're thinking about considering thinking about using a part in a design, they jump all over you because they think you're gonna be writing a req for 10,000 parts tomorrow ... I'm looking at doing a VirtexE design. XCV50E should be big enough. Mainly, I want the LVDS I/O. Are they available now, or will they be available in the next couple of months? Of course, I could probably do the design with external LVDS parts, but this seems like a "neat" solution. -- andy ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25374
Hi. Does anyone know any manufacturer who fabricates numerically-controlled crystal oscillators (NCXO), also known as digitally-controlled crystal oscillators (DCXO) which are suitable for digital phase-locked loop designs in VHDL and FPGAs? Although these blocks resemble a numerically-controlled oscillator (NCO), they differ in that the NCXO is not oversampled to generate the required output signal (an NCO needs to be oversampled by at least 8-times in order to have an acceptable low jitter output). Rather, a digital input word is fed to the NCXO and it synthesizes the required output frequency using a standard, low-cost crystal oscillator. The output is also a square wave, just like the standard crystal. In general, the NCXO has a narrow tuning range similar to a voltage-controlled crystal oscillator (VCXO), e.g. +/-150ppm relative to a frequency in the MHz range. The NCXO technology is fairly recent from what I understand, but allows one to replace a circuit composed of a digital-to-analog converter (DAC) and a VCXO by one chip that performs the exact same task will less design hassles. The DCXO is ideal for custom-made phase-locked loop (PLL) circuits using digital sections that can be implemented in VHDL and FPGAs. Since I haven't been able to find any NCXO manufacturers over the web, I am now looking to the knowledgeable engineers, designers and friends that frequent these newsgroups for some potential referrals and/or links. Thanks in advance for your help. Nestor
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