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 Thu, 29 Nov 2007 15:42:45 +0100, "Denkedran Joe" <denkedranjoe@googlemail.com> wrote: >Hi all, > >I'm working on a hardware implementation (FPGA) of a lossless compression >algorithm for a real-time application. The data will be fed in to the >system, will then be compressed on-the-fly and then transmitted further. > >The average compression ratio is 3:1, so I'm gonna use some FIFOs of a >certain size and start reading data out of the FIFO after a fixed >startup-time. The readout rate will be 1/3 of the input data rate The size >of the FIFOs is determined by the experimental variance of the mean >compression ratio. Nonetheless there are possible circumstances in which no >compression can be achieved. Since the overall system does not support >variable bitrates a faster transmission is no solution here. > >So my idea was to put the question to all of you what to do in case of >uncompressibility? Any ideas? > >Denkedran Joe Given the constraints you have put on the problem, you're kinda left with reducing the incoming data rate or dropping packets. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.comArticle: 126676
On Thu, 29 Nov 2007 09:44:37 -0000, "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote: >> The thing to watch out for is signal-signal crosstalk, especially on >> clock lines. Clocks need especially serious signal integrity treatment >> these days. And "clocks" includes CCLK! > > >We've been following one of the Micron app notes here, especially wrt >the clocks. It's a fairly short pt to pt connection so hopefully we >should be OK. > >Thanks, > >Nial. > We've found that a lot of cheap surface-mount crystal oscillators have a combination of sub-ns rise time and weak drive. So if they drive a few inches or more of trace, their output step can have a plateau right in the ballpark of Vcc/2, which is like hanging out a welcome sign for noise. The fpga clock inputs are very fast and have little or no hysteresis, so a tiny amount of crosstalk noise can result in multiple clockings on either edge. CCLK can be a problem, too; we often buffer it with a Tiny Logic schmitt right at the fpga, especially if it's a shared SPI clock that goes everywhere. JohnArticle: 126677
On Nov 29, 8:42 am, "Denkedran Joe" <denkedran...@googlemail.com> wrote: > Hi all, > > I'm working on a hardware implementation (FPGA) of a lossless compression > algorithm for a real-time application. The data will be fed in to the > system, will then be compressed on-the-fly and then transmitted further. > > The average compression ratio is 3:1, so I'm gonna use some FIFOs of a > certain size and start reading data out of the FIFO after a fixed > startup-time. The readout rate will be 1/3 of the input data rate The size > of the FIFOs is determined by the experimental variance of the mean > compression ratio. Nonetheless there are possible circumstances in which no > compression can be achieved. Since the overall system does not support > variable bitrates a faster transmission is no solution here. > > So my idea was to put the question to all of you what to do in case of > uncompressibility? Any ideas? > > Denkedran Joe If the compression must be lossless, and you can not increase the bit rate, you need to allow for the buffering of the input data to grow in size to accommodate the worst case. If you can not build a big enough FIFO inside the FPGA, add some external memory and use it as a FIFO. Is the hardware already designed? What are your data rates, and do you know what the worst case compression is? Regards, John McCaskill www.fastertechnology.comArticle: 126678
Denkedran Joe wrote: > > I'm working on a hardware implementation (FPGA) of a lossless > compression algorithm for a real-time application. The data will > be fed in to the system, will then be compressed on-the-fly and > then transmitted further. > > The average compression ratio is 3:1, so I'm gonna use some FIFOs > of a certain size and start reading data out of the FIFO after a > fixed startup-time. The readout rate will be 1/3 of the input > data rate The size of the FIFOs is determined by the experimental > variance of the mean compression ratio. Nonetheless there are > possible circumstances in which no compression can be achieved. > Since the overall system does not support variable bitrates a > faster transmission is no solution here. > > So my idea was to put the question to all of you what to do in > case of uncompressibility? Any ideas? Bigger buffers. Smarter algos. -- Chuck F (cbfalconer at maineline dot net) <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.comArticle: 126679
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in message news:5r7esrF12d91kU1@mid.individual.net... >> I would never split a plane except as a last resort (unless you can >> sandwich it between two solid planes - I often use a four layer GND, >> split power, split power, GND sandwich in the middle of 16-20 layer >> boards), because of the issues with traces crossing the split. > > As you say below signals can use the PWR plane as a 'pseudo gnd'. > > By using this stack are you not loosing the ability to route two internal > signal layers adjacent to the GND planes, and the additional use of the > PWR planes as pseudo grounds? > > Nial. > No, because everything is referenced to ground. My favorite stackups are: 12-layer S, G, S, S, G, P, P, G, S, S, G, S 14-layer microvia S, S, G, S, S, G, P, P, G, S, S, G, S, S 18-layer S, G, S, S, G, S, S, G, P, P, G, S, S, G, S, S, G, S 20-layer microvia S, S, G, S, S, G, S, S, G, P, P, G, S, S, G, S, S, G, S, S S = Signal, G = Ground, P = Power. Microvias are laser-drilled vias going from the outside down just one layer - makes double-sided fan-out on high density boards much easier. The advantages of these stackups are: 1. All signal layers are referenced to a real ground plane. 2. For normal board thicknesses (1.6 - 2.5 mm) it is easy to get 50-ohm single-ended and 100-ohm differential impedance on the inner signal layers with 4 mil track and gap (the outers give you about 42 ohms with 5 mil traces). 3. You can use ZBC cores on the innermost power stack up achieve buried capacitance decoupling. 4. You can split the power planes as much as you like without having to worry about signal integrity, because the splits are caged. 5. You can adjust the thickness of the board by changing the prepreg between the two power layers without having any real effect on the electrical characteristics. The possible disadvantages are: 1. The via length down to the power planes will be longer than had the planes been closer to the surface, but this is unlikely to cause a problem. 2. The board cost in increased somewhat over a six or eight layer one, but not by as much as you might think.Article: 126680
I am new to EDK (but not ISE) and have some questions about the workflow for developing a custom IPIF peripheral. The documentation implies that the peripheral is re-imported into EDK once it's development is *complete*. But what if one wants to work iteratively? That is, I would like to start with a stubbed-out design (the one provided in user_logic.vhd) and add to it incrementally, debugging and testing the peripheral from the processor along the way. Is there a simple way to do this? Or does one have to re-import the design every time a internal structural change is made? (The external specification will remain the same.) Thanks, AntonArticle: 126681
chesi, I am looking into this now. My concern is that feeding a phase shifted clock out of one DCM into another that is set to multiply by ten (10) may not work (I never simulated that case). Not sure what the second DCM will do while the input clock is changing phase (it might lose lock). I am presuming that your problem is not with the second DCM, but with the first one? It does not perform the negative phase shifts between 20 and 28 counts? At 27 MHz, that is a 37 ns period, so each count is 27,000/256 =~ 105 ps. Given that there is a finite number of delay taps, I believe the lower frequency limit is 19 MHz, there should be no reason you are running out of taps (and the status register would indicate overflow or underflow, and you would lose lock). I will discuss this, and post again. AustinArticle: 126682
"CBFalconer" <cbfalconer@yahoo.com> wrote: > > Bigger buffers. Smarter algos. > Ah okay, now that's why I'm here! Let's discuss some ideas of smarter algos!Article: 126683
On Nov 29, 9:38 am, Anton Kowalski <AntonKowal...@gmail.com> wrote: > I am new to EDK (but not ISE) and have some questions about the > workflow for developing a custom IPIF peripheral. > > The documentation implies that the peripheral is re-imported into EDK > once it's development is *complete*. But what if one wants to work > iteratively? That is, I would like to start with a stubbed-out design > (the one provided in user_logic.vhd) and add to it incrementally, > debugging and testing the peripheral from the processor along the way. > Is there a simple way to do this? Or does one have to re-import the > design every time a internal structural change is made? (The external > specification will remain the same.) > > Thanks, > Anton In the MPD file for your peripheral, add the line: OPTION CORE_STATE = DEVELOPMENT This will cause EDK to not cache the synthesis results for your peripheral. For simulation, I just use the clean option, then regenerate the simulation files if I change the peripheral. If you are not changing the data files (MPD, TCL, etc), you do not need to rescan the repository. If you are creating your own peripheral in EDK, you will want to read the "Platform Specification Format Reference Manual" located at $EDK/ doc/psf_rm.pdf Regards, John McCaskill www.fastertechnology.comArticle: 126684
>> Bigger buffers. Smarter algos >Ah okay, now that's why I'm here! Let's discuss some ideas of smarter algos! Let's not. Instead, start here and study for a few weeks, then get back to us: http://en.wikipedia.org/wiki/Lossless_data_compressionArticle: 126685
On Nov 29, 3:46 am, "heinerl...@googlemail.com" <heinerl...@googlemail.com> wrote: > Hi, > > we are using an asynchronous FIFO to bridge two clock domains. Both > domains have "the same" clock speed but different clock oscillators. > > We shift data phits in the FIFO which always form a data packet. In > between a packet data is shifted in continously without a break. > Breaks (no shift in) are only allowed in between packets. > On the output side of the FIFO we need a steady data stream during a > data packet. The packet may not be interrupted. As the input side may > be slower we start shift-out data if at least two data phits are in > the FIFO. As the 2 clocks have almost the same frequency this > guarantees that we never have a buffer underflow. > > The problem we found is that the almost empty flag is only asserted if > the FIFO is beeing emptied and not if it is beeing filled. So if the > FIFO was empty and we get a shift in the almost empty is not asserted > although we set the treshold to one. Is this a bug? Which FPGA family, which type of FIFO controller, and also what clock rate? Peter Alfke, Xilinx Applications> > We tried to solve that problem by generating a delay-empty signal at > the output which guarantees that if the FIFO was emtpy and than > receives a shift in we still wait another cycle so we get another > shift in to avoid underflow. > > This solution however does not solve the problem if the FIFO exactly > had one entry when starting to shift out a packet. In this case > neither delayed-empty nor almost empty is asserted, hence we get an > underflow. > > Why isn't the almost empty signal asserted every time there is a > single packet in the FIFO? Ideas?Article: 126686
"Didi" <diditgi@gmail.com> wrote in message news:0fb44a5a-ceba-4643-87ad-4ea2f1ed60f2@a39g2000pre.googlegroups.com... > > Again, 120 MHz is nearly DC nowadays. You don't need any > fancy SI tools to do it. > > Dimiter > > It's not the frequency that matters, but rather the edge rate. It is the behavior of the edges that are altered by the characteristics of a transmission line. The frequency just indicates how often such edges occur. This is why many older designs fail when a manufacturer introduces a faster, die-shrunk, version of a part. Although the application is using the part in the same way, the unavoidable change in edge rate can break a previously working board.Article: 126687
On Nov 29, 6:42 am, "Denkedran Joe" <denkedran...@googlemail.com> wrote: > Hi all, > > I'm working on a hardware implementation (FPGA) of a lossless compression > algorithm for a real-time application. The data will be fed in to the > system, will then be compressed on-the-fly and then transmitted further. > > The average compression ratio is 3:1, so I'm gonna use some FIFOs of a > certain size and start reading data out of the FIFO after a fixed > startup-time. The readout rate will be 1/3 of the input data rate The size > of the FIFOs is determined by the experimental variance of the mean > compression ratio. Nonetheless there are possible circumstances in which no > compression can be achieved. Since the overall system does not support > variable bitrates a faster transmission is no solution here. > > So my idea was to put the question to all of you what to do in case of > uncompressibility? Any ideas? > > Denkedran Joe You cannot solve your problem losslessly. You must guarantee your image is in a state that will guarantee compressibility or your stream will occasionally require more bandwidth than is available; you'd need infinite FIFOs to cover worst-case situations. You MUST have a lossy fallback OR supply enough bandwidth to accommodate uncompressed data as a fallback. Variable bit-rate multi- channel systems can borrow bandwidth from each other since - statistically - all channels do not experience poor compression at once unless they're all transmitting similarly uncompressible images. If your video is dynamic in movement and in color for a length of time, your stream will exceed your channel bandwidth. If you have very large (disk based?) FIFOs, you can drop video for a short time and pick back up when the compressed stream is better behaved and you can receive continuous video again. You will not be able to recover the delay that you introduced from the compression on the receive side unless you skip some received video (which is lossy) or speed up the playback. Can you deal with a fixed delay of seconds or minutes once you've experienced a period of poor compression? No lossless compression scheme can compress everything. You can only have better compression schemes that will fail less often or present a fallback: lossy compression or variable bit rates. There are no finite alternatives; it's one of the basic principles of compression. There are no smarter algos, just better compression schemes that fail less often. - John_HArticle: 126688
> Are you using Impact? Chipscope? Synplicity's Identify? If you have > anything else that does JTAG, get a second opinion. > > Help us help you - please specify what board and what software. Oh I wish someone of you could help me a out a little bit ;). Anyway I installed ISE 7.1 and the drivers for the ADM-XRC-II board on another machine. I connected and installed the MultiLinx cable to the board and used Impact to get the devices in the boundary scan. Again I can just see the Xilinx xc9572xl CPLD in the boundary scan. According to section 6.3 of the ADM-XRC-II manual, the FPGA (VirtexII) and CPLD are on the same JTAG chain, so both should be visible in the software: http://www.alphadata.co.uk/pdf/ADM-XRC-II%20User%20Manual.pdf Any helpful comments are appreciated!Article: 126689
> Whether it's a development board or > your own board, you should be able to find schematics. These schematics > may show the JTAG pins of the FPGA (TDI, TDO, TCLK, TRST or similar > names) either unconnected or connected to a specific JTAG connector or > JTAG chain. And yes, I have exactly set up this connections to the FPGA board which should be fine but there is still just this one CPLD in my boundary scan!Article: 126690
It means "120 MHz clock rate is nearly DC nowadays", I thought it was obvious from the context. On Nov 29, 6:41 pm, "David Spencer" <davidmspen...@verizon.net> wrote: > "Didi" <didi...@gmail.com> wrote in message > > news:0fb44a5a-ceba-4643-87ad-4ea2f1ed60f2@a39g2000pre.googlegroups.com... > > > Again, 120 MHz is nearly DC nowadays. You don't need any > > fancy SI tools to do it. > > > Dimiter > > It's not the frequency that matters, but rather the edge rate. It is the > behavior of the edges that are altered by the characteristics of a > transmission line. > .... Of course so, I meant "120 MHz clock rate is nearly DC nowadays", I thought it was obvious from the context. It applies to the concrete DDRAM case allright. DimiterArticle: 126691
"Denkedran Joe" <denkedranjoe@googlemail.com> writes: > Hi all, > > I'm working on a hardware implementation (FPGA) of a lossless compression > algorithm for a real-time application. The data will be fed in to the > system, will then be compressed on-the-fly and then transmitted further. > > The average compression ratio is 3:1, so I'm gonna use some FIFOs of a > certain size and start reading data out of the FIFO after a fixed > startup-time. The readout rate will be 1/3 of the input data rate The size > of the FIFOs is determined by the experimental variance of the mean > compression ratio. Nonetheless there are possible circumstances in which no > compression can be achieved. Since the overall system does not support > variable bitrates a faster transmission is no solution here. > > So my idea was to put the question to all of you what to do in case of > uncompressibility? Any ideas? You will need to specify your data integrity contraints. If your real-time constraints are soft, then big buffers will make the problem less common, but not get rid of it entirely. If you've got hard real time constraints, then they won't, as the data will be stale before you've had a chance to send it. Either way, you must be prepared to throw some data away under some situations. The question then becomes chosing what to throw away, and how to make sure that the recipient can also cope with the lost data. However, if you know something about your source data that general purpose algorithms don't know, then perhaps you can achieve a guaranteed compression ratio from a bespoke algorithm. What's in your data? Phil -- Dear aunt, let's set so double the killer delete select all. -- Microsoft voice recognition live demonstrationArticle: 126692
"KJ" <kkjennings@sbcglobal.net> wrote in message news:jRy3j.3053$Dt4.871@newssvr19.news.prodigy.net... > > "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in > message news:5r7d87F1326q5U1@mid.individual.net... >>> I disagree, as does most of the research done into the subject. The use >>> of buried capacitance, typically by having adjacent power and ground >>> planes separated by as small a distance as possible (2 thou is normal), >>> has been shown to be very favorable when compared to discrete decoupling >>> caps because although the capacitance is much lower the inductance is >>> very much lower so the overall impedence is significantly lower. There >>> is an article about it here: >>> http://www.ddmconsulting.com/Design_Guides/bcguide.pdf >> >> David, >> >> I too am skeptical about the amount of decoupling that close GND/PWR >> plane >> coupling can provice. >> >> In that atricle above they quote 560pF/sq inch. Most BGAs are smaller >> than that. >> > > It's not so much the capacitance as it is the lowered inductance that the > closely spaced planes brings you. Having a fire hydrant near a burning > house doesn't help much if you only have a garden hose to deliver the > water. The inductance of the power delivery network is the thing that > delivers the power from the source to the load. > > KJ > Hi KJ, This is a good analogy. I say the garden hose is between the planes and the FPGA. It matters not a jot if the planes had zero impedance, the BGA balls, and the vias to them, are the bottleneck that makes the plane capacitance moot. Cheers, Syms.Article: 126693
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in message news:5r7gc7F12nc8dU1@mid.individual.net... > > Looking at the complexity/density/performance of a typical PC motherboard > I'm still impressed at the price they knock them out for. > Hi Nial, I doubt they press the 'autoroute' button on their PCB CAD tool! Cheers, Syms.Article: 126694
"David Spencer" <davidmspencer@verizon.net> wrote in message news:_YB3j.26538$XT.7448@trnddc01... > > It's not the frequency that matters, but rather the edge rate. It is the > behavior of the edges that are altered by the characteristics of a > transmission line. The frequency just indicates how often such edges > occur. This is why many older designs fail when a manufacturer introduces > a faster, die-shrunk, version of a part. Although the application is using > the part in the same way, the unavoidable change in edge rate can break a > previously working board. > Hi David, To be technically correct (the best kind of correct!) it's not the edge rate, but the rise time. :-) I'm sure that's what you meant, I'm just being pedantic... HTH, Syms.Article: 126695
"Symon" <symon_brewer@hotmail.com> wrote in message news:fims50$arc$1@aioe.org... > Hi David, > To be technically correct (the best kind of correct!) it's not the edge > rate, but the rise time. :-) I'm sure that's what you meant, I'm just > being pedantic... > HTH, Syms. > Or "fall time". ;) The point I was trying to make (and which I'm still not sure Didi fully got) was that if a device is designed such that its outputs can operate at, say, 200 MHz, then running that device at 1 MHz will not generally magically improve the signal integrity.Article: 126696
On Nov 29, 3:46 am, "heinerl...@googlemail.com" <heinerl...@googlemail.com> wrote: > Hi, > > we are using an asynchronous FIFO to bridge two clock domains. Both > domains have "the same" clock speed but different clock oscillators. > > We shift data phits in the FIFO which always form a data packet. In > between a packet data is shifted in continously without a break. > Breaks (no shift in) are only allowed in between packets. > On the output side of the FIFO we need a steady data stream during a > data packet. The packet may not be interrupted. As the input side may > be slower we start shift-out data if at least two data phits are in > the FIFO. As the 2 clocks have almost the same frequency this > guarantees that we never have a buffer underflow. > > The problem we found is that the almost empty flag is only asserted if > the FIFO is beeing emptied and not if it is beeing filled. So if the > FIFO was empty and we get a shift in the almost empty is not asserted > although we set the treshold to one. Is this a bug? In a synchronous (single-clock) FIFO, flag control is very simple, done by a synchronous state machine. With asynchronous (unrelated clocks) operation, flag control is very complex, if metastable posssibilities must also be considered. Almost Empty is generally considered a warning flag that can have a one-count ambiguity. Empty is the most important flag, and its rising edge is not allowed to have any uncertainty. The trailing edge of EMPTY, however, often has an additional delay, so as to avoid metastability. My advice: trust the rising edge of the Empty flag, expect its falling edge to have an additional pipeline delay, and treat the Almost Empty flag just as a warning. Peter Alfke > We tried to solve that problem by generating a delay-empty signal at > the output which guarantees that if the FIFO was emtpy and than > receives a shift in we still wait another cycle so we get another > shift in to avoid underflow. > > This solution however does not solve the problem if the FIFO exactly > had one entry when starting to shift out a packet. In this case > neither delayed-empty nor almost empty is asserted, hence we get an > underflow. > > Why isn't the almost empty signal asserted every time there is a > single packet in the FIFO? Ideas?Article: 126697
On Nov 29, 12:41 pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Wed, 28 Nov 2007 08:59:30 -0800 (PST), Rgamer <rgamer1...@gmail.com> > wrote: > > >I understood. And thanks for all for the replies. > > >So, I can't use a global line for reset and like all Xilinx guys say, > >I shouldn't use it. > >IMHO the lack of reset circuitry is a serious flaw. > >I have a global enable too, that must get everypart of the design. > >Again, no way to use it as global. This is even a more serious flaw, > >since enable is the best design pratice regarding FPGAs. > > >I think I'll have to prey that PAR meet my timing constraints, as they > >are somewhat tight... Does anyone have a better idea than using low > >skew lines? > > If you control your design from some central state machine, add several > states between the "reset" state and the central despatcher state (e.g. > "idle" where you wait for inputs to react to and depatch to states that > do the work). > > That guarantees that nothing else in your design will be active for > those several cycles; therefore reset to anything OUTSIDE these states > can be constrained as a multicycle path. > > - Brian I thought another solution for either global reset and global enable: I kept the global buffer, since it has more strength (greater fanout) and I added the attribute for low skew lines. That should do a good job. Regards,Article: 126698
On Nov 29, 7:25 pm, "David Spencer" <davidmspen...@verizon.net> wrote: > "Symon" <symon_bre...@hotmail.com> wrote in message > The point I was trying to make (and which I'm still not sure Didi fully got) > was that if a device is designed such that its outputs can operate at, say, > 200 MHz, then running that device at 1 MHz will not generally magically > improve the signal integrity. I got the point you made with your first post. In goes into details I explicitly did not want to go into, because one does not need to do it in this case, this is the essence of my point. It can be detailed as "at 120 MHz DDR clock frequency edges and generally related parts on the market are nearly as easy to use as if they were DC nowadays". I expected the "nowadays", put in context with the links to some board photos I provided, to make the point obvious enough. Clearly you do have to treat transmission lines as such, but no extra effort except keeping in mind you are doing that is necessary. I hope my point is now clear enough :-). BTW, how many persons do you know who have designed boards of comparable complexity/density/speed to those I showed in the thread who would have a problem getting the point you made (which says it is not the frequency but the timing relationships which matter, put in a more general way)? .... :-) :-) Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ In fact the denser board - http://tgi-sci.com/misc/PICT3084.JPG - is routed by me 7 years ago, with 100 MHz SDRAMs at the photo. > > news:fims50$arc$1@aioe.org...> Hi David, > > To be technically correct (the best kind of correct!) it's not the edge > > rate, but the rise time. :-) I'm sure that's what you meant, I'm just > > being pedantic... > > HTH, Syms. > > Or "fall time". ;) > > The point I was trying to make (and which I'm still not sure Didi fully got) > was that if a device is designed such that its outputs can operate at, say, > 200 MHz, then running that device at 1 MHz will not generally magically > improve the signal integrity.Article: 126699
> And yes, I have exactly set up this connections to the FPGA board which > should be fine but there is still just this one CPLD in my boundary scan! Alright, my mistake. Actually there is another JTAG interface hiden between the two boards. With this one it should work. Sorry for the confusion!
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