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
Eric Smith wrote: > "If you're using Gray counters because you have counters in two clock > domains (e.g., for a FIFO), doesn't implmenting them as binary counters > with converters defeat the purpose? With that implementation you can > have glitches where multiple bits change simultaneously. Only if you do a combinatorial (XOR) decode of the binary. No problem if you re-register the Gray, and also no problem if you derive the input to the Gray registers from the binary Ds. Peter AlfkeArticle: 28376
Hi, This is probably a basic question. I am using cadence tool for designing FPGA. Everything there is compiled as verilog. I need to run the simulation to test the design. Cadence supports "singnalscan" to view the waveforms... But I dont understand where I should put the timing values for different signals from cadence. When I run the simulation I can see only flat waveforms. Looks like it needs a simulation file with *.trn extension.... Can anyone enlighten me on that... Like How I can write a simulation file OR how I can specify the waveforms of different input signals to see the response!!? Thanks Sharif Sent via Deja.com http://www.deja.com/Article: 28377
Bottom Line Technologies Inc., designing with Xilinx since 1986 and one of Xilinx's first XPERT partners, is hiring senior engineers with experience in FPGA and/or ASIC design and Verilog and/or VHDL expertise. See our web site www.bltinc.com and select EMPLOYMENT or call us at 908-713-6100 for further information.Article: 28378
You are right that the design wouldn't work if you just read the unregistered XOR outputs in another domain. The second set of flops are required. That is, you clock the conventional counter and the Gray pipeline registers on clock A, and then you can read the Gray registers from domain B safely. The XOR outputs can glitch so they need to be registered. Eric Smith wrote in message ... >"Kevin Neilson" <kmneilson@earthlink.net> writes: >> Making a Gray counter is surprisingly simple. I have some code, which I >> can't give out, but it is basically just a conventional counter and some >> XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. >> Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = >> (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. >> "Gray" can just be the output of the flipflops, or you can pipeline the >> output for extra speed. In that case the Gray counter would run at whatever >> speed the convential counter ran. > >If you're using Gray counters because you have counters in two clock >domains (e.g., for a FIFO), doesn't implmenting them as binary counters >with converters defeat the purpose? With that implementation you can >have glitches where multiple bits change simultaneously. >Article: 28379
Peter Alfke wrote: > > > I have forwarded these request to the appropriate party (and also to the > highest level) within Xilinx. I will let them come up with the right > response. > We are aware of the problem and the opportunity. > > Peter Alfke, Xilinx Applications Is there any benefit in a larger number of requests ? If so, count me :-) Simon. -- Physicists get hadrons!Article: 28380
Orcad capture v9.2 (and possibly even 9.1) has a Xilinx "import" facility to do most of the tedious work of building symbols. The command is under the TOOLS/GENERATE PART menu, and accepts either a Xilinx PIN file or a .XNF netlist. -- Bob Elkind, eteam@aracnet.com Gil Golov wrote: > > Does anybody have a symbol library for Xilinx chips for Orcad capture. > I'm specially looking for the PQ208 package for the Spartan II > and VX44 package for the 18Vxx ISP Prom > > Many thanks for your help > > Gil Golov.Article: 28381
See the response by Dennis McCrohan. He is not the official Xilinx spokesman, neither am I, but he brought up some valid points. Quality assurance and support can be an enormous burden, that must be weighed against the potential total benefit, i.e. additional chip sales. Peter Alfke ========================== Simon Gornall wrote: > Peter Alfke wrote: > > > > > > I have forwarded these request to the appropriate party (and also to the > > highest level) within Xilinx. I will let them come up with the right > > response. > > We are aware of the problem and the opportunity. > > > > Peter Alfke, Xilinx Applications > > Is there any benefit in a larger number of requests ? If so, count me :-) > > Simon. > > -- > Physicists get hadrons!Article: 28382
> patches.... If I build our tools on my box, how do I warranty that they will > run (correctly) on any other Linux machine in the world? In the Windows > world, we have SP's from MS that we can specify on our product requirements > and build and test against (oh yeah, we also have to test against many > localized versions of Windows). A lot of combinations, but at least finite. I don't know much about the Windows world, but I've heard enough stories about things breaking because some add-on software installed something that broke something else .... The major Linux distributions come on CDs with version numbers. I don't see why that isn't as well specified as an SP from MS. All you have to do is pick a few to support. In case anybody is wondering, I'm also interested in having tools that run on Linux. -- These are my opinions, not necessarily my employers. I hate spam.Article: 28383
Dennis McCrohan wrote: > > I probably shouldn't, but I can't resist commenting on this thread... > > Let's preface this by saying that the following in no way, shape, or form > expresses the opinion of Xilinx, Inc. > > Linux presents some real challenges from a s/w business point-of-view (as > opposed to looking at it as a programmer's toy). Think of it from the > perspective of a software quality assurance manager, or support manager. The > reality of Linux is that there are no two Linux installations alike. I have > Linux on one of my machines, originally RH 6.0. But now I can claim no > version for it, since I've rebuilt the kernel several times with various > patches.... If I build our tools on my box, how do I warranty that they will > run (correctly) on any other Linux machine in the world? In the Windows > world, we have SP's from MS that we can specify on our product requirements > and build and test against (oh yeah, we also have to test against many > localized versions of Windows). A lot of combinations, but at least finite. To quote Josh Rosen: > The issue of > which distribution to support is also easy, it's Redhat. Redhat is the > defacto standard, it's what Synopsys and Cadence support so that's what > Xilinx should support also. And I completely agree. Support stock Redhat, everyone else is on their own. > So supporting any new OS, even one that doesn't come in infinite > permutations like Linux, involves very significant $$$. I, as a developer, > see almost none of those costs, they are born primarily by the folks who > supply our development tools/platforms, test, support, and documentation > people. For all of this, we would see very little incremental revenue (how > much do we charge for our tools?). Not surprisingly, I suspect that most of > my fellow developers would like to support Linux, and most of the rest of > the company would like to have our heads for even muttering the word. > > FYI, I am a s/w developer for Xilinx, working primarily on the > Webpack/Webfitter stuff. In previous lives I was a ASIC/board designer. I've > also done web programming, network admin, etc. on several Linux systems. I would at least like to see the basic command line tools ported to Linux (since I currently run them under Linux/Wine anyway). As Georg Acher mentioned, they are unlikely to require any changes at all to work in Linux. And because of that they are unlikely to require any more support than they currently require on any other platform. Though I realize that a partial Linux release may be an even harder sell to the managers. -- My real email is akamail.com@dclark (or something like that).Article: 28384
Using the D-inputs would probably be a bit slower, since the combinational path would include the adder logic in addition to the XORs. Peter Alfke wrote in message <3A5CB7A4.EC07468@xilinx.com>... >XAPP131 is just a straightforward binary-to-gray converter, as described in >the 1972 Fairchild applications handbook ( by yours truly). >The trick of using the XOR of the binary D-inputs is smarter, if I may say >so. >Same brain, just 29 years additional experience. :-) >Peter Alfke >======================================Article: 28385
Interesting, but hard to understand. And in my case, there was no need to make the counter faster than the FIFO data storage in BlockRAM, which limits the cycle time to about 4 ns ( 200 MHz was my usual conservatism, I could have said 250 MHZ, but that would be bragging :-) I would also feel a bit queasy using 256 shifting bits to implement what is really a 12-bit counter. What if one bit ever goes wrong? It will never straighten itself out. Maybe this is heresy in a digital world, but the reliability of a fast-clocked shift register bit may perhaps not be as good as that of a static configuration bit. I always feel uneasy when there are lots of redundant flip-flops sloshing around. Call me chicken... Peter Alfke Kevin Neilson wrote: > SRL Johson Rings: > > Provided one is using a Virtex architecture, a smaller and faster > implementation would be to use the SRL (shift-register LUTs) as 16-bit > Johnson rings. A 4-bit Gray counter would use only 4 LUTs and no CLB flops. > You just configure the LSB SRL as a 16-bit Johnson ring with the initial > pattern 01100110_01100110, the next bit as an SRL loaded with > 00111100_00111100, and so on. After 4 bits, it gets a little harder. To do > an 8-bit counter, you would need 10 SRLs (10 LUTs). Bit 3 would need 2 > SRLs, since it repeats after 32 ticks. Then you would need a "terminal > count" SRL which is a Johnson ring with one '1' so the output goes hi every > 16th cycle. This would be used at the clock enable to another 4-SRL Johnson > Ring Gray counter. You could keep stringing them together like this. A > 12-bit counter would have 3 quad-Johnson-rings and the third would have a > clock enable of the AND of the terminal counts of the lower 2. So that's > about 16 LUTs for a 12-bit Gray counter. Which is better than the 24 flops > and 24 luts you would normally need. Of course this only works for Virtex > and Spartan-II. But this would be the fastest and smallest implementation > for that family. It only counts forward, though, and can't be reset, which > is a big drawback. > > -Kevin > > Peter Alfke wrote in message <3A5C99C5.6B1A0CBC@xilinx.com>... > >I recently had reason to investigate this for the design of an asynchronous > >BlockRAM-based FIFO in Virtex and Virtex-II. ( BTW: I got it to run at 200 > >MHz, with proper FULL and EMPTY handshake, while running with with two > >independent unrelated clocks) > >Here are my notes: > > > >Grey-Coded Addresses > >Only one bit/address changes at any time > >Therefore no glitches from the identity comparator > > > >Implementation: > >Build binary counter > >Generate XOR of two adjacent D-inputs > >(that is the trick ! Don't use the binary Q, use the binary D) > >Feed these XORs to a register = Grey ! > >MSB binary = MSB Grey > >Advantage: very fast and easily epandable. > > > >Please excuse the terse (PowerPoint) notation. > >Yes, it wastes flip-flops. But I think it is still the most compact > >(cheapest) solution in Virtex, where one CLB implements two bits, since it > >has 4 flip-flops. > >I tried various other ways, and -while they did not waste flip-flops- they > >were no cheaper. > >BTW: You can of course use the simultaneous binary output "for free". > >You can also run the counter in both directions "for free". > >I will gladly accept a more compact solution. > > > >Peter Alfke, Xilinx Applications > > > > > >Bill Lenihan wrote: > > > >> I know how to make binary up/down counters and LFSR-based counters in > >> verilog, but does anyone know of an algorithmic/equation-based way to > >> make grey-code counters? > >> > >> The only examples I've seen are from old PAL application notes, and they > >> are for 4-bit grey counters that are described as 16-state state > >> machines, which is ok if you are keeping the counter at 4-bits, but > >> impractical if you are going to much wider bit widths. > >> > >> -- > >> ============================== > >> William Lenihan > >> lenihan3weNOSPAM@earthlink.net > >> .... remove "NOSPAM" when replying > >> ============================== > > > >Article: 28386
Hi All, I want to make a switching IC, decimal to binary idea. I've made a PAL before using Palasm. Made the 16V8/16L8 PLDs and it works. Now I need to expand the small PLD. 1. what do I do next? 2. I have my Palasm code below ; ;PALASM Design Description ;---------------------------- Declaration Segment ------------ TITLE VGAL-3 for GAL16V8 using PALCE16V8 PATTERN A REVISION 1.0 AUTHOR Ed Ngai COMPANY tbd DATE 7/26/00 ;The design file has extension *.PDS CHIP DECBIN MUX PAL16V8 ;---------------------------- PIN Declarations --------------- ;ASSIGNED pin numbers to match I/O. ;Address and LEDs. PIN 2 SW1 COMBINATORIAL ; INPUT PIN 3 SW2 COMBINATORIAL ; INPUT PIN 4 SW3 COMBINATORIAL ; INPUT PIN 5 SW4 COMBINATORIAL ; INPUT PIN 10 GND ; INPUT PIN 12 L1 COMBINATORIAL ; OUTPUT PIN 13 L2 COMBINATORIAL ; OUTPUT PIN 14 L3 COMBINATORIAL ; OUTPUT PIN 15 L4 COMBINATORIAL ; OUTPUT PIN 16 A3 COMBINATORIAL ; OUTPUT PIN 17 A2 COMBINATORIAL ; OUTPUT PIN 18 A1 COMBINATORIAL ; OUTPUT PIN 19 A0 COMBINATORIAL ; OUTPUT PIN 20 VCC ; INPUT ;---------------------------- Boolean Equation Segment ------ EQUATIONS A0 = /SW2 + /SW4 + A0 * /(/SW1 + /SW3) A1 = /SW3 + /SW4 + A1 * /(/SW1 + /SW2) A2 = /SW2 + /SW4 + A0 * /(/SW1 + /SW3) A3 = /SW3 + /SW4 + A1 * /(/SW1 + /SW2) L1 = /(A1 + A0) L2 = /(A1 + /A0) L3 = /(/A1 + A0) L4 = /(/A1 + /A0) ;---------------------------- Simulation Segment ------------ SIMULATION ; 1. Try asserting each of the switches once ; 2. Negate all switches ; 3. Check that the outputs are holding the correct address TRACE_ON SW1 SW2 SW3 SW4 A0 A1 A2 A3 L1 L2 L3 L4 SETF /SW1 SW2 SW3 SW4 SETF SW1 SW2 SW3 SW4 CHECK /A0 /A1 /A2 /A3 L1 /L2 /L3 /L4 SETF SW1 /SW2 SW3 SW4 SETF SW1 SW2 SW3 SW4 CHECK A0 /A1 A2 /A3 /L1 L2 /L3 /L4 SETF SW1 SW2 /SW3 SW4 SETF SW1 SW2 SW3 SW4 CHECK /A0 A1 /A2 A3 /L1 /L2 L3 /L4 SETF SW1 SW2 SW3 /SW4 SETF SW1 SW2 SW3 SW4 CHECK A0 A1 A2 A3 /L1 /L2 /L3 L4 TRACE_OFF ;------------------------------------------------------------------- 3. I'd like to use Xilinx , but now what ? If I was to do this w/ a PLD, 1. I get my PDS , design code right. 2. I get a PLD programmer 3. I burn the PLD 4. I test it on a breadboard What are the steps to make a FPGA? FPGA's are like $20.00 from Digi-key, ok I can buy that. Xilinx ISE Foundation I can d/l. I have to solder some small QFP, I can do SMD, 0.050" to wire-wrap wire is not bad. Can some fill in the steps ? thanks EdArticle: 28387
Here is some direct logic for a 4 bit Gray code counter:
G0 <- !( G3 @ G2 @ G1 )
G1 <- G0 !( G3 @ G2 ) + !G0 G1
G2 <- !G3 G1 !G0 + G2 ( !G3 + !G1 + G0 )
G3 <- G2 !G1 !G0 + G3 ( G2 + G1 + G0 )
( + = or, @ = xor, ! = not, and is implied)
Generally, the reflected code is logic intensive,
because _every_ bit depends _every_ other bit
(except G0 does not depend on itself!)
Here's the reverse conversion as well:
G(N) = B(N)
G[n] = B[n] @ B[n+1] B[n] = G[N] @ G[N-1] @ G[N-2] ... @ G[n]
(N = MS bit, n = any smaller bit)
Kevin Neilson wrote:
>
> You are right that the design wouldn't work if you just read the
> unregistered XOR outputs in another domain. The second set of flops are
> required. That is, you clock the conventional counter and the Gray pipeline
> registers on clock A, and then you can read the Gray registers from domain
> B safely. The XOR outputs can glitch so they need to be registered.
>
> Eric Smith wrote in message ...
> >If you're using Gray counters because you have counters in two clock
> >domains (e.g., for a FIFO), doesn't implmenting them as binary counters
> >with converters defeat the purpose? With that implementation you can
> >have glitches where multiple bits change simultaneously.
> >
Article: 28388Supporting Linux would be an order of magnitude cheaper than supporting Windows. Things like kernal versions don't matter to programs like the Xilinx tools. I've just installed the 2.4 kernel on one of my machines and it didn't break anything and going from a 2.2x kernel to 2.4 is as big a step as you can make. The important thing is that Linux is stable, whereas Windows isn't. Windows systems suffer from DLL hell, there is no equivalent on Linux. When you install a new program on Linux you never have to worry that it will stomp on some other program. On Windows you have a 50/50 chance of mangling your system every time you install something. Even when you're not adding new software to a Windows system, it's quietly corrupting itself. Linux doesn't do that, if you want to break a Linux system you have to work at it, it doesn't break itself. As a result you never see strange behavior on Linux systems like you do on Windows. The other advantage of Linux/Unix is that you can keep multiple revs of the software on a system. I have 2.2i, 3.1i, 3.2i and 3.3i on my Linux systems, try doing that with Windows. If there is a problem with a new rev all I have to do change a symbolic link and I'm back to the old rev. This is not just a theoretical advantage, in my earlier post I said that there was a problem with 3.3i under WINE. It turns out that it wasn't a WINE problem, it was a problem with the NT version of map, the Unix version works fine. Xilinx has a fix that they are including in SP7. Because I'm using Linux I was able to go back to 3.2i with a simple link change. If I had been using NT I would have been forced to do a complete reinstall. In article <3A5CC4BE.D0CE4EF9@xilinx.com>, Dennis McCrohan <mccrohan@xilinx.com> wrote: > I probably shouldn't, but I can't resist commenting on this thread... > > Let's preface this by saying that the following in no way, shape, or form > expresses the opinion of Xilinx, Inc. > > Linux presents some real challenges from a s/w business point-of-view (as > opposed to looking at it as a programmer's toy). Think of it from the > perspective of a software quality assurance manager, or support manager. The > reality of Linux is that there are no two Linux installations alike. I have > Linux on one of my machines, originally RH 6.0. But now I can claim no > version for it, since I've rebuilt the kernel several times with various > patches.... If I build our tools on my box, how do I warranty that they will > run (correctly) on any other Linux machine in the world? In the Windows > world, we have SP's from MS that we can specify on our product requirements > and build and test against (oh yeah, we also have to test against many > localized versions of Windows). A lot of combinations, but at least finite. > > So supporting any new OS, even one that doesn't come in infinite > permutations like Linux, involves very significant $$$. I, as a developer, > see almost none of those costs, they are born primarily by the folks who > supply our development tools/platforms, test, support, and documentation > people. For all of this, we would see very little incremental revenue (how > much do we charge for our tools?). Not surprisingly, I suspect that most of > my fellow developers would like to support Linux, and most of the rest of > the company would like to have our heads for even muttering the word. > > FYI, I am a s/w developer for Xilinx, working primarily on the > Webpack/Webfitter stuff. In previous lives I was a ASIC/board designer. I've > also done web programming, network admin, etc. on several Linux systems. > > -dm > > Sent via Deja.com http://www.deja.com/Article: 28389
Here is my algorithm: <BR>For big counters replace function in parentheses with fast carry chain (at least Xilinx FPGAs have such components). For small counters parentheses are excessives. QZ = ~QZ; <BR>Q[0] = QZ ^ Q0; <BR>Q[1] = (~QZ) & Q0 ^ Q1; <BR>Q[2] = (~QZ & ~Q0) & Q1 ^ Q2; <BR>Q[3] = (~QZ & ~Q0 & ~Q1) & Q2 ^ Q3; <BR>... <BR>Q[N-1] = (~QZ & ~Q0 & ~Q1 &..& ~Q[N-3]) & Q[N-2] ^ Q[N-1]; <BR>Q[N] = (~QZ & ~Q0 &..& ~Q[N-2]) ^ Q[N]; ^ is XOR. Jaan Sirp. <I have made grey-code counter, it has N + 1 T-type FFs, where N is number of output bits. I <have used ALDEC schematics capture, but converting it to Verilog is very simple. Let me <know, if you are interested.Article: 28390
I FORGOT A LITTLE, BUT IMPORTANT REMARK: <BR>When resetting the counter, QZ must be set to logic one. < Here is my algorithm: <BR>< For big counters replace function in parentheses with fast carry chain <BR>< (at least Xilinx FPGAs have such components). <BR>< For small counters parentheses are excessives. <BR>< <BR>< QZ = ~QZ; <BR>< Q[0] = QZ ^ Q0; <BR>< Q[1] = (~QZ) & Q0 ^ Q1; <BR>< Q[2] = (~QZ & ~Q0) & Q1 ^ Q2; <BR>< Q[3] = (~QZ & ~Q0 & ~Q1) & Q2 ^ Q3; <BR>< ... <BR>< Q[N-1] = (~QZ & ~Q0 & ~Q1 &..& ~Q[N-3]) & Q[N-2] ^ Q[N-1]; <BR>< Q[N] = (~QZ & ~Q0 &..& ~Q[N-2]) ^ Q[N]; <BR>< <BR>< ^ is XOR, <BR>< ~ is inversion. <BR>< <BR>< Jaan Sirp.Article: 28391
Bill Lenihan <lenihan3weNOSPAM@earthlink.net> writes:
> I know how to make binary up/down counters and LFSR-based counters in
> verilog, but does anyone know of an algorithmic/equation-based way to
> make grey-code counters?
>
> The only examples I've seen are from old PAL application notes, and they
> are for 4-bit grey counters that are described as 16-state state
> machines, which is ok if you are keeping the counter at 4-bits, but
> impractical if you are going to much wider bit widths.
I've done this the brute force way - 6-7 years ago I wrote a program
to generate the verilog case statements for grey code counters (or
Johnson counters). I've uploaded the program at
ftp://ftp.gustad.com/pub/eda/jc.tgz
./jct 4 will generate the following table:
case 10'b0000: ns = 10'b0001;
case 10'b0001: ns = 10'b0011;
case 10'b0011: ns = 10'b0010;
case 10'b0010: ns = 10'b0110;
case 10'b0110: ns = 10'b0111;
case 10'b0111: ns = 10'b0101;
case 10'b0101: ns = 10'b0100;
case 10'b0100: ns = 10'b1100;
case 10'b1100: ns = 10'b1101;
case 10'b1101: ns = 10'b1111;
case 10'b1111: ns = 10'b1110;
case 10'b1110: ns = 10'b1010;
case 10'b1010: ns = 10'b1011;
case 10'b1011: ns = 10'b1001;
case 10'b1001: ns = 10'b1000;
case 10'b1000: ns = 10'b0000;
You'll have to update the bit size manually before you include it in
your code. The jc program will find all possible sequences which
changes in only a single bit:
0 1 3 2 6 4 5 7
0 1 3 2 6 7 5 4 circular
0 1 3 7 5 4 6 2 circular
0 1 5 4 6 2 3 7
0 1 5 4 6 7 3 2 circular
0 1 5 7 3 2 6 4 circular
0 2 3 1 5 4 6 7
0 2 3 1 5 7 6 4 circular
0 2 3 7 6 4 5 1 circular
0 2 6 4 5 1 3 7
0 2 6 4 5 7 3 1 circular
0 2 6 7 3 1 5 4 circular
...
Sequences which wraps around with only a single bit change are marked
circular.
Please note that this is not production code (simply I hack I used
myself). Use at your own risk. If you use and like the program, please
tell Xilinx that you would like their tools ported to Linux :-)
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 28392Dennis McCrohan wrote: > > > Linux presents some real challenges from a s/w business point-of-view (as > opposed to looking at it as a programmer's toy). Think of it from the > perspective of a software quality assurance manager, or support manager. The > reality of Linux is that there are no two Linux installations alike. I have > Linux on one of my machines, originally RH 6.0. But now I can claim no > version for it, since I've rebuilt the kernel several times with various > patches.... If I build our tools on my box, how do I warranty that they will > run (correctly) on any other Linux machine in the world? In the Windows > world, we have SP's from MS that we can specify on our product requirements > and build and test against (oh yeah, we also have to test against many > localized versions of Windows). A lot of combinations, but at least finite. > I can't reproduce your arguments. E.g., I'm using Modelsim on a Suse Linux box, whether Modeltech recommend Red Hat it works fine (Suse is the preferred distribution in german speaking countries). If such a incompatibility would exist, Linux' market share would not increase. There is not only the EDA market, for example Borland is now supporting Linux with it famous s/w development tools. How about the experience of other companies now supporting Linux? -- Dipl.-Ing. Thomas Reinemann IMAT Otto-von-Guericke-Universität Magdeburg Universitätsplatz 2 39106 Magdeburg GermanyArticle: 28393
Peter Alfke <peter.alfke@xilinx.com> writes:
>I have forwarded these request to the appropriate party (and also to the
>highest level) within Xilinx. I will let them come up with the right
>response.
>We are aware of the problem and the opportunity.
Thank you Peter,
I personally think you will get more requests for Linux as the Xilinx
devices gets bigger. Lately I've been retargeting some of our earlier
ASIC (LSI G10) designs into a Virtex. The time it takes to run through
synthesis and par is quite long (27+ hours on a SUN).
Almost every night I log in from home to check my simulation and
synthesis (or par) jobs. Every now and then I'll have to install or
upgrade software while the machine is running (e.g. new Alliance
service pack while FPGA Compiler 2 is running, or vice versa, or
verilog simulations running for weeks). Doing this under Windows is
quite cumbersome as I have explained earlier.
I could of course buy the fastest SUN machine I can get, but I would
rather get a farm of cheap PC's and run Linux...
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 28394
Dennis McCrohan <mccrohan@xilinx.com> writes:
>I probably shouldn't, but I can't resist commenting on this thread...
>Let's preface this by saying that the following in no way, shape, or form
>expresses the opinion of Xilinx, Inc.
Thank you for your comments.
>Linux presents some real challenges from a s/w business point-of-view (as
>opposed to looking at it as a programmer's toy). Think of it from the
I've been doing ASIC design for 10+ years and I've been a Linux user
for the past 7 years (since kernel version 0.99.13). During this time
I've used Linux for production type work and and I would not look at
Linux as a programmers toy...
I'm aware of the vast distribution and library space space under
Linux. I've been running Slackware (and SLS) distributions of Linux. I
too don't know what to call my Linux (other than it used to be a
Slackware release, but now is running kernel 2.4.0).
However, this does not prevent me from running EDA tools from
Synopsys, Cadence and Fintronic. Cadence and Synopsys are actually
facing more difficult problems than Xilinx since they distribute
object files (e.g. for signalscan) and the user links the objects
together to build the executable simulator. Some of objects might be
based upon different libc versions which might cause problems.
Some vendors say that they support a finite set of popular releases
(e.g. Red Hat 6.2/x86). Others say that they will give you Linux
binaries and you're on own if you get problems. I can't see why Xilinx
would have to support all possible releases and patches out there.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 28395Maybe you have the same problem as I (See posting: "Foundation P&R + location constraint" from Monday). The optimizer (synthesis tool or P&R) cancels one of your signals and the P&R tool results in an error because of the invalid pin assignment in the constraint file (location constraint for non existent signal). Why can't the P&R tool just generate a warning instead of an error and assign this pin prohibited for the actual implementation? To come to an ad hoc solution for your problem: You could assign this input signal directly to an unused output pin -> no removing of the optimizer possible. Maybe there are some expert's who know how to tell the synthesis tool not to remove single signals via attributes? Michael diei-unipg-it wrote: > We are implementing a fir filter using VIRTEX FPGA XCV1000-6-BG560.We got a problem during the implementation.Does anybody know how to avoid a signal to be removed during the implementation?For a better understanding of the question a part of the report text > of map.mrp file follows: > > The signal "N_ControlPortPins<7>" is unused and has been removed. > Unused block "C_ControlPortPins<7>" (IBUF) removed. > The signal "ControlPortPins<7>" is unused and has been removed. > Unused block "ControlPortPins<7>.PAD" (X_IPAD) removed.Article: 28396
Hello, Peter Alfke schrieb: > > I suggested a slight twist to this design: > Same logic, but feed the XOR from the D-inputs of the binary counter, not their > Q outputs. This way the binary and grey counters are "in step". > Peter Alfke How do I get access to the D-inputs of the binary counter in VHDL? > > Kevin Neilson wrote: > > > Bill, > > Making a Gray counter is surprisingly simple. I have some code, which I > > can't give out, but it is basically just a conventional counter and some > > XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. > > Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = > > (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. > > "Gray" can just be the output of the flipflops, or you can pipeline the > > output for extra speed. In that case the Gray counter would run at whatever > > speed the convential counter ran. > > > > You may hardcode this or use a loop to make Gray counters of N size. > > > > -Kevin Neilson, IDS > > -- Wolfgang Friedrich wolfgang.friedrich@heitec.de /\ /\ Heitec AG __/ \\ \__ 91052 Erlangen, Schuhstr. 30, Germany \ // / Tel: +49(0)9131/877-237 Fax: +49(0)9131/877-222 \/ \/Article: 28397
murray@pa.dec.com (Hal Murray) writes:
> > (3) Do builds from the command line. Learning how to use ``make'' will
> > vastly repay the effort.
>
> How many other people would be happier if Xilinx "supported" make style
> development?
I almost never use the interactive tools (except the floorplanner).
Here's roughly the flow through my scripts (for a virtex device):
partgen
ngdbuild
map
par
trce
bitgen
promgen
ngdanno
ngd2ver
The last two steps are to generate a gate level verilog netlist and
standard delay file.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 28398
acher@in.tum.de (Georg Acher) writes:
> I spoke about this topic to a FAE of the Xilinx booth at the electronica last
> year. He said roughly the following:
>
> "The Xilinx SW-developers already have Linux versions, since the development
> of the core tools (map/par etc.) is faster than on Solaris and not as
> reboot-prone as on Windows. The reason for the non-availability on the
IIRC this was the case with Design Acceleration as well (before they
were acquired by Cadence), they used Linux as an internal development
tool to develop Solaris, HP and IBM binaries. After a while they
released the Linux/x86 version too.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 28399On Wed, 10 Jan 2001 12:23:26 -0800, Dennis McCrohan <mccrohan@xilinx.com> wrote: <snipped> I hate to say it, but I agree. On the other hand, if you released Red Hat tools, and specified that anyone who messed around with their kernels/libs/whatever was on their own, then I'd dump Debian today and install RH. And even if you released an unsupported Linux version, I'd probably still use it. Evan
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