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
Hi all, I'am looking for information on some experience using the Triscend solution including ARM7+SDRAM Controller + System Glue and the FPGA core... To what can you compare the Triscend Logic Block in the FPGA? Has somebody allready used those chips successfully in a real application? Is there a plan for a new familiy inlcuding an MMU on chip? thank's markusArticle: 38226
1Article: 38227
Hello has anybody tried to connect a FPGA to several CCDs ( for imaging purpose, of course ? ) I am new to FPGA programming. Regards, William GacquerArticle: 38228
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, > > matthiasArticle: 38229
Anthony, The basic algorithms themselves are detailed in the standards. The ITU-T G series for Europe (and the rest of the world), or the ATIS "T1 Committee" standards for the US. Check out the IP cores that Xilinx offers for easy guaranteed compliance with these standards. Austin Anthony Ellis wrote: > Hi, > > We are interested in implementing ADPCM in an FPGA. Any idea where one can > get the algorithms (tested) for this compression technique? > AnthonyArticle: 38230
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: 38231
In article <3C3C5C80.5080702@yahoo.fr>, Gacquer William
<wgacquer@yahoo.fr> writes
>Hello
> has anybody tried to connect a FPGA to several CCDs ( for imaging
>purpose, of course ? )
Linear or area (2-D) CCD? Colour or monochrome? Interline
transfer or frame transfer? Electronic shutter or not?
Single-phase or polyphase clocks? Single or multiple video
outputs? Do you need quasi-random readout?
If all the CCDs are the same type, you can generate common timing
signals for all of them; but you will still need separate
drivers (level shifters) for each device, because of the very heavy
capacitive load presented by the CCD clock pins. And you will
need separate signals to control electronic shutter on each device,
unless all CCDs are operating in the same optical environment.
Similarly the timing signals for your A/D converters can perhaps
be common for all CCDs, although this will not work if you are
aiming to use a single A/D converter to support all your
CCDs.
Linear CCDs are fairly easy to drive. The clock signals are
not very complicated. But area CCDs require complicated
clock sequences (especially colour devices) and it is usually
much easier to use the dedicated drive LSI chips provided by
the CCD vendor. Sometimes the vendor does not provide full
details of the required clocks, and therefore you are forced
to use their proprietary control chips.
--
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: 38232This is a multi-part message in MIME format. --------------C3638F3F6EF1FBD4BF266090 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If you are targeting Virtex-E, there is a pretty cool page on the Xilinx web site explaining each of these data path types at http://support.xilinx.com/applications/web_ds/ It is called the Interactive Data Sheet and can be set up for your exact target device and I/O standards. My understanding is a Virtex-II and Spartan-IIE version is in the works but I do not know when it will be released. Otherwise, the timing section of the data sheet contains a brief description of each path however is not as visual as the interactive datasheet. -- Brian Richard Padovan wrote: > Where can I find a list explaining all the delay types detailed in the > Timing Analyser report file ? Sure most are self-explanatory but some > not: eg Tf_fgm.Article: 38233
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. --aArticle: 38234
This is a multi-part message in MIME format. --------------1FDBD6B7FEAA4CC2F2049E73 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. -- BrianArticle: 38235
"axilon" <axilon@attbi.com> schrieb im Newsbeitrag news:3C3BE93D.8050002@attbi.com... > How can I relate the package pin names and Slice XY locations in Xilinx > Virtex2 device? I need it to put LOC constraint to IOB. > I looked into the pinout_text_files at DataSource CD-ROM but its > Slice X/Y Location data doesn't match with Physical names appeared at > FPGA editor screen. For an example, in 2v40cs144.txt file, X15Y14 > location has 6 pads (PAD21-PAD26) - that doesn't make sense since > each Slice location can have max 4 pads. Am I just discovered > documentation error? No. Dont mix up Slices with IO Cells. If you want to move some signals to specific IO-Pins, just use a LOC constraint like NET mysignalname LOC ="P100"; Watch out, the Signal names dependes on the package, BGAs are different from TQFPs. If you want an IO FlipFlop to be placed inside an IOB, just use NET mysignalname IOB=true; -- MfG FalkArticle: 38236
<swan> schrieb im Newsbeitrag news:ee740b2.2@WebX.sUN8CHnE... > isnt it high time that xilinx introduce a better solution for doing that? There are more complete solutions from Xilinx, but I havent used them yet. The "classic" configuration sequence via serial/parallel mode is detailed explained in the datasheets. > i really wonder if xapp 58 has really helped anyone Yes, we used it in a project. Successfull ;-) And are using it right now in another project. Hopefully successfull ;-) -- MfG FalkArticle: 38237
dotty1319 wrote: > ngdbuild -p xc9572-7-pc84 -uc re.ucf -dd .. > c:\xilinx\active\projects\re\re.edf re.ngd > Release 3.3.08i - ngdbuild D.27 > Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved. > > Command Line: ngdbuild -p xc9572-7-pc84 -uc re.ucf -dd .. > c:\xilinx\active\projects\re\re.edf re.ngd > > Launcher: Executing edif2ngd "c:\xilinx\active\projects\re\re.edf" > "C:\Xilinx\active\projects\re\xproj\ver1\re.ngo" > Release 3.3.08i - edif2ngd D.27 > Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved. > Writing the design to > "C:/Xilinx/active/projects/re/xproj/ver1/re.ngo"... > Reading NGO file "C:/Xilinx/active/projects/re/xproj/ver1/re.ngo" ... > Reading component libraries for design expansion... > > Annotating constraints to design from file "re.ucf" ... > > Checking timing specifications ... > > Checking expanded design ... > FATAL_ERROR:StaticFileParsers:Xml_Node.c:358:1.12.8.2 - Corrupt or > missing Xml > conversion files. Process will terminate. To resolve this error, > please > consult the Answers Database and other online resources at > http://support.xilinx.com You should ask this question directly of our support hotline, or go to the URL listed above. That said, my hunch would be that you have an installation problem. This is definitely NOT a user error, i.e., there is nothing in your design causing it. It's an issue with not having all the necessary files for the application installed in the correct location. In this case, I would hazard the guess that the files that are missing are those in (or that should be in) your XILINX/data/xml directory. I just checked my iSE 4.1 install, and I've got 171 files in there with a .cnv file extension. -Dennis McCrohan, Xilinx CPLD S/W [Speaking for myself, and not for Xilinx....]Article: 38238
The Virtex series devices have mux selects (F5 and F6 muxes) that allow additional control. The BX inputs from adjacent slices control the F5 muxes in each slice - selecting the output of two CLBs in a slice - and the BY input controls the F6 mux in the slice with the output, selecting the two F5 mux results. Two BXs and one BY pad out to 19. Matthias Weber wrote: > hi, > > the architectural description of xilinxs fpga explains, that 4 logic cells of a CLB can be combined for executing selected functions up to 19 inputs. > before it is explained that the function generator of each logic cells works with 4 inputs. thus there are all in all 16 inputs at each CLB. > where are the last 19 - 16 = 3 inputs are comming from? are the carry inputs used? > > thanks, > > matthiasArticle: 38239
In my opinion, Xilinx messed up when creating their coordinate systems. They could have easily created a system in which the BRAM, slice, and IOB coordinates were all related, but they refused to do so. The result makes the creation of placement scripts extremely difficult. For example, if you wish to make a script that places registers next to a BRAM, it is very difficult, because there is no relation between the BRAM at x,y and the coords of the slice that surround it. In fact, this is even different for every part. The same is true for the IOBs that sit next to slices. A better coordinate system would have helped a lot in the development of cores which can be placed anywhere in any part. Instead, if you have a core that requires IOBs close to core slices, you can't include the IOB relative locations in the core and have to hand-place for each situation. That's not how a core is supposed to work. "axilon" <axilon@attbi.com> wrote in message news:3C3BE93D.8050002@attbi.com... > How can I relate the package pin names and Slice XY locations in Xilinx > Virtex2 device? I need it to put LOC constraint to IOB. > I looked into the pinout_text_files at DataSource CD-ROM but its > Slice X/Y Location data doesn't match with Physical names appeared at > FPGA editor screen. For an example, in 2v40cs144.txt file, X15Y14 > location has 6 pads (PAD21-PAD26) - that doesn't make sense since > each Slice location can have max 4 pads. Am I just discovered > documentation error? > Can any Xilinx folks out there answer my question? > TIA > Ax >Article: 38240
dotty1319 wrote: > ngdbuild -p xc9572-7-pc84 -uc re.ucf -dd .. > c:\xilinx\active\projects\re\re.edf re.ngd > Release 3.3.08i - ngdbuild D.27 > Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved. > > Command Line: ngdbuild -p xc9572-7-pc84 -uc re.ucf -dd .. > c:\xilinx\active\projects\re\re.edf re.ngd > > Launcher: Executing edif2ngd "c:\xilinx\active\projects\re\re.edf" > "C:\Xilinx\active\projects\re\xproj\ver1\re.ngo" > Release 3.3.08i - edif2ngd D.27 > Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved. > Writing the design to > "C:/Xilinx/active/projects/re/xproj/ver1/re.ngo"... > Reading NGO file "C:/Xilinx/active/projects/re/xproj/ver1/re.ngo" ... > Reading component libraries for design expansion... > > Annotating constraints to design from file "re.ucf" ... > > Checking timing specifications ... > > Checking expanded design ... > FATAL_ERROR:StaticFileParsers:Xml_Node.c:358:1.12.8.2 - Corrupt or > missing Xml > conversion files. Process will terminate. To resolve this error, > please > consult the Answers Database and other online resources at > http://support.xilinx.com I think there was another thread on this topic some months ago. Try looking at the archives: http://www.fpga-faq.com generously hosted by Phillip Freidin.Article: 38241
To the best of my knowledge, the Virtex chips are nearly pin identical with the Spartan II family. The only difference is the temperature sense diode was intended to be replaced with a power down function, but was removed from the final design and is now a pair of No Connects. As I look at the pinouts for the Spartan IIE family, I don't see the same level of pin compatiblity with the Virtex E family. Am I not reading the docs correctly, or are the pinouts different between these two families? I thought I had a solution to my problems with the power supply surge current of the Spartan II chips. I only need a (relatively) small number of 5 volt tolerant IOs in this design (~90). So I could split the FPGAs into an XC2S using an LDO from the 3.3 supply and a XC2Se running off the DSP core supply at 1.8 volts. By using different power voltages, the separate on board regulators could provide the high surge current each part needed and keep the total parts cost to a reasonable level for the standard board. But I am also looking for the option of using a higher density part in the XC2Se socket to be able to provide a lot of FPGA density for customers who want to roll their own FPGA designs. But it looks like the XC2Se is not pin compatible with the XCVe parts... Am I back to the drawing board??? -- 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: 38242
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 There's the other option of specifying a .wlf on the vsim command line. This is useful since it avoids c:/temp getting cluutered up with 100s of waveform files, one for each restart/run.Article: 38243
rickman wrote: > To the best of my knowledge, the Virtex chips are nearly pin identical > with the Spartan II family. The only difference is the temperature sense > diode was intended to be replaced with a power down function, but was > removed from the final design and is now a pair of No Connects. > > As I look at the pinouts for the Spartan IIE family, I don't see the > same level of pin compatiblity with the Virtex E family. Am I not > reading the docs correctly, or are the pinouts different between these > two families? > > I thought I had a solution to my problems with the power supply surge > current of the Spartan II chips. I only need a (relatively) small number > of 5 volt tolerant IOs in this design (~90). So I could split the FPGAs > into an XC2S using an LDO from the 3.3 supply and a XC2Se running off > the DSP core supply at 1.8 volts. By using different power voltages, the > separate on board regulators could provide the high surge current each > part needed and keep the total parts cost to a reasonable level for the > standard board. But I am also looking for the option of using a higher > density part in the XC2Se socket to be able to provide a lot of FPGA > density for customers who want to roll their own FPGA designs. But it > looks like the XC2Se is not pin compatible with the XCVe parts... Am I > back to the drawing board??? > I was just about to investigate the same idea. Looks like we've been bitten by the marketing dept.Article: 38244
Rick Filipkiewicz wrote: > > rickman wrote: > > > To the best of my knowledge, the Virtex chips are nearly pin identical > > with the Spartan II family. The only difference is the temperature sense > > diode was intended to be replaced with a power down function, but was > > removed from the final design and is now a pair of No Connects. > > > > As I look at the pinouts for the Spartan IIE family, I don't see the > > same level of pin compatiblity with the Virtex E family. Am I not > > reading the docs correctly, or are the pinouts different between these > > two families? > > > > I thought I had a solution to my problems with the power supply surge > > current of the Spartan II chips. I only need a (relatively) small number > > of 5 volt tolerant IOs in this design (~90). So I could split the FPGAs > > into an XC2S using an LDO from the 3.3 supply and a XC2Se running off > > the DSP core supply at 1.8 volts. By using different power voltages, the > > separate on board regulators could provide the high surge current each > > part needed and keep the total parts cost to a reasonable level for the > > standard board. But I am also looking for the option of using a higher > > density part in the XC2Se socket to be able to provide a lot of FPGA > > density for customers who want to roll their own FPGA designs. But it > > looks like the XC2Se is not pin compatible with the XCVe parts... Am I > > back to the drawing board??? > > > > I was just about to investigate the same idea. Looks like we've been bitten > by the marketing dept. Actually, I would bet this is the engineering department. I did not do a thorough comparison to see exactly what has changed (very, very tedious) but I did notice that some ground pins are have moved to power pins. It looks like they use thee power pins for each bank of IO pins on the XC2Se rather than the two power pins on the XCVe. I would guess that they had some trouble with power decoupling or other dv/dt effects from the power rather than the typical ground bounce effects that they had been so worried about. So rather than to stick with the devil that you know, they decided to add a new one :) It would have been nice to be able to offer one board with the dual build approach. -- 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: 38245
Jonathan Bromley wrote: > In article <3C3C5C80.5080702@yahoo.fr>, Gacquer William > <wgacquer@yahoo.fr> writes > >>Hello >> has anybody tried to connect a FPGA to several CCDs ( for imaging >>purpose, of course ? ) >> > > Linear or area (2-D) CCD? Colour or monochrome? Interline > transfer or frame transfer? Electronic shutter or not? > Single-phase or polyphase clocks? Single or multiple video > outputs? Do you need quasi-random readout? > > If all the CCDs are the same type, you can generate common timing > signals for all of them; but you will still need separate > drivers (level shifters) for each device, because of the very heavy > capacitive load presented by the CCD clock pins. And you will > need separate signals to control electronic shutter on each device, > unless all CCDs are operating in the same optical environment. > > Similarly the timing signals for your A/D converters can perhaps > be common for all CCDs, although this will not work if you are > aiming to use a single A/D converter to support all your > CCDs. > > Linear CCDs are fairly easy to drive. The clock signals are > not very complicated. But area CCDs require complicated > clock sequences (especially colour devices) and it is usually > much easier to use the dedicated drive LSI chips provided by > the CCD vendor. Sometimes the vendor does not provide full > details of the required clocks, and therefore you are forced > to use their proprietary control chips. > 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, the number of video outputs and the quasi-random readout (what is it ?) Is it feasible to synchronize CCD readouts ? (what is the uncertainty ?) 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. Best regards William GacquerArticle: 38246
We need to buy 8 ALtera APEX20K chips with resonable price. Please email me (mthan@divio.com) information. THank you for your help.Article: 38247
Following up on my difficulties in doing dynamic digital writes, I created a VI that seemed to be along the right lines. I do a DIO Config and a Digital Clock config outside my data-generation While loop. Inside the loop, I have a Digital Single Write followed by a Digital Buffer Control with the start argument to start the transfer. But no matter what value I pass to the Digital Buffer Control for the number of updates, it errors out with a -10010 error. I tried putting the Digital Buffer Control before the Single Write, and after, neither of which made any difference. I tried setting it to the value I set in the DIO Config. I tried 0, 1, 2, and 4. In desperation I even tried a looping iteration through incremental values of the number of updates, hoping to hit a valid value by brute force, none of which worked. I also thought about the possibility that maybe Digital Single Write doesn't require Digital Buffer Control. But when I did that, the DIO-32HS would never write the data bits at all. Instead, writes would stack up for each successive iteration, until the loop died at iteration 16 (presumably because the DIO-32HS' internal FIFO overflowed). So what do I need to do to get Digital Single Write to actually write the words? Alex Rast arast@inficom.com arast@qwest.netArticle: 38248
Hi Kevin, The 4.1i release (SP2 needed) contains a new feature that you may find useful. It supports a new grid system called the RPM Grid. It's a combined grid system that allows you to create heterogeneous relocatable RPMs. With the standard grid, if you created an RPM with BRAMs , Slices and IOBs, the relative locations between the different component types would shift as the macro was moved. This doesn't occur with the RPM Grid. To use the new grid system, create the RPM as usual, but using the alternative coordinate system. The RPM needs to also contain the attribute "RPM_GRID=GRID" to identify the coordinate system. This attribute can be placed on any symbol in the macro. The coordinate system can be viewed in FPGA Editor. If you select a Site in FED, note that an RPM_GRID coordinate is printed in the history window. Sorry, there's no documentation yet. I'm working on an appnote. Regards, Bret Wade Xilinx Product Applications Kevin Neilson wrote: > In my opinion, Xilinx messed up when creating their coordinate systems. > They could have easily created a system in which the BRAM, slice, and IOB > coordinates were all related, but they refused to do so. The result makes > the creation of placement scripts extremely difficult. For example, if you > wish to make a script that places registers next to a BRAM, it is very > difficult, because there is no relation between the BRAM at x,y and the > coords of the slice that surround it. In fact, this is even different for > every part. The same is true for the IOBs that sit next to slices. A > better coordinate system would have helped a lot in the development of cores > which can be placed anywhere in any part. Instead, if you have a core that > requires IOBs close to core slices, you can't include the IOB relative > locations in the core and have to hand-place for each situation. That's not > how a core is supposed to work. > > "axilon" <axilon@attbi.com> wrote in message > news:3C3BE93D.8050002@attbi.com... > > How can I relate the package pin names and Slice XY locations in Xilinx > > Virtex2 device? I need it to put LOC constraint to IOB. > > I looked into the pinout_text_files at DataSource CD-ROM but its > > Slice X/Y Location data doesn't match with Physical names appeared at > > FPGA editor screen. For an example, in 2v40cs144.txt file, X15Y14 > > location has 6 pads (PAD21-PAD26) - that doesn't make sense since > > each Slice location can have max 4 pads. Am I just discovered > > documentation error? > > Can any Xilinx folks out there answer my question? > > TIA > > Ax > >Article: 38249
[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] Hello, Maxlock's PCI cores are not free, however by filling in the request forms you can obtain an evaluation copy for assessment. (However if you wanted to use it in any projects you'd have to license it off them). PC
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