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
axr0284 <axr0284@yahoo.com> wrote: > I wrote some code in VHDL and I would like to create a core targeting > Xilinx Spartan-3E devices. I am clueless of how to proceed with that. > 1) I can synthesize the code using XST with an XCF timing constraint > file which will create an NGC file. Is that considered a CORE? What I consider a core is a module (that is the verilog term, I forget what VHDL calls it) that can be instantiated in a larger design. Similar to a library subroutine in software. In most cases, additional logic will go between that and the actual pins. > 2) Will the NGC file contain the timing information from the XCF > timing constraint file? It seems that they now use UCF. As far as I know, any timing related constraints will occur when the core is used. > 3) Is there a way to actually area constrain it during synthesis? That gets farther into floorplanning than I usually go. -- glenArticle: 137426
"james" <george@washington.edu> wrote in message news:f81vm49djff50gd2s2mvfa07jdejkklg0h@4ax.com... >I have Windows XP with SP3. Can I install Webpack on this OS? The > Webpage states that i would need XP Pro. I care not to upgrade at this > point but this is getting rediculus with Xilinx. They offer products > but very limited scope of OS's. Right now I have 9.2 SP4. > > > james I submitted a case to Xilinx support asking the same question. Here's their response: --- To answer you question about ISE WebPack running on XP home, is it should work, but it's unsupported on XP Home. The Requirement is Microsoft Windows XP Professional (32-bit only). --- Bob -- == All google group posts are automatically deleted due to spam ==Article: 137427
And here is my last attempt:
First, I was wrong thinking that
8259 requires a "minimum LOW period"
even in level sensitive mode (as it
does in edge mode) so I've removed
IRQCOUNTER and lfIRQANY.
Also, I am using plenty of async
resets in my project, and it works
w/o any problems, so thats what I
used here, also.
Result? The SAME as in my previous post..
I'm starting to think that the problem
is somewhere else, but don't know where..
(of course, the 8259 is broken! ;)
(only channel A shown)
TIMER : process (CLKMAIN)
begin
if falling_edge(CLKMAIN) then
if counterA=0 then
cIRQA <= '0';
counterA <= reloadA;
else
cIRQA <= '1';
counterA <= counterA -1;
end if;
end if;
end process TIMER;
IRQFLAGS : process (CLKMAIN, RD, ADDR)
begin
if RD='0' and ADDR=ADRA then
fIRQA <= '0';
elsif rising_edge(CLKMAIN) and cIRQA='0' then
fIRQA <= '1';
end if;
end process IRQFLAGS;
IRQPROC : process (CLKMAIN) begin
if falling_edge(CLKMAIN) then
fIRQANY <= fIRQA or fIRQB or fIRQC;
end if;
if rising_edge(CLKMAIN) then
if fIRQANY='1' then
irqA <= '1';
else
irqA <= '0';
end if;
end if;
end process IRQPROC;
Anyone see a reason why this should not work?
Article: 137428<ikogan@alumni.technion.ac.il> wrote in message news:1188838781.893882.166580@r29g2000hsg.googlegroups.com... >I was trying to estimate the power consumption of IGLOO AGL600V2 FPGA > from Actel with IGLOO power calculator (posted on Actel website). I > received very astonishing results. With full logic utilization at 50 > MHz, 25% toggle rate and around 100 I/Os (LVCMOS 1.8V, LVCMOS 3.3V) it > consumes around 100 mW. It's about half of Xilinx Coolrunner-II > consumption and a small fraction of Xilinx FPGAs (Spartan or Virtex) > for same functionality. I was very surprised by this so maybe I'm > missing something here. Is anybody familiar with this chip and its > power consumption? > I'm using IGLOO now for exactly the reasons you state. The main difference vs. SRAM-based FPGAs is the insanely low static current (measured in uW even in the largest device in the family). The dynamic current is on the order of 30-40% vs. those guys from what I've seen. As a test I compiled a real design into a Xilinx XC2V250 and an AGL600V2. These devices are roughly comparable in size. I then and used the vendor tools to estimate power on the placed and routed designs. Here's what I got: XC2V250-4CS144: Max clock frequency: 119MHz Flip flops: 757/3072 (24%) 4-input LUTs: 817/3072 (26%) Block RAMs: 5/24 Estimated power: 253mW* (using Xilinx's XPower tool) Static: 32mW Dynamic: 221mW * Calculated at 80MHz with 12.5% data toggle rate. AGL600V2-FG144: Max clock frequency: 33.3MHz Flip flops: 870 Total VersaTiles: 4974/13824 (36%) Block RAMs: 5/24 Estimated power: 66mW** (using Actel's SmartPower tool) Static: 0.067mW (67uW) Dynamic: 66mW ** Calculated at 80MHz with 12.5% data toggle rate (even though design won't run that fast). The IGLOO power is ~25% of the Xilinx power at the same frequency, and the IGLOO static power is only 67 uW (~1/500th of the Xilinx). Truly amazing. You pay the price for that low power, though, as the design runs 3.5x as fast in the Xilinx. But for some designs, like the one I'm working on now, low power is paramount. As for the Coolrunner-II, the Coolrunner is a 1.8V part vs. 1.2V for the IGLOO V2. That's a 50% power difference right off the bat. The rest must just be differences in the design and process. RobArticle: 137429
"Douglas" <j.d.morrison@gmail.com> wrote in message news:1189491208.142555.102930@50g2000hsm.googlegroups.com... > On Sep 3, 7:59 pm, iko...@alumni.technion.ac.il wrote: >> It's about half of Xilinx Coolrunner-II >> consumption and a small fraction of Xilinx FPGAs (Spartan or Virtex) >> for same functionality. > > Which Xilinx parts you used as a comparison point? I don't have > expertise on Actel parts, but they seem to have 'quite' optimistic > marketing gates readings, so comparing 250k part to 250k part might > not be fair. > > On a related topic - does anyone have expertise about the trade-offs > of Actel's "Versa-Tiles" vs. 4/6-LUTs. It seems like obviously > wastefull configuration - how many thansistors they can really share > between 3-LUT and D-FF? Is there some benefit in this configuration, > or is this 'design choice' made just to avoid Altera and Xilinx > patents? > > - Doug > I don't see it as wasteful. It's just a more granular and generic architecture, which has some advantages. I would guess that lowering power was also a big part of the equation. No idea about patent concerns. RobArticle: 137430
On Jan 14, 9:47=A0pm, sreenivas.jyo...@gmail.com wrote: > On Dec 15 2008, 11:39=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > > > In a conventional design (single clock, distributed over global clock > > nets, all flip-flops triggered on the same, usually rising, clock > > edge, clock frequency not at the max data-sheet limit)dutycycleis irrel= evant, as long as you do not violate any clock-High > > or clock-Low timing. > > More exotic designs that use both clock edges or use latches instead > > of flip-flops, are (or might be) sensitive to clockdutycycle. > > Distributing clocks on non-global lines can seriously affectdutycycle, = and also cause uncontrolled clock skew and other bad problems. > > Don't do that! > > Peter Alfke > > Hi peter, > thanks for your response, i am still not configuring my doubt on this > (duty Cycle). > Here is my clear query: I have requirement saying that "The test case > is to test the output signal rcom_tx when fpga_clk is 50 MHz with 40% > and 60% duty cycles", and before that i had a test case for same > signals on 50% duty cycle. so when i did test on 50% duty cycle i got > normal results without any problems, and i am not able to figure out > if i change to 40% and 60% duty cycles than what to expect on output > line. > > As of my knowledge within duty cycle boundary limit the output doesn't > affect, but out of boundary change in duty cycle is the only > expectancy. > If possible could you please give me any example in explaining this > concept. > > Thanks 50% duty cycle at 50 MHz means 10 ns High followed by 10 ns Low. If you use global clock distribution, there will be no difference whatsoever in the register outputs if you vary the 10 ns to 8 or 12 ns. Try to understand the operation of clocked D-flip-flops, and you will agree. Peter AlfkeArticle: 137431
robj schrieb: > <ikogan@alumni.technion.ac.il> wrote in message > news:1188838781.893882.166580@r29g2000hsg.googlegroups.com... >> I was trying to estimate the power consumption of IGLOO AGL600V2 FPGA >> from Actel with IGLOO power calculator (posted on Actel website). I >> received very astonishing results. With full logic utilization at 50 >> MHz, 25% toggle rate and around 100 I/Os (LVCMOS 1.8V, LVCMOS 3.3V) it >> consumes around 100 mW. It's about half of Xilinx Coolrunner-II >> consumption and a small fraction of Xilinx FPGAs (Spartan or Virtex) >> for same functionality. I was very surprised by this so maybe I'm >> missing something here. Is anybody familiar with this chip and its >> power consumption? > As for the Coolrunner-II, the Coolrunner is a 1.8V part vs. 1.2V for the > IGLOO V2. That's a 50% power difference right off the bat. The rest must > just be differences in the design and process. The voltage counts quadratic for the power consumption. So a difference from 1.8V to 1.2V results in a power reduction by a factor of 2.25 and not 1.5! MatthiasArticle: 137432
On Jan 15, 9:45=A0am, reganirel...@gmail.com wrote: > Same with me. > > A staff member from Digilent emailed me with that same link, good as > gold now. > > Regan I guess they had shipped the boards before the software was ready to go on the website. Have fun. No I can start to have a real go at learning VHDL! Dave...Article: 137433
> I'm using IGLOO now for exactly the reasons you state. The main difference vs. SRAM-based FPGAs is > the insanely low static current..... ...and performance. > XC2V250-4CS144: > Max clock frequency: 119MHz > AGL600V2-FG144: > Max clock frequency: 33.3MHz I got bitten recently trying to convert a design from a Cyclone I to an Actel ProAsic3. It was runing at 66MHz in the Cyclone I with reasonably tight IO requirements, this took a wee bit of tweaking in Quartus but I got it to build cleanly fairly quickly. I've no doubt I could have translated the design to a Spartan-3 fairly quickly/easily. After a great deal of work and some assistance from an Actel rep I still wasn't able to get the design working in the ProAsic3, I had naievly presumed the performance would be roughly similar to the Altera/Xilinx parts. My get out was that my client had chosen the part. They're great for what they do well but just be wary if you need to push the performance (at all). Nial.Article: 137434
> IRQFLAGS : process (CLKMAIN, RD, ADDR) > begin > if RD='0' and ADDR=ADRA then > fIRQA <= '0'; > elsif rising_edge(CLKMAIN) and cIRQA='0' then > fIRQA <= '1'; > end if; > end process IRQFLAGS; > As I said before... You probably don't want to do this, use your master 20MHz clock to synchronise all your external signals and use the re-timed signals to drive the internal logic. Do a bit of googling on synchronous FPGA design and how to handle asynchronous inputs. _DON'T_USE_THE_RD_SIGNAL_AS_AN_ASYNCHRONOUS_SIGNAL_ Nial.Article: 137435
On Jan 16, 12:50=A0pm, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > I'm using IGLOO now for exactly the reasons you state. The main differe= nce vs. SRAM-based FPGAs is > > the insanely low static current..... > > ...and performance. > > > XC2V250-4CS144: > > Max clock frequency: 119MHz > > AGL600V2-FG144: > > Max clock frequency: 33.3MHz > > I got bitten recently trying to convert a design from a Cyclone I to > an Actel ProAsic3. > > It was runing at 66MHz in the Cyclone I with reasonably tight IO > requirements, this took a wee bit of tweaking in Quartus but I > got it to build cleanly fairly quickly. I've no doubt I could have > translated the design to a Spartan-3 fairly quickly/easily. > > After a great deal of work and some assistance from an Actel rep > I still wasn't able to get the design working in the ProAsic3, > I had naievly presumed the performance would be roughly similar > to the Altera/Xilinx parts. My get out was that my client had > chosen the part. > > They're great for what they do well but just be wary if you need > to push the performance (at all). > > Nial. Hi Nial, i could have saved you the trouble, i guess. after having an almost year long struggle while converting from Xilinx to A3P060 with a project with NO timing issues at all, well if you had timing tweaking requirements with Cyclone, my thumb advice would have been, DO NOT DARE to try the same with A3P well, but they are OK, for what they work, nothing agains them, just you need to know where to use them, and where not. world first FPGA-Stamps are made of A3P060-CN132 :) AnttiArticle: 137436
On Jan 16, 11:59=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > IRQFLAGS : process (CLKMAIN, RD, ADDR) > > begin > > =A0 =A0if RD=3D'0' and ADDR=3DADRA then > > =A0 =A0 =A0 =A0fIRQA <=3D '0'; > > =A0 =A0elsif rising_edge(CLKMAIN) and cIRQA=3D'0' then > > =A0 =A0 =A0 =A0fIRQA <=3D '1'; > > =A0 =A0end if; > > end process IRQFLAGS; > > As I said before... > > You probably don't want to do this, use your master 20MHz > clock to synchronise all your external signals and use > the re-timed signals to drive the internal logic. > > Do a bit of googling on synchronous FPGA design and how to handle > asynchronous inputs. Ok, will do. But, read below. > > _DON'T_USE_THE_RD_SIGNAL_AS_AN_ASYNCHRONOUS_SIGNAL_ > > Nial. Problem solved. Nial Stewart pointed out some 2 days ago: "if you need a count of X then load the counter with X-1 if you're counting to 0" Since my "clock to sink-in" time is about 48 hrs, I did as I was told and it now works.. Thanks, everyoneArticle: 137437
"aleksa" <aleksaZR@gmail.com> wrote in message news:68552330-6502-40da-9d6a-31e17040bb0c@v4g2000yqa.googlegroups.com... > And here is my last attempt: > Giving up already? > > TIMER : process (CLKMAIN) > begin > if falling_edge(CLKMAIN) then There is no reason to be using falling edge here. Synchronous design practice uses rising edge. Other than that there are no obvious problems with the timer process. > > > IRQFLAGS : process (CLKMAIN, RD, ADDR) > begin > if RD='0' and ADDR=ADRA then > fIRQA <= '0'; > elsif rising_edge(CLKMAIN) and cIRQA='0' then And here is your problem. You're using RD and ADDR asynchronously. Now ask yourself what happens if the condition "RD='0' and ADDR=ADRA " goes *away* just prior to the rising edge of CLKMAIN? The result will be a timing problem on signal fIRQA which means that this process can end up setting fIRQA to 1. The other problem is that the async reset of fIRQA can screw up the timing to anything that *uses* fIRQA. The solution as has been pointed out already is to: 1. synchronize RD and ADDR before using. 2. Don't use "RD='0' and ADDR=ADRA " to asynchronously reset fIRQA. In fact, don't use asynchronous resets at all...ever (almost ever). 3. Perform static timing analysis > > IRQPROC : process (CLKMAIN) begin > if falling_edge(CLKMAIN) then > fIRQANY <= fIRQA or fIRQB or fIRQC; Again, synchronous design practice has no use for falling edge triggered logic, use the rising edge instead. Other than that, there doesn't seem to be any problems with the irqproc process...however the inputs to the process have not been synchronized to the clock because fIRQA is not synchronous due to your use of the async reset in the previous process. > Anyone see a reason why this should not work? Yes Kevin JenningsArticle: 137438
Yes. I'm using webpak 10.1 and edk 10.1 on winxp sp3. They are working well without any problems.Article: 137439
On Jan 16, 5:50=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > I'm using IGLOO now for exactly the reasons you state. The main differe= nce vs. SRAM-based FPGAs is > > the insanely low static current..... > > ...and performance. > > > XC2V250-4CS144: > > Max clock frequency: 119MHz > > AGL600V2-FG144: > > Max clock frequency: 33.3MHz > > I got bitten recently trying to convert a design from a Cyclone I to > an Actel ProAsic3. > > It was runing at 66MHz in the Cyclone I with reasonably tight IO > requirements, this took a wee bit of tweaking in Quartus but I > got it to build cleanly fairly quickly. I've no doubt I could have > translated the design to a Spartan-3 fairly quickly/easily. > > After a great deal of work and some assistance from an Actel rep > I still wasn't able to get the design working in the ProAsic3, > I had naievly presumed the performance would be roughly similar > to the Altera/Xilinx parts. My get out was that my client had > chosen the part. > > They're great for what they do well but just be wary if you need > to push the performance (at all). > > Nial. Igloo is slow, that's true, but ProAsic3 should be able to handle 66 Mhz. My current ProAsic3 is running at 160 Mhz, using vanilla vhdl. No special constraints or manually placed logic blocks were needed other than specifying clock speed.Article: 137440
"Matthias Alles" <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de> wrote in message news:gkpdq5$f02$1@news.uni-kl.de... > > The voltage counts quadratic for the power consumption. So a difference > from 1.8V to 1.2V results in a power reduction by a factor of 2.25 and > not 1.5! > > Matthias Good point!Article: 137441
"Andreas Ehliar": > Is anyone aware of a newer comparison than this one? Not me. But what I know is, that manual floorplanning can also affect the type of logic inferred, not only the routing. So you'll need to be more specific about if your question relates to eaxcat, similar or diffrent types of inferred logic. Since your post is mainly focussing on routing, I'd expect you're interested in exact or similar logic types. As a lesser experienced FPGA user, I'd expect a manually floorplanned version to perform at most noticaeble better than an automatically generated version (please someone correct me). On the other hand, the type of logic resources used makes up a heavy difference, no matter if you're mainly focussed on area or speed. So maybe better don't even mind the theoretical option to manually take care about where exactly any of the individual signals might go (in addition to care about some few important signals), and just remember that each device family always comes with a huge set of undocumented details about routing options (and even if you just focus on documented details, you'll notice that absoulte placement heavily affects local routing within real devices; just try to get an impression of how long shortest paths between to given points look like...). That's not what people normally mean when saying "RLOC". Gruss Jan BrunsArticle: 137442
"Jan Bruns" <testzugang_janbruns@arcor.de> wrote:
>
>"Andreas Ehliar":
>> Is anyone aware of a newer comparison than this one?
>
>Not me.
>
>But what I know is, that manual floorplanning can also affect
>the type of logic inferred, not only the routing. So you'll
>need to be more specific about if your question relates to
>eaxcat, similar or diffrent types of inferred logic.
>
>Since your post is mainly focussing on routing, I'd expect
>you're interested in exact or similar logic types. As a
>lesser experienced FPGA user, I'd expect a manually
>floorplanned version to perform at most noticaeble better
>than an automatically generated version (please someone
>correct me).
I think this is true if you hand-route an entire design that has to be
fast. That would take an enormous amount of time...
I like to think at it like mixing C and assembly. C compilers are very
good these days and generally will produce code you can't get to run
faster using assembly. Assembly however may give you access to special
DSP style instructions which are not supported by the C compilers.
Even though you may have expert assembly skill, the resulting program
may be slower because the C compiler can't fully optimize because of
your code.
I've experienced this with FPGA designs as well. I've used Xilinx's
Picoblaze several times. This is a piece of logic which has quite a
bit of RLOCs however, disabling the RLOCs usually results in designs
that meet there timing specifications. Why? The placer can break the
picoblaze into pieces and optimize it together with the rest of the
logic.
Moral: Optimizers are very powerful tools and have a large window to
look at your design. Its better to try and figure out how to get the
optimizer to work better than to try to outsmart the optimizer.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 137443On Jan 16, 1:03=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > On Jan 14, 9:47=A0pm, sreenivas.jyo...@gmail.com wrote: > > > > > On Dec 15 2008, 11:39=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > > > > In a conventional design (single clock, distributed over global clock > > > nets, all flip-flops triggered on the same, usually rising, clock > > > edge, clock frequency not at the max data-sheet limit)dutycycleis irr= elevant, as long as you do not violate any clock-High > > > or clock-Low timing. > > > More exotic designs that use both clock edges or use latches instead > > > of flip-flops, are (or might be) sensitive to clockdutycycle. > > > Distributing clocks on non-global lines can seriously affectdutycycle= , and also cause uncontrolled clock skew and other bad problems. > > > Don't do that! > > > Peter Alfke > > > Hi peter, > > thanks for your response, i am still not configuring my doubt on this > > (duty Cycle). > > Here is my clear query: I have requirement saying that "The test case > > is to test the output signal rcom_tx when fpga_clk is 50 MHz with 40% > > and 60% duty cycles", and before that i had a test case for same > > signals on 50% duty cycle. so when i did test on 50% duty cycle i got > > normal results without any problems, and i am not able to figure out > > if i change to 40% and 60% duty cycles than what to expect on output > > line. > > > As of my knowledge within duty cycle boundary limit the output doesn't > > affect, but out of boundary change in duty cycle is the only > > expectancy. > > If possible could you please give me any example in explaining this > > concept. > > > Thanks > > 50% duty cycle at 50 MHz means 10 ns High followed by 10 ns Low. > If you use global clock distribution, there will be no difference > whatsoever in the register outputs if you vary the 10 ns to 8 or 12 > ns. > Try to understand the operation of clocked D-flip-flops, and you will > agree. > Peter Alfke O.K., but it was you and not the OP who inferred that all flip-flops are using the same clock edge. Clearly there would be effect on the period where signals are used on opposite edges of the clock.Article: 137444
"Nico Coesel": > Moral: Optimizers are very powerful tools and have a large window to > look at your design. Its better to try and figure out how to get the > optimizer to work better than to try to outsmart the optimizer. On the other hand, tools have no intelligence. They're normally even to stupid to let the user decide about design gloals that otherwise need to be "guessed". For example, "area vs. speed" is still a global switch in ise-xst, wheres you'd naturally assign diffrent goals to parts of a module. If there's viable way to tell a tool about what you want, don't expect it to do what you want. This leads me to the point I disagree: It's not always wise to minimize only "software" development effort, since this often means much more of work on a other areas. For example, if you decide to not do some "free" 50% area-saving manual optimization for a specific FPGA-product, you might save some weeks of development by "just buying a better device", but the marketing people might then have to shout much louder, making it difficult for you to focus on the next thing to do. Gruss Jan BrunsArticle: 137445
On Jan 16, 1:34=A0pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "aleksa" <aleks...@gmail.com> wrote in message
>
> news:68552330-6502-40da-9d6a-31e17040bb0c@v4g2000yqa.googlegroups.com...>=
And here is my last attempt:
>
> Giving up already?
>
>
>
> > TIMER : process (CLKMAIN)
> > begin
> > =A0 =A0if falling_edge(CLKMAIN) then
>
> There is no reason to be using falling edge here. =A0Synchronous design
> practice uses rising edge. =A0Other than that there are no obvious proble=
ms
> with the timer process.
>
>
>
> > IRQFLAGS : process (CLKMAIN, RD, ADDR)
> > begin
> > =A0 =A0if RD=3D'0' and ADDR=3DADRA then
> > =A0 =A0 =A0 =A0fIRQA <=3D '0';
> > =A0 =A0elsif rising_edge(CLKMAIN) and cIRQA=3D'0' then
>
> And here is your problem. =A0You're using RD and ADDR asynchronously. =A0=
Now ask
> yourself what happens if the condition "RD=3D'0' and ADDR=3DADRA " goes *=
away*
> just prior to the rising edge of CLKMAIN? =A0The result will be a timing
> problem on signal fIRQA which means that this process can end up setting
> fIRQA to 1. =A0The other problem is that the async reset of fIRQA can scr=
ew up
> the timing to anything that *uses* fIRQA. =A0The solution as has been poi=
nted
> out already is to:
> 1. synchronize RD and ADDR before using.
> 2. Don't use "RD=3D'0' and ADDR=3DADRA " to asynchronously reset fIRQA. =
=A0In
> fact, don't use asynchronous resets at all...ever (almost ever).
> 3. Perform static timing analysis
>
>
>
> > IRQPROC : process (CLKMAIN) begin
> > =A0 =A0if falling_edge(CLKMAIN) then
> > =A0 =A0 =A0 =A0fIRQANY <=3D fIRQA or fIRQB or fIRQC;
>
> Again, synchronous design practice has no use for falling edge triggered
> logic, use the rising edge instead. =A0Other than that, there doesn't see=
m to
> be any problems with the irqproc process...however the inputs to the proc=
ess
> have not been synchronized to the clock because fIRQA is not synchronous =
due
> to your use of the async reset in the previous process.
>
> > Anyone see a reason why this should not work?
>
> Yes
>
> Kevin Jennings
Ok, I did a bit of reading,
and this is what I came up with.
(this is similar to one of my prev posts,
but the IRQPROC is simpler and there
are two FF for synchronizing ACK flag)
Is now everything ok?
TIMER : process (cCLKMAIN) begin
if rising_edge(cCLKMAIN) then
if counterA=3D0 then
cIRQA <=3D not cIRQA;
counterA <=3D reloadA;
else
counterA <=3D counterA -1;
end if;
end if;
end process TIMER;
IRQFLAGS : process (cCLKMAIN, RD) begin
if rising_edge(RD) and ADDR=3DADRA then
aIRQA0 <=3D not aIRQA0;
end if;
if rising_edge(cCLKMAIN) then
aIRQA1 <=3D aIRQA0;
aIRQA <=3D aIRQA1;
if cIRQA /=3D aIRQA then fIRQA <=3D '1'; else fIRQA <=3D '0'; end
if;
end if;
end process IRQFLAGS;
IRQPROC : process (cCLKMAIN) begin
if rising_edge(cCLKMAIN) then
fIRQANY <=3D fIRQA or fIRQB or fIRQC;
if fIRQANY=3D'1' then
IRQ <=3D '1';
else
IRQ <=3D '0';
end if;
end if;
end process IRQPROC;
Article: 137446On Jan 16, 11:47=A0am, Gabor <ga...@alacron.com> wrote: > On Jan 16, 1:03=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > > > > > On Jan 14, 9:47=A0pm, sreenivas.jyo...@gmail.com wrote: > > > > On Dec 15 2008, 11:39=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > > > > > In a conventional design (single clock, distributed over global clo= ck > > > > nets, all flip-flops triggered on the same, usually rising, clock > > > > edge, clock frequency not at the max data-sheet limit)dutycycleis i= rrelevant, as long as you do not violate any clock-High > > > > or clock-Low timing. > > > > More exotic designs that use both clock edges or use latches instea= d > > > > of flip-flops, are (or might be) sensitive to clockdutycycle. > > > > Distributing clocks on non-global lines can seriously affectdutycyc= le, and also cause uncontrolled clock skew and other bad problems. > > > > Don't do that! > > > > Peter Alfke > > > > Hi peter, > > > thanks for your response, i am still not configuring my doubt on this > > > (duty Cycle). > > > Here is my clear query: I have requirement saying that "The test case > > > is to test the output signal rcom_tx when fpga_clk is 50 MHz with 40% > > > and 60% duty cycles", and before that i had a test case for same > > > signals on 50% duty cycle. so when i did test on 50% duty cycle i got > > > normal results without any problems, and i am not able to figure out > > > if i change to 40% and 60% duty cycles than what to expect on output > > > line. > > > > As of my knowledge within duty cycle boundary limit the output doesn'= t > > > affect, but out of boundary change in duty cycle is the only > > > expectancy. > > > If possible could you please give me any example in explaining this > > > concept. > > > > Thanks > > > 50% duty cycle at 50 MHz means 10 ns High followed by 10 ns Low. > > If you use global clock distribution, there will be no difference > > whatsoever in the register outputs if you vary the 10 ns to 8 or 12 > > ns. > > Try to understand the operation of clocked D-flip-flops, and you will > > agree. > > Peter Alfke > > O.K., but it was you and not the OP who inferred that > all flip-flops are using the same clock edge. =A0Clearly there > would be effect on the period where signals are used on opposite > edges of the clock. This is a basic discussion, and a basic design would hardly ever use both clock edges, unless there were an exotic reason. (Excessive clock delays might be one). Peter AlfkeArticle: 137447
aleksa wrote:
> Is now everything ok?
NO.
Reread the previous posts
"And here is your problem. You're using RD and ADDR asynchronously."
"_DON'T_USE_THE_RD_SIGNAL_AS_AN_ASYNCHRONOUS_SIGNAL_"
> IRQFLAGS : process (cCLKMAIN, RD) begin
RD is not a clock.
RD is a plain input.
cCLKMAIN is the only clock.
to detect a 0, 1 sequence on RD, use a shift register on cCLKMAIN
Good night and good luck.
-- Mike Treseler
Article: 137448Peter Alfke <peter@xilinx.com> wrote: (snip) > This is a basic discussion, and a basic design would hardly ever use > both clock edges, unless there were an exotic reason. (Excessive clock > delays might be one). Well, how about DDR RAM? I now have a Spartan 3E starter kit with DDR RAM on board, though for the designs I have in mind more ordinary RAM would have been my first choice. Most likely I don't actually need the high rate and will only use one edge, if that is possible. It would be nice to have a simple design that would drive the DDR, though. -- glenArticle: 137449
Hi, I'm on a design that requires 2 fast ADC (14bit 100Ms/s) and an FPGA. So far all all plans were based on parallel data to the FPGA, but I must confess these new serial ADC's are tempting specially the ADS6244 that fits perfectly with my intentions. (2ch 14bit 125Ms/s in a single package and a few lvds lines only interfacing the FPGA) But I fear the interfacing to an ALtera CycloneIII. The required will be; serial data at 700Mb/s and serial clock at 350MHz (DDR) I would certainly be confident with one of the high end FPGA's but I can't use anything except the low cost ones ;-) I have no problem in doing a proper layout with all cares about line length and impedances but... Is that what it takes and the rest is easy enough ? I do fear input and inside the FPGA... too marginal for a CycloneIII to do ?.... is it too hard/difficult ? does a shift register and word transfer register design described in VHDL, suffice for the input deserializer or something fancier is needed ? Or in the end... Will I be better off with parallel bus ADC's ? I'm having trouble to decide myself... I'll be very happy to hear some comments please. Thanks. Luis C.
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