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
"shjin" <seunghun.jin@gmail.com> wrote in message news:07aef7e1-bb1b-4f98-95cd-af24ab4a96ad@k22g2000yqh.googlegroups.com... > Hi, all. > > I got some error message when I use HDL Analysis and Lint (HAL) tool > from Cadence on my design. > > It is, > "Combinatorial path crossing multiple units drives a signal. The > driver of flip-flop/output port has combinatorial assignment at > multiple hierarchy levels." > > Since the code is just a normal register - combinational logic - > register style, it seems usual to me. > > Can anybody explain why the analysis tool makes an error on this? You seem to have a long combinatorial path going through multiple modules without a FF. This error message might be triggered by a HAL rule which states that each output (or input) port needs to be registered. I would change this rule to a warning and when you come to synthesis and look at your critical path you might remember this warning :-) Hans www.ht-lab.com > > Thanks in advance. > > - shjin >Article: 149701
phil <pcgarcia@wisc.edu> wrote: > Hello all, > I am currently a PhD student at the University of Wisconsin-Madison. > I am working on research where I'm interfacing CPUs directly with > reconfigurable logic. Part of this work (and part of my thesis) is > going to require me to have area estimates of portions of my interface > system. Having these estimates is useful for two reasons: first, it > allows me to better estimate the overhead (in terms of area) of the > interface I've designed between the reconfigurable fabric and the > cache hierarchy, and second, it will allow me to make better > comparisons between using reconfigurable accelerators as compared to > using other accelerator architectures such as vector processing units > and GPUs. > I would be most interested in Xilinx 65nm Virtex 5 devices (as the > reconfigurable fabric I'm simulating in my research is assumed to be > similar to the Virtex-5, and I use timing and area estimates for my > accelerators using this device), in particular the LX 155 device, > although any of them would likely prove to be useful for at least > coming up with a ballpark estimate. If this isn't available, I'd be > open to other recent devices, as I could likely extrapolate an > approximate area, which would allow me to make better educated guesses > concerning the system. > These numbers would be useful to my work even if I can't publish exact > figures, but only rough estimate comparisons. Any help would be > greatly appreciated though. Go to a dentist and X-ray some parts... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 149702
On Nov 18, 1:58=A0am, "k...@att.bizzzzzzzzzzzz" <k...@att.bizzzzzzzzzzzz> wrote: > On Wed, 17 Nov 2010 09:03:54 -0800, Rob Gaddi <rga...@technologyhighland.= com> > wrote: > > > > > > > > > > >On 11/16/2010 4:06 PM, k...@att.bizzzzzzzzzzzz wrote: > >> On Tue, 16 Nov 2010 14:23:22 -0600, Jon Elson<jmel...@wustl.edu> =A0wr= ote: > > >>> On 11/14/2010 09:26 AM, Gabor wrote: > > >>>> I'll also agree that schematics are broken, at least since they > >>>> dumped Aldec after Foundation version 4.1i. =A0It's pretty clear > >>>> that schematics are very low on their software support priority > >>>> list. =A0I stopped using schematics when I moved from the > >>>> Aldec-based Foundation tools to ISE. > >>> Actually, I thought the Aldec schematic tool was simply AWFUL, so bad= I > >>> rigged up a system to use my preferred schematic entry (Protel 99) to > >>> generate architectural VHDL. =A0It didn't make the VHDL quite the way > >>> Xilinx wanted it, so I had to hand edit - mostly to remove redundant > >>> duplications of library component declarations. =A0But, I've been slo= wly > >>> learning the benefits of all-VHDL development, so this is much less a= n > >>> issue now than it was for me almost a decade ago. =A0I still think th= eir > >>> ise schematic is pretty bad, only slightly better than Aldec's, which > >>> seemsed like you could only get one gate and one FF on a page before = the > >>> automated wire generator went nuts. =A0Now, I can get 4 gates and 4 F= Fs on > >>> a page before the wiring gets messy. =A0I mostly only use schematics = for > >>> relatively simple, one-page glue logic for a CPLD, so it is OK. > > >> Schematics would be nice for high-level design where dataflows tend to > >> dominate the reader's interest. =A0I've never seen a package that work= ed well > >> enough to use, though. =A0I just use schematics for board level. =A0I'= ve always > >> used VHDL only for programmable parts. > > >> OTOH, physical and logical viewers are useful to make sure synthesis i= s doing > >> what the designer expects, though. =A0The difference between such a vi= ewer and a > >> schematic entry package is the routing. =A0The viewer doesn't (well) a= nd the > >> schematic capture package won't (you do). =A0;-) > > >Having done some playing with the Aldec Active-HDL block diagram editor, > >if you're in the market you may find it worth a look. =A0For doing actua= l > >schematic entry of low level blocks it's only mediocre, but for tying > >together the high level stuff it's pretty quick and clean. > > Market? =A0Does it cost more than pocket lint? =A0The Aldec rep has been = bugging > me to do a test drive, but there zero chance of spending money on such th= ings. > > The big advantage I see in schematic entry at the top level is documentat= ion. > Schematics are (well, can be) intuitive. =A0A pile of VHDL is very diffic= ult to > dig through. =A0Having had to verify a subsystem with a few hundred ~10K = line > files... =A0 You can do the reverse - write VHDL/Verilog and then get the schematic viewer in ISE to draw a representation of it for documentation. I've always thought it does a pretty good job of displaying the RTL view and giving a way to look at the hookup of top-level modules. PlanAhead can also generate schematics from the RTL source. Note - I'm just offering it here as an idea to facilitate documentation.Article: 149703
On Thu, 18 Nov 2010 03:34:10 -0800 (PST), 2cents <web@sharonmccormack.com> wrote: >On Nov 18, 1:58 am, "k...@att.bizzzzzzzzzzzz" ><k...@att.bizzzzzzzzzzzz> wrote: >> On Wed, 17 Nov 2010 09:03:54 -0800, Rob Gaddi <rga...@technologyhighland.com> >> wrote: >> >> >> >> >> >> >> >> >> >> >On 11/16/2010 4:06 PM, k...@att.bizzzzzzzzzzzz wrote: >> >> On Tue, 16 Nov 2010 14:23:22 -0600, Jon Elson<jmel...@wustl.edu> wrote: >> >> >>> On 11/14/2010 09:26 AM, Gabor wrote: >> >> >>>> I'll also agree that schematics are broken, at least since they >> >>>> dumped Aldec after Foundation version 4.1i. It's pretty clear >> >>>> that schematics are very low on their software support priority >> >>>> list. I stopped using schematics when I moved from the >> >>>> Aldec-based Foundation tools to ISE. >> >>> Actually, I thought the Aldec schematic tool was simply AWFUL, so bad I >> >>> rigged up a system to use my preferred schematic entry (Protel 99) to >> >>> generate architectural VHDL. It didn't make the VHDL quite the way >> >>> Xilinx wanted it, so I had to hand edit - mostly to remove redundant >> >>> duplications of library component declarations. But, I've been slowly >> >>> learning the benefits of all-VHDL development, so this is much less an >> >>> issue now than it was for me almost a decade ago. I still think their >> >>> ise schematic is pretty bad, only slightly better than Aldec's, which >> >>> seemsed like you could only get one gate and one FF on a page before the >> >>> automated wire generator went nuts. Now, I can get 4 gates and 4 FFs on >> >>> a page before the wiring gets messy. I mostly only use schematics for >> >>> relatively simple, one-page glue logic for a CPLD, so it is OK. >> >> >> Schematics would be nice for high-level design where dataflows tend to >> >> dominate the reader's interest. I've never seen a package that worked well >> >> enough to use, though. I just use schematics for board level. I've always >> >> used VHDL only for programmable parts. >> >> >> OTOH, physical and logical viewers are useful to make sure synthesis is doing >> >> what the designer expects, though. The difference between such a viewer and a >> >> schematic entry package is the routing. The viewer doesn't (well) and the >> >> schematic capture package won't (you do). ;-) >> >> >Having done some playing with the Aldec Active-HDL block diagram editor, >> >if you're in the market you may find it worth a look. For doing actual >> >schematic entry of low level blocks it's only mediocre, but for tying >> >together the high level stuff it's pretty quick and clean. >> >> Market? Does it cost more than pocket lint? The Aldec rep has been bugging >> me to do a test drive, but there zero chance of spending money on such things. >> >> The big advantage I see in schematic entry at the top level is documentation. >> Schematics are (well, can be) intuitive. A pile of VHDL is very difficult to >> dig through. Having had to verify a subsystem with a few hundred ~10K line >> files... > >You can do the reverse - write VHDL/Verilog and then get the schematic >viewer in ISE to draw a representation of it for documentation. That works for *very* small entities. As I said in another post, this is really useful for seeing what muck the synthesizer is making out of your code. Synthesis uses "template matching" so one style of code *usually* produces one sort of output. These tools are great for discovering these templates. >I've always thought it does a pretty good job of displaying the RTL >view and giving a way to look at the hookup of top-level modules. I haven't found this sort of thing useful at all. The wires turn into spaghetti on very simple designs. The purpose of documentation is clarity, not spaghetti. >PlanAhead can also generate schematics from the RTL source. >Note - I'm just offering it here as an idea to facilitate >documentation. Haven't used it. Do you have a review?Article: 149704
Hello all I am using xilinx platform studio (XPS) for testing my FX12 minin module development board and facing some problems. Using base system builder, i select only RS232 and Mini module GPIO leds and two examples were created,one test memory and second test peripheral.Test memory resides in BRAM while test peripheral in DDR SDRAM. I downloaded bit file to my board successfully for both memory and peripheral examples one by one using xps download bitstream but problem is that test peripheral example shows nothing (test memory example shows correct results on hyperterminal). I am quite new to xps and fpga, kindly guide me what can be the problem?I guess it has to do something with executing code from external DDR SDRAM? Thanks in advance --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149705
On Nov 18, 10:48=A0pm, "bhatti" <bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote: > Hello all > > I am using xilinx platform studio (XPS) for testing my FX12 minin module > development board and facing some problems. > > Using base system builder, i select only RS232 and Mini module GPIO leds > and two examples were created,one test memory and second test > peripheral.Test memory resides in BRAM while test peripheral in DDR SDRAM= . > > I downloaded bit file to my board successfully for both memory and > peripheral examples one by one using xps download bitstream but problem i= s > that test peripheral example shows nothing (test memory example shows > correct results on hyperterminal). > > I am quite new to xps and fpga, kindly guide me what can be the problem?I > guess it has to do something with executing code from external DDR SDRAM? > > Thanks in advance > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Downloading the bitfile to the FPGA will not put the test peripheral program into DDR memory for you. The simplest thing you can do is to regenerate the linker script to put that program into BRAM memory so that it will be downloaded with the rest of the bitfile. What version of EDK/XPS are you using, and are you also using SDK? Regards, John McCaskill www.FasterTechnology.comArticle: 149706
On Nov 17, 6:58=A0pm, shjin <seunghun....@gmail.com> wrote: > Hi, all. > > I got some error message when I use HDL Analysis and Lint (HAL) tool > from Cadence on my design. > > It is, > "Combinatorial path crossing multiple units drives a signal. The > driver of flip-flop/output port has combinatorial assignment at > multiple hierarchy levels." > > Since the code is just a normal register - combinational logic - > register style, it seems usual to me. > > Can anybody explain why the analysis tool makes an error on this? > > Thanks in advance. > > - shjin The warning seems to hint that you are driving an output port with a combinatorial path that consists of multiple logic levels, which correlates to longer flop-to-flop delays and slower performance. Good practice to register that output port to (1) beef up performance, and (2) to allow destination module that is receiving that signal to deal with clk-to-out delay out of your module. Gives floorplanning more flexibility as well. Do it now, or spend many hours during timing closure later... JohnArticle: 149707
Hi, funny, we have a very similar setup here and also fried an LVDS-input on a prototype... (Now, the n-input of the pair is low impedance to ground). We came to the same conclusion (add ESD-protection in the re- design)... So I am curios if there is an answer to your question. Regards, Thomas www.entner-electronics.comArticle: 149708
On 11/17/2010 6:26 PM, BW wrote: > Hi! > > We have a design where an Altera Cyclone-3 (EP3C5) with LVDS inputs is > connected to a sender on another board through a cable. > > In a number of cases on our prototype boards, the LVDS-inputs have > been fried from this setup. > > Apart from any misdesign in the sender-board, does anyone have any > suggestions on possible causes? Do these inputs have lesser ESD- > protection? The cables used are shielded RJ45 TP-cables (ethernet > cables) and I think the shield touches the connector before the > signals, thus grounding away any accumulated potentials during > assembly. > > I guess we'll put on external protection for the next board-spin, but > I would just like some hints on if this is a common problem with these > devices (if external protection is not used). > > Best regards, > Bjorn W > I can imagine situations where a difference in ground levels between the two modules would cause trouble. How are the grounds of the two modules related? Are the modules powered from the same supply? (Like two boards in the same backplane, for example.) If you disconnect the data cable between the two and connect a multimeter in current mode between the grounds is there any current flowing? Probably not the issue, but easy to check. Chris AbeleArticle: 149709
>Downloading the bitfile to the FPGA will not put the test peripheral >program into DDR memory for you. The simplest thing you can do is to >regenerate the linker script to put that program into BRAM memory so >that it will be downloaded with the rest of the bitfile. > >What version of EDK/XPS are you using, and are you also using SDK? > >Regards, > >John McCaskill >www.FasterTechnology.com > Thanks for your response.I am using EDK 10.1. No, i have not still used SDK.Using BRAM i think i will face limited memory problem, secondly i want to learn how to execute my code from external DDR SDRAM. Thanks in advance --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149710
I generally implement resets with asynchronous assertion and synchronous de-assertion. With a single reset, this is simple. However, what happens if there are multiple reset inputs but I only want one internal reset? I was always under the impression that one should not have any combinational logic in the asynchronous reset path, as it could lead to static hazards (and reset glitches). So, how do you combine two resets into one without using combinational logic somewhere? I was thinking of two scenarios: 1. AND the two resets coming into the FPGA, and connect to the asynchronous reset of a synchronizer. The output of the synchronizer is the single internal reset. 2. Individually synchronize the two resets coming into the FPGA (note that each reset input feeds the asynchronous reset of the synchronizer). AND the output of each of the synchronizers and feed this single signal into the asynchronous reset of a final flip-flop. The output of this flip-flop is the single internal reset. In both cases we achieve asynchronous assertion and synchronous de- assertion ... however, in both cases there is combinational logic in the asynchronous reset path. Any suggestions how these multiple resets should be combined?Article: 149711
I have to develop some electronics that will probably fit nicely into a spartan3 device xc3s200 or xc3s400. Which series / package should I choose for long availability? I am considering the TQFP144 or PQ208 package, I try to avoid BGA. Will there be any differences in the long-term availability between spartan 3, spartan 3A, spartan 3E, or even spartan 3AN? Thanks, ThomasArticle: 149712
> I try to avoid BGA. Don't. It has many advantages over the other packages, among them - better yield in soldering. - less EMI - less ground bounce - less board space - better cooling KoljaArticle: 149713
Thomas Heller <theller@ctypes.org> wrote: > I have to develop some electronics that will probably fit nicely into > a spartan3 device xc3s200 or xc3s400. Which series / package should > I choose for long availability? > I am considering the TQFP144 or PQ208 package, I try to avoid BGA. > Will there be any differences in the long-term availability > between spartan 3, spartan 3A, spartan 3E, or even spartan 3AN? No hints for availability, but 3E and 3A configure from cheap commodity serialflash and 3A and 3AN can run with only 3.3/1.2 Volt, while S3 and S3E always need 2.5 Volt. Otherwise S2 was introduced around 2000, but still seems running strong, so thi may indicate whats happening with S3... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 149714
Kolja Sulimma <ksulimma@googlemail.com> wrote: > > I try to avoid BGA. > Don't. > It has many advantages over the other packages, > among them > - better yield in soldering. > - less EMI > - less ground bounce > - less board space > - better cooling And if you go th BGA, you might now consider S6. S6 in QFP still is _not_ available... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 149715
Huffman encoder/Decoder For Text data compression
Hi All,
I am working on Huffman Encoder/Decoder for text
compression/Decompression.And here are the things not clear for me.
1.How can I give text input (Whole text once) to the FPGA.
2.When I encode the data the output code length is not fixed and how can I
manage this with constant I/O pins of the FPGA.
3.When Encoding the text I have to use heaps,Sort and mearge but this
things
are not synthesizable in FPGA
thanks in advance
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 149716In article <63d8c432-53dd-43c0-9541-e87ee1645090 @q14g2000yqe.googlegroups.com>, analog_guy@hotmail.com says... > I was thinking of two scenarios: > 1. AND the two resets coming into the FPGA, and connect to the > asynchronous reset of a synchronizer. The output of the synchronizer > is the single internal reset. You really want to OR the two resets together. Either one _or_ the other should reset the internal logic. The sense of the logic may be H active or L active but in any case the combinatorial logic is an OR. Now I say this because in all my experience I cannot envision a case where you would be saying you want to reset your internal logic when both inputs are active at the same time. Lastly, what is wrong with some combinatorial logic in the asynchronous path? Since the inputs arrive at who knows what time the added delay of the combinatorial logic only adds a small amount to that best guess time! Now I suppose there could be special cases of the input signals being very narrow pulses where the delay may be an impact but then they are going to have problems being detected by the synchronizer - but you did not mention that detail. -- Michael Karas Carousel Design Solutions http://www.carousel-design.comArticle: 149717
On Nov 20, 8:12=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > Thomas Heller <thel...@ctypes.org> wrote: > > I have to develop some electronics that will probably fit nicely into > > a spartan3 device xc3s200 or xc3s400. =A0Which series / package should > > I choose for long availability? > > I am considering the TQFP144 or PQ208 package, I try to avoid BGA. > > Will there be any differences in the long-term availability > > between spartan 3, spartan 3A, spartan 3E, or even spartan 3AN? > > No hints for availability, but 3E and 3A configure from cheap commodity > serialflash and 3A and 3AN can run with only 3.3/1.2 Volt, while S3 and S= 3E > always need 2.5 Volt. > > Otherwise S2 was introduced around 2000, but still seems running strong, = so > thi may indicate whats happening with S3... > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar= mstadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- S3A is the newest of the S3 series, and likely to survive longest. It is also cheapest per LUT. I would stay away from the S3AN which is a die-stack FPGA / SPI flash combo. You can do the same thing with a very inexpensive external SPI flash chip, and you don't have to worry about Xilinx's own long term arrangement to obtain the stacked flash device. S3A also has some architectural advantages over the older versions including better IDELAY elements, but be careful to read the I/O restrictions, because part of the price reduction was to make the top/bottom banks have different subsets of the I/O capabilities than the left/right banks. If you can get all of the I/O you need in the available packages, then the S3A is probably the best choice. Regards, GaborArticle: 149718
On Nov 20, 8:57=A0am, "kude" <tadmas09@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > Huffman encoder/Decoder For Text data compression > > Hi All, > =A0 I am working on Huffman Encoder/Decoder for text =A0 =A0 > =A0 compression/Decompression.And here are the things not clear for me. > 1.How can I give text input (Whole text once) to the FPGA. > 2.When I encode the data the output code length is not fixed and how can = I > > =A0 manage this with constant I/O pins of the FPGA. > 3.When Encoding the text I have to use heaps,Sort and mearge but this > things =A0 > =A0 are not synthesizable in FPGA > > =A0 =A0 thanks in advance =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com There are some publicly available JPEG compression cores if I'm not mistaken. Part of the core is a Huffman encoder. You might want to check this out to see how it can be done. I have worked on a JPEG compression core, but only to optimize it to meet timing, so I'm not up on all the details. However I remember that at one point in the interface the data path had to become very wide to handle the worst case expansion, and then there is a lot of shifting and packing that grabs the required bits from the wide path. The latter was a part I worked on extensively, and it required a lot of pipelining to meet timing. Regards, GaborArticle: 149719
On Nov 20, 1:56=A0am, "bhatti" <bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote: > >Downloading the bitfile to the FPGA will not put the test peripheral > >program into DDR memory for you. The simplest thing you can do is to > >regenerate the linker script to put that program into BRAM memory so > >that it will be downloaded with the rest of the bitfile. > > >What version of EDK/XPS are you using, and are you also using SDK? > > >Regards, > > >John McCaskill > >www.FasterTechnology.com > > Thanks for your response.I am using EDK 10.1. No, i have not still used > SDK.Using BRAM i think i will face limited memory problem, secondly i wan= t > to learn how to execute my code from external DDR SDRAM. > > Thanks in advance =A0 =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com You can load the code into DDR sdram using XMD. If you have a compact flash system, an ACE file can load DDR SDRAM for you. If you have non-volatile memory, a boot loader program in BRAM can move the executable from nvmem to DDR. You should read the tutorials and manuals.Article: 149720
Here's a good mind bender for the gurus... I have a device with an FPGA and a PIC microcontroller (among other things). The two communicate over a 12-line link: 8 multiplexed data/address lines -- can be In or Out 2 Address Load lines -- low and high. Inputs to the FPGA. Read and Write -- inputs to the FPGA I can make these outputs or inputs on the PIC, and can do the same on the FPGA. The I/O state above is simply how they're configured in the "working" hardware. Problem is, the boards I'm getting back from manufacturing have really shoddy yields. 70% failure rate. I'm getting bridges and opens, nearly always on the PIC-to-FPGA lines. Anyway, enough of that. Suffice it to say, I have a stack of almost-working boards with various issues. Visual inspection is not finding them, and shotgun-resoldering the PIC and FPGA tends to cause more problems. Basically: I need to find the shorts and opens, and fix them, without affecting the rest of the pins (which I assume to work). In order to do this, I need to know where those shorts and opens are. Problems: 1) I don't know which pins work. I can't even guarantee that any of them work. 2) The only real output the FPGA has is an LED 3) I'd like to find as many shorted pins as possible in each test pass. If I can find and eliminate them all, so much the better. So far the best idea I've come up with (actually a friend came up with it) is to load a bitstream which reads the state of the other 10 lines. The FPGA clocks out 20 '0' bits, a '1', then the state of the 10 pins. This allows the PIC/PC combination to automatically test the whole set of remaining combinations. Can anyone think of an easier way to do this? Thanks, -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 149721
On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote: > [snip] > Lastly, what is wrong with some combinatorial logic in the asynchronous > path? Since the inputs arrive at who knows what time the added delay of > the combinatorial logic only adds a small amount to that best guess > time! Now I suppose there could be special cases of the input signals > being very narrow pulses where the delay may be an impact but then they > are going to have problems being detected by the synchronizer - but you > did not mention that detail. The OP is worried about glitches in the combinatorial logic. In general, a glitch can be generated at the output of some combinatorial logic whenever any input changes, even if (under steady state conditions) that input should not affect the output. For the specific case of an AND (or OR) gate implemented in a single LUT, glitches can not be generated and the OP needn't worry. There's an old Xilinx appnote dating from the XC3000 days which stated that a single LUT will not generate an glitch if only one input changes at a time (i.e. within some brief time window). This behaviour was due to the structure of the readback mux in the LUT. I believe I have seen a similar statement from Altera as well, although this information never appears in contemporary datasheets from either company. Guaranteeing glitch free behaviour from synthesised logic with more than a few inputs is nigh on impossible, as the synth tool will ignore any hazard coverage you do. Cheers, AllanArticle: 149722
"David Brown" <david@westcontrol.removethisbit.com> wrote in message news:poednSAUkb9tRlLRnZ2dnUVZ7v6dnZ2d@lyse.net... > > If you get an appropriate DAC (such as the AD5791) with an SPI interface, > you could connect it up to an FTDI FT4232H module. I am not recommending you get their servicesArticle: 149723
On Sat, 20 Nov 2010 23:22:48 +0000, Philip Pemberton wrote: > Here's a good mind bender for the gurus... > > Problems: [snip] > 2) The only real output the FPGA has is an LED When I worked at Fujitsu, we had a controller board with a GPIO driven status LED on its front panel. When it was in debug mode (e.g. after a crash), software on the target system would implement a bit-bashed UART and send the resulting bits to the LED. We had a little gizmo with a phototransistor and an line-powered RS232 buffer that would send the bits back to a serial port on a PC so the debug results (in this case a stack trace) could be seen on a terminal emulator program. A magnet in the gizmo held it on to the panel in the right place above the LED. You shouldn't have any trouble rolling your own UART to do something similar. If it's a Xilinx part, I recommend a picoblaze + picoblaze uart combination if there's more than a trivial amount of information to send. Cheers, AllanArticle: 149724
On Nov 20, 7:09=A0pm, Allan Herriman <allanherri...@hotmail.com> wrote: > On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote: > > [snip] > > Lastly, what is wrong with some combinatorial logic in the asynchronous > > path? Since the inputs arrive at who knows what time the added delay of > > the combinatorial logic only adds a small amount to that best guess > > time! Now I suppose there could be special cases of the input signals > > being very narrow pulses where the delay may be an impact but then they > > are going to have problems being detected by the synchronizer - but you > > did not mention that detail. > > The OP is worried about glitches in the combinatorial logic. =A0In genera= l, > a glitch can be generated at the output of some combinatorial logic > whenever any input changes, even if (under steady state conditions) that > input should not affect the output. > Actually, the OP is worried about something that does not need to be worried about. Glitches causing resets are things that need to be avoided when you're trying to *prevent* a false reset from occurring (i.e. resetting when you don't want to be). What the OP describes is two inputs which are supposed to cause a reset. A 'glitch' on one of them would be a case of something that should cause a reset, not something that should be prevented. KJ
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