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
To paraphrase Winston Churchill: Never have so many spent so much effort on so little... Peter Alfke On Dec 18, 9:13 am, "Matthew Hicks" <mdhic...@uiuc.edu> wrote: > Sorry, ignore my last post, I looked back and saw that you refering to an > actual signal not a catch all, which will also work, if you test the value > in the always block, but will create a level sensitive instead of edge > triggered (combinatiorial vs sequential) circuit. Here are my corrections > to the OP's code and the reasons behind them. > > //divide oscillator clock by 10 (xc9536) > module clk_div10 (in,out) > input in; > output out; > // Set initial value for cnt, 0 to 4 = 5 ticks, period of slow signal = 10 > ticks(periods of fast signal > reg[0..3] cnt = 4; > // Changed to edge triggered > always @ (posedge in) begin > // Subtraction method synthesizes better than addition > cnt=cnt-1; > if (cnt == 0) begin > cnt = 4; > // Logic operations better than mathematical ones, although the > synthesizer would probably optomize it for you > out = ~out; > end > end > endmodule > > "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote in messagenews:0dphh.25718$qD1.247465@wagner.videotron.net... > > > 222 wrote: > >>>> Correction, this is wrong > >>>> out =out +1; > >>>> Put this in instead > >>>> out =!out > > >>> Since you toggle "out" every time your counter reaches 10, you are > >>> actually creating a waveform with twice the period you intended. Also, > > >> Does "always @(x)" work on _any_ change, i.e. it should react twice > >> on each clock, which would make it right, or does it default to positive > >> edge, > >> which would make it twice the period? > > > As I said, I have only poked into verilog with a pole... I overlooked that > > little detail and yes, this does appear to be equivalent to clk'event in > > VHDL. > > > In this case, try synthesizing your code with free tools from most FPGA > > vendors and I think you will get an error saying that you have to pick an > > edge - the FFs in all FPGAs I know of do not work with both edges, even > > the DDR IOBs are implemented with two register banks clocked on opposite > > edges. > > > It might work the way you intended in simulation but I am almost 100% > > certain that it will fail in synthesis. > > >>> because counting starts at 0 and you compare with 10, there are actually > >>> 11 counts between toggles instead of 10. > > >> Correct, I need to count to 9.Article: 113626
Hi, I'm working on a design with V4 FX12 and gigabit rgmii PHY. To me it seemed obvious to use plb_temac and hard_temac (both come with EDK). A "small" implementation of these cores (DMA and checksum offload disabled) uses about 30% of the FX12 area. For my design this is quite a lot, and I'd prefer to reduce the resource usage. At the moment, 100mbit support would be sufficient, as long as the board and PHY stay the same. I did not see any options to disable 10 or 1000 mbit support in the cores, so I suppose they don't let me save anything here. Are there leaner alternatives to plb_temac that might work for me? Regards, MarcArticle: 113627
We just purchased the full version of Quartus II (version 6.0) because
it has the ability to perform incremental recompiles after small
changes, saving on compile time. I understand the design flow as
described in the manual, but so far I've been unable to get
incremental recompiles to work right. (I'm using a command line
interface rather than the GUI, in case that makes a difference.)
Running quartus_map, I get this message.
Info: Partition "s_led" is synthesized because no netlist is
available for reuse
That makes sense the first time around, but presumably a
post-synthesis or post-fit netlist would be saved and subsequent
compiles could use it.
Running quartus_cdb --merge=on, I get this:
Warning: Previously generated Fitter netlist for partition
"s_led" does not exist -- trying to use previously generated
Synthesis netlist
This might indicate a modicum of success, i.e. that at least the
post-synthesis netlist *might* be used, but I want to use the post-fit
netlist for more time savings.
Running quartus_fit, I get this:
Warning: Ignored partition netlist type assignment changes
Info: Partition "s_led" is using previous netlist type "Source
File" and not current setting of "Post-Fit"
I suspect that this warning message is tied in with the fact that no
post-fit netlist appears to be being saved for next time.
Does anyone know what might be going on?
Many thanks...
David
--
If only 2^(7/12) were equal to 3/2, music would sound a lot better.
Article: 113628jetmarc@hotmail.com wrote: > Hi, > > I'm working on a design with V4 FX12 and gigabit rgmii PHY. > >[snip] > > Are there leaner alternatives to plb_temac that might work for me? Have a look at xapp807: http://www.xilinx.com/bvdocs/appnotes/xapp807.pdf Uses only a few slices, but you can't use any PLB or OPB components. But if all you need is Ethernet and nothing else from the PowerPC, this is probably thew way. -- My email address is only valid until the end of the month. Go figure what the address is going to be after that...Article: 113629
Brian, OK, now I see it. Spartan 3/3E/3A dropped HSTL IV, which is a 48 mA drive strength standard. III is 24 mA. That means the area required is cut in half, so the C could be half that of the Virtex series IOB's (that have HSTL IV). I wonder how many people need IV? Austin Austin wrote: > Brian, > > That would make sense (dropping a low voltage strong standard reduces > pin C). Dropping DCI would hardly save anything except area, however. > > I will take it that you did not file a webcase. With a webcase number, > it could be tracked and solved, or escalated (and solved). Or even > reported to myself or Peter (as some have done). > > Now that Spartan has "grown up", they are making their own decisions as > to what to spend their silicon on, so I have lost track of some of their > features. I should not have replied for them, as I really don't know > what they are doing (without asking). > > Austin > > > Brian Davis wrote: > >> Austin wrote: >> >>> From what I know about the design, the only way to reduce >>> the C is to leave out the LVDS output driver (0.5pF less), or >>> make the IO drive strength smaller. <snip> >>> It may be that 3E drops some of these (I will check). >>> >> >> The simplified S3E I/O drops DCI and some of the higher >> drive standards vs. S3, and adds DIFF_TERM support. >> >> >>>> Which makes no distinction between input only pins, I/O pins, >>>> global clock input pins, left/right side clock pins, dual mode >>>> config pins, Vref pins, dedicated config pins, etc. >>> >>> The Vref pins do not have any more load, until they are programmed >>> to be a Vref, so we do not specify their C as a Vref <snip> >>> >>> Sometimes a missing specification is just something not needed. >>> >> >> Some inputs, such as global clocks or the MGT clock inputs of this >> thread, are likely to differ from general I/O, but are not documented >> as such in that single datasheet spec, nor in the IBIS files. >> >> >>>> Perhaps I should file a WebCase asking Xilinx to update >>>> their datasheet to match their IBIS files :) >>> >>> But, if you filed it as a case, you should have received a reply as to >>> why the specification did not require an update. Case #? >>> >> >> If the "perhaps" and the smiley didn't give it away, >> that was intended as a humorous observation for those >> of us who have filed WebCases. >> >> Brian >>Article: 113630
Antti - Have you checked to see if the IDELAY taps have reasonable delay operations? The original post by Lecroy7200 said: "I see no problems using the IDELAY when I use the RF generator for the clock source. In this case I am running the input clock at 200MHz. However when I use the 50MHz clock and multiply it up to 200MHz with a DCM, the IDELAY does some strange things. I have a MICTOR on the board that I can use to look at some of the signals. Looking at the CLKFX output from the DCM, it appears normal and is running at 200MHz. I see both the DCM and IDELAYCRTL readys. What is strange is that when I program in a delayline, rather than seeing 75ps of delay, I see about 200ps per tap." Maybe Austin or Peter from Xilinx can comment on this? John Providenza Antti Lukats wrote: > "johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag > news:1166289684.160124.11030@l12g2000cwl.googlegroups.com... > > Has anyone else seen the problem that lecroy7200@chek.com talks about > > when using a DCM to multiply an input clock to create the 200MHz > > input clock to the IDELAYCTRL block? > > > > My current design is planning to use a DCM to convert a 14.318MHz clock > > to a 200.4 MHz for the IDELAYCTRL clock. I don't want to fight > > problems > > with this if it is doomed to failure. > > > > Any suggestions on DCM + IDELAYCTRL ? > > > > Thanks! > > > > John Providenza > > > hm > I am testing with 2 different DDR2 designs, > using either 100 or 50 mhz input clock > > the 200mhz for idelayctrl is derived from second DCM > first dcm FX is used to get internal 200mhz > > both designs seem to work somewhat, there are some problems > but those are more likely fpga timing or board layout related. > > in any case fx=200 from 50mhz input does work, eg memory tests > on the DDR2 memory do pass all. > > AnttiArticle: 113631
Hi, I don't exactly know what's going on for you, but I can share my experience with the quartus webpack, where I could perform kind of incremental compiles. The way to do this is to back-annotate the design in plaintext files, and ask quartus to reuse the files. You can get the mapping, place, and route back annotation via: quartus_cdb design --vqm=design.vqm quartus_cdb design --back_annotate=lab (writes place in the .qsf) quartus_cdb design --back_annotate=routing (writes routing info in .rcf) The vqm is automatically taken into account. You reduce (I think) quartus compile time with: set_global_assignment -name TRUE_WYSIWYG_FLOW ON (in the .qsf) Routing back-annotation should add lines of its own in the qsf asking quartus to re-use routing info. I think that quartus will re-do the mapping on design change, but will take into account whatever place/route information still applies. I've only tried the above on very small design, where it seems to work, but never on full-fledged designs... If you give this a spin, i'd be interested in the results. JBArticle: 113632
These is a reccurring theme - I should use edge triggered. Can someone explain why I should use "edge triggered" as we have established that "state triggered" will synthesise? tnx.Article: 113633
John, When we characterized the DCM DFS output for the IDELAY, we did not see any ill effects: the jitter from the CLKFX hardly affected the IDELAY at all, and as long as the frequency was close to 200 MHz (+/- 10 MHz) everything was just fine. So, I am unsure why things are behaving the way they are reported. Do you have a case open? Do you have a case number? Austin johnp wrote: > Antti - > > Have you checked to see if the IDELAY taps have reasonable delay > operations? The original post by Lecroy7200 said: > > "I see no problems > using the IDELAY when I use the RF generator for the clock source. In > this case I am running the input clock at 200MHz. However when I use > the 50MHz clock and multiply it up to 200MHz with a DCM, the IDELAY > does some strange things. I have a MICTOR on the board that I can use > to look at some of the signals. Looking at the CLKFX output from the > DCM, it appears normal and is running at 200MHz. I see both the DCM > and IDELAYCRTL readys. What is strange is that when I program in a > delayline, rather than seeing 75ps of delay, I see about 200ps per > tap." > > Maybe Austin or Peter from Xilinx can comment on this? > > John Providenza > > > Antti Lukats wrote: >> "johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag >> news:1166289684.160124.11030@l12g2000cwl.googlegroups.com... >>> Has anyone else seen the problem that lecroy7200@chek.com talks about >>> when using a DCM to multiply an input clock to create the 200MHz >>> input clock to the IDELAYCTRL block? >>> >>> My current design is planning to use a DCM to convert a 14.318MHz clock >>> to a 200.4 MHz for the IDELAYCTRL clock. I don't want to fight >>> problems >>> with this if it is doomed to failure. >>> >>> Any suggestions on DCM + IDELAYCTRL ? >>> >>> Thanks! >>> >>> John Providenza >>> >> hm >> I am testing with 2 different DDR2 designs, >> using either 100 or 50 mhz input clock >> >> the 200mhz for idelayctrl is derived from second DCM >> first dcm FX is used to get internal 200mhz >> >> both designs seem to work somewhat, there are some problems >> but those are more likely fpga timing or board layout related. >> >> in any case fx=200 from 50mhz input does work, eg memory tests >> on the DDR2 memory do pass all. >> >> Antti >Article: 113634
On 2006-12-18, jetmarc@hotmail.com <jetmarc@hotmail.com> wrote: > > To me it seemed obvious to use plb_temac and hard_temac (both come with > EDK). A "small" implementation of these cores (DMA and checksum > offload disabled) uses about 30% of the FX12 area. plb_temac has a lot of configuration options that drastically affect the amount of resources required. If you can use fifo mode (instead of DMA mode) you will cut it in about half. Also keep in mind that area usage is pretty meaningless until you fill the part. The tools will spread out the logic if the FPGA is sparesely utilized. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 113635
Austin - I have not yet seen a problem , I'm just concerned that Lecroy7200 says he saw problems trying this type of DCM+IDELAYCTRL configuration. I don't want to waste time on a known problem if it *really* exists. John P Austin Lesea wrote: > John, > > When we characterized the DCM DFS output for the IDELAY, we did not see > any ill effects: the jitter from the CLKFX hardly affected the IDELAY > at all, and as long as the frequency was close to 200 MHz (+/- 10 MHz) > everything was just fine. > > So, I am unsure why things are behaving the way they are reported. > > Do you have a case open? Do you have a case number? > > Austin > > > johnp wrote: > > Antti - > > > > Have you checked to see if the IDELAY taps have reasonable delay > > operations? The original post by Lecroy7200 said: > > > > "I see no problems > > using the IDELAY when I use the RF generator for the clock source. In > > this case I am running the input clock at 200MHz. However when I use > > the 50MHz clock and multiply it up to 200MHz with a DCM, the IDELAY > > does some strange things. I have a MICTOR on the board that I can use > > to look at some of the signals. Looking at the CLKFX output from the > > DCM, it appears normal and is running at 200MHz. I see both the DCM > > and IDELAYCRTL readys. What is strange is that when I program in a > > delayline, rather than seeing 75ps of delay, I see about 200ps per > > tap." > > > > Maybe Austin or Peter from Xilinx can comment on this? > > > > John Providenza > > > > > > Antti Lukats wrote: > >> "johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag > >> news:1166289684.160124.11030@l12g2000cwl.googlegroups.com... > >>> Has anyone else seen the problem that lecroy7200@chek.com talks about > >>> when using a DCM to multiply an input clock to create the 200MHz > >>> input clock to the IDELAYCTRL block? > >>> > >>> My current design is planning to use a DCM to convert a 14.318MHz clock > >>> to a 200.4 MHz for the IDELAYCTRL clock. I don't want to fight > >>> problems > >>> with this if it is doomed to failure. > >>> > >>> Any suggestions on DCM + IDELAYCTRL ? > >>> > >>> Thanks! > >>> > >>> John Providenza > >>> > >> hm > >> I am testing with 2 different DDR2 designs, > >> using either 100 or 50 mhz input clock > >> > >> the 200mhz for idelayctrl is derived from second DCM > >> first dcm FX is used to get internal 200mhz > >> > >> both designs seem to work somewhat, there are some problems > >> but those are more likely fpga timing or board layout related. > >> > >> in any case fx=200 from 50mhz input does work, eg memory tests > >> on the DDR2 memory do pass all. > >> > >> Antti > >Article: 113636
222 wrote: > These is a reccurring theme - I should use edge triggered. > Can someone explain why I should use "edge triggered" > as we have established that "state triggered" will > synthesise? There are many things that will synthesize that you really don't want to use. If it makes a transparent latch out of CLB logic, you might not. I don't know what it would do with a FF triggered on both edges. -- glenArticle: 113637
John, OK, I hear you. I have no idea what he was complaining about, that is why I did not post anything. I have heard at various times things about the software concerning IDELAY (wrong bits set, etc. back with 7.1i) but that is all fixed by subsequent service packs, and is easy to find on the web page by searching for IDELAY. http://www.xilinx.com/support/library.htm There are lots of answers, that give tips on usage, how many clocks to wait, simulation of the IDELAY, etc. AustinArticle: 113638
Al wrote: > AMONTEC wrote: >> Al wrote: >> >>> Hi guys, >>> I have to produce a PCB with a couple of FPGA on it and I was >>> wondering if the solder mask right under the FPGA would prevent a >>> good heat dissipation (provided that we will put the thermal paste >>> underneath). Some of our designers suggested that the gain you have >>> in heat dissipation you will loose it in short-circuit problems on >>> the mounting, through the via underneath which are much more of a pain. >>> Could you give me any suggestion? >>> >>> Thanks a lot >>> >>> Al >>> >> >> For BGA or TQFP ? >> I think CERN is working on big BGA ;-) >> > > Well, it's a Cern official experiment, but it's not going on any beams. > It's for space application (AMS-02). > Anyway I'm talking about PQFP 208 (Actel A54SX072A). > > Al > The heat dissipation loss will be pretty minimal - my SWAG is a thermal resistance of less (probably much less) than 4C/W but it depends on the material of course. Are you using LPI mask? I know a couple of people I could ask for the actual thermal specs - I'll see if I can hook up with them in the next few days. Cheers PeteSArticle: 113639
Peter Alfke wrote: > To paraphrase Winston Churchill: > Never have so many spent so much effort on so little... > Peter Alfke Snort!!! PeteS > > On Dec 18, 9:13 am, "Matthew Hicks" <mdhic...@uiuc.edu> wrote: >> Sorry, ignore my last post, I looked back and saw that you refering to an >> actual signal not a catch all, which will also work, if you test the value >> in the always block, but will create a level sensitive instead of edge >> triggered (combinatiorial vs sequential) circuit. Here are my corrections >> to the OP's code and the reasons behind them. >> >> //divide oscillator clock by 10 (xc9536) >> module clk_div10 (in,out) >> input in; >> output out; >> // Set initial value for cnt, 0 to 4 = 5 ticks, period of slow signal = 10 >> ticks(periods of fast signal >> reg[0..3] cnt = 4; >> // Changed to edge triggered >> always @ (posedge in) begin >> // Subtraction method synthesizes better than addition >> cnt=cnt-1; >> if (cnt == 0) begin >> cnt = 4; >> // Logic operations better than mathematical ones, although the >> synthesizer would probably optomize it for you >> out = ~out; >> end >> end >> endmodule >> >> "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote in messagenews:0dphh.25718$qD1.247465@wagner.videotron.net... >> >>> 222 wrote: >>>>>> Correction, this is wrong >>>>>> out =out +1; >>>>>> Put this in instead >>>>>> out =!out >>>>> Since you toggle "out" every time your counter reaches 10, you are >>>>> actually creating a waveform with twice the period you intended. Also, >>>> Does "always @(x)" work on _any_ change, i.e. it should react twice >>>> on each clock, which would make it right, or does it default to positive >>>> edge, >>>> which would make it twice the period? >>> As I said, I have only poked into verilog with a pole... I overlooked that >>> little detail and yes, this does appear to be equivalent to clk'event in >>> VHDL. >>> In this case, try synthesizing your code with free tools from most FPGA >>> vendors and I think you will get an error saying that you have to pick an >>> edge - the FFs in all FPGAs I know of do not work with both edges, even >>> the DDR IOBs are implemented with two register banks clocked on opposite >>> edges. >>> It might work the way you intended in simulation but I am almost 100% >>> certain that it will fail in synthesis. >>>>> because counting starts at 0 and you compare with 10, there are actually >>>>> 11 counts between toggles instead of 10. >>>> Correct, I need to count to 9. >Article: 113640
PeteS wrote: > Al wrote: >> AMONTEC wrote: >>> Al wrote: >>> >>>> Hi guys, >>>> I have to produce a PCB with a couple of FPGA on it and I was >>>> wondering if the solder mask right under the FPGA would prevent a >>>> good heat dissipation (provided that we will put the thermal paste >>>> underneath). Some of our designers suggested that the gain you have >>>> in heat dissipation you will loose it in short-circuit problems on >>>> the mounting, through the via underneath which are much more of a pain. >>>> Could you give me any suggestion? >>>> >>>> Thanks a lot >>>> >>>> Al >>>> >>> >>> For BGA or TQFP ? >>> I think CERN is working on big BGA ;-) >>> >> >> Well, it's a Cern official experiment, but it's not going on any >> beams. It's for space application (AMS-02). >> Anyway I'm talking about PQFP 208 (Actel A54SX072A). >> >> Al >> > > The heat dissipation loss will be pretty minimal - my SWAG is a thermal > resistance of less (probably much less) than 4C/W but it depends on the > material of course. Are you using LPI mask? > > I know a couple of people I could ask for the actual thermal specs - > I'll see if I can hook up with them in the next few days. > > Cheers > > PeteS Isn't the thermal resistance of air (or vacuum, perhaps, for the CERN folks) that would be between the package and the board be greater than when filling the gap with solder mask? There is a specific, designed gap between the PQFP package and the pins' mounting plane. Any solder mask would help to fill that gap but there will still be a thermal gap. Only if there's a desire to fill the gap with a thermally conductive material should there be a concern about reduced thermal conductivity from solder mask. Perhaps black soldermask would work well for radiated heat transfer?Article: 113641
John_H <newsgroup@johnhandwork.com> wrote: (snip on thermal conductivity of solder mask for PQFP packaging) > Isn't the thermal resistance of air (or vacuum, perhaps, for the CERN > folks) that would be between the package and the board be greater than > when filling the gap with solder mask? There is a specific, designed > gap between the PQFP package and the pins' mounting plane. Any solder > mask would help to fill that gap but there will still be a thermal gap. > Only if there's a desire to fill the gap with a thermally conductive > material should there be a concern about reduced thermal conductivity > from solder mask. Perhaps black soldermask would work well for radiated > heat transfer? PC boards don't have that much conductivity, either. Maybe a big metal pad would help, but that doesn't help get it out. How about a BeO solder mask? -- glenArticle: 113642
Also take a look at XAPP443. It uses the embedded TEMAC block and microblaze in a tri-mode configuration. It should provide enough information to get started. The TEMAC block supports gigabit rgmii, but this will take some additional logic that may be required for your main design (and it sounds like your external PHY is already laid out on the PCB). "Sean Durkin" <news_dec06@durkin.de> wrote in message news:4uo68tF18qqroU1@mid.individual.net... > jetmarc@hotmail.com wrote: >> Hi, >> >> I'm working on a design with V4 FX12 and gigabit rgmii PHY. >> >>[snip] >> >> Are there leaner alternatives to plb_temac that might work for me? > Have a look at xapp807: http://www.xilinx.com/bvdocs/appnotes/xapp807.pdf > > Uses only a few slices, but you can't use any PLB or OPB components. But > if all you need is Ethernet and nothing else from the PowerPC, this is > probably thew way. > > -- > My email address is only valid until the end of the month. > Go figure what the address is going to be after that...Article: 113643
I feel it is better to start a new thread, I have compiled my
divide oscillator clock by ten module, what do I do now?
////////////////////////////////////////////////////////////////////////////
//////
module clkdiv10mod(in, out);
input in;
output out;
reg [3:0] cnt;
always @ (in)
begin
cnt=cnt+1;
if (cnt ==9)
begin
cnt =0;
cnt =!cnt;
end
end
endmodule
Here is my console output:
=========================================================================
* HDL Compilation *
=========================================================================
Compiling verilog file "clkdiv10mod.v" in library work
Module <clkdiv10mod> compiled
No errors in compilation
Analysis of file <"clkdiv10mod.prj"> succeeded.
=========================================================================
* Design Hierarchy Analysis *
=========================================================================
Analyzing hierarchy for module <clkdiv10mod> in library <work>.
Building hierarchy successfully finished.
=========================================================================
* HDL Analysis *
=========================================================================
Analyzing top module <clkdiv10mod>.
Module <clkdiv10mod> is correct for synthesis.
=========================================================================
* HDL Synthesis *
=========================================================================
Performing bidirectional port resolution...
Synthesizing Unit <clkdiv10mod>.
Related source file is "clkdiv10mod.v".
WARNING:Xst:647 - Input <in> is never used.
WARNING:Xst:1306 - Output <out> is never assigned.
Found 4-bit adder for signal <$old_cnt_1>.
Summary:
inferred 1 Adder/Subtractor(s).
Unit <clkdiv10mod> synthesized.
=========================================================================
HDL Synthesis Report
Macro Statistics
# Adders/Subtractors : 1
4-bit adder : 1
=========================================================================
=========================================================================
* Advanced HDL Synthesis *
=========================================================================
=========================================================================
Advanced HDL Synthesis Report
Macro Statistics
# Adders/Subtractors : 1
4-bit adder : 1
=========================================================================
=========================================================================
* Low Level Synthesis *
=========================================================================
Optimizing unit <clkdiv10mod> ...
=========================================================================
* Partition Report *
=========================================================================
Partition Implementation Status
-------------------------------
No Partitions were found in this design.
-------------------------------
WARNING:ProjectMgmt - "C:/Xilinx/clkdiv10/clkdiv10mod.ngc" line 0 duplicate
design unit: 'Module|clkdiv10mod'
Process "Synthesize" completed successfully
Command Line: C:\Xilinx\bin\nt\ngdbuild.exe -ise
c:/Xilinx/clkdiv10/clkdiv10.ise
-intstyle ise -dd _ngo -i -p xc9500 clkdiv10mod.ngc clkdiv10mod.ngd
Reading NGO file 'c:/Xilinx/clkdiv10/clkdiv10mod.ngc' ...
Loading design module "c:\Xilinx\clkdiv10/clkdiv10mod.ngc"...
WARNING:NgdBuild:578 - Design contains no instances.
Checking timing specifications ...
Checking Partitions ...
Checking expanded design ...
Partition Implementation Status
-------------------------------
No Partitions were found in this design.
-------------------------------
NGDBUILD Design Results Summary:
Number of errors: 0
Number of warnings: 1
Writing NGD file "clkdiv10mod.ngd" ...
Writing NGDBUILD log file "clkdiv10mod.bld"...
NGDBUILD done.
Process "Translate" completed successfully
Started : "Fit".
ERROR:Cpld:1005 - Design 'clkdiv10mod' has no outputs.
Process "Fit" failed
Article: 113644Al wrote: > Al wrote: > >> AMONTEC wrote: >> >>> Al wrote: >>> >>>> Hi guys, >>>> I have to produce a PCB with a couple of FPGA on it and I was >>>> wondering if the solder mask right under the FPGA would prevent a >>>> good heat dissipation (provided that we will put the thermal paste >>>> underneath). Some of our designers suggested that the gain you have >>>> in heat dissipation you will loose it in short-circuit problems on >>>> the mounting, through the via underneath which are much more of a pain. >>>> Could you give me any suggestion? >>>> >>>> Thanks a lot >>>> >>>> Al >>>> >>> >>> For BGA or TQFP ? >>> I think CERN is working on big BGA ;-) >>> >> >> Well, it's a Cern official experiment, but it's not going on any >> beams. It's for space application (AMS-02). >> Anyway I'm talking about PQFP 208 (Actel A54SX072A). >> >> Al >> > ...and TQFP 100 (Actel A54SX08A). Do these have exposed paddles, or are you just looking for PlasticPackage - ThermalPaste - Soldermask - Copper - PCB - More layers etc In that context, you will be better off thermally, by removing the solder mask from the copper areas, IF it has worse conductance than the paste. Most of the thermal work is done by the copper : Leads, PCB area, vias etc. We have used paste-vias, that fill with solder, to improve thermal pathways, and maximal poured copper areas. We have also used black solder mask, tho I'm not sure how much actual dT that finally gave. -jgArticle: 113645
<222> wrote in message news:45873ba6$1_3@mk-nntp-2.news.uk.tiscali.com... >I feel it is better to start a new thread, I have compiled my > divide oscillator clock by ten module, what do I do now? Get out a simulator and see if it works. Once you've done some of your own work, perhaps ask for some help. KJArticle: 113646
"KJ" <kkjennings@sbcglobal.net> wrote in message news:s6Hhh.4519$yC5.3050@newssvr27.news.prodigy.net... > > <222> wrote in message news:45873ba6$1_3@mk-nntp-2.news.uk.tiscali.com... > >I feel it is better to start a new thread, I have compiled my > > divide oscillator clock by ten module, what do I do now? > > Get out a simulator and see if it works. Once you've done some of your own > work, perhaps ask for some help. No, no need to simulate, I am ready for the real thing Please contine (as opposed to 'break') > > KJ > >Article: 113647
<222> wrote in message news:45874059$1_1@mk-nntp-2.news.uk.tiscali.com... > > "KJ" <kkjennings@sbcglobal.net> wrote in message > news:s6Hhh.4519$yC5.3050@newssvr27.news.prodigy.net... >> >> <222> wrote in message news:45873ba6$1_3@mk-nntp-2.news.uk.tiscali.com... >> >I feel it is better to start a new thread, I have compiled my >> > divide oscillator clock by ten module, what do I do now? >> >> Get out a simulator and see if it works. Once you've done some of your > own >> work, perhaps ask for some help. > > > No, no need to simulate, I am ready for the real thing > Please contine (as opposed to 'break') > You have EVERY reason to simulate.. By trivial inspection I can tell that your design doesn't do anything at all. You could start by pondering on the warning messages out of the HDL Synthesis that 'warn' you that input 'in' is never used and output 'out' is never assigned and try to figure out why that would be (Hint: Input 'in' is never used BECAUSE output 'out' is never assigned and since 'out' is the only output this would imply that there is no need for any inputs). Since no inputs or resources of any kind are needed to implement your code, eventually this leads to the fitting error....once again, perhaps read the error message that says that your module has no outputs. In any case, I'll repeat the suggestion to start to use a simulator and simulate your code. There is not much point in running through the synthesis process until you have functioning code....and you can't say you have functioning code until it works at least in a simulation environment. KJArticle: 113648
Hello David,
I recommend that you use Quartus II 6.1 which was just released and can
be downloaded from www.altera.com. Quartus II 6.1 will be available without
charge as it is part of your subscription. The incremental flow has been
simplified and the limitations that existed in 6.0 regarding incremental
compile have been removed. Please read the following document available as
part of the Quartus II handbook, prior to doing incremental compile
http://www.altera.com/literature/hb/qts/qts_qii51015.pdf
A lot of the information you require is available from page 2-84 onwards,
but I recommend that you invest the time in reading this document to use
this feature effectively.
Hope this helps,
Subroto Datta
Altera Corp.
"David B. Thomas" <dt@dt.prohosting.com> wrote in message
news:u4prtvyho.fsf@dt.prohosting.com...
> We just purchased the full version of Quartus II (version 6.0) because
> it has the ability to perform incremental recompiles after small
> changes, saving on compile time. I understand the design flow as
> described in the manual, but so far I've been unable to get
> incremental recompiles to work right. (I'm using a command line
> interface rather than the GUI, in case that makes a difference.)
>
> Running quartus_map, I get this message.
>
> Info: Partition "s_led" is synthesized because no netlist is
> available for reuse
>
> That makes sense the first time around, but presumably a
> post-synthesis or post-fit netlist would be saved and subsequent
> compiles could use it.
>
> Running quartus_cdb --merge=on, I get this:
>
> Warning: Previously generated Fitter netlist for partition
> "s_led" does not exist -- trying to use previously generated
> Synthesis netlist
>
> This might indicate a modicum of success, i.e. that at least the
> post-synthesis netlist *might* be used, but I want to use the post-fit
> netlist for more time savings.
>
> Running quartus_fit, I get this:
>
>
> Warning: Ignored partition netlist type assignment changes
> Info: Partition "s_led" is using previous netlist type "Source
> File" and not current setting of "Post-Fit"
>
> I suspect that this warning message is tied in with the fact that no
> post-fit netlist appears to be being saved for next time.
>
> Does anyone know what might be going on?
>
> Many thanks...
> David
> --
> If only 2^(7/12) were equal to 3/2, music would sound a lot better.
Article: 113649We are not actually configuring the FPGA using the CF Card, we are using the USB JTAG for configuration. Do I need to load a .ace file a different way? Lasse wrote: > Hello > > This error is due to the system ace is looking for .ace file for configuring the FPGA. If it can not find the file the led will bi lit.
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