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
Hello all, Whenever I need to look at a filter output (or any DSP core), I used to define a real signal and assign it to what I want to examine, roughly something like this: dac_real_out <= hex2real(dac_holder, 12.0); where dac_holder is a std_logic_vector. It is much easier to look at an analogue signal waveform instead of tracing hex values word by word. This used to work quite alright using ModelSim XE edition. Now for some reason, it seems I can't get it to compile my design---I get the following error: # ** Error: (vcom-42) Unsupported ModelSim library format for "work". (Format: 3) My first question is: can I go around it as I've never encountered this before. My second one is: if not, is there anyway I can make ISE simulator do the same thing? apparently I can't add this real signal to my waveform editor and presumably ISE doesn't support it. Would appreciate any input on this. Thanks & regards, -MannyArticle: 120776
HSWAPEN is the Input Dedicated pin. Active High input used to disable weak pre-configuration I/O pull-up resistors: 0 = weak pre-configuration I/O pull-up resistors enabled 1 = weak pre-configuration I/O pull-up resistors disabled HSWAPEN must be connected to either enable or disable the pull-up. This is depends on your custo design, if you want to disable/enable the function. Regards, Sachin resistors. HSWPEN has a weak pull-up prior to and during configuration.Article: 120777
HSWAPEN is the Input Dedicated pin. Active High input used to disable weak pre-configuration I/O pull-up resistors: 0 = weak pre-configuration I/O pull-up resistors enabled 1 = weak pre-configuration I/O pull-up resistors disabled HSWAPEN must be connected to either enable or disable the pull-up resistors. HSWPEN has a weak pull-up prior to and during configuration. This is depends on your custom design, if you want to disable/enable the function. This means your all I/O pins would be pulled-up to VCCIO voltages during configuration. If you don't want to pulled-up ur all I/O's to Pulled-up to VCCIO then you can disable it. Regards, SachinArticle: 120778
Yes if you have never used your INOUT pins as an input to your design then when you sysnthesize your code tool will automatically treated it as a tristated output only. SachinArticle: 120779
Thanks for clarifying this David JonArticle: 120780
Sachin <sachin.gorkhe@einfochips.com> wrote: > HSWAPEN is the Input Dedicated pin. > > Active High input used to disable weak pre-configuration I/O > pull-up resistors: > > 0 = weak pre-configuration I/O pull-up resistors enabled > > 1 = weak pre-configuration I/O pull-up resistors disabled HSWAPEN > must be connected to either enable or disable the pull-up resistors. > > HSWPEN has a weak pull-up prior to and during configuration. > > > > This is depends on your custom design, if you want to disable/enable > the function. > > This means your all I/O pins would be pulled-up to VCCIO voltages > during configuration. If you don't want to pulled-up ur all I/O's > to Pulled-up to VCCIO then you can disable it. Thanks for clarifying the direction of the pin. Do you have any idea of the strength of the weak pullups? In most cases I want the pullup, but for a couple IO pins I want to override it with a stronger pulldown in the preconfigurationn time. If no one knows I guess I'll just have to suck it and see, but I'm surprised there doesn't seem to be any indication what "weak" means in the docs. Cheers, Nobby -- Nobby AndersonArticle: 120781
Is there a method of using external RAM (Generic external Memory) where the data, heap and stack can be located? Ideally the code would remain in BRAM so not to require additional external non-volatile memory. I've tried altering the loader script to indicate a different address range for the data side but I come up with: WARNING:MDT - Elf file TestApp_Memory/executable.elf does not reside completely within BRAM memory of processor microblaze_0. Is there an example I can use as a starting point - if one exists!Article: 120782
On Fri, 15 Jun 2007 09:33:59 -0500, "Chris@Austin" <ggkuo@yahoo.com> wrote: >On FPGA A, >1. A clock, APP_CLK (200 MHz), comes out of a DCM, which is used to >mange the receiving clock from off-chip DDR2 DIMM. > >2. APP_CLK drives another DCM for clock synthesis of 100 MHz and 50 MHz. >The feedback of this DCM is from the output of DCM itself, which may be >an issue. > >3. Takes the 100 MHz clock to an ODDR primitive (Dedicated IOB double >data rate output registers). This is suggested by Xilinx Vitex-5 User >Guide. > >4. forward this clock to FPGA B. > >on FPGA B, > >1. use IBUG, DCM and BUFG to generate the synchronous clock. That's 3 DCMs in series, which is generally reckoned to be a bad idea, because of jitter accumulation. (1) Can you not simply use IBUFG on the second FPGA? If the DCM is just generating a copy of the incoming clock with no phase shift, try without it. You have some tools in the IOBs to control signal timings between the FPGAs, without adjusting clock phase in FPGA2; alternatively you may have 90/180/270 degree phase shifts available on the 100MHz clock in FPGA1. (2) Can you use CLKX2, CLK and CLKDV from a single DCM in the first FPGA? (Alternatively, get both 100 and 200MHz from one DCM and use the second DCM for only the 50MHz clock) Either of these will reduce the chain of DCMs down to the recommended max of 2. Both will eliminate chaining DCMs altogether. (3) You could divide the 200MHz clock in a FF in FPGA1, to feed to FPGA2, if you need the DCM in FPGA2. Take care to analyse the delay introduced by the FF. BrianArticle: 120783
jjlindula@hotmail.com wrote: > Hello, I'm looking for opinions on using LogicLock in Quartus II, is > it useful or a waste of time? What are some of your experiences with > LogicLock? Generally speaking, on an 'average', not-too-large (<20K LUTs) design that tends to meet frequency, there's no need to use LogicLock at all. It gets interesting if you need to push de FPGA for performance and/or if you have a very large design. The fitter makes one huge compromise between all paths when doing its job and in order to get the most out of it you may want to sometimes just optimize a subdesign for performance and then merge it back into your main design as a QXP file (which is pre-placed-and-routed). The good things about this are 1 - You pretty much preserve the subdesign's performance 2 - You greatly reduce fitting time Now, you don't want your logic to be all over the place in the FPGA, and in those cases it is practical to constrain your subdesign to lie within a certain rectangle, which is exactly what LogicLock regions do. I'm currently working on a rather tricky design in terms of timing, and by pre-optimizing a subdesign and importing it as a QXP in the main design I do fitter runs in 22mins instead of 50... Best regards, BenArticle: 120784
Dear I am confused to obtain real "clock frequency" of my 2 implementations. Implementation details are following. In UCF file, (1) "CLK" is connected to Virtex-II Pro clock pin. (2) I constrained the clock "CLK" as 10 ns. Inside the design module, DCM is instantiated. DCM generates a signal with two times frequency, "CLK2X". Finally, following report was obtained. ------------------------------------------------------------ Implementation 1 ----------------------------------------------------------- Constraint 1 TS_Inst_DCM1_CLK2X_BUF = PERIOD TIMEGRP "Inst_DCM1_CLK2X_BUF" TS_CLK / 2 HIGH 50% Requested = 5.000ns Actual =3.683ns --------------------- Constraint 2 TS_Inst_DCM1_CLK0_BUF = PERIOD TIMEGRP "Inst_DCM1_CLK0_BUF" TS_CLK HIGH 50% Requested = 10.000ns Actual = 4.565ns ------------------------------------------------------------ ------------------------------------------------------------ Implementation 2 ----------------------------------------------------------- Constraint 1 TS_Inst_DCM1_CLK2X_BUF = PERIOD TIMEGRP "Inst_DCM1_CLK2X_BUF" TS_CLK / 2 HIGH 50% Requested = 5.000ns Actual =4.897ns --------------------- Constraint 2 TS_Inst_DCM1_CLK0_BUF = PERIOD TIMEGRP "Inst_DCM1_CLK0_BUF" TS_CLK HIGH 50% Requested = 10.000ns Actual = 2.929ns ------------------------------------------------------------ Question is that Is following statement correct? Clock period of Implementation 1 = 4.565ns Clock period of Implementation 2 = 4.897ns Thank you in advance for any comment.Article: 120785
Nobby, The weak pullup is specified here: http://direct.xilinx.com/bvdocs/publications/ds302.pdf page 3 of 5. From 40uA to 200 uA depending on Vcco. 200 uA @ 3.3 volts, 40 uA at 1.5 volts. So if VccoConfig=2.5v, that is 120 uA. 2.5/120uA =~ 21 K ohms R min. All of those are max values. Min is 5 uA for any Vcco. 2.5/5 uA = 500 K ohms. Max R pullup. AustinArticle: 120786
There is a way (at least Xilinx descibe it somewhere) to load cache through the USER_ACCESS_REGISTER. Software(bootloader) portion is appended to the configuration data portion of FPGA. After FPGA is configured, your proceeed with sending software portion of data to the FPGA. Inside FPGA, special hardware block converts your data stream to JTAG commands for PPC. These commands put your software into the cache and run it.Article: 120787
Manny wrote:
> This used to work quite alright using ModelSim XE edition. Now for
> some reason, it seems I can't get it to compile my design---I get the
> following error:
> # ** Error: (vcom-42) Unsupported ModelSim library format for "work".
> (Format: 3)
You can't *elaborate* (vsim) your design because
the compiled work directory does not match the simulator
you are using. Delete it and recompile (vcom)
For modelsim, that is something like:
vdel -all
vlib work
vmap work work
vcom <source files>
I like to write script like this
to archive with the design.
> is there anyway I can make ISE simulator do
> the same thing? apparently I can't add this real signal to my waveform
> editor and presumably ISE doesn't support it.
I expect that is true.
You are better off with a real hdl simulator in any case.
-- Mike Treseler
Article: 120788On Jun 15, 10:18 am, "John_H" <newsgr...@johnhandwork.com> wrote: > "cutemonster" <ckh...@hotmail.com> wrote in message > > news:CuOdneSaAIBJXO_b4p2dnAA@giganews.com... > > > > > Whatever you do, please don't use the DCM to generate the clock for the ADC > since it could raise the noise floor of the ADC output significantly. > Instead, use the clean clock that feeds the ADC to run the FPGA. > > - John_H I am curious as to know the reason behind not using fpga generated clock to drive the adc. Is it because they have higher amount of jitter? I am in the process of designing a datapath from adc to the fpga. Thanks. -sanjayArticle: 120789
On Jun 16, 7:32 am, Ben Twijnstra <ben.twijns...@gmail.com> wrote: > jjlind...@hotmail.com wrote: > > Hello, I'm looking for opinions on using LogicLock in Quartus II, is > > it useful or a waste of time? What are some of your experiences with > > LogicLock? > > Generally speaking, on an 'average', not-too-large (<20K LUTs) design that > tends to meet frequency, there's no need to use LogicLock at all. > > It gets interesting if you need to push de FPGA for performance and/or if > you have a very large design. The fitter makes one huge compromise between > all paths when doing its job and in order to get the most out of it you may > want to sometimes just optimize a subdesign for performance and then merge > it back into your main design as a QXP file (which is > pre-placed-and-routed). The good things about this are > > 1 - You pretty much preserve the subdesign's performance > 2 - You greatly reduce fitting time > > Now, you don't want your logic to be all over the place in the FPGA, and in > those cases it is practical to constrain your subdesign to lie within a > certain rectangle, which is exactly what LogicLock regions do. > > I'm currently working on a rather tricky design in terms of timing, and by > pre-optimizing a subdesign and importing it as a QXP in the main design I > do fitter runs in 22mins instead of 50... > > Best regards, > > Ben I tried to use incremental compile in Quartus 6.0. The size of this particular project was <15K gates was using 95% of the internal ram. I wasn't using qxp files instead relied on Quartus knowing which blocks to not touch. In some cases I found that my compile times went from 25minutes to 15 minutes. But I lost that edge when I started using signaltap. If I remember, I could not meet timing. My motivation for using the incremental compile was to save time during debugging in signaltap. That purpose was defeated. As I recollect the situation - in our case we did not have registers on the inputs. In my case, I was working on a block that had inputs going to other blocks in the system as well. I was changing things only in my block but as I did not have any input registers, the delays to the registers in my block kept changing and Quartus was not able to meet timing as it could not change the placement of any of the registers in the blocks that were locked. In this case, by changing the placement and routing options on the fixed blocks from hard to soft, Quartus was able to meet timing but I lost any edge in time saving in incremental compile. Therefore, my recommendation - if you are relying on incremental compiles - besides other good design practices, make sure you use registers on the inputs to a block and if you would like to improve speeds. Try going to a machine with more memory. In our case, a dual- core pentium with 2 GB memory dropped our compile times from 25 minutes to 7 min. -sanjayArticle: 120790
austin <austin@xilinx.com> wrote: > Nobby, > > > The weak pullup is specified here: > > > http://direct.xilinx.com/bvdocs/publications/ds302.pdf Ah, I misunderstood that, I was looking for a different "weak" and "normal" or "strong" value, or some such. I guess they really mean that if there's a pullup, they're always week, and this is the value. The documentation could be a little clearer, and not use the term "weak" in some places and not in others. Thanks for that, Austin, that's sorted me out. Cheers, Nobby -- Nobby AndersonArticle: 120791
<rob.dimond@gmail.com> wrote in message news:1181925467.941552.286330@n2g2000hse.googlegroups.com... > Hi, > > I have a vague memory that Xilinx used to provide excel spreadsheets > that showed the graphical pinout of each FPGA package using coloured > cells to represent each pin. > I couldn't find any reference after much googling and searching of the > Xilinx site. Does anyone have a pointer to these spreadsheets, if > indeed they still (or ever) existed? > > Rob > They have an Excel spreadsheet for the Spartan 3 - I Googled "spartan 3 datasheets" and went straight to it - but I could only see ASCII text files for Virtex 4 e.t.c. Maybe they don't do it for BGA packages.Article: 120792
fpgabuilder wrote: > On Jun 15, 10:18 am, "John_H" <newsgr...@johnhandwork.com> wrote: >> "cutemonster" <ckh...@hotmail.com> wrote in message >> >> news:CuOdneSaAIBJXO_b4p2dnAA@giganews.com... >> >> >> >> >> Whatever you do, please don't use the DCM to generate the clock for the ADC >> since it could raise the noise floor of the ADC output significantly. >> Instead, use the clean clock that feeds the ADC to run the FPGA. >> >> - John_H > > I am curious as to know the reason behind not using fpga generated > clock to drive the adc. Is it because they have higher amount of > jitter? I am in the process of designing a datapath from adc to the > fpga. > > Thanks. > -sanjay The jitter is the problem. For a high speed ADC, the error from jitter can approach the ratio of the jitter to the clock period for a properly band-limited input signal. For a direct IF sampling system, the error can exceed that ratio. If you think of the voltage slewing on the ADC input, the error in the sample point corresponds directly in a voltage error; if the sample was ideally zero volts, the jitter makes the actual sample further up or down that rapidly changing voltage. The noise floor will be noticeably raised in a fast system. The cleanest way to work with an FPGA/ADC system is to use the clean clock to drive the ADC and the FPGA, no daisy chaining. If you *must* use an FPGA to drive the clock (if you're doing phase modulation of the sampling, for instance) then a cleanup PLL is required to get the noise down to an acceptable level. FPGAs are superb for logic. They are not designed to function as analog elements. The DCMs are well specified and perform very well for even the most demanding logic. But DCMs are not analog quality. Treat them as analog noise sources! The jitter is the biggest issue. - John_HArticle: 120793
On 12 juin, 19:02, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Amine.Mi...@gmail.com wrote: > > On 12 juin, 04:05, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > > >>Amine.Mi...@gmail.com wrote: > > >>>Hi, > > >>>when i implemented my architecture using ACTEL AFS600 (Fusion family) > >>>i noticed that over 16MHz there is a gap in consumption, in fact when > >>>i was changing my frequency from 1 kHz to 16 Mhz the power consumption > >>>is varying from 13 mW till 20 mW when i reach 16 MHz there is a gap > >>>and the power consumption jump directly to 30 mW, > >>>anyone has any reason to explain this gap? > > >>>my speed grade is -2, > > >>Is it operating normally over that threshold ? > >>Normally, such a current discontinuity, also infers > >>an operational discontinuity. > > >>Does the slope continue at just under 0.5mW/Mhz above that threshold ? > > >>I'd test again with some simpler code, that you know has a very high Fmax. > > >>-jg > > > that's the problem: the FPGA is still working good. > > Yes the slope continue at just 0.5mW/Mhz above that threshold, > > i tested the FPGA with other code and what s strange is that this > > discontinuity still exist but for higher frequency (again the fpga is > > still working good) > > Yes, that does sound strange - what was the higher freq in the other test ? > 16MHz should be 'low' by FPGA standards - were you using (or had > enabled?) any of the PLL/Clock multiplier resources ? > > Did you ask Actel ? - those symptoms suggest they might not > be disabling everything they should, in the SW process ? > > -jg- Masquer le texte des messages pr=E9c=E9dents - > > - Afficher le texte des messages pr=E9c=E9dents - the maximum frequency is 37 MHz, and no i m not using any PLL, I asked atcel but i m still waiting for the answer!!!Article: 120794
When you said "define clock corectly", you meant define them in timing analyzer. Am I right? I did that and I found which paths have "Hold Violation". But I don't know what to do now. What should I do to get rid of this "Non operational path". Should I insert some "delay" in these datapaths (how?), or there is another way. What can be done in this situation? Also, I defined all clocks (in timing analyzer), and I set on "optimaze hold timing" stating "all path", but I still have these "non operational paths". I apologize if this questions is so stupid but I realy don't know how to move on. Any advice is helpfull. Thanks Zorjak wrote: > Thanks David for this explanation. > > I think that I understood you. Thanks for this advices. You are great. > > Thanks again > > dkarch...@gmail.com wrote: > > Zorjak, > > > > A non-operational path is a "Hold Violation". We give this type of > > warning in cases where there is no clock requirements and the clock > > delay to the destination/latching register is much larger than the > > clock delay to the source/launching register (larger than the data > > delay), creating harmful clock skew. This is a problem because the > > data travels to the destination register much faster than the clock, > > creating a situation where the destination register will latch data > > sent by the source register on the "same clock edge" (as oppose to the > > following clock cycle). This is very serious as it means the circuit > > will never operate no matter what the clock speed is. See > > http://en.wikipedia.org/wiki/Clock_skew. > > > > So, why are you seeing this? > > This can happen if Quartus cannot place the clock on a global clock > > network, or more often, if the design has gated clocks (i.e. logic in > > the clock path), or ripple clocks not defined as derived clocks. > > > > The reason why you get the warning in some cases and not in others is > > likely plain luck. Based on the fit, the two registers may have > > positive clock skew (which result in the hold violation) or negative > > skew (which simply results in a lower Fmax). Or the different fit may > > simply slow down the data path such that data delay > clock skew. From > > the Clock Hold Timing Analyzer report panel, select the row with the > > Non-operational message, and use the mouse right-button "List Path" > > command to get details on the path. It will show you details on both > > the clock skew and data path > > > > >From the warning, I know you are not defining any clock requirement. I > > strongly recommend that you create clock requirements for all your > > clocks. This should include derived clocks on any ripple clocks (e.g. > > clock dividers). This will help the fitter come up with a better > > answer. If you go to "Assignments | Settings..." and clock on the > > "Fitter Settings", you will also find an "Optimize hold timing" check. > > You can change its value to "All Paths" to have the fitter insert > > delay to try to avoid hold violations. But this setting will only work > > well if you define your clocks correctly (this is very important). > > Please look at the following handbook chapter for more on timing > > analysis > > > > http://www.altera.com/literature/hb/qts/qts_qii53004.pdf > > > > David Karchmer > > Altera CorpArticle: 120795
Thanks a lot Mike. Got sorted. -MannyArticle: 120796
"Fred" <fred@n0spam.com> writes: > I've tried altering the loader script to indicate a different address range > for the data side but I come up with: > WARNING:MDT - Elf file TestApp_Memory/executable.elf does not reside > completely within BRAM memory of processor microblaze_0. Does anything go wrong other than the warning?Article: 120797
hi, I need to design and implement a very simple FPGA. There will be 34 TTL inputs. One (and only one) will be tripped every few seconds. I need the FPGA to report on which one was tripped. So the output will be six bits outputted via either RS232 or USB, whichever is easier to implement. At this stage I need only one unit and I don't know anyone who'll make such a small quantity. Designing it on my own is not really an option because I'm a mechanical engineer :-) Can anyone recommend someone who can do this for me? thanks, Yoni.Article: 120798
Hi everyone, I have a strange behaviour in my implementation even if the design is pretty simple (even if it's very dense!). I have a decoding block which gets "address" to write data into several registers. The decoding block is such that it will produce an enable signal for each single register. Then a "write" signal is distributed with some latency such that propagation delays are taken into account. What I find is that for postsynthesis simulation everything is fine, but in my postlayout I have some addresses which are enabled even if the address is another one, turning out that I write two registers at once. I can't really understand why! Here is a sketch of my vhdl code: > -- decoding signals > p_signal1 <= '1' when addr = x"123" else > '0'; > p_signal2 <= '1' when addr = x"456" else > '0'; > > > -- writing process > > process (clk, nrst) > begin > if nrst = '0' then > signal1 <= '0'; > signal2 <= '0'; > elsif rising_edge (clk) then > if wr = '1' then > if p_signal1 = '1' then > signal1 <= data; > elsif p_signal2 = '1' then > signal2 <= data; > ... > end process; So it happens that writing to addr = x"123" it will change signal2 as well...how can it be possible??? I did prefer to have "p_signals" and not use directly the "addr" in the process just because in the very beginning I thought about latching the "p_signals" to have them stable, but then I realized it wouldn't have fit in the logic (I have already an occupancy of 84% and I have more than 300 addresses to decode). Do you have any explanation of this behaviour? Thanks a lot for any comment Al -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 120799
On Jun 17, 2:57 am, j...@eng.tau.ac.il wrote: > Can anyone recommend someone who can do this for me? > > thanks, > Yoni. Hi Yoni, Not a problem, How much are you offering for the project, and when do you need your PCB's delivered? I'd suggest using a PLD instead of an FPGA, cheaper and just as fast for your application as stated. Where are you located? John Sr. Engineer.
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