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
<moogyd@yahoo.co.uk> wrote in message news:1187414658.093964.216970@k79g2000hse.googlegroups.com... > Hello group, > > The question is : How do I constrain the frequency f/2, f/4 etc. The > synthesis tool optimizes nets clk_div2, clk_div4 so that only one net > exists (clk), so I have no where to put the constraints (or do select > all endpoints). > > (I currently add constraints via the UCF). > > Any suggestions or pointers grreatly appreciated. > > Thanks, > > Steven > Hi Steven, OK, your system sounds like you have one clock, witth clock enables for the slower bits. That's a good thing. So, you constraints should be something like this. NET "clock_div_2_enable*" TNM="slow_ffs"; TIMESPEC TS1 = FROM : slow_ffs : TO : slow_ffs : 20ns; I added a wildcard at the end of the clock enable signal because often the synthesis tool will duplicate nets that go to a lot of desitinations. This will hopefully catch that situation. Also, be careful not to generate the enable signal by feeding it back to itself, or the tool will include the FF used to make the enable in the timegroup. You don't want that as the enable has to get to every destination in the time determined by the clock period, not the relaxed multi-path delay. For example, have a counter and use it to generate the enables. HTH., Syms. p.s. Here's a freebie puzzle I remembered while typing this. What's the only word that's an anagram of itself?Article: 123176
i have a posted for a camera and i was suggesed the following. it is 1/3 Color Camera Mod C3188A-6018 Digital output.i am attaching its datasheet.(http://www.electronics123.net/amazon/datasheet/c3188a.pdf). i have a problem in knowing what its ports are from its data sheet.can anyone help me out in telling me what the ports 1.1~8 Y0~Y7 Digital output Y Bus 23~30 UV0-UV7 Digital output UV bus. are. the description in the datasheet is too vague for me to program them. can anyone altest send me a link for their description.Article: 123177
sriman wrote: > i have a posted for a camera and i was suggesed the following. it is > 1/3 Color Camera Mod C3188A-6018 Digital output.i am attaching its > datasheet.(http://www.electronics123.net/amazon/datasheet/c3188a.pdf). > i have a problem in knowing what its ports are from its data sheet.can > anyone help me out in telling me what the ports > 1.1~8 Y0~Y7 Digital output Y Bus > 23~30 UV0-UV7 Digital output UV bus. > are. the description in the datasheet is too vague for me to program > them. can anyone altest send me a link for their description. > Sometimes I find it amazing. Google is your friend. ( for the 1,000,000th time ) You would have a real data sheet if you even tried. ( first hit on a google search) http://mxhaard.free.fr/spca50x/Doc/Omnivision/OV7620.pdf Good luck You'll need it. donaldArticle: 123178
Hello Ben, I'm trying to build a standalone DDR2 SODIMM interface for ML505 evaluation board. I noticed that you've done a similar work recently and wonder if you could share your experiences with me. As you know, the current release of MIG 1.73 does not support DDR2 SODIMM for Virtex-5 yet. So what is your approach to build the memory interface for your ML501 board? Could you give me some suggestions on possible issues I'm going to encounter in this design? Thanks a lot! Best regards CarsonArticle: 123179
Hello I decided to make my own DDR controller. I want to do this on CycloneII or Spartan-3 I'm not decided yet. That's way I want to ask the quastion: Which of this device familly has better features to design a DDR controller core. That what I know now: Altera Cyclone2: - PLL - Clock Delay Control Circuitry for DQS signal - it's look interesting - altdq and altdqs megafunctions to implement output and input logic - Series On-Chip Termination Xilinx Spartan3: - DCM - Programmable Delay on each input pin. - How it's work? How to use it? - IFDDRxxx and OFDDRxxx components implement output and input logic - Digitally Controlled Impedance (DCI) - but require some pins: VREN, VREP Which features more could be helpful? PGWArticle: 123180
On Jul 29, 5:43 am, charon <mega_me...@gmx.de> wrote: > Well, my mother tongue is "de_DE.UTF-8@euro", at least this is what > $LANGUAGE is set to. I get warnings in all Xilinx tools because of > that. > The problem is that the EDK generates a Makefile that sets LANGUAGE to > vhdl. The other tools seem to rely on this. > When I modify it and set the LANGUAGE to an empty string I don't get > these warnings anymore. When I do not touch LANGUAGE I get thousands > of warnings with de_DE.UTF-8@euro not supported. > BTW the Makefile says it is generated each time so it makes no sense > to edit it. So this really isn't a solution. Even if I would set my > $LANGUAGE to usenglish the Makefile would override it with vhdl..... > If the language in the project preferences is set to verilog it is the > same. Arfff... > > Matthias > > On 29 Jul., 09:08, Antti <Antti.Luk...@googlemail.com> wrote: > > > On 28 Jul., 21:55, charon <mega_me...@gmx.de> wrote: > > > > Hi! > > > > I recently installed EDK 9,1.02i. When I synthesize a project I get > > > thousand of warnings, which is really annoying: > > > > WARNING: vhdl is not supported as a language. Using usenglish. > > > > Reading the real information becomes almost impossible. What can I do > > > to circumvent this? > > > > Thanks! > > > Matthias > > > this is hilarious - is your mother tonque really VHDL ? > > it looks like ISE wants you to use US English instead of VHDL? > > maybe you speak oxford english, and that upsets it.. > > > sorry, no idea whats wrong, but its just another example of how xilinx > > understand > > "software testing..." (lets leave it to our customers...) > > > Antti I've experienced the same problem on my lab machine running Debian Linux 2.6.15 and EDK 9.1.02i. When I ssh into another lab machine running 2.6.18 Linux, the number of usenglish warnings is reduced to normal. Could be that some other settings on that machine affect how EDK runs, though. Hopefully that might help in some way. ----JD----Article: 123181
pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: >Hello > >I decided to make my own DDR controller. I want to do this on CycloneII or >Spartan-3 I'm not decided yet. That's way I want to ask the quastion: > >Which of this device familly has better features to design a DDR controller >core. > >That what I know now: > >Altera Cyclone2: > >- PLL >- Clock Delay Control Circuitry for DQS signal - it's look interesting >- altdq and altdqs megafunctions to implement output and input logic >- Series On-Chip Termination > >Xilinx Spartan3: > >- DCM A normal and 90 degrees phase shifted clock are all that is required to clock a DDR controller. >- Programmable Delay on each input pin. - How it's work? How to use it? Not necessary for DDR (should be left disabled) >- IFDDRxxx and OFDDRxxx components implement output and input logic Yes, These are very necessary. Clock the signals as close to the IO pin as possible. The setup and hold times will vary more as the amount of logic increases which is something you don't want. >- Digitally Controlled Impedance (DCI) - but require some pins: VREN, >VREP Useless. It will make the chip run very hot especially with many lines connected. Use series resistors on the board. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 123182
On Aug 18, 12:55 pm, n...@puntnl.niks (Nico Coesel) wrote: > pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: > >Hello > > >I decided to make my own DDR controller. I want to do this on CycloneII or > >Spartan-3 I'm not decided yet. That's way I want to ask the quastion: > > >Which of this device familly has better features to design a DDR controller > >core. > > >That what I know now: > > >Altera Cyclone2: > > >- PLL > >- Clock Delay Control Circuitry for DQS signal - it's look interesting > >- altdq and altdqs megafunctions to implement output and input logic > >- Series On-Chip Termination > > >Xilinx Spartan3: > > >- DCM > > A normal and 90 degrees phase shifted clock are all that is required > to clock a DDR controller. > > >- Programmable Delay on each input pin. - How it's work? How to use it? > > Not necessary for DDR (should be left disabled) > > >- IFDDRxxx and OFDDRxxx components implement output and input logic > It is a common misconception that DCI (on-chip termination) causes the chip to run hot. When used as serial (output) termination, the on-chip heat generated by DCI is insignificant. When used as parallel (input) Thevenin termination, the heat indeed is substantial. But an external series resistor is not the alternative to the parallel case... Peter Alfke > Yes, These are very necessary. Clock the signals as close to the IO > pin as possible. The setup and hold times will vary more as the amount > of logic increases which is something you don't want. > > >- Digitally Controlled Impedance (DCI) - but require some pins: VREN, > >VREP > > Useless. It will make the chip run very hot especially with many lines > connected. Use series resistors on the board. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U opwww.adresboekje.nlArticle: 123183
Peter Alfke wrote: >>>- Digitally Controlled Impedance (DCI) - but require some pins: VREN, >>>VREP >> >> Useless. It will make the chip run very hot especially with many lines >> connected. Use series resistors on the board. > It is a common misconception that DCI (on-chip termination) causes the > chip to run hot. > When used as serial (output) termination, the on-chip heat generated > by DCI is insignificant. > When used as parallel (input) Thevenin termination, the heat indeed is > substantial. > But an external series resistor is not the alternative to the parallel > case... > Peter Alfke Also the best way is to use a SSTL2_II (without DCI) iostandard with output driver impedance 25Ohm and external parallel resistor? PGWArticle: 123184
Peter Alfke <alfke@sbcglobal.net> wrote: >On Aug 18, 12:55 pm, n...@puntnl.niks (Nico Coesel) wrote: >> pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: >> >Hello >> >> >I decided to make my own DDR controller. I want to do this on CycloneII or >> >Spartan-3 I'm not decided yet. That's way I want to ask the quastion: >> >> >Which of this device familly has better features to design a DDR controller >> >core. >> >> >That what I know now: >> >> >Altera Cyclone2: >> >> >- PLL >> >- Clock Delay Control Circuitry for DQS signal - it's look interesting >> >- altdq and altdqs megafunctions to implement output and input logic >> >- Series On-Chip Termination >> >> >Xilinx Spartan3: >> >> >- DCM >> >> A normal and 90 degrees phase shifted clock are all that is required >> to clock a DDR controller. >> >> >- Programmable Delay on each input pin. - How it's work? How to use it? >> >> Not necessary for DDR (should be left disabled) >> >> >- IFDDRxxx and OFDDRxxx components implement output and input logic >> >It is a common misconception that DCI (on-chip termination) causes the >chip to run hot. >When used as serial (output) termination, the on-chip heat generated >by DCI is insignificant. >When used as parallel (input) Thevenin termination, the heat indeed is >substantial. I agree, but parallel termination is the only option for SSTL-II outputs. So if you want to connect a 32 bit wide DDR memory to a Spartan 3 device (like I did), DCI is not going to work. >But an external series resistor is not the alternative to the parallel >case... The Spartan 3 ain't that fast. I know the I/O pins are specified to be able to run at 300MHz or so, but the internal logic won't allow that speed anyway in practical situations. I estimate the real life upper limit is about 150MHz. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 123185
Nico Coesel wrote: >>- Digitally Controlled Impedance (DCI) - but require some pins: VREN, >>VREP > > Useless. It will make the chip run very hot especially with many lines > connected. Use series resistors on the board. Output pin in SSTL2_II IOSTANDARD has output driver impedance 25 Ohms is that not suffiecient? Additionally an external parallel 50 Ohms resistor connect to Vtt and output and input termination is done, I think. -- PGWArticle: 123186
Hello,
To summarize the issue briefly: I have a group of flip-flops which
toggle every 4 clocks by using an "clock enable" signal, but I can't
define a multipath constraint according to this signal. That is, I can
do it, but I silently create timing violations.
The following bare-bone example illustrates the problem:
module top(clk, cnt);
input clk;
output [15:0] cnt;
reg [15:0] cnt;
reg [1:0] en_counter;
reg en;
always @(posedge clk)
begin
en_counter <= en_counter + 1;
en <= (en_counter == 0);
end
always @(posedge clk)
if (en) // This is the "clock enable"
begin
// This runs only once in four clocks
if (cnt != 16'hffff)
cnt <= cnt + 1;
end
endmodule
So here we have "en" high every 4 clocks. We use it as the "clock
enable" in the second "always" clause. I don't think I can hint the
synthesizer more clearly that I want a clock enable.
So this is what my UCF would look like (bare-bone again):
NET "clk" TNM_NET = "clk";
TIMESPEC "ts_clk" = PERIOD "clk" 10 ns HIGH 50 %;
NET "en" TNM = "tgrp_en";
TIMESPEC "ts_multipath" = FROM "tgrp_en" TO "tgrp_en" "TS_clk" * 4;
The "ts_multipath" says that any path going from "tgrp_en" to
"tgrp_en" can be relaxed to 4 clocks. "tgrp_en" is effectively all
flip-flops to which the signal reaches. In our case, it's cnt[15:0].
And here comes the catch: The synthesizer recognized that cnt[15:0]
should be incremented if and only if two conditions are met: "en" is
high and (cnt != 16'hffff). So it picked the simplest solution: 16 D-
flip-flops, whose inputs are (cnt+1), and their clock enable (CE) is
the increment condition just described.
This is all nice, but now we have a path from cnt[15:0] (a.k.a.
"tgrp_en") to itself, which has to be finished in one single clock:
>From the values of cnt[15:0], through the logic which does cnt!
=16'hffff, and back to the flip-flops' CE. After all, the CE must meet
timing for every clock. On the other hand, the multi-path constraint
allows 4 clocks for this path.
So by making this multi-path constraint, we've actually allowed a
timing violation. The core of the problem is the assumption that "en"
reaches its flip-flops only as clock enable. The reality is that NET/
TNM grouping constraints (and NET/TNM_NET as well) starts at the given
net ("en" in our case) and includes any flip-flop which is driven by
it, even if it's trough some logic.
So now what? How can I find a rule for grouping multi-path flip-flops?
Is there any way to group the flip-flops to which "en" is connected
directly? Or even better, can I require that the net reaches a certain
pin (CE, in our case)?
Or, is there any way to tell the synthesizer (XST in particular) that
"en" should be used as clock enable only, and not make any logic
tricks with it?
Thanks in advance,
Eli
Article: 123187"davide" <davide@xilinx.com> wrote in message news:fa2j1c$g1r2@cnn.xilinx.com... > Symon, > > I believe that DRP can only change the attributes for phase shift, M and D > values of the DCM. Not CLKDV values. > > -David > Hi David, Yeah, looks like you're right. I might try some addresses when I get chance, if I find anythign I'll report back... Cheers, Syms.Article: 123188
Nico Coesel wrote: > pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: > >> Hello >> >> I decided to make my own DDR controller. I want to do this on CycloneII or >> Spartan-3 I'm not decided yet. That's way I want to ask the quastion: >> >> Which of this device familly has better features to design a DDR controller >> core. >> >> That what I know now: >> >> Altera Cyclone2: >> >> - PLL >> - Clock Delay Control Circuitry for DQS signal - it's look interesting >> - altdq and altdqs megafunctions to implement output and input logic >> - Series On-Chip Termination >> >> Xilinx Spartan3: >> >> - DCM > > A normal and 90 degrees phase shifted clock are all that is required > to clock a DDR controller. For the perfect (or close to it) case. A practical DDR controller running at 200/400 or greater benefits greatly from having the ability to add/subtract a small delay around the 90 degrees. Whether the delay is useful depends on the application. > >> - Programmable Delay on each input pin. - How it's work? How to use it? > > Not necessary for DDR (should be left disabled) See above. > >> - IFDDRxxx and OFDDRxxx components implement output and input logic > > Yes, These are very necessary. Clock the signals as close to the IO > pin as possible. The setup and hold times will vary more as the amount > of logic increases which is something you don't want. > >> - Digitally Controlled Impedance (DCI) - but require some pins: VREN, >> VREP > > Useless. It will make the chip run very hot especially with many lines > connected. Use series resistors on the board. Agreed, but DDR should have a known impedance at the driver and receiver, which I believe the SSTL (II) IO standard provides. >Article: 123189
Peter Alfke wrote: > On Aug 18, 12:55 pm, n...@puntnl.niks (Nico Coesel) wrote: >> pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: >>> Hello >>> I decided to make my own DDR controller. I want to do this on CycloneII or >>> Spartan-3 I'm not decided yet. That's way I want to ask the quastion: >>> Which of this device familly has better features to design a DDR controller >>> core. >>> That what I know now: >>> Altera Cyclone2: >>> - PLL >>> - Clock Delay Control Circuitry for DQS signal - it's look interesting >>> - altdq and altdqs megafunctions to implement output and input logic >>> - Series On-Chip Termination >>> Xilinx Spartan3: >>> - DCM >> A normal and 90 degrees phase shifted clock are all that is required >> to clock a DDR controller. >> >>> - Programmable Delay on each input pin. - How it's work? How to use it? >> Not necessary for DDR (should be left disabled) >> >>> - IFDDRxxx and OFDDRxxx components implement output and input logic > It is a common misconception that DCI (on-chip termination) causes the > chip to run hot. > When used as serial (output) termination, the on-chip heat generated > by DCI is insignificant. > When used as parallel (input) Thevenin termination, the heat indeed is > substantial. > But an external series resistor is not the alternative to the parallel > case... It is not always necessary to parallel terminate data lines in DDR. If the system is point to point (only one bank physically) it's perfectly possible to series terminate the line with a little homework. Parallel termination is not an option for address and control, however. Cheers PeteS > Peter Alfke > >> Yes, These are very necessary. Clock the signals as close to the IO >> pin as possible. The setup and hold times will vary more as the amount >> of logic increases which is something you don't want. >> >>> - Digitally Controlled Impedance (DCI) - but require some pins: VREN, >>> VREP >> Useless. It will make the chip run very hot especially with many lines >> connected. Use series resistors on the board. >> >> -- >> Reply to nico@nctdevpuntnl (punt=.) >> Bedrijven en winkels vindt U opwww.adresboekje.nl > >Article: 123190
eli.billauer@gmail.com wrote:
> To summarize the issue briefly: I have a group of flip-flops which
> toggle every 4 clocks by using an "clock enable" signal, but I can't
> define a multipath constraint according to this signal.
The "en" signal is a synchronous input
to the second block. It is not a clock
and does not need any constraint other
than the Fmax for "clk".
Here's a related example using a single block:
http://home.comcast.net/~mike_treseler/count_enable.v
-- Mike Treseler
Article: 123191
[1] There are lots of ways to define a Time group, and yours is too
inclusive.
Here are some multipath constraints I use for similar problem :
INST "u_tcg_sys_timers/tcg_year_*" TNM="SYSTIMER_1_PER_SEC";
INST "u_tcg_sys_timers/tcg_doy_*" TNM="SYSTIMER_1_PER_SEC";
INST "u_tcg_sys_timers/tcg_hrs_*" TNM="SYSTIMER_1_PER_SEC";
INST "u_tcg_sys_timers/tcg_min_*" TNM="SYSTIMER_1_PER_SEC";
INST "u_tcg_sys_timers/tcg_sec_*" TNM="SYSTIMER_1_PER_SEC";
TIMESPEC "TS_IGNORE_1_PER_SEC" = FROM "SYSTIMER_1_PER_SEC" TO
"SYSTIMER_1_PER_SEC" 18.0;
[2] In future, if you have a prefix on signal names that you
know will be a multipath source/destination, it will be easier,
in large designs to use wildcards for inclusion in group.
[3] Take a look at
xilinx/doc/usenglish/docs/cgd/cgd.pdf for good reference
on constraint usage. Or open the constraint editor, and
experiment with applying constraints ... check the results
in .ucf file for syntax. I personally don't use constraint editor
for final changes, because I don't like the tools mucking with
my .ucf file.
--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
Colorado Based Xilinx Consultant
email : jretta@rtc-inc.com
web : www.rtc-inc.com
<eli.billauer@gmail.com> wrote in message
news:1187532611.606163.221620@o80g2000hse.googlegroups.com...
> Hello,
>
> To summarize the issue briefly: I have a group of flip-flops which
> toggle every 4 clocks by using an "clock enable" signal, but I can't
> define a multipath constraint according to this signal. That is, I can
> do it, but I silently create timing violations.
>
> The following bare-bone example illustrates the problem:
>
> module top(clk, cnt);
>
> input clk;
> output [15:0] cnt;
>
> reg [15:0] cnt;
> reg [1:0] en_counter;
> reg en;
>
> always @(posedge clk)
> begin
> en_counter <= en_counter + 1;
> en <= (en_counter == 0);
> end
>
> always @(posedge clk)
> if (en) // This is the "clock enable"
> begin
> // This runs only once in four clocks
> if (cnt != 16'hffff)
> cnt <= cnt + 1;
> end
>
> endmodule
>
> So here we have "en" high every 4 clocks. We use it as the "clock
> enable" in the second "always" clause. I don't think I can hint the
> synthesizer more clearly that I want a clock enable.
>
> So this is what my UCF would look like (bare-bone again):
>
> NET "clk" TNM_NET = "clk";
> TIMESPEC "ts_clk" = PERIOD "clk" 10 ns HIGH 50 %;
> NET "en" TNM = "tgrp_en";
> TIMESPEC "ts_multipath" = FROM "tgrp_en" TO "tgrp_en" "TS_clk" * 4;
>
> The "ts_multipath" says that any path going from "tgrp_en" to
> "tgrp_en" can be relaxed to 4 clocks. "tgrp_en" is effectively all
> flip-flops to which the signal reaches. In our case, it's cnt[15:0].
>
> And here comes the catch: The synthesizer recognized that cnt[15:0]
> should be incremented if and only if two conditions are met: "en" is
> high and (cnt != 16'hffff). So it picked the simplest solution: 16 D-
> flip-flops, whose inputs are (cnt+1), and their clock enable (CE) is
> the increment condition just described.
>
> This is all nice, but now we have a path from cnt[15:0] (a.k.a.
> "tgrp_en") to itself, which has to be finished in one single clock:
>>From the values of cnt[15:0], through the logic which does cnt!
> =16'hffff, and back to the flip-flops' CE. After all, the CE must meet
> timing for every clock. On the other hand, the multi-path constraint
> allows 4 clocks for this path.
>
> So by making this multi-path constraint, we've actually allowed a
> timing violation. The core of the problem is the assumption that "en"
> reaches its flip-flops only as clock enable. The reality is that NET/
> TNM grouping constraints (and NET/TNM_NET as well) starts at the given
> net ("en" in our case) and includes any flip-flop which is driven by
> it, even if it's trough some logic.
>
> So now what? How can I find a rule for grouping multi-path flip-flops?
> Is there any way to group the flip-flops to which "en" is connected
> directly? Or even better, can I require that the net reaches a certain
> pin (CE, in our case)?
>
> Or, is there any way to tell the synthesizer (XST in particular) that
> "en" should be used as clock enable only, and not make any logic
> tricks with it?
>
> Thanks in advance,
> Eli
>
Article: 123192On Aug 19, 11:15 am, PeteS <axk...@dsl.pipex.com> wrote: > Nico Coesel wrote: > > pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: > > >> Hello > > >> I decided to make my own DDR controller. I want to do this on CycloneII or > >> Spartan-3 I'm not decided yet. That's way I want to ask the quastion: > > >> Which of this device familly has better features to design a DDR controller > >> core. > > >> That what I know now: > > >> Altera Cyclone2: > > >> - PLL > >> - Clock Delay Control Circuitry for DQS signal - it's look interesting > >> - altdq and altdqs megafunctions to implement output and input logic > >> - Series On-Chip Termination > > >> Xilinx Spartan3: > > >> - DCM > > > A normal and 90 degrees phase shifted clock are all that is required > > to clock a DDR controller. > > For the perfect (or close to it) case. A practical DDR controller > running at 200/400 or greater benefits greatly from having the ability > to add/subtract a small delay around the 90 degrees. Whether the delay > is useful depends on the application. > > > > > > >> - Programmable Delay on each input pin. - How it's work? How to use it? > > > Not necessary for DDR (should be left disabled) > See above. > > >> - IFDDRxxx and OFDDRxxx components implement output and input logic > > > Yes, These are very necessary. Clock the signals as close to the IO > > pin as possible. The setup and hold times will vary more as the amount > > of logic increases which is something you don't want. > > >> - Digitally Controlled Impedance (DCI) - but require some pins: VREN, > >> VREP > > > Useless. It will make the chip run very hot especially with many lines > > connected. Use series resistors on the board. > > Agreed, but DDR should have a known impedance at the driver and > receiver, which I believe the SSTL (II) IO standard provides. > > I recently removed the series and parallel terminations from a Cyclone 3 dev board and ran the ddr interface at 133MHz. The interface worked overnight without a problem. I think the trace length on the ddr signals is about 2-3 inches. They are point-to-point signals. The data bus is 16bits wide and is implemented using Altera's ALTMEMPHY megafunction. Further, I momentarily cooled down the memory and altera chips to -40degC and then heated them up to 125degC without any errors. I see that without the series terminations there is a problem on the overshoot and undershoot. But it does not violate the specs of the fpga. On the memory side, the problem goes away when I use onchip series termination.Article: 123193
Andreas Schwarz wrote: > On 14 Aug., 03:52, David Bishop <dbis...@vhdl.org> wrote: >> Xilinx said that they were going to fix this in 9.3. I have not had a >> chance to check it out yet, but I would try that first. > > Thanks for the info. 9.3 isn't released yet, do you have any idea when > it will be? I'd use Synplicity. I've been using 8.803 with these packages.Article: 123194
On Sun, 19 Aug 2007 07:10:11 -0700, eli.billauer@gmail.com wrote: >Hello, > >To summarize the issue briefly: I have a group of flip-flops which >toggle every 4 clocks by using an "clock enable" signal, but I can't >define a multipath constraint according to this signal. That is, I can >do it, but I silently create timing violations. > >The following bare-bone example illustrates the problem: > >module top(clk, cnt); > > input clk; > output [15:0] cnt; > > reg [15:0] cnt; > reg [1:0] en_counter; > reg en; > > always @(posedge clk) > begin > en_counter <= en_counter + 1; > en <= (en_counter == 0); > end > > always @(posedge clk) > if (en) // This is the "clock enable" > begin > // This runs only once in four clocks > if (cnt != 16'hffff) > cnt <= cnt + 1; > end > >endmodule > >So here we have "en" high every 4 clocks. We use it as the "clock >enable" in the second "always" clause. I don't think I can hint the >synthesizer more clearly that I want a clock enable. > >So this is what my UCF would look like (bare-bone again): > >NET "clk" TNM_NET = "clk"; >TIMESPEC "ts_clk" = PERIOD "clk" 10 ns HIGH 50 %; >NET "en" TNM = "tgrp_en"; >TIMESPEC "ts_multipath" = FROM "tgrp_en" TO "tgrp_en" "TS_clk" * 4; I think you need to change the way you're setting up the MCP constraint. What you want is for every flop which is controlled by EN, the REG.Q to REG.D path is 4 cycles. EN.Q to CNT.D is actually a single cycle path. It's easier to see if you draw the waveform; EN controls a MUX one end of which is connected CNT.Q and the other is connected to the output of the incrementer logic (including the CNT!=16'hFFFF check) (only logically not what the synthesizer necessarily implements) EN is high only a single clock so the path of the MUX which is short has to work in a single cycle. The other path which has the conditional incrementer can take 4 cycles to settle.Article: 123195
First, thanks all for responding.
Now to business:
On Aug 19, 8:52 pm, "John Retta" <jre...@rtc-inc.com> wrote:
> [1] There are lots of ways to define a Time group, and yours is too
> inclusive.
Of course it is. Otherwise there wouldn't be a problem. ;)
(...)
> [2] In future, if you have a prefix on signal names that you
> know will be a multipath source/destination, it will be easier,
> in large designs to use wildcards for inclusion in group.
That won't solve the problem, I'm afraid. What I showed in my example
above, is that some paths between registers which change only every 4
clocks still can't be allowed for multipath constraint relaxation. So
hand-picking those registers according to their expected BEHAVIOUR
won't do the job. I mean, wouldn't you (manually) pick "cnt" as a
candidate for a multi-cycle path from itself to itself? (which would
be correct, if there wasn't any extra "if" to mess up the real CE
path)
>
> [3] Take a look at
> xilinx/doc/usenglish/docs/cgd/cgd.pdf for good reference
> on constraint usage.
Ah, the Constraint Guide is my friend. And in section 4->FPGA Timing
Constraint Strategies->Specific Timing Assignments I it says:
<< SNIP >>
Identifying groups by connectivity allows you to group elements by
specifying nets that eventually drive synchronous elements and pads.
This method is a good way to identify multi-cycle paths elements that
are controlled by a clock enable. This method uses TNM_NET on a net.
The TNM_NET syntax for identifying groups by connectivity is:
NET "net_name" TNM_NET = qualifier "tnm_name";
<< SNIP >>
... and then they go on more or less like I did. (I chose TNM instead
of TNM_NET but that's not relevant here).
So the problem remains. Any ideas?
Eli
Article: 123196PeteS <axkz70@dsl.pipex.com> wrote: >fpgabuilder wrote: >> On Aug 19, 11:15 am, PeteS <axk...@dsl.pipex.com> wrote: >>> Nico Coesel wrote: >>>> pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: >>>>> Hello >>>>> I decided to make my own DDR controller. I want to do this on CycloneII or >>>>> Spartan-3 I'm not decided yet. That's way I want to ask the quastion: >>>>> Which of this device familly has better features to design a DDR controller >>>>> core. >>>>> That what I know now: >>>>> Altera Cyclone2: >>>>> - PLL >>>>> - Clock Delay Control Circuitry for DQS signal - it's look interesting >>>>> - altdq and altdqs megafunctions to implement output and input logic >>>>> - Series On-Chip Termination >>>>> Xilinx Spartan3: >>>>> - DCM >>>> A normal and 90 degrees phase shifted clock are all that is required >>>> to clock a DDR controller. >>> For the perfect (or close to it) case. A practical DDR controller >>> running at 200/400 or greater benefits greatly from having the ability >>> to add/subtract a small delay around the 90 degrees. Whether the delay >>> is useful depends on the application. >>> >>>>> - Programmable Delay on each input pin. - How it's work? How to use it? >>>> Not necessary for DDR (should be left disabled) >>> See above. >>> >>>>> - IFDDRxxx and OFDDRxxx components implement output and input logic >>>> Yes, These are very necessary. Clock the signals as close to the IO >>>> pin as possible. The setup and hold times will vary more as the amount >>>> of logic increases which is something you don't want. >>>>> - Digitally Controlled Impedance (DCI) - but require some pins: VREN, >>>>> VREP >>>> Useless. It will make the chip run very hot especially with many lines >>>> connected. Use series resistors on the board. >>> Agreed, but DDR should have a known impedance at the driver and >>> receiver, which I believe the SSTL (II) IO standard provides. >>> >>> >> >> I recently removed the series and parallel terminations from a Cyclone >> 3 dev board and ran the ddr interface at 133MHz. The interface worked >> overnight without a problem. >> >> I think the trace length on the ddr signals is about 2-3 inches. They >> are point-to-point signals. The data bus is 16bits wide and is >> implemented using Altera's ALTMEMPHY megafunction. Further, I >> momentarily cooled down the memory and altera chips to -40degC and >> then heated them up to 125degC without any errors. >> >> I see that without the series terminations there is a problem on the >> overshoot and undershoot. But it does not violate the specs of the >> fpga. On the memory side, the problem goes away when I use onchip >> series termination. >> >> >The decision as to whether to parallel terminate is based on a number of >things, as is the decision to simply series terminate. It depends on the >application. Generally, if the data lines are point to point (2 >connections only) you can get away with series termination (but it's not >that simple - some thought needs to be given to the termination value) - >if you have more than one endpoint, series termination is not possible >for guaranteed operation, which is why series termination of >address/control is generally not possible for guaranteed operation. Almost all the address and control lines can be run at half the memory clock frequency so drive strength and termination can be relaxed. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 123197
[1] Try this. NET "clk" TNM_NET = "clk"; TIMESPEC "ts_clk" = PERIOD "clk" 10 ns HIGH 50 %; INST "cnt*" TNM="JUST_CNT_FF"; TIMESPEC "TS_JUST_CNT_FF" = FROM "JUST_CNT_FF TO "JUST_CNT_FF" "TS_clk" * 4; [2] My only point was that there were more specific techniques for identifying paths. The level of specificity though is limited. For instance, suppose FF1 had two paths to FF2, one a multicycle path, the second a single clk path. It is not clear how to distinguish the two paths. This might seem like an arcane example, but I suspect your "simple" example might be more illustrative of a common problem -- Regards, John Retta Owner and Designer Retta Technical Consulting Inc. email : jretta@rtc-inc.com web : www.rtc-inc.com <eli.billauer@gmail.com> wrote in message news:1187558599.351844.214710@w3g2000hsg.googlegroups.com... > First, thanks all for responding. > > Now to business: > > On Aug 19, 8:52 pm, "John Retta" <jre...@rtc-inc.com> wrote: >> [1] There are lots of ways to define a Time group, and yours is too >> inclusive. > > Of course it is. Otherwise there wouldn't be a problem. ;) > > (...) > >> [2] In future, if you have a prefix on signal names that you >> know will be a multipath source/destination, it will be easier, >> in large designs to use wildcards for inclusion in group. > > That won't solve the problem, I'm afraid. What I showed in my example > above, is that some paths between registers which change only every 4 > clocks still can't be allowed for multipath constraint relaxation. So > hand-picking those registers according to their expected BEHAVIOUR > won't do the job. I mean, wouldn't you (manually) pick "cnt" as a > candidate for a multi-cycle path from itself to itself? (which would > be correct, if there wasn't any extra "if" to mess up the real CE > path) > >> >> [3] Take a look at >> xilinx/doc/usenglish/docs/cgd/cgd.pdf for good reference >> on constraint usage. > > Ah, the Constraint Guide is my friend. And in section 4->FPGA Timing > Constraint Strategies->Specific Timing Assignments I it says: > > << SNIP >> > > Identifying groups by connectivity allows you to group elements by > specifying nets that eventually drive synchronous elements and pads. > This method is a good way to identify multi-cycle paths elements that > are controlled by a clock enable. This method uses TNM_NET on a net. > > The TNM_NET syntax for identifying groups by connectivity is: > > NET "net_name" TNM_NET = qualifier "tnm_name"; > > << SNIP >> > > ... and then they go on more or less like I did. (I chose TNM instead > of TNM_NET but that's not relevant here). > > So the problem remains. Any ideas? > > Eli >Article: 123198
Hello Let me ask one question. >From my small experience, I find that FPGA is good for synchronous design, because (1) There are enough registers, (2) There are fat clock trees for entire chip, (3) There are IPs for different clock synchronization management (for example, DCM). Question is that If we design very complex systems that contains many IPs that (1) different IPs need different clock domains, (2) different communication buses (for example, PLB, OPB) need different clocks, (3) single clock has too many loads, Then how can current FPGA handle? I think that following will be good in FPGA (1) Each IP has its own clock, (2) IPs communicate with "asynchronous handshaking" each other.Article: 123199
"Pasacco" <pasacco@gmail.com> wrote in message news:1187565989.685058.128660@57g2000hsv.googlegroups.com... > Hello > > Let me ask one question. > Then how can current FPGA handle? > > I think that following will be good in FPGA > (1) Each IP has its own clock, > (2) IPs communicate with "asynchronous handshaking" each other. > Dear P., Let me answer your question. IP should have a clock port and a clock enable port. So, if you need to integrate several bits of IP, you can use one clock with different enables. HTH., Syms.
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