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
I want to synthesize the following N bit counter with Synopsys (design
compiler) or Mentor Graphics (Autologic II).
Both doing something and can optimize fine for minimal area.
But if I want to get minimal delay (must use a adder ( + 1 ) with
carry look ahead logic) they fail!
How can I solve the problem? Drawing in a schematic entry tool?
By the way the target technology is an ACT1 from Actel.
Thanks in Advance
J"oerg
library ieee; use ieee.std_logic_1164.all;
library ieee; use ieee.std_logic_arith.all;
entity cnt is
generic( N : positive );
port(
clk : in std_ulogic;
rst : in std_ulogic;
cnt : out std_ulogic_vector(N-1 DOWNTO 0)
);
end cnt;
architecture cnt_a of cnt is
signal count : integer range 0 to 2**N-1;
begin
process(clk,rst)
begin
if (rst = '1') then
count <= 0;
elsif (clk'event and clk = '1') then
if (count = 2**N-1) then
count <= 0;
else
count <= count +1;
end if;
end if;
end process;
cnt <= std_ulogic_vector(conv_unsigned(count,N));
end cnt_a;
--
Joerg Schoeppe - Labor Mikroelektronik - FH-Muenchen
schoeppe@mec.fh-muenchen.de - http://www.mec.fh-muenchen.de/~schoeppe
Public key available via 'finger -l schoeppe@sun1.mec.fh-muenchen.de'
Key fingerprint = C1 58 7A 1E BD 88 75 6B 21 8E 80 78 CB 09 67 7C
Article: 5176>>3) ViewLogic DOS : as close to bug-free as any other tool, nicely integrated >>schematic editor/simulator, good support for Xilinx (e.g. attribute mechanism >>for schematic). Decent documentation > >Kind of disagrees with the previous poster. Does it? The old DOS Viewlogic+XACT stuff is actually excellent, bugs-wise. The really painful thing is upgrading to the Windows versions. For the cost of the "upgrade" you can buy yourself several PCs, and over a number of years you pay enough to buy a very reasonable car. I have recently been billed about $1000 for the annual maintenance for the XACT6 place/route tools alone - I refused to pay it, so bye bye to any bug fixes, like the one with the pre-1/1/97 date. This is why there are more than a few of us still using these old tools. Unless you are moving to XC6k etc, or do really demanding work, they do the job fine. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 5177
Aren't these supposed to have CRC checking on the config bitstream? (followups trimmed) Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 5178
Peter wrote:
> >Kind of disagrees with the previous poster.
>
> Does it?
>
> The old DOS Viewlogic+XACT stuff is actually excellent, bugs-wise. The
> really painful thing is upgrading to the Windows versions. For the
> cost of the "upgrade" you can buy yourself several PCs, and over a
> number of years you pay enough to buy a very reasonable car. I have
> recently been billed about $1000 for the annual maintenance for the
> XACT6 place/route tools alone - I refused to pay it, so bye bye to any
> bug fixes, like the one with the pre-1/1/97 date.
>
> This is why there are more than a few of us still using these old
> tools. Unless you are moving to XC6k etc, or do really demanding work,
> they do the job fine.
>
> Peter.
As "the previous poster", the sequence of events went:-
1) Buy the DOS-based tools. Hack my PC about until they ran, not a
trivial piece of work, but done eventually.
2) Discover that the documentation for the VHDL components of the
PC-Xilinx-Viewlogic software was basically wrong. The flows wouldn't,
the sample code was uncompilable, and, for some reason, the books had
been printed in an ink that smelled like cat piss. The last I could have
lived with, the other two made learning anything a bit of a challenge.
3) Rather than answer my tech support queries on the DOS toolset, I was
'upgraded' to the Windows version. Perhaps this was where I went wrong.
On moving to the Windows version, I also got a new PC, and didn't spend
the time to get the 'redundant' DOS toolset running on it.
It looks like I ought to have bought myself a monitor+keyboard switch
box and kept running the DOS version for sanity-checking. Oh well, way
too late now. There was definitely a lack of communication between me,
the dealer and the vendors.
(Through all the above, try desparately hard to design and ship product,
despite everything. Perhaps all CAD vendors ought to run design bureaux
using their own tools, and _publish_ design flows that work, so we mere
mortals could stand a chance of copying them)
Still, from at least one other poster, Viewlogic now have a product for
the PC that works well, so I hope this is all dead and buried now.
All the best,
Steve.
--
Steve Wiseman, Senior Systems Engineer, SJ Consulting Ltd, Cambridge, UK
Desk +44 1223 578524 (Fax 578524) Group +44 1223 578518 steve@sj.co.uk
Article: 5179
In message <5cnlo1$q6t@sparcserver.lrz-muenchen.de>
schoeppe@mec.fh-muenchen.de (Joerg Schoeppe) writes:
> I want to synthesize the following N bit counter with Synopsys (design
> compiler) or Mentor Graphics (Autologic II).
.
.
.
Have you tried using Actel's Actgen macro builder. This optimizes
for either speed or area and the results are available as EDIF or
VHDL files. The only problem with the VHDL may be that the components
are instantiations of Actel cells which might not be recognised by
Synopsis or Mentor unless you define them separately.
Geoff Bostock
(PLD/FPGA consultant)
Article: 5180Yes, the Xilinx XC4000E/EX, XC5200 FPGA have CRC checking on the configuration bitstream if the option is turned on. This just checks the configuration data as it enters the device. It does not check the results constantly after the initial configuration. -- Steven Knapp E-mail: optmagic@ix.netcom.com Programmable Logic Jump Station: http://www.netcom.com/~optmagic Peter <zx80@dgiserve.com> wrote in article <32f06026.1916545@news.alt.net>... > Aren't these supposed to have CRC checking on the config bitstream? > > (followups trimmed)Article: 5181
Wayne Turner (waynet@goodnet.com) wrote: : garyk@svpal.svpal.org (George Noten) wrote: : >Here is my experience: : >1) Xilinx vs Altera support: I work mostly with Xilinx and usually get : >response from them the same day or, sometimes, next day. If I send email : >to Xilinx support they usually respond by email within 3-4 days or less. : >Similar email request to Altera was answered in 10 days. However, I think : >that they are basically equivalent if you are talking about support over : >the long term and not separate cases. : Pretty weird to email, since you can call and someone will answer the phone. Pretty weird to call since this "someone" is the receptionist. She tells you that all the engineers are busy and they will call you back soon. They usually do and it initiates telephone tag game for the rest of the day. Be- sides they usually need to have your files (schematic, VHDL, XNF etc.). I don't need to speek to them before emailing all this stuff together with customer ID and short description of the problem. : >2) *THE BIG DIFFERENCE* : real-life example from the last month. : >Altera just discontinued their FLASHlogic family and gave its customers : >6 months to decide on orders and quantities and then 1 more year for : >shipments. NOBODY KNEW IT WAS COMING !!!!!. Quite a surprise that will : >cost our company a lot of money. : Neither did Altera. Sharp gave a last time buy notice on wafers for : FlashLogic. As you know, it's a rather complex process (being both FLASH and : SRAM) and no one else seems interested in making the wafers at the volumes : they sell at. Does it mean that the rest of Altera customers should pay for their problems? : As for Xilinx, they came to my design group two years ago saying that : anti-fuse is the future; they already dumped it. Yes, but this part never got out of "preliminary" category and there are no customers that were using it for years. : >Xilinx discontinued their 2000 Series FPGA in the following way: : > a) for quite some time (about a year) it was not recommended for new designs : > b) the customers have time till January 1999 to make orders and till July : > 1999 for the last delivery. : >This is the proper way to do it. : It is if it is under your control. Altera still ships devices from the : mid-1980s because there is demand due to existing product. The normal method : for obseleting a device is much as you've stated. This one wasn't up to them. This one was. : >3) ViewLogic DOS : as close to bug-free as any other tool, nicely integrated : >schematic editor/simulator, good support for Xilinx (e.g. attribute mechanism : >for schematic). Decent documentation : Kind of disagrees with the previous poster. What other tools have you tried? Orcad with Xilinx library and Xact George.Article: 5182
Austin Franklin (#darkroom@ix.netcom.com#) wrote: : Xilinx 3k and 4k both have internal tri-state busses. And so do Xilinx 5k.Article: 5183
OK, I suppose one could have a design in which lots of tri-state buffers drive each other. >Yes, the Xilinx XC4000E/EX, XC5200 FPGA have CRC checking on the >configuration bitstream if the option is turned on. This just checks the >configuration data as it enters the device. It does not check the results >constantly after the initial configuration. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 5184
The optimization of counters for highest speed is quite complex, since there are many different methods available ( carry lookahead, carry select or anticipate etc ) It also depends whether the counter is loadable or not. A unidirectional, non-loadable counter can be made very fast by using the "Count Enable Trickle & Count Enable Parallel" trick popularized by the 74160-series counters. I doubt very much that you can just push a button and have the synthesizer take care of these trade-offs. Of course, if I'm allowed a subtle advertising here, you could use Xilinx XC4000 or XC5200 devices which have dedicated carry hardware and plenty of library elements for fast counters. In these devices, carry speed is a non-issue, unless you want to run faster than 100 MHz. Non-loadable counters using the CEP/CET trick can run at 200 MHz in XC3100-09 evices. But you can obviously implement the same logic trick in Actel devices. Just ask their applications group. Most of us have several tricks up our sleeves. Fast counters are a neat and clean challenge, where an experienced applications engineer can beat a synthesis tool any day. Peter Alfke, Xilinx AplicationsArticle: 5185
Joerg Schoeppe wrote: > > I want to synthesize the following N bit counter with Synopsys (design > compiler) or Mentor Graphics (Autologic II). > > Both doing something and can optimize fine for minimal area. > > But if I want to get minimal delay (must use a adder ( + 1 ) with > carry look ahead logic) they fail! > > <rest of message snipped> > I am assuming by "fail" you mean you get stuck with a ripple carry architecture, and you can't seem to optimize past that. I will address the problem in Mentor's Autologic, since I am not very experienced with Synopsys DC. Note that what I say below about adders applies equally to counters. The basic problem revolves around the '+' operator and your optimization process. If you do an area optimization, allowing the tool to dissolve (i.e. interpret) the operator during area optimization, then you will get a standard ripple carry adder, which is usually the minimum area adder available in any technology. Once the operator has been dissolved in this manner, no amount of timing optimization will result in a carry lookahead (or carry select, or any other fast/big) adder being generated. It is beyond the tool to make this complicated a size/speed tradeoff using the timing algorithms at its disposal. There are two ways around this: 1) It is possible to keep operators from being dissolved during area optimization. I forget the exact command for this, so check your docs. You will see a '+' operator in the design browser if you look for it. Do your area optimization without dissolving the operator - the rest of the circuit logic will be optimized & mapped, but this operator will remain. Now, when you do a timing optimization, Autologic will select the minimum area adder (or counter) which will meet your timing criteria. 2) Write VHDL code which specifically implements a carry lookahead structure. Note that this is harder because you cannot simply write a process to do the job. If you use a single process, AutoLogic figures out you are trying to build an adder, and gives you the minimum area adder possible, i.e. the ripple carry, as before. What you have to do is separate various parts of the lookahead logic into separate ENTITY/ARCHITECTURE blocks. AutoLogic will not optimize across the hierarchy boundary (unless you flatten or otherwise rearrange the hierarchy prior to optimization), and since no single block contains an adder, AutoLogic will not "figure out" you have an adder, and smash all your wonderfully constructed logic into a ripple carry adder. You should then end up with the desired circuit. General Comment: 2) is trickier to implement, because you have to know something about how your tool implements hierarchy (i.e. what VHDL structures will invoke hierarchy in the circuit), and how to take advantage of this to prevent unwanted optimization. It can be a challenge to group the logic correctly so that the tool gives a good area results while preserving the structure. Also, 2) is less flexible than 1), since 1) will give the minimum area circuit (from among the choices available to it) meeting your needs (whether a carry lookahead, or something else), while 2 always gives you a carry lookahead, no matter what. The advantage of 2) is that once VHDL code is written, it will probably give this architecture regardless of the tool on which it is optimized. In other words, you don't have to find "the trick" for each tool which will be the equivalent of the operation described in 1). Hope this helps. Todd James Graduate Student, Electrical Engineering Ohio State University jamest@ee.eng.ohio-state.eduArticle: 5186
It depends what you mean by a fast counter. Is it count rate? In that case, you can't beat a ripple counter. If you need a fast synchronous method, then there's lots of methods available. Since you are designing an Actel device, I would recommend dumping the VHDL and using their macro generator (Actgen). All of the 'tricks' are encoded into this tool and you can select various options and the type of counter you want, depending on your requirements. If it fits your requirements, consider a counter based on a LFSR; very compact, very fast. I just used one of these to generate a counter running at 32 MHz for 32000 states in an FPGA. rkArticle: 5187
In article <32f0368f.4505959@news.alt.net>, zx80@dgiserve.com (Peter) wrote: > >>>3) ViewLogic DOS : as close to bug-free as any other tool, nicely integrated >>>schematic editor/simulator, good support for Xilinx (e.g. attribute mechanism >>>for schematic). Decent documentation >> >>Kind of disagrees with the previous poster. >Does it? Yes it does, if you bothered to read what the previous poster said. Did you? >The old DOS Viewlogic+XACT stuff is actually excellent, bugs-wise. The >really painful thing is upgrading to the Windows versions. For the >cost of the "upgrade" you can buy yourself several PCs, and over a >number of years you pay enough to buy a very reasonable car. I have >recently been billed about $1000 for the annual maintenance for the >XACT6 place/route tools alone - I refused to pay it, so bye bye to any >bug fixes, like the one with the pre-1/1/97 date. And bye-bye to support if you need it, since most companies don't want to support old versions of software when bugs have been fixed in later versions. >This is why there are more than a few of us still using these old >tools. Unless you are moving to XC6k etc, or do really demanding work, >they do the job fine. If it works for you then you're right, there is no reason for you to change. WayneArticle: 5188
In article <5cnvp6$d0p@borg.svpal.org>, garyk@svpal.svpal.org (George Noten) wrote: >Wayne Turner (waynet@goodnet.com) wrote: >: garyk@svpal.svpal.org (George Noten) wrote: >: >Here is my experience: >: >1) Xilinx vs Altera support: I work mostly with Xilinx and usually get >: >response from them the same day or, sometimes, next day. If I send email >: >to Xilinx support they usually respond by email within 3-4 days or less. >: >Similar email request to Altera was answered in 10 days. However, I think >: >that they are basically equivalent if you are talking about support over >: >the long term and not separate cases. > >: Pretty weird to email, since you can call and someone will answer the phone. > > Pretty weird to call since this "someone" is the receptionist. She tells > you that all the engineers are busy and they will call you back soon. They > usually do and it initiates telephone tag game for the rest of the day. Be- > sides they usually need to have your files (schematic, VHDL, XNF etc.). > I don't need to speek to them before emailing all this stuff together with > customer ID and short description of the problem. WRONG!!!!! There is NO receptionist at the Altera help-line, at least in the United States. You will be on hold until someone is available, and the person who comes on the line is an applications engineer, NOT a receptionist. What number are YOU dialing? >: >2) *THE BIG DIFFERENCE* : real-life example from the last month. >: >Altera just discontinued their FLASHlogic family and gave its customers >: >6 months to decide on orders and quantities and then 1 more year for >: >shipments. NOBODY KNEW IT WAS COMING !!!!!. Quite a surprise that will >: >cost our company a lot of money. > >: Neither did Altera. Sharp gave a last time buy notice on wafers for >: FlashLogic. As you know, it's a rather complex process (being both FLASH and >: SRAM) and no one else seems interested in making the wafers at the volumes >: they sell at. > > Does it mean that the rest of Altera customers should pay for their > problems? What is their option? Build a fab to make FlashLogic? They are put in the same situation as you are. Obselesence happens. >: As for Xilinx, they came to my design group two years ago saying that >: anti-fuse is the future; they already dumped it. > > Yes, but this part never got out of "preliminary" category and there are > no customers that were using it for years. Does it matter how long people were using it? If it does, how long had people been using FLASHlogic, considering it has only been around for a few years (and owned by Altera for less than two)? >: >Xilinx discontinued their 2000 Series FPGA in the following way: >: > a) for quite some time (about a year) it was not recommended for new > designs >: > b) the customers have time till January 1999 to make orders and till July >: > 1999 for the last delivery. >: >This is the proper way to do it. > >: It is if it is under your control. Altera still ships devices from the >: mid-1980s because there is demand due to existing product. The normal method >: for obseleting a device is much as you've stated. This one wasn't up to them. > > This one was. No, it wasn't. If your wafer supplier won't make the wafer anymore, what can you do if they are the only fab with that technology? >: >3) ViewLogic DOS : as close to bug-free as any other tool, nicely integrated >: >schematic editor/simulator, good support for Xilinx (e.g. attribute > mechanism >: >for schematic). Decent documentation > >: Kind of disagrees with the previous poster. What other tools have you tried? > > Orcad with Xilinx library and Xact I think I'd have to take Viewlogic over Orcad as well. WayneArticle: 5189
> Orcad with Xilinx library and Xact Interesting. Was this SDT/386? And how did you manage with simulation? VST? The main reason I am keeping the ancient Viewlogic stuff is that it has a good simulator. My experience of VST was very bad. Sorry - off topic :) Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 5190
In article <Pine.BSI.3.91.970128134422.10678A-100000@malasada.lava.net>,
Alvin E. Toda <aet@lava.net> wrote:
)It seems to me that to fail operational, you need FOUR rams. The assumption
)is that the rams do not have a parity bit and so a parity error is not
)noted on a read access. After one fails in a 3way vote, there are only two
)left and the system can only detect an error. Therefore, starting with four
)and losing one (assuming a single point failure), you still have three
)left and enough to still fail operational. And the system still needs
)to fix the data that is bad.
)
)It seems simpler in terms of hardware (and thus more reliable
)since fewer things can go wrong) to encode error correction in the data
)in the ram even if it complicates the software.
But one is still operational.
The shuttle has a TMR system for its main computers. If one gets voted
down, then the other two continue. If they disagree, then there is a
separate, different kind of computer with just enough smarts to land the
thing. That is the "backup" system.
Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for DSC. <- They make me say that.
Article: 5191Ahmad Alsolaim <aa939788@oak.cats.ohiou.edu> wrote in article <E4CJsF.4tM@boss.cs.ohiou.edu>... > Hello, > I am a P.h.D student at OhioU, I have been assigned to writ a > proposal for an FPGA development lab. And since I am new in this field, > can any one mail me a list of the most important things that have to bee > included in the proposal. we are going to use PC Pentium200 station and > Viewlogic's Workview Office. > Also what is the best (in terms of compatiblity with other vendors) > FPGAs testing borad. > > Thank you in advanced. > aalsolai@homer.ece.ohiou.edu > -- I recommend that you look at the Synopsys FPGA compiler for the PC (I can't remember the exact name). We do our design work in VHDL and until recently had been using Viewlogic but we found it to be such a pain to work with (both Windows and Unix versions!) that we dumped it completely and switched (at great expense) to Synopsys. Our gate counts immediately dropped by at least 30% and the timing improved by a similar margin.Article: 5192
Peter wrote: > > OK, I suppose one could have a design in which lots of tri-state > buffers drive each other. > > >Yes, the Xilinx XC4000E/EX, XC5200 FPGA have CRC checking on the > >configuration bitstream if the option is turned on. This just checks the > >configuration data as it enters the device. It does not check the results > >constantly after the initial configuration. > > Peter. > > Return address is invalid to help stop junk mail. > E-mail replies to z80@digiserve.com. Look at the XC6200. Since you can read the microprocessor port at any time you can hook up a small micro that does nothing but load the device and then calculate the CRC of the configuration. Also since you can create relocatable hardware you could have the small micro move any hardware away from the defective spot (hard fail). Since the XC6200 is open you could even write a program that would completely reroute the device (but you would have to be off line a couple of seconds:) Steve Casselman http://www.vcc.com/hotann.html couldArticle: 5193
Stuart Clubb wrote: > > Using your 2/3 rule, Why not try Lucent OR2C15A. They've been shipping > since February 1996, they're in 0.35-micron. They might even be lower > cost than the above two. > Because the cost of the development software is very high. At least last time I asked, it was said to be 10K $. You can buy a lot of 10K100 for that. AndreasArticle: 5194
There is a method of repetatively verifying the Xilinx configuration memory without using significant system resources. After the end of each full device readback the device shifts out the contents of the on chip CRC register. If you configured with READCAPTURE:DISABLE and are not using the CLBs as RAM then this CRC value will always come out the same for any given configuration. You can use the internal oscilator to clock the readback circuitry and a counter which will tell you when you have reached the CRC bits. These can then be checked against the expected value using only on chip resources. It will take a little patience or some software work to match the comparator value versus the config bits that program the comparator so be careful. Brian Peter wrote: > > OK, I suppose one could have a design in which lots of tri-state > buffers drive each other. > > >Yes, the Xilinx XC4000E/EX, XC5200 FPGA have CRC checking on the > >configuration bitstream if the option is turned on. This just checks the > >configuration data as it enters the device. It does not check the results > >constantly after the initial configuration. > > Peter. > > Return address is invalid to help stop junk mail. > E-mail replies to z80@digiserve.com.Article: 5195
jmccarty@sun1307.spd.dsccc.com (Mike McCarty) writes: > The shuttle has a TMR system for its main computers. If one gets voted > down, then the other two continue. If they disagree, then there is a > separate, different kind of computer with just enough smarts to land the > thing. That is the "backup" system. Nope. The shuttle's primary avionics system is quad-redundant, with an additional fifth computer running a backup system that is also totally different software (the first four have identical software). The most elaborate scheme I know of is in the Airbus A320. Every major functional block is implemented at least three times using different software by teams not allowed to talk to each other. The hardware also comes in a number of different versions, and care is taken so that no particular combination of functional blocks of software is replicated on any particular computer. Nonetheless, the different versions of each functional block must arrive at the same decisions. The only common mode failure I can think of are errors in the function and integral tables the teams use to write their software... JanArticle: 5196
"Austin Franklin" <#darkroom@ix.netcom.com#> wrote: >Peter, > >> Perhaps you are using the DOS versions of Viewlogic. > >No, I'm using Workview Office 7.2 under NT 4.0 WS. It's excellent! > > I'm using Workview Office 7.2 under 95a. It's absolutely dreadful. The minor bugs are legion & major ones far too common. The documentation is useless too (for troubleshooting at any rate). I've got the bit's of a new PC scattered around my desk & a shiny new NT 4.0 WS cd to run it. If the difference is magical, I'll post somthing in this group. (After I pick myself up off the floor of course ;-> ) JulianArticle: 5197
Does anybody know where I can get hold of the command line description of the DataIO ABEL6/Synario & Xilinx XACT tools (for XC9000 devices). The problem with this is that these tools run under the control of some Windoze thing called Project Navigator. All this seems to be is a glorified collection of make files & shell scripts glued together with a user-hostile Windows i/f. What I really want to do is install the tools on an NT machine, make up my own batch files, and use RSH to execute them remotely via the Unix system makefiles. Also: Do any of you Xilinx users out there know where I can get a description of the XNF file syntax ? Or is this still a deep dark secret? _________________________________________________________________________ Dr. Richard Filipkiewicz phone: +44 171 700 3301 Algorithmics Ltd. fax: +44 171 700 3400 3 Drayton Park email: rick@algor.co.uk London N5 1NU EnglandArticle: 5198
Julian Cox wrote: > > "Austin Franklin" <#darkroom@ix.netcom.com#> wrote: > > >Peter, > > > >> Perhaps you are using the DOS versions of Viewlogic. > > > >No, I'm using Workview Office 7.2 under NT 4.0 WS. It's excellent! > > > > > I'm using Workview Office 7.2 under 95a. It's absolutely dreadful. > The minor bugs are legion & major ones far too common. The > documentation is useless too (for troubleshooting at any rate). > > I've got the bit's of a new PC scattered around my desk & a shiny new > NT 4.0 WS cd to run it. If the difference is magical, I'll post > somthing in this group. (After I pick myself up off the floor of > course ;-> ) > > Julian Well, I must agree with Julian 100%, with Win95 Workview Office 7.2 is a rather "interesting" experience ... I'm curious to see if it gives "real" improvements going from Win95 to NT 4.0 MarcArticle: 5199
Brian reminds us that the XC4K readback includes a CRC, and by setting the appropriate option, and not usung the CLB RAM capability, the CRC value will be constant, and can be read back continuously, using only internal resources. The compare need only be done between the readback CRC, and a constant copy kept somewhere else. He goes on to suggest that the compare (and I assume the reference copy of the CRC) might also be done on chip. I have thought about this for a few years, and I suspect but can not prove, that this is not possible. The reason is that the storing of a reference CRC value on chip will permute the calculated CRC. If you then change the reference value to the new value, it will just permute again. I suspect you may be able to play this silly game forever. Reference: Patent 5,321,704 Recomendation: Store the reference CRC outside the FPGA. Philip Freidin. In article <32F0481F.637D@ihot.com> bfox@ihot.com writes: >There is a method of repetatively verifying the Xilinx configuration >memory without using significant system resources. > >After the end of each full device readback the device shifts out the >contents of the on chip CRC register. If you configured with >READCAPTURE:DISABLE and are not using the CLBs as RAM then this CRC >value will always come out the same for any given configuration. > >You can use the internal oscilator to clock the readback circuitry and a >counter which will tell you when you have reached the CRC bits. These >can then be checked against the expected value using only on chip >resources. It will take a little patience or some software work to >match the comparator value versus the config bits that program the >comparator so be careful. >Brian
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