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 Mar 29, 11:43=A0am, PureSine <Green.Tech.Co...@gmail.com> wrote: > Hello, I want to tell XST that uses block RAM for my FIFO, > but I couldn't till now. can you please take a look at my > code and tell me what should I do ?http://openpaste.org/en/20191/ > > thanks I'm not looking at your code right now, but I will tell you how to fix it. Start with one of the BRAM examples in Xilinx's XST guide. Make sure that when you synthesize it, it generates a block ram. Munge on it until the I/Os to the module look like what you want (resynthesizing as you go to insure you haven't done anything to make XST think it's not a synchronous block ram any more). Then build your FIFO wrapper around it. BTW, if you are building a synchronous FIFO where both input and output are on the same clock, some of the xilinx tools get pissy if you don't declare the two ports to the RAM in two different processes. That can be a problem, because you can have a design that is logically correct for a block ram, but won't infer as one. That's why the best approach is to incrementally modify a working design -- the synthesis tools are a little fragile on the whole inference thing. Alternatively, you could just instantiate the block ram, but I prefer not to do that if I don't have to, since if it's inferred I can simulate it with anything. Regards, PatArticle: 146826
On 03/29/2010 05:20 PM, Patrick Maupin wrote: > On Mar 29, 2:36 pm, Jason Thibodeau<jason.p.thibod...@gmail.com> > wrote: >> What I'm working on, I need to be able to place these gates into >> specific portions of the chip. This is why I cannot have them optimized >> or absorbed into other CLB's. > > I have no idea why you would want to do this, but I would build the > design as discrete units. At the top, you can stitch them together > using xilinx's "black box" stuff, and then the synthesizer won't be > smart enough to optimize things out. Also, doing it this way makes it > easy to constrain placement. > > HOWEVER, the map has gotten a lot smarter lately, so you'll probably > need to set some options on that to keep it from resynthesizing the > chip when it sees the full picture. > > Regards, > Pat Unfortunately, the gates that are being optimized out, are being inserted into an existing design file. They are, however, instances of a predefined entity. I cannot move them to be parts of a "black box". -- Jason ThibodeauArticle: 146827
On Sun, 28 Mar 2010 19:06:23 -0700 (PDT), Weng Tianxiang wrote: >From the first moment I learn how stack segment and stack pointer are >used to link all subroutines in PC, I have been appreciating the >hardware structure as I can and I think it is the the most beautiful >and memorable hardware structure I have learn from the CPU structure. Aw, c'mon. Most of that is software - the only hardware requirements are the ability to copy a stack pointer to/from some other place, and the ability to construct an address that's offset from a register or memory value. For sheer luminous beauty, let's hear it for the PDP-8's JMS instruction... oh, maybe not. OK, second attempt. SPARC register windows. No? Don't like that? OK, the Transputer's tiny 3-register evaluation stack, with context switches permitted only at points where the stack is known to be empty. The 21st century operating system wonks could REALLY learn something about lightweight elegance from that one. What about the whole idea of a stack? How cool is that, if you haven't seen it before? Set-associative cache? Sheesh, the field is so crowded with beautiful, genius-level ideas - but we're all so familiar with them that we don't see how hard it must have been to come up with them in the first place. Trying to single out just one is silly. >Oh, I forgot to mention the most important invention since then is the >Mouse we use it every day. Crap. Are you *really* trying to convince us that the mouse is more important, elegant, beautiful than... - convolution codes? and Shannon's theorem? - quadrature modulation? - Boolean algebra? Set theory? - The Fourier transform? - crystallography? - The Goldberg Variations? The kind of slavish technology-worship that your original question exemplifies is depressing and backward-looking; it leads us into relying on past achievements instead of being thrilled by what might be if only we keep questioning. It's the kind of thinking that should (but too often does not) give technologists and businessmen a bad reputation. We technologists are the 21st-century equivalent of the 19th century ironfounders. We're exploiting the heroic achievements of the recent past to build the infrastructure that the future needs. We are facilitators, not visionaries. The next half-century belongs to the molecular biologists and geneticists, and we are merely there to help out with the menial work. Get a sense of proportion. -- Jonathan BromleyArticle: 146828
Bill, The DCM "fits" a delay line of 256 taps long, to the period of the clock input signal. In 3E & 3A, a different architecture was used than in the V2, V2P, 3 and V4, where the taps are always 20 to 40 ps long, and there are always enough of them to even fit 256 of them to a 5 MHz input clock. I know, its magic. AustinArticle: 146829
Bill, Oops. I mean that it has as many taps as required to "fit" a 5 MHz input clock, not 256 like V2, V2P, 3, and V4.... Magic... AustinArticle: 146830
austin <austin@xilinx.com> wrote: > Oops. I mean that it has as many taps as required to "fit" a 5 MHz > input clock, not 256 like V2, V2P, 3, and V4.... So as the process gets faster, the number of taps will increase? (With a margin big enough for process/temperature/voltage variations.) -- glenArticle: 146831
On 29/03/10 21:22, Abby Brown wrote: > Hi, > > Altera's Quartus II does not include a free simulator. Is there > a free VHDL or Verilog simulator that is reasonalbly good? > Google shows a few but I would prefer a recommendation. > > Thanks, > Gary > > Depends what you mean by "include" - you can download a completely free version of Modelsim from the Altera Website, regards Alan -- Alan FitchArticle: 146832
On Mar 28, 5:27=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Mar 28, 1:22=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > If you're going to feed the clock back, then you'll want to parallel > > terminate to ground rather than series terminate at the source. > > I figured the external lines are small enough that the transmission > line characteristics are no longer as important as the lumped model. Depends on the edge rates...but likely true that no termination might be needed. The point is to add one resistor as insurance against a nasty surprise on an unexpectedly high edge rate. > Having a series resistor could help the transmitter avoid too much of > a surge. If you're talking abou the 'surge' from when the I/O switches, then series termination causes the large surge, parallel termination has much smaller AC current changes. > =A0The termination at the final destination is the classical > version, however. =A0Having room for both can help, perhaps more than > hinder. Ummm...nothing 'classical' about it. If you have a multi-drop net and you need clean edges at each load, you don't use series termination, you use parallel. If you have a driver that can't provide a clean incident wave switching edge into the PCB then you need to rethink having a multi- drop net, go back to having one load and then series terminate...in the radarman's case, that would mean not feeding back the SRAM clock back to the FPGA. Kevin JenningsArticle: 146833
Jonathan Bromley wrote: > Crap. > > Are you *really* trying to convince us that the mouse is > more important, elegant, beautiful than... > - convolution codes? and Shannon's theorem? > - quadrature modulation? > - Boolean algebra? Set theory? > - The Fourier transform? > - crystallography? > - The Goldberg Variations? I'll add the Burrows-Wheeler transform which enables great compression and the Reed-Solomon method for forward error correction, used in so many places. I wish I could come up with something as mind-boggling AND useful. > The kind of slavish technology-worship that your original > question exemplifies is depressing and backward-looking; > it leads us into relying on past achievements instead of > being thrilled by what might be if only we keep questioning. > It's the kind of thinking that should (but too often does > not) give technologists and businessmen a bad reputation. he seems to be too young or too noob to understand that yet. Give him 10 or 20 years... > Get a sense of proportion. This comes with learning, and Internet is a great facilitator for this. And other less noble things, but so is the human nature... yg -- http://ygdes.com / http://yasep.orgArticle: 146834
Hi there, Looking for insight here - Spartan 6 adds a PLL to the mix and we wondered to what extent it can be used to filter jitter, for example for a Synchronous Ethernet product requirement we have. However, the SP6 PLL seems to have a very stringent max input jitter requirement. It does not allow an input clock with more that 1ns jitter (not much). Looking in the datasheet, the SP6 PLL looks like a classic PLL, so why the input jitter requirement? (I can understand the jitter requriement for a DCM). I.e. Table 49, pg 45 of DC and switching characteristics. FINJITTER Maximum Input Clock Period Jitter All <20% of clock input period or 1 ns Max Anyone (from Xilinx?) prepared to comment on this? Cheers AndrewArticle: 146835
On 3/30/2010 1:56 AM, Patrick Maupin wrote: > On Mar 29, 11:43 am, PureSine<Green.Tech.Co...@gmail.com> wrote: >> Hello, I want to tell XST that uses block RAM for my FIFO, >> but I couldn't till now. can you please take a look at my >> code and tell me what should I do ?http://openpaste.org/en/20191/ >> >> thanks > > I'm not looking at your code right now, but I will tell you how to fix > it. > > Start with one of the BRAM examples in Xilinx's XST guide. Make sure > that when you synthesize it, it generates a block ram. Munge on it > until the I/Os to the module look like what you want (resynthesizing > as you go to insure you haven't done anything to make XST think it's > not a synchronous block ram any more). Then build your FIFO wrapper > around it. > > BTW, if you are building a synchronous FIFO where both input and > output are on the same clock, some of the xilinx tools get pissy if > you don't declare the two ports to the RAM in two different > processes. That can be a problem, because you can have a design that > is logically correct for a block ram, but won't infer as one. That's > why the best approach is to incrementally modify a working design -- > the synthesis tools are a little fragile on the whole inference thing. > > Alternatively, you could just instantiate the block ram, but I prefer > not to do that if I don't have to, since if it's inferred I can > simulate it with anything. > > > Regards, > Pat Thanks a lot Pat :) , I will try and if I had problem I'll post it here. RegardsArticle: 146836
On Mar 29, 4:29=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > Unfortunately, the gates that are being optimized out, are being > inserted into an existing design file. They are, however, instances of a > predefined entity. I cannot move them to be parts of a "black box". OK, from what I've seen: 1) You claim the gates are an "integral part of the design", but that TWO different synthesizers remove them. 2) You claim that for some unreported reason they HAVE to be placed at a certain place on the chip (and we haven't even gotten to how routing will affect the timing on that...) 3) You claim that you can't change the design; yet you simultaneously have to change the design. 4) You are apparently reluctant to explain enough about the design to let others independently judge the veracity of claims 1-3. I don't know whether you are building one of these weird neural nets where some genetic trial and error algorithm has found a design that does something strange and wonderful, or what. It sounds like an interesting puzzle; unfortunately most of the give and take around here is on puzzles that have solutions that are useful to multiple people, especially where two different people giving answers can learn a bit from each other. I'm beginning to suspect that you are the only person on the planet with this particular problem, and since I can't see its relevance to my life, and I tried (and also read a bunch of answers where others have tried), I only have one answer left for you: FPGA Editor. And I'm sure you have a reason why that won't work, and although I shouldn't care, I would like to see this reason. It's like watching one of those slow motion train-wrecks... Regards, PatArticle: 146837
On Mar 29, 9:30=A0am, colin <colin_toog...@yahoo.com> wrote: > I need to start using ISE 11.4 instead of 10.1 > > Copy a full project using explorer and open with 10.1, all paths are > relative and you have a "new project" > > Copy a full project with explorer and open with 11.4 and you need to > upgrade the project. > > Start editing stuff and then discover that the project upgrade used > absolute pathnames and I've been editing the original files. > > Hello XILINX this is the real world calling........... is anyone > there?.......................... That's just Xilinx's little way of gently reminding you that you really *should* be using verson control on your sources ;-)Article: 146838
The most memorable hardware structure is the vector indirect addressing mode. MitchArticle: 146839
On 3/30/2010 1:56 AM, Patrick Maupin wrote: > On Mar 29, 11:43 am, PureSine<Green.Tech.Co...@gmail.com> wrote: >> Hello, I want to tell XST that uses block RAM for my FIFO, >> but I couldn't till now. can you please take a look at my >> code and tell me what should I do ?http://openpaste.org/en/20191/ >> >> thanks > > I'm not looking at your code right now, but I will tell you how to fix > it. > > Start with one of the BRAM examples in Xilinx's XST guide. Make sure > that when you synthesize it, it generates a block ram. Munge on it > until the I/Os to the module look like what you want (resynthesizing > as you go to insure you haven't done anything to make XST think it's > not a synchronous block ram any more). Then build your FIFO wrapper > around it. > > BTW, if you are building a synchronous FIFO where both input and > output are on the same clock, some of the xilinx tools get pissy if > you don't declare the two ports to the RAM in two different > processes. That can be a problem, because you can have a design that > is logically correct for a block ram, but won't infer as one. That's > why the best approach is to incrementally modify a working design -- > the synthesis tools are a little fragile on the whole inference thing. > > Alternatively, you could just instantiate the block ram, but I prefer > not to do that if I don't have to, since if it's inferred I can > simulate it with anything. > > > Regards, > Pat Thanks Pat :) , that worked. Now I have a BRAM FIFO. Thanks for your help. RegardsArticle: 146840
On Mar 29, 6:06=A0pm, austin <aus...@xilinx.com> wrote: > Bill, > > The DCM "fits" a delay line of 256 taps long, to the period of the > clock input signal. > > In 3E & 3A, a different architecture was used than in the V2, V2P, 3 > and V4, where the taps are always 20 to 40 ps long, and there are > always enough of them to even fit 256 of them to a 5 MHz input clock. > > I know, its magic. > > Austin Austin - are you up on your Spartan3E variable phase shift trivia? There is unfortunately no 256-tap fit (for the variable phase shift, at least). The variable phase shift is a tap-by-tap adjustment unlike most every other family out there which did the 256 tap "fit" properly even if it took more than one inc or dec to change taps. The limits defined by the data sheet ended up being a very unusual set of numbers and is enough to make an engineer sweat about whether they'll be able to get the phase shift they want. I was happy to get the 3 bit periods of phase adjustment out of the 300 MHz multiplied clock (based off a 50MHz reference). But what a wild ride that was! I ended up with correspondence directly with the silicon designer when the phase inc/dec update started ignoring commands on occasion. So, Bill - word of caution... If you use the variable phase shift and consider the "about 100 clocks" to make sure the adjustment occurs - or similarly worded metric - you may have occasion where the adjustment doesn't happen or at least for a duration much longer than expected. I ended up with a timeout count such that if I didn't get an ack after a certain period of time, I retried the adjustment. Sadly, I forget what the final implementation included, whether the timeout was still the way to go or if there was a "real" solution.Article: 146841
On Mar 29, 8:31=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Mar 28, 5:27=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > > > On Mar 28, 1:22=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > If you're going to feed the clock back, then you'll want to parallel > > > terminate to ground rather than series terminate at the source. > > > I figured the external lines are small enough that the transmission > > line characteristics are no longer as important as the lumped model. > > Depends on the edge rates...but likely true that no termination might > be needed. =A0The point is to add one resistor as insurance against a > nasty surprise on an unexpectedly high edge rate. > > > Having a series resistor could help the transmitter avoid too much of > > a surge. > > If you're talking abou the 'surge' from when the I/O switches, then > series termination causes the large surge, parallel termination has > much smaller AC current changes. > > > =A0The termination at the final destination is the classical > > version, however. =A0Having room for both can help, perhaps more than > > hinder. > > Ummm...nothing 'classical' about it. =A0If you have a multi-drop net and > you need clean edges at each load, you don't use series termination, > you use parallel. > > If you have a driver that can't provide a clean incident wave > switching edge into the PCB then you need to rethink having a multi- > drop net, go back to having one load and then series terminate...in > the radarman's case, that would mean not feeding back the SRAM clock > back to the FPGA. > > Kevin Jennings Kevin, you're turning my stomach in knots here. You're regurgitating transmission line theory quoting "edge rates" without apparent consideration for the extremely minute distances involved. At 250-750 mil, you will NOT see a classic step, reflect, step kind of response. And when's the last time you really fixed a signal by capacitively loading it? Your suggestion that lightening the driver's load with a series resistor (hence, reducing initial overshoot that I've seen on the scope in many families) exacerbates the problem is downright ludicrous. Please stop parroting what you heard in transmission line theory; it's good stuff but it doesn't apply for these flight times with the SSTL drivers involved. Take some time and check out the signal fidelity on boards with various terminations with a high end scope or run some IBIS simulations to see what really happens when traces become lumped elements rather than transmission lines.Article: 146842
On Mar 29, 9:49=A0pm, PureSine <Green.Tech.Co...@gmail.com> wrote: > Thanks Pat :) , that worked. Now I have a BRAM FIFO. > Thanks for your help. You're welcome! Glad you got it working. PatArticle: 146843
On Mon, 29 Mar 2010 19:39:12 -0700, MitchAlsup wrote: > The most memorable hardware structure is the vector indirect addressing > mode. I had a soft spot for the 3D-matrix-stride post-modify addressing mode that the Motorola 56000 had, for a while. (The processor still has the mode, I'm no longer so sure it was a good idea...) Certainly memorable. Cheers, -- AndrewArticle: 146844
On Mon, 29 Mar 2010 13:15:11 -0400, Jason Thibodeau <jason.p.thibodeau@gmail.com> wrote: >I know the design intimately, and I know for a fact the gates it is >optimizing out are necessary for proper operation. I'm trying to figure >out WHY this is happening. > >FWIW, this is not just a problem with Xilinx's optimization. Synopsys >does the same thing during synthesis, but I can tell it to not optimize. >The branches it is optimizing have a VERY (<.000001%) low probability of >activation, but I need the gates to remain, anyway. For logic synthesis probability of activity doesn't matter. If the logic cone includes the path, it will be kept. Maybe your gates are being merged in a LUT instead of being kept as individual gates which XST maybe more inclined than Synopsys is (DC is usually more obsequious as ASIC developers are more insistent on what they want to keep). One thing you can check is to compare the behavior of the post map netlist vs your input structural netlist. If they're the same XST is restructuring your code. It is extremely unlikely that they are different but if so open a case with Xilinx. One final thing you can try is to replace each gate with LUTs and equivalent INIT statements which are protected with an abundence of keep, no_prune etc. You should be able to protect every single gate with this method. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 146845
On 29/03/2010 20:36, Jason Thibodeau wrote: e raison d'ętre of HDL synthesizers is to produce an optimized >> design that matches the HDL input code. If the tools didn't do this >> then they no one would use or buy them. >> >> If the gate/net was optimized away then it wasn't needed. Either the >> input (registers and IO pads) equation cone had redundancies or there >> was a redundancy to the final output (registers or IO pads). The >> synthesizer will also move the equations around to optimize timing. A >> signal that you have coded to appear early in an multi-level logic >> cone may be pushed to later in the logic cone to improve the timing. >> >> If the synthesizer changed the logic then it would be a bug. Since >> you have said that this happens in two different tools it is very >> unlikely to be a bug. >> >> I think that you mentioned that you had OR'ed all of the outputs >> together to keep all of the logic from being trimmed. I would suggest >> instead that you register all of the outputs and then OR the registers >> outputs to keep the logic. Optimizing across the register boundaries >> is available in some synthesizers, but there is usually an option to >> enable/disable the feature. >> >> Ed McGettigan >> -- >> Xilinx Inc. >> > > The logic that is being optimized out is a simple comparator. And gates > in roughly a tree structure, with a final or gate to feed it back into > the 'main' circuit. > > The or gate was not implemented to keep the tool from trimming the > logic, rather it was necessary for proper function of the circuit. > > What I'm working on, I need to be able to place these gates into > specific portions of the chip. This is why I cannot have them optimized > or absorbed into other CLB's. > > I'm really just trying to figure out if it is possible to place an > attribute before an instantiation so it will not be trimmed. I realize > what I want may not be a standard request, but I just want to make it work. > > Thanks for all your help, everyone. > Hi Jason, I still don't really understand - but I suspect there may be a misunderstanding here. If you say the gates are "optimized out", to me that means, as Ed and others have said, that they are redundant - to put it bluntly, the tool is right and you are wrong :-; However I wonder if what you really mean is that the functionality of those gates has been merged in with other logic, and you want to keep it separate? If that is the case, then you need to put those gates in a separate component and tell the tool to preserve the hierarchy, and to keep that component using whatever magic spells are required by XST, regards Alan -- Alan Fitch Senior Consultant Doulos – Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.Article: 146846
In article <27ebdb37-e3ba-4559-be7d-d7f3b6613d77@30g2000yqi.googlegroups.com>, MitchAlsup <MitchAlsup@aol.com> wrote: >The most memorable hardware structure is the vector indirect >addressing mode. Yes. There were and are more bizarre ones, but they are Not Memorable (see Sellars and Yeatman). Regards, Nick Maclaren.Article: 146847
As others have said you at least need to have series termination on your clock, unless you're bringing it back to the FPGA then parallel terminate it at the end. CycloneIII s have on chip termination which you could try using for this, but this only has two settings, 25R and 50R so if you need to tweak values you're stuffed (although you can add an external resistor to set the termination value). I'd play safe and add an external resistor. Nial.Article: 146848
On Mar 29, 11:47=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Mar 29, 8:31=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > Kevin, you're turning my stomach in knots here. =A0You're regurgitating > transmission line theory quoting "edge rates" without apparent > consideration for the extremely minute distances involved. =A0At 250-750 > mil, you will NOT see a classic step, reflect, step kind of response. > I have considered the distances...and every post said that the termination is probably not needed, but is cheap insurance if it turns out to be needed for some unforeseen reason down the road. > And when's the last time you really fixed a signal by capacitively > loading it? =A0 Never...nor did I suggest it here. > Your suggestion that lightening the driver's load with a > series resistor (hence, reducing initial overshoot that I've seen on > the scope in many families) exacerbates the problem is downright > ludicrous. > Not my suggestion at all. What I said was that you series terminate when the load is at the end of a line; parallel terminate if you have multiple loads along the line. Radarman said he was going to implement someone's suggestion to route the clock to the SRAM and then feed it back to the FPGA...sounds like two loads to me, SRAM in the middle, FPGA at the end. > Please stop parroting <snip> I don't parrot...I gave sound advice that you seem to have trouble understanding. I run the sims, make the measurements, add insurance where necessary, been doing this successfully for a long time too. Time to end this thread Kevin JenningsArticle: 146849
Thank you for your answers. I take it that they're serious about having some 4000 taps. Also, I keep hearing (reading, actually) about the variable phase shifter taking a long time to acknowledge its commands. Make me wonder why, since all we're asking for is "what you did right now, just another tap". I wish someone revealed what really goes on there, and how they reached those peculiar equations. All this feels like witchcraft. I'm going to experiment a bit. The problem is that my experiments will be on a stepping 0 FPGA, while the target board will have a stepping 1 high speed grade chip. With all this mystery, I wonder if that's going to make a difference (and they obviously did something with the DCM between the steppings). Bill.
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