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
Thomas Rudloff napisal(a): >Yup, its a problem with many tools. >If you have a date stamp beyond the actual date they refuse working. >Using the C tool "touch" is a convinient way to solve this problem. I just used TotalCommander. BTW TC rules ;--). >> >> Ok, I believe it but first I would like to know if I should cut down >> >> windows and reinstall OS or there is simpler solution. >> > >> >I would completely un-install Flexlm then use a registry cleaner >> >(I've used RegCleaner from http://www.vtoy.fi/jv16/shtml/software.shtml >> >before) to completely remove all traces of Flexlm from the >> >registry. Re-install Flexlm and see if it works. >> >> I got help from Altera support. Solution was simpler: I searched for >> all the files with date newer than 2003-01-21 and changed their >> dates. -- Pozdrowienia, Marcin E. Hamerla "Płoń, płoń, płoń parlamencie, spali Cię ogień na historii zakręcie."Article: 51801
Did somebody already work with XAPP 290 example (xapp290.zip)?? I tried to run modular design flow to use partial reconfiguration. But when I execute run_flow.bat file from XAPP290 example (CALCPR10 design) at once, it happens errors in UCF file (calctop.ucf). This erros are related when NGDBUILD command is executed. There are errors on the INST tags on the UCF file (INST DisplayLCD/Internal_GND issued errors on the NGBuild command) If somebody already worked with this example, I´d like ideas to continue to run modular design flow for partial reconfiguration. Regards Eduardo Wenzel BriăoArticle: 51802
"B. Joshua Rosen" <bjrosen@polybus.com> wrote in message news:<b0l35s$qehog$1@ID-78650.news.dfncis.de>... > On Tue, 21 Jan 2003 13:43:24 -0500, Roger wrote: > > > Which one is the "best"? > > > > What are the various advantages and disadvantages of each one? > > > > Thanks. > > > > Rog. > > Verilog is more consise and easier to read. Simulation speeds for > Verilog are much faster and in my experience there are lot fewer > synthesis problems with Verilog because the language is much simpler. Have to agree with that. I also much prefer Verilog but thats because I was in VLSI, ASICs where it dominates >>70% although now I am mostly in FPGAs and I am very biased. If there is one book you should buy, its the big blue "HDL Chip Design" book by Douglas Smith. It gives literally hundreds of examples of equiv VHDL & Verilog code and the logic gates that get synthed for it as well as lots of coding guidelines. Unfortunately it doesn't cover FPGAs, but that shouldn't stop you having it as a ref. See which code you prefer the look of. After that, there are zillions of VHDL and a few Verilog books. Some are even written for the FPGA market now. The rest is a little opinionated When FPGAs were really small it didn't matter since everyone used schematics. As they got bigger, VHDL found a space that Verilog vendors weren't interested in as FPGAs were hardly capable compared to ASICs. Now that top of the line FPGA projects routinely have 10 person+teams, they look alot like medium size ASIC projects, so alot of ASIC people are coming in with their tool flows which I think will be mostly Verilog. So if you are in eec,edu,gov work its likely to be VHDL no matter what. In ASICs and large FPGA projects it would be Verilog. In smaller or medium size FPGA projects, its a toss up, personal preferences. You will notice the traffic in the VHDL news groups being 2x Verilog. You may also notice that VHDL books vastly outnumber Verilog books by maybe 5 to 1. Most book stores barely stock Verilog books let alone PLI. Imagine if they mostly stocked ADA & very few C++ books. This might lead some to conclude that VHDL is far ahead of Verilog but it more reflects that VHDL is a much bigger language with more programming abstractions and is descended from ADA a committe programming language. It just requires much more effort to learn the whole, & I suspect is intimidating. It needs all that news traffic & books to help the newbies. I also believe it is prevalent because the professors that teach it are pushing a more general view of programming & architecture & systems which is fine. Verilog might seem uncouth in .edu. For a real biased view on this, follow John Cooleys web site & the infamous DAC Verilog v VHDL codeathon for an oddball 9bit counter. Almost all the Verilog coders got something working correctly in the alloted time, some were even Verilog freshmen. The VHDL people included some of their best experts mostly failed to complete. Basically they needed far more preparation time. It is commonly assumed that Verilog designs will be faster designs than VHDL designs, and alot of ASIC guys scorn VHDL completely. Even Cadence long term previous president hated that his company was forced to develop the same tools twice for a split market. Eventually Verilog became the ASIC default and almost all new original ASIC tools are created for Verilog alone. VHDL support can be added by Synopsys translation. Some say that Verilog is like C, it is also like Pascal in other ways, but mainly it was designed from the ground up as a HDL to simulate all the aspects of digital design & simulation. It also has several levels of modelling, both at the sub gate switch level, all the way to behavioural level. Most people only use the RTL style for synthesis, but since it predates synthesis it also has alot of baggage that few use. It has issues, it is often extended by C code by plugins to support access to the simulation internals using PLI which is another whole language. It also was very poor for signed no work, and general programming. VHDL on the other hand is a derivative of ADA, its big. To even write hello world, I mean a small simple counter example, you have to do alot of setup, and like in C++, you are creating prototypes (architectures) as well as implementation. Atleast 2x the typing. It is a much more powerful system language no doubt. Both languages were bitter rivals since the eighties having separate organisations, they are now both under the same roof accellera.org. Both languages are in constant state of improvement. Verilog is in process of acquiring significant new features from the C world to improve abstractions so that cosimulation & test benches can be easier to write. Both are borrowing a few feature the other has that should have been in 1st time around but we had to work around. Verilog gets signed nos, generates etc, better programming IO. For ASICs, the future could well go SuperLog a Verilog/C descendant. Maybe its time that accellera or someone created an RTL HDL that is a subset of Verilog/VHDL that reflects what people are actually using now & in near future, and drops all the excess baggage that doesn't get used. But instead, the C folks are in town pushing SystemC, HandelC, etc. Some other point, if your shop does contracts with so many clients as on on your website, you may well end up having some projects in either language, but I would steer clear of ever trying to mix them in any project. On the other hand mixed language tools like ModelSim will help.Article: 51803
Mu Young Lee <muyoung@umich.edu> wrote in message news:<Pine.SOL.4.44.0301171329430.16122-100000@zektor.gpcc.itd.umich.edu>... > Is there a company out there that makes anything close to what LeCroy > Research Systems used to make? Especially in nuclear and atomic physics CAMAC and NIM are still widely used. I guess that the manufacturers of CAMAC controllers like National Semiconductors can give you a list of CAMAC module manufacturers. There ist for example CAEN in italy that build CAMAC and NIM modules http://www.caen.it/nuclear/family.php?fam=cam Roentdek in germany has a CAMAC controller and a couple of time to digital converters: http://www.roentdek.de/ What would you do with an FPGA in a CAMAC crate? Kolja SulimmaArticle: 51804
If you are doing lots of arithmetic, such as with a DSP design, the much
stronger typing of VHDL makes it more appropriate. VHDL also is better
for structural instantiation of primitives, which is necessary for
floorplanning in the source code.
"B. Joshua Rosen" wrote:
> On Tue, 21 Jan 2003 13:43:24 -0500, Roger wrote:
>
> > Which one is the "best"?
> >
> > What are the various advantages and disadvantages of each one?
> >
> > Thanks.
> >
> > Rog.
>
> Verilog is more consise and easier to read. Simulation speeds for
> Verilog are much faster and in my experience there are lot fewer
> synthesis problems with Verilog because the language is much simpler.
--
--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: 51805
Depends on the design. If performance/density is an issue, it may involve
some floorplanning and possibly iterating through the synthesis to modify
the implementation for timing/layout. You usually also need to specify
timing constraints.
Matt wrote:
> I'm still curious about one thing. Do HW people have to muck around with
> anything after the verilog or vhdl is optimized?
--
--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: 51806richard.coster@4rf.com (Richard Coster) wrote in message news:<732c59cc.0301201509.8498de2@posting.google.com>... > I believe there is an issue with the stability of the clock on > power-up, as the DLL locks if the clock source is changed. However > after power-up the clock settles down and the DLL will lock if a reset > is applied. I have now provided an automatic reset from a counter and > this seems to fix the problem. I'm having a similar problem; the clock is stable enough but it's at the other end of 350mm of track. I'll try using external reset and see if it helps. By the way, the Spartan II DLL app note is no. 174, though it's almost identical to 132. The interesting configuration is figure 13; I guess STARTUP_WAIT won't work with that because it'd stop the SRL16 doing its job?Article: 51807
Hello,
I am using Xilinx Webpack (latest version 5.1 SP3) ; in my VHDL code, I would
like to use signal conditional assignment, as they are more elegant (and
implement more efficiently I heard).
Alas, the XST compiler does not seem to recognize them when they are part
of a case statement; it complains:
unexpected WHEN, expecting SEMICOLON
Yet I did not find any restriction in the VHDL syntax about this.
Is this normal?
Yours,
Frederic Bastenaire
PS: VHDL code sample:
case state is
when sample_r =>
if (count = 0) then
-- sample memory data, copy to to data_out
data_out(0) <= d0; -- same for d1...d7
state <= end_pulse_r;
else
count <= count-1;
end if;
when end_pulse_r =>
ram_oe <= '1'; flash_oe <= '1';
-- #### this is where XST complains:
count <= ram_highz_cycles-1 when (ram_operation = '1')
else flash_highz_cycles-1;
state <= end_r;
(...)
Article: 51808"Florin Franovici" <ffranovici@redlinecommunications.com> wrote in message news:<b0k4le$prajc$1@ID-95060.news.dfncis.de>... > Hello all, > > I want to know how do I add a switch to a ISE command in Project navigator, > without dos command window (if is possible). > > Any sugestions? > > 10x Hi, I am not sure I understand fully what you mean. Do you want to supply options to the Xilinx commands? You can right click on the icons on the process view (line Synthesize, Implement Design...) and select "Properties...", most options are there, no need to dig in the manuals to find the right syntax. Quite a nice program this navigator actually... Thanx Xilinx. FBArticle: 51809
Nial,
Yes, I am aware of the 2^25 clock rule (That's also part of PCI 2.2.)
before the first access, but FFs still have to be initialized by
something.
If I am correct, FFs can be initialized to their default value when
the FPGA is being configured, but to do that, doesn't the user have to
know what those values are going to be?
To me, resetting FFs by RST# seems easier and more reliable.
Also, if the user is dealing with 64-bit PCI, the FPGA has to be
configured before RST# gets deasserted because REQ64# needs to be
asserted during RST# assertion.
However, know that I think about it, Eric (Eric Crabill of
Xilinx) is probably right that the original poster didn't correctly
ground some ground pins now being used by PCI-X.
Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)
"Nial Stewart" <nial@spamno.nialstewart.co.uk> wrote in message news:<3e2b11be$0$29911$fa0fcedb@lovejoy.zen.co.uk>...
>
> Kevin, since PCI v2.2 the spec was changed (to allow larger programmable
> devices to be configured?). I've had a quick flick through v2.3 and
> can't find the exact details, but devices now have something like
> 2^25 clock cycles guaranteed before the first access.
>
> Having said that I'm not sure if it dictates a minimun time before
> reset is de-asserted so if you were using the rising edge of reset to reset
> state machines etc you could miss it if it was de-asserted before
> your device was configured.
>
> Nial.
>
> ------------------------------------------------
> Nial Stewart Developments Ltd
> FPGA and High Speed Digital Design
> www.nialstewartdevelopments.co.uk
Article: 51810Hi, For options not found in the property, please follow the instructions in the link below. http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=11088 Regards, Wei Frederic Bastenaire wrote: > "Florin Franovici" <ffranovici@redlinecommunications.com> wrote in message news:<b0k4le$prajc$1@ID-95060.news.dfncis.de>... > > Hello all, > > > > I want to know how do I add a switch to a ISE command in Project navigator, > > without dos command window (if is possible). > > > > Any sugestions? > > > > 10x > > Hi, > > I am not sure I understand fully what you mean. Do you want to supply options > to the Xilinx commands? You can right click on the icons on the process view > (line Synthesize, Implement Design...) and select "Properties...", most options > are there, no need to dig in the manuals to find the right syntax. Quite > a nice program this navigator actually... Thanx Xilinx. > > FBArticle: 51811
"Austin Franklin" <austin@da98rkroom.com> writes: >> > It's not arbitrary, it's entirely deterministic. That's the POINT! >> >> No, the point was that I should be able to take any arbitrary C code >> of my choosing, and use that book to determine what code the compiler >> will generate. > > Er, Eric, that IS what deterministic means. Same input always generates > same output. I seem to remember that Synopsys DC looked at the full source code to get a seed value for optimization runs, that is, also formatting and commenting (maybe even line-end convention) mattered, even though a parser would come up with the same result. So, here are two levels of "same input" if I indeed remember correctly. And of course, this does not matter if you use the term "compiler" exclusively for something that does not optimize. It might not give anything new to the rest of your discussion (which, frankly, I haven't followed thoroughly), but I thought I'd bring it up. Cheers, ColinArticle: 51812
In article <d977c973.0301220613.3ca49487@posting.google.com>, Frederic Bastenaire <fba@free.fr> wrote: >Hello, > >I am using Xilinx Webpack (latest version 5.1 SP3) ; in my VHDL code, I would >like to use signal conditional assignment, as they are more elegant (and >implement more efficiently I heard). >Alas, the XST compiler does not seem to recognize them when they are part >of a case statement; it complains: > > unexpected WHEN, expecting SEMICOLON > >Yet I did not find any restriction in the VHDL syntax about this. >Is this normal? Look up the difference between sequential statements and concurrent statements. Inside a process you may use only sequential statements. The when-else conditional assignment is a concurrent statement and may only be used in the architecture body. > >Yours, > >Frederic Bastenaire > >PS: VHDL code sample: > > case state is > when sample_r => > if (count = 0) then > -- sample memory data, copy to to data_out > data_out(0) <= d0; -- same for d1...d7 > state <= end_pulse_r; > else > count <= count-1; > end if; > when end_pulse_r => > ram_oe <= '1'; flash_oe <= '1'; > -- #### this is where XST complains: > count <= ram_highz_cycles-1 when (ram_operation = '1') > else flash_highz_cycles-1; > state <= end_r; > > (...) -- Caleb Hess hess@cs.indiana.eduArticle: 51813
I do have a case open with xilinx, and I have gone through all of the steps you mention below. I have taken steps to make sure both Vcco and Vccaux are within spec. I have also added separate decoupling on each power pin. The ground bounce is currently withing reasonable values, 60 mV peak-to-peak. I am suspect of the package, and just wanted to see if anyone else has similar problems with it. Unfortunately, the 500 does not come in a flip-chip package, and it would not be cost effective to move to a larger part (although this may be the end result). Thanks for the suggestions. Anyone else out there successfully use this package with a large percentage of the I/O utilized? John Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3E2DA4A2.B0A5731F@xilinx.com>... > John, > > I suggest you open a case with the hotline. Yes, if you have really > terrible ground bounce, then you will exceed the input jitter tolerance > specification, and the DCM will not lock. > > App note 623 on powering is helpful, and to really see what is going on, > you need to pin out a IO driven to a logic '0' to see just how bad the > ground bounce is inside the die. > > http://support.xilinx.com/xapp/xapp623.pdf > > fg are wire bond, and are more sensitive to strong currents (more > inductance in the ground returns) than the flip chip packages you > mention. They require better bypassing techniques to get the same level > of jitter performance as a flip chip package. > > All design (SSO tables, DCM operation, system jitter, etc) assumes that > the ground bounce stays below +/- 100 mV peak to peak for proper > operation. > > There is also a requirement on Vccaux, which powers the DCM. > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=13756 > > (tech answer 13756) > > There may be other issues as well that our hotline is well trained in, and > can quickly get you up and running, > > Austin > >Article: 51814
As of this week, you now have a third option: Confluence. One nice feature of Confluence, especially for FPGA design, is its enforcement of synchronous RTL. With Confluence, it is impossible to construct gated clocks, level sensitive latches, combinatorial loops, or other FPGA no-nos. Further more,the language allows you to clock, enable, and reset entire subsystems without having to drag these signals down to every register. Confluence is not a hardware "description" language, but is rather a "construction" language. One of VHDL's best features is its generate statement, which allows a designer to create an algorithm to build a configurable logic structure. In comparison, a Confluence program IS a generate statement. It does not describe the behavior of a design, but rather is an algorithm to construct the design's architecture. This concept leads to smaller, easier to manage, source code. I agree with other posts on the thread that suggest Verilog is simpler than VHDL. If you base a language's simplicity on the size of its grammar, then Confluence is 3 times simpler than Verilog. Confluence compiles into Verilog and Vhdl. It also generates C, which is useful if you want to integrate with software or run your own simulation environment. For more info: http://www.launchbird.com/ Regards, Tom -- Tom Hawkins tom1@launchbird.com Launchbird Design Systems, Inc. http://www.launchbird.com/Article: 51815
John, Did you measure the ground difference as suggested? Is that where you get the 60 mV? Is it 60 mV peak, or peak to peak, or RMS? How much ripple is there on the power supplies (peak to peak)? What are the voltages of each of the power supplies? (we have seen Vccint as low as 1.3 volts and customers were not aware it had drooped so far -- inadequate power distribution system) How much jitter is on the incoming clock? Peak to peak? How measured? (LeCroy scope best way, plain scope can be 30% less jitter than actually there as they can't sample enough clocks to measure, and delaying the trigger to "catch" jitter is a really bad way to see jitter!) What you suggest implies that something else is going on, and has nothing to do with the package. Cross talk on the pcb from other signals (adds jitter)? Is the IO switching synchronous with the clock to the DCM, or asynchronous? How much of the fabric or core is being used? What is the power being dissipated? How hot is the case? Could be something else is going on here.... Rise time of clock input? It the rise time is 5 ns (for eample - from a real case), and the bounce is 100 mV peak to peak, that will cause an additional dV/dt change at the input slicer, and jitter of 150 ps P-P (0 to 3.3V is 3.3V swing, .1V is 3% of the total, 3% of 5000 ps = 150 ps). If the jitter is already 350 ps, the extra 150 ps pushes it close to the limit..... Please email me the case number at austin@xilinx.com and the answers to the above so I can see the case notes and help out. Thanks, Austin John M wrote: > I do have a case open with xilinx, and I have gone through all of the > steps you mention below. I have taken steps to make sure both Vcco > and Vccaux are within spec. I have also added separate decoupling on > each power pin. The ground bounce is currently withing reasonable > values, 60 mV peak-to-peak. I am suspect of the package, and just > wanted to see if anyone else has similar problems with it. > Unfortunately, the 500 does not come in a flip-chip package, and it > would not be cost effective to move to a larger part (although this > may be the end result). Thanks for the suggestions. Anyone else out > there successfully use this package with a large percentage of the I/O > utilized? > > John > > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3E2DA4A2.B0A5731F@xilinx.com>... > > John, > > > > I suggest you open a case with the hotline. Yes, if you have really > > terrible ground bounce, then you will exceed the input jitter tolerance > > specification, and the DCM will not lock. > > > > App note 623 on powering is helpful, and to really see what is going on, > > you need to pin out a IO driven to a logic '0' to see just how bad the > > ground bounce is inside the die. > > > > http://support.xilinx.com/xapp/xapp623.pdf > > > > fg are wire bond, and are more sensitive to strong currents (more > > inductance in the ground returns) than the flip chip packages you > > mention. They require better bypassing techniques to get the same level > > of jitter performance as a flip chip package. > > > > All design (SSO tables, DCM operation, system jitter, etc) assumes that > > the ground bounce stays below +/- 100 mV peak to peak for proper > > operation. > > > > There is also a requirement on Vccaux, which powers the DCM. > > > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=13756 > > > > (tech answer 13756) > > > > There may be other issues as well that our hotline is well trained in, and > > can quickly get you up and running, > > > > Austin > > > >Article: 51816
On 22 Jan 2003 03:57:55 -0800, kolja@bnl.gov (Kolja Sulimma) wrote: >Mu Young Lee <muyoung@umich.edu> wrote in message news:<Pine.SOL.4.44.0301171329430.16122-100000@zektor.gpcc.itd.umich.edu>... >> Is there a company out there that makes anything close to what LeCroy >> Research Systems used to make? > >Especially in nuclear and atomic physics CAMAC and NIM are still >widely used. I guess that the manufacturers of CAMAC controllers like >National Semiconductors can give you a list of CAMAC module >manufacturers. What is this part? I can't find any reference to CAMAC on National's site. >What would you do with an FPGA in a CAMAC crate? > >Kolja Sulimma I've built three CAMAC modules here at TRIUMF using Altera FPGAs - they replace a heluvalot of logic chips. One of the modules is a scanning 32 channel ADC, to replace a Lecroy 2232A - all the logic and channel registers that fills most of Lecroy's board is in one Altera part. -- Peter Bennett VE7CEI GPS and NMEA info and programs: http://vancouver-webpages.com/peter/index.html Newsgroup new user info: http://vancouver-webpages.com/nnqArticle: 51817
gospod88@hotmail.com (Richard) wrote in message news:<f7779f31.0301210415.57fe1c85@posting.google.com>... > Dennis McCrohan <mccrohan@xilinx.com> wrote in message news:<3E2C70A3.929A348D@xilinx.com>... > Not an option I'm afraid. I'm using v4.2. Duh. The option *is* in v4.2. Silly me. Regards, RichardArticle: 51818
In article <25c81abf.0301220357.41eb4cea@posting.google.com>, kolja@bnl.gov (Kolja Sulimma) wrote: > Mu Young Lee <muyoung@umich.edu> wrote in message news:<Pine.SOL.4.44.0301171329430.16122-100000@zektor.gpcc.itd.umich.edu>... > > Is there a company out there that makes anything close to what LeCroy > > Research Systems used to make? > > Especially in nuclear and atomic physics CAMAC and NIM are still > widely used. I guess that the manufacturers of CAMAC controllers like > National Semiconductors can give you a list of CAMAC module > manufacturers. > Say what? Do you have a part number for this National Semi CAMAC controller?Article: 51819
Hal Murray wrote: > >It sounds like a better way to improve C or Fortran might be to use an > >fpga as a coprocessoer that implements common math routines or common > >communication protocols and let the user treat that as fixed hardware. > > Most of the number crunching in scientific computing is floating > point, so appropriate "common math routines" aren't that common. They actually are. If there were something to speed up sparse matrix solves it would speed up a major portion of lots of programs. BLAS 1, 2, and 3 are also used in most applications. Just a vector processor could help a lot. > Communication is hard. It takes wires and packaging. You might > be able to use FPGAs to help, but it won't be anything as simple > as adding in a PCI card with an FPGA on it. Absolutely. PCI is much too slow. There already exists hw for communication but there is a need for something between that hardware and memory. What might work is a board with a cpu connected to memory through a shared memory bus. This bus is also connected to a set of fpgas which in turn is connected to the communication hw. The fpga could be used for specialized communication protocols or a math coprocessor. As fpgas get bigger I can't believe they won't end up on processor boards.Article: 51820
John,
Try bringing the clock back out of a package pin and look at the jitter on the internal clock. I had
a case a couple years ago where single ended outputs switching on the same bank as the clock input
caused the clock input threshold to modulate, adding jitter to the clock. There was enough jitter
added that the DLL was coming unlocked. While that was in a Virtex part, the same effect can be seen
on a Spartan part. If you have the spare pins, put a virtual ground on either side of the clock pin
(drive a low out, and tie the pin to hard ground). Check to make sure your clock trace isn't picking
up crosstalk from other traces on the board (that also adds jitter). If possible, move the I/O off
the bank with the clock input altogether. You might also try reducing the drive strength and slew
rate of those outputs.
John M wrote:
> I do have a case open with xilinx, and I have gone through all of the
> steps you mention below. I have taken steps to make sure both Vcco
> and Vccaux are within spec. I have also added separate decoupling on
> each power pin. The ground bounce is currently withing reasonable
> values, 60 mV peak-to-peak. I am suspect of the package, and just
> wanted to see if anyone else has similar problems with it.
> Unfortunately, the 500 does not come in a flip-chip package, and it
> would not be cost effective to move to a larger part (although this
> may be the end result). Thanks for the suggestions. Anyone else out
> there successfully use this package with a large percentage of the I/O
> utilized?
>
> John
--
--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: 51821I'm trying to use a Spartan 2 device with more than 4 external clocks and am running into the following error message from the Xilinx tools: ------------ ERROR:MapLib:94 - The design contains more than 4 GCLKIOBs. The maximum number of GCLKIOBs in this device is 4. Please correct the design. Errors found during the mapping phase. Output files will not be written. ------------ I'm using the Xilinx WebPACK tools (I believe version 4.1). The code is Verilog using the Xilinx XST synthesizer. The Spartan part is on a OEM board, and some of the input clocks are not on dedicated Xilinx clock pins. In addition, the board designers put some simple i/o signals on 2 of the dedicated high speed clock input pins. Yuck. I've looked at the USELOWSKEWLINES directive, but it seems to be aimed at the PAR phase of the chip "compilation", not the MAP phase where the error message appears. 1) Any suggestions? 2) Does anyone know of a good document that describes the ins & outs of actually using more than 4 clocks with the Spartan? Thanks! John P.Article: 51822
John, There are only 4 BUFG resources, so did you try to use more than 4? If so, remove BUFGs till you are back to only 4. Note: the BUFGDLL uses one. As well, there are only 4 IBUFG resources (what your error message is complaining about!). Use BUF and IBUF instead. Austin John Providenza wrote: > I'm trying to use a Spartan 2 device with more than 4 external > clocks and am running into the following error message from the > Xilinx tools: > > ------------ > ERROR:MapLib:94 - The design contains more than 4 GCLKIOBs. The maximum number > of GCLKIOBs in this device is 4. Please correct the design. > Errors found during the mapping phase. Output files will not be written. > ------------ > > I'm using the Xilinx WebPACK tools (I believe version 4.1). The code > is Verilog using the Xilinx XST synthesizer. > > The Spartan part is on a OEM board, and some of the input clocks > are not on dedicated Xilinx clock pins. In addition, the board designers > put some simple i/o signals on 2 of the dedicated high speed clock input > pins. Yuck. > > I've looked at the USELOWSKEWLINES directive, but it seems to be aimed > at the PAR phase of the chip "compilation", not the MAP phase where the > error message appears. > > 1) Any suggestions? > 2) Does anyone know of a good document that describes the ins & outs of > actually using more than 4 clocks with the Spartan? > > Thanks! > > John P.Article: 51823
On Wed, 22 Jan 2003 02:57:47 -0500, Hal Murray wrote: > Thanks. > >>* VHDL is much more strongly typed: Verilog has only some basic types >>and allows automatic conversion of vectors of mismatching widths. In >>VHDL you often need a conversion function to assign a value from one >>signal to another. It is a true PITA, but in a large design can save you >>weeks of searching for odd errors caused by automatic conversion of >>widths. In addition, in VHDL you can create new types of signals as >>needed (very common: create an enumerated type for all states in each >>FSM in the design or each control-signal group). Verilog will only allow >>you to assign names to numeric constants. > > I consider the wires/vectors sort of "type" system to be a major fuckup. > Note that's all you get with most schematic packages too. > > It seems really stupid and error prone to be stuffing things like > control signals into the back end of a vector so you can avoid a major > amount of clutter as a bus gets passed around. > > > >>* The other side of VHDL's strong typing is that usually VHDL >>simulations are slower. > > Could you please say more? I think of strong typing as a compile time > issue. The final circuit is going to be just wires and gates. Why does > it take longer to simulate if they came from one language or another? I've did some benchmarking a few years ago comparing the same code in both VHDL and Verilog on the same simulator which was ModelSim. I wrote a test case in VHDL and then translated it to Verilog so when I mean the same code I mean line for line equivalent code The Verilog code ran 3 times faster than the VHDL code. I think the reason for the difference is that VHDL does a lot of run time checking that in Verilog is done only at compile time. I think it's also a lot harder for the compiler writers to optimize VHDL code because the language is so large and so general. Verilog is a very simple language so there is a lot less for compiler writers to worry about and it's easier for them to do a good job.Article: 51824
David Rogoff wrote: > Andrew Rogers <andrew@rogerstech.co.uk> writes: > > >>I discovered the problem when I ran XST on Linux using Wine. First I >>set the XILINX variable > > > Why don't you run the Linux version? Is the Linux version free? If so, how can I obtain it? I am currently using the free WebPack ISE for Windows. Thanks Andrew Rogers
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