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
> However, 51/256ths is pretty close: > 0.1992. When this is expressed in binary, it is 0.0110011, which has only > four ones so you can do the multiplication with four shifted adds (if you > don't have a multiplier). > > So the optimized code would look something like: > > wire [20:0] in; // number to be divided > wire [20:0] result = (in + (in<<1) + (in<<4) + (in<<5)) >> 8; Actually, you need only two adds: temp = in + (in<<1) result = (temp + (temp<<4)) >> 8Article: 44001
Hi all, does anyone implement a design on the RC1000 board to control the 8 LEDs on the board?Article: 44002
Heya,
Thanks for the feedback...
> If turning the timingchecks off doesn't fix you problem, it would be helpful if
> you would post the snippet of code including the logic feeding the SRL16 so
> that we could see what you are doing.
Very true - I'm quite busy at the moment so I don't have time to strip
the code down to an example case. I'll try to find the time in a couple
of weeks.
> Could be an RTL flip-flop that is not initialized feeding into it
> too.
Nope - everything's green across the wave window except for these blots
of red at the SRL16 output (before you ask - yes, I am waving the inputs
to the SRL16 ;).
Cheers,
--
. . Iain Waugh
. o ._o .o \#/. o. o_. o . iain@zip.com.au
`) /\ =) .-kai- )= /\ )' http://www.zip.com.au/~iain
/< < < /#\ . > > >\ :.::.:TAG.:.::.
.
Article: 44003Maybe I am missing something, but don't you have to specify the frequency in the timing constraints for the FPGA anyway? If you want the chip to give you better performance than you actually need, you can still do that if you want, just add more time to the other chip's output delays and input setup times. That does not change. But if you specify a hard setup time for the FPGA, you will always have to do the math for every group of pins any time you make a frequency change. I like to eliminate possible sources of errors when I can. But as you say, it is largely a matter of style. John_H wrote: > > Personally, I want my FPGAs specified like all the other chips on my board: > setup/hold and clk-to-out times. > > The IN AFTER and OUT BEFORE require the cycle time to be hard coded into the > timing numbers. If I change my frequency I no longer need to reevaluate my > system level setup and holds but need to respecify the timing numbers even if > my setup and holds are fine. > > Maybe it's because I work towards "best" setup and Tco times rather than > letting the system come in around them. > > It's all style. > > rickman wrote: > > > Let me add my two cents worth to this discussion. > > > > I feel that it is better to specify OFFSET IN xx AFTER and OFFSET OUT xx > > BEFORE rather than the way you are doing it. I am pretty sure I have > > used these constraints this way and they did what I intended. That is > > to account for the frequency (or period) and allow you to specify the > > input and output delays in a frequency independany way. > > > > When you spec OFFSET IN xx BEFORE, you have to take the output delay of > > the driving chip, add the routing delay if significant and subtract that > > from the period of the clock. If your clock changes, you have to change > > all of your IN specs. The same is true for the OFFSET OUT xx AFTER > > spec. This requires that you add all the setup factors and subtract > > from the period. > > > > If you use OFFSET IN xx AFTER or OFFSET OUT xx BEFORE, the software uses > > the period of the clock and does this calculation for you. All you have > > to do is specify the sum of all delays from the clock to the data being > > stable on the input pin or the delays from the output pin to the clock > > on the chip being driven. > > > > Not a big deal, but if you have a lot of different delays and multiple > > clocks, it can get pretty confusing when you need to make changes. To > > opimize reusability, it is good to spec the delays rather than the setup > > time on input and the setup time required rather than the delay on > > output. > > > > John Williams wrote: > > > > > > Hi folks, > > > > > > Can someone illuminate for me the physical interpretation of the OFFSET > > > IN xx BEFORE and OFFSET OUT xx AFTER constraints? > > > > > > I'm happy with the PERIOD constraint, that specifies the maximum delay > > > along a path between any two sequential elements (registers etc), and I > > > grasp the physical interpretation of how that relates to the maximum > > > clock speed. > > > > > > I think I understand the OFFSET IN xx BEFORE constraint, basically > > > saying the data will be on the pad XX ns before the clock goes high - > > > this is like a setup time right? > > > > > > However, the OFFSET OUT xx AFTER constraint is really confusign me. > > > Does this specify the maximum path delay from the Q output of a register > > > to the output pad? > > > > > > In the dummy pipeline design that I'm experimenting with on a Virtex, > > > I'm finding that I can meet a period constraint of 100MHz no worries, > > > but the OFFSET IN BEFORE and OUT AFTER constraints don't make sense, I'm > > > getting minimum input delays of around 7 ns and output delays > 10ns. > > > > > > With my design, the input path from a pad is straight into a register, > > > and similarly the output path is straight out of a register to the pad - > > > why am I unable to constrain the OFFSET IN BEFORE and OFFSET OUT AFTER > > > values to around 2 or 3 ns? I've got the P&R tools on maximum extra > > > effort. > > > > > > Is there somewhere a worked example/tutorial illustrating the use of > > > these constraints? I've scoured the Xilinx website and found notes and > > > papers that talk about them, but haven't seen any worked examples. > > > > > > Thanks, > > > > > > John > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 44004
rickman wrote: > > Maybe I am missing something, but don't you have to specify the > frequency in the timing constraints for the FPGA anyway? Absolutely! In one place. Second line of the file. > If you want > the chip to give you better performance than you actually need, you can > still do that if you want, just add more time to the other chip's output > delays and input setup times. That does not change. I know the clock delays from the timing analyzer results. I know the timing parameters for the IOB inputs and outputs as well as the CLB characteristics from the speedprint utility. I can find the expected routing times for CLBs "very close" to the IOBs. I can determine my best Tsu and Tco times from these numbers. I know when the results aren't valid. > But if you specify > a hard setup time for the FPGA, you will always have to do the math for > every group of pins any time you make a frequency change. I have to do the math for every group of pins on the devices I'm interfacing with. Often a speed-bump will change these numbers due to different parts or better speed grade devices. If it's a new design that requires the speedup of the existing FPGA, my time of flight will change and jitter issues may be different. The whole timing budget needs to be reevaluated. If the FPGA can't get there, I like to know ahead of time. Bumping from a Spartan-IIE to a Virtex-IIE to get a two speed grade improvement isn't an option. Since my designs tend to leave the input and output timing with little flexibility for the tool to move them around, I don't benefit from using the OUT BEFORE and IN AFTER constraints. > I like to eliminate possible sources of errors when I can. > > But as you say, it is largely a matter of style. An idea for a new magazine: "Cosmopolitan Engineer" "Check out the NEW styles direct from San Jose" "How to know when your tools are cheating you" "New synthesis techniques for ohmigod action"Article: 44005
You make my point. If conferences publish papers in an area, they should balance papers that "prove" with papers that "refute". If such papers were published you would know what th technical term "degenerating" research program means. It is a technical term from mid century philosphers of Science named Lakatos and Feyerabend (a good starting reference is: Lakatos, I. "Mathematics, Science, and Epistomology", Philosophical Papers Volume 2. Cambridge Press, 1978. Formal verification is a degenerating research program because it replaced the superior Polya program without any scientific debate and because continual predictions of impending success have been made for the last 30 years and are still being made. This discussion should not be taking place in a newsgroup but rather in refereed conferences. /Steve On Fri, 07 Jun 2002 06:32:59 GMT, Kelly Hall <hall@priest.com> wrote: > On 7 Jun 2002 05:17:05 GMT, Steve Meyer <sjmeyer@www.tdl.com> wrote: >> This may be a side effect of commercialization of Computer Science, >> but there is a very interesting scientific puzzle that one can observe >> at next week's Design Automation Conference (DAC). Namely, that although >> formal verification has been a degenerating research program since at >> least 1972, nearly every technical paper and new exhibitor is describing >> tools for formal verification of circuits. > > Define 'degenerating' because I have no idea what you're trying to say. > Please - I'm genuinely puzzled by what you said. I know a few people > making their living quite nicely doing formal methods in academia, > government, and industry. What part of FM is degenerating? > >> These tools supposedly lead to RTL sign off without a need to simulate and >> verification usally by software checking of user supplied constraints. > > I've never heard *any* formal methods person advocate not simulating the > RTL. Maybe I've not travelled in the same circles you have. All you get > from FM is confidence that two representations of your circuit (your spec > and your implementation) have some relationship (equivalency, implication). > That certainly doesn't prevent your synthesis tool from breaking your > design, or your layout tool, or the fab house. > > I like simulating the RTL as much to have confidence in my formal specs > as to gain trust in my design. > >> Here are Some of the puzzles. 1) because formal proving is related to >> BDD construction from net lists, this formal analysis should be usable >> in communication code breaking cryptography. Yet, paper at this year's >> Eurocrypt showed heuristics for the related NP complete problem do not help. >> Reference is: Krause, M. "BDD-based Cryptanalysis of Keystream Generators", >> Proceeding 2002 Eurocrypt, Springer, 2002. Also the objections to >> formal verification first detailed in the Lighthill Report submitted to >> the British Government in 1972 still need answers. > > I think you need to get out and look at formal methods more. I'm from the > theorem prover side of the house (as opposed to the BDD side) and it's not > a problem to omit BDDs entirely if you don't mind algebraic representations. > > I haven't read the paper you've cited, but I gave a lot of thought to > crypto applications when I was in grad school. Feel free to ignore this: > > As to why BDDs aren't much use for crypto, the answer isn't hard: BDDs only > have huge gains when the logic functions collapse nicely under a certain > ordering of the logic variables. A big random function of 128 variables > probably won't become tractable just because you throw BDDs at it. Luckily, > most of the sorts of functions that real-life hardware designers use are > much more amenable to BDDs, given a suitable variable ordering. Crypto > functions are generally designed to mix up the variables quite completely, > making the functions hard to manipulate algebraically (via theorem provers) > or via BDDs. > > As to the 1972 paper, I'd have to go find it. The earliest FM-for-hardware > papers I've studied are the RSRE Viper project from the mid 1980s. Is the > Lighthill Report online? > >> Some are: 1) how is >> correctness of human coded assertions verified, i.e. errors in assertions >> become injected into formally verified circuits?, > > The problem of writing 'correct' specifications is, IMHO, harder than the > problem of showing that a given design meets the specification. Joe > Jackson said is succintly: you can't get what you want 'till you know > what you want. The best ways I've found for writing good specs is lots > of peer review together with use-case analysis; simulators also help a > lot. Wwriting specs for hardware isn't much different than writing specs > for software. Excepting those damn-near unreadable temporal logic specs, > of course. Those are the specification equivalent to apl - write only. > >> 2) how can circuit proving >> data structures not have exponential size? > > Here are two ideas: a) BDDs may reduce ugly logic equations to a more > compact form, under certain ordering of the variables. See McMillan's > "Symbolic Model Checking", or any BDD reference. I say 'may' because > there are worst-case functions that are not amenable to BDDs. Fortunately, > those sorts of functions are rare in most hardware designs, although crypto > hardware is a notable exception. b) if you maintain the function > symbolically, and do your verification that way, you may avoid exponential > size at the expense of doing a big proof instead. If you do a brute-force > case-analysis on the variables, of course you'll get an exponential number > of proof cases. But the power of the proof tools is being able to perform > induction or otherwise make the proof tractible. > >> 3) how can verification work >> when the same formal algorithms are used to synthesize circuit in one >> direction and verify them in other direction using same "closed system" >> algorithms. > > I think you're confused here. Every formal verification tool I've seen > attempts to show equivalence (or at least implication) of two different > formalisms. For example, between a formal specification written in some > logic (be it a temporal logic, or higher-order logic, or even propositional > logic) and an implementation represented as a state machine, or BDDs, or > some other representation. The benefit lies in showing that the > implementation satisfies the spec. > > The equivalence checking folks make their money (or used to, anyway) > by showing the equivalence of two diffenent forms of the implementation, > as when the design is revved for other bug fixing. The formal checking > takes less time than running a complete regression simulation, hopefully. > >> It is unfortunate that DAC technical committee does not try to balance >> papers that advocate theories with papers that falsify theories. > > No one declared DAC the end-all and be-all of formal methods. > If you've got some interesting results to present to the world, you've > already found Usenet. Matt Drudge broke the Monica Lewinsky fiasco on > his web site - I would assume that you could create a web page on which > to publish your results. > > If you're just bent because DAC rejected your paper, get over it. The > papers of many people are rejected from DAC - they've got finite space > and time considerations. You're actually in good company. > >> In any >> case, what is probably the most one side scientific refereeing in the last >> 500 years should make for interesting listening and observing. > > I think you *might* be over-reacting just a smidge to having your paper > rejected. 500 years of history goes back to 1502. Do you really believe > DAC 2002 is the most one-sided scientific event in all that time? > > So what's the kernel of your gripe with formal methods? It sounds like > you're convinced that FM is totally bogus. I think it's merely a pain > in the butt, expensive, and arcane. But with ICs having 50M transitors > and development schedules under 12 months, FM starts making sense compared > to the concept of thousands of workstations running simulations 24/7. > > Kelly -- Steve Meyer Phone: (612) 371-2023 Pragmatic C Software Corp. email: sjmeyer@pragmatic-c.com 520 Marquette Ave. So., Suite 900 Minneapolis, MN 55402Article: 44006
Hello. I'd like to know where can I send some questions about Celoxica's Handel-C. I', looking for an e-mail list where I can be subscribed. Is it normal it takes 1 hour to make an EDIF from an easy project? Thank you -- Antonio Martínez ÁlvarezArticle: 44007
Folks, I am looking for the best way that doesn't involve a lot of hardcoding of physical information (through directives or floorplanning) to insert an arbitrary number of flops into paths that can tolerate arbitrary cycle relationships and having map/par do the right thing. Let me explain a bit more: Let's say that I have a 32 bit debug bus that goes from one corner of the chip to another. I am perfectly willing to add an arbitrary number of flops to get that bus from point A to point B without having par work very hard to do it. I insert the flops into the RTL (and use the appropriate synthesis directives to ensure they are preserved, etc.), but then map and par don't necessarily do the same think. map chooses to put them into the same slice, par places them without considering actual timing impact, etc. and the additional flops that could help the timing significantly end up being useless. I have a similar problem with my global synchronous reset signal (where I have treated it as a "functional" signal as opposed to using GSR-logic, per the Virtex-II suggestions on Xilinx' web pages). Again, to help par, I have built a couple of stages of a tree to distribute reset to my top level blocks (which are floorplanned). I have locked down the "root" of the reset tree to the middle of the chip. Now, if par could do the right thing with the intermediate and leaf flops to place them close to the blocks that are using them. Alas, that doesn't happen and I have a bunch of reset related paths with large delays in my timing report. The reason I am insisting on trying not to depend on coding this via physical location constraints is that this chip has a bunch of configurtions that control the way its built (as in the logical blocks that are present in the design, the number of those blocks, etc.) The configurations even span two separate physical implementations, in XC2V3000s and XC2V6000s. Given the array of possibilities, coming up with the specific locations for this extra "timing help" flops would be very tedious. I'd like to believe that there has to be a way to get par to do the right thing in getting signals from one floorplanned block to another floorplanned block, via unconstrained flops sprinkled between the blocks. Thanks very much in advance, BerendArticle: 44008
For pipelining, I'm thinking you implement your delays like I do: define an array and pipeline through those stages. To get that to work properly, you need to turn off the MAP option for "register ordering" by adding a -r to the MAP command line. I don't think there's a clean way to do this without the manual running of MAP but I'd love to be wrong. Check the Development System section of the online software manuals and find the MAP utility and its Options. The single pertinent frame is http://toolbox.xilinx.com/docsan/xilinx4/data/docs/dev/map6.html For the reset, I've gone to great lengths to get my synchronous reset to go directly to the reset pin in the individual CLBs rather than the logically acceptable equivalents through combinations with data and other controls. This gives me a full clock cycle to get around the part without extra levels of logic getting in my way. For a Virtex-II, I'd consider 1) using an async reset and 2) using the global clock mux to gate my clock off when I apply the reset then reapply the clock after my reset has deasserted. I'd need to keep a few registers for delay generation on a non-gated clock, but the idea is there: use the global reset but get around skew and delay problems associated with the net by manipulating the clock. I don't want to pay for the Amplify product, but that expensive "physical synthesis" solution might get around some of the proplems you're encountering with greater ease. Ahhh, if only we could get the tools to do "what we want" without a lot of cyber arm twisting. Berend Ozceri wrote: > Folks, > > I am looking for the best way that doesn't involve a lot of hardcoding > of physical information (through directives or floorplanning) to insert > an arbitrary number of flops into paths that can tolerate arbitrary > cycle relationships and having map/par do the right thing. Let me > explain a bit more: > > Let's say that I have a 32 bit debug bus that goes from one corner of > the chip to another. I am perfectly willing to add an arbitrary number > of flops to get that bus from point A to point B without having par work > very hard to do it. I insert the flops into the RTL (and use the > appropriate synthesis directives to ensure they are preserved, etc.), > but then map and par don't necessarily do the same think. map chooses to > put them into the same slice, par places them without considering actual > timing impact, etc. and the additional flops that could help the timing > significantly end up being useless. > > I have a similar problem with my global synchronous reset signal (where > I have treated it as a "functional" signal as opposed to using > GSR-logic, per the Virtex-II suggestions on Xilinx' web pages). Again, > to help par, I have built a couple of stages of a tree to distribute > reset to my top level blocks (which are floorplanned). I have locked > down the "root" of the reset tree to the middle of the chip. Now, if par > could do the right thing with the intermediate and leaf flops to place > them close to the blocks that are using them. Alas, that doesn't happen > and I have a bunch of reset related paths with large delays in my timing > report. > > The reason I am insisting on trying not to depend on coding this via > physical location constraints is that this chip has a bunch of > configurtions that control the way its built (as in the logical blocks > that are present in the design, the number of those blocks, etc.) The > configurations even span two separate physical implementations, in > XC2V3000s and XC2V6000s. Given the array of possibilities, coming up > with the specific locations for this extra "timing help" flops would be > very tedious. I'd like to believe that there has to be a way to get par > to do the right thing in getting signals from one floorplanned block to > another floorplanned block, via unconstrained flops sprinkled between > the blocks. > > Thanks very much in advance, > > BerendArticle: 44009
rickman wrote: I've done both "IN AFTER and OUT BEFORE" style and "IN BEFORE and OUT AFTER" styles. There are three cases that I see. The first is that the frequency is fixed, the second is that I'm designing to fit into specifications not yet fixed outside my design, and the last is that I'm designing something that others will build into their designs. In the first case, I don't see how it matters. In the second, I agree with Rickman that writing the constraints to allow for the clock rate to change is a good point, as it does cut down on the needed effort and some of the opportunities to error when changing clock speed. For the third case, I agree with John_H, as I think that a specification for a widget that others are going to use is best described in "databook style". -- Phil HaysArticle: 44010
Hal Murray wrote:
> In article <3D015A4B.9780DDA2@andraka.com>,
> Ray Andraka <ray@andraka.com> writes:
> > Problem is the lion's share of the skew is caused by jitter in the
> > clock input rather than parameters inherent in the FPGA. In our
> > case, we were inducing much of that jitter by hammering a bunch
> > of outputs on the same bank as the clock input.
>
> Was the clock driving those outputs the same as the input clock
> or asynchronous?
>
> If it's the same clock and the raw input clock is reasonably clean
> then I'd expect the outputs wouldn't start to switch until the clock
> ticked so the outputs wouldn't be switching at the wrong time.
No, different clock. As is typical in our Radar designs, there is an input/ADC
clock, a process clock and a backend interface clock. The process clock is
doubled to get the most bang for the buck, but has very little or no I/O
associated with it. In that case, it was stuff toggling on the backend interface
clock.
>
>
> But if there is "too much" jitter on the input clock then some
> of the time the outputs would be switching at exactly the wrong
> time. Is there a positive feedback loop in there? I'm fishing
> for something with alternate good-bad cycles. On the good cycles
> the internal clock from the previous cycle via the DLL is late
> so nothing is switching at the wrong time. On the bad cycles,
> the clock from the previous cycle via the DLL is early so it
> makes a lot of noise which delays the clock input switching
> to make the clock late for the next cycle...
>
> --
> The suespammers.org mail server is located in California. So are all my
> other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
> commercial e-mail to my suespammers.org address or any of my other addresses.
> These are my opinions, not necessarily my employer's. I hate spam.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44011Antonio Martínez Álvarez wrote: > > Hello. > I'd like to know where can I send some questions about Celoxica's > Handel-C. I', looking for an e-mail list where I can be subscribed. > > Is it normal it takes 1 hour to make an EDIF from an easy project? Wow, imagine how much SW there is between your Source, and this output. Then imagine how much control that means you actually have over the design... For easy projects, ( and even medium ones ), CUPL takes 1-8 seconds to Compile/optimise/fit/simulate and create output files. And bits of it even look like C ... -jgArticle: 44012
Antonio Martínez Álvarez wrote: > I'd like to know where can I send some questions about Celoxica's > Handel-C. I', looking for an e-mail list where I can be subscribed. At least in the USA, Celoxica's technical support was fairly good. Is there a reason why you don't care to contact them? There are a few in this group that seem to have Handel-C experience. > Is it normal it takes 1 hour to make an EDIF from an easy project? Not in my very limited experience. I could make it take significantly longer to build by doing things like dividing by 1024 rather than shifting by 10 bits (these calculations have identical results). -- Phil HaysArticle: 44013
Hi, Another quick newbie question. Reading thorugh the datasheet of the XC18V00 family of PROMs, there is a figure which shows JTAG hardware design setup of PROM with Spartan II FPGA. The TDI line from the JTAG input pins is connected directly to the PROM, with no connection with the FPGA. Using this setup, how is it possible to program the FPGA directly without first loading a PROM file into the PROM? adrianArticle: 44014
Hi Kyle, there is also an English version. For the USB-Version of the Spartan-II development board look here: http://www.cesys.com/english/ebene2/x2s_usb.htm You can order the board from U.S. without problems. Greetings Manfred Kraus "Kyle Davis" <kyledavis@nowhere.com> schrieb im Newsbeitrag news:hxDK8.15955$xm6.255188132@newssvr14.news.prodigy.com... > It's not in English, I don't understand it! Also, I live in the U.S and > would prefer to order something within the U.S. > > "Johann Glaser" <Johann.Glaser@gmx.at> wrote in message > news:adcltu$10cemk$1@ID-115042.news.dfncis.de... > > Hi! > > > > Look at the CESYS X2S_USB Board at > > http://www.cesys.de/ > > They use a Cypress EZ-USB chip for USB communication. > > > > If you need Linux download drivers visit > > https://sourceforge.net/projects/x2susbsfwkit/ (which is actually not > > usefull) or contact me for the files. > > > > Bye > > Hansi > >Article: 44015
Hi all, I have to evaluate the A7 TRISCEND chip. For that I have the A7 Development Board. But as I am a Leonardo user, I can not do synthesis for TRISCEND (not supported). We will buy synopsys or synplicify later. But for now, I am just evaluating the A7 product, and I need to do a synthesis of our CAN ANYBODY DO A SYNTHESIS of my PSK.vhd core to edif2.0.0 netlist (for A7 TRISCEND). If you have some minutes to help me and to do the synthesis of my PSK.vhd, you will give all sources of our Phase Shift Key core. The PSK is actually placed in COOLRUNNERs, SPARTAN-IIs and VIRTEXs Please help me Laurent Gauch www.amontec.comArticle: 44016
Wang Xiao-yun <wangxy@fudan.edu> wrote: > Dear gurus: > I don't know wether there are any success stories on downloading > Altera CPLD through a boundary scan chain together with devices from > other vendors(PMC-Sierra ie.). Basically it works, so there are success stories. But quite a lot of vendors have problems with their implementation of the JTAG port, this can cause the Altera software to fail. On a recent board I had 8 devices, but Quartus detected 9. I don't know about PMC-Sierra, but I know about troubles with Texas DSPs (at least the C62x series) and PLX- PCI- bridges. I used jumpers to be able to bypass this devices. <snip> >Most of the time, we observed an error message of "Unrecognized >devices" and the procedure can not continue, while some other times >(very rare), we may be lucky to finished the program. This sounds similar to our problem with Texas DSPs. They need a few clock cycles on TCK while TRST is asserted, which is not compliant to the JTAG standard. In some rare cases after Power up it worked, but mostly not. > Thanks in advance. > PS: The settings of download are: > MAX-plus II from Altera for program > CPLD EPM7064B from AlteraArticle: 44017
Noddy wrote: > Hi, > > Another quick newbie question. Reading thorugh the datasheet of the XC18V00 > family of PROMs, there is a figure which shows JTAG hardware design setup of > PROM with Spartan II FPGA. The TDI line from the JTAG input pins is > connected directly to the PROM, with no connection with the FPGA. Using this > setup, how is it possible to program the FPGA directly without first loading > a PROM file into the PROM? > > adrian In short - You can't. If you want to be able to load the FPGA directly from JTAG you will have to put it in a daisy chain with the XC18V00 part. That said generating a PROM download file in .exo or .mcs format from the .bit file takes so little time that it barely seems worth the bother these days. Unless, of course, you're into direct bit stream hacking with JBits. One thing to do, if its not already shown on the diagram, is to connect the XC18V00's CF pin to the FPGA's PROGRAM* pin so that, with the appropriate box on the iMPACT ticked, the FPGA is reconfigured after the XC18V00 download is complete. Finally: Beware of a classic ``Let's catch the newbies out'' thing - If you *do* want to download direct to the FPGA via JTAG then remember to set the BITGEN start-up clock option to "JTAG" [or something like that]. If I had $10 for each time this has come up on this NG I'd be writing this from some tropical paradise island .... sigh.Article: 44018
Thanks for the help... adrian > > Noddy wrote: > > > Hi, > > > > Another quick newbie question. Reading thorugh the datasheet of the XC18V00 > > family of PROMs, there is a figure which shows JTAG hardware design setup of > > PROM with Spartan II FPGA. The TDI line from the JTAG input pins is > > connected directly to the PROM, with no connection with the FPGA. Using this > > setup, how is it possible to program the FPGA directly without first loading > > a PROM file into the PROM? > > > > adrian > > In short - You can't. If you want to be able to load the FPGA directly from JTAG > you will have to put it in a daisy chain with the XC18V00 part. That said > generating a PROM download file in .exo or .mcs format from the .bit file takes > so little time that it barely seems worth the bother these days. Unless, of > course, you're into direct bit stream hacking with JBits. > > One thing to do, if its not already shown on the diagram, is to connect the > XC18V00's CF pin to the FPGA's PROGRAM* pin so that, with the appropriate box on > the iMPACT ticked, the FPGA is reconfigured after the XC18V00 download is > complete. > > Finally: Beware of a classic ``Let's catch the newbies out'' thing - If you > *do* want to download direct to the FPGA via JTAG then remember to set the > BITGEN start-up clock option to "JTAG" [or something like that]. If I had $10 > for each time this has come up on this NG I'd be writing this from some tropical > paradise island .... sigh. >Article: 44019
Hi, I know that one should place 0.1uF and 0.01uF caps on all power supply pins on the FPGA... does this include both Vcco and Vccint, or can one get away with just Vccint and then put only 0.1uF on Vcco. I am seriously running out of room on my PCB, and increasing the PCB size is not an option! adrianArticle: 44020
Hello folks,
I have written a VHDL design that I am trying to get to run at as high a
clock-rate as possible - I am using Synplify 7.03 and Xilinx ISE 4.1.03i.
I think my VHDL is as pipelined as it could be - I have quoted a cut-down
version of the code here. The structure of my design is all present along
with examples from each block of repetitive code that I have cut down to
make things clearer here.
The design is simple - an input vector is passed too the 1st of four
processes that are sensitive only to the rising edges of my clock. The 1st
process (pipe stage 1) generates more signals and passes them to pipeline
stage 2 (process 2). The pipeline stage 2 signals are passed to pipeline
stage 3. Pipeline stage 3 passes signals to the final process (AdderChain )
which produces Tap30_Sub_V17 which is hard-wired to the output Y.
I synthesise this is Synplify and APR it in ISE. I use a UCF file that
specifies LOCs for the signals as I believe I have to do this to stop the
whole design being optimised away for not being connected to anything!
I also specify a 10ns period for my clock in the UCF file.
Anyway, after mapping, the maximum clock frequency is reported to be
138.947MHz.
But, after place and route, the max clock freq. is reported to be 91.166MHz.
Where could I be losing so much MHz? Can my choice of LOCs in the UCF
affect the max clock freq.?
Is there anything in my VHDL I can change/add (attributes?) to make it run
faster? Any Synplify settings I can change?
Or can I make it run faster via some ISE settings?
Any help greatly appreciated...
Thanks for your time,
Ken
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_signed.all;
use IEEE.std_logic_arith.all;
entity ePipelinedDesign is
port (
CLK : in STD_LOGIC;
X : in std_logic_vector(11 downto 0);
Y : out std_logic_vector(24 downto 0)
);
end ePipelinedDesign;
architecture aPipelinedDesign of ePipelinedDesign is
-- *** lots of signals declared in here
signal CLKi : std_logic;
component BUFGDLL
port (
I : in STD_ULOGIC;
O : out STD_ULOGIC);
end component;
begin
CLK_IN : BUFGDLL port map (I => CLK, O => CLKi);
-- example of a concurrent signal assignment
V_168_P3 <= V_21_P3 & "000";
PipelineStage_1 : process (CLKi)
begin
if (rising_edge(CLKi)) then
-- examples of pipeline stage 1 signals
-- being generated from the input
V_1_P1 <= V_1_P0;
V_7_P1 <= (V_1_P0 & "000") - SXT(V_1_P0,15);
end if;
end process;
PipelineStage_2 : process (CLKi)
begin
if (rising_edge(CLKi)) then
-- two examples of pipeline stage 2 using
-- signals from pipe stage 1
V_3_P2 <= (V_1_P1 & "0") + SXT(V_1_P1,14);
V_39_P2 <= (V_1_P1 & "00000") + SXT(V_7_P1,18);
end if;
end process;
PipelineStage_3 : process (CLKi)
begin
if (rising_edge(CLKi)) then
-- two examples of pipeline stage 3 using
-- signals from pipe stage 2
V_17_P3 <= (V_1_P2 & "0000") + SXT(V_1_P2,17);
V_21_P3 <= (V_3_P2 & "000") - SXT(V_3_P2,17);
end if;
end process;
-- the output is permanently wired here
Y <= Tap30_Sub_V17;
AdderChain : process (CLKi)
begin
if (rising_edge(CLKi)) then
-- two examples of pipeline stage 3 signals being added
Tap13_Add_V617 <= SXT(Tap12_Add_V261,23) + SXT(V_617_P3,23);
Tap14_Add_V910 <= SXT(Tap13_Add_V617,24) + SXT(V_910_P3,24);
Tap30_Sub_V17 <= SXT(Tap29_Sub_V29,25) - SXT(V_17_P3,25);
end if;
end process;
end aPipelinedDesign;
Article: 44021"Noddy" <g9731642@campus.ru.ac.za> wrote in message news:<1023692147.287737@turtle.ru.ac.za>... > Hi, > > Another quick newbie question. Reading thorugh the datasheet of the XC18V00 > family of PROMs, there is a figure which shows JTAG hardware design setup of > PROM with Spartan II FPGA. The TDI line from the JTAG input pins is > connected directly to the PROM, with no connection with the FPGA. Using this > setup, how is it possible to program the FPGA directly without first loading > a PROM file into the PROM? > > adrian The JTAG software will instruct the JTAG controller built into the PROM (and other devices in your JTAG chain) to go into a bypass mode. Have fun, MarcArticle: 44022
"Noddy" <g9731642@campus.ru.ac.za> wrote in message news:1023706297.365340@turtle.ru.ac.za... > Hi, > > I know that one should place 0.1uF and 0.01uF caps on all power supply pins > on the FPGA... does this include both Vcco and Vccint, or can one get away > with just Vccint and then put only 0.1uF on Vcco. I am seriously running out > of room on my PCB, and increasing the PCB size is not an option! > > adrian > > It's "vital" to put those caps if you need to get correct results from your board ;) And for the capacitors, follow exactly the directions from the data-sheets of your device. Unless you're not going to analyze your PCB with something like Hyperlynx, you'd better be carefull to follow what is suggested in the data-sheet as choosing the right capacitor and it's placement is not a trivial job. Regards ArashArticle: 44023
In my design internal clock is sourced from 4-to-1 multiplexer. Inputs of the multiplexer are connected to IPADs. Is there any possibility to add OFFSET_IN_BEFORE / OFFSET_OUT_AFTER constraint to this internal clock line. Thanks in advance, Piotr ForytArticle: 44024
Ken Mac wrote: > Hello folks, > > I have written a VHDL design that I am trying to get to run at as high a > clock-rate as possible - I am using Synplify 7.03 and Xilinx ISE 4.1.03i. > > I think my VHDL is as pipelined as it could be - I have quoted a cut-down > version of the code here. The structure of my design is all present along > with examples from each block of repetitive code that I have cut down to > make things clearer here. > > The design is simple - an input vector is passed too the 1st of four > processes that are sensitive only to the rising edges of my clock. The 1st > process (pipe stage 1) generates more signals and passes them to pipeline > stage 2 (process 2). The pipeline stage 2 signals are passed to pipeline > stage 3. Pipeline stage 3 passes signals to the final process (AdderChain ) > which produces Tap30_Sub_V17 which is hard-wired to the output Y. > > I synthesise this is Synplify and APR it in ISE. I use a UCF file that > specifies LOCs for the signals as I believe I have to do this to stop the > whole design being optimised away for not being connected to anything! > > I also specify a 10ns period for my clock in the UCF file. > > Anyway, after mapping, the maximum clock frequency is reported to be > 138.947MHz. > > But, after place and route, the max clock freq. is reported to be 91.166MHz. > > Where could I be losing so much MHz? Can my choice of LOCs in the UCF > affect the max clock freq.? > > Is there anything in my VHDL I can change/add (attributes?) to make it run > faster? Any Synplify settings I can change? > > Or can I make it run faster via some ISE settings? > > Any or all of those things might help but before you get started trying you'll need to do get a full timing report from TimingAnalyser or (command line) TRCE. This should give you a breakdown of failing paths but before you run this its probably worth re-doing your design and add some temporary pin assignments on CLK,X,Y so its ``connected to something''.
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