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
Hi I'm trying to porting uclinux using microblaze 4.0. When I try to run the OS I've got the following error message. Kernel panic: VFS: Unable to mount root fs on 1f:00 Does anybody had a similar problem? Thanks in advance, FrancescoArticle: 110676
Josh Rosen wrote: > On Thu, 19 Oct 2006 16:38:26 +0200, Henrik Pedersen wrote: > >> Josh Rosen wrote: >> >>> On Thu, 19 Oct 2006 13:54:10 +0200, Henrik Pedersen wrote: >>> >>>> Next problem. >>>> >>>> Running a simulation turns up the following error. >>>> ERROR:Simulator:222 - Generated C++ compilation was unsuccessful >>>> >>>> Seaching Xilinx.com does'nt give many ideas as to what is happening. >>>> >>>> Anyone here has a clue ? >>>> >>>> Henrik >>> >>> What simulator are you using? >> >> I was told that Multisim was'nt supported for the free edition of webpack >> for Linux, så i'm trying to make the ISE simulator work. >> >> Henrik > > I don't know anyone who is using the ISE simulator. Most people use NCsim, > VCS or ModelSim, I use NC. If you are looking for a free simulator I'd > suggest that you give icarus a try. > > http://www.icarus.com/eda/verilog/ I ment ModelSim offcourse. I would like to use ModelSim, as i have some experience with it. Does Icarus support VHDL as well as Verilog ? HenrikArticle: 110677
Marc, why didn't you try to google for the answer? This question is asked every other week on comp.arch.fpga. I only reply because I have some new numbers. marc_ely wrote: > Has anyone recently done any benchmarking of Windows PC's for Xilinx > ISE Compiles? No, but I have for Quartus which is very similar. > Is ISE multithreaded? No and not for a while to come. > Can it use multiple processors (or cores)? Nope. > Do big CPU caches help? Oh yeah, but once you have that, core frequency is all that matters. I recently went from an Athlon 64 2.0 GHz/1 MiB L2$ to a E6600 Core 2 Duo 2.4 GHz/4 MiB L2$. For my benchmark, the time for Synth/P&R went from 12m34/33m40 to ~6m/~15m, thus more then double the P&R performance. When overclocked to 3.3 GHz the result scaled to 5m54/11m12, thus 3X the P&R performance. Other experiments confirm that it scales linearly with frequency (assuming memory scales equally). I have expensive memory, but from my experiments the benchmark results showed very little sensitivity to memory bandwidth and latency. The 4 MiB Core 2 Duo is a very fast chip for FPGA work, probably the fastest x86 available, but it's still not fast enough to reduce the compilation times to an acceptable level. TommyArticle: 110678
Francesco wrote: > Hi I'm trying to porting uclinux using microblaze 4.0. > When I try to run the OS I've got the following error message. > > Kernel panic: VFS: Unable to mount root fs on 1f:00 > > Does anybody had a similar problem? > > Thanks in advance, > Francesco > Linux is up but it can't mount the root partition. What is your kernel command line? What is the "root=xxx" specifically. That device number 1f:00 seems screwy. It's not listed in include/linux/major.h. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 110679
> Digilent has a $59 board with a 100k-gate FPGA, switches, port > connectors, LEDs etc. > http://digilentinc.com/Products/Detail.cfm?Prod=BASYS BINGO!!! Id like to start there ... after I have gained some experience, I can buy a more more expensive FPGA board with larger resources Thanks > I think that seeing something work in reality is an important part of > learning, even though simulators give you more insight into what's > happening. Otherwise you get to your first real design after a few > years of learning VHDL and then you ask 'what does non-synthesizable > mean?' I like to put equal time in reading/research as I do in "lab work". Theres a certain joy and "ahah" factor that comes from seeing the results in front of you. priceless!Article: 110680
NigelE wrote: > I actually think the broad scope of TLM is one of its key strengths. > Being able to apply the same techniques across a wide range of problems > means the same methodology can be used at multiple abstraction levels. > Transactors are used to communicate across these abstraction boundaries > (not just the TLM<>signal boundary) enabling modelling to occur at the > highest abstraction level appropriate resulting in smaller/faster code. Sorry, Nigel, I don't agree with this. Broad definitions lead to ambiguity. Everything which is not formalized is ambiguis. Ambiguity of the basic terms leads to ambiguity of the whole system, based on these terms. We all know how difficult is to work with ambiguis specifications. The problem is that we believe that we understand correctly the meaning of some term, and don't do any efforts to clarify things further. Then, we spend significant amount of time and energy in wrong direction. As verification engineers, we have to formalize design specification documents in verification plans, thus removing ambiguity from them. However, we have ambiguity in our own definitions, which leads to many communication problems. Transaction definition is one example. Here is another one: what is the difference between assertions, assertion monitors, asertion-based checkers, non-assertion-based checkers and scoreboards? All of them validate the correctness od some design properties during all simulation time and independently of stimulus. > A quick point on AVM monitors. > The AVM provides a capability called an analysis port (which is an > implementation of the OO design observer design pattern). > > An analysis port provides a mechanism for a monitor to broadcast > transactions to zero or more subscribers (listeners) via a single > write() function call. > > The subscribers need to implement a write() function, each of which can > do different things (eg record functional coverage, update a scoreboard > etc). Thus a monitor does not need to know in what context it will be > used as it is only in the top level environment of the simulation where > analysis components are registered onto a particular analysis port. > > This makes AVM monitors extremely generic, being able to be used in > module, chip and system verification and across multiple designs using > the same interface. Thanks for clarification. In this case, the monitors are not "transaction senders" but rather "transaction presenters", which really make them highly reusable. I am also using similar concept to build Verilog testbenches for more than 4 years. Regards, -AlexArticle: 110681
On Thu, 19 Oct 2006 18:15:51 +0200, Henrik Pedersen wrote: > Josh Rosen wrote: > >> On Thu, 19 Oct 2006 16:38:26 +0200, Henrik Pedersen wrote: >> >>> Josh Rosen wrote: >>> >>>> On Thu, 19 Oct 2006 13:54:10 +0200, Henrik Pedersen wrote: >>>> >>>>> Next problem. >>>>> >>>>> Running a simulation turns up the following error. >>>>> ERROR:Simulator:222 - Generated C++ compilation was unsuccessful >>>>> >>>>> Seaching Xilinx.com does'nt give many ideas as to what is happening. >>>>> >>>>> Anyone here has a clue ? >>>>> >>>>> Henrik >>>> >>>> What simulator are you using? >>> >>> I was told that Multisim was'nt supported for the free edition of webpack >>> for Linux, så i'm trying to make the ISE simulator work. >>> >>> Henrik >> >> I don't know anyone who is using the ISE simulator. Most people use NCsim, >> VCS or ModelSim, I use NC. If you are looking for a free simulator I'd >> suggest that you give icarus a try. >> >> http://www.icarus.com/eda/verilog/ > > > I ment ModelSim offcourse. > I would like to use ModelSim, as i have some experience with it. > Does Icarus support VHDL as well as Verilog ? > > Henrik Icarus is Verilog. There are some free VHDL projects out there, I don't know anything about them, I use Verilog.Article: 110682
NigelE wrote: > I actually think the broad scope of TLM is one of its key strengths. > Being able to apply the same techniques across a wide range of problems > means the same methodology can be used at multiple abstraction levels. > Transactors are used to communicate across these abstraction boundaries > (not just the TLM<>signal boundary) enabling modelling to occur at the > highest abstraction level appropriate resulting in smaller/faster code. Sorry, Nigel, I don't agree with this. Broad definitions lead to ambiguity. Everything which is not formalized is ambiguis. Ambiguity of the basic terms leads to ambiguity of the whole system, based on these terms. We all know how difficult is to work with ambiguis specifications. The problem is that we believe that we understand correctly the meaning of some term, and don't do any efforts to clarify things further. Then, we spend significant amount of time and energy in wrong direction. As verification engineers, we have to formalize design specification documents in verification plans, thus removing ambiguity from them. However, we have ambiguity in our own definitions, which leads to many communication problems. Transaction definition is one example. Here is another one: what is the difference between assertions, assertion monitors, asertion-based checkers, non-assertion-based checkers and scoreboards? All of them validate the correctness od some design properties during all simulation time and independently of stimulus. > A quick point on AVM monitors. > The AVM provides a capability called an analysis port (which is an > implementation of the OO design observer design pattern). > > An analysis port provides a mechanism for a monitor to broadcast > transactions to zero or more subscribers (listeners) via a single > write() function call. > > The subscribers need to implement a write() function, each of which can > do different things (eg record functional coverage, update a scoreboard > etc). Thus a monitor does not need to know in what context it will be > used as it is only in the top level environment of the simulation where > analysis components are registered onto a particular analysis port. > > This makes AVM monitors extremely generic, being able to be used in > module, chip and system verification and across multiple designs using > the same interface. Thanks for clarification. In this case, the monitors are not "transaction senders" but rather "transaction presenters", which really make them highly reusable. I am also using similar concept to build Verilog testbenches. Regards, -AlexArticle: 110683
Alex wrote: > NigelE wrote: > > > I actually think the broad scope of TLM is one of its key strengths. > > Being able to apply the same techniques across a wide range of problems > > means the same methodology can be used at multiple abstraction levels. > > Transactors are used to communicate across these abstraction boundaries > > (not just the TLM<>signal boundary) enabling modelling to occur at the > > highest abstraction level appropriate resulting in smaller/faster code. > > Sorry, Nigel, I don't agree with this. > Broad definitions lead to ambiguity. Everything which is not formalized > is ambiguis. Ambiguity of the basic terms leads to ambiguity of the > whole system, based on these terms. > > We all know how difficult is to work with ambiguis specifications. The > problem is that we believe that we understand correctly the meaning of > some term, and don't do any efforts to clarify things further. Then, we > spend significant amount of time and energy in wrong direction. > > As verification engineers, we have to formalize design specification > documents in verification plans, thus removing ambiguity from them. > However, we have ambiguity in our own definitions, which leads to many > communication problems. Transaction definition is one example. Here is > another one: what is the difference between assertions, assertion > monitors, asertion-based checkers, non-assertion-based checkers and > scoreboards? All of them validate the correctness od some design > properties during all simulation time and independently of stimulus. > > > A quick point on AVM monitors. > > The AVM provides a capability called an analysis port (which is an > > implementation of the OO design observer design pattern). > > > > An analysis port provides a mechanism for a monitor to broadcast > > transactions to zero or more subscribers (listeners) via a single > > write() function call. > > > > The subscribers need to implement a write() function, each of which can > > do different things (eg record functional coverage, update a scoreboard > > etc). Thus a monitor does not need to know in what context it will be > > used as it is only in the top level environment of the simulation where > > analysis components are registered onto a particular analysis port. > > > > This makes AVM monitors extremely generic, being able to be used in > > module, chip and system verification and across multiple designs using > > the same interface. > > Thanks for clarification. In this case, the monitors are not > "transaction senders" but rather "transaction presenters", which really > make them highly reusable. I am also using similar concept to build > Verilog testbenches. > > Regards, > -Alex Alex, I think this definition issue depends on the perspective you are looking from ;) I agree that within a verification team, you should have a clear, common understanding of what each component should and shouldn't do. However, what may be suitable for one team may be too loose OR too restrictive for another team. Thus a methodology that can accommodate most user requirements is one that can be broadly adopted. However that doesn't preclude it being used in a tightly defined manner. I guess where we differ is who should be responsible for defining these precise definitions - the user or the tool/methodology provider ? Regards - NigelArticle: 110684
Roger schrieb: > A design is built to work at 50MHz, but the deisgn when tested works > only at 48MHz. What > should we do to make the design meet specific timing constraint .i.e. > to make the design to make it work at 50 MHz? Read the report of the critical path. You need to understand, where this path is located (not the placement - I mean the logical connection from one flipflop to an other) and why it is so long. Then think about shortening the path. (Maybe you can insert a pipeline step or move some combinational logic block outside this path.) RalfArticle: 110685
Al wrote: > Eli Bendersky wrote: > > The solution usually used is an external > > reset circuit (they come packed in nice tiny ICs these days) that > > provides a clean reset signal of 200 ms (or whatever you set it to) > > whenever there's a problem with the supplies, and as a byproduct, when > > the power is going up. > > Excuse me Eli, can you give me a reference for those tiny ICs? > thanks a lot > > Al > Hello Al, Googling "voltage supervisor" will bring up lots of results EliArticle: 110686
"Roger" <hpsham@gmail.com> wrote: >A design is built to work at 50MHz, but the deisgn when tested works >only at 48MHz. What >should we do to make the design meet specific timing constraint .i.e. >to make the design to make it work at 50 MHz? >Thanks Are you sure all signals are covered by timing constraints? Don't forget connections which connect IO cells to internal flipflops. These should be constrained as well. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 110687
marc_ely wrote: > I would really like to fix down some of the blocks to stop the Xilinx > tool re-placing etc. <snip> > > At first glance there seems to be many options in the Xilinx tools to > do this, but I can't get any of them to work properly. > So far I have tried the following: <snip> > - Planahead. Beta, poor doc's, didn't know where to start really. > Even my FAE doesn't have a scooby-doo about this one. I have to come to the defense of PlanAhead here. Although I don't use it as part of an incremental flow, I do use it to improve timing, and I found it surprisingly easy to use. I watched the video-on-demand demo, scanned the documentation then started floorplanning. In most cases I've found it sufficient to just assign area groups to modules, but it's not hard to lock the placement (but not routing) of logic elements within the module. --- Joe Samson Pixel VelocityArticle: 110688
> Alex, > > I think this definition issue depends on the perspective you are > looking from ;) > > I agree that within a verification team, you should have a clear, > common understanding of what each component should and shouldn't do. > However, what may be suitable for one team may be too loose OR too > restrictive for another team. Thus a methodology that can accommodate > most user requirements is one that can be broadly adopted. However > that doesn't preclude it being used in a tightly defined manner. In this context, I am not speaking about "what each component should and shouldn't do". I am speaking about terminology and basic definitions. The whole industry will betefit from speaking the same language. Imagine, for example, job interview question: "What is scoreboard?". Or : "What does transaction mean?". The applicant is lucky, if his/her understanding of scoreboard/transaction matches the understanding of the interviewer. > I guess where we differ is who should be responsible for defining these > precise definitions - the user or the tool/methodology provider ? For me, there is only one answer: methodology provider. Methodiology is a building, and definitions/concepts are the building blocks. If the shape of building block changes (at least, slightly), the shape of the whole buiding changes significantly. Then, user definitions are not always complementary - they can also contradict. The attempt of "being nice to everyone by making loose definitions" may reduce the technical value of the whole methodology, developed by EDA company. Regards, -AlexArticle: 110689
Stevo_V2pro wrote: > Does anyone know if it is possible to have mutltiple processors be able > to access the DDR memory in an ML310 board(Virtex-II Pro)? Currently I > am experimenting with 2 PowerPC cores, but I am also looking into using > a single PPC core and a single microblaze core. I'm intending to run a > seperate operating system on each of the cores and would like each to > have access to a fast and decent sized amount of RAM. I've seen guides > using shared BRAMS for having two procs accessing the same memory for > data sharing, but BRAMs are relatively small. I'm not looking to share > data between the procs. Essentially, I want both processors to be able > to use RAM, but have separate memory spaces within that RAM. If this > is not possible, is it possible for the two procs to have access to the > same memory space, but to avoid collisions by assigning each operating > system a spearate portion of that memory space to use? I would assume > that both processors need to be on the same bus as the memory > controller, and some sort of bus arbitration mechanism would be needed. > Any help that anyone can provide would be greatly appreciated. > You can put both the processors on a single plb and use plb_ddr. If you are concerned about bandwidth, then you should look into MPMC2 design examples @ www.xilinx.com/mpmc2 /SivaArticle: 110690
Nico Coesel wrote:
> "Roger" <hpsham@gmail.com> wrote:
>
> >A design is built to work at 50MHz, but the deisgn when tested works
> >only at 48MHz. What
> >should we do to make the design meet specific timing constraint .i.e.
> >to make the design to make it work at 50 MHz?
> >Thanks
>
You can try one or more of the following -
1. Over-constrain your clock frequency in the Synthesis tool -
Set the clock frequency to 55-60Mhz and then run it through the P&R
tool. This sometime results in better timing for the bitstream (I have
myself noticed this with Synplify synthesis + Xilinx ISE on a couple of
ocassions).
2. The P&R tool (Xilinx, Altera, or whichever you are using) will
always have options to compile for speed, area, etc. Assuming area (or
resources) is not a critical concern you can set the compile option for
"compile for speed". Some tools also offer multiple synthesis runs with
different seeds and then pick the best result for the bitstream.
3. As someone has already suggested earlier, make sure that you have
the latest speed files (technology) files and/or latest P&R software.
However, sometimes an older version can give better results, so you can
try runs with one or two tool versions.
4. If nothing works, then, go back to the source - make changes to the
RTL and re-code to optimize for timing.
Hope this helps.
Article: 110691Really appreciate everyone's input , the specifies are a little different to my first understand of the problem but never the less useful information ( I'm just an undergrad , still learning the ropes) . Ben with your response , I'm unable to make count1 2^N because its actually the measured result that will vary depending on the drift of the oscillator, if the formula was the other way around it would make the problem much easier , using your solution. Peter , I can't use the external clock reference because the nco utilizes a rocketio mgt component and the specifics require the local 125MHz clock to drive it ,, only with hardware changes can I change this " and for the time been isn't really the most viable option , hence implementing compensator circuit. Ray , similar to Bens answer , the problem is , the denominator is measured , thus varying So delta2 = (nominal/ measured) * delta1 One solution is to do a lookup table and also utilize linear interpolation between points. Count of NCO (which is measured count of local oscillator) corresponds to a particular delta correction phase. Please feel free to ask more question if anything is un clear.. Also you future references are there custom cores available for divisions? Ray Andraka wrote: > luca_grossi@hotmail.com wrote: > > > Hi everyone, > > I'm currently using a vitex-II pro FPGA, I've implemented an NCO > > frequency generator, which is supplied with a 64bit init & delta phase > > value. I'm currently using a local oscillator to clock the NCO ( must > > use specific local oscillator) but this does contain a margin of offset > > and drift thus influencing output frequency of NCO. A compensation > > circuit which includes another stable clock is used to correct the > > drift and offset by using a frequency counter on both clocks then > > calculating appropriate delta phase to compensate. My problem is that > > my equation to calculate adjusted delta which requires a 64 bit > > division > > > > Delta2 = (count2/count1) * delta1 > > > > Delta2 = new delta phase with correction > > Count2 = frequency counter for Local Oscillator > > Count1 = frequency counter for external Oscillator > > Delta1 = Original calculated delta phase to product output frequency > > > > What would be the most appropriate way of doing this calculation, > > especially with the division? also time constraints, everyone 1.6ms > > roughly this will occur. > > Maybe this could be done differently? Ideas I've been thinking about > > are on the lines of, Maybe reduces the counting resolution ? use > > internal PPC (CPU) > > > > Any advice would be appreciated :) > > Cheers Luca > > > > Division is the brute force way of addressing that, but is not really a > good approach in most cases. When dealing with two counts like that, > you can count the number of clocks of the numerator clock per cycle (or > multiple cycles) of the denominator clock to determine the ratio without > performing an explicit division. In fact, you don't even need a > frequency counter, as that is what you are constructing here anyway. > The more cycles of clk1 you accumulate clk2 over, the greater the > precision of your result. Basically you have a counter that counts up > with each cycle of clk2 that is read and reset every N cycles of clk1. > Multiply that by your delta constant to get the adjustment. > > There are some more advanced tricks to determine fractional clocks in > order to reduce the accumulation time, but that is beyond the scope of a > usenet post I think. > > For this type of application, it is more common to use a feedback loop > and a measured parameter such as residual frequency after the mixer to > nudge the DDS increment up or down. Look at phase lock loops for this.Article: 110692
Hi. I am trying to write generic VHDL code for FIR filter. generic parametars should be word_length, filter_order. Can anybody help me how to input filter coeficients. I tought something like, read coeficitients from file and write it in some LUT table. Could it be done (or something similar)? Thanks for helpArticle: 110693
On Oct 19, 4:04 pm, luca_gro...@hotmail.com wrote: > > So delta2 = (nominal/ measured) * delta1 > > One solution is to do a lookup table and also utilize linear > interpolation between points. Count of NCO (which is measured count of > local oscillator) corresponds to a particular delta correction phase. Since you are in a V2Pro, you have multipliers galore, and can build adders. For a 64-bit quotient in good time you might try Newton-Raphson approximation. See e.g.: http://www.azillionmonkeys.com/qed/adiv.html for a start (the simplest early google hit for Newton-Raphson division). If you have 1.6ms, that's an incredibly long time, and a long divider would work easily if you are strapped for multipliers or fabric. > Please feel free to ask more question if anything is un clear.. Also > you future references are there custom cores available for divisions? The circuitry goes together easily, if you're a student, the exercise will do you good!Article: 110694
luca_grossi@hotmail.com wrote: > Really appreciate everyone's input , the specifies are a little > different to my first understand of the problem but never the less > useful information ( I'm just an undergrad , still learning the > ropes) . Ben with your response , I'm unable to make count1 2^N > because its actually the measured result that will vary depending on > the drift of the oscillator, if the formula was the other way around it > would make the problem much easier , using your solution. > Peter , I can't use the external clock reference because the nco > utilizes a rocketio mgt component and the specifics require the local > 125MHz clock to drive it ,, only with hardware changes can I change > this " and for the time been isn't really the most viable option , > hence implementing compensator circuit. > Ray , similar to Bens answer , the problem is , the denominator is > measured , thus varying > > So delta2 = (nominal/ measured) * delta1 > > One solution is to do a lookup table and also utilize linear > interpolation between points. Count of NCO (which is measured count of > local oscillator) corresponds to a particular delta correction phase. > > Please feel free to ask more question if anything is un clear.. Also > you future references are there custom cores available for divisions? > Perhaps I am missing a few things here. You have both clocks, no? If you do, you don't need the frequency measurement from somewhere else, you use the clocks themselves and the counter arrangement I described. A more conventional approach would be to not worry about the specific delta, but instead nudge it up or down with feedback derived from the frequency or phase error at the NCO output (mix the NCO with the signal and determine the phase/frequency offset from the resulting beat). Properly done, it will self adjust without ever having to compute the delta value. The sample rate through your NCO is fixed by the clock (I think you said it is a 125 MHz clock). The signal's center frequency is determined by the transmitter, but you don't have access to exact transmitter frequency (besides, it will drift). As a result, you need to vary the phase increment for the NCO in order to match the transmitter's carrier.Article: 110695
Zorjak wrote: > Hi. > I am trying to write generic VHDL code for FIR filter. generic > parametars should be word_length, filter_order. Can anybody help me > how to input filter coeficients. I tought something like, read > coeficitients from file and write it in some LUT table. Could it be > done (or something similar)? > > Thanks for help > If it is synthesizable code, it can't go and read files. What you can do though is have a helper function that converts your coefficient file into a VHDL package containing the coefficient constants. Write that package to a file, and then include that file with the rest of the design when you compile the design. The helper function can be non-synthesizable VHDL, C, Matlab or any other programming language you feel like using. Alternatively, you can cut and paste your coefficients into a VHDL package or directly into a constant array in your code. You can also pass the coefficients into the entity through a generic by defining an integer_array type in a top level package, referring to that package in the library declarations, and then putting the int_array in the generics like this: component matrix generic( coefs: int_array:= ( -62465, -8923, 24026, 39814, 41873, 33635, 18534, 0,-18534,-33636,-41873,-39813,-24025, 8925, 62468, 48188, 27536, 10061)); port( clk : in std_logic; Leaving the integer array unconstrained allows you to put in an arbitrary number of coefficients (must be more than 1).Article: 110696
Hi, I installed XPS - EDK 8.1i in my WinXP machine. When I try to call XPS the DPS window appears, and dissapears within a few seconds and nothing else happens. Reviewing the C:\EDK folder, a file bash.exe.stackdump appears, which contents are: Exception: STATUS_ACCESS_VIOLATION at eip=00000000 eax=00000000 ebx=0247ED28 ecx=0247EB64 edx=7C91EB94 esi=0247ED2C edi=00000000 ebp=0247ED30 esp=0247ED08 program=C:\EDK\cygwin\bin\bash.exe, pid 1680, thread main cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023 Stack trace: Frame Function Args End of stack trace How could I fix this? Regards.Article: 110697
On 2006-10-09 08:55:58 -0700, Austin Lesea <austin@xilinx.com> said: > Rajeev, > > Xilinx takes seriously any suggestions. > > We, of all people, with the introduction of the Virtex 5 LX330, know > that we need to somehow make everything work better, and faster. > > Note that due to the memory required, the LX330 can ONLY be complied on > a 64 bit Linux machine.... there are just too many logic cells, and too > much routing. 8 Gbytes is about what you need, and windoze can't handle > it (at all). Well then, it's about time you ported it to the Mac, isn't it ? A full 64-bit OS, with quad top-of-the-range processors on the desktop machine and gobs of RAM using this new weirdo serial-network RAM interface... Given that you've got a Linux version (which uses X), and an X server on the Mac (which also runs a pretty plain-vanilla Unix for its OS), the only real barrier ought to be the QA overhead... Perhaps not *quite* as simple as typing 'make', but almost certainly within the confines of an intern's summer job :) Well ? Simon :)Article: 110698
"marc_ely" <marc_ely@yahoo.co.uk> wrote in message
news:1161261816.609566.34830@b28g2000cwb.googlegroups.com...
> Hi
> I am working on some Spartan3 projects using ISE8.2 on WindowsXP.
>
> One of the designs (XC3S4000) instantiates a core from a 3rd party as
> an EDIF netlist. I then add all sorts of other home spun blocks around
> it.
>
> I am quite happy with the core's function, and am now just adding
> peripheral blocks and debugging them etc.
> This is proving frustrating due to the Xilinx tool ripping up and
> re-routing the whole design each time I compile. It takes 1.5hrs to
> recompile, which may not sound a lot, but to add a wire is a bit
> ridiculous IMHO.
>
> I would really like to fix down some of the blocks to stop the Xilinx
> tool re-placing etc.
>
> At first glance there seems to be many options in the Xilinx tools to
> do this, but I can't get any of them to work properly.
> So far I have tried the following:
> - Partitions. They don't work >at all< do they? I can't even add one
> and get it to pass through MAP.
> - Incremental Design Flow, I don't seem to be able to get ISE to use
> my area constraints, and how do you find out how big to make blocks in
> floorplanner?
> - Planahead. Beta, poor doc's, didn't know where to start really.
> Even my FAE doesn't have a scooby-doo about this one.
> - FPGA Editor Does anyone use the probe points to debug? I don't
> seem to have anywhere near a full netlist to choose from, even if I
> don't flatten
>
> So questions to experienced ISE users;
> 1) How do you tie blocks down? (or do you not bother?)
Typically, the main reason for a long par time is challenging timing
constraints. The tool is 'throwing darts' initially, and then working
towards a locally optimal solution. If you can spend the time to figure out
where the trouble spots are, you can:
1) Determine if the timing requirement is real on these critical paths.
(Often, there is a multi-cycle path. When you take unnecessary pressure off
the tool, it tends to do a better job achieving timing closure.)
2) Lock down the endpoints in the critical paths. Sometimes this is
obvious, sometimes it's not.
3) Force (in your code, for instance) register/logic replication to
reduce fanout.
4) Prohibit register/logic replication. (The answer is: it depends.)
5) Direct par to leverage a previous route. (This can improve things,
and it can make things much worse. It depends.)
6) Use incremental and/or hierarchical design techniques. The tools
are very good at solving challenging, but small, problems. They are pretty
good at solving easy, but large, problems. Oftentimes blocks A, B, & C will
meet timing closure individually quite quickly, but flounder when all three
are present. I haven't experimented with the hierarchical design flow in a
couple of years, but I did notice that the final par can run much more
quickly (achieving timing closure) this way, rather than making the tool
solve all the issues at once. Starting with a 'known-good' baseline can
really speed things up. Further, it is less susceptible to the impact of
small design changes. (The impact is felt when running par on the
appropriate block more than it is for the final par.)
This technique tends to produce larger designs, but the turnaround time
may be quicker.
>
> 2) Are the 8.2 service packs an improvment? I briefly tried pack2 a
> couple of weeks back, but it destroyed one of my projects so I couldn't
> load it into a non SP version on another PC. Obviously backwards
> compatibility is not high on Xilinx's lists.
I haven't upgraded from 8.1sp3 to 8.2 yet, so I can't say. There are
reasons I want to (the corrupted project file can be such a pain...), but
for compatibility reasons, I stay at 8.1.
>
> 3) Does anyone use Floorplanner? Are there any GOOD tutorials out
> there?
I have only used it a little bit; mainly, to get insight, or as a starting
point. I've been handplacing critical registers for better than 10 years,
and old habits die hard. (Especially when they work. It seems most of by
timing challenges have been datapath, and the tool seems to get the most
help by hand-placing things register by register. I have seen designs go
from almost never meeting timing, to easily meeting timing, by fixing the
locations of registers in the critical path. My experience has been: let
the tool work hard on what it is good at, and give it explicit directions on
what it is not good at.)
>
> Regards
> Marc
>
Food for thought,
Jason
Article: 110699Have you properly specified the input/output timing constraints? Most of the effort is spent defining internal timing constraints, but the I/O can be messed up--even if it meet the specifications you've given it, if they aren't correct! (The rate may be correct, but the offset may not.) What is the clock phase uncertainty for the incoming signals? What is the setup/hold time on the device the FPGA sends data to? Xilinx FPGAs (4k, V2, probably many others) let you adjust the delay (coarsely) on your inputs; you get to select drive strength and fast/slow on the outputs. Are the settings appropriate for your device's environment? Also, there are the physical board issues: how far from nominal are the voltages? How noise are the voltage and ground planes? Even at 50 MHz, you could create quite a bit of simultaneous switching noise if the chip isn't bypassed correctly, or .... Also, "doesn't work" can mean many things; you may want to insert some test circuity (Chipscope, or something similar, perhaps) to characterize the failure. If you identify "where" the failure occurs, "why" might not be far behind. And then it is often (but not always) just a quick jog to "fixed." Jason "Nico Coesel" <nico@puntnl.niks> wrote in message news:4537c0f0.1286740364@news.kpnplanet.nl... > "Roger" <hpsham@gmail.com> wrote: > >>A design is built to work at 50MHz, but the deisgn when tested works >>only at 48MHz. What >>should we do to make the design meet specific timing constraint .i.e. >>to make the design to make it work at 50 MHz? >>Thanks > > Are you sure all signals are covered by timing constraints? Don't > forget connections which connect IO cells to internal flipflops. These > should be constrained as well. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nl
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