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
Antti, iMPACT does allow user to download, verify, get device ID via JTAG. For other functions such as EXTEST, INTEST, etc, you can shift in such instructions with iMPACT's Debug Chain functionality. This feature allows you to move through the 16 TAP controller states and shift in TDI data. With 6.1i iMPACT you'll be able to genrate and program the Xilinx part with SVF (via inbuild XSVF player function). If iMPACT isn't detecting the Parallel Cable for you, please see Xilinx solution 15742 for debugging tips and contact the Xilinx hotline support for further issues. Regards, Wei Xilinx Applications Antti Lukats wrote: > Aurelian Lazarut <aurash@xilinx.com> wrote in message news:<3F6B1811.FD334DE@xilinx.com>... > >>Antti Lukats wrote: >> >>Antti, >>why are you saying that the boundary scan is not supported with PAR cable >>IV ?? - or it's a wild guess... >>Aurash >> __ >>/ /\/\ Aurelian Lazarut >>\ \ / System Verification Engineer >>/ / \ Xilinx Ireland >>\_\/\/ >> >>phone: 353 01 4032639 >>fax: 353 01 4640324 > > > Dear Xilinx Verification Engineer, > > No it is not a wild guess. Sure Cable IV hardware support all JTAG > (inclusive boundary scan of course) but 99% of Xilinx customers who > own Cable IV can not use it for boundary scan because there are no > software available for that purpose. > > Cable IV: > hardware is boundary scan capable > can not be used for boundary scan because no software or API is available. > > I had a pretty urgent need to use boundary during development of on board > with Xilinx FPGA, I have Cable IV (only because it was bundled with > ML300 kit), but I could not use Cable IV, because the lack of software. > > Cable IV hardware description and software driver API are all kept Xilinx > confidential and secret, so 3rd party software can not use Cable IV. > > If the API (or register level description of the hardware interface) > would be public it would be real simple to modify STAPL player to support > Cable IV. Unfortunatly this is not possible and STAPL player hardware support > ends with Cable III (i.e. simple LPT download cable). > Xilinx provided XSVF player also does not support Cable IV. > > > There is only one wacked way to use Cable IV for boundary scan, but that > really not an option - SystemACE files may contain SVF so if you have systemACE > that you program using Cable IV then you could optionally create a SVF that > does the needed boundary scan, program the systemACE and let systemACE to > perform the JTAG boundary scan. > > Except that I am not aware of any means of using Cable IV for boundary scan. > Correct me if I am wrong. There might be some JTAG software that cost some > thousands of $$$ and support Cable IV, but an regular Xilinx customer who > has to deal with Xilinx FPGAs and owns Cable IV can not use it boundary scan. > > PLEASE, PLEASE SAY I am wrong. (I dont think I am) > > antti > who does not work for xilinx but in most cases knows more than those who do.Article: 60776
Bertrik, you are right in stating that the Xilinx solutions do not offer "fall-through" as an option. We might offer that in the future. But let's be realistic: The only value of this option is when you write the first word into a previously empty FIFO. Then the word appears at the output without any Read Enable action. Once beyond this, there is no difference between this and the conventional mode. So it all depends whether you intend to often empty the FIFO completely. If this is rare, the fall-through is of dubious value. Peter Alfke ==================== Bertrik Sikken wrote: > > Hi all, > > I worked on a project using an Altera FPGA and I noticed that > their FIFOs have a 'show-ahead' feature. Currently I'm working > with an FPGA from Xilinx and I could not find a similar feature > on their FIFO's. > > It seems to me such a feature can be very useful since it > allows you to get at the data one clock earlier. > > Why don't the Xilinx FIFOs have such a feature? > (Or am I perhaps overlooking something some crucial > drawback of show-ahead FIFOs?) > > Regards, > Bertrik SikkenArticle: 60777
Lorenzo Lutti wrote: > > > Yes! But be afraid of iMPACT user interface, which is the worst > nightmare ever invented. I've lost more than ten minutes to understand > how to use a PROM with iMPACT... Lorenzo, you must be pretty smart if you can solve the "worst nightmare ever invented" in a mere ten minutes... :-) Peter AlfkeArticle: 60778
What is the most inexpensive programmer available for the ICT 7572J Peel device? Thanks, MikeArticle: 60779
My first answer is: look it up on google. You get 747 hits! Question: Do you need any more? The parts do not exist anymore, so why do you need the data sheet? Peter Alfke, Xilinx "H.Azmi" wrote: > > Hi guyes , > Does any body have datasheet for XC6216 ?Article: 60780
There is none. That's the beauty of it. But it also means that we must be self-policing. Which we usually are... Peter Alfke ================= Stephan Neuhold wrote: > > Hi, > > Can somebody please tell me who the moderator of this newsgroup is? > > Thanks, > Stephan NeuholdArticle: 60781
Andrew Paule wrote: > > Hi Philip - > > you're right on all cases - only thing is that you are going to be > either a half or full clock behind. FWFT Fifo's are done with > transparent latches (that's the limiter) - you have to be cautious in > use of them. I've done fifo's using the transparent latch trick that > are out running at >430MHz, in IBM SiGe (Fishkill) - but in an FPGA, > unless you pay attention to how you're routing the thing, you can have a > nightmare (One of the reasons I like Actels) - the true FWFT types have > the flags updated on the rising edge of the incoming clock and have the > synched flops (look at a Cypress or IDT design) done with the same flop > that's used for the empty flag. What you are doing is great for > avoiding problems in designs that are not well followed through, and > should be a design standard. What goes on in the newsgroups is that > some folks out there will take a quick look at things and then try to > implement them without understanding the real problems in post route > timing (especially over temperature). Unless I am all wet, these are not true FIFOs, but are only RAM blocks with address counters. I am not sure you are correct about the need for transparent latches. I don't see how you would even use a transparent latch in this application to any advantage. I expect the RAM block is simply leaving out the output latch on the read data. The Altera RAMs work in a way that the output data is not available for half a clock cycle after it is written (internal falling edge write strobe perhaps?). This may look like a transparent latch, but it is not. In this case I don't see how you could use a transparent latch on the output and get it to do anything useful. -- 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: 60782
If you design synchronously and use a common global clock, you "have
nothing to fear but fear itself" (to quote FDR).
Instead of decoding TC of the big counter, you could waste a flip-flop
and build a digital differentiator of the MSB. Just an idea for simplification.
When you use Global Clocks, you can forget about any hild-time issues.
But it's good that you are not naïve ! Taht's worth at leaast an A- ( in
US notation)
Peter Alfke
Tom Derham wrote:
>
> I am using one counter to trigger a second counter.
> The first counter is loadable but typically runs for a long time ('count' is
> 28 bit).
> This counter keeps running, and each time it terminates, produces a pulse.
> This pulse is used to trigger the second counter, which typically runs for
> much less time ('count' is 8 bit). This counter produces output 1 while it
> is counting, then returns to 0 until it is retriggered by the pulse from the
> first counter.
> The whole design is synchronous (running of a single clock at 100 MHz),
> using Webpack on Spartan IIE.
>
> Question: how long must the pulse from the first clock be, to ensure that it
> triggers the second clock? As I see it, if it is one clock cycle long, then
> the second clock should trigger on the next clock rising edge (providing the
> sum of clock propagation and the 2nd clock flip-flop setup is less than one
> clock cycle)... but functionally the pulse will fall back at the moment it
> is triggered (one cycle later), so will only work if the hold time of the
> flip-flop is less than the clock propagation.
> Is this safe? Does the pulse need to be longer? Will the simulation tools
> realise if there is a problem here?
>
> Many thanks
>
> Tom Derham
Article: 60783>I think that's because one of the standards counts transistors in its MTBF.. >so a PAL is more reliable than an FPGA but less reliable than an HC00. Many years ago, somebody told me that system reliability was roughly: connectors solder joints bond wires on chip problems I think the handwave was a factor of 10 each step. (Big handwave.) Is that still a good rough cut? Any obvious overview article I should scan for a modern view? Is on-chip failure rate anything anybody should worry about these days? What fraction of real-world failures are caused by ESD or running too hot? (or ...?) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 60784
Hal, That is still true. If you look at the calculation of reliability methods used by the telecom business, the NEBS (new equipment building standards) from Telcordia (aka Bellcore), you will find all of these items with their listed FIT rate (failures per billion hours). Things like fuses (100 fits), and diodes (7 fits), or connectors (10 fits per mating pin-pair), are listed from their historical data, which can be tossed out and replaced with your own data, or data from the manufacturer. Austin Hal Murray wrote: > >I think that's because one of the standards counts transistors in its MTBF.. > >so a PAL is more reliable than an FPGA but less reliable than an HC00. > > Many years ago, somebody told me that system reliability was > roughly: > connectors > solder joints > bond wires > on chip problems > > I think the handwave was a factor of 10 each step. (Big handwave.) > > Is that still a good rough cut? Any obvious overview article I > should scan for a modern view? > > Is on-chip failure rate anything anybody should worry about these days? > What fraction of real-world failures are caused by ESD or running too > hot? (or ...?) > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam.Article: 60785
Also take a look at: http://www.opencores.org/projects/fpga/ Regrads, Andras Tantos "Philip Freidin" <philip@fliptronics.com> wrote in message news:ksutmv8keob45q149tk04kb040lu6l8bl5@4ax.com... > On 22 Sep 2003 06:26:07 -0700, Sebastian_Lange@gmx.de (Sebastian Lange) wrote: > >This post may seem a bit awkward, but has anyone ever come across a > >VHDL or > >Verilog implementation of an FPGA? It would be very instructional to > >have a > >look at it. IMHO, it should be at any rate possible to implement a > >small FPGA as a bit file sitting on top of another FPGA. Our group is > >currently working on some ideas for minimizing the reconfiguration > >data in dynamically reconfigurable FPGA applications. > >It would be very kind if anyone could point me to any resources... > >Thank you so much in advance... > > > >Sebastian > > Eric Crabill's course at SJSU covers this as Lab 5 > > http://www.engr.sjsu.edu/crabill/ > > > > > > Philip Freidin > FliptronicsArticle: 60786
> > Some days ago Xilinx did workshops in many european states. > > Why Italy was excluded? > > No workshops in UK either :( Gentlemen, Altera is offering a summer workshop series for designers as well. The current schedule (for Europe) includes sessions in Milan on October 30, and in Bedfordshire on November 20. You can view the program and enroll to attend online: http://www.altera.com/education/events/europe/sopc03/evt-index.jsp?xy=sopc_algh Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 60787
> a VHDL or Verilog implementation of an FPGA? I know that somebody started one about 2 years ago, but I can't find the bookmark anymore. The main problem was that the custom FPGA needs a custom toolchain, and that makes it a really huge project. MarcArticle: 60788
On Mon, 22 Sep 2003 00:12:54 -0700, Simon Peacock wrote: > Now this sounds like a plan.. I would be interested in more info.. as > would a few around here.. > > Simon > > "Peter Wallace" <pcw@karpy.com> wrote in message > news:pan.2003.09.21.22.57.55.531717.20522@karpy.com... >> On Sat, 20 Sep 2003 23:19:37 -0700, Simon Peacock wrote: >> >> > I have a feeling you might be pushing it .. but I'd like to hear the >> > outcome.. The parallel port is treated as a bit bashed I/O port by >> > the downloader's where as the USB to parallel port is a printer >> > port.. or an EPP port.. >> > >> > Xilinx do a USB to FPGA downloader box for about US$500.. that would >> > be my best thought.. or there's a few USB - JTAG boxes that might >> > also work. Altera have a similar device similar price.. >> > >> > I have often thought an EZ-USB would make a great FPGA downloader and >> > at the same price as the parallel port downloader's. >> > >> > Simon >> > >> > >> > "CF" <carl@notsoform.com> wrote in message >> > news:_e4bb.2249$YO5.1748748@news3.news.adelphia.net... >> >> Thank you for confirming my suspicion that I cannot accomplish this >> >> task with a USB adapter. >> >> I have ordered a Quatech SPP-100 PCMCIA to Parallel adapter. I >> >> believe it will install as an LPT device properly and do the job. >> >> Thank you again. >> >> Carl >> >> >> >> >> >> >> A little early to announce but we have a simple USB/JTAG downloader. >> The downloader uses the FTDI245B chip + a SpartanII Xc2S50 for the TAP >> controller. The XC2S50 is first downloaded in bit-bang mode via the >> FTDI chip and then acts as a smart TAP controller. This is an open >> project with all design information (software, stiffware, schenmatics, >> gerbers) freely available. >> >> The downloader supports 2.5V, 3.3V and 5V JTAG I/O and programmable >> clock rates up to 48 MHz. The programmer is USB powered (no adapter >> needed). Connector pinout is 26 pin superst of EJTAG pinout. >> >> The current software allows downloading Xilinx Bit files and SVF files >> (Thanks Jim!) If you dont want to build it yourself, The programmer >> hardware is available from my company for $99.00 >> >> >> Peter Wallace >> >> Here is a link to the programmer www.mesanet.com/parallelcardinfo.html (at the bottom) The support software link is to a zipped file of schematics and current software/stiffware... Peter Wallace >> >> >> >>Article: 60789
Hi Peter,
If the pin has 10 Ohms of drive impedance the initial sent pulse
will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10
Ohms driver drives a 50 Ohm line. The reflected signal from the
unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse
then increases the voltage at the pin to 3.667, as it's driven from 50
Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the
absolute maximum rating of 3.75V. Hooray!
As you say, this calculation disregards the attenuation due to
the trace propagation function, which will further reduce the
amplitude of the pulse as it travels back and forth down the
transmission line(pcb trace). This is caused by skin effect and stuff.
I guess you could also reduce the drive strength of the pin from the
default 12mA, to increase the source impedance.
The receiver pin is the one that gets the big hit.
cheers, Symon.
Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>...
> Let me help you, and rephrase your original question:
> If a 3.3 V output on Spartan3, going active Low to active High, drives a
> transmission line of arbitrary length that is open ended at the far end,
> there will be a return signal that wants to pull the 3S pin higher than
> Vcco = 3.3 V.
> Can this cause do damage to the Spartan3 pin?
>
> My answer would be: NO.
> The returning 3.3V wave wants to pull the pin to 6.6 V, but the
> transmission line impedanec is roughly 50 Ohm, and the chip pull-up
> impedance is roughly 10 Ohm, so you have a voltage divider that raises
> the output pin voltage by only 1/6 of the 3.3 V swing = 550 mV. The
> resulting theoretical 3.85 voltage is really a bit lower since the
> reflection is not perfect, and there are losses on the line.
> Also, this spike will only last a few nanoseconds.
> I would say that this poses no problem. But I have copied Steve Knapp,
> who handles Spartan applications. He may add his opinion to this.
>
> Peter Alfke, Xilinx
> =============================
> lecroy wrote:
> > I am still looking for an answer to my question.
> >
> > ê
Article: 60790Tom Derham wrote: > [snip] > Question: how long must the pulse from the first clock be, to ensure that it > triggers the second clock? As I see it, if it is one clock cycle long, then > the second clock should trigger on the next clock rising edge (providing the > sum of clock propagation and the 2nd clock flip-flop setup is less than one > clock cycle)... but functionally the pulse will fall back at the moment it > is triggered (one cycle later), so will only work if the hold time of the > flip-flop is less than the clock propagation. > Is this safe? Does the pulse need to be longer? Will the simulation tools > realise if there is a problem here? You can delay the output signal with another FF and 'OR' its input and output. That gives you another clock cycle in length. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 60791
Symon, As if often the case, if you do not run a simulation, you will not get results that are even close to the truth (by guessing at what is happening). With a driver impedance of 8.8 ohms (from IBIS simulation), the overshoot/undershoot back at the driver is less than 100 mV (no pcb or t-line losses, IBIS done with Hyperlynx). Why does this not scale exactly as you state? Because the ON resistance of the transistors is not very linear, and they are less than 8.8 ohms near Vcc or ground. So, unless you simulate the actual circuit, you will not get the actual result. Austin Symon wrote: > Hi Peter, > If the pin has 10 Ohms of drive impedance the initial sent pulse > will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10 > Ohms driver drives a 50 Ohm line. The reflected signal from the > unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse > then increases the voltage at the pin to 3.667, as it's driven from 50 > Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the > absolute maximum rating of 3.75V. Hooray! > As you say, this calculation disregards the attenuation due to > the trace propagation function, which will further reduce the > amplitude of the pulse as it travels back and forth down the > transmission line(pcb trace). This is caused by skin effect and stuff. > I guess you could also reduce the drive strength of the pin from the > default 12mA, to increase the source impedance. > The receiver pin is the one that gets the big hit. > cheers, Symon. > > Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>... > > Let me help you, and rephrase your original question: > > If a 3.3 V output on Spartan3, going active Low to active High, drives a > > transmission line of arbitrary length that is open ended at the far end, > > there will be a return signal that wants to pull the 3S pin higher than > > Vcco = 3.3 V. > > Can this cause do damage to the Spartan3 pin? > > > > My answer would be: NO. > > The returning 3.3V wave wants to pull the pin to 6.6 V, but the > > transmission line impedanec is roughly 50 Ohm, and the chip pull-up > > impedance is roughly 10 Ohm, so you have a voltage divider that raises > > the output pin voltage by only 1/6 of the 3.3 V swing = 550 mV. The > > resulting theoretical 3.85 voltage is really a bit lower since the > > reflection is not perfect, and there are losses on the line. > > Also, this spike will only last a few nanoseconds. > > I would say that this poses no problem. But I have copied Steve Knapp, > > who handles Spartan applications. He may add his opinion to this. > > > > Peter Alfke, Xilinx > > ============================= > > lecroy wrote: > > > I am still looking for an answer to my question. > > > > > > êArticle: 60792
"Rene Tschaggelar" <some@know.me> wrote in message news:da916fbbcc79413230e067ade436a0d4@news.teranews.com... > Tom Derham wrote: > > [snip] > > Question: how long must the pulse from the first clock be, to ensure that it > > triggers the second clock? As I see it, if it is one clock cycle long, then > > the second clock should trigger on the next clock rising edge (providing the > > sum of clock propagation and the 2nd clock flip-flop setup is less than one > > clock cycle)... but functionally the pulse will fall back at the moment it > > is triggered (one cycle later), so will only work if the hold time of the > > flip-flop is less than the clock propagation. > > Is this safe? Does the pulse need to be longer? Will the simulation tools > > realise if there is a problem here? > > You can delay the output signal with another FF and 'OR' its input and output. > That gives you another clock cycle in length. Rene, wouldn't this enable the second counter twice?Article: 60793
Hello all,
I have one question about usage of LUT and Registers in Xilinx
Virtex 2 FPGA:
if, inside a slice, the LUT is consumed by some logic product, but
not the corresponding register, is this register available for other use
(for example, registering signal coming from an other slice) ? or is it
disabled for the whole design ? does it depend on the compilation tool ?
thanks,
Julien Eyries
Article: 60794"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3F6F09E4.5865169E@xilinx.com... > Simon, > > That is for the lazy folks: if you know the reliability (from studies, > manufacturers data, etc.) you can choose to replace the "count method" with the > real data (wow, what a concept!). > > The "count method" is there as a last resort, if there is no other way to gauge > reliability. Once you see the count method numbers, it should send you > screaming to get the real data. The standards bodies know this, and understand > this, it is just that lazy engineers just keep filling out the forms as if they > were still designing in 1968 .... There is a story I heard some years ago, related to statistical physics, but it should work for any statistics problem. A person was told that the probability of a bomb being on an airplane was 1 in 1000, but the probability of two bombs was 1 in 1000000. To be safe, he always brought his own bomb on the plane. (I think those are the numbers in the story, which has no relation to any real planes or real bombs.) The important thing in a large number of problems is statistical independence. When all the transistors on a single chip are made at the same time, using the same process, the probability of one failing is not statistically independent of another failing. A bad batch of any of the chemicals that go into the processing, various mechanical problems that could occur, or any number of other events tend to affect all the transistors on a chip equally. Without statistical independence any count based method will fail, just like in the bomb story. -- glenArticle: 60795
"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
> I am using one counter to trigger a second counter.
> The first counter is loadable but typically runs for a long time ('count'
is
> 28 bit).
> This counter keeps running, and each time it terminates, produces a pulse.
> This pulse is used to trigger the second counter, which typically runs for
> much less time ('count' is 8 bit). This counter produces output 1 while
it
> is counting, then returns to 0 until it is retriggered by the pulse from
the
> first counter.
> The whole design is synchronous (running of a single clock at 100 MHz),
> using Webpack on Spartan IIE.
>
> Question: how long must the pulse from the first clock be, to ensure that
it
> triggers the second clock? As I see it, if it is one clock cycle long,
then
> the second clock should trigger on the next clock rising edge (providing
the
> sum of clock propagation and the 2nd clock flip-flop setup is less than
one
> clock cycle)... but functionally the pulse will fall back at the moment it
> is triggered (one cycle later), so will only work if the hold time of the
> flip-flop is less than the clock propagation.
> Is this safe? Does the pulse need to be longer? Will the simulation
tools
> realise if there is a problem here?
The problem should be exactly the same as that in building the synchronous
counter in the first place.
I still remember from many years ago, that the 74LS74 has 0 hold time, but
the 7474 has a positive hold time. You can make T flip-flops by connecting
Qbar to D on a 74LS74, but not (reliably) on a 7474. Most likely even one
level of logic in between would be enough, though.
The LSB of a synchronous counter would normally have the shortest feedback
path. That would be the first place to look.
As I understand it, FPGA's are usually designed so that in a synchronous
design you don't have to worry about hold time, though possibly setup time.
It might be that it is not possible to make a feedback path short enough,
even if the FF itself has a positive hold time.
Now, some people might design a synchronous counter with a clock input from
the TC pulse of another synchronous counter. That would not qualify as
synchronous logic, and could cause timing problems.
-- glen
Article: 60796If your external clocking is fast enough to allow use of the timing delays inherant in the internals of your FGPA, then using a D and running the output to a pad will allow you to get a good Tpd as the delay - that's really all a transparent does for you in this case - gives a one gate + one (or more pad delays). if you use the supplied macromodels, they will do away with any use for this - roll your own means just that, no RAM blocks. There are other architectures out there besides Altera and Xilinx, but most of this newsgroup seems to forget this. They all have their uses, and obviously they all have some good points to be considered when choosing your architecture. just like the processor people (I still like MIPs and SHARCs), but that's another thread entirely. Andrew rickman wrote: >Andrew Paule wrote: > > >>Hi Philip - >> >>you're right on all cases - only thing is that you are going to be >>either a half or full clock behind. FWFT Fifo's are done with >>transparent latches (that's the limiter) - you have to be cautious in >>use of them. I've done fifo's using the transparent latch trick that >>are out running at >430MHz, in IBM SiGe (Fishkill) - but in an FPGA, >>unless you pay attention to how you're routing the thing, you can have a >>nightmare (One of the reasons I like Actels) - the true FWFT types have >>the flags updated on the rising edge of the incoming clock and have the >>synched flops (look at a Cypress or IDT design) done with the same flop >>that's used for the empty flag. What you are doing is great for >>avoiding problems in designs that are not well followed through, and >>should be a design standard. What goes on in the newsgroups is that >>some folks out there will take a quick look at things and then try to >>implement them without understanding the real problems in post route >>timing (especially over temperature). >> >> > >Unless I am all wet, these are not true FIFOs, but are only RAM blocks >with address counters. > >I am not sure you are correct about the need for transparent latches. I >don't see how you would even use a transparent latch in this application >to any advantage. I expect the RAM block is simply leaving out the >output latch on the read data. The Altera RAMs work in a way that the >output data is not available for half a clock cycle after it is written >(internal falling edge write strobe perhaps?). This may look like a >transparent latch, but it is not. In this case I don't see how you >could use a transparent latch on the output and get it to do anything >useful. > > >Article: 60797
Hold time is a quantum statistical thing - thermal trip of a balanced
pair. Been through this in this newgroup before.
Andrew
Glen Herrmannsfeldt wrote:
>"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
>news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
>
>
>>I am using one counter to trigger a second counter.
>>The first counter is loadable but typically runs for a long time ('count'
>>
>>
>is
>
>
>>28 bit).
>>This counter keeps running, and each time it terminates, produces a pulse.
>>This pulse is used to trigger the second counter, which typically runs for
>>much less time ('count' is 8 bit). This counter produces output 1 while
>>
>>
>it
>
>
>>is counting, then returns to 0 until it is retriggered by the pulse from
>>
>>
>the
>
>
>>first counter.
>>The whole design is synchronous (running of a single clock at 100 MHz),
>>using Webpack on Spartan IIE.
>>
>>Question: how long must the pulse from the first clock be, to ensure that
>>
>>
>it
>
>
>>triggers the second clock? As I see it, if it is one clock cycle long,
>>
>>
>then
>
>
>>the second clock should trigger on the next clock rising edge (providing
>>
>>
>the
>
>
>>sum of clock propagation and the 2nd clock flip-flop setup is less than
>>
>>
>one
>
>
>>clock cycle)... but functionally the pulse will fall back at the moment it
>>is triggered (one cycle later), so will only work if the hold time of the
>>flip-flop is less than the clock propagation.
>>Is this safe? Does the pulse need to be longer? Will the simulation
>>
>>
>tools
>
>
>>realise if there is a problem here?
>>
>>
>
>The problem should be exactly the same as that in building the synchronous
>counter in the first place.
>
>I still remember from many years ago, that the 74LS74 has 0 hold time, but
>the 7474 has a positive hold time. You can make T flip-flops by connecting
>Qbar to D on a 74LS74, but not (reliably) on a 7474. Most likely even one
>level of logic in between would be enough, though.
>
>The LSB of a synchronous counter would normally have the shortest feedback
>path. That would be the first place to look.
>
>As I understand it, FPGA's are usually designed so that in a synchronous
>design you don't have to worry about hold time, though possibly setup time.
>It might be that it is not possible to make a feedback path short enough,
>even if the FF itself has a positive hold time.
>
>Now, some people might design a synchronous counter with a clock input from
>the TC pulse of another synchronous counter. That would not qualify as
>synchronous logic, and could cause timing problems.
>
>-- glen
>
>
>
>
>
>
Article: 60798On Mon, 22 Sep 2003 12:54:14 -0700, emanuel stiebler wrote: > Peter Wallace wrote: >> A little early to announce but we have a simple USB/JTAG downloader. >> The downloader uses the FTDI245B chip + a SpartanII Xc2S50 for the TAP >> controller. The XC2S50 is first downloaded in bit-bang mode via the >> FTDI chip and then acts as a smart TAP controller. This is an open >> project with all design information (software, stiffware, schenmatics, >> gerbers) freely available. > > You should have told us before ;-) > I'm sitting on a layout for something like this, but with the cypress > fx2 as USB2 chip ... > > cheers I looked at that chip for a newer design but it draws so much power that it looks troublesome to stay under the 500 mA limit, at least for a simple low cost card with linear regulators. I've got a low cost USBScope (2 channels ~30 MHz (100 Ms/S)) design using the FTDI245 and a XC2S100E as well, I would have liked to have used the Cypress part there but there is no hope even with switching regulators of staying below 500 mA with Cypress. Peter WallaceArticle: 60799
Here are some practical points.
For all but the most extremely fast applications ( say up to 200 MHz),
synchronous counters are built using a global clock, and the bult-in
free ripple carry structure, which of course determines a max frequency
(where the ripple carry can still meet the set-up time requirements of
the MSB.) Decoding TC can be quite tricky, that's why I suggested the
digital differentiator which actually detects TC+1.
Peter Alfke
=============
Glen Herrmannsfeldt wrote:
>
> "Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
> news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
> > I am using one counter to trigger a second counter.
> > The first counter is loadable but typically runs for a long time ('count'
> is
> > 28 bit).
> > This counter keeps running, and each time it terminates, produces a pulse.
> > This pulse is used to trigger the second counter, which typically runs for
> > much less time ('count' is 8 bit). This counter produces output 1 while
> it
> > is counting, then returns to 0 until it is retriggered by the pulse from
> the
> > first counter.
> > The whole design is synchronous (running of a single clock at 100 MHz),
> > using Webpack on Spartan IIE.
> >
> > Question: how long must the pulse from the first clock be, to ensure that
> it
> > triggers the second clock? As I see it, if it is one clock cycle long,
> then
> > the second clock should trigger on the next clock rising edge (providing
> the
> > sum of clock propagation and the 2nd clock flip-flop setup is less than
> one
> > clock cycle)... but functionally the pulse will fall back at the moment it
> > is triggered (one cycle later), so will only work if the hold time of the
> > flip-flop is less than the clock propagation.
> > Is this safe? Does the pulse need to be longer? Will the simulation
> tools
> > realise if there is a problem here?
>
> The problem should be exactly the same as that in building the synchronous
> counter in the first place.
>
> I still remember from many years ago, that the 74LS74 has 0 hold time, but
> the 7474 has a positive hold time. You can make T flip-flops by connecting
> Qbar to D on a 74LS74, but not (reliably) on a 7474. Most likely even one
> level of logic in between would be enough, though.
>
> The LSB of a synchronous counter would normally have the shortest feedback
> path. That would be the first place to look.
>
> As I understand it, FPGA's are usually designed so that in a synchronous
> design you don't have to worry about hold time, though possibly setup time.
> It might be that it is not possible to make a feedback path short enough,
> even if the FF itself has a positive hold time.
>
> Now, some people might design a synchronous counter with a clock input from
> the TC pulse of another synchronous counter. That would not qualify as
> synchronous logic, and could cause timing problems.
>
> -- glen
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