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
Antti wrote: > New low cost families other than from Xilinx are known to be coming > this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info > an Spartan-4 yet, is there a hope at all that there will be modern low > cost family from Xilinx too? > > Spartan-3 is 'not for new designs' as there is no price roadmap for it, > Spartan-3E only has small members, eg not replacement for S3 > > so we have vacuum in the place of Spartan-4 ! > > I wonder if that vacuum will be filled with Cyclone-3 or is Spartan-4 > coming this autumn? > > Antti I don't know about positioning but http://tinyurl.com/fvup6 (or http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=23856)Article: 107426
KJ wrote: > rickman wrote: > > The fanout of an async reset in an FPGA is not an issue because the > > signal is a dedicated net. > My point was that if timing is not met due to the large fanout, that > the typical fitter will allow for the fanout to be limited by the user > if necessary. But to directly answer the original question, 'no' I > haven't had reset signal fanout as a problem but if I did I know I > could fix it by limiting the fanout on the fitter side without having > to change the source code. But I also tend to reset only those things > that really need resetting which, by itself, cuts down on the fanout as > well. I don't know exactly what you mean by fanout. If a sync reset has to go to 100 FFs, then there is nothing you can do to tell the fitter to change that. The async reset is free, or actually already paid for, so if it does the job why not use it? > > That is what I addressed above. Whether the circuit will malfunction > > depends on the circuit as well as the inputs preset. It is often not > > hard to assure that one or the other prevents the circuit from changing > > any state while the reset is released. > > > But simply synchronizing the reset in the first place will do that as > well...two different approaches to the problem, each equally valid. Both valid, but typically I find the async reset takes less effort and resources. Only a small portion of my typical design has to be controlled coming out of reset. > Agreed, but one can also view these locally generated resets as simply > synchronized versions of the original reset. In fact, the synthesizer > would probably do just that seeing that you have (for example) 4 places > throughout the design where you've generated a local reset which is > simply the raw reset signal brought into a flip flop chain (I think > that's what you're describing). So it would take those four instances > and probably generate a single shift chain and local reset signal to > send to those 4 places. So all you've really done is written the > source code for the local reset 3 more times than is needed. Had you > taken the view that the reset input to those 4 places must be a > synchronized reset signal in the first place you probably would've > written the reset shift chain logic one time at a top level and > connected it up to those four inputs yourself and not written it on the > receiver side. Yes, that is exactly how I think of it, a local sync'd reset. Putting it where it is needed is both very clear and saves resources. I never use this in place of the async reset, but rather to supplement it for synchronization. Much of the logic has to be reset, but very little of it has to be synchronously released from reset. > > This is not a problem when you use the dedicated reset net. > I agree, but I was referring more to the reset signal distribution on a > board rather than inside an FPGA. I understand, but noise still can upset a sync reset. This is just not a workable solution to noise. > > Even though there are FFs that do not need a reset, it does not hurt to put > > the entire device in a known state every time. > OK, it doesn't 'hurt', but it doesn't 'help' either in the sense that > both approaches would meet the exact same requirements of the > functional specification for that part. I don't agree. By globally resetting the device, you have handled all FFs so that if your requirement misses one, you don't find out about it after the unit is in the field. > > It is not hard to miss a FF that needs to be reset otherwise. > Inside the FPGA it doesn't matter since if you discover something that > you now realize needs to be reset you re-route and get a new file. Not > routing it to a part on a board and then discovering you need it is a > bit more of an issue. Resolving that issue by routing reset to every > part and then using it asynchronously is where problems have come up > when there are a lot of parts on the board. The question is when do you find out about the missing reset? It is easy for this sort of thing to slip totally through testing and only show up in the users's hands. > > Personally I think the noise issue is a red herring. > If it's a red herring than I can safely say that I have slayed several > red herrings over my career...but actually not many of late....not > since a certain couple designers moved on to to greener pastures to be > brutally honest. I assume you mean board designers who were not producing quiet boards? > > If you have noise > > problems on the board, changing your reset to sync will not help in > > general. You would be much better off designing a board so it does not > > have noise problems. > Maybe. But remember the scenario when you're brought in to fix a > problem with an existing board that you trace back to some issue with > reset. In that situation, a programmable logic change is more likely > the more cost effective solution. I am in a fairly long thread in comp.arch.embedded about how to design boards so that you don't have SI and EMI issues. I think this sort of problem should be dealt with before you make the board, not after it is in the field. Too many engineers learn to cover their butts rather than to produce good designs. I am tired of working that way and not really knowing if my design will work before it is shipped. The one universal rule I learned very early on is that you can not prove a product works correctly by testing. It has to be designed to work correctly by using design methods based on understanding what you are doing. I have never seen a board noise issue that could be fixed by an FPGA design change.Article: 107427
Hi ... I had an EDK project which took longer and longer to load. In the begining this was tolerable as there were not many changes but this got worse and finally the project took over 1 hour to load. I found out that my .xmp project file has grown to 12 MBytes (containing the same lines with LockAddr: again and again). Deleting most of those lines helped but the file started to grow again! what is wrong with that? how can I stop this? ... did anyone at Xilinx ever use their tools for a real project? bye, MichaelArticle: 107428
Rick, Via in pad (basically no trace) is best. Placement is not critical, as long as you have via in pad, and planes. But even so, the diameter of the vias, and their lengths can be critical, and still be the dominant factor. It is all about the lop that is formed (see the HK sparse chevron presentations, as I think he said it best). Do you need a broad low impedance? I would say that it is most unusual that a pcb has to work over all frequencies. The system is usually designed with a finite number and range of clocks (33 MHz, 266 MHz, 78 MHz, for example). I would counter that rather than a flat broad low impedance, you could do better to target just the frequencies you care about. High loss/low loss is a red herring: I have never seen a case where the type of capacitor made any difference at all. I would be interested if anyone has made a board where high loss/loss loss caps actually made a measurable difference, Austin rickman wrote: > Austin Lesea wrote: >> To the subject at hand: placing additional caps across existing caps >> does not reduce the noise (unless the dominant cause is lack of adequate >> capacitance). >> >> The reason why the noise is bad is that the L (as in Ldi/dt) is most >> likely the largest, and most dominant factor, in the form of the via and >> traces to the bypass capacitor. >> >> Many times people have placed additional caps on top of the the existing >> caps and wondered why the noise is not reduced: well, you did not >> change the L in the equation, did you. So why did you expect V to change? >> >> You may have moved the resonant frequency (more often not), but often >> people make the mistake of assuming that a 0.1uF requires a 0.01uF and a >> 0.001uF in parallel. You can see that if the series L is dominant, you >> haven't even moved the frequency by more than a few percent by the small >> amount of additional capacitance. > > What do you think about the idea that if the caps are connected > directly to good low impedance power planes that the location of the > caps are not critical at all. I have been discussing this in > comp.arch.embedded and have not gotten much negative feedback except > some claim that more is always better and that multiple values are not > needed. > > A recent SI/EMI class I took says that you can put a relatively small > number of caps pretty much anywhere on the board as long as they are > coupled to the power planes with no traces, just the via. This gives a > very low impedance connection to the planes and the planes give a very > low impedance connection to the chip. It was also shown that to get a > low impedance over a broad bandwidth multiple values are needed to push > the impedance down and the parallel resonance up. High loss capacitors > (X7R/X5R vs. C0G) were also recommended to reduce the signficance of > the parallel resonance. > > Does any of this sound correct to you? It was sure convincing in the > class and appears to be a very sure way of getting low noise on the > power planes and thereby on the chip power pins! >Article: 107429
Uwe, The on-chip capacitors are a compromise. They are intended to improve the energy storage (reduce supply sag, reduce jitter, etc.) but they are not intended to be the entire solution, nor should they affect the overall PDS design. Given that we have room for maybe 16 total capacitors, and their values (each) is ~0.1uF, they are at best useful, and at worst, provide little improvements at all. Since we can not choose these values for a specific operation frequency, they may be useful for only some frequencies, and not useful at others. We have worked with customers who wish to completely model everything, and when we supply the geometric model (suitable for Ansoft, or other E&M tool), we also supply the capacitors for that package being modeled. I would say that for the 0.1% of customers who are pushing the part to its absolute limits in their design, that these capacitors may be important, and they may be required (as input values) in order to properly optimize/design the rest of the PDS. If you desire more information about a particular package, please contact your FAE, who will be able to contact the factory to get the values, and on what supplies, the internal capacitors are. Austin Uwe Bonnes wrote: > Austin Lesea <austin@xilinx.com> wrote: > > >> To the subject at hand: placing additional caps across existing caps >> does not reduce the noise (unless the dominant cause is lack of adequate >> capacitance). > >> The reason why the noise is bad is that the L (as in Ldi/dt) is most > ... > > On that subject: > The webpages for Spartan 5 talk about "Virtex-5 sparse chevron packaging > effectively positions bypass capacitors on-substrate" > > I didn't find any further information about these capacitors.Article: 107430
Kolja, I think you are doing extremely well if your cap inductance is dominant. I have seen many cases where the vias and traces to the capacitors are more than 1 nH. Many do not realize just how bad a small diameter via going through half a pcb can be. Austin Kolja Sulimma wrote: > Austin Lesea schrieb: > >> You may have moved the resonant frequency (more often not), but often >> people make the mistake of assuming that a 0.1uF requires a 0.01uF and a >> 0.001uF in parallel. You can see that if the series L is dominant, you >> haven't even moved the frequency by more than a few percent by the small >> amount of additional capacitance. > > Larger caps can contribute a significant portion to the L. In that case > the second capacitor helps because you reduce part of the L by adding a > smaller L in parallel to a portion of the big L. > The inductance for an SMT capacitor is in the range of 50pH to 3000pH. > This is about the same range as vias of various sizes. > > Kolja SulimmaArticle: 107431
Synplicity can infer DDR IOB input registers, but there are two outputs, one for each clock. If you need DDR functionality inside the FPGA (not in the IOBs), the only way I know of is two roll your own DDR flop from two SDR flops and 3 xor gates: ddr: process (clk, rst) is variable qr, qf : std_logic; begin if rst = '1' then qr := '0'; qf := '0'; elsif rising_edge(clk) then qr := d xor qf; elsif falling_edge(clk) then qf := d xor qr; end if; q <= qr xor qf; end process; Synplicity handles the above just fine, but Mentor Precision does not (it implements it incorrectly, with no warning!). ISE does not accept it. I think Quartus will take it. If your synthesis tool does not like the above, then split it out into separate processes: signal qr, qf: std_logic; re: process (rst, clk) is begin if rst = '1' then qr <= '0'; elsif rising_edge(clk) then qr <= d xor qf; end if; end process; fe: process (rst, clk) is begin if rst = '1' then qf <= '0'; elsif falling_edge(clk) then qf <= d xor qr; end if; end process; q <= qr xor qf; Andy Sylvain Munaut <SomeOne@SomeDomain.com> wrote: > > I have a little problem and I need some help. > > > > I program a controller for a DDR-SDRAM on a FPGA-Board (Virtex 4, Xilinx). > > > > For the synchronisation signal I need a process that is case sensitiv on > > both edges. > > > > But the following commands are not synthesizeable: > > > > " if DQS'event then..." > > You need to instanciate the DDR IOB flip flop by hand, you can't infer > them from > VHDL. Look at the templates in ISE for examples. > > And btw, are you gonna drive directly the IOB FF clk input from the DQS > signals ??? > > > > " if (DQS'event and DQS = '1') and (DQS'event and DQS = '0') then..." > > Hum ... the logic reduction of the condition you put is "if false then" > ... > > > SylvainArticle: 107432
In a related note, I had ISE 8 creating GB and GB of project folders, during the wonderful conversion process from ISE 7 to 8... It got in an endless loop upgrading a snapshot, as it automatically generated a sub folder with a new snapshot.. which was upgraded... giving another sub folder with a snapshot... which was upgraded... and so on until some hours later the harddrive was full. Excellent. Good luck bug hunting. Ben "Michael Schöberl" <MSchoeberl@mailtonne.de> wrote in message news:44f2fe03$1@news.fhg.de... > Hi ... > > I had an EDK project which took longer and longer to load. In the begining > this was tolerable as there were not many changes but this got worse and > finally the project took over 1 hour to load. > > > I found out that my .xmp project file has grown to 12 MBytes (containing > the same lines with LockAddr: again and again). Deleting most of those > lines helped but the file started to grow again! > > what is wrong with that? how can I stop this? ... did anyone at Xilinx > ever use their tools for a real project? > > > bye, > MichaelArticle: 107433
John_H schrieb: > Antti wrote: > > New low cost families other than from Xilinx are known to be coming > > this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info > > an Spartan-4 yet, is there a hope at all that there will be modern low > > cost family from Xilinx too? > > > > Spartan-3 is 'not for new designs' as there is no price roadmap for it, > > Spartan-3E only has small members, eg not replacement for S3 > > > > so we have vacuum in the place of Spartan-4 ! > > > > I wonder if that vacuum will be filled with Cyclone-3 or is Spartan-4 > > coming this autumn? > > > > Antti > > I don't know about positioning but > > http://tinyurl.com/fvup6 > > (or > http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=23856) Thanks John, its only visible from 8.2 SP2 but here is quick link to Spartan3A libraries guide :) http://toolbox.xilinx.com/docsan/xilinx82/books/docs/s3adl/s3adl.pdf it looks like the ICAP and therefore self-reconfiguration is added to Spartan-3A, but it still lacks the SPI or NOR flash configuration that is available on S3e. those the Spartan3A may be the replacement part for Spartan-3 meaning that Spartan-4 is possible even further away from being available, I was expecting Spartan-4 announcement of prelim info in 6 months from now, but guess we have to wait more. actually no, the Spartan3e is partial downgrade from s3e ? only xc3s50a, xc3s200a, xc3s400a, xc3s700a, xc3s1400a so no large Spartan3a devices either :( is the Spartan-3 family really the last big low cost Xilinx FPGA ?? http://xilant.com/index.php?option=com_content&task=view&id=28&Itemid=1 I wrote down the non-NDA info about Spartan3A there is now DNA port as direct primitive, to be linked with the genetic what? AnttiArticle: 107434
KJ wrote: > Whether you get the concise code or the bloated code for a particular > hardware design I've found is simply a function of > - The skill level of the person with the hardware design language that they > are using. > - The skill level of the person in hardware design. This is certainly one of several key determinates, as is the specific task and experience with it. > I could be wrong, but I haven't seen anything to indicate that the actual > language used itself is an important factor. Here we differ, even if just discussing VHDL/Verilog, in how FSM's are best constructed for clarity. I've read nearly 100 different coding styles, too many very difficult to issolate just exactly what the FSM really is. This is one area where language design makes a significant difference in maintainability. FSM's in C are just a natural byproduct of the for/do/while construction coupled with if/then/else constructions (or switch/case/break/continue if supported). Here, the C language is about describing flow control (the task at hand), not about describing instantiation (where flow control must be designed by construction). While it might be possible to build indirect FSM's as you do in VHDL/Verilog using C constructs, it's certainly not the native style of any C coder, even those that are also hardware trained. But again ... language is something of a religious war ... the real topic is reducing expression complexity, which is greatly abused by nearly all VHDL/Verilog designs I've read. This variation is certainly visible in the current thread on FSM construction, and the clearly different ideas about how this should be expressed.Article: 107435
bazarnik@hotmail.com wrote: > <snip> > > Obviously request will be active for several clock cycles. > This is beacuse some waiting time for acknowledge is necessary. > (If not then why would we need arbiter?) > > <snip> > > Cheers, > Przemek Not so obvious. Some arbiters contain logic to queue incoming requests and (for example) will interpret 4 continuous cycles of request assertion as 4 separate requests. This can be useful if your arbitration logic requires multiple cycles while being expected to handle a new request every cycle.Article: 107436
Austin Lesea wrote: > Many do not realize just how bad a small diameter via going through half > a pcb can be. Ahmen ....Article: 107437
Hello, The suggestion you have made didn't work. I couldn't find a suitable solution even in the answers database of xilinx. Sivakanth g.bernocchi@gmail.com wrote: > sivakanth.telasula@gmail.com ha scritto: > > > Hello, > > > > I am newbie learning Xilinx system generator. > > > > I have made a simple down sampler program which will just downsample > > the incoming signal and presents it as downsampled version. > > > > The simulink simulation runs well, but when I try to create a HDL > > netlist, the process just hangs in "Running Netlister". > > > > Can someone help with this issuse and can provide a solution. > > > > Sivakanth. > > Hi, > > Try to restart Matlab and delete the '.\netlist' directory. My design > (with sysgen 8.1) work correctly.Article: 107438
rickman wrote: > KJ wrote: > > rickman wrote: > I don't know exactly what you mean by fanout. If a sync reset has to > go to 100 FFs, then there is nothing you can do to tell the fitter to > change that. Yes you can. If for example, the timing analysis failed because of reset then you can tell the fitter to limit fanout to say, 20. Then what the fitter would do is replicate the flip flop that generates the reset signal so that there are 5 of them and distribute those 5 (logically identical) resets to those 100 loads. We can debate the extra resource usage of those 4 extra flops or that maybe there wouldn't have been 100 in the first place, but I think we've both made our points already. > The async reset is free, or actually already paid for, so > if it does the job why not use it? At what point do you want to find out that the answer to the question "if it does the job..." turns out to be "No, it doesn't do the job" because the designer of some hunk of code that you're integrating in didn't pay as close attention to resets as they should have and that the way that the code 'used' the reset, while implying it could be asynchronous really was not the case and that it needed to be synchronous after all? (Either that or 'fix' the errent hunk of code of course). > > But simply synchronizing the reset in the first place will do that as > > well...two different approaches to the problem, each equally valid. > > Both valid, but typically I find the async reset takes less effort and > resources. Only a small portion of my typical design has to be > controlled coming out of reset. And unless that small portion is actually 'zero' you'll need some synchronizer somewhere. In that case, I've found that resources differences is neglibile or non-existent. I'll accept that you may have seen differences and I don't want to get into the nitty gritty but I'll bet that those differences that you saw were pretty small as well. If not, then to what did you attribute the large difference would be interesting to know. As for effort, the only effort I see in either case is the coding which is identical. It's just a question of where you physically put the "if (Reset = '1) then"....or is there some other effort that you mean? > > > This is not a problem when you use the dedicated reset net. > > I agree, but I was referring more to the reset signal distribution on a > > board rather than inside an FPGA. > > I understand, but noise still can upset a sync reset. This is just not > a workable solution to noise. I'm not sure what solution you're referring to. All I'm saying is that use of a synchronous reset is less susceptible to a noise issue than an asynchronous one because it requires the noise to be somewhat coincident with the clock in order for it to have any effect. On a given board design though that coincidence will tend to either be near 0 or near 100%....but those near 0 ones don't need to be fixed because they're not broken if used synchronously. > > > Even though there are FFs that do not need a reset, it does not hurt to put > > > the entire device in a known state every time. > > OK, it doesn't 'hurt', but it doesn't 'help' either in the sense that > > both approaches would meet the exact same requirements of the > > functional specification for that part. > > I don't agree. By globally resetting the device, you have handled all > FFs so that if your requirement misses one, you don't find out about it > after the unit is in the field. Only if your requirement is that the flip flop be set to the state that you happened to have coded for it and not the other state. In any case, it's not sporting to say that one design approach is better because it has a chance that it just happened to code correctly for a missing requirement. Actual reset signal requirements are usually pretty benign and in many cases NOT coding it as a matter of course could lead one to finding this missing requirement earlier....during simulation. The scenario I'm thinking of here is that OK, the functional requirements has an as yet unidentified reset state. Based on that I code the design and do not do anything to signal 'ABC' as a result of reset. During simulation I find that I just can't get signal 'ABC' into the proper state (since it is an unknown at the end of reset) and that I need to because the logic tree that it feeds into requires 'ABC' to be in the proper state. In that situation the simulation has immediately hit on to the missing functional requirement and you can investigate, whereas coding to a specific value you have the chance of getting it right or not and not finding out until product is in the field. Starting with 'U' states in simulation and seeing your system simulation model drive the 'U' out as a result of signals other than 'reset' is a good indicator of things I've found. > > > > It is not hard to miss a FF that needs to be reset otherwise. > > Inside the FPGA it doesn't matter since if you discover something that > > you now realize needs to be reset you re-route and get a new file. Not > > routing it to a part on a board and then discovering you need it is a > > bit more of an issue. Resolving that issue by routing reset to every > > part and then using it asynchronously is where problems have come up > > when there are a lot of parts on the board. > > The question is when do you find out about the missing reset? It is > easy for this sort of thing to slip totally through testing and only > show up in the users's hands. > Simulation and the 'U' value in the std_logic type is the key here I've found to getting all initialization issues properly identified really early on, long before prototypes. > > > > Personally I think the noise issue is a red herring. > > If it's a red herring than I can safely say that I have slayed several > > red herrings over my career...but actually not many of late....not > > since a certain couple designers moved on to to greener pastures to be > > brutally honest. > > I assume you mean board designers who were not producing quiet boards? > And that then had problems that needed to be fixed. > > > > If you have noise > > > problems on the board, changing your reset to sync will not help in > > > general. You would be much better off designing a board so it does not > > > have noise problems. > > Maybe. But remember the scenario when you're brought in to fix a > > problem with an existing board that you trace back to some issue with > > reset. In that situation, a programmable logic change is more likely > > the more cost effective solution. > > I am in a fairly long thread in comp.arch.embedded about how to design > boards so that you don't have SI and EMI issues. I think this sort of > problem should be dealt with before you make the board, not after it is > in the field. Totally agree. But being realistic here, if you DO have boards out in the field with this problem, there is also the issue of what is the cost effective way to fix the problem from the perspective of both your company and your customer? > Too many engineers learn to cover their butts rather > than to produce good designs. I am tired of working that way and not > really knowing if my design will work before it is shipped. The one > universal rule I learned very early on is that you can not prove a > product works correctly by testing. Agreed. > It has to be designed to work > correctly by using design methods based on understanding what you are > doing. I have never seen a board noise issue that could be fixed by an > FPGA design change. Here's a hypothetical one (but not far from what I've seen) for you then. You've got a 'blip' on reset where it gets above threshold and that lasts for...maybe 1 ns at the receiver. You trace it down and find out exactly what output switching condition is causing the blip to happen. You can also characterize and analyze it to say that it will never be able to couple and cause this blip to exist for more than 2 ns. On the receiver you have a clocked device that receives this reset signal. The 'proper' solution of course is to re-route the board to get the reset away from the noise initiator, guard it appropriately, etc.....the 'soft' design change is to change the code in the receiving device to ignore resets that last for only two clocks or less (or whatever works for you). Granted, the reset response of the device has been degraded (by that clock cycle or two) but in many cases, that's OK as well. You need to investigate it of course to validate but under the right circumstances it would work just as flawlessly as the PCB re-route. The point being that just because a solution does not tackle the root cause does not necessarily imply that it is in any way less robust. And I'll also accept that in some (possibly many) situations there may be no 'soft' solution...if you'll also accept that in some (possibly many) situations that there really might. Now, you've got "N" boards in the field. What is the 'best' solution, not only from the perspective of your company (presumably the 'soft' update is easier to distribute) but from your customers as well (who would have down time to swap out the PCBA....oops, that board is in a deep sea sensor? On the way to Mars? Inside average Joe user's PC?) KJArticle: 107439
Robin Bruce wrote:
> A final point is that we really need to nail down this fallacy that an
> FPGA-targeting C-syntax HLL is somehow inherently sequential. It's not.
> The compiler determines that.
Take Robin's example, one thing that compilers need, is a hint about
available resources. That for-loop can easily be unrolled by a fair
factor and each instance executed in parallel. Even with N a variable,
it can lop the loop into large parallel chunks, and finish the last
increment with a partial chunk execution.
> FPGAs are best for algorithms where there are large data sets.
I disagree here ... they can also easily replicate MANY instances of
small parallel processes as they can replicate parallel instances of
any other data handling code block. For example, the code block of a
typical MPI parallel process can be replicated on FPGA
dozens/hundreds/thousands of times, that would require huge clusters of
machines for a sequential instruction set processor.
> They offer the best performance when the
> algorithms (or their main computational loops) are pipelinable.
Best? not clear ... but pipelining is certainly an advantage for
getting clock rate up. Another alternative is pure async construction,
or better yet, fully async FPGA fabrics.
> for(i=0; i<N; i++){
>
> sigma_local = sigma[i];
> mu_local = mu[i];
> x_local = x[i];
>
> sigma_sqr = sigma_local * sigma_local;
>
> dif_x_mu = x_local - mu_local;
> dif_x_mu_sqr = dif_x_mu * dif_x_mu;
>
> phi[i] = (1.0 / (sigma_local * ROOT_2PI)) * expf(-( dif_x_mu_sqr /
> (2 * sigma_sqr) ));
>
> }
There are a lot of things a good compiler can do here to improve
synthesis and performance, IF the compiler is tuned for doing FP based
data algorithms. Those are optimizations, that would never be put into
a pure hardware description language, as they would seldom be needed.
As such the optimizations in the compiler are leveraged across many
applications.
If this code block was the kernel of simulation engine, with thousands
of cells, it would be best for the compiler to implement this bit/digit
serial, using a data flow linkage to avoid the multiplier expansion.
Literially run thousands in parallel, with a word length latency in
clocks.
In many cases, C programers use variables instead of constants. There
is a clear advantage for FPGA compilers to be presented with constants
instead. This favors using maifest constants at compile time, rather
than per run constants in the data. Frequently a recompile is faster
than the resulting code fully parameterized.
Article: 107440
If I look in the FPGA editor there seems to be one element
in the CLB of a Virtex-4 that is odd as compared to previous
FPGA generations that I have looked at in the FPGA editor.
The CLB looks something like this in ASCII art:
+-------------+
| | +--+
| | | |
| | | | +-----+
| | | | |SLICE|
| | | | | |
| | | | +-----+
| | | |
| | | | +-----+
| | | | |SLICE|
| | | | | |
| | |??| +-----+
| Switchbox | |??|
| | | | +-----+
| | | | |SLICE|
| | | | | |
| | | | +-----+
| | | |
| | | | +-----+
| | | | |SLICE|
| | | | | |
| | | | +-----+
| | | |
| | +--+
+-------------+
The box with question marks just seems to rearrange the wires so that
they are grouped according to function at the switchbox.
Is that all there is to it?
/Andreas
Article: 107441
Eli Bendersky wrote:
> I also try to avoid variables for another reason (in addition to the
> ones you stated). Somehow, when variables are used I can't be 100% sure
> if the resulting code is synthesizable, because it can turn out not to
> be.
If you mean that a variable does not always infer a register I agree.
If you mean that synthesis does not always produce a netlist that
simulates the same as the code, I disagree.
> Additionally, since I do use signals, variables create the mixup of
> "update now" and "update later" statements which make the process more
> difficult to understand. With signals only it's all "update later".
I agree, and this is exactly why
I do not declare any signals for synthesis.
-- Mike Treseler
Article: 107442Amongst my junk I found a tube of 25 PZ5032CS10A44 32-macrocell CPLDs in PLCC44 package. Datasheet at <http://www.ife.tugraz.at/datashts/Philips/pz5032.pdf#search=%22pz5032%22> You pay postage, you get the chips.Article: 107443
Andreas, I would like to educate the newsgroup: FPGA_editor has a highly simplified graphical visual representation of the chip that is the 'software view' of the world -- it has very little basis in the actual hardware. I often have people ask me questions about the editor view, only to have to remind them that it does not represent the schematics. For example, there is no such thing as a "switchbox." It doesn't even exist. That said, improvements or changes in FPGA_editor may be done for reasons having nothing to do with the actual architecture, or hardware. Or they may be a way to represent a new architectural or hardware feature in a simplified fashion. Austin Andreas Ehliar wrote: > If I look in the FPGA editor there seems to be one element > in the CLB of a Virtex-4 that is odd as compared to previous > FPGA generations that I have looked at in the FPGA editor. > > The CLB looks something like this in ASCII art: > > +-------------+ > | | +--+ > | | | | > | | | | +-----+ > | | | | |SLICE| > | | | | | | > | | | | +-----+ > | | | | > | | | | +-----+ > | | | | |SLICE| > | | | | | | > | | |??| +-----+ > | Switchbox | |??| > | | | | +-----+ > | | | | |SLICE| > | | | | | | > | | | | +-----+ > | | | | > | | | | +-----+ > | | | | |SLICE| > | | | | | | > | | | | +-----+ > | | | | > | | +--+ > +-------------+ > > > The box with question marks just seems to rearrange the wires so that > they are grouped according to function at the switchbox. > Is that all there is to it? > > /AndreasArticle: 107444
Austin Lesea wrote: > Rick, > > Via in pad (basically no trace) is best. Placement is not critical, as > long as you have via in pad, and planes. > > But even so, the diameter of the vias, and their lengths can be > critical, and still be the dominant factor. > > It is all about the lop that is formed (see the HK sparse chevron > presentations, as I think he said it best). Where exactly is the loop you are referring to? Some would say it is back to the chip through the power pins. It appears to me that it only has to include the power planes. If it is back to the chip, then placement should be critical. I understand what you are saying, but I think the Ritchey method is very simple and effective. The range of change in the inductance of the various via placements is not so large that it swamps out the inductance of the cap which I would say dominates. In any event, if you just use a range of cap values to provide multiple SRFs you end up with a very broad low impedance power plane. This was shown both in simulation and in measurements. > Do you need a broad low impedance? I would say that it is most unusual > that a pcb has to work over all frequencies. The system is usually > designed with a finite number and range of clocks (33 MHz, 266 MHz, 78 > MHz, for example). I would counter that rather than a flat broad low > impedance, you could do better to target just the frequencies you care > about. Ritchey also discussed this, since knowing your frequency range is actually critical to any power decoupling approach. He showed that the IO noise for a series damped transmission line can be calculated assuming a current profile of the rise time limiting the slew (max freq) and the duration controlled by the roundtrip delay (min freq). This trapezoid has a given spectral profile which is not controlled by the clock at all. So even if the entire design is run from the same clock you can expect a lot of power noise to show at a wide range of frequencies. > High loss/low loss is a red herring: I have never seen a case where the > type of capacitor made any difference at all. I would be interested if > anyone has made a board where high loss/loss loss caps actually made a > measurable difference, I can't say a design failed because of low loss caps, but Ritchey had very clear measurements that showed a strong ESR peak where the caps resonated with the plane. By using caps with a higher ESR the resonance was damped out and the impedance "hole" was eliminated. BTW, one of your people was in the class. He seemed to get a lot from it too. I have misplaced his card or I would ask you to say hi to him for me. He seemed like a good guy! :^)Article: 107445
fl wrote:
> I modified the source of that resource library. I found
> that my simulation did not reflect my changes even I refreshed that
> resource library. The only way is to totally delete that library and
> recreat it. Do you have method to update a user defined library?
Compile the library first and then files
that use the library.
-- Mike Treseler
Article: 107446KJ wrote: > ... > The drawback of signals is that take longer simulation time...wasted > time too. I'm trying to resurrect the test code that I had comparing > use of variables versus signals but I seem to remember about a 10% hit > for signals... I would be interested in whether anyone has theories on why variables would simulate faster than signals. And whether this behavior has been seen on different simulators, or only Modelsim.Article: 107447
Perhaps I did not phrase my question correctly. Assume a hypothetical system where raw captured data from an ADC is streamed from one box to another. The two boxes are connected via some sort of RocketIO link over copper. Ideally, I would like to transmit just the raw samples, but it seems some sort of overhead will be required to keep the link established and aligned. In the event that bit errors occur, and a comma character is falsly detected by the receiver, what happens? For example, will the receiver try to realign and continue pumping out data, now misaligned by the false comma, until the real comma is detected? Or will the receiver raise an error flag, but not try and realign. I am more interested in maintaining the throughput, and less concerned that data is "correct". That having been said, I would like to have correct data, but I do not think I can afford the overhead of error correction. Any insight or suggestions? --Dennis Ed McGettigan wrote: > vt2001cpe wrote: > > Thank you everyone for your quick and informative responses! In the > > event of a large number of bit errors, is it possible for a comma > > character to be incorrectly introduced? What would the effect be? Will > > the CRC fail and put the state machine into an error state, or will > > data continue to transmit, unaware? > > It is possible to generate more than a single bit error in the same > 8b10b word, but with a well designed link this is very unlikely to > occur. In any case your transmitter is completely unaware that an > error actually occurred and will happily continue transmitting. It's > your receiver logic needs to be able to handle any errors that happen. > > The worst case that could happen is that the error generates a comma > character that is out of alignment with the previous alignment. This > would cause a constant stream of errors until a correct comma character > is received and the link realigns to the correct 8b10b word. All of > this is fairly standard stuff and has been around for decades in > many different protocols. > > Since it doesn't look like you have a particular protocol in mind. I > would suggest that you take a look at the light weight Aurora protocol > http://www.xilinx.com/aurora Even if you decide to not use it, you > should be able to learn a lot from it. > > Ed McGettigan > -- > Xilinx Inc.Article: 107448
vt2001cpe schrieb: > Perhaps I did not phrase my question correctly. Assume a hypothetical > system where raw captured data from an ADC is streamed from one box to > another. The two boxes are connected via some sort of RocketIO link > over copper. Ideally, I would like to transmit just the raw samples, > but it seems some sort of overhead will be required to keep the link > established and aligned. In the event that bit errors occur, and a > comma character is falsly detected by the receiver, what happens? For > example, will the receiver try to realign and continue pumping out > data, now misaligned by the false comma, until the real comma is > detected? Or will the receiver raise an error flag, but not try and > realign. I am more interested in maintaining the throughput, and less It will detect a code error and raise a flag. Dependig on configuration the receiver will try to realign or just continue sampling data. Usually a state machine will keep a look at the code error flag and force a realign after 3 consecutive errored codes. Iam not sure if this state machine is already implemented inside the MGTs, probably you have to create it yourself using FPGA logic. Should be no big deal. Regards FalkArticle: 107449
vt2001cpe, http://www.xilinx.com/products/design_resources/conn_central/grouping/aurora.htm details the Aurora protocol, which should be lightweight enough that it does not burden your data transfers. You need something to: keep track of connection state, bond more than one MGT together (to get more bandwidth), deal with errors, organize data into frames, perform flow control, encode/decode in 8b/10b or 84b/66b, etc. Using the MGT all by itself is starting from scratch, and you will eventually have to decide how to deal with all of the items I mentioned above. Thus, the reason why we created Aurora, and offer it license free, with supported IP. Enjoy, Austin vt2001cpe wrote: > Perhaps I did not phrase my question correctly. Assume a hypothetical > system where raw captured data from an ADC is streamed from one box to > another. The two boxes are connected via some sort of RocketIO link > over copper. Ideally, I would like to transmit just the raw samples, > but it seems some sort of overhead will be required to keep the link > established and aligned. In the event that bit errors occur, and a > comma character is falsly detected by the receiver, what happens? For > example, will the receiver try to realign and continue pumping out > data, now misaligned by the false comma, until the real comma is > detected? Or will the receiver raise an error flag, but not try and > realign. I am more interested in maintaining the throughput, and less > concerned that data is "correct". That having been said, I would like > to have correct data, but I do not think I can afford the overhead of > error correction. > > Any insight or suggestions? > --Dennis > > Ed McGettigan wrote: >> vt2001cpe wrote: >>> Thank you everyone for your quick and informative responses! In the >>> event of a large number of bit errors, is it possible for a comma >>> character to be incorrectly introduced? What would the effect be? Will >>> the CRC fail and put the state machine into an error state, or will >>> data continue to transmit, unaware? >> It is possible to generate more than a single bit error in the same >> 8b10b word, but with a well designed link this is very unlikely to >> occur. In any case your transmitter is completely unaware that an >> error actually occurred and will happily continue transmitting. It's >> your receiver logic needs to be able to handle any errors that happen. >> >> The worst case that could happen is that the error generates a comma >> character that is out of alignment with the previous alignment. This >> would cause a constant stream of errors until a correct comma character >> is received and the link realigns to the correct 8b10b word. All of >> this is fairly standard stuff and has been around for decades in >> many different protocols. >> >> Since it doesn't look like you have a particular protocol in mind. I >> would suggest that you take a look at the light weight Aurora protocol >> http://www.xilinx.com/aurora Even if you decide to not use it, you >> should be able to learn a lot from it. >> >> Ed McGettigan >> -- >> Xilinx Inc. >
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