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
hello again Peter you are right, for some reason i expanded the address without being necessary.I must keep it the same. Finally i got it working, but i had to remove the bit 9 of address of S8_S8 in the declaration and in the process that calculates the new address, because S16_S16 uses 8 bit width.(Otherwise i got wrong data). I need almost empty and almost full signals, and i use common clocks for read write, and the frequency should be 110 Mhz at least. Ray i needed 32 bit data to store so i used two S16_S16 fifos in parallel. Eric i think that the 36 bit fifo is available only for virtex, but i am not sure.I use a SpartanII, so that's why i did not use it. thank all of you for your advice and your time!Article: 49126
Hi, I am trying to obtain the state bit of a register in the readback bitstream from. The information I got from a LL (logic allocation) file is as below ; <offset> <frame address> <frame offset> <information> Bit 1108503 0x00480400 343 Block=CLB_R19C8.S1 Latch=XQ Can anyone tell me how to caculate the bit position? Thanks alot, JunArticle: 49127
hello again Peter you are right, for some reason i expanded the address without being necessary.I must keep it the same. Finally i got it working, but i had to remove the bit 9 of address of S8_S8 in the declaration and in the process that calculates the new address, because S16_S16 uses 8 bit width.(Otherwise i got wrong data). I need almost empty and almost full signals, and i use common clocks for read write, and the frequency should be 110 Mhz at least. Ray i needed 32 bit data to store so i used two S16_S16 fifos in parallel. Eric i think that the 36 bit fifo is available only for virtex, but i am not sure.I use a SpartanII, so that's why i did not use it. thank all of you for your advice and your time!Article: 49130
I read on this NG that from 5.x onwards Win-NT is no longer `supported' by Xilinx. Since I'm loathe to change O/S for no very good reason and AFAIC, Win-NT 4.0 SP6A is as close to bomb-proof as any 'doze O/S has ever got I'd like to at least try installing 5.1 under NT. Has anyone tried this successfully ?Article: 49131
On Fri, 1 Nov 2002 09:16:36 -0000, "Alan Fitch" <alan.fitch@doulos.com> wrote: > > >"Allan Herriman" <allan_herriman.hates.spam@agilent.com> wrote in >message news:3dc210cc.14049401@netnews.agilent.com... >> Hi, >> >> I'm trying to write some VHDL that will infer an FDRE (ff with >clock >> enable and *sychronous* reset) in a Xilinx Virtex-E or -2 >device. >> >> We've tried several versions of Synplify Pro 7.x, and they all >waste a >> LUT to implement the synchronous reset function. >> >> The code used looks something like this: >> >> foo : process (gsr, clk) >> begin >> if gsr = '1' then >> ff <= '0'; >> elsif rising_edge(clk) then >> if sync_reset = '1' then >> ff <= '0'; >> elsif clk_enable = '1' then >> ff <= other_sig; >> end if; >> end if; >> end process foo; >> >> Gsr can be traced back to the gsr input of a startup block. >> >> Does anyone know how to do this without wasting a LUT? >> >> TIA, >> Allan. > >I don't know if this is possible in your design, >but Xilinx recommend that you don't use GSR in Virtex >devices. So I would just write > >> foo : process (clk) >> begin >> if rising_edge(clk) then >> if sync_reset = '1' then >> ff <= '0'; >> elsif clk_enable = '1' then >> ff <= other_sig; >> end if; >> end if; >> end process foo; > >Of course this will only get reset on configuration. > >Do you need the global reset functionally, i.e. do you >use it in your application, rather than just letting >reset on configuration happen? No, it doesn't have any function in this particular application except for making the simulation and synthesis results match. Since verification takes up a significant part of the development effort, I wouldn't like to do anything that causes the behaviour in simulation to differ from that in synthesis. I'll have my serf run some trials without the gsr to see if that makes any difference. Thanks for the tip. Regards, Allan.Article: 49132
Alan Fitch <alan.fitch@doulos.com> wrote: > I don't know if this is possible in your design, > but Xilinx recommend that you don't use GSR in Virtex > devices. So I would just write The recommendation seems to be based on the slow propagation delay (and therefore large skew) on the reset net. If that doesn't cause you any problems then you can use it safely. If you want asynchronous reset functionality, the GSR net should save you resources as you should still be able to use the synchronous resets for your logic. > Of course this will only get reset on configuration. > > Do you need the global reset functionally, i.e. do you > use it in your application, rather than just letting > reset on configuration happen? Actual async reset other than on configuration is required in some applications. It'd be useful to be able to infer an FDRE and still have GSR. Cheers, Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 49133
Allan,
I haven't found a way to do it without canning the global resets either.
Rather than doing the rope pushing trick, I just instantiate them. If
your global reset is for simulation only and you can accept power on
initialize of '0' for every flip-flop in you design, you could try putting
the global reset clause inside a translate_off pragma something like
this. In order for it to work though, you can't have GSR any where in the
synthesized design expression, which means no initialize to '1's and no
global reset pin.
--synthesis translate_off
if global_reset='1' then
blah blah
else
--synthesis translate_ofn
if rising_edge(clk) then
if reset='1' then
Q<='0';
else
Q<=D;
end if;
end if;
--synthesis translate_off
end if;
--synthesis translate_on
Allan Herriman wrote:
> Hi,
>
> I'm trying to write some VHDL that will infer an FDRE (ff with clock
> enable and *sychronous* reset) in a Xilinx Virtex-E or -2 device.
>
> We've tried several versions of Synplify Pro 7.x, and they all waste a
> LUT to implement the synchronous reset function.
>
> The code used looks something like this:
>
> foo : process (gsr, clk)
> begin
> if gsr = '1' then
> ff <= '0';
> elsif rising_edge(clk) then
> if sync_reset = '1' then
> ff <= '0';
> elsif clk_enable = '1' then
> ff <= other_sig;
> end if;
> end if;
> end process foo;
>
> Gsr can be traced back to the gsr input of a startup block.
>
> Does anyone know how to do this without wasting a LUT?
>
> TIA,
> Allan.
--
--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: 49134I want to build a cct which is mainly counters to go in a Xilinx CPLD, 9536 has been chosen and looks fine. I have obtained from OrCAD/Cadence/Mentor/whoever-they-are-this-week, a library called XUnified.olb, which contains most of the primitives and macros in the lib.pdf file issued by Xilinx. There are a few gotchas, and I've had to be careful the parts I choose are supported in the 95xx series. But I've done the cct, and I can produce an EDIF file. When I import that EDIF file, and try to use it I get error messages like: ERROR:NgdBuild:604 - logical block 'U42' with type 'FDRE' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'FDRE' is not supported in target 'xc9500xl'. However using FDCPE objects is accepted perfectly happily, I can even change an FRDE to one and get it to pass. I can't see any difference between them in lib.pdf. I've checked the EDIF file for pin and part name discrepancies, but can't see any. My local support guy is stumped. does anyone know the answer, or is anyone else out there using OrCAD -> EDIF -> design flow and getting the right results? OK I could do this in the Xilinx schematic editor, but I'm drawn to the idea of keeping the entire design inside an OrCAD project, CPLD and all. Thanks for any help anyone can give. David Collier Dexdyne Ltd see www.Dexdyne.comArticle: 49135
> This methodology only works for small, simple designs. The project > I'm working on at the moment has about 1/2 million lines of source. > Yes, we look over it carefully, but simulation is vitally important > for a successful end result. The design in question consists of about 5k lines of code; there are no functional simulation errors, nor do any errors appear in the timing report. The post-PAR simulation errors seem to be caused by setup and/or hold violations in logic that is synchronizing signals across two time domains, and as "nospam" pointed out, these are allowable and inherently unavoidable. The issue as I see it is the shear volume of errors I get under simulation, simply because there are so many such points of synchronization--the FPGA must interface with three external time domains, and a handful of new internal domains were created for various reasons. It makes it very difficult under simulation to distinguish these allowable/unavoidable timing errors from legitimately critical timing errors. Obviously, in my next design, I'll minimize the number of time domains and the size of the interfaces between domains, in order to make this task more manageable . . . but is it worth ripping this finished design apart to get more acceptable simulation results? Or given the size, is the methodology John suggested (careful code inspection) sufficient? Thanks again for your input. JoeArticle: 49136
> Where do you put what hierical level timing/placment constraignts? > 1. IN ucf file > 2. In the schematic? > 3. Elsewhere? > > What are the rules? UCF timing constraints are generally applied to nets, and unfortunately the net names generated by your design may vary depending on which synthesis tool you are using. One way I've found to pin down net names (for the purpose of adding constraints in the UCF) is to implement the design without any constraints, then open FPGA Editor to locate the nets you want to constrain. JoeArticle: 49137
I am working on an FPGA design which involves an interface to a 8051 style uController. The clock of the uC is not available to me. The FPGA is running on an unrelated faster clock. I am trying to clock in address which is stable around the falling edge of ALE. The address setup time to ALE going low is long enough to guarantee that the address is clocked in correctly at least once before ALE goes low. What will happen when ALE falls at the same time that the flip-flops are being clocked? At the moment ALE falls the data on the D pin of the flip-flops is the same as the contents of the flip-flops. Greetings, Henri FaberArticle: 49138
On 1 Nov 2002 07:21:10 -0800, joefrese@hotmail.com (Joe Frese) wrote: >> This methodology only works for small, simple designs. The project >> I'm working on at the moment has about 1/2 million lines of source. >> Yes, we look over it carefully, but simulation is vitally important >> for a successful end result. > >The design in question consists of about 5k lines of code; there are >no functional simulation errors, nor do any errors appear in the >timing report. The post-PAR simulation errors seem to be caused by >setup and/or hold violations in logic that is synchronizing signals >across two time domains, and as "nospam" pointed out, these are >allowable and inherently unavoidable. > >The issue as I see it is the shear volume of errors I get under >simulation, simply because there are so many such points of >synchronization--the FPGA must interface with three external time >domains, and a handful of new internal domains were created for >various reasons. It makes it very difficult under simulation to >distinguish these allowable/unavoidable timing errors from >legitimately critical timing errors. Obviously, in my next design, >I'll minimize the number of time domains and the size of the >interfaces between domains, in order to make this task more manageable >. . . but is it worth ripping this finished design apart to get more >acceptable simulation results? Or given the size, is the methodology >John suggested (careful code inspection) sufficient? Thanks again for >your input. > >Joe One thing you can do is to generate different gate level models for the first synchronizing DFFs in your cross domain transfers. You can make the model give random data when it violates the setup/hold checks instead of giving X and generating a violation. This way you're also making sure that you don't depend getting the right value every single time across the boundary. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 49139
This looks like it should work. We will chase it down. - Ken Synplicity, Inc. Allan Herriman wrote: > Hi, > > I'm trying to write some VHDL that will infer an FDRE (ff with clock > enable and *sychronous* reset) in a Xilinx Virtex-E or -2 device. > > We've tried several versions of Synplify Pro 7.x, and they all waste a > LUT to implement the synchronous reset function. > > The code used looks something like this: > > foo : process (gsr, clk) > begin > if gsr = '1' then > ff <= '0'; > elsif rising_edge(clk) then > if sync_reset = '1' then > ff <= '0'; > elsif clk_enable = '1' then > ff <= other_sig; > end if; > end if; > end process foo; > > Gsr can be traced back to the gsr input of a startup block. > > Does anyone know how to do this without wasting a LUT? > > TIA, > Allan. >Article: 49140
Joe Frese wrote: > The design in question consists of about 5k lines of code; there are > no functional simulation errors, nor do any errors appear in the > timing report. If the static timer is smart and covers all the clocks, you may be ok. > The post-PAR simulation errors seem to be caused by > setup and/or hold violations in logic that is synchronizing signals > across two time domains, and as "nospam" pointed out, these are > allowable and inherently unavoidable. Synchronization flops violate timing by definition. They are required for synthesis, but can only pass a post-PAR sim if you rig the sim inputs or replace the actual -[DQ]-[DQ]- with rigged model as Muzaffer suggests. Your design choices are: 1. Leave design as is and either punt the gate level simulation or remodel the synchronizers to make it pass. 2. Synchronize the design to a single fast clock, by generating clock enables instead of multiple clocks. 3. Partition your design by clock and check static timing for each module. Write a testbench for each module. Remodel the synchronizers for the top level sim. -- Mike TreselerArticle: 49141
Henri Faber <henri.faber@emdes.nl> wrote: : I am working on an FPGA design which involves an interface to a 8051 : style uController. The clock of the uC is not available to me. The : FPGA is running on : an unrelated faster clock. : I am trying to clock in address which is stable around the falling : edge of ALE. : The address setup time to ALE going low is long enough to guarantee : that the : address is clocked in correctly at least once before ALE goes low. : What will : happen when ALE falls at the same time that the flip-flops are being : clocked? : At the moment ALE falls the data on the D pin of the flip-flops is the : same as : the contents of the flip-flops. Why don't you clock the address latches with ALE going low? If you need the address on the FPGA clock domain, take care for the clock domain crossing. But mostly the address is needed to read out other registers or write to them. Latch the registers to read out on negedge ALE and sample the registers set with latches clocked from FPGA clock. I hope you get the picture... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 49142
Faidon, yes, Spartan-II, like Virtex, has max 16 parallel bits in its 4K BlockRAM.(Virtex-II is up to 36 bits wide in its 18K BlockRAM) Being synchronous, your design is very simple: You can use binary counters, no need for LFSR counters. The whole design is a synchronous state machine, manipulating the two 8-bit counters according to the count enable inputs. You can detect the fullness of the FIFO by subtracting the read counter value from the write counter value ( modulo 256). At 110 MHz, you should have no problem at all with this totally synchronous design. FIFOs only get complicated and tricky when the two clocks are unrelated. Peter Alfke, Xilinx Applications ========== faidon wrote: > hello again > > Peter you are right, for some reason i expanded the address without being necessary.I must keep it the same. > Finally i got it working, but i had to remove the bit 9 of address of S8_S8 in the declaration and in the process that calculates the new address, because S16_S16 uses 8 bit width.(Otherwise i got wrong data). > > I need almost empty and almost full signals, and i use common clocks for read write, and the frequency should be 110 Mhz at least. > > Ray i needed 32 bit data to store so i used two S16_S16 fifos in parallel. > > Eric i think that the 36 bit fifo > is available only for virtex, but i am not sure.I use a SpartanII, so that's why i did not use it. > > thank all of you for your advice and your time!Article: 49143
...or you clock in the address on every FPGA clock, but use ALE being Low as a clock disable. That way you have the address already moved over to the FPGA clock domain. Clocking "new" data into a register that already contains the same data just means that nothing is going to happen in the register. :-) Peter Alfke, Xilinx Applications =============== Uwe Bonnes wrote: > Henri Faber <henri.faber@emdes.nl> wrote: > : I am working on an FPGA design which involves an interface to a 8051 > : style uController. The clock of the uC is not available to me. The > : FPGA is running on > : an unrelated faster clock. > : I am trying to clock in address which is stable around the falling > : edge of ALE. > : The address setup time to ALE going low is long enough to guarantee > : that the > : address is clocked in correctly at least once before ALE goes low. > : What will > : happen when ALE falls at the same time that the flip-flops are being > : clocked? > : At the moment ALE falls the data on the D pin of the flip-flops is the > : same as > : the contents of the flip-flops. > > Why don't you clock the address latches with ALE going low? If you need the > address on the FPGA clock domain, take care for the clock domain > crossing. But mostly the address is needed to read out other registers or > write to them. Latch the registers to read out on negedge ALE and sample the > registers set with latches clocked from FPGA clock. I hope you get the > picture... > > Bye > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 49144
I've implemented a Sparc reference MMU for open source processor Leon to be able to port linux onto the platform. you can download MMU sources from http://www.tamaki.de/data/mmu.tar.gz (6mb) and http://www.tamaki.de/data/linux.tar.gz (13mb) If there is anyone that is interested in joining me? I'm developing on a Xess XSV800 board, developers with the same hardware settings could start right away, I'll help to get the dev-enviroment it setup. Currently linux will boot to the end of the init function when execv is called, with memory initialized, and romfs mounted. The page fault signal is not routed yet, that will be the next task. Code would need a cleanup, of course.. Give me a note. -- Konrad Eisele <eiselekd@web.de>Article: 49145
When you are as seasoned as John, then this is a more tenable approach, in fact I once was caught saying that gate level sim was a waste of time. I was under the impression that you are fairly new to HDL based design and the exercise may be well worth it. And by the way, I've seen many a design that were "almost done" except for a few setup/hold problems, that seem to go on and on in that nearly finished state. Sometimes these problems also come back to haunt you in the form of "How come this new lot of Xilinx chips in production don't work?" President, Quadrature Peripherals Altera, Xilinx and Digital Design Consulting email: kayrock66@yahoo.com http://fpga.tripod.com ----------------------------------------------------------------------------- joefrese@hotmail.com (Joe Frese) wrote in message news:<c176b8c2.0211010721.3327b47e@posting.google.com>... > > This methodology only works for small, simple designs. The project > > I'm working on at the moment has about 1/2 million lines of source. > > Yes, we look over it carefully, but simulation is vitally important > > for a successful end result. > > The design in question consists of about 5k lines of code; there are > no functional simulation errors, nor do any errors appear in the > timing report. The post-PAR simulation errors seem to be caused by > setup and/or hold violations in logic that is synchronizing signals > across two time domains, and as "nospam" pointed out, these are > allowable and inherently unavoidable. > > The issue as I see it is the shear volume of errors I get under > simulation, simply because there are so many such points of > synchronization--the FPGA must interface with three external time > domains, and a handful of new internal domains were created for > various reasons. It makes it very difficult under simulation to > distinguish these allowable/unavoidable timing errors from > legitimately critical timing errors. Obviously, in my next design, > I'll minimize the number of time domains and the size of the > interfaces between domains, in order to make this task more manageable > . . . but is it worth ripping this finished design apart to get more > acceptable simulation results? Or given the size, is the methodology > John suggested (careful code inspection) sufficient? Thanks again for > your input. > > JoeArticle: 49146
I've done a few FPGA prototypes of designs that we knew in advance were going to be ASICs. We used TSMC and IBM. I never heard the price on the TSMC and I think IBM was charging something like $400k for chip #1. However, expect foundries to be very agreeable these days on account of the surplus capacity. The results went fine, because usually, by the time you've worked out all the bugs to get the FPGA to work in the lab, you've solved most of your problems. Also FPGA use sort of forces a certain level of simplicity with repect to clocking. A BIG FPGA turns into a small ASIC because of the difference in area efficiency. Also, expect about a 4X speed-up going to ASIC. And of course, yes you can hand place, super pipeline, embedded multiplier, etc your FPGA to get a faster design, but I'm speaking in general for random logic writen by your average ASIC designer, not spending all the time to get so deep into the implimentation details. President, Quadrature Peripherals Altera, Xilinx and Digital Design Consulting email: kayrock66@yahoo.com http://fpga.tripod.com ----------------------------------------------------------------------------- "alla" <alng23@hotmail.com> wrote in message news:<aps669$cdd$1@tilde.itg.ti.com>... > Just want see anyone here has any experience of converting a Xilinx FPGA > design into an ASIC implementation. If so, which vendor did you use? What's > the cost? Are you happy with the result? We are using the Virtex series and > considering this option. ThanksArticle: 49147
On Fri, 01 Nov 2002 17:45:52 +1300, Jim Granville <jim.granville@designtools.co.nz> wrote: >skyhawk172L@attbi.com wrote: >> >> On Fri, 01 Nov 2002 15:25:46 +1300, Jim Granville >> <jim.granville@designtools.co.nz> wrote: >> >> >skyhawk172L@attbi.com wrote: >> >> >> >> Has anyone seen any instances of the image programmed in a Xilinx >> >> XC18VXX device getting corrupted? >> >> >> >> I've seen this several times on both XC18V02 and XC18V04 devices. We >> >> load an image in the PROM once and don't touch it again. The FPGA gets >> >> successfully configured by the PROM numerous times until one day >> >> configuration fails. Once it fails, the only way to get things working >> >> again is to reprogram the PROM. >> >> >> >> Anyone else seen anything like this?? >> > >> > Next time it occurs, read the PROM, and check the details of the >> >failure(s). ( 0->1 or 1->0, Bit/Byte/Row etc ) >> > >> > Does raise an intersting question about ECC in Loader devices ? >> > >> >-jg >> >> What, specifically, should I be looking for? I had one fail today and >> did a 'verify'. It came back and told me there was a mismatch at a >> certain location in the PROM. >> >> I can also do a 'readback' from the PROM and see what's in there. I >> can see differences. Now what?? > > Readback a failed one to a file, and if that file is not identical >in format to the loaded one, read a GOOD prom back as well >( easy way to get two comparable files :) > Also, read a BLANK one, to check which polarity is blank. > > Then, run a file compare program to compare both files, and check >the differences report. > Page-flipping in an editor can also show changes, once you know where >to look. > > - jg I did a readback of the failed prom and compared it to a readback of a good prom. I found one data bit that should be a 1 had become a 0 in the failure case. This obviously caused the checksum for that row to be different as well. I don't think a spurious 'erase' could wipe out one bit. It's more like a voltage threshold degradation within the part or something along those lines. Any other ideas?? Now that I'm convinced I have a real issue here, I'm curious if others have run into this as well. Any similar experiences out there??Article: 49148
skyhawk172L@attbi.com wrote: > > On Fri, 01 Nov 2002 17:45:52 +1300, Jim Granville > <jim.granville@designtools.co.nz> wrote: > > >skyhawk172L@attbi.com wrote: > >> > >> On Fri, 01 Nov 2002 15:25:46 +1300, Jim Granville > >> <jim.granville@designtools.co.nz> wrote: > >> > >> >skyhawk172L@attbi.com wrote: > >> >> > >> >> Has anyone seen any instances of the image programmed in a Xilinx > >> >> XC18VXX device getting corrupted? > >> >> > >> >> I've seen this several times on both XC18V02 and XC18V04 devices. We > >> >> load an image in the PROM once and don't touch it again. The FPGA gets > >> >> successfully configured by the PROM numerous times until one day > >> >> configuration fails. Once it fails, the only way to get things working > >> >> again is to reprogram the PROM. > >> >> > >> >> Anyone else seen anything like this?? > >> > > >> > Next time it occurs, read the PROM, and check the details of the > >> >failure(s). ( 0->1 or 1->0, Bit/Byte/Row etc ) > >> > > >> > Does raise an intersting question about ECC in Loader devices ? > >> > > >> >-jg > >> > >> What, specifically, should I be looking for? I had one fail today and > >> did a 'verify'. It came back and told me there was a mismatch at a > >> certain location in the PROM. > >> > >> I can also do a 'readback' from the PROM and see what's in there. I > >> can see differences. Now what?? > > > > Readback a failed one to a file, and if that file is not identical > >in format to the loaded one, read a GOOD prom back as well > >( easy way to get two comparable files :) > > Also, read a BLANK one, to check which polarity is blank. > > > > Then, run a file compare program to compare both files, and check > >the differences report. > > Page-flipping in an editor can also show changes, once you know where > >to look. > > > > - jg > > I did a readback of the failed prom and compared it to a readback of a > good prom. I found one data bit that should be a 1 had become a 0 in > the failure case. This obviously caused the checksum for that row to > be different as well. What is 'erased' state for a XC18VXX ? On FLASH memory it's 1111 is Erased, but XC18xx could differ. > I don't think a spurious 'erase' could wipe out one bit. It's more > like a voltage threshold degradation within the part or something > along those lines. Any other ideas?? PGM of a bit is by charge bubble tunneling, and if a BIT that was pgmd changes to erased, that's typical of a leaky bit cell. If the opposite occurs - A bit that was 'erased' becomes 'pgmd', then that is typical of marginal erase, and typically appears as Vcc is decreased. > Now that I'm convinced I have a real issue here, I'm curious if others > have run into this as well. Any similar experiences out there?? -jgArticle: 49149
On Fri, 01 Nov 2002 05:02:45 GMT, "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote: > >"Peter Alfke" <peter@xilinx.com> wrote in message >news:3DC1CF68.722D62F7@xilinx.com... >> >(snip regarding clock edge and master-slave flip-flops) >> >> This is whereI disagree, and this is the reason for continuing this >pedantic >> thread: >> A flip-flop can NEVER miss a clock. There is NO way to sneak the clock >from one >> level to the other, without the flip-flop recognizing it. >> That's always my argument when users complain that a counter bit does not >> toggle. It cannot avoid toggling, but it might have toggled twice, which >looks >> deceptively like no toggle... >> > >The one I remember being told not to do, though maybe it doesn't >exactly apply here, has to do with reset on asynchronous counters. > >If you want an asynchronous BCD counter, you can set up an >AND gate to reset the counter when it gets to B'1010'. It is possible >that the such reset signal won't reset all the FF's before the reset >signal goes away. > >In the case of edge triggered FF's, say for a falling edge, I would >expect there to be a case where the clock wasn't high long enough >before the falling edge. > >I seem to remember some circuit that I think Peter posted before >containing two FF's where one times the signal for the other such >that it can be guaranteed to have the right timing. I can't remember >any more about it than that, though. > >-- glen > > Or even a shift register, say 2 stages, with a one input Start 1 - A - 0 - B - 1 Since A and B will not trigger at exactly the same voltage, and a slow clock means the setup times can be met. Assume that flip-flop A triggers first Low mid 1 - A - 1 - B - 1 because A triggered first higher mid 1 - A - 1 - B - 1 B clocked in the new 1 from A, instead of the original 0 This would appear to be F/F B missed the clock, because it missed the 0 input. All ditigal circuits are made of analog components, and no two gates will have exactly the same triggering levels. Fast clock edges will have all circuits using the setup delays to remember the levels. You would need every FF to be double buffered, using seperate clocks to clock into the master and into the slave. This can (and has) been done, but not with modern ICs.
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