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
On Nov 20, 7:22=A0pm, Allan Herriman <allanherri...@hotmail.com> wrote: > On Sat, 20 Nov 2010 23:22:48 +0000, Philip Pemberton wrote: > > Here's a good mind bender for the gurus... > > > Problems: > [snip] > > =A0 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. =A0When 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. =A0We 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. =A0A 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. =A0If it's a Xilinx part, I recommend a picoblaze + picoblaze ua= rt > combination if there's more than a trivial amount of information to send. > > Cheers, > Allan If it is a Xilinx FPGA, you may also consider using the JTAG UART IP block where you can get terminal information via the jtag connector. You may also consider sending a walking 1 and walking 0 across the interface to the FPGA and observing the signal with chipscope if you have it.Article: 149726
kude <tadmas09@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > Huffman encoder/Decoder For Text data compression > 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. Usually clocked in a byte at a time, but for speed could be multiple bytes in parallel at a time. > 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. Again, clocked out one byte or some other number of bits, at a time. Probably an enable output and a done (EOF) output. > 3.When Encoding the text I have to use heaps,Sort and mearge > but this things are not synthesizable in FPGA There are ways to do sorts. Well, there are a few different ways to do Huffman. One is with a static table based on the usual probabilities. That is what Group 3 fax uses. I believe another is to adapt as you go along, maybe recomputing every so often, and having the decoder do the same. Otherwise, you have to go through the whole file, compute the table, then go through again. -- glenArticle: 149727
> >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. > If there is a tutorial (with example) covering this typical issue, please let me know --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149728
On Sat, 20 Nov 2010 18:11:55 -0800, KJ wrote: > On Nov 20, 7:09 pm, 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. 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. >> >> > 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. Exactly right, which is why I said: "For the specific case of an AND ... the OP needn't worry." Cheers, AllanArticle: 149729
Am 20.11.2010 13:03, schrieb Kolja Sulimma: >> 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 > > Kolja How are you doing prototyping with BGA packages? ThomasArticle: 149730
Thomas I would expect the XC3S200 and XC3S400 to have a long life even though it is 6-7 years or so since there were first available. I won't be surprised if these are still available in 10 years time. What is likely is that they will get more expensive, and maybe have longer lead times, in the coming years as Spartan-6, and later, take over as main low cost families. II would also consider Spartan-6 as it will have an even longer lifetime. Most of Spartan-6 is available now in small numbers if not large numbers. Digikey are showing stock in the TQFP package. John Adair Enterpoint Ltd. - Home of Drigmorn3. The Cost Effective Spartan-6 Development Board. On Nov 20, 9:27=A0am, 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? > > Thanks, > ThomasArticle: 149731
Could some FPGA guru please help me ? I was wondering if any of the currently available FPGA families - Alterra, Xilinx etc., have any built-in network stack (seven layer ISO/OSI model). Any information regarding this would be greatly appreciated. Thanks in advance for your help.Article: 149732
On Nov 20, 11:34=A0pm, "bhatti" <bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote: > >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. > > If there is a tutorial (with example) covering this typical issue, please > let me know =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Have a look at this. http://www.xilinx.com/support/documentation/boards_and_kits/ug494.pdf I searched and found this document just to see how difficult it was to find. I found it in 5 minutes.Article: 149733
On 11/21/2010 6:42 AM, Daku wrote:
> Could some FPGA guru please help me ? I was wondering if any of the
> currently available FPGA families - Alterra, Xilinx etc., have any
> built-in network stack (seven layer ISO/OSI model). Any information
> regarding this would be greatly appreciated. Thanks in advance for
> your help.
A network stack is mostly software.
An fpga might help out on layer 1 or 2 with
line encoding/decoding or packing/picking
bytes from a bitstream.
-- Mike Treseler
Article: 149734John Adair <g1@enterpoint.co.uk> wrote: .. > large numbers. Digikey are showing stock in the TQFP package. ... with a constant lead time 6 weeks in the future. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 149735
On 10/31/2010 7:06 AM, Pete Fraser wrote: > I'm just finishing up design of an analog data acquisition system > (16 bits, 100 kHz sampling), and need to come up with a > test / verification scheme. I've looked at some of the arbitrary > waveform generators available, and they seem to be expensive, > and not very accurate (13 or 14 bits). > > There seems to be a wide variety of inexpensive USB and > firewire audio DACs available, and some of them are > specified to 192 kHz sampling and 24 bits. If I could buy > a DAC with 24 bits and 192 kHz (or higher) sampling I > could write some code to generate a source file, play it through > the DAC, capture the resultant signals in the test system, and > analyze the system performance. > > Has anyone here done that? Can you offer any pointers? > It's not clear from the specifications / manual of the DACs I've > looked at whether filtering can be disabled. Most are > specified from 20 Hz to 20 kHz, and seem intended to > take in 44.1 kHz or 48 kHz, do a filtered up-conversion, > and (presumably) have a sloppy output filter. Some specify > that they can accept 192 kHz, but I've no idea what filters > they use and whether they can be bypassed. > > Any thoughts / observations? > > Thanks > > Pete > > Pete, I've not done this but it seems to me that a high-quality sine generator would be very useful and maybe easier to come by than an arbitrary signal generator. I'd be thinking sine waves and step inputs. You could force the FT length to match an integral number of periods after having gathered a bunch of sinusoid samples. If the generator clock is locked to the sample clock or vice-versa so much the better. Then you could look for distortion and noise levels (which one might hope would be close to the predicted quantization noise. Step inputs would give you a good idea of overall transient performance: slew rate, rise time, ringing, recovery times, etc. I didn't see any strange input requirements here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.8077&rep=rep1&type=pdf But there are a bunch of good ideas there at least. FredArticle: 149736
Thomas Heller <theller@ctypes.org> wrote: >Am 20.11.2010 13:03, schrieb Kolja Sulimma: >>> 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 >> >> Kolja > >How are you doing prototyping with BGA packages? Get your own reflow oven kit like this: http://www2.conrad.nl/goto.php?artikel=530330 I'm pretty sure similar (much cheaper) kits are offered on Ebay. I never tried it but it looks usefull for prototyping. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 149737
Mike Treseler <mtreseler@gmail.com> wrote: > On 11/21/2010 6:42 AM, Daku wrote: >> Could some FPGA guru please help me ? I was wondering if any of the >> currently available FPGA families - Alterra, Xilinx etc., have any >> built-in network stack (seven layer ISO/OSI model). Any information >> regarding this would be greatly appreciated. Thanks in advance for >> your help. > A network stack is mostly software. > An fpga might help out on layer 1 or 2 with > line encoding/decoding or packing/picking > bytes from a bitstream. There are processors like nios and microblaze designed to work with certain FPGA families, and I believe that there are TCP/IP versions for them. Well, full stack is a little much, as some of those layers are part of the application program, but at least to layer three. I believe it isn't so hard to do UDP with a simple state machine in an FPGA, but TCP would generally need a programmable processor. Also possible is an external processor doing the IP stack and buffering, then handing the data off to the FPGA. -- glenArticle: 149738
On Nov 21, 4:41=A0am, Allan Herriman <allanherri...@hotmail.com> wrote: > On Sat, 20 Nov 2010 18:11:55 -0800, KJ wrote: > > 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 th= e > >> > 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 th= e > >> > synchronizer - but you did not mention that detail. > > >> The OP is worried about glitches in the combinatorial logic. =A0In > >> 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. > > > Actually, the OP is worried about something that does not need to be > > worried about. =A0Glitches 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). =A0What the OP describes is > > two inputs which are supposed to cause a reset. =A0A 'glitch' on one of > > them would be a case of something that should cause a reset, not > > something that should be prevented. > > Exactly right, which is why I said: > > "For the specific case of an AND ... the OP needn't worry." > > Cheers, > Allan Thanks for all of your feedback. The only reason I mentioned the AND function is because I generally use active LO resets. I can see now that having some logic in the asynchronous reset path is not a big deal since I am actually dealing with a reset circuit. I just thought I had heard somewhere that avoiding combinational logic in the asynchronous reset path was a good design practice.Article: 149739
On Nov 21, 8:40=A0pm, Analog_Guy <analog_...@hotmail.com> wrote: > > I just thought I had heard somewhere that avoiding combinational logic > in the > asynchronous reset path was a good design practice.- Hide quoted text - > In certain situations combinatorial logic in the reset path should be avoided. See my reply to your post in comp.lang.vhdl KJArticle: 149740
I was writing some code and decided to make it a procedure to put in a library. I have written functions many times, but not a procedure. This was a routine for some registers and counters internal to the procedure and so required a clock and reset. I couldn't figure out how to wirte it so that it would be inside a clocked process, so I added the clock and reset to the inputs and put the clocking code within the procedure. That was all well and good. But when I tried to test it, none of the internal variables that should have created registers were being remembered. I ran a simulation and the variables were getting reset initially, but on the next entry to the procedure they were back to being undefined. Do I have a basic misunderstanding about how procedures operate? I haven't found a good reference to explain enough to figure out what I am doing wrong. GregArticle: 149741
On Nov 21, 10:34=A0pm, makeuptest <spamgoeshe...@yahoo.com> wrote: > > That was all well and good. =A0But when I tried to test it, none of the > internal variables that should have created registers were being > remembered. =A0I ran a simulation and the variables were getting reset > initially, but on the next entry to the procedure they were back to > being undefined. > Procedures do not inherently 'remember' the values of internal variables or signals as you would have in a process. Instead you must make the signal available on the interface of the procedure and hook up a real signal to that port. This generally means that you must actually add two signals to the interface of the procedure: one is an 'input' to the procedure which represents the current state of the signal; the other is an 'output' of the procedure which represent the next state of the signal. > Do I have a basic misunderstanding about how procedures operate? Yes...you can't hide signals within a procedure. Kevin JenningsArticle: 149742
> Can anyone think of an easier way to do this? Are the JTAG pins available? If so, Chipscope with VirtualIO should be the easiest for this kind of debug. You can desolder the PIC and manually loopback/short the pads and then change the stimulus through the chipscope GUI and see if the signals propagate. With one design you can then test all routes. If this is an Altera device, use SignalTap. saar.Article: 149743
Uwe Spartan-6 availability is improving very rapidly and in many cases is now on shorter lead time than Spartan-3 parts. We have a considerable amount here now of the parts we use most awaiting some time on our line to build more development boards. 4-6 weeks is usually the standard lead time value, usually quoted in better times, on Spartan families if you buy them in any numbers. The general components shortage is only starting to improve and Xilinx are doing a much better job than most vendors. It's not quite a paradise yet but I expect Q1/2011 we will be back to nearly normal supply conditions and almost certainly for FPGA availability. John Adair Enterpoint Ltd. On Nov 21, 9:12=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > John Adair <g...@enterpoint.co.uk> wrote: > > .. > > > large numbers. Digikey are showing stock in the TQFP package. > > ... with a constant lead time 6 weeks in the future. > > -- > 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 ----------Article: 149744
Greetings, I have an FPGA board that has JPEG 2000 images stored in its memory and need to send the images to another device that has a Cemara Link standard-based interface. The Camera Link docuement explains the overall communication protocol: for example for a basic interface there are 3 8-bit pixel-data lines and 3 main control signals FVAL, DVAL, and LVAL. In my case, the images that I have are in the following format: meta data + byes of image data. In the case of basic interface, do I just load the image data 3 bytes at a time, put them in parallel on the pixel-data lines while the FVAL, DVAL, LVAL signals are raised until the end of image bytes? Is this the basic idea? Thank you in advance for your time, look forward to your kind reponse. -Shervin --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149745
On Nov 22, 11:56=A0am, "Shervin" <Shervin.Mehryar@n_o_s_p_a_m.mdacorporation.com> wrote: > Greetings, I have an FPGA board that has JPEG 2000 images stored in its > memory and need to send the images to another device that has a Cemara Li= nk > standard-based interface. The Camera Link docuement explains the overall > communication protocol: for example for a basic interface there are 3 8-b= it > pixel-data lines and 3 main control signals FVAL, DVAL, and LVAL. In my > case, the images that I have are in the following format: meta data + bye= s > of image data. In the case of basic interface, do I just load the image > data 3 bytes at a time, put them in parallel on the pixel-data lines whil= e > the FVAL, DVAL, LVAL signals are raised until the end of image bytes? Is > this the basic idea? =A0 > > Thank you in advance for your time, look forward to your kind reponse. > > -Shervin > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com It would be best to find out from the company that makes your framegrabber if they need any special formatting. Many times you need to keep a constant line size and frame size, which is not really appropriate for JPEG images, since their size depends on the complexity of the image. Some framegrabbers will drop any data that is sent beyond the length of the defined line or image width. Also if you are using the "base" Camera Link hardware and want to use three bytes, be aware that most framegrabbers only allow this for RGB mode, so the three bytes are regarded as one "pixel". If you are making the logic for both ends of the interface you can obviously do anything you want. We have made cameras and framegrabbers that can handle JPEG compressed images using a straightforward frame interface that does not require LVAL to toggle. It's been a while since we did this, but as I recall we used a 2-tap mode (16 bits per clock) and used the DVAL signal to indicate valid data because the rate data came from the JPEG compression core was not constant. Camera Link does not have any provisions for variable length frames, so there's no standard way to do this. HTH, GaborArticle: 149746
Hi, please, how can I find out the minimum clock period (the maximum clock frequency in MHz) of a combinational circuit (for example, for a full adder) ? After the synthesizing and implementation I got the following message: Clock Information: ------------------ No clock signals found in this design Asynchronous Control Signals Information: ---------------------------------------- No asynchronous control signals found in this design Timing Summary: --------------- Speed Grade: -4 Minimum period: No path found Minimum input arrival time before clock: No path found Maximum output required time after clock: No path found Maximum combinational path delay: 9.033ns Is there any way to know the minimum clock period ? Thanks :) --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149747
>Hi, >please, how can I find out the minimum clock period (the maximum clock >frequency in MHz) of a combinational circuit (for example, for a full >adder) ? >After the synthesizing and implementation I got the following message: > >Clock Information: >------------------ >No clock signals found in this design >Asynchronous Control Signals Information: >---------------------------------------- >No asynchronous control signals found in this design >Timing Summary: >--------------- >Speed Grade: -4 > Minimum period: No path found > Minimum input arrival time before clock: No path found > Maximum output required time after clock: No path found > Maximum combinational path delay: 9.033ns > >Is there any way to know the minimum clock period ? > >Thanks :) Is your adder driven by data that is clocked? Looking at the report it seems that there are no clocked devices in your design. The minimum period will be derived using the worst case delay between clocked primitives. If you dont have any it cant calculate it. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149748
Thank you Gabor for your useful tips. I will try to bug the company for some more information and see if I can do anything about it. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149749
Hi everyone I've heard from a friend of a friend that running synthesis and implementation with a solid-state drive can yield substantial speed gains compared with the same process run on a machine with a regular hard drive. Are there any FPGA designers here that have tried it? If so, is there any truth to that statement and can you tell how much performance has been gained? Best regards
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