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
There are a number of vendors selling PCI solutions. However, they will all be considerably more expensive than a netlist solution from Xilinx. Any silicon vendor can make I.P. netlists available at what is essentially a subsidised price as they will gain from the future locked-in silicon revenue. An I.P. vendor has no such luxury. If development cost is the primary limiter, then a ASSP product from the usual PCI suspects would be best. Cheers Stuart On Fri, 11 Aug 2000 04:37:09 GMT, "Dan" <daniel.deconinck@sympatico.ca> wrote: >I realize Xilinx sells a PCI core but it is way too pricey for a self >employed person such as myself. > >Does anyone know of somesone selling a PCI interface design ? For Email remove "NOSPAM" from the addressArticle: 24551
Dan wrote: > > Hello <snip> > The TTL inputs are noisy. I am interfacing the V50 to a SAA7110 Philips > video ADC. > > By touching (with my hand) the input trace & pins I am able to get a clean > input. But I can not be shipped with the product. Do you mean Visible Noise, or Functional Noise ? Visible noise is 'fur' on the waveforms above the TTL High threshold. It is quite common in logic systems, can be alarming in amplitude and appearance, and will 'clean up' with a 'finger test'. Because this noise is above the TTL high, it does not affect functional operation. Functional noise is inside the TTL limits band, and is usually ground related ( where the margins are lower ), or edge related ( eg slow edges causing oscillations ) -jgArticle: 24552
Hi Philip, Thanks for your input. (and laughs) The spec says the IO is LVTTL. Would LVTTL be compatible with 74LS... series logic chips and would LVTTL be compatible with the ISA bus ?? DanArticle: 24553
Hi Jim, I put the pin on the scope and the signal looks clean. The signal is a vertical sync pulse from a NTSC video ADC. This is a 60HZ cycle going high 2% of the cycle. The Virtex50 randomly sees more high transitions. I just wonder if the Virtex pasrt inherently does a poor job with 5V TTL. Sincerely. Daniel DeConinckArticle: 24554
Dan wrote: > > Hi Jim, > > I put the pin on the scope and the signal looks clean. > > The signal is a vertical sync pulse from a NTSC video ADC. This is a 60HZ > cycle going high 2% of the cycle. The Virtex50 randomly sees more high > transitions. > > I just wonder if the Virtex part inherently does a poor job with 5V TTL. The newer FPGAs are both faster, and lower voltage, so they could easily find a problem that was tolerated before. With this type of problem, a usefull trick is to get the FPGA to toggle on the SYNC pulse, and drive a pin. This will show if the extra counts are all edge related ( multiple clocking) or occur at other times ( gnd or system noise immunity issue ). Check the exact threshold specs fo the IO you have chosen, and consider a resistive PAD to interface the ADC - FPGA, and if that fails, there is always the tiny logic schmitt buffers ... -jgArticle: 24555
Hi all, I would like test the the SelectMAP With Capture using Virtex. But what is the WS pin on the Multilinx cable from Xilinx? Where do I need to connect this wire ? (to a IO or ?) Thank you for your comments. LaurentArticle: 24556
Hi Jim, The noise occurs at other times ( gnd or system noise immunity issue ). I think my Virtex may be damaged. I may have another board assembled. Sincerely Daniel DeConinckArticle: 24557
rickman wrote: > A "Gray" coded FSM would use 5 bits to > encode 20 states. Each transistion in your state diagram (including the > "stay in this state" transistions) would require the full state vector > to be decoded. This may have required a lot of logic if you have a lot > of transistions. > > I don't think this would produce so many gates that you could not have > built the FSM, but I think "Gray" coding would require a lot more gates > than straight binary. I will have to think about that a bit. > I don't understand how "Gray encoding" would work in a general-purpose state machine. Gray means ( to me at least ) that only one bit changes on any transition. That works very nicely in a counter, which is a specialized state machine with only one "next state" for every state. ( Well, two for an up-down counter ) But it is inherently impossibel to have a single-bit change in a state machine where, depending on control inputs, the code might jump in many ways. So, what's the meaning of a "Gray-encoded" state machine? Peter AlfkeArticle: 24558
On Sun, 13 Aug 2000 21:46:07 GMT, "Dan" <daniel.deconinck@sympatico.ca> wrote: >Hi Jim, >The noise occurs at other times ( gnd or system noise immunity issue ). >I think my Virtex may be damaged. I may have another board assembled. >Sincerely >Daniel DeConinck Before replacing the FPGA (which is usually a pain) consider some more debug. First, although it does happen, the FPGA is probably fine. I would look carefully at the ground and VCC connections, they must all be connected, and lots of decoupling capacitors. A simple test may be to rout the input to another pin, and see if you have the same problem. I also agree with Jim's suggestion of routing it to a flipflop, to see when transitions are seen. Try and correlate that with other things happening in the system, such as a bus being driven/released, DRAM refresh, ..... Good luck Philip Freidin Philip Freidin Mindspring that acquired Earthlink that acquired Netcom has decided to kill off all Shell accounts, including mine. My new primary email address is philip@fliptronics.com I'm sure the inconvenience to you will be less than it is for me.Article: 24559
rickman wrote: > Without this information, it is hard to determine the failure rate of a > design. If you could release numbers saying that the metastable rate is > better than X then we could at least determine that our device will not > fail (on the average) for 100 years even if it is really 10000 years. > > Without the numbers we can't say it has any maximum failure rate. I agree and think that all manufacturers should supply this as a specification. Some manufacturers are getting close to 10 years out of date. A bounded limit would be fine; after all, that is how the specifications are typically written. One may wish to put a note on the specification, as is often done for clarification, that the "true limit" has not been measured and not provide a typical number in the "typ" column. And, of course, state the test conditions such as temperature and voltage as they can affect the results. rkArticle: 24560
You can use a CLKDLL if you're going to use the PCI Core in an embedded design (where you can guaranty that the clock will always be > 25MHz). Otherwise, you must follow Xilinx recommendations. Martin Filteau Hardware Design Engineer Hyperchip, Inc. The Petabit Routing CompanyArticle: 24561
Later,I find the automated conversion into "one-hot" does not occur any more, when I don't choose the option of Symbolic FSM Compiler in the main window of Synplify. So I think it is the Symbolic FSM Complier that performs the optimization of FSM during synthesis and converts the state-encoding to "one-hot" automatically, though I hava specify it as "gray" using the attribute of syn_encoding as follows: -- synthesis syn_encoding= "gray" . Thank for your above replies, jianjie threehero wrote in message <8n32kt$4ns$1@sunlight.pku.edu.cn>... >I use VHDL and Synplify to describe and synthesize my design, respectively. >when i designed a state machine, I used the attribute of syn_encoding to >specify the type of state encoding, such as "gray".The number of states in >my >state machine is 20.But when I looked in the log file after synthesis, I >found >my state encoding had been converted to "one-hot" by Synplify automatically. >Why did it do such? I did not need "one-hot". How could i tell it what I >want >the state encoding to be? > >Any suggestions and replies would be very appreciated! > >jianjie > >Article: 24562
rickman wrote: > t-rickman wrote: > > > A "Gray" coded FSM would use 5 bits to > > encode 20 states. Each transistion in your state diagram (including the > > "stay in this state" transistions) would require the full state vector > > to be decoded. This may have required a lot of logic if you have a lot > > of transistions. > > > > I don't think this would produce so many gates that you could not have > > built the FSM, but I think "Gray" coding would require a lot more gates > > than straight binary. I will have to think about that a bit. I don't understand how "Gray encoding" would work in a general-purpose state machine. Gray means ( to me at least ) that only one bit changes on any transition. That works very nicely in a counter, which is a specialized state machine with only one "next state" for every state. ( Well, two for an up-down counter ) But it is inherently impossibel to have a single-bit change in a state machine where, depending on control inputs, the code might jump in many ways. So, what's the meaning of a "Gray-encoded" state machine? Peter AlfkeArticle: 24563
>I don't understand how "Gray encoding" would work in a general-purpose state >machine. Gray means ( to me at least ) that only one bit changes on any >transition. That works very nicely in a counter, which is a specialized state >machine with only one "next state" for every state. ( Well, two for an up-down >counter ) >But it is inherently impossibel to have a single-bit change in a state machine >where, depending on control inputs, the code might jump in many ways. >So, what's the meaning of a "Gray-encoded" state machine? If we took "Gray code" to mean simply "single bit-change on each transition" this is doable in some situations. Imagine embedding the states of a state machine on a hypercube, with all transitions fitting on the edges of the hypercube. If each dimension is represented by a different bit, then you have achieved a gray code for the system. If you insist that all FSM states be represented by a single code, then not all FSMs can be embedded in a hypercube. One simple constraint is there can't be an odd cycle in the state graph (i.e. a mod 3 counter). It is necessary to avoid this to achieve a 1-to-1 embedding, but I don't know if it is sufficient. If you wanted to go nuts, I believe you could duplicate states enough so that any circuit could be embedded in a hypercube. For example, a mod 3 counter could be built from a mod 6 counter, which can be embedded in the hupercube. To be less extreme, one set of heuristics for state assignment is to use an encoding that minimizes bit transitions between states (I think most of this is in Katz at least). Perhaps "gray" means "minimize bit changes". Scott P.S. Yes, I'm an academic. How could you tell?Article: 24564
Well, you can have a state machine with multiple branches that always has only one bit changing, but it does take a bit of patience, and often requires adding a dummy state or two (I've done a couple of these over the years). I'm not sure I'd call it a gray coded machine though. Gray code to me is a very specific sequence. A better description, although more verbose is a state machine with a maximum hamming distance of 1. Gray code is a special case of that that produces a linear sequence through all the possible states. Here's a simple example: +----- 001 <--+ v ^ 000 -> 100 -> 101 v ^ 010 -> 110 Peter Alfke wrote: > > rickman wrote: > > > t-rickman wrote: > > > > > A "Gray" coded FSM would use 5 bits to > > > encode 20 states. Each transistion in your state diagram (including the > > > "stay in this state" transistions) would require the full state vector > > > to be decoded. This may have required a lot of logic if you have a lot > > > of transistions. > > > > > > I don't think this would produce so many gates that you could not have > > > built the FSM, but I think "Gray" coding would require a lot more gates > > > than straight binary. I will have to think about that a bit. > > I don't understand how "Gray encoding" would work in a general-purpose state > machine. Gray means ( to me at least ) that only one bit changes on any > transition. That works very nicely in a counter, which is a specialized state > machine with only one "next state" for every state. ( Well, two for an up-down > counter ) > But it is inherently impossibel to have a single-bit change in a state machine > where, depending on control inputs, the code might jump in many ways. > So, what's the meaning of a "Gray-encoded" state machine? > > Peter Alfke -- -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: 24565
> Please try to read any VLSI or ASIC book that you get. Please don't always think that your are the best and so we must read book because you don't want to answer any question... If you think that some question are not interresting for you, please, forget it! Or the next time, please, forget the first word "Please"! You are not in your scool but over Internet, here ! Tankx PaulArticle: 24566
aesolutions wrote: > > Thanks Dan > (I am trying to figure out my news-reader program) > > "Dan" <daniel.deconinck@sympatico.ca> wrote in message > news:KrSl5.148321$Gh.2339132@news20.bellglobal.com... > > Reply test only. > > > > Had this been a real message, you would been notified important public events. Thank you for supporting the Emergency test message system. Now back to your regularly scheduled newsfeed. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Octal Computers:Where a step backward is two steps forward!" http://www.jetnet.ab.ca/users/bfranchuk/index.htmlArticle: 24567
Patrick, Can you suggest a suitable text book - something practical that gives me the basic knowledge. Cheers, Austin Patrick Schulz wrote: > Austin Tempany wrote: > > > > Hi, > > Could someone please explain the whole process of Scan Test with reference to ASIC implementation. > > Sorry, but this would go beyond the scope of this group. Try to read the documentation of your test > tool. I could post some scan insertion scripts if you use DC2000.05 > > > > Apparently during Scan Testing (if the implementation has memory) the memory blocks are bypassed > > while the remaining circuitry is Scan Tested. > > > Scan testing is only capable of testing combinational logic between two FFs. As your memory cell is > a blackbox for your test tool, you need to bypass it in test mode to achieve highest test coverage. > This would also happen with PLLs or other cells that are in the fanin cone of clk or reset pins of a > FF. > > Hope this helps > > Patrick > > -- > Patrick Schulz (schulz@rumms.uni-mannheim.de, pschulz@ieee.org) > University of Mannheim - Dep. of Computer Architecture > 68161 Mannheim - GERMANY / http://mufasa.informatik.uni-mannheim.de > Phone: +49-621-181-2720 Fax: +49-621-181-2713 -- ------------------------------------------------------------ Integrated Silicon Systems Ltd. Tel: +44 28 90 50 4000 50 Malone Road Fax: +44 28 90 50 4001 Belfast BT9 5BS Web: www.iss-dsp.comArticle: 24568
On Fri, 11 Aug 2000 09:23:19 -0700, Ramy <ramy@cim.mcgill.ca> wrote: >I suspect the problem is in the bit file generated. This is the log file BOX.BGN at the end. >It mentions a possible warning about the STARTUP and the CCLK. I don't understand >what it means. Could you explain its meaning and a possible fix? The start up sequence includes a trivial state machine. See it on page 6-58 of the 1/1999 data book. Title is Figure 49: Start-up Logic. Your command line to bitgen is specifying the clock for this circuit with -g StartUpClk:CCLK Which is the default, and is correct for most configuration modes. Xchecker uses serial slave mode, so it is the correct choice, unless you are planning something special with synchronous startup. The above option controls the mux in the lower left corner of the diag on page 58. Since this is your choice, the sw is advising you that you have also connected a signal to the clock pin of the startup symbol, and this cant possibly work, since your -g StartUpClk:CCLK tells it to take the signal from the cclk pin. In fact even if you changed the command line to select the internal clock that you have routed to the startup symbol it couldnt work, because until the startup sequence is completed, all your flipflops are held in reset, and your divide by 4 for the 8MHz signal would never get thru the two flipflops that are being held reset! >I'm using an external 8 MHz clock that is divided into a 2 MHz clock inside the chip. >This clock signal is connected to the STARTUP and all other flipflops, etc. The external >8 MHz clock is used only to clock the 2-bit clock divider. So just disconnect it from the startup symbol. You will stop getting the warning message. >Another possibility is that my XCHECKER.EXE program might be too old to program the chip? >I'm using a DOS version 5.2.0. I haven't been able to find a more recent version. If you know >where I can find it, (DOS or UNIX) that would be great. > >This is the log file: >---------------------------- >Loading device database for application Bitgen from file "box.ncd". > > "box" is an NCD, version 2.27, device xc4010e, package pg191, speed -4 > >Loading device for application Bitgen from file '4010e.nph' in environment > >C:/fndtn. > >Opened constraints file box.pcf. > > > > > >BITGEN: Xilinx Bitstream Generator M1.5.25 > >Copyright (c) 1995-1998 Xilinx, Inc. All rights reserved. > > > >Fri Jul 21 13:13:47 2000 > > > >bitgen -l -w -g ConfigRate:SLOW -g TdoPin:PULLNONE -g M1Pin:PULLNONE -g DonePin:PULLUP -g CRC:enable >-g StartUpClk:CCLK -g SyncToDone:no -g DoneActive:C1 -g OutputsActive:C3 -g GSRInactive:C4 -g ReadClk:CCLK >-g ReadCapture:enable -g ReadAbort:disable -g M0Pin:PULLNONE -g M2Pin:PULLNONE box.ncd > > >WARNING:x4kbs:36 - There is a STARTUP component with a signal on the CLK pin > > but StartupClk is Cclk. > >Running DRC. > >DRC detected 0 errors and 0 warnings. > >Saving ll file in "box.ll". > >Creating bit map... > >Saving bit stream in "box.bit". Philip Freidin Mindspring that acquired Earthlink that acquired Netcom has decided to kill off all Shell accounts, including mine. My new primary email address is philip@fliptronics.com I'm sure the inconvenience to you will be less than it is for me.Article: 24569
"Mark W Brehob" <brehob@cse.msu.edu> wrote: <snip> > Micron's free book about what they sell is an interesting read if you take > your time. I learned a lot from it. What book? -- Derrick ShearerArticle: 24570
Ramy, Your problem may be due to the delay from your 8-bit counter to the I/O pins of the FPGA device - if theses delays are not all of a similar value, then the DAC will glitch from one value to the next. 1. Which Development Package are you using - are you using VHDL or Schematics. 2. Which DAC are you using. 3. Assuming the DAC simply converts the 8-bit value from the FPGA (i.e. there are no clocks to clock the data into the DAC device) then you must ensure that all 8-bits are presented to the DAC at the same time. The easiest way to do this is to use the output flip-flops in the I/O cells of the FPGA (OFD flip-flops in the IOB's). This is easy to do in Schematics, a bit trickier in VHDL. There is also an implementation switch in the software to force the use of IO flip-flops. Regards, Neil Carrington (Xilinx FAE for Insight Memec) "ramy" <ramy@cim.mcgill.ca> wrote in message news:ee6d780.-1@WebX.sUN8CHnE... > Hello, > > I have been working with the Foundation Series to program my XC4010E-4 PG191, and I have been having many problems. Any ideas or suggestions would be greatly appreciated. > > What I need: > I need to create a triangular wave voltage signal. I implemented an 8-bit counter that counts from 0 to 255 to 0 and back to 255, etc. The output goes through a D/A converter and to an amplifier to generate at 30V peak to peak triangular wave. > > Problem: > Occasionally, the bit file will program correctly, and the triangle wave will be as desired. However, when I implement other parts of the Xilinx control circuit, the new bit file does not program the chip correctly: the resulting triangle wave is not smooth, but rather a very odd shape that is more like a staircase. > > The previous version of this project has used the XC4010 version of the chip and works correctly. However, I am currently using Foundation Series which only implements the XC4010E library. However, the results are identical when programming the XC4010 and XC4010E chips. > (note, the XC4010E chip is backwards compatible with XC4010, but differs by architectural enhancements.) > > If you have any idea what might be causing this problem, ideas or solutions (anything!!) or would like me to provide more information, please e-mail me ramy@cim.mcgill.ca. > > thanks, > RamyArticle: 24571
Hello there. This is a quick test. Regards, Neil Carrington.Article: 24572
Reply test only.Article: 24573
This is another test "aesolutions" <aesolutions@supanet.com> wrote in message news:8n8qe8$egr$1@cinnamon.nnrp.netline.net.uk... > Hello there. This is a quick test. > Regards, Neil Carrington. > > >Article: 24574
Thanks Dan (I am trying to figure out my news-reader program) "Dan" <daniel.deconinck@sympatico.ca> wrote in message news:KrSl5.148321$Gh.2339132@news20.bellglobal.com... > Reply test only. > >
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