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
Slight correction to the previous post. Any change in the output of the toggle flop would indicate that the previous 100 MHz clock edge corresponded to a rising edge on the 25 MHz, not just a 0->1 transition on the flop. KJArticle: 136751
> One clean way is to look at a FF clocked by the 25 MHz clock > rather than the raw 25 MHz clock. You can either find an edge > and just keep counting from there or make a FF that toggles > on each 25 MHz clock and restart your state machine each toggle. > Good point, *any* signal from the 25 MHz domain would work, it doesn't need to be a free running toggling flop. KJArticle: 136752
KJ wrote: >> One clean way is to look at a FF clocked by the 25 MHz clock >> rather than the raw 25 MHz clock. You can either find an edge >> and just keep counting from there or make a FF that toggles >> on each 25 MHz clock and restart your state machine each toggle. > > Good point, *any* signal from the 25 MHz domain would work, it doesn't need > to be a free running toggling flop. > I actually have one handy anyway (part of a counter in the 25 MHz domain.) -hpaArticle: 136753
"H. Peter Anvin" <hpa@zytor.com> wrote in message news:gh6tkh$s08$1@terminus.zytor.com... > Hello, > > I have a design which I am porting to a Cyclone II FPGA. This design > includes two clocks, one at 25 MHz and one at 100 MHz, currently > generated from the Cyclone II PLL from a common clock (and thus > synchronous.) I have avoided it so far, but I'm running into a > situation where the high-speed logic would like to understand where it > is in relation to the low-speed clock cycle, in order to generate clock > enables. > Hi H., Is it not possible to ditch the 25MHz clock and use only the 100MHz clock for all the synchronous elements? Just enable it once every four goes. HTH HPA, Syms.Article: 136754
Hello all, I was wondering what is signified by the number suffix that comes with each of Xilinx FPGAs along with their Family Names (v2p,v4,v5). For example xc5vfx130t, I know t stands for Rocket IO Capability. Could anyone clarify me the number 130 suffixed to the name? Thanks in advance for your patient response. regards, Venkat.Article: 136755
>> Good point, *any* signal from the 25 MHz domain would work, it doesn't need >> to be a free running toggling flop. >I actually have one handy anyway (part of a counter in the 25 MHz domain.) FFs are generally plentiful in FPGAs. The routing from where you have a FF over to where you need it may be more valuable than a FF. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 136756
Hal Murray wrote: >>> Good point, *any* signal from the 25 MHz domain would work, it doesn't need >>> to be a free running toggling flop. > >> I actually have one handy anyway (part of a counter in the 25 MHz domain.) > > FFs are generally plentiful in FPGAs. The routing from where you > have a FF over to where you need it may be more valuable than a FF. > Yes. Fortunately the compiler takes care of that (it will split and merge identical registers as routing warrants.) I guess one can override that, but that's hard to know without knowing where things end up anyway. -hpaArticle: 136757
On Wed, 3 Dec 2008 21:17:34 -0800 (PST), Venkat wrote:
>Hello all,
>
>I was wondering what is signified by the number suffix that comes with
>each of Xilinx FPGAs along with their Family Names (v2p,v4,v5). For
>example xc5vfx130t, I know t stands for Rocket IO Capability.
Yes, that's right. In fact it explains the name "Virtex":
'V' stands for the family name (Virtex);
'i' indicates that it has Integer multipliers on-chip;
'r' shows it's Reconfigurable (have you noticed that all
Xilinx parts have an R in their name - spaRtan, viRtex,
coolRunner?)
't' - as you say - indicates the RocketIO capability;
'e' shows that Extended temperature range is available;
'x' is a warning that the largest parts are quite eXpensive.
As far as the other stuff is concerned, I must admit that
I have the rather dull and old-fashioned habit of consulting
manufacturers' data sheets for that kind of information. I
am aware, though, that this is a very outmoded approach that
doesn't fit well in the modern Web2.0 world, which explains
why you young chaps are so much better at all this than we
old fellers.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 136758Hi newsgroup, please consider the following scenario: One design block "core_xy" is clocked with a clock coming from a FPGA internal PLL. That PLL shifts the incoming clock (from external). A second design block "ctrl_core_xy" controls the first block and is clocked directly by the external clock. My question: Do FPGA timing analysis tools imply the PLL phase shift in their timing calculation ? If "timing is met" can I be sure that both clock domains have been treated correctly ? Or do I face asynchronous clock domains which have been blocked in timing calculation ? Rgds, ALuPinArticle: 136759
Hello, Can Xilinx-ISE produce a report correlating the names of the signal of the source code (VHDL) to the names of the nets after placement & routing or viseversa? If not how can I perform a back-annotated simulation without knowing the names of the signals I want to debug? Thank you in advance Giorgos P.Article: 136760
1. Thanks Eilert, >In that case it might happen, >that the first FF changes its output line before the hold time required >for the second FF is over(tCO < tH). Changing a FFs input between start >of setup time and end of hold time causes unpredictable results or even >metastability. To check my understanding, between the two statements above, are you trying to say: ? Since the output of the 1st FF feeds to the D input of 2nd FF, inequality (tCO of 1st FF < tH of 2nd FF) means that the signal value on D input changes before the end of hold time for the 2nd FF. >May be a rare case, but formally correct. >Inside FPGAs, where all the FFs are the same, this should not be an >issue at all. Could you please elaborate on this? 2. Thanks Muzaffer, >The more accurate equation is >tCK1 + tCO > tCK2 + tH ie the clock arrival time to the the source >clock plus the clock to output delay should be greater than clock >arrival time to the target flop plus the hold time. Thanks for adding clock arrival into the picture (Eilert also indicated it) Could you please formally define the clock arrival time? From when to when? 3. Thanks Hal, >It's not that the FFs are the same, it's that the hardware designers >decided to simplify things for the software guys by making all >FFs appear to have 0 hold time. >It's actually more complicated than that. The hardware guys have to >promise that min clock-out and min routing has to cover the >max hold time and any clock skew using the normal clock distribution >network. You seem to suggest that FPGA hardware guarantees the hold time requirement tH always *appear* to the FPGA application designer to be 0? And, is this why the FPGA vendors never have to check the hold time requirement? 4. Thanks Gabor, >Actually tCO in the above equation needs to include the minimum >routing delay as well as the clock to output time of the flop. In >an FPGA, the routing delays are often longer than the logic delays. Thanks for adding routing delay and logic delay into the picture. To check my understanding, the hold time requirement becomes: tCK1 + tCO + tRouting + tLogic > tCK2 + tH Is this correct and complete? >Xilinx has an appnote on how their timing analyzer calculates >setup and hold times. For me it's a little like looking at >accounting methods, because although the calculated answer is >correct, the way they present the arithmetic is not the way >you would normally think of the problem. Are you talking about the white paper entitled "What Are PERIOD Constraints? (WP257)" ? If yes, the presentation of this paper really confused me, especially page 10 of it. 5. Thanks all again! The difficulty with me to understand the hold time requirement is that I am trying follow the same way to understand the setup time requirement: Setup Slack = (Tclock - tCLK_Skew) - (tCO + tData) - tS Which can be thought through by 1) tracing the data path from clock source's 1st clock edge through the 1st DFF tCO, combinational logic data path delay, required setupt time tS, to the D input of 2nd DFF: (tCO + tData + tS) 2) tracing the clock path from the clock source through clock path delay (causing clock skew) to get clock arrival time at 2nd DFF for the *next* active clock edge. The Setup Slack is the difference between Clock Arrival and Data Arrival: Setup Slack = ClockArrival - DataArrival - tS = (Tclock - tCLK_Skew) - (tCO + tData) - tS ---------- (1) Now, to derive the Hold Slack, one has to look at the *same* clock edge for both DFFs: Hold Slack = DataArrival - ClockArrival - tH = (tCO + tData) - tCLK_Skew - tH ----------- (2) The difference for ClockArrival in (1) and (2) is the thing that bothers me. Could you please help me out on this? Thanks all, gentlemen! CarlArticle: 136761
Hello, All, As I understand it, ISE Timing Analyzer does setup time analysis for PERIOD, OFFSET IN and OFFSET OUT constraints as follows: PERIOD slack = (requirement - (data path - clock path skew + uncertainty)) OFFSET IN slack = (requirement - (data path - clock path - clock arrival + uncertainty)) OFFSET OUT slack = (requirement - (clock arrival + clock path + data path + uncertainty)) Q1: My impression is that "setup time" is included in the "data path". Is this correct? If yes, where is this documented? Q2: Which term includes "hold time" in the analysis? If yes, where is this documented? If no, why? Thanks. Carl HortonArticle: 136762
On Dec 4, 3:48=A0am, "ALu...@web.de" <ALu...@web.de> wrote: > Hi newsgroup, > > please consider the following scenario: > > One design block "core_xy" is clocked with a clock coming from a FPGA > internal PLL. > That PLL shifts the incoming clock (from external). > A second design block "ctrl_core_xy" controls the first block and is > clocked directly > by the external clock. > > My question: > Do FPGA timing analysis tools imply the PLL phase shift in their > timing calculation ? That is a tool dependent question, some do and some do not. > If "timing is met" can I be sure that both clock domains have been > treated correctly ? Only if you know for certain that they are correctly handling any phase shift between the two domains and that the tool is actually performing the analysis between signals that cross domains. > Or do I face asynchronous clock domains which have been blocked in > timing > calculation ? > Since the clock domains are related, treating them like asynchronous domains might be worse depending on what the PLL is doing in the frequency domain. As an example, if the PLL does a 2:1 multiply but not totally in phase then the input clock and the PLL output clock will be clashing 100% of the time and any timing problems will quickly show up. Timing problems with a PLL multiplier of 7:3 would take longer to show up. The short answer though is simply to correctly perform the timing analysis in the first place which is what it sound like you're trying to do by questioning whether phase shifts get correctly handled by the timing analysis tool. Create a simple test design that simply clocks something in with the input clock and then transfers it over to the PLL out clock domain and bring that signal to an output pin and run that design through the tools. Vary the PLL phase and run it through again. You might also want to bring the PLL output to an output pin as well since many times other external devices base their timing on such a signal (like a DDR controller inside an FPGA that talks to an external DDR). That should give you the background needed to insure that you're using the tools in a way that is properly analyzing the clock domain transfers. Kevin JenningsArticle: 136763
On Dec 4, 3:48=A0am, "ALu...@web.de" <ALu...@web.de> wrote: > Hi newsgroup, > > please consider the following scenario: > > One design block "core_xy" is clocked with a clock coming from a FPGA > internal PLL. > That PLL shifts the incoming clock (from external). > A second design block "ctrl_core_xy" controls the first block and is > clocked directly > by the external clock. > > My question: > Do FPGA timing analysis tools imply the PLL phase shift in their > timing calculation ? > If "timing is met" can I be sure that both clock domains have been > treated correctly ? > Or do I face asynchronous clock domains which have been blocked in > timing > calculation ? > > Rgds, > ALuPin You don't mention which tools you are using. I have found for example that the Lattice tools (from NeoCad) try to analyze the timing on related clocks, but don't always do it right. For example I had a PLL generating both 0 shift and 270 degree shifted clock. Calculating the setup to the shifted clock on a signal generated on the non-shifted clock you would expect that the path needs to meet 3/4 cycle time from clock to clock. In fact the tools treated this as 1 and 3/4 cycles available for the signal path from clock to clock! I would suggest looking at a timing report to see if you can find coverage for cross clock-domain paths. If you use Xilinx tools you can also get a report of uncovered paths to see if your cross clock-domain paths fall into this category. Cheers, GaborArticle: 136764
Hi, thank you for your answers. I am using ispLEVER 7.1 from Lattice. Maybe having a look at the coverage reports will shed some light on it. Rgds ALuPinArticle: 136765
Giorgos_P wrote:
> Can Xilinx-ISE produce a report correlating the names of the signal of
> the source code (VHDL) to the names of the nets after placement &
> routing or viseversa? If not how can I perform a back-annotated
> simulation without knowing the names of the signals I want to debug?
I do my debugging with source code.
A back-annotated gate sim is a double check
on synthesis and static timing, not functionality.
-- Mike Treseler
Article: 136766Hello group, I'm trying to implement a simple design that uses partial reconfiguration, and for testings I'm beginning with a modular implementation that still has the bus macros. I use an AREA GROUP constraint to pack all the reconfigurable logic into a rectangular region of the FPGA. This works for logic (the constraint successfully moved the static design slices out of the reconfigurable area), but apparently not with signals, as PAR routed a static wire in the middle of my reconfigurable area (troublesome signal is in red) : http://lekernel.net/routing_problem.png The design is very simple, it is just supposed to blink two LEDs (blinking enabled with DIP switches) with one controlled by the static design and the other with a reconfigurable area. I am using the ML401 board which has a Virtex 4. Top-level Verilog code is: module top(input clk, input en1, output led1, input en2, output led2); blink_static static(.clk(clk), .en(en1), .blink(led1)); wire led2_prr, en2_prr; busmacro_xc4v_l2r_async_narrow busmacro_fromprr(.input0 (led2_prr), .output0(led2)); busmacro_xc4v_r2l_async_narrow busmacro_toprr(.input0(en2), .output0 (en2_prr)); blink_prm prr(.clk(clk), .en(en2_prr), .blink(led2_prr)); endmodule The signal that causes the problem is named en2_IBUF in FPGA Editor. I am using the following area constraints in the UCF file : INST "busmacro_fromprr" LOC=SLICE_X20Y122; INST "busmacro_toprr" LOC=SLICE_X20Y124; AREA_GROUP "AG_pr" RANGE = SLICE_X16Y98:SLICE_X21Y131; AREA_GROUP "AG_pr" GROUP = CLOSED; AREA_GROUP "AG_pr" PLACE = CLOSED; # tried with and without this one, no change INST "prr" AREA_GROUP="AG_pr"; How to prevent static signals from crossing my reconfigurable area ? Perhaps I should not connect I/O signals directly to busmacros (but why ?) ? Or did I misunderstand something and this signal is not going to be a problem ? Thanks. SebastienArticle: 136767
On Dec 3, 9:17=A0pm, Venkat <venkat.ja...@gmail.com> wrote:
> Hello all,
>
> I was wondering what is signified by the number suffix that comes with
> each of Xilinx FPGAs along with their Family Names (v2p,v4,v5). For
> example xc5vfx130t, I know t stands for Rocket IO Capability.
>
> Could anyone clarify me the number 130 suffixed to the name?
>
AFAIK, each family has its own rules. The nomenclature for Virtex-5
is spread throughout the following document.
http://www.xilinx.com/support/documentation/data_sheets/ds100.pdf
In specific, check out Table 1 on page 2.
Example: XC5VSX35T
All device codes have the followign formats.
XC5V ff iii T
"XC5V" =3D Virtex-5 FPGA family
ff =3D device sub type
LX =3D Logic-only, general-purpose family.
SX =3D Signal processing heavy, more DSP48 DSP blocks at the expense of
general-purpose logic.
FX =3D Full-featured family including PowerPC processing blocks along
with all the other bells and whistles.
TX =3D Devices with enhanced GTX transcievers capable of 6.5 Gbps.
iii =3D Logic capacity
The integer number is a gross approximation at the number of "logic
cells" (which is an entirely different discussion). The larger the
number, the more logic capacity the device has.
T =3D Transceivers (optional suffix)
High-speed serial I/O. All SX, FX, and TX devices have transcievers.
The LX versions include devices with or without transceivers. Also,
the TX devices have a different, higher-performance tranceiver than
the others.
Steve Knapp
Prevailing Technology, Inc.
www.prevailing-technology.com
Article: 136768Hello, I'm experiencing some aggravation with ISE 10.1. I'm trying to add an existing vhd file to my project. When I try to add it ISE freezes and I have to go to the task manager to shut it down. If I try to recreate the project, using the same folder and same project name as soon as I try to add a file to the project it does the same thing. If I recreate the project using a project name other than the original name, it works fine. I have no idea what's going on. If you have any ideas, please share. Thanks, DaleArticle: 136769
>>> I actually have one handy anyway (part of a counter in the 25 MHz domain.) >> >> FFs are generally plentiful in FPGAs. The routing from where you >> have a FF over to where you need it may be more valuable than a FF. >Yes. Fortunately the compiler takes care of that (it will split and >merge identical registers as routing warrants.) I guess one can >override that, but that's hard to know without knowing where things end >up anyway. If the counter is on the opposite side of the chip from the place where you want your 25/100 logic, you have to route the signal across the chip. What I was trying to suggest is changing the source text to create a new FF in order to avoid that routing. It all depends... I'd probably start with the extra FF just to keep the source code clean. Why add an obscure dependency if you don't need it. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 136770
>You seem to suggest that FPGA hardware guarantees the hold time >requirement tH always *appear* to the FPGA application designer >to be 0? And, is this why the FPGA vendors never have to check the >hold time requirement? Yes. That's my understanding, but I don't work for the vendors so I'm reading between the lines. It seems pretty obvious. >tCK1 + tCO + tRouting + tLogic > tCK2 + tH >Is this correct and complete? It's not quite complete. You need a bunch of min/max-es in there. For setup times, you want the max time of everything. For hold times, you want the min times on getting the signal to the target FF and the max hold time it needs after you get there. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 136771
Hal Murray wrote: > > If the counter is on the opposite side of the chip from the place > where you want your 25/100 logic, you have to route the signal > across the chip. > > What I was trying to suggest is changing the source text to create > a new FF in order to avoid that routing. > > It all depends... > > I'd probably start with the extra FF just to keep the source code clean. > Why add an obscure dependency if you don't need it. > My point was mostly that the compiler will treat two FFs with identical clocks and identical inputs as a single FF, and then will split that single FF if warranted. This is actually the right thing for the compiler to do, as it has information the programmer generally does not in this instance. I'll just do in my source what ends up looking cleanest. -hpaArticle: 136772
> When I try to add it ISE freezes and > I have to go to the task manager to shut it down. Must be something in the VHDL file. Perhaps there is something that conflicts with the heirarchy? Like a module with the same name as your top module. Brad Smallridge Ai VisionArticle: 136773
On Dec 4, 2:30=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > > When I try to add it ISE freezes and > > I have to go to the task manager to shut it down. > > Must be something in the VHDL file. > Perhaps there is something that conflicts > with the heirarchy? Like a module with the > same name as your top module. > > Brad Smallridge > Ai Vision I've found that ISE 10.1 tries to be very smart about detecting the hierarchy, and runs into trouble when there are errors in a source file, sometimes ripping out entire sections of the design and asking for a new top level module assignment when certain errors confuse it. There are also conflicts with other programs including some virus scanners and backup software like Carbonite that cause confusion with ISE's underlying database software. If ISE hasn't completely trashed the old project, you could try "cleanup project files" before adding the new source. It seems that ISE is not good at cleaning up after itself. This often appears in things like .ucf file entries that don't go away when you delete them from the file. Sometimes you have to find the temp folders under your main project directory with a name containing the project name and delete everything in them. When all else fails, file a web case. I know it's a headache but otherwise how is Xilinx to know just how buggy their software is? Regards, GaborArticle: 136774
On 4 =C4=E5=EA, 16:55, Mike Treseler <mtrese...@gmail.com> wrote: > Giorgos_P wrote: > > Can Xilinx-ISE produce a report correlating the names of the signal of > > the source code (VHDL) to the names of the nets after placement & > > routing or viseversa? If not how can I perform a back-annotated > > simulation without knowing the names of the signals I want to debug? > > I do my debugging with source code. > A back-annotated gate sim is a double check > on synthesis and static timing, not functionality. > > =A0 =A0 =A0 =A0-- Mike Treseler I agree, but if this double check fails, you need to go and see where it failed. You can't do this without knowing what the names of the nets correspond to (to the initial source code). Any ideas?
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