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
>has anybody tried to connect a FPGA to several CCDs Hello, I have designed progressive-scan CCD-based digital camera. Several CCDs can operate synchronously but, I think, we should talk about several digital cameras in that case. The camera shall include a CCD sensor, analog-to-digital converter (several ADCs if CCD has several outputs), timing generator and level converters required for CCD operation, automatic gain control (AGC), digital video link (IEEE-1394 or LVDS..), camera control interface, and digital-to-analog converter (if analog output is needed). In such design, FPGA(s) incorporates all 'camera logic': - timing generator (you can refer to a particular CCD data sheet; Sony has timing generator chips /and provides full specification/, but if you need some functionality beyond original specification - probably, extended-range electronic shutter and specific charge-transfer modes, you will need to implement your own timing generator) -partially, AGC (along with microprocessor running AGC program) -logic-level communication and control protocol -digital image processing (requires external memory array) Best Regards, Igor KauranenArticle: 38251
hello i download service pack8 for update software xilinx foundation F3.1i my download is 3_3_08i_pc.exe,Aldec_2001_3.exe and FPGAEXP35.exe when i implement my project FATAL_ERROR:StaticFileParsers:Xml_Node.c:358:1.12.8.2 - Corrupt or missing Xml pls tell me how to connect xilinx or solve this problemArticle: 38252
Hi - The argument I made previously also applies to I/O. A DECREASE IN THE CLOCK DELAY IS A PROBLEM ONLY IF THE DATA DELAY DOESN'T DECREASE IN PROPORTION. As I mentioned in my previous post, delays tend to track on chip. Not perfectly, but closely enough that you don't have to worry about the clock delay going to 0 while the data delay remains unchanged. Bob Perlman On Wed, 09 Jan 2002 09:55:15 -0600, Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com> wrote: >Bob, > >I guess my initial posting missed several points. >The thing I was concerned was the setup time (Tsu) for signals coming >from outside of the chip. >Here is part of a timing report that should clarify my point. > > >================================================================================ >Timing constraint: COMP "irdy_n" OFFSET = IN 7 nS BEFORE COMP "clk" ; > > 567 items analyzed, 68 timing errors detected. > Minimum allowable offset is 9.445ns. >-------------------------------------------------------------------------------- >Slack: -2.445ns (requirement - (data path - clock path >- clock arrival)) > Source: irdy_n > Destination: PCI_IP_Core_Instance_ad_Port_21 > Destination Clock: clk_BUFGP rising at 0.000ns > Requirement: 7.000ns > Data Path Delay: 11.833ns (Levels of Logic = 5) > Clock Path Delay: 2.388ns (Levels of Logic = 2) > Timing Improvement Wizard > Data Path: irdy_n to PCI_IP_Core_Instance_ad_Port_21 > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tiopi 1.224 irdy_n > irdy_n_IBUF > net (fanout=47) 1.974 irdy_n_IBUF > Tilo 0.653 PCI_IP_Core_Instance_I_XXL_1384 > net (fanout=32) 1.564 PCI_IP_Core_Instance_N2952 > Tilo 0.653 PCI_IP_Core_Instance_I_411_LUT_40 > net (fanout=1) 1.648 PCI_IP_Core_Instance_N4755 > Tilo 0.653 PCI_IP_Core_Instance_I__n0024_21 > net (fanout=1) 2.256 PCI_IP_Core_Instance_N4759 > Tioock 1.208 PCI_IP_Core_Instance_ad_Port_21 > ---------------------------- ------------------------------ > Total 11.833ns (4.391ns logic, 7.442ns route) > (37.1% logic, 62.9% route) > > Clock Path: clk to PCI_IP_Core_Instance_ad_Port_21 > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tgpio 1.082 clk > clk_BUFGP/IBUFG > net (fanout=1) 0.007 clk_BUFGP/IBUFG > Tgio 0.773 clk_BUFGP/BUFG > net (fanout=468) 0.526 clk_BUFGP > ---------------------------- ------------------------------ > Total 2.388ns (1.855ns logic, 0.533ns route) > (77.7% logic, 22.3% route) > >-------------------------------------------------------------------------------- > > > > >-------------------------------------------------------------------------------- >4 constraints not met. > > >Data Sheet report: >----------------- >All values displayed in nanoseconds (ns) > >Setup/Hold to clock clk >---------------+------------+------------+ > | Setup to | Hold to | >Source Pad | clk (edge) | clk (edge) | >---------------+------------+------------+ >ad<0> | 5.516(R)| 0.000(R)| >ad<10> | 5.691(R)| 0.000(R)| >ad<11> | 4.457(R)| 0.000(R)| >ad<12> | 4.478(R)| 0.000(R)| >ad<13> | 3.422(R)| 0.000(R)| >ad<14> | 3.916(R)| 0.000(R)| >ad<15> | 4.468(R)| 0.000(R)| >ad<16> | 3.490(R)| 0.000(R)| >ad<17> | 3.402(R)| 0.000(R)| >ad<18> | 3.470(R)| 0.000(R)| >ad<19> | 3.821(R)| 0.000(R)| >ad<1> | 4.943(R)| 0.000(R)| >ad<20> | 3.848(R)| 0.000(R)| >ad<21> | 4.427(R)| 0.000(R)| >ad<22> | 4.728(R)| 0.000(R)| >ad<23> | 3.456(R)| 0.000(R)| >ad<24> | 2.986(R)| 0.000(R)| >ad<25> | 3.444(R)| 0.000(R)| >ad<26> | 3.260(R)| 0.000(R)| >ad<27> | 3.517(R)| 0.000(R)| >ad<28> | 4.303(R)| 0.000(R)| >ad<29> | 4.606(R)| 0.000(R)| >ad<2> | 5.781(R)| 0.000(R)| >ad<30> | 3.844(R)| 0.000(R)| >ad<31> | 3.945(R)| 0.000(R)| >ad<3> | 5.734(R)| 0.000(R)| >ad<4> | 4.404(R)| 0.000(R)| >ad<5> | 5.967(R)| 0.000(R)| >ad<6> | 5.709(R)| 0.000(R)| >ad<7> | 4.880(R)| 0.000(R)| >ad<8> | 4.615(R)| 0.000(R)| >ad<9> | 3.910(R)| 0.000(R)| >c_be_n<0> | 6.539(R)| 0.000(R)| >c_be_n<1> | 6.116(R)| 0.000(R)| >c_be_n<2> | 5.946(R)| 0.000(R)| >c_be_n<3> | 7.348(R)| 0.000(R)| >frame_n | 8.493(R)| 0.000(R)| >idsel | 0.884(R)| 0.000(R)| >irdy_n | 9.445(R)| 0.000(R)| >par | 7.649(R)| 0.000(R)| >---------------+------------+------------+ > >Clock clk to Pad >---------------+------------+ > | clk (edge) | >Destination Pad| to PAD | >---------------+------------+ >ad<0> | 9.840(R)| >ad<10> | 9.731(R)| >ad<11> | 9.731(R)| >ad<12> | 9.731(R)| >ad<13> | 9.733(R)| >ad<14> | 9.733(R)| >ad<15> | 9.733(R)| >ad<16> | 9.734(R)| >ad<17> | 9.733(R)| >ad<18> | 9.733(R)| >ad<19> | 9.733(R)| >ad<1> | 9.840(R)| >ad<20> | 9.734(R)| >ad<21> | 9.733(R)| >ad<22> | 9.733(R)| >ad<23> | 9.733(R)| >ad<24> | 9.731(R)| >ad<25> | 9.731(R)| >ad<26> | 9.734(R)| >ad<27> | 9.734(R)| >ad<28> | 9.774(R)| >ad<29> | 9.779(R)| >ad<2> | 9.786(R)| >ad<30> | 9.782(R)| >ad<31> | 9.784(R)| >ad<3> | 9.786(R)| >ad<4> | 9.784(R)| >ad<5> | 9.782(R)| >ad<6> | 9.779(R)| >ad<7> | 9.734(R)| >ad<8> | 9.734(R)| >ad<9> | 9.731(R)| >devsel_n | 9.731(R)| >par | 9.733(R)| >perr_n | 9.733(R)| >serr_n | 9.733(R)| >stop_n | 9.731(R)| >trdy_n | 9.734(R)| >---------------+------------+ >-------------------------------------------------------------------------------- > > > In this example, IRDY# (irdy_n) comes from outside of the chip, >goes through 3 levels of LUTs, and goes into an IOB output FF. >Some people may ask me why I don't register the input, but in my case, I >am already using a registered version of IRDY# when that is possible >like during a configuration cycle, a single transfer, or the first >transfer of a burst transfer where wait cycles are being inserted. >If wait cycles are being inserted for several cycles, the registered >version and the raw (unregistered) version signal are guaranteed to be >same by the PCI specification (unless a parity error occurs) because >once a signal is asserted, the specification doesn't allow it to change >until end of a transfer (or end of a microaccess in burst transfer). >During a no-wait cycle burst transfer, a PCI device has to see the raw >signal to determine what to do next, and from looking at the inputs >going into the above LUTs through Floorplanner, the state machine state >where no-wait burst transfer is handled is the signal path shown above. >Note that the routing delay shown in above report looks pretty bad, but >I should be able to reduce that when I floorplan the design. > If I restate my concern, the concern I have is that if a chip >that can pass testing for a Spartan-II speed grade -6 is sold as a speed >grade -5 because of yield improvement, the actual clock skew for that >chip will be reduced by about 20% (from 2.388ns (-5) to about 1.90ns >(-6)). >Yes, I guess the LUT delay will likely drop by at least 20% (when I >resynthesized my design for Spartan-II speed grade -6, the logic and >routing delay seemed to have dropped faster than the clock skew), so the >end result will be that the timings will still be met . . . I guess. >Another concern is at low temperatures, because at lower temperatures, >clock skew should decrease. >I guess logic and routing delay will also decrease, so the end result >will be that the timings will still be met . . . I guess. > I must say that the views I have here are pretty pessimistic. >I assume that the clock skew will decrease at lower temperatures, but >the LUT, DFF setup time, and routing delay will not decrease at all, >which is not true. >Should I redo the timing report analysis at lower temperature, and >believe those numbers? >What I am trying to do to some extent is that I want the data path delay >(logic + routing) to be less than 7ns, so that I don't have to worry >about clock skew being there to aid the setup time. >I realize that this becomes harder and harder to achieve as the die size >grows because the bigger chip will have more routing delay (For example, >Virtex XCV1000 will likely have much more routing delay than Virtex >XCV150 or Spartan-II XC2S150). >But my understanding which might be wrong is that the clock skew number >shown in the report is for the maximum possible clock skew. >Than because clock skew can be less than shown in the report, what is >the minimum clock skew I should expect? > > > > >Thanks, > > > >Kevin Brace (don't respond to me directly, respond within the newsgroup) > > > > >Bob Perlman wrote: >> >> Hi - >> >> I assume you're talking about setup time margins within the chip, >> i.e., both the source and destination flip-flops are on-chip. >> >> The question boils down to how well the data delay tracks the clock >> skew delay over temperature, voltage, and process. Xilinx used to >> claim (and maybe still does) that gate delays track to 70%, i.e., if a >> gate is at its maximum delay, no other gate on the die will have a >> delay of less than 70% of its maximum. Someone at Xilinx can correct >> me, but I believe that the actual tracking of delays on a die is far >> better than that, and that the 70% tracking number was chosen because >> there was absolutely no chance of it ever being violated. >> >> I tend to obsess over timing, but have to admit that I don't worry too >> much about Xilinx subtracting the clock skew from setup time. In >> essense, they're guaranteeing that the resulting setup time is >> correct, and that you can design to it. >> >> If you want something to worry about, wonder whether the speed files >> are correct. The nice thing is, this concern is vendor-independent >> and will never go away no matter how much you worry, something that >> can be appreciated by those of us seeking constancy in an >> ever-changing, chaotic world. >> >> Bob Perlman >> Cambrian Design Works >> >> On Tue, 08 Jan 2002 14:12:06 -0600, Kevin Brace >> <nospamtomekevinbraceusenet@nospamtomehotmail.com> wrote: >> >> >I made this posting around Chrismas, and that seems to be the reason no >> >one responded, so I am reposting the same posting again. >> > >> > >> > >> > >> >_________________________________________________________________________ >> > >> >Hi, I will like to know how the readers of this newsgroup think of >> >including clock skew for setup time analysis? >> >I am working on a PCI IP core which with various suggestions from the >> >readers of this newsgroup, I was able to improve setup timings (Tsu) >> >through reduction of logic levels (reduction of levels of LUTs). >> >I am using ISE WebPack 4.1 and targeting Spartan-II 150K system gate >> >part for my PCI IP core. >> >In ISE WebPack when I ran TRCE to generate a timing error report, the >> >timing report for setup time includes clock skew occurring, and this >> >clock skew time subtracts some time off the data path delay (data path >> >delay = gate delay + routing delay) which becomes total or final delay, >> >and the worst time here is shown in the timing summary section. >> >However, if I think carefully about the timing data shown in the report, >> >the temperature assumed here is 85 degrees celsius, and since >> >semiconductor devices have less delays in a lower temperature, at room >> >temperature (20 degrees Celsius) the clock skew will likely be much less >> >than what the report suggests, and even lower at a freezing temperature >> >(0 degrees Celsius, the lowest temperature commercial package version of >> >Spartan-II is guaranteed to function). >> >Yes, I do realize that at a temperature lower than 85 degrees Celsius, >> >the gate delays for LUTs and FFs will also decrease, therefore even if >> >the clock skew decreases that shouldn't cause a major problem, however, >> >no one really knows which one will decrease faster. >> > Another problem I can think is that in the case of Xilinx >> >devices, several Xilinx employees have written publicly in this >> >newsgroup (I know those are their own opinions, and not necessarily the >> >company's official position on the issues being raised) that whether or >> >not it is a different speed grade, all the chips come from the same >> >silicon wafer. >> >That will mean that in the case of Virtex, speed grade -4, -5, or -6 >> >devices come from the same silicon wafer. >> >I knew nothing about FPGAs two years ago, but from what I hear, Xilinx >> >first came out with Virtex speed grade -4 in 1998, and later got speed >> >grade -5 and -6 out (I don't know the exact release date of those two >> >speed grades. I will be interested to hear when they started to ship). >> >Likely most chips manufactured back in 1998 ran only at speed grade -4, >> >but as Xilinx improved the speed of Virtex through circuit and >> >manufacturing improvements, it was able to pick chips that will run at >> >speed grade -5 or -6. >> >However, there are customers who designed products in the days of Virtex >> >speed grade -4, so Xilinx still has to supply Virtex speed grade -4 to >> >the market. >> >The concern I have here is that even though the chip is marked as a >> >Virtex speed grade -4, isn't it possible that chip could have been >> >marked as a speed grade -6 device because it was manufactured recently? >> >(let's say in 2001) >> >If so, won't the clock skew assumption made during the setup time >> >analysis be off for such Virtex speed grade -4 device, perhaps by 1ns to >> >2ns depending on the device size? >> >I am not criticizing Xilinx for bin splitting devices, but I think it >> >seems risky to use maximum clock skew during setup time analysis. >> >Are there any ways to disable using maximum clock skew from being used >> >in MAP/PAR/TRCE/TimingAn? >> > >> > >> > >> >Thanks, >> > >> > >> > >> >Kevin Brace (don't respond to me directly, respond within the newsgroup) >> >> -- >> Cambrian Design Works >> digital design, signal integrity >> http://www.cambriandesign.com >> e-mail: respond to bob at the domain above. -- Cambrian Design Works digital design, signal integrity http://www.cambriandesign.com e-mail: respond to bob at the domain above.Article: 38253
Kevin, aside from your technical question, we have a semantic problem: What you call "clock skew", I ( and we at Xilinx) call "clock delay". Clock skew is the difference in clock delay to various destinations. With the DLL or DCM ( Clock Manager in Virtex-II) we can completely eliminate the clock delay on global clock lines, and we are left only with the clock delay difference, the clock skew, which is less than 100 picoseconds, even for a big chip (on Global Clock lines). Now, these techniques only work for Xilinx and Spartan-II, and they assume a free-running clock ( I suppose that is not a proper assumption for PCI ). As far as I remember, we always publish pin-to-pin set-up time numbers, explicitly for your purposes, so that users do not subtract delay values in an unrealistic way. Sorry for the confuion between delay and skew. Peter Alfke Kevin Brace wrote: > Bob, > > I guess my initial posting missed several points. > The thing I was concerned was the setup time (Tsu) for signals coming > from outside of the chip. > Here is part of a timing report that should clarify my point. > > ================================================================================ > Timing constraint: COMP "irdy_n" OFFSET = IN 7 nS BEFORE COMP "clk" ; > > 567 items analyzed, 68 timing errors detected. > Minimum allowable offset is 9.445ns. > -------------------------------------------------------------------------------- > Slack: -2.445ns (requirement - (data path - clock path > - clock arrival)) > Source: irdy_n > Destination: PCI_IP_Core_Instance_ad_Port_21 > Destination Clock: clk_BUFGP rising at 0.000ns > Requirement: 7.000ns > Data Path Delay: 11.833ns (Levels of Logic = 5) > Clock Path Delay: 2.388ns (Levels of Logic = 2) > Timing Improvement Wizard > Data Path: irdy_n to PCI_IP_Core_Instance_ad_Port_21 > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tiopi 1.224 irdy_n > irdy_n_IBUF > net (fanout=47) 1.974 irdy_n_IBUF > Tilo 0.653 PCI_IP_Core_Instance_I_XXL_1384 > net (fanout=32) 1.564 PCI_IP_Core_Instance_N2952 > Tilo 0.653 PCI_IP_Core_Instance_I_411_LUT_40 > net (fanout=1) 1.648 PCI_IP_Core_Instance_N4755 > Tilo 0.653 PCI_IP_Core_Instance_I__n0024_21 > net (fanout=1) 2.256 PCI_IP_Core_Instance_N4759 > Tioock 1.208 PCI_IP_Core_Instance_ad_Port_21 > ---------------------------- ------------------------------ > Total 11.833ns (4.391ns logic, 7.442ns route) > (37.1% logic, 62.9% route) > > Clock Path: clk to PCI_IP_Core_Instance_ad_Port_21 > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tgpio 1.082 clk > clk_BUFGP/IBUFG > net (fanout=1) 0.007 clk_BUFGP/IBUFG > Tgio 0.773 clk_BUFGP/BUFG > net (fanout=468) 0.526 clk_BUFGP > ---------------------------- ------------------------------ > Total 2.388ns (1.855ns logic, 0.533ns route) > (77.7% logic, 22.3% route) > > -------------------------------------------------------------------------------- > > -------------------------------------------------------------------------------- > 4 constraints not met. > > Data Sheet report: > ----------------- > All values displayed in nanoseconds (ns) > > Setup/Hold to clock clk > ---------------+------------+------------+ > | Setup to | Hold to | > Source Pad | clk (edge) | clk (edge) | > ---------------+------------+------------+ > ad<0> | 5.516(R)| 0.000(R)| > ad<10> | 5.691(R)| 0.000(R)| > ad<11> | 4.457(R)| 0.000(R)| > ad<12> | 4.478(R)| 0.000(R)| > ad<13> | 3.422(R)| 0.000(R)| > ad<14> | 3.916(R)| 0.000(R)| > ad<15> | 4.468(R)| 0.000(R)| > ad<16> | 3.490(R)| 0.000(R)| > ad<17> | 3.402(R)| 0.000(R)| > ad<18> | 3.470(R)| 0.000(R)| > ad<19> | 3.821(R)| 0.000(R)| > ad<1> | 4.943(R)| 0.000(R)| > ad<20> | 3.848(R)| 0.000(R)| > ad<21> | 4.427(R)| 0.000(R)| > ad<22> | 4.728(R)| 0.000(R)| > ad<23> | 3.456(R)| 0.000(R)| > ad<24> | 2.986(R)| 0.000(R)| > ad<25> | 3.444(R)| 0.000(R)| > ad<26> | 3.260(R)| 0.000(R)| > ad<27> | 3.517(R)| 0.000(R)| > ad<28> | 4.303(R)| 0.000(R)| > ad<29> | 4.606(R)| 0.000(R)| > ad<2> | 5.781(R)| 0.000(R)| > ad<30> | 3.844(R)| 0.000(R)| > ad<31> | 3.945(R)| 0.000(R)| > ad<3> | 5.734(R)| 0.000(R)| > ad<4> | 4.404(R)| 0.000(R)| > ad<5> | 5.967(R)| 0.000(R)| > ad<6> | 5.709(R)| 0.000(R)| > ad<7> | 4.880(R)| 0.000(R)| > ad<8> | 4.615(R)| 0.000(R)| > ad<9> | 3.910(R)| 0.000(R)| > c_be_n<0> | 6.539(R)| 0.000(R)| > c_be_n<1> | 6.116(R)| 0.000(R)| > c_be_n<2> | 5.946(R)| 0.000(R)| > c_be_n<3> | 7.348(R)| 0.000(R)| > frame_n | 8.493(R)| 0.000(R)| > idsel | 0.884(R)| 0.000(R)| > irdy_n | 9.445(R)| 0.000(R)| > par | 7.649(R)| 0.000(R)| > ---------------+------------+------------+ > > Clock clk to Pad > ---------------+------------+ > | clk (edge) | > Destination Pad| to PAD | > ---------------+------------+ > ad<0> | 9.840(R)| > ad<10> | 9.731(R)| > ad<11> | 9.731(R)| > ad<12> | 9.731(R)| > ad<13> | 9.733(R)| > ad<14> | 9.733(R)| > ad<15> | 9.733(R)| > ad<16> | 9.734(R)| > ad<17> | 9.733(R)| > ad<18> | 9.733(R)| > ad<19> | 9.733(R)| > ad<1> | 9.840(R)| > ad<20> | 9.734(R)| > ad<21> | 9.733(R)| > ad<22> | 9.733(R)| > ad<23> | 9.733(R)| > ad<24> | 9.731(R)| > ad<25> | 9.731(R)| > ad<26> | 9.734(R)| > ad<27> | 9.734(R)| > ad<28> | 9.774(R)| > ad<29> | 9.779(R)| > ad<2> | 9.786(R)| > ad<30> | 9.782(R)| > ad<31> | 9.784(R)| > ad<3> | 9.786(R)| > ad<4> | 9.784(R)| > ad<5> | 9.782(R)| > ad<6> | 9.779(R)| > ad<7> | 9.734(R)| > ad<8> | 9.734(R)| > ad<9> | 9.731(R)| > devsel_n | 9.731(R)| > par | 9.733(R)| > perr_n | 9.733(R)| > serr_n | 9.733(R)| > stop_n | 9.731(R)| > trdy_n | 9.734(R)| > ---------------+------------+ > -------------------------------------------------------------------------------- > > In this example, IRDY# (irdy_n) comes from outside of the chip, > goes through 3 levels of LUTs, and goes into an IOB output FF. > Some people may ask me why I don't register the input, but in my case, I > am already using a registered version of IRDY# when that is possible > like during a configuration cycle, a single transfer, or the first > transfer of a burst transfer where wait cycles are being inserted. > If wait cycles are being inserted for several cycles, the registered > version and the raw (unregistered) version signal are guaranteed to be > same by the PCI specification (unless a parity error occurs) because > once a signal is asserted, the specification doesn't allow it to change > until end of a transfer (or end of a microaccess in burst transfer). > During a no-wait cycle burst transfer, a PCI device has to see the raw > signal to determine what to do next, and from looking at the inputs > going into the above LUTs through Floorplanner, the state machine state > where no-wait burst transfer is handled is the signal path shown above. > Note that the routing delay shown in above report looks pretty bad, but > I should be able to reduce that when I floorplan the design. > If I restate my concern, the concern I have is that if a chip > that can pass testing for a Spartan-II speed grade -6 is sold as a speed > grade -5 because of yield improvement, the actual clock skew for that > chip will be reduced by about 20% (from 2.388ns (-5) to about 1.90ns > (-6)). > Yes, I guess the LUT delay will likely drop by at least 20% (when I > resynthesized my design for Spartan-II speed grade -6, the logic and > routing delay seemed to have dropped faster than the clock skew), so the > end result will be that the timings will still be met . . . I guess. > Another concern is at low temperatures, because at lower temperatures, > clock skew should decrease. > I guess logic and routing delay will also decrease, so the end result > will be that the timings will still be met . . . I guess. > I must say that the views I have here are pretty pessimistic. > I assume that the clock skew will decrease at lower temperatures, but > the LUT, DFF setup time, and routing delay will not decrease at all, > which is not true. > Should I redo the timing report analysis at lower temperature, and > believe those numbers? > What I am trying to do to some extent is that I want the data path delay > (logic + routing) to be less than 7ns, so that I don't have to worry > about clock skew being there to aid the setup time. > I realize that this becomes harder and harder to achieve as the die size > grows because the bigger chip will have more routing delay (For example, > Virtex XCV1000 will likely have much more routing delay than Virtex > XCV150 or Spartan-II XC2S150). > But my understanding which might be wrong is that the clock skew number > shown in the report is for the maximum possible clock skew. > Than because clock skew can be less than shown in the report, what is > the minimum clock skew I should expect? > > Thanks, > > Kevin Brace (don't respond to me directly, respond within the newsgroup) > > Bob Perlman wrote: > > > > Hi - > > > > I assume you're talking about setup time margins within the chip, > > i.e., both the source and destination flip-flops are on-chip. > > > > The question boils down to how well the data delay tracks the clock > > skew delay over temperature, voltage, and process. Xilinx used to > > claim (and maybe still does) that gate delays track to 70%, i.e., if a > > gate is at its maximum delay, no other gate on the die will have a > > delay of less than 70% of its maximum. Someone at Xilinx can correct > > me, but I believe that the actual tracking of delays on a die is far > > better than that, and that the 70% tracking number was chosen because > > there was absolutely no chance of it ever being violated. > > > > I tend to obsess over timing, but have to admit that I don't worry too > > much about Xilinx subtracting the clock skew from setup time. In > > essense, they're guaranteeing that the resulting setup time is > > correct, and that you can design to it. > > > > If you want something to worry about, wonder whether the speed files > > are correct. The nice thing is, this concern is vendor-independent > > and will never go away no matter how much you worry, something that > > can be appreciated by those of us seeking constancy in an > > ever-changing, chaotic world. > > > > Bob Perlman > > Cambrian Design Works > > > > On Tue, 08 Jan 2002 14:12:06 -0600, Kevin Brace > > <nospamtomekevinbraceusenet@nospamtomehotmail.com> wrote: > > > > >I made this posting around Chrismas, and that seems to be the reason no > > >one responded, so I am reposting the same posting again. > > > > > > > > > > > > > > >_________________________________________________________________________ > > > > > >Hi, I will like to know how the readers of this newsgroup think of > > >including clock skew for setup time analysis? > > >I am working on a PCI IP core which with various suggestions from the > > >readers of this newsgroup, I was able to improve setup timings (Tsu) > > >through reduction of logic levels (reduction of levels of LUTs). > > >I am using ISE WebPack 4.1 and targeting Spartan-II 150K system gate > > >part for my PCI IP core. > > >In ISE WebPack when I ran TRCE to generate a timing error report, the > > >timing report for setup time includes clock skew occurring, and this > > >clock skew time subtracts some time off the data path delay (data path > > >delay = gate delay + routing delay) which becomes total or final delay, > > >and the worst time here is shown in the timing summary section. > > >However, if I think carefully about the timing data shown in the report, > > >the temperature assumed here is 85 degrees celsius, and since > > >semiconductor devices have less delays in a lower temperature, at room > > >temperature (20 degrees Celsius) the clock skew will likely be much less > > >than what the report suggests, and even lower at a freezing temperature > > >(0 degrees Celsius, the lowest temperature commercial package version of > > >Spartan-II is guaranteed to function). > > >Yes, I do realize that at a temperature lower than 85 degrees Celsius, > > >the gate delays for LUTs and FFs will also decrease, therefore even if > > >the clock skew decreases that shouldn't cause a major problem, however, > > >no one really knows which one will decrease faster. > > > Another problem I can think is that in the case of Xilinx > > >devices, several Xilinx employees have written publicly in this > > >newsgroup (I know those are their own opinions, and not necessarily the > > >company's official position on the issues being raised) that whether or > > >not it is a different speed grade, all the chips come from the same > > >silicon wafer. > > >That will mean that in the case of Virtex, speed grade -4, -5, or -6 > > >devices come from the same silicon wafer. > > >I knew nothing about FPGAs two years ago, but from what I hear, Xilinx > > >first came out with Virtex speed grade -4 in 1998, and later got speed > > >grade -5 and -6 out (I don't know the exact release date of those two > > >speed grades. I will be interested to hear when they started to ship). > > >Likely most chips manufactured back in 1998 ran only at speed grade -4, > > >but as Xilinx improved the speed of Virtex through circuit and > > >manufacturing improvements, it was able to pick chips that will run at > > >speed grade -5 or -6. > > >However, there are customers who designed products in the days of Virtex > > >speed grade -4, so Xilinx still has to supply Virtex speed grade -4 to > > >the market. > > >The concern I have here is that even though the chip is marked as a > > >Virtex speed grade -4, isn't it possible that chip could have been > > >marked as a speed grade -6 device because it was manufactured recently? > > >(let's say in 2001) > > >If so, won't the clock skew assumption made during the setup time > > >analysis be off for such Virtex speed grade -4 device, perhaps by 1ns to > > >2ns depending on the device size? > > >I am not criticizing Xilinx for bin splitting devices, but I think it > > >seems risky to use maximum clock skew during setup time analysis. > > >Are there any ways to disable using maximum clock skew from being used > > >in MAP/PAR/TRCE/TimingAn? > > > > > > > > > > > >Thanks, > > > > > > > > > > > >Kevin Brace (don't respond to me directly, respond within the newsgroup) > > > > -- > > Cambrian Design Works > > digital design, signal integrity > > http://www.cambriandesign.com > > e-mail: respond to bob at the domain above.Article: 38254
I know it works for CLB ROM, I haven't tried it for block ROMs. For the Block ROM, I
prefer to instantiate the primitives in order to be able to specify placement, control how
the data is organized, and frequently to permit dual port access to the ROM data.
Besides, the instantiation works in any synthesizer that accepts user attributes.
Antonio wrote:
> Ray Andraka <ray@andraka.com> wrote in message news:<3C3B746B.8E1B4A72@andraka.com>...
> > Depends on your synthesizer. Synplicity can infer a ROM.
>
> Does synplify 7.02 automatically recognize the ROM and put it inside the blockram ??
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38255
And in Virtex and later families, that 16 bits of ram can also be connected as a shift register, which is really handy for long delay queues as well as being able to be used as a
reconfigurable LUT without having to go through the device reconfiguration (handy for filters with programmable coefficients, for example)
Peter Alfke wrote:
> All Xilinx FPGAs since the XC4000 days can use the 16-bit Look-up table, normally used as logic, alternatively as RAM. So, there are 16 bits of RAM in every LUT.
>
> Peter Alfke, Xilinx Applications
> ========================
> Matthias Weber wrote:
>
> > hi,
> >
> > i have read in the fgpa spezifications (preliminary product spezification v2.2) about distributed ram bits (e.g 614,400 within XCV2000E)
> > is this kind of ram for the fpgas configuration or for user specific usage (= 2 flipflops/latches in each logic cell or are they extra bits? if latter, are extra bits chosen
> > for reducing singal prpagation delays?
> >
> > thanks,
> >
> > matthias
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38256
Andy,
I instantiate the BUFGs too for a couple of reasons: a) the synthesis
inference is not always reliable from version to version of the tools and
particularly from vendor to vendor, and b) more important for me the PAR
tools will complain with certain configurations of the DLL and BUFG's if
they are not placed. I find it easier to place them once in the code than
to monkey around with them in the floorplanner everytime I make a change
in the design.
Andy Peters wrote:
> k. wrote:
>
> > I am instantiating clock buffers in ISE 4.1 using XST with the
> > following
> > code -
> >
> > component bufg
> > port (
> > i : in std_logic;
> > o : out std_logic
> > );
> > end component;
> >
> > ua : bufg
> > port map (
> > i => clk,
> > o => clk_bufg
> > );
> >
> > this will implement ok. But when I try to load the design into
> > ModelSim I get
> > the following error -
> >
> > # WARNING[1]: master.vhd(345): No default binding for component:
> > "bufg". (No entity named "bufg" was found)
> >
> > What am I missing? I've gone through the Xilinx and ModelSim
> > documentation, but I can't find anything relevent. Any help would be
> > appreciated.
>
> Why are you instantiating these components? The tool will infer them
> for you.
>
> --a
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38257
Oh,
sounds like k. is missing the unisim library reference, or perhaps has a
mismatch on signal or generic names in his/her VHDL.
Andy Peters wrote:
> k. wrote:
>
> > I am instantiating clock buffers in ISE 4.1 using XST with the
> > following
> > code -
> >
> > component bufg
> > port (
> > i : in std_logic;
> > o : out std_logic
> > );
> > end component;
> >
> > ua : bufg
> > port map (
> > i => clk,
> > o => clk_bufg
> > );
> >
> > this will implement ok. But when I try to load the design into
> > ModelSim I get
> > the following error -
> >
> > # WARNING[1]: master.vhd(345): No default binding for component:
> > "bufg". (No entity named "bufg" was found)
> >
> > What am I missing? I've gone through the Xilinx and ModelSim
> > documentation, but I can't find anything relevent. Any help would be
> > appreciated.
>
> Why are you instantiating these components? The tool will infer them
> for you.
>
> --a
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38258
It may be closing the session if it doesn't have enough room in the temp directory. I've had that happen before.
Brian Philofsky wrote:
> Hua Wang wrote:
>
> > Help!
> > Every time I launched the modelsim in ISE4.1 there was error occured. Messages displayed in the modelsim window are as follows;
> > Warning: Could not open log file vsim.wlf, using C;\document settings\...\temp\vismw10 instead.
> >
> > Problem with simulator....vsim U/I closing(2)
> >
> > Problem with simluator...vism U/I closing(1)
> >
> > Then the modelsim was terminated.
> > I have followed the instructions on Xilinx site to compile the libs of Xilinx into Modlesim.
> > Could anybody please help me solve this problem.
>
> I have seen this issue before however I have not seen it close a session before. Usually it issues the warning that it can not
> open the file (generally becuase it is locked by another program) and writes the file in your Temp directory rather than the
> project directory. Simulation then continues without closing the simulator.
>
> Be sure you are not opening more than one ModelSim session at a time. This looks like it could be you issue since the message you
> included shows ModelSim closing twice. I believe that is generally the cause of this problem. Try closing all Modelsim sessions
> on the machine. Then go into the project directory and manually delete the vsim.wlf file. This file is a waveform file saved by
> ModelSim during the simulation. Generally is not of much use to you after you have completed your simulation. Then try running
> the simulation again however only have one session of ModelSim open at a time. It is never a good idea to have two simulations
> occuring in the same project directory using the same work library as well as other files (like the vsim.wlf file). Hopefully that
> will get you going. If not, I suggest contacting Xilinx Support and see if they can figure out the problem.
>
> -- Brian
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38259Andy Peters <andy@exponentmedia.nospam.com> wrote in message news:<3C3C6D30.8070609@exponentmedia.nospam.com>... > Why are you instantiating these components? The tool will infer them > for you. > > --a because I am using the Spartan II device, which only has 4 global buffers. By instantiating the buffers myself, rather than letting ISE infer them, I can make sure they are assigned to the signals I want them assigned to.Article: 38260
allan_herriman.hates.spam@agilent.com (Allan Herriman) wrote in message news:<3c3c31dc.211570932@netnews.agilent.com>... > You should do two things: > > 1. In your source code, you need the lines: > library unisim; > use unisim.vcomponents.all; > > 2. Use Modelsim create a library called "unisim". Compile the > following unisim source files into it: > unisim_vcomp.vhd > unsim_vpkg.vhd > unisim_vital.vhd > You'll be able to find these files in your Xilinx software > installation. > > Regards, > Allan. Thanks! That worked a treat. :)Article: 38261
In article <3C3CB954.30406@yahoo.fr>, Gacquer William
<wgacquer@yahoo.fr> writes
>Thanks for your answer.
>
>It's for video purpose.
>The CCDs are :
>- area
>- colour
>- interline transfer
>- electronic shutter
>
>I do not fully understand your questions about the clocks,
Some specialised CCD parts have multi-phase transfer clocks. It
is fairly unusual today.
> the number of video outputs
Large CCDs for instrumentation applications sometimes have
multiple analogue output taps on the output shifter -
typically at 25%, 50%, 75% and 100% positions - thereby
allowing faster readout.
>and the quasi-random readout (what is it ?)
In an area CCD: You can read a small horizontal "stripe" of the
frame very quickly by clocking the line (vertical) transfer clock
repeatedly - this accumulates the sum of several lines
into the horizontal shift register - then you can manipulate the
column anti-blooming voltage to dump all that accumulated charge -
then go on reading as normal.
>Is it feasible to synchronize CCD readouts ? (what is the uncertainty ?)
As I suggested, you can run several CCD devices from common clock
signals and they are then synchronised to better than one pixel time.
However, they will need independent shutter control and this of course
will affect the integration timing.
>Which CCD vendor would you recommend for 60 FPS digital video at a
>resolution of 800x600 (for instance) in outdoor conditions? I am not
>looking for the CCD itself but also for the companion chips as you
>mentionned.
It is many years since I needed to buy CCD chips and drivers. But
I suggest you look at Sony first - I found they were the most
helpful in providing data. Also look at www.glyn.com who are
a specialist distributor of Japanese parts; they can often supply
CCD chips and support devices in small quantities.
For specialist (instrumentation) parts you should look at Dalsa
and also Fairchild Imaging (their name has changed - I think
it's now called Loral). But these parts are VERY expensive.
Good luck. This kind of thing is often difficult for
hobby or academic workers because the CCD market is dominated
by high-volume users (digital camera makers, etc) and the device
vendors are not interested in small volume customers.
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 38262Hi all, I'm trying to create modules with WebPACK, and mix them later in other designs. I can do it if all modules and higher level designs are in Verilog (or VHDL), but I want to export modules to EDIF and include them in the higher level design, made in Verilog too. The WebPACK produces EDIF files (*.edn) properly, and the ISE 4.1 can implement them if all the design is in EDIF format. But I want to create in verilog a high level design and include those modules in EDIF format (I don't want to give to the final users the original source code ;-/). All I get is that ISE 4.1 (or my installation of it) cannot do such thing. Would anyone help me? Is this approach correct or these things are usually done in other way? Thanks in advance, Santiago (sanpab@eis.uva.es).Article: 38263
Hi everyone I am looking for a fast 32 bit barrel shifter for APEX20K400E, I use the LPM from Altera, but after P&R, I found it ocuppy three MegaLAB, and many wire run between them. so I think if somebody have hand place the shifter?Article: 38264
Hi there, I know ISE Foundation 4.1 for Win NT. After installing Alliance 4.1 for Solaris (with SP3) there is no design flow except EDIF in project navigator. With the installation manual I got Leonardo Spectrum flow to run. I don't find any information about the XST flow under Solaris. Isn't it supported or went installation wrong? Thanks. MatthiasArticle: 38265
On previous releases of the tool, we were required to delete the "corelib.xml" file in the $XILINX/coregen/ip directory. I could not find this file on the new version of the tool (v4.1i) does anyone know if this step is still needed? -- Alfredo, FPGA Support Group. Nortel Networks.Article: 38266
Rick Filipkiewicz wrote: > In many ways its even better than that since FPGAs allow an evolutionary approach to > design. This has some big benefits in allowing s/w development to start earlier. You > can even apply the evolutionary thing to the device's timing - in some cases. Yup. The only issue is that feature creep sometimes tends to be a problem with FPGAs. Since everyone knows you can make changes at any time, attempts will be made to throw in new features near the end of the design cycle. Yuck! Having worked on ASICs and FPGAs each has their own strong points. Virtex2 is really nice but quite a few of our desgins just won't work in it. > There's also something on the budgetary side that's been missed out. ASIC design tools > (synthesisers, simulators, layout tools, etc.) are MUCH more expensive than the > corresponding ones for FPGAs. I believe its normal in ASIC design to have several > "seats" for each of these wich is going to burn another couple of $100K of investment. Well you need a simulator no matter what. The ASIC design house typically does the layout for you (thats what part of the NRE is for) so there is no need for layout tools. Now the synthesiser you are right, synopsys is not cheap. A static timing tool is usally required as well. MD -- Martin Darwin ASIC Design Engineer Tel +1 (613) 784-8873 Alcatel CanadaArticle: 38267
Should have read the entire "Installation Guide". Page 1-4 says: XST is supported for Foundation only. But why, when it is even in WebPack ?! Matthias Scheerer wrote: > > Hi there, > > I know ISE Foundation 4.1 for Win NT. After installing Alliance 4.1 for > Solaris (with SP3) there is no design flow except EDIF in project > navigator. With the installation manual I got Leonardo Spectrum flow to > run. I don't find any information about the XST flow under Solaris. > Isn't it supported or went installation wrong? > > Thanks. > MatthiasArticle: 38268
Article: 38269
155 MHz is not hard to achieve in a VirtexE (any speed grade), but you do have
to be careful about how the design is implemented, particularly making sure that
you don't have lots of levels of logic. You will likely need to do some
floorplanning to get the speed, especially when reading from the BRAMs. If you
are accessing the BRAMs at 155 MHz, you will need registers immediately adjacent
to the BRAM with no LUTs between the BRAM and the registers, and you will have
to floorplan those to place them there. Depending on how wide the BRAMs are,
you may not be able to read them at 155MHz in a -6 or if 16 bits wide, even a -7
part. One solution may be to run the BRAM at half the clock rate and read/write
two locations per clock by using a set of staging registers.
The first step, of course, is to look at the timing report to see where your
design is not meeting the timing. Once you do that, you'll know where you need
to focus your attention.
"H.L" wrote:
> Hello all,
>
> I have to program a Virtex-E FPGA at 155MHz. For this purpose I use 8 vhdl
> entities,a MUX BUS and a Block RAM from the CORE GENERATOR (I use XILINX ISE
> 4.1 with SP2). I use for synthesis FPGA EXPRESS 3.6.1 , so I create a fpga
> express project where I add the vhdl sources and the 2 edn files (the one
> for the mux bus and the one for the block ram), is this the correct
> procedure? I manage to export the netlist for my design but in the PAR
> process I get too many timing errors!!!
>
> Thanks a lot
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38270
Hi,
I'm working for my final project at the Swiss Federal Institute of
Technology (ETH Zuerich). The main goal of the project is to develop a
reconfigurable system on an single FPGA (XCV800 on a XESS-Board)
consisting of a processor core and several virtual components which
can be added and removed to the system dynamically. We use JBits for
the partial reconfiguration.
We want to do this with the following steps:
1)
Generating (standard flow with Xilinx-Tools) a static design with
the processor core and a place-holder for the virtual component (empty
area or maybe an anti-core).
2) Replacing the place-holder with the desired virtual component and
connecting it to the static part using partial configuration with JBits.
We managed to floor-planning the design in the first step that the
place-holder is at a defined position. Our problem now is, that there
are some disturbing lines (nets from the processor core to IOBs)
through this area.
One way to get rid of them is to manually reroute them with FPGA-Editor,
what we did with an effort for the first approach. But we'll have to do
this every time the static design changes (still isn't so static). We
are looking for a more flexible solution which can be automated.
Is there another way to avoid routing through a certain area? To my
knowledge there aren't any area-constraints for routing not either in
JRoute. The anti-cores on the other hand reserve only a part of the
routing resources, so there isn't either a guarantee that no route will
go through.
Used Hard-/Software:
FPGA: Xilinx XCV800HQ240
Board: XESS XSV800 V1.1
Software: Xilinx Foundation Series 3.1i (3.3-08i)
Synthese: FPGA Express 3.5
JBits: v 2.8
Thanks
==========================================================================
Matthias Dyer EMail: mdyer@ee.ethz.ch
Swiss Federal Institute of Technology Zurich
Computer Engineering and Networks Laboratory
==========================================================================
Article: 38271
If your bus mux is connected directly from the BRAMs and you only have latency
of 1, then that is a problem. If you look at the Tcko of the BRAMs, you'll find
that it is pretty long compared to other delays in the chip. Add to that the
fact that routing around the BRAMs is usually pretty congested (especially if
you are using the BRAMs as 32 bits wide), plus your routing through several
layers of logic before hitting a flip-flop. You need to put an additional
pipeline register between the BRAM and your bus mux. You will also have to
floorplan those flip-flops to be immediately adjacent to the BRAM. With 32 bits
wide, You are going to have to avoid using the BRAMs on the edges of the chips,
as it gets too congested there to put the registers close enough to the BRAMs.
Even then, you may find that you need to use narrower data paths to the BRAMs to
get enough fast connections from the BRAM. If you are using the BRAM ENA or WE,
be aware that those inputs have a long set up time too, so the driving flip-flop
has to be right there. Those inputs are actually even more critical than the
data read path. In high performance stuff, I try to keep those inputs wired to
constants and control the read/write address counters instead.
"H.L" wrote:
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3C3DB8F1.48F10CD1@andraka.com...
> > 155 MHz is not hard to achieve in a VirtexE (any speed grade), but you do
> have
> > to be careful about how the design is implemented, particularly making
> sure that
> > you don't have lots of levels of logic.
>
> In the timing errors the max levels of logic is 6, is this good?
>
> You will likely need to do some
> > floorplanning to get the speed, especially when reading from the BRAMs.
> If you
> > are accessing the BRAMs at 155 MHz, you will need registers immediately
> adjacent
> > to the BRAM with no LUTs between the BRAM and the registers, and you will
> have
> > to floorplan those to place them there. Depending on how wide the BRAMs
> are,
> > you may not be able to read them at 155MHz in a -6 or if 16 bits wide,
> even a -7
> > part. One solution may be to run the BRAM at half the clock rate and
> read/write
> > two locations per clock by using a set of staging registers.
>
> I use 3 BRAMS (128x32) at 155MHz , I have 3 modules that access them so I
> use BUS MUXs for the memory arbitration (the BUS MUXs is LUT based and
> registered with latency 1), all 3 modules use a fsm to read and write to
> the BRAMs. Do you think that the logic is total wrong? In the functional
> simulation all seem well (if that counts :)) )
> In the timing errors I get that the total delay is mostly owing to route
> (70% route - 30% logic), do you think that with floorplanning I will be able
> to decrease the delays?
>
> Thank you very much for the help , I am new into these :)
>
> >
> > The first step, of course, is to look at the timing report to see where
> your
> > design is not meeting the timing. Once you do that, you'll know where you
> need
> > to focus your attention.
> >
> >
> >
> > "H.L" wrote:
> >
> > > Hello all,
> > >
> > > I have to program a Virtex-E FPGA at 155MHz. For this purpose I use 8
> vhdl
> > > entities,a MUX BUS and a Block RAM from the CORE GENERATOR (I use XILINX
> ISE
> > > 4.1 with SP2). I use for synthesis FPGA EXPRESS 3.6.1 , so I create a
> fpga
> > > express project where I add the vhdl sources and the 2 edn files (the
> one
> > > for the mux bus and the one for the block ram), is this the correct
> > > procedure? I manage to export the netlist for my design but in the PAR
> > > process I get too many timing errors!!!
> > >
> > > Thanks a lot
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38272Matthias Dyer wrote: > > Hi, > > I'm working for my final project at the Swiss Federal Institute of > Technology (ETH Zuerich). The main goal of the project is to develop a > reconfigurable system on an single FPGA (XCV800 on a XESS-Board) > consisting of a processor core and several virtual components which > can be added and removed to the system dynamically. We use JBits for > the partial reconfiguration. > > We want to do this with the following steps: > > 1) > Generating (standard flow with Xilinx-Tools) a static design with > the processor core and a place-holder for the virtual component (empty > area or maybe an anti-core). > > 2) Replacing the place-holder with the desired virtual component and > connecting it to the static part using partial configuration with JBits. > > We managed to floor-planning the design in the first step that the > place-holder is at a defined position. Our problem now is, that there > are some disturbing lines (nets from the processor core to IOBs) > through this area. > > One way to get rid of them is to manually reroute them with FPGA-Editor, > what we did with an effort for the first approach. But we'll have to do > this every time the static design changes (still isn't so static). We > are looking for a more flexible solution which can be automated. > > Is there another way to avoid routing through a certain area? To my > knowledge there aren't any area-constraints for routing not either in > JRoute. The anti-cores on the other hand reserve only a part of the > routing resources, so there isn't either a guarantee that no route will > go through. > > Used Hard-/Software: > FPGA: Xilinx XCV800HQ240 > Board: XESS XSV800 V1.1 > Software: Xilinx Foundation Series 3.1i (3.3-08i) > Synthese: FPGA Express 3.5 > JBits: v 2.8 > > Thanks I have not seen any way to do this. The two missing pieces in design for partial reconfiguration are "keep routes in this area" and "keep routes out of this area". To the best of my knowledge, Xilinx does not support either one in any way. I like the idea of an "anti-core". I assume you are defining blocks of the chip that are "pre-routed", but will be removed from the actual routed file before it is finallized. It might be possible to tie up all of the routing resources on the periphery of the "anti-core". For a wire to get into the block, it must pass through the edge. But then I guess there are any number of wires that lead into a block at different levels so this is still not an easy task. If you find a way to get this working, I would be very interested in how to do it. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 38273
Nachiket Kapre wrote: > Hello, > I am currently in a project which uses Spartan FPGA and need to know > how to program it. Can I make my own version of the Parallel Cable III > and use it to program via the JTAG pins(i have a schematic from the > xilinx website). Or if I decide to use a Serial PROM ,how can i get it > programmed?...is a ciruit schematic avaiable for the same? Or are > there any other programming options that i havent considered? For development (lab) work, I made up a simple circuit using a Xilinx CPLD (9572, overkill, but we use them in another product) that converts a standard, byte-wide EPROM like a 27C512 to look like a Xilinx-type serial EPROM. It has an address counter, and a bit shift register. I made sure the bit and address ordering was such that programming it with a file created by the PROM formatter program would correctly load the FPGA. (A logic analyzer is handy to compare the first 3 bytes or so with that they are supposed to be.) This is what I use when spinning the design cycle in actual hardware. It plugs into the 8-pin DIP socket where the Xilinx serial PROM goes in the final system. I made sure to get a PROM programmer that would handle both 27Cxxx EPROMS and the Xilinx 17128 and similar serial PROMS. I use the Xeltek Superpro/Z, which was about $245. JonArticle: 38274
Peter Alfke wrote: > Contemplate only the -XL versions, since 5-V is now a dead-end street. Arrgh! Yes, of course, in PCs and other computer gear, 3.3 (and lower) voltages are the thing. But, there are a LOT of us out here still forced (by existing equipment or non-digital components we are interfacing with) to work at 5 V. Please don't abandon us! The Spartan line is going to be good for us for many projects, as long as we can still get them! Jon
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