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
peterc wrote: > > Is there a DOS based download program with the new tools (I guess I could > > use the old XCHECKER???), or do I have to convert all the 486/16M/120M DOS > > notebooks we use in the lab for downloading over to CD based (NT only comes > > on CD) NT machines??? > > It can be run under 95 according to Xilinx (but I've not tried). works just fine under 95. Ver 1.4 had a bug that required downloading the patch from xilinx. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 13226
I have been having the same problem while doing functional sim with Foundation 1.5. I called the Xilinx support line and sent them a copy of what I was working on. It worked fine for them! They had no explanation for my problem, and it's still a problem. I my case, some levels of the hierarchy could be probed and others could not. For example, once I could probe the top sheet, but not the sheet below that. I could, however, probe a sheet three levels down. Later, without doing anything obvious, I was able to probe level 2 sheets, but not the top sheet. Anyone else get any help on this? jdehaven@my-dejanews.com wrote in message <728v8e$voo$1@nnrp1.dejanews.com>... >Joel, Are you doing a functional or a timing simulation in Foundation 1.5? >The behaviour you are describing is to be expected at times when running a >timing simulation. The reason is that many of the nodes in the schematic get >absorbed into look-up-tables in the Xilinx CLBs. So... when you place a >probe on such a net, the simulator cannot find that node in it's netlist >(which is a back-annotated timing netlist from the Xilinx tool). Follow the >net back to a flop or pad (or forward to a flop or pad), and see if placing a >probe at those points work better. > >If you need to do a functional simulation, and you haven't edited (saved) the >top level of the schematic since the last place and route, you will probably >have to manually load the .alb netlist in the simulator. > >Good luck, >John >-- >John DeHaven >Insight Electronics >Xilinx-Dedicated Senior FAE >PH: (503)644-3300 > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 13227
1. Did you run timing simulation, do you have a reset or start-up
block to initialise your state machines.
2. Your vectors do they reflect real world ?
3. Your FPGA's is it configured properly ?
rjs wrote in message <36550AD0.1728AFBC@home.com>...
>Sounds like you have some serious problems. Some ideas:
>
>1. Check your timing. That fact that raising voltage to the part
>makes it
>work sounds like you're on the hairy edge timing-wise. Learn how
>to use
>trace to run useful reports and make sure you've got all your
>paths covered.
>2. If you're using HDL design entry read the Xilinx map and par
>reports
>to make sure critical logic is not getting ripped out. Code that
>simulates
>fine can sometimes synthesize to garbage. Read the trimming
>reports carefully
>and try to account for everything. Also look at CLB and FF usage
>and make
>sure it makes sense.
>3. Make sure your global reset was implemented correctly and that
>your clocks were
>routed using global buffers.
>4. Make sure you don't use the JTAG pins for general-purpose I/O.
>Prohibit these
>in your UCF file and terminate them on the board.
>
>I've never seen a Xilinx FPGA design that simulated correctly and
>met
>timing (assuming it was properly constrained) that did not work in
>the system.
>If it doesn't work then 99.99% of the time it's your fault, not
>the part or
>the tools.
>
>If you're so sold on Altera then why the change? Sometimes it's
>better to stay
>with what you know and love.
>
>Good luck. Give us a post when you figure it out.
>
>RJS
>
>
>"John J. Hovey" wrote:
>>
>> Hello anybody and everybody!
>>
>> I have been working on a complex host/daughter card system for
the PCI
>> bus which is using a total of 5 Xilinx FPGA's along with a host of other
>> components. We chose the XL series of the 4000 architecture for the
>> extended RAM features and Versa-ring routing. As it happened the
>> smaller devices of the family are only available in the low voltage XL
>> versions.
>> Now that I have been attempting to implement the designs I am
finding
>> major problems with designs that are logically correct but do not
>> function as expected in the real world. These designs pass the timing
>> constraints I'm using but do not function at all or stop in the middle
>> of processing loops. At times the state machines hold in an apparent
>> meta-stable state.
>> I have found conditions where active signals associated with
completely
>> separate logic functions effect the operation of state machines in the
>> same device.
>> I have also found a condition where the logic will function only
if the
>> 3.3 VDC supply to the Xilinx devices is raised to 3.52 VDC, and not
>> below.
>> Is anyone experiencing the same type of problems with this or any
other
>> device family from Xilinx.
>>
>> P.S.
>>
>> Long live Altera!!
>>
>> John J. Hovey
>> ARL: University of Texas
>
>--
>
>---------------------------
> real addr:
> rsefton_@_home.com
> (remove the underscores)
>---------------------------
Article: 13228
COMSOL is celebrating 20 years of selling the best microprocessor
development tools in the UK.
Every 20th _UK_ microprocessor developer who visits our web site will
get a free bottle of champagne.
So to join us in a bottle of bubbly or to find out about the widest
range of development tools go to
www.computer-solutions.co.uk
COMSOLS's embedded microprocessor developers web site includes details
of tools for over 80 CPU families and for most information on:-
In-circuit emulators
Super fast Ethernet BDM Emulators
Assemblers
C & C++ compilers
Real-time executives for most micros
Embedded TCP/IP, Web Server and Browser
Embedded DOS & W95 Compatible file system
Software simulators
186-486 linkers
Remote debuggers
Flash and EPROM Emulators
EPROM-PAL-GAL-micro programmers
GANG programmers
CASE tools
Forth systems from chips to Windows
RS232 Debuggers
PC instruments (Logic Analysers & DSOs)
Regards, Chris
-----------------------------
Chris Stephens E-mail: sales@computer-solutions.co.uk
Computer Solutions Ltd. Phone & Fax: +44 (0)1 932 829 460
1a New Haw Road, Addlestone,
Surrey, KT15 2BZ England http://www.Computer-Solutions.co.uk
For the largest range of embedded microprocessor development tools in the UK
Article: 13229> 4. Make sure you don't use the JTAG pins for general-purpose I/O. Why? AustinArticle: 13230
> So, what will happen with Coregen ? Xilinx will support EDIF only, AFAIK. UtkuArticle: 13231
This sounds to me like it could be a metastabilty problem. Make sure all inputs are synchronized with double-sychronizers. John J. Hovey wrote in message <3654A445.68D25580@arlut.utexas.edu>... >Hello anybody and everybody! > > I have been working on a complex host/daughter card system for the PCI >bus which is using a total of 5 Xilinx FPGA's along with a host of other >components. We chose the XL series of the 4000 architecture for the >extended RAM features and Versa-ring routing. As it happened the >smaller devices of the family are only available in the low voltage XL >versions. > Now that I have been attempting to implement the designs I am finding >major problems with designs that are logically correct but do not >function as expected in the real world. These designs pass the timing >constraints I'm using but do not function at all or stop in the middle >of processing loops. At times the state machines hold in an apparent >meta-stable state. > I have found conditions where active signals associated with completely >separate logic functions effect the operation of state machines in the >same device. > I have also found a condition where the logic will function only if the >3.3 VDC supply to the Xilinx devices is raised to 3.52 VDC, and not >below. > Is anyone experiencing the same type of problems with this or any other >device family from Xilinx. > >P.S. > >Long live Altera!! > >John J. Hovey >ARL: University of TexasArticle: 13232
In article <72ki6t$tfd$1@news00.btx.dtag.de>, Hlebasko@t-online.de wrote: > I am looking for information for some low cost FPGA development tools for > learning. I am trying to improve my "skill set" on my own and I can't > afford multiple thousand dollar tool sets. > > Thanks. > > Joseph Hlebasko > > Atmel is currently offering their FPGA tool suite for free including a VHDL and verilog synthesis tool, floorplanner, place and route tool and a macrogenerator that will write corresponding VHDL modules. Visit http://www.atmel.com and sign up for one today. Russ VerNooy -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 13233
The following is from the Xilinx answers database on their website: -------------------------------------------------------------------- Record #239 Problem Title: BOUNDARY SCAN/JTAG: Preventing inadvertent activation of boundary scan in XC4K/XC5K devices Problem Description: Keywords: inadvertent, activation, bounday scan, jtag, xc4000, xc5200, tck, tms, pullup, test logic reset Urgency: Standard General Description: How to prevent inadvertent activation of boundary scan? Solution 1: When a XC4K/XC5K device powers up, ideally the TAP controller is in the Test-Logic-Reset state. For various reasons, a situation may occur where the TMS and TCK pins of the TAP may toggle forcing the TAP controller out of the Test-Logic-Reset state. This will cause the device to go in to the Boundary Scan mode. If this happens during configuration, it may disrupt the configuration process. The TMS and TCK pins of the device must be pulled up high before powerup to prevent inadvertent activation of boundary scan. End of Record #239 -------------------------------------------------------------------- I was also advised by a Xilinx FAE to not use these pins for general-purpose I/O if possible. If you can guarantee the startup state of the pins then it's not a problem, but I choose not to mess with it if I can spare the pins. RJS Austin Franklin wrote: > > > 4. Make sure you don't use the JTAG pins for general-purpose I/O. > > Why? > > Austin -- --------------------------- real addr: rsefton_@_home.com (remove the underscores) ---------------------------Article: 13234
Maybe I am missing something, but how can you tell if your are heading into a full vs. empty state just from knowing which quadrant each pointer is in? They can both be in the same quadrant and you still don't know whether entering the A = B state is full or empty! It appears to me that you need to do an arithmetic compare for A < B vs A > B, plus this must be a modulo compare! In other words, you need to subtract A - B and then test the MSB of the result. Am I missing something??? Or are we talking about two different situations. I am assuming you are talking about a FIFO of size 2**n with the same number of memory locations. Ray Andraka wrote: > > Depends on the size of the fifo. For a 16 deep fifo, you can use a pair of 2 bit gray > counters for each pointer. The top one indicates which quadrant of the fifo the pointer > is in, the bottom points to one of the four entries. The top halves of the two pointers > feed one 4 lut to do the gross compare. Since the counters are gray coded, you don't have > the multi-bit race problem. This works great for a 16 deep fifo. Bigger than that, and > you get into more complexity. In that case, I suppose the cost of an extra word becomes a > smaller percentage of the fifo so it may not be so bad. I don't often have a need for an > async fifo deeper than 16 entries in an FPGA. > > Rickman wrote: > > > Ray Andraka wrote: > > > > > > That flip flop doesn't have to be set/reset on the transition to the equal state. > > > It can be set/reset based on a gross comparison of the read and write counters. The > > > trick is if the fifo is more than half full, it will be full when the pointers > > > become equal unless it first becomes less than half full and vice-versa. Where I > > > work in schematics, I don't have a synthesizable version of this. > > > > > > Johnny Smooth wrote: > > > > > > > Ray Andraka wrote in message <3652DA19.BD7F31CE@ids.net>... > > > > >Not so smooth there Johnny, > > > > > > > > > >You don't need storage for N+1 words for an N deep fifo. Read=Write means > > > > either > > > > >empty or full. The direction this condition was entered from differentiates > > > > the > > > > >two conditions. This uses an extra flip-flop in the control logic, but has the > > > > > > > > And what might you clock it with? That little flipflop is the problem. Because > > > > the > > > > two interfaces are asynchronous AND the flags must be valid AT ALL TIMES, > > > > there is really no good safe way to know what the last op was. Have you tried > > > > I believe your original objection to Johnny's method was that he was > > using an arithmetic compare in order to set the full/empty flags (in > > addition to wasting one location of memory). But your "gross comparison" > > will require an arithmetic compare of the two pointers, no? I think that > > Johnny may be right about a simpler circuit. When the two clocks are > > asynchronous, you can never make an assumption about when the output of > > both counters are stable. So the arithmetic compare would be very > > difficult. On the other hand, a gray coded counter could be examined for > > equality without worring about races. With only a single bit changing, > > you will either see the old value or the new value. > > > > I believe Johnny needed a compare of A+1 = B. This can be done by using > > the D inputs to the A counter FFs since the D inputs will always have > > the next value on them (A+1). So this also becomes an equality compare. > > > > So then the only problem is the metastability issue. Of course the best > > way to handle this is to synchronize one of the inputs to the clock of > > the other and run the entire FIFO from that clock. That is what I did in > > my last design. But I am sure that is not an available solution in many > > cases. > > > > -- > > > > Rick Collins > > > > redsp@XYusa.net > > > > remove the XY to email me. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13235
Jamie Lokier wrote: > > Rickman <spamgoeshere4@yahoo.com> writes: > > I believe Johnny needed a compare of A+1 = B. This can be done by using > > the D inputs to the A counter FFs since the D inputs will always have > > the next value on them (A+1). So this also becomes an equality > > compare. > > Is this in A's clock domain or B's clock domain? If B's, the D inputs > to A's FFs won't satisfy the "off by one at most" property because > they're stabilising between clocks. > > -- Jamie I don't think this affects the situation since the counters are gray coded. So there will only be a single bit changing when the A + 1 value is stabilizing. So you either catch it at the value A or you catch it at the value A + 1. By definition, the A and B counts are in different clock domains. But with a single bit changing you will not have a race condition and you only need to deal with metastability. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13236
> The TMS and TCK pins of the device must be pulled up high before > powerup to prevent inadvertent activation of boundary scan. I've never seen this condition in thousands of chips, obviously, it has been seen by 'someone'. I don't think the answer is to 'avoid' these pins. Avoiding them for I/O isn't going to prevent this from happening, as floating pins can do the same... but to do what's suggested above, and, providing your I/O on these pins can handle pullups, you will be fine. AustinArticle: 13237
Hi, I'm looking for a tool that allows me to do functional simulation on 9500 CPLD designs done in Orcad Capture (schematics). What is the least expensive tool to do the job? Thanx, Klaus -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 13238
Austin - Unless you need to use 100% of the available I/O, what's the problem with prohibiting two pins and pulling them up on the board? If you use these as inputs and the driver of one of these signals (regardless of the pullup) toggles the pin during configuration you're likely to have problems. What does it matter if you've seen it happen? Why would you chance it? Do you think the manufacturer likes to advertise that two of its I/O are basically unusable as inputs? I take them at their word because it's not worth worrying about it. Just run these pins to a test header and use them for debug. I'm not preaching the Xilinx gospel here, it just doesn't make sense to question EVERYTHING! Warm regards, Bob S. Austin Franklin wrote: > > > The TMS and TCK pins of the device must be pulled up high before > > powerup to prevent inadvertent activation of boundary scan. > > I've never seen this condition in thousands of chips, obviously, it has > been seen by 'someone'. I don't think the answer is to 'avoid' these pins. > Avoiding them for I/O isn't going to prevent this from happening, as > floating pins can do the same... but to do what's suggested above, and, > providing your I/O on these pins can handle pullups, you will be fine. > > Austin -- --------------------------- real addr: rsefton_@_home.com (remove the underscores) ---------------------------Article: 13239
> Unless you need to use 100% of the available I/O, what's the > problem with prohibiting two pins and pulling them up on the > board? Because if you have a 32 bit bus on the left edge of the die, and you move two of the pins in the middle of this bus, which doesn't keep them contiguous, you change the timing on the pins that move, and what once was perfect timing, because the I/O pins lined up perfectly with the internal 32 bit tri-state bus, now requires faster more expensive parts to do the same function. Two resistors an a little thought, I believe, is not really a big deal. > If you use these as inputs and the driver of one of these > signals (regardless of the pullup) toggles the pin during > configuration you're likely to have problems. Well, then, don't drive these signals during configuration then ;-) > What does it matter > if you've seen it happen? Why would you chance it? Do you think > the manufacturer likes to advertise that two of its I/O are > basically unusable as inputs? I take them at their word because > it's not worth worrying about it. Just run these pins to a test > header and use them for debug. I haven't seen it, because I engineered my boards to not have this problem. I don't have to not use these two pins, and they are fully usable, I've always provided the two pullups. I treat them just like the configuration pins, you have to hook them up appropriately. I just don't see this as a problem that a little fore-thought can't remedy. > I'm not preaching the Xilinx gospel here, it just doesn't make > sense to question EVERYTHING! Actually, I don't take things as just black magic. I believe the better understanding I have of how the parts behave, their architecture, and how to use their architecture, allows me to make a more reliable and higher performance product in slower/cheaper parts, and in shorter time. That's just how I look at it. Doesn't mean everyone has to look at it that way. AustinArticle: 13240
What's the big deal. As long as you either keep TMS high (keeping the JTAG controller in the reset state) or keep from toggling TCK (keep it high or keep it low) during configuration, there is nothing to worry about. Note, you only have to satisfy one of these to keep it from going JTAG on you. It should be pretty easy to do as long as you don't have both pins on an active bus. rjs wrote: > Austin - > > Unless you need to use 100% of the available I/O, what's the > problem with prohibiting two pins and pulling them up on the > board? If you use these as inputs and the driver of one of these > signals (regardless of the pullup) toggles the pin during > configuration you're likely to have problems. What does it matter > if you've seen it happen? Why would you chance it? Do you think > the manufacturer likes to advertise that two of its I/O are > basically unusable as inputs? I take them at their word because > it's not worth worrying about it. Just run these pins to a test > header and use them for debug. > > I'm not preaching the Xilinx gospel here, it just doesn't make > sense to question EVERYTHING! > > Warm regards, > > Bob S. > > Austin Franklin wrote: > > > > > The TMS and TCK pins of the device must be pulled up high before > > > powerup to prevent inadvertent activation of boundary scan. > > > > I've never seen this condition in thousands of chips, obviously, it has > > been seen by 'someone'. I don't think the answer is to 'avoid' these pins. > > Avoiding them for I/O isn't going to prevent this from happening, as > > floating pins can do the same... but to do what's suggested above, and, > > providing your I/O on these pins can handle pullups, you will be fine. > > > > Austin > > -- > > --------------------------- > real addr: > rsefton_@_home.com > (remove the underscores) > --------------------------- -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 13241
only if they are in the same quadrant do you get a full or empty. You need to look at which quadrant the read pointer is relative to the write pointer. If the read pointer quadrant was one quadrant ahead of the write pointer quadrant more recently than it was one quadrant behind the write pointer quadrant, then when the pointers are equal the fifo is full, otherwise it is empty. Now remember, i said the pointers were made up of a pair of 2 bit gray counters, so only one bit is changing at a time on the quadrant portion of the count. The comparison between the quadrants sets the auxiliary FF when the read pointer is in the quadrant ahead of the write pointer quadrant; resets that FF when the read pointer is in the quadrant behind the write pointer's quadrant, and leaves that FF alone otherwise. The result is that the set and reset of the direction FF are separated by an extra read or write, and that the full does not happen at the same time the direction flop is changing state. It sounds a lot more complicated than it is. Rickman wrote: > Maybe I am missing something, but how can you tell if your are heading > into a full vs. empty state just from knowing which quadrant each > pointer is in? They can both be in the same quadrant and you still don't > know whether entering the A = B state is full or empty! > > It appears to me that you need to do an arithmetic compare for A < B vs > A > B, plus this must be a modulo compare! In other words, you need to > subtract A - B and then test the MSB of the result. > > Am I missing something??? Or are we talking about two different > situations. I am assuming you are talking about a FIFO of size 2**n with > the same number of memory locations. > > Ray Andraka wrote: > > > > Depends on the size of the fifo. For a 16 deep fifo, you can use a pair of 2 bit gray > > counters for each pointer. The top one indicates which quadrant of the fifo the pointer > > is in, the bottom points to one of the four entries. The top halves of the two pointers > > feed one 4 lut to do the gross compare. Since the counters are gray coded, you don't have > > the multi-bit race problem. This works great for a 16 deep fifo. Bigger than that, and > > you get into more complexity. In that case, I suppose the cost of an extra word becomes a > > smaller percentage of the fifo so it may not be so bad. I don't often have a need for an > > async fifo deeper than 16 entries in an FPGA. > > > > Rickman wrote: > > > > > Ray Andraka wrote: > > > > > > > > That flip flop doesn't have to be set/reset on the transition to the equal state. > > > > It can be set/reset based on a gross comparison of the read and write counters. The > > > > trick is if the fifo is more than half full, it will be full when the pointers > > > > become equal unless it first becomes less than half full and vice-versa. Where I > > > > work in schematics, I don't have a synthesizable version of this. > > > > > > > > Johnny Smooth wrote: > > > > > > > > > Ray Andraka wrote in message <3652DA19.BD7F31CE@ids.net>... > > > > > >Not so smooth there Johnny, > > > > > > > > > > > >You don't need storage for N+1 words for an N deep fifo. Read=Write means > > > > > either > > > > > >empty or full. The direction this condition was entered from differentiates > > > > > the > > > > > >two conditions. This uses an extra flip-flop in the control logic, but has the > > > > > > > > > > And what might you clock it with? That little flipflop is the problem. Because > > > > > the > > > > > two interfaces are asynchronous AND the flags must be valid AT ALL TIMES, > > > > > there is really no good safe way to know what the last op was. Have you tried > > > > > > I believe your original objection to Johnny's method was that he was > > > using an arithmetic compare in order to set the full/empty flags (in > > > addition to wasting one location of memory). But your "gross comparison" > > > will require an arithmetic compare of the two pointers, no? I think that > > > Johnny may be right about a simpler circuit. When the two clocks are > > > asynchronous, you can never make an assumption about when the output of > > > both counters are stable. So the arithmetic compare would be very > > > difficult. On the other hand, a gray coded counter could be examined for > > > equality without worring about races. With only a single bit changing, > > > you will either see the old value or the new value. > > > > > > I believe Johnny needed a compare of A+1 = B. This can be done by using > > > the D inputs to the A counter FFs since the D inputs will always have > > > the next value on them (A+1). So this also becomes an equality compare. > > > > > > So then the only problem is the metastability issue. Of course the best > > > way to handle this is to synchronize one of the inputs to the clock of > > > the other and run the entire FIFO from that clock. That is what I did in > > > my last design. But I am sure that is not an available solution in many > > > cases. > > > > > > -- > > > > > > Rick Collins > > > > > > redsp@XYusa.net > > > > > > remove the XY to email me. > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > -- > > Rick Collins > > redsp@XYusa.net > > remove the XY to email me. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 13242
The main problem with Big Endian AND Little Endian formats is that there are two of them (actually, when you consider all the byte, short, word, double-word, ... data and address permutations and the associated hardware screwups introduced by almost every new device, there are many many more than two)!!! Literally millions of man-hours of useless and frustrating debugging time could have been saved in the past, present, and very unfortunately, the future if we could all just get along. This is only partially humorous and only in retrospect. [Getting off the comfy couch] Thanks for listening, Doc ... how much will that be today ... -- Alex I. Leyn, P.Eng. [aleyn@coreal.com, aleyn@pixstream.com]Article: 13243
> I haven't seen it, because I engineered my boards to not have this problem. > I don't have to not use these two pins, and they are fully usable, I've > always provided the two pullups. I treat them just like the configuration > pins, you have to hook them up appropriately. I just don't see this as a > problem that a little fore-thought can't remedy. It's not a difficult problem to understand or work around (usually). My point is just that if you can afford to not use the pins then it's not worth ANY time or thought to find a workaround. Same goes for the configuration pins. If you need the pins then you have to deal with it. This one has now been beat to death. Thanks for the exchange. Bob S. -- --------------------------- real addr: rsefton_@_home.com (remove the underscores) ---------------------------Article: 13244
Ken, What do you mean by a double-synchronizer? Are you simply saying that all asynchronous inputs should have a 2 stage latch? -jjh Ken Coffman wrote: > This sounds to me like it could be a metastabilty problem. Make sure all > inputs are synchronized with double-sychronizers. > > John J. Hovey wrote in message <3654A445.68D25580@arlut.utexas.edu>... > >Hello anybody and everybody! > > > > I have been working on a complex host/daughter card system for the PCI > >bus which is using a total of 5 Xilinx FPGA's along with a host of other > >components. We chose the XL series of the 4000 architecture for the > >extended RAM features and Versa-ring routing. As it happened the > >smaller devices of the family are only available in the low voltage XL > >versions. > > Now that I have been attempting to implement the designs I am finding > >major problems with designs that are logically correct but do not > >function as expected in the real world. These designs pass the timing > >constraints I'm using but do not function at all or stop in the middle > >of processing loops. At times the state machines hold in an apparent > >meta-stable state. > > I have found conditions where active signals associated with completely > >separate logic functions effect the operation of state machines in the > >same device. > > I have also found a condition where the logic will function only if the > >3.3 VDC supply to the Xilinx devices is raised to 3.52 VDC, and not > >below. > > Is anyone experiencing the same type of problems with this or any other > >device family from Xilinx. > > > >P.S. > > > >Long live Altera!! > > > >John J. Hovey > >ARL: University of TexasArticle: 13245
The design, at certain stages, has been functionally simulated and works. As
I said, the state machine runs correctly for a while and then either just stops
or gets caught in what appears to be a meta-stable state where some of the
outputs within the loop are active and some are frozen.
The design entry is a Foundation schematic entry while the state machines are
HDL code generated by the state editor. The code generated appears to be
correct.
As to timing, I'm simply using period constraints with input pads to clock
groups/clock group to output pads.
Am I being too simplistic with my contraints? Do I need to explicitly
constrain all elements of the design?
-jjh
Austin Franklin wrote:
> > Now that I have been attempting to implement the designs I am finding
> > major problems with designs that are logically correct but do not
> > function as expected in the real world. These designs pass the timing
> > constraints I'm using but do not function at all or stop in the middle
> > of processing loops. At times the state machines hold in an apparent
> > meta-stable state.
>
> Did you do functional simulation to verify that your design works in the
> first place?
>
> What front end are you using (an HDL or schematic)?
>
> It sounds to me like you have two possible problems. First, if you are
> using an HDL, the HDL may not be giving you the results you believe you
> 'should' be getting. This can be either to wrong code, or erroneous HDL
> compilation. Secondly, sounds like you have timing problems, dispite your
> belief you make timing. Are you sure you have ALL your timing paths
> specified, and did you verify that all the paths are correct?
>
> Austin Franklin
> darkroom@ix.netcom.com
Article: 13246
rjs,
I'll admit I'm not as fluent with trace as I'd like to be. However from what I
can see, the timing paths are covered by the period constraints. There are so many
paths that should be covered it's hard to see how I can ever find a path that was
missed by the par timing analyzer.
I continue to examine the map reports and have not seen anything removed that
shouldn't be. There are certain things that get ripped out because I dropped the use
of the signal or specified an output in a logi-blox component, but didn't use it.
Should I be more careful about unused logic and/or should I deselect the par
control to not trim unsed logic?
The JTAG pins for all devices are not used for general I/O. I have provided a
dedicated JTAG chain. Are you suggesting that 1 or more devices might be entering a
BSCAN mode trapping the device within a loop?
Also what do "you" mean by a global reset implemented correctly?
Thanks for the input,
-jjh
rjs wrote:
> Sounds like you have some serious problems. Some ideas:
>
> 1. Check your timing. That fact that raising voltage to the part
> makes it
> work sounds like you're on the hairy edge timing-wise. Learn how
> to use
> trace to run useful reports and make sure you've got all your
> paths covered.
> 2. If you're using HDL design entry read the Xilinx map and par
> reports
> to make sure critical logic is not getting ripped out. Code that
> simulates
> fine can sometimes synthesize to garbage. Read the trimming
> reports carefully
> and try to account for everything. Also look at CLB and FF usage
> and make
> sure it makes sense.
> 3. Make sure your global reset was implemented correctly and that
> your clocks were
> routed using global buffers.
> 4. Make sure you don't use the JTAG pins for general-purpose I/O.
> Prohibit these
> in your UCF file and terminate them on the board.
>
> I've never seen a Xilinx FPGA design that simulated correctly and
> met
> timing (assuming it was properly constrained) that did not work in
> the system.
> If it doesn't work then 99.99% of the time it's your fault, not
> the part or
> the tools.
>
> If you're so sold on Altera then why the change? Sometimes it's
> better to stay
> with what you know and love.
>
> Good luck. Give us a post when you figure it out.
>
> RJS
>
> "John J. Hovey" wrote:
> >
> > Hello anybody and everybody!
> >
> > I have been working on a complex host/daughter card system for the PCI
> > bus which is using a total of 5 Xilinx FPGA's along with a host of other
> > components. We chose the XL series of the 4000 architecture for the
> > extended RAM features and Versa-ring routing. As it happened the
> > smaller devices of the family are only available in the low voltage XL
> > versions.
> > Now that I have been attempting to implement the designs I am finding
> > major problems with designs that are logically correct but do not
> > function as expected in the real world. These designs pass the timing
> > constraints I'm using but do not function at all or stop in the middle
> > of processing loops. At times the state machines hold in an apparent
> > meta-stable state.
> > I have found conditions where active signals associated with completely
> > separate logic functions effect the operation of state machines in the
> > same device.
> > I have also found a condition where the logic will function only if the
> > 3.3 VDC supply to the Xilinx devices is raised to 3.52 VDC, and not
> > below.
> > Is anyone experiencing the same type of problems with this or any other
> > device family from Xilinx.
> >
> > P.S.
> >
> > Long live Altera!!
> >
> > John J. Hovey
> > ARL: University of Texas
>
> --
>
> ---------------------------
> real addr:
> rsefton_@_home.com
> (remove the underscores)
> ---------------------------
Article: 13247
Steve,
I'm not using the Xilinx devices for the PCI interface. Back when the
concept was being dreamed up, neither Xilinx or Altera were close to a no
wait-state PCI solution. We were looking at several solutions and ultimately
decided on PLX Technology and the PCI9080 device which is 3.3/5 V PCI
compliant. Besides, with all the features of this device most of the work to
get the 80 MByte/s data off the card was already in place.
-jjh
Steve wrote:
> I assume the the PCI pins are in fast slew rate mode. Which package are you
> using, is it 32 or 64 bit PCI, and have you spaced out the PCI pins to limit
> ground bounce? I believe the standard Xilinx designs all do this.
>
> For testing purposes you might consider putting the PCI bus in slow slew
> rate
> mode. You don't have much chance of meeting timing, but if you are having
> ground bounce problems they should disappear.
>
> Are you running 3.3 or 5V PCI? If 3.3V you need to supply clamping diodes,
> and if you turn on the internal ones you lose your 5V tolerance.
>
> Steve
Article: 13248On Sat, 21 Nov 1998 09:56:14 -0600, john hovey <hovey@arlut.utexas.edu> wrote: > The design, at certain stages, has been functionally simulated and works. As >I said, the state machine runs correctly for a while and then either just stops >or gets caught in what appears to be a meta-stable state where some of the >outputs within the loop are active and some are frozen. > The design entry is a Foundation schematic entry while the state machines are >HDL code generated by the state editor. The code generated appears to be >correct. > As to timing, I'm simply using period constraints with input pads to clock >groups/clock group to output pads. > Am I being too simplistic with my contraints? Do I need to explicitly >constrain all elements of the design? >-jjh Does it run at half speed? If not, there's not much use worrying about the fine details of timing constraints... - BrianArticle: 13249
I thought people here might be interested in this, as we have discussed
this previously:
Digital Millennium Copyright Act of 1998 (S.2037)
On October 28, 1998, President Clinton signed the Digital Millennium
Copyright Act of 1998. It went into effect that day. This act amends the
U.S. Copyright Act to add a new chapter 12 -- Copyright Protection and
Management Systems. This chapter contains five provisions:
1201.Circumvention of copyright protection systems
1202.Integrity of copyright management information
1203.Civil remedies
1204.Criminal offenses and penalties
1205.Savings Clause
1201. Circumvention of copyright protection systems
(a) Violations Regarding Circumvention of Technological Protection
Measures. --
(1) No person shall circumvent a technological protection measure that
effectively controls access to a work protected under this title.
(2) No person shall manufacture, import, offer to the public, provide,
or otherwise traffic in any technology, product, service, device,
component, or part thereof, that --
(A) is primarily designed or produced for the purpose of
circumventing
a technological protection measure that effectively controls
access
to a work protected under this title;
(B) has only limited commercially significant purpose or use other
than
to circumvent a technological protection measure that
effectively
controls access to a work protected under this title; or
(C) is marketed by that person or another acting in concert with
that
person's knowledge for use in circumventing a technological
protection measure that effectively controls access to a work
protected under this title.
(3) As used in this subsection --
(A) to 'circumvent a technological protection measure' means to
descramble a scrambled work, to decrypt an encrypted work, or
otherwise to avoid, bypass, remove, deactivate, or impair a
technological protection measure, without the authority of the
copyright owner; and
(B) a technological protection measure 'effectively controls access
to
a work' if the measure, in the ordinary course of its operation,
requires the application of information, or a process or a
treatment, with the authority of the copyright owner, to gain
access to the work.
(b) Additional Violations. --
(1) No person shall manufacture, import, offer to the public, provide,
or otherwise traffic in any technology, product, service, device,
component, or part thereof, that --
(A) is primarily designed or produced for the purpose of
circumventing
protection afforded by a technological protection measure that
effectively protects a right of a copyright owner under this
title
in a work or a portion thereof;
(B) has only limited commercially significant purpose or use other
than
to circumvent protection afforded by a technological protection
measure that effectively protects a right of a copyright owner
under
this title in a work or a portion thereof; or
(C) is marketed by that person or another acting in concert with
that
person's knowledge for use in circumventing protection afforded
by
a technological protection measure that effectively protects a
right
of a copyright owner under this title in a work or a portion
thereof.
(2) As used in this subsection --
(A) to 'circumvent protection afforded by a technological protection
measure' means avoiding, bypassing, removing, deactivating, or
otherwise impairing a technological protection measure; and
(B) a technological protection measure 'effectively protects a right
of a copyright owner under this title' if the measure, in the
ordinary course of its operation, prevents, restricts, or
otherwise limits the exercise of a right of a copyright owner
under this title.
(c) Other Rights, Etc., Not Affected. --
(1) Nothing in this section shall affect rights, remedies,
limitations,
or defenses to copyright infringement, including fair use, under
this
title.
(2) Nothing in this section shall enlarge or diminish vicarious or
contributory liability for copyright infringement in connection
with
any technology, product, service, device, component or part
thereof.
(3) Nothing in this section shall require that the design of, or
design
and selection of parts and components for, a consumer electronics,
telecommunications, or computing product provide for a response to
any particular technological protection measure, so long as such
part
or component or the product, in which such part or component is
integrated, does not otherwise fall within the prohibitions of
subsection (a)(2) or (b)(1).
You can find the complete Digital Millennium Copyright Act of 1998. on the
web at http://thomas.loc.gov.
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