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
gnu.org has many tools like the editbin - hex editors abound Andrew Marlboro wrote: > Hi all, > the error message like this : > > FATAL_ERROR:Map:Portability/export/Port_Main.h:116:1.17 -This > application has discovered an exceptional condition from which it > cannot recover.Process will terminate. To resolve this error, please > consult the Answers Database... > > Xilinx answer to use "editbin" from msvc++ sdtudio-6.0.... but I dont > have such thing..., download map.exe from xilinx still give same > error. How to get around it? please...I think the error ocurs with > this particular design only, I try other projects it works fine,... > what's the true story about this? > > many thanks >Article: 58351
hi The solution for this is to set XIL_MAP_LOCWARN=1 but where do I do this , can someone help me?? Thanx ParaagArticle: 58352
I guess I may be missing something. When I asked about partial reconfiguration, I was told that the part must first be loaded with a full download before it can be *partially* reconfigured. Is this not correct? If it is correct, then this method would seem to require that before you can use a compressed bitstream file, you would need to load a full sized bitstream for the decompression engine. Perhaps the method I was enquiring about is somehow different. I was looking into modular designs with partial reconfiguration. Austin Lesea wrote: > > Symon, > > Great idea! I will pass it along. To use a soft core is, as you point out, best, as one can > tailor it to the best method of decompression! > > By the way, since you have disclosed this, there is nothing to prevent any of our customers from > doing this, now. Heck, one could use the PPC in an amazingly complex decompression to unravel the > bitstream in a virtex II pro .... > > Austin > > Symon wrote: > > > Hey Austin, > > How about an App note/ Tech exclusive showing how to do > > configuration bitstream decompression using the ICAP present in some > > of your parts? The configuration stream first loads the FPGA with a > > small decompression engine. This engine then decompresses the rest of > > the bitstream and loads the rest of the FPGA through the ICAP. This > > way, you (Xilinx) get to demonstrate partial configuration and the > > ICAP. We (the customers) get a way to compress bitstreams if needed. > > You're not selling a tool, it's an app note. > > It also is better than a 'hard' solution, as you can update the > > decompression engine as new ideas are tried. You could start with run > > length encoding and add more complex stuff later. Users could develop > > their own, depending on their requirements. > > As mentioned on comp.arch.fpga passim, you can alter many bits > > with SEUs without affecting the logic design, this would imply to me > > significant compression is possible. > > cheers, Syms. > > > > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F1462AB.B2CEE7A7@xilinx.com>... > > > Nick, > > > > > > It is really hard to sell a tool that only works sometimes (in fact, it does more > > > damage to do so, than to just not use that tool). > > > > > > Thus, until we have a really robust method of compression that works across > > > thousands of bitstreams, we will stick to the easy method that we use now > > > (suppressing unused frames from being in the .bit file). > > > > > > Austin > > > > > > "Nicholas C. Weaver" wrote: > > > > > > > In article <3F144161.242FBBAB@xilinx.com>, > > > > Austin Lesea <Austin.Lesea@xilinx.com> wrote: > > > > >Compression of bit streams.... > > > > > > > > > >Is a tricky business. Some bitstreams compress well, others do not compress > > > > >much at all. > > > > > > > > Right. But compression, in the worst case, offers no savings, but in > > > > the best case offers substantial savings. > > > > > > > > And I'd expect that there is generally a fair amount of savings, just > > > > from all the switchpoints which support a fairly large amount of > > > > fanout when most switches only have a small amount of fanout most of > > > > the time. > > > > -- > > > > Nicholas C. Weaver nweaver@cs.berkeley.edu -- 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: 58353
Rick, Using a small (few resources) configuration allows the use of the present compress option, which does not use the unused frames. So if you floorplan the design to use a minimum of frames, then the compress option will result in a pretty tiny file size. Austin rickman wrote: > I guess I may be missing something. When I asked about partial > reconfiguration, I was told that the part must first be loaded with a > full download before it can be *partially* reconfigured. Is this not > correct? If it is correct, then this method would seem to require that > before you can use a compressed bitstream file, you would need to load a > full sized bitstream for the decompression engine. > > Perhaps the method I was enquiring about is somehow different. I was > looking into modular designs with partial reconfiguration. > > Austin Lesea wrote: > > > > Symon, > > > > Great idea! I will pass it along. To use a soft core is, as you point out, best, as one can > > tailor it to the best method of decompression! > > > > By the way, since you have disclosed this, there is nothing to prevent any of our customers from > > doing this, now. Heck, one could use the PPC in an amazingly complex decompression to unravel the > > bitstream in a virtex II pro .... > > > > Austin > > > > Symon wrote: > > > > > Hey Austin, > > > How about an App note/ Tech exclusive showing how to do > > > configuration bitstream decompression using the ICAP present in some > > > of your parts? The configuration stream first loads the FPGA with a > > > small decompression engine. This engine then decompresses the rest of > > > the bitstream and loads the rest of the FPGA through the ICAP. This > > > way, you (Xilinx) get to demonstrate partial configuration and the > > > ICAP. We (the customers) get a way to compress bitstreams if needed. > > > You're not selling a tool, it's an app note. > > > It also is better than a 'hard' solution, as you can update the > > > decompression engine as new ideas are tried. You could start with run > > > length encoding and add more complex stuff later. Users could develop > > > their own, depending on their requirements. > > > As mentioned on comp.arch.fpga passim, you can alter many bits > > > with SEUs without affecting the logic design, this would imply to me > > > significant compression is possible. > > > cheers, Syms. > > > > > > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F1462AB.B2CEE7A7@xilinx.com>... > > > > Nick, > > > > > > > > It is really hard to sell a tool that only works sometimes (in fact, it does more > > > > damage to do so, than to just not use that tool). > > > > > > > > Thus, until we have a really robust method of compression that works across > > > > thousands of bitstreams, we will stick to the easy method that we use now > > > > (suppressing unused frames from being in the .bit file). > > > > > > > > Austin > > > > > > > > "Nicholas C. Weaver" wrote: > > > > > > > > > In article <3F144161.242FBBAB@xilinx.com>, > > > > > Austin Lesea <Austin.Lesea@xilinx.com> wrote: > > > > > >Compression of bit streams.... > > > > > > > > > > > >Is a tricky business. Some bitstreams compress well, others do not compress > > > > > >much at all. > > > > > > > > > > Right. But compression, in the worst case, offers no savings, but in > > > > > the best case offers substantial savings. > > > > > > > > > > And I'd expect that there is generally a fair amount of savings, just > > > > > from all the switchpoints which support a fairly large amount of > > > > > fanout when most switches only have a small amount of fanout most of > > > > > the time. > > > > > -- > > > > > Nicholas C. Weaver nweaver@cs.berkeley.edu > > -- > > 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: 58354
Hello Jim, Alan, Looks like you are programming a MAX device, right? This can be programmed by a POF file, or JAM or JBC file. The POF is generally used when programming from MAX+PLUS II or Quartus, and the JAM and JBC files are used when programming using the Jam STAPL player. The RBF file is used to configure SRAM-based FPGAs from Altera, but I don't think that is the case here. The Jam STAPL Player is a stand alone programmer that can program any JTAG programmable part from Altera either CPLD or FPGA. The Jam STAPL Player executable takes .jam or .jbc files as inputs and can program the Altera CPLD or FPGAs within a JTAG chain. The executable is small because the programming algorithm is embedded into the .jam or .jbc file. Jam STAPL is a JEDEC standardized programming language for CPLDs and FPGAs - it is also supported by non-Altera vendors. The Jam STAPL player can program any vendor's device as long as the software for those devices outputs a .jam or .jbc file. Most JTAG Test Tool Companies also support the .jam file format for programming with their test tools. The MAX+PLUS II or Quartus II software can be used to convert .pof files to .jam or .jbc. See online help "Jam", "Convert Programming files" for more information. Also look at these links for downloads and information on running Jam STAPL player: https://www.altera.com/support/software/download/programming/jam/jam-index.jsp http://www.altera.com/literature/an/an122.pdf AN 122 talks about using Jam/STAPL Player for embedded processors, but its command line usage applies to a desktop DOS/command line environment executable too. You can download the Jam STAPL player from the Altera web site, run it on the PC, and use it to program the devices from a Jam or JBC file without having to run MAX+PLUS II or Quartus. Sincerely, Greg Steinke Altera Corporation gregs@altera.com alann@accom.com (Alan Nishioka) wrote in message news:<a2db9b48.0307180719.591a20b3@posting.google.com>... > Jim Flanagan <jflan@ieee.org> wrote in message news:<MPG.197fad6474e7fddb989682@netnews.worldnet.att.net>... > > I am searching for a 'standalone' command line utility that will > > allow me to program Altera CPLD parts using the ByteBlasterMV cable > > and WITHOUT using Max-Plus,etc. > > Have you looked into JAM/STAPL? > www.jamisp.com > > This is an Altera invented standard for programming CPLD's using > external programmers and embedded systems. > > The kit includes source code so you can modify it to program a CPLD > from an embedded system. But the last time I looked at it, the sample > code worked with a ByteBlaster and ran from the command line. > > Alan Nishioka > alann@accom.comArticle: 58355
I have designed a synchronous FIFO in the past, but now I need one with asynchronous read and write clocks. It will be in a Virtex2, and I need to keep a count of the number of words in the FIFO. I do not need the empty and full indicators. I have the Xilinx app notes (175, 131), which say that it is not possible to have a reliable count of the number of words. Any ideas or example code would be much appreciated. TIA Barry BrownArticle: 58356
Synchronous FIFOs are effectively synchronous state machines. Asynchronous operation is much trickier, since you must accomodate any conceivable phase difference between the two clocks. Clock speed is important. One method performs the simple subtraction of the two binary counters, but performs it continuously, and throws out any "non-fitting" results, assuming they are the result of one counter just changing during the capture. Clever but not really kosher... The design depend on the clock frequencies involves, and on free-running or not free-running clock behavior. There is no simple standard recipe. Peter Alfke ========= Barry Brown wrote: > > I have designed a synchronous FIFO in the past, but now I need one with > asynchronous read and write clocks. It will be in a Virtex2, and I need to > keep a count of the number of words in the FIFO. I do not need the empty and > full indicators. I have the Xilinx app notes (175, 131), which say that it > is not possible to have a reliable count of the number of words. Any ideas > or example code would be much appreciated. > > TIA > Barry BrownArticle: 58357
Hi all, See in http://www.easics.com/webtools/crctool an easy manner to implement a module in hardware to resolve the CRC in parallel in a single clock cycle. Bye. Ewerson L. S. Carvalho, Master Student - Informatics Institute, PUCRS Mail Address: Av Ipiranga, 6681, Prédio 16. Porto Alegre, RS, Brazil CEP:90619-900 - Phone:+55 51 3320 3611 - Fax:+55 51 3320 3758 e-mail: ecarvalho@inf.pucrs.br - URL: http://www.inf.pucrs.br/~ecarvalhoArticle: 58358
Hi,
Try https://www.national.com/appinfo/wireless/files/DeansBook_4_01.pdf
for a good read on PLLs. I'm thinking of using the design in chapter
12 with the XAPP0028 circuit minus the tri-states.
Also, see XAPP250 for a similar PFD design. In XAPP250 use a delay
between the 'AND' gate and the reset of the FFs to get rid of dead
band. This delay allows both 'up' and 'down' to be on at once, so
don't connect them together without a resistor at least!
HTH, SYms.
Peter Alfke <peter@xilinx.com> wrote in message news:<3F1C202D.8E41AA9@xilinx.com>...
> The sins of the past... :-)
> I patented that method 26 years ago, while I was at Fairchild Semiconductor:
> US patent # 4 023 116,
> filed July 76, issued May 77.
>
> It's a neat way to reduce jitter when perfect phase adjustment is not required.
> Peter Alfke
> ==========================================
> Jim Granville wrote:
> >
> > If you are seriously worried about PLL/VCO sidebands, better PLL
> > detectors
> > have deliberate dead-band removal - this is extra logic that prevents
> > a 'flat spot' in the phase/voltage curve, that can occur in simpler
> > digital-state only designs.
> > If in this class, you should use the FPGA OP to drive an analog switch,
> > so the relatively noisy Vcc/Gnds do not appear on the VCO control
> > voltage
> > domain.
> >
> > -jg
Article: 58359
A few more details I should have mentioned:
write clock is 40 MHz
read clock is 75 MHz
I only need the "number of words in FIFO" count on the read clock side
Here is what I have been thinking -
Gray counters for read and write addresses. Re-clock the gray write address
with the read clock, then convert it back to binary. Subtract the read
address from the re-clocked write address (both in binary), to get the
number of words in the FIFO. It seems that if I re-clock the write address
while it's in gray code, I should only have a one count ambiguity.
Anyone see a flaw, or have a better idea?
"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F1C5BFC.493D4F68@xilinx.com...
> Synchronous FIFOs are effectively synchronous state machines.
> Asynchronous operation is much trickier, since you must accomodate any
> conceivable phase difference between the two clocks.
> Clock speed is important.
> One method performs the simple subtraction of the two binary counters,
> but performs it continuously, and throws out any "non-fitting" results,
> assuming they are the result of one counter just changing during the
> capture. Clever but not really kosher...
>
> The design depend on the clock frequencies involves, and on free-running
> or not free-running clock behavior.
> There is no simple standard recipe.
> Peter Alfke
> =========
> Barry Brown wrote:
> >
> > I have designed a synchronous FIFO in the past, but now I need one with
> > asynchronous read and write clocks. It will be in a Virtex2, and I need
to
> > keep a count of the number of words in the FIFO. I do not need the empty
and
> > full indicators. I have the Xilinx app notes (175, 131), which say that
it
> > is not possible to have a reliable count of the number of words. Any
ideas
> > or example code would be much appreciated.
> >
> > TIA
> > Barry Brown
Article: 58360Hi Avrum, Thanks for your detailed and rapid response! So basically the only thing special about IOs labelled GCLKxx is that that particular pad can, if desired, be hooked to a IBUFG (for inputs) or BUFG (for outputs). As far as the physical output standard is concerned, it's just a regular IO. Thanks again, JohnArticle: 58361
rickman wrote: > I guess I may be missing something. When I asked about partial > reconfiguration, I was told that the part must first be loaded with a > full download before it can be *partially* reconfigured. Is this not > correct? If it is correct, then this method would seem to require that > before you can use a compressed bitstream file, you would need to load a > full sized bitstream for the decompression engine. > > Perhaps the method I was enquiring about is somehow different. I was > looking into modular designs with partial reconfiguration. > > snip isn't there a good chance that the current bitfile compression will work quite well on something that only uses a (hopefully) tiny part of the chip? -LasseArticle: 58362
"Barry Brown" <barry_brown@agilent.com> wrote in message news:1058824681.854644@cswreg.cos.agilent.com... > A few more details I should have mentioned: > write clock is 40 MHz > read clock is 75 MHz > I only need the "number of words in FIFO" count on the read clock side > > Here is what I have been thinking - > Gray counters for read and write addresses. Re-clock the gray write address > with the read clock, then convert it back to binary. Subtract the read > address from the re-clocked write address (both in binary), to get the > number of words in the FIFO. It seems that if I re-clock the write address > while it's in gray code, I should only have a one count ambiguity. > > Anyone see a flaw, or have a better idea? > Barry, That's exactly the way to do it. If your clock speeds are low enough that you don't have to pipeline the subtractor or the gray->binary converter, then you can have low latency. There will still be a bit of latency, even if it's just one cycle. -KevinArticle: 58363
Hi, Can anybody tell me the advantage of distributed RAM and the resources descriping it? sincerely ------------- Kuan Zhou ECSE departmentArticle: 58364
Hi, all, I have a problem with the leonardo spectrum synthesis result. When I am using two leonardo versions to run synthesis of my design, I got the following clock rates. I targetted Xilinx Virtex II FPGA, 2v40cs144, speed grade -6, LenoardoSpectrum v2001: 180MHz LeonardoSpectrum v2003: 330MHz I don't know why it varies so much, which one should I believe? thank you for your answer, AlexArticle: 58365
opencores.org has one available Andrew Barry Brown wrote: >I have designed a synchronous FIFO in the past, but now I need one with >asynchronous read and write clocks. It will be in a Virtex2, and I need to >keep a count of the number of words in the FIFO. I do not need the empty and >full indicators. I have the Xilinx app notes (175, 131), which say that it >is not possible to have a reliable count of the number of words. Any ideas >or example code would be much appreciated. > >TIA >Barry Brown > > > >Article: 58366
Symon wrote: > > Hi, > Try https://www.national.com/appinfo/wireless/files/DeansBook_4_01.pdf > for a good read on PLLs. I'm thinking of using the design in chapter > 12 with the XAPP0028 circuit minus the tri-states. ... In most hardware designs, tri state is a way to lock a steady charge on the integrating cap, instead of always ramping it up or down, "galloping ghost" style. Applied that way, it reduces phase jitter. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 58367
In Xilinx devices, the 4-input LUTs can also be used as 16-bit RAM. That means each LUT can be a RAM with 4 address inputs and one Din and one Dout. There are also ways to combine two LUTs to form a 16-bit dual-port RAM. Compared to BlockRAMs, these distributed RAMs are more flexible and faster, but they require more external logic when they are expanded to greater depth. The LUT can also be configured to be a 16-bit shift register (LSR16). Distributed RAM (LUT-RAM) is only available in Xilinx FPGA families... Peter Alfke, Xilinx. ========== Kuan Zhou wrote: > > Hi, > Can anybody tell me the advantage of distributed RAM and the resources > descriping it? > > sincerely > ------------- > Kuan Zhou > ECSE departmentArticle: 58368
Here is a slight simplification offering a very compact layout. Start with two binary counters. For the write counter only: convert it to Grey and reclock the output with the read clock, then re-convert to binary (without registering), and do your subtraction. Binary counters are simpler than Grey counters, and the conversion is just a chain of concatenating XORs. I always do the bin-Grey conversion by XORing the D-inputs of the binary counter, which keeps the binary and Grey values in synchronism. The bin-Grey converter has a ripple delay, but that should not bother you at your benign frequencies. Obviously, you need to use the binary counters for addressing the dual-port RAM. Peter Alfke, Xilinx ================= Barry Brown wrote: > > A few more details I should have mentioned: > write clock is 40 MHz > read clock is 75 MHz > I only need the "number of words in FIFO" count on the read clock side > > Here is what I have been thinking - > Gray counters for read and write addresses. Re-clock the gray write address > with the read clock, then convert it back to binary. Subtract the read > address from the re-clocked write address (both in binary), to get the > number of words in the FIFO. It seems that if I re-clock the write address > while it's in gray code, I should only have a one count ambiguity. > > Anyone see a flaw, or have a better idea? > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3F1C5BFC.493D4F68@xilinx.com... > > Synchronous FIFOs are effectively synchronous state machines. > > Asynchronous operation is much trickier, since you must accomodate any > > conceivable phase difference between the two clocks. > > Clock speed is important. > > One method performs the simple subtraction of the two binary counters, > > but performs it continuously, and throws out any "non-fitting" results, > > assuming they are the result of one counter just changing during the > > capture. Clever but not really kosher... > > > > The design depend on the clock frequencies involves, and on free-running > > or not free-running clock behavior. > > There is no simple standard recipe. > > Peter Alfke > > ========= > > Barry Brown wrote: > > > > > > I have designed a synchronous FIFO in the past, but now I need one with > > > asynchronous read and write clocks. It will be in a Virtex2, and I need > to > > > keep a count of the number of words in the FIFO. I do not need the empty > and > > > full indicators. I have the Xilinx app notes (175, 131), which say that > it > > > is not possible to have a reliable count of the number of words. Any > ideas > > > or example code would be much appreciated. > > > > > > TIA > > > Barry BrownArticle: 58369
Yeah, that's the one.
Martin Thompson wrote:
> Ray Andraka <ray@andraka.com> writes:
> >
> > David Tucker wrote:
> >
> > > I'm working on implementing a custom game boy advance cartrige with
> > > the following features:
> > >
> > > - 4-16MByte flash rom (bank switched to a 24 pin buss)
> > > - 32kbyte save ram (game state save, can be stored in flash rom if
> > > needed)
> > > - usb-to-pc link
> > > - in system reprogramability via usb
> > > - hardware assist for MP3/OGG decoding or similar lossy compression
> > > (target compression is 8bit, 2-8Kbit/sec, for 30min of audio in
> > > 2mbyte of rom)
> > >
>
> > I recall seeing recently someone with an FPGA (I think it is Xilinx
> > Spartan2) board for a gameboy advance. I'll have to look around to see
> > where it was, but I did get the distinct impression it is commercially
> > available.
> >
>
> Would that be this one?
> http://www.charmedlabs.com/xportmain.htm
> According to the FAQ at http://www.charmedlabs.com/xportfaqmain.htm
> the FPGA is an XC2S50.
>
> Cheers,
> Martin
>
> --
> martin.j.thompson@trw.com
> TRW Conekt, Solihull, UK
> http://www.trw.com/conekt
--
--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: 58370Hi, Thank you for your reply. How about Block SelectRAM? Is it a unique feature of Xilinx too? I checked the website recently.It says the fastest FPGA in Xilinx has a system clock of 400 MHz while the fastest one in Altera is 500 MHz. What's the main difference which leads to the difference of speed? The speed difference is not big though. Thank you very much! sincerely ------------- Kuan Zhou ECSE department On Mon, 21 Jul 2003, Peter Alfke wrote: > In Xilinx devices, the 4-input LUTs can also be used as 16-bit RAM. That > means each LUT can be a RAM with 4 address inputs and one Din and one Dout. > There are also ways to combine two LUTs to form a 16-bit dual-port RAM. > Compared to BlockRAMs, these distributed RAMs are more flexible and > faster, but they require more external logic when they are expanded to > greater depth. > The LUT can also be configured to be a 16-bit shift register (LSR16). > Distributed RAM (LUT-RAM) is only available in Xilinx FPGA families... > Peter Alfke, Xilinx. > ========== > Kuan Zhou wrote: > > > > Hi, > > Can anybody tell me the advantage of distributed RAM and the resources > > descriping it? > > > > sincerely > > ------------- > > Kuan Zhou > > ECSE department > >Article: 58371
Not quite... Each ball or pin is connected to an IOB, which is a complex block that can take on many personalities. This IOB is the connection and conversion between the internal signals to/from the core of the FPGA device and the board level signals. The different personalities of the IOB are controlled by instantiating one of the possible I/O buffers and mapping it to the IOB location. The mapping is done using the LOC attribute either embedded in the RTL or in the .ucf file, and uses the pin/ball name (not the IO_L###_P/N_# name). To make the IOB a regular input buffer you instantiate an IBUF and LOC it to the position. To make the IOB an output buffer, you instantiate an OBUF and LOC it to the position. To make it a tristateable output, you instantiate an OBUFT, and to make it an input/output buffer you instantiate an IOBUF. All pins can be any one of these types. Further, each of these main types can be further personalized to be a particular I/O standard - this is done either by instantiating a different type of buffer, or by setting the IOSTANDARD attribute on the buffer. So, to make an HSTL1 input buffer, you can instantiate an IBUF, LOC it to the desired position, and set the IOSTANDARD attribute for that IBUF to be hstl1. Alternatively, you can simply instantiate an IBUF_HSTL1, which specifies that it is an IBUF and that it is the HSTL1 standard at the same time. Every IOB can become an IBUF/OBUF/OBUFT/IOBUF and can also become any standard subject to the rules regarding mixing different IO standards in the same bank. Sixteen of the IOBs in the FPGA also have the ability to take on an additional personality - that of an IBUFG. This is a IOB that is identical to a regular IBUF (an input buffer), but will take advantage of the special routing connected to that IOB to drive the clocking resources of the FPGA (DCMs or BUFGs). A BUFG is NOT a personality of the IOB - it is a different resource in the FPGA. The BUFG is a global clock buffer. This is essentially a big internal buffer that drives the clock network of the FPGA. Dedicated routing exists within the FPGA to connect the output of a BUFG to every clockable resource in the FPGA (the slice flops, the IOB flops, the block RAMs, and the multipliers). In a "normal" configuration, you use the following resources to bring a clock into the FPGA: - one of the 16 "GLCK" IOBs is configured as an IBUFG to bring the clock into the chip - dedicated routing is used to take the output of the IBUFG to the CLKIN of a DCM - one of the CLK outputs (CLK0 or CLK2X) of the DCM is connected to the input of a BUFG (which again uses dedicated routing) - the output of the BUFG uses dedicated routing to connect the clockable components in the FPGA (you also need to connect the output of the BUFG back to the CLKFB input of the DCM; this also uses dedicated routing) Using this arrangement the arrival time of the clock at all clockable devices inside the FPGA is tightly controlled with respect to the arrival of the clock at the pin of the FPGA. This allows for predictable setup and hold times for signals going into the FPGA (via an IBUF and the dedicated flop in the IOB), and predictable clock to Q timing for signals coming out of the FPGA (from the IOB flops through an OBUF). These times are documented in the data sheet as Tpsdcm/Tphdcm and Tickofdcm respectively. Avrum "John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:bfho2p$q7v$1@bunyip.cc.uq.edu.au... > Hi Avrum, > > Thanks for your detailed and rapid response! So basically the only > thing special about IOs labelled GCLKxx is that that particular pad can, > if desired, be hooked to a IBUFG (for inputs) or BUFG (for outputs). As > far as the physical output standard is concerned, it's just a regular IO. > > Thanks again, > > John >Article: 58373
If your application can utilize counting packets instead of words the problem might be simplified. Say you have a FIFO collecting data to be burst into SDRAM. You have to wait for a packet equivalent to the burst length before executing a burst cycle. In that case your FIFO counter might not have to resolve down to a word. For packet counting you can pass "packet_plus" and/or "packet_minus" pulses between the write and read address generator modules and keep a packet counter on the side of interest. Just make sure the plus/minus pulses are not single-clock wide and use edge detection on the receiving end to generate the local domain up/down signal. Finally, a case statement would resolve all possible up/down combinations in order to ensure that the packet counter is accurate. My 0.2ns worth. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Barry Brown" <barry_brown@agilent.com> wrote in message news:1058824681.854644@cswreg.cos.agilent.com... > A few more details I should have mentioned: > write clock is 40 MHz > read clock is 75 MHz > I only need the "number of words in FIFO" count on the read clock side > > Here is what I have been thinking - > Gray counters for read and write addresses. Re-clock the gray write address > with the read clock, then convert it back to binary. Subtract the read > address from the re-clocked write address (both in binary), to get the > number of words in the FIFO. It seems that if I re-clock the write address > while it's in gray code, I should only have a one count ambiguity. > > Anyone see a flaw, or have a better idea? > > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3F1C5BFC.493D4F68@xilinx.com... > > Synchronous FIFOs are effectively synchronous state machines. > > Asynchronous operation is much trickier, since you must accomodate any > > conceivable phase difference between the two clocks. > > Clock speed is important. > > One method performs the simple subtraction of the two binary counters, > > but performs it continuously, and throws out any "non-fitting" results, > > assuming they are the result of one counter just changing during the > > capture. Clever but not really kosher... > > > > The design depend on the clock frequencies involves, and on free-running > > or not free-running clock behavior. > > There is no simple standard recipe. > > Peter Alfke > > ========= > > Barry Brown wrote: > > > > > > I have designed a synchronous FIFO in the past, but now I need one with > > > asynchronous read and write clocks. It will be in a Virtex2, and I need > to > > > keep a count of the number of words in the FIFO. I do not need the empty > and > > > full indicators. I have the Xilinx app notes (175, 131), which say that > it > > > is not possible to have a reliable count of the number of words. Any > ideas > > > or example code would be much appreciated. > > > > > > TIA > > > Barry Brown > >Article: 58374
Alex wrote:
> When I am using two leonardo versions to run synthesis of my design,
> I got the following clock rates.
>
> I targetted Xilinx Virtex II FPGA, 2v40cs144, speed grade -6,
>
> LenoardoSpectrum v2001: 180MHz
> LeonardoSpectrum v2003: 330MHz
>
> I don't know why it varies so much, which one should I believe?
Neither. Take your v2003 .edf file, run a place and route with
static timing and use that fmax.
Synthesis does get better with newer versions, but the fmax
from synthesis is just an estimate in any case.
-- Mike Treseler
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