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
On Wed, 29 Mar 2000 22:34:52, galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > In article <38E21159.490EB7CD@ids.net>, Ray Andraka wrote: > >No, I'm just presenting the technical side of what I suspect is the vendor's reluctance to > >release it. There are times I've needed to get into the bitstream to modify it slightly, and > >there an open format would have been helpful. On the otherhand, I can plainly see why the > >Vendors would not want to put this out for general consumption. > > I was replying to Keith, not you. :) Ok, and your point? He answered most of the points I was addressing, likely better than I could. ..or do you just like my keyboarding? ;-) ---- KeithArticle: 21726
Understood. However, the fact is that the astronauts have told the OBS people that they would never pull the lever in flight. By the time time things got so bad that they'd try un-FLIGHT-tested software they'd be dead, or so hopelessy lost that it wouldn't matter. Note that they won't test the backup software on a nominal flight. It's one thing to screw up in the simulator because you're "dead" and another kettle-o-fish to be in space and pull the plug on something you've always trusted. With the dynamics there isn't time to react and any reaction is *going* to go with what you know - right or wrong. On Wed, 29 Mar 2000 03:21:33, rk <stellare@nospam.erols.com> wrote: > Keith R. Williams wrote: > > > > The one example of a system with diversity that I am aware of is the Space > > > Shuttle's main computer system. It consists of 5 computers, with identical > > > hardware. The software, however, is identical on the 4 computers that > > > actually do the work. A fifth computer, running but not controlling the > > > vehicle unless commanded to, runs software developed by a completely > > > independent team. > > > > This is correct. Note the astronauts have also said that they > > would never pull the switch to go to the redundant software (it > > is a manual override). They trust the Shuttle OBS and have never > > tried the other. > > > > > > Anyone else know of any other examples? > > > > Other than multiple parallel, but identical, TMR circuits in a > > crypto processor I don't know of any. It's incredibly expensive > > to duplicate everything, especially the intellectual part. Then, > > when you get an error after years of fault-free operation, do you > > want to trust a newbie? When do you make that determination? > > ..likely when things have gone so wrong it's too late. I > > believe it's better to throw that money and tallent at making > > sure the original problem is solved. I believe the Shuttle OBS > > is evidence of this, both ways. > > Here's an excerpt from: > > The Space Shuttle Primary Computer System > A. Spector and D. Gifford > Communications of the ACM, September, 1984, p. 874 > > which is "interesting" ... > > > AS. Could you describe a training scenario on the SMS that caused a problem > for you? > > Clemons. Yes - it was a "bad-news - good-news" situation. In 1981, just > before STS-2 was scheduled to take off, some fuel spilled on the vehicle and > a number of tiles fell off. The mission was therefore delayed for a month > or so. there wasn't much to do at the Cape, so the crew came back to > Houston to put in more time on the SMS. > > One of the abort simulations they chose to test is called a "TransAtlantic > abort," which supposes that the crew can neither return to the launch site > nor go into orbit. The objective is to land in Spain after dumping some > fuel. The crew was about to go into this dump sequence when all four of our > flight computer machines locked up and went "catatonic." Had this been the > real thing, the Shuttle would probably have had difficulty landing. This > kind of scenario could only occur under a very specific and unlikely > combination of physical and aerodynamic conditions; but there it was: Our > machines stopped. Our greatest fear had materialized - a generic software > problem. > We went off to look at the problem. The crew was rather upset, and they > went off to lunch. > > AS. And contemplated their future on the next mission? > > Clemons. We contemplated our future too. We analyzed the dump and > determined what had happened. Some software in all four machines had > simultaneously branched off into a place where there wasn't any code to > branch off into. This resulted in a short loop in the operating system that > was trying to field and to service repeated interrupts. No applications > were being run. All the displays got a big X across them indicating that > there were not being serviced. > > rk >Article: 21727
EDM, Here is a link that I hope will be helpful: http://rk.gsfc.nasa.gov/richcontent/eeelinks/eee_links/9703_eee.htm It is a paper by the title of "Programmable Logic Application Notes" which addresses Single Point Failure, Single Event Upset, and radiation Total Dose issues for multiple PLD technologies. It lists useful items for anyone doing designs for space or high radiation environments. Regards, Jonathan Feifarek Beyond the Horizon Ent.Article: 21728
Hello all, I'm trying to make a macro with an HIZ output but can only get plain OUT outputs even though the underlying part has an HIZ output. The macro editor lets me change the pin type to HIZ and save it but when I reload it, the pin type is set back to OUT. I can create a BIDIR pin which might work but what I really want is HIZ. Thanks for any ideas, ChuckArticle: 21729
Greg Alexander wrote:
>
> >
> >I think, you (Greg) should start with that and roll your own tools
> >down to XDL. If you are there, you can still start looking around
> >for the bitgen option.
> >I guess that final step is than not hard anymore.
>
> There'll always be a nagging
> suspicion that perhaps it's buggy or similar. If you work with
> proprietary software on a daily basis you are completely used to the
> suspicion, you don't even let t enter your concious mind, but I've known
> another way and it's really hard to go back.
>
I am aware that most software contain bugs. In particular my own.
Its one of the most basic facts of life that human beeings make
mistakes.
I do a lot of scripting to make cross checks of the results at every
point
in design flow.
Some examples:
I count the number of lines in the pcf (physical constraints file),
check the reports on TBUFs and IOB FFs used in the reports and so on.
Most mistakes are discover are mine.
Our front end tool (Sy..s), perl and the xilinx tools are among the best
software
I used so far.
Andreas
-----------------------------------------------------------------
Andreas C. Doering
Medizinische Universitaet zu Luebeck
Institut fuer Technische Informatik
Ratzeburger Allee 160
D-23538 Luebeck Germany
Tel.: +49 451 500-3741, Fax: -3687
Email: doering@iti.mu-luebeck.de
Home: http://www.iti.mu-luebeck.de/~doering
quiz, papers, VHDL, music
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 21730
Hi Keith,
This is an interesting example of a computer system designed for high-reliability in a
very critical application. That fly-by-wire system is required to operate during
flight. It also did have a systematic flaw that was uncovered despite very extensive
analysis and test that forced things to lock up which made the astronauts slightly less
then happy.
From the same reference:
DG. How do you make the system reliable?
...
As I mentioned, there is a fifth computer that runs the Backup Flight System
(BFS). Early on, NASA was concerned about the possibility of a generic software
problem in the PASS. what if there were a "bug" in the PASS that brought the
entire primary system down? The way they alleviated their fears was by developing
independent ascent and entry software from a subset of the requirements they had
given us. This independent software was witten by Rockwell International and
resides in the fifth computer.
...
The decision to engage the VGS is totally a crew function. Their procedures
indentify certain situations for which the switch should be made: for instance,
loss of control, multiple consecutive failures of PASS coputers, or the infamous
two-on-two split where the computers split up into two pairs (we've never seen
this occur). To date the crew has never had to use the BFS during a mission..
Of course, I assume that the crew would follow their procedures. I would suggest
follow-up on current Shuttle procedures be directed to sci.space.shuttle where one can
find people currently employed in the Shuttle program and some of the original
designers of that computer system (not me) as that would be too off-topic for this
group.
How much time would they have in this particular system to switch to a backup? That's
a good question. Again, I'll just take a quick snip from the reference:
DB. How quickly would the astronauts have to switchover from the PASS to the BFS?
Spotz. In the worst case, there would be a 400-millisecond window where, if the
whole primary went down and had previously commanded hard overs on the thrust
vector controllers, we would lose the vehicle if they couldn't switchover in
time. This would be at maximum dynamic pressure, shortly after lift-off.
The general rule, based onobservations from the crew trainer, is that if they
can't switchover within about 10 seconds, they needn't bother. There are physical
reasons for this: One is that the integrating accelerometer registers overflow in
about 10 seconds at three gravities. After 10 seconds, they would have lost 1000
feet per second in velocity.
As long as the BFS is able to listen to all of the data the primary is getting,
there's no real constraint unless the primary issues a hard over command
improperly. If the primary stops issuing I/O commands, the crew has about 10
seconds from that point.
Some more information on this is available from _Computers in Spaceflight - The NASA
Experience_, James E. Tomayko,Wichita State University:
At first the backup flight system computer was not considered to be a permanent
fixture. When safety level requirements were lowered, some IBM and NASA people
expected the fifth computer to be removed after the Approach and Landing Test
phase of the Shuttle program and certainly after the flight test phase (STS-1
through 4). However, the utility of the backup system as insurance against a
generic software error in the primary system outweighed considerations of the
savings in weight, power, and complexity to be made by [104] eliminating it.
The reference for this last sentence: A.D. Aldrich, "A Sixth GPC On-Orbit,"
Memorandum, Johnson Space Center, Houston, TX, October 13, 1978, JSC History
Office.
Clearly, this system was designed with diversity. Again, any one know of any others?
One other is, Gemini, although I don't recall that the intent was to provide a
"diverse" system by use of a different computer for a backup. In that case, their
launch vehicle [Titan] was essentially a missle; for backup, the astronauts could use
the Gemini computer if necessary, with switchover done either or automatically or by
manual control. This was part of man rating that particular system. The Saturn V,
designed for manned operations from the start, was internally redundant such that it
could operate, non-stop, through a fault. I have seen some attitude control systems
designed with diversity where an analog backup was used along with a primary digital
system.
"18 Years of Flight Experience with the UoSAT Microsatellites," Craig I. Underwood,
discusses their use of diverse design. This was presented at ESCCON, 2000. I'll quote
some of the general verbiage; he follows up with specifics of how other components
provide functional backup.
In the "Design Philosophy" section:
Recognising the risk inherent in the use of components which are not formally
“space qualified”, we use redundancy at
many levels to reduce the risk of total mission failure. When adopting new
technologies, we employ them alongside
flight-proven technologies in order to reduce risk. Thus we build a “layered
architecture”, in which each successive layer relies on different systems
comprising increasingly well-proven technologies. The top-layer systems use
state-of-the-art high-performance device types - often without flight-heritage -
but which give a high degree of functionality. Whereas the lower-layer systems use
device-types which have been flown and tested in previous spacecraft, and which
are able to carry out most of the same functions, albeit with a possible loss of
performance. In this way, problems caused by an inherent system design fault, or
by the failure of a particular device-type, are not duplicated in the different
layers.
Going through various notes and references laying around, I can only quickly find one
more reference to diverse systems in _Reducing Space Mission Cost_, Wertz and Larson.
Here's a quick quote (p. 299):
In diverse design redundancy two or more components of different design furnish
the same service. This has two advantages: it offers high protection against
failures due to design deficiencies, and it can offer lower cost if the back-up
unit is a "life-boat," with lower accuracy and functionality, but still adequate
for the minimum mission needs. The installation of diverse units usually adds to
logistic cost because of additional test specifications, fixtures, and spare
parts. This form of redundancy is, therefore, economical primarily where the
back-up unit comes from a previous satellite design, or where there is experience
with it from another source. Where there is concern about the design integrity of
a primary component, diverse design redundancy may have to be employed regardless
of cost. [Unfortunately they don't give, in their case studies, specific examples
of this, or at least none that I could find at this hour].
I have some other references that might include more material on this but they are not
available right now.
Clearly, common design errors in redundant systems is a strong concern for designers of
these systems [or at least they should be]. Other then the Space Shuttle, I can't
think off-hand of any other operating systems that do offer diverse design for
reliability purposes. The other application of "diversity" is usually employed in
verification efforts, either through independent design verification or an independent
test team. This, of course, is quite common, as there is a strong desire not to repeat
the same mistake, particularly an assumption, during the verification effort.
Have a good evening/morning or whatever, as appropriate for your time zone,
An interesting discussion,
Regards,
rk
============================================
Keith R. Williams wrote:
> Understood. However, the fact is that the astronauts have told
> the OBS people that they would never pull the lever in flight.
> By the time time things got so bad that they'd try
> un-FLIGHT-tested software they'd be dead, or so hopelessy lost
> that it wouldn't matter. Note that they won't test the backup
> software on a nominal flight.
>
> It's one thing to screw up in the simulator because you're "dead"
> and another kettle-o-fish to be in space and pull the plug on
> something you've always trusted. With the dynamics there isn't
> time to react and any reaction is *going* to go with what you
> know - right or wrong.
>
> On Wed, 29 Mar 2000 03:21:33, rk <stellare@nospam.erols.com>
> wrote:
>
> > Keith R. Williams wrote:
> >
> > > > The one example of a system with diversity that I am aware of is the Space
> > > > Shuttle's main computer system. It consists of 5 computers, with identical
> > > > hardware. The software, however, is identical on the 4 computers that
> > > > actually do the work. A fifth computer, running but not controlling the
> > > > vehicle unless commanded to, runs software developed by a completely
> > > > independent team.
> > >
> > > This is correct. Note the astronauts have also said that they
> > > would never pull the switch to go to the redundant software (it
> > > is a manual override). They trust the Shuttle OBS and have never
> > > tried the other.
> > > >
> > > > Anyone else know of any other examples?
> > >
> > > Other than multiple parallel, but identical, TMR circuits in a
> > > crypto processor I don't know of any. It's incredibly expensive
> > > to duplicate everything, especially the intellectual part. Then,
> > > when you get an error after years of fault-free operation, do you
> > > want to trust a newbie? When do you make that determination?
> > > ..likely when things have gone so wrong it's too late. I
> > > believe it's better to throw that money and tallent at making
> > > sure the original problem is solved. I believe the Shuttle OBS
> > > is evidence of this, both ways.
> >
> > Here's an excerpt from:
> >
> > The Space Shuttle Primary Computer System
> > A. Spector and D. Gifford
> > Communications of the ACM, September, 1984, p. 874
> >
> > which is "interesting" ...
> >
> >
> > AS. Could you describe a training scenario on the SMS that caused a problem
> > for you?
> >
> > Clemons. Yes - it was a "bad-news - good-news" situation. In 1981, just
> > before STS-2 was scheduled to take off, some fuel spilled on the vehicle and
> > a number of tiles fell off. The mission was therefore delayed for a month
> > or so. there wasn't much to do at the Cape, so the crew came back to
> > Houston to put in more time on the SMS.
> >
> > One of the abort simulations they chose to test is called a "TransAtlantic
> > abort," which supposes that the crew can neither return to the launch site
> > nor go into orbit. The objective is to land in Spain after dumping some
> > fuel. The crew was about to go into this dump sequence when all four of our
> > flight computer machines locked up and went "catatonic." Had this been the
> > real thing, the Shuttle would probably have had difficulty landing. This
> > kind of scenario could only occur under a very specific and unlikely
> > combination of physical and aerodynamic conditions; but there it was: Our
> > machines stopped. Our greatest fear had materialized - a generic software
> > problem.
> > We went off to look at the problem. The crew was rather upset, and they
> > went off to lunch.
> >
> > AS. And contemplated their future on the next mission?
> >
> > Clemons. We contemplated our future too. We analyzed the dump and
> > determined what had happened. Some software in all four machines had
> > simultaneously branched off into a place where there wasn't any code to
> > branch off into. This resulted in a short loop in the operating system that
> > was trying to field and to service repeated interrupts. No applications
> > were being run. All the displays got a big X across them indicating that
> > there were not being serviced.
> >
> > rk
> >
Article: 21731In article <lauE4.42019$pA.130208@typhoon.mbnet.mb.ca>, "Steve" <reply.through.newsgroup@paranoid.com> wrote: > > Tom Burgess <tom.burgess@hia.nrc.ca> wrote in message > news:38E245D1.B020618E@hia.nrc.ca... > > Is the software usable with any real FPGAs or it is just an academic > exercise? > > Isn't this the stuff Altera is picking up? > > Steve > > Well the technology in VPR has been commercialized by Right Track CAD (see http://www.rtrack.com/ and http://www.rtrack.com/technology.html ) and incorporated in version 9.5 of MAX+PLUS II. See this press release: http://www.altera.com/html/new/pressrel/pr-mp9.5.html VPR's timing-driven packing, placement, and routing algorithms have been incorporated in MAX+PLUS II. The "academic non-commercial research" version just released also incorporates timing-driven algorithms, but they are probably more generic (i.e. not tuned to Altera's architecture). The academic VPR allows to define your own FPGA architectural parameters so you could target it to Xilinx- or Altera-like architectures, but you won't be able to generate a bitstream from it and I don't think you can even pass a placed and routed netlist to the Xilinx or Altera tools. The academic VPR is mainly a tool for research into FPGA architectures and CAD algorithms. (The founders of Right Track CAD have written a book on these topics: http://www.wkap.nl/book.htm/0-7923-8460-1 ) Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21732
AMD make a "zero power" one too, but in fact it is no more than a standard 100mA 22V10 with input transition detection, powering down the device if nothing is happening. So if you are clocking at say 1MHz all the time (as some people do :)) it draws maybe 10-20mA - far too much for me. >>I do think someone else makes a "zero power" 22V10, though. >TI makes them, however the price is out of all proportion to the amount >of logic you can get in them. Peter. -- Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 21733
For the present, you need a separate demultiplexer in front of the FPGA to bring the data rate down to something it can handle. For example, the Vitesse 8172 1-16 demux http://www.vitesse.com/pdfs/vsc8172.pdf produces 16 parallel LVDS streams at a mere 600 MHz or so, which I think? should work with Xilinx's Virtex-E series. For FPGAs, you want parts that are fast (duh), and that interface well with available demuxes, meaning lots of LVDS or PECL differential inputs and clocks, and demuxes on the inputs to bring the data rate down some more - you DON'T want to run the whole FPGA at 600 MHz. regards, tom Anoop Nannra wrote: > > Hi all, > > Anyone out there know of any references, texts or otherwise, that may give > me an idea on how to take in a 10gbit/s serial data stream into an fpga or > an array of fpga's ? Also, any ideas on what I should be looking for in and > fpga to be able to accept that kind of input ? > > TIA > AnoopArticle: 21734
In article <8btl68$kjh$1@jetsam.uits.indiana.edu>, galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > In article <8bt2io$rnp$1@nnrp1.deja.com>, rob_dickinson@my-deja.com wrote: > >Having read most of this thread I have the following global comments. > > > >1)If you just want to play then surely you can understand that company > >A or X have better things to do than to be bothered with even a few > >hundred people going "your" route. > > Total disagreement. As I've said before, most people competent in the > field learned most of what they knew going in just playing around. The > more hobbyists playing with it today the more companies buying hte things > tomorrow. I think Linux's commercial success proves that -- I don't think > managers picked it because htey liked it, I think managers picked it > because their employees said "I know and like Linux, it'll do the job and > if it doesn't we'll make it." Greg I'm about to disapoint you. FPGA's are inevitably designed by many people in such a manner that they can be maintained by other people over many years and probably ported easily to newer devices. The ability to "hack" at or near the bitstream level will not impress many people and I can assure you that decisions to invest 10,000 (say) man hours because "Greg played with bitstreams at home" will not cut it at all. If it was "Greg is bloody good at VHDL simulation using VITAL and does the job in half the time" then you probably will still not influence the decision making but you will get paid more than the next guy. Yes one guy can probably write good code for FPGA's on his own, doing it some strange weird way because X let him do it at the bitstream level, but you might go under a bus and you will almost definitely change companies during the lifetime of the #CODE#. You are therefore only usefull to a company if you are competent with the tools which the next guy can use. The more hobyists using VHDL (which is free from the right places) the better, the more people coming through degrees who still know what a counter or state machine is at the gate level, even better. A thorough knowledge of the routing architecture at any level is almost useless, Vertex will be almost completely superceeded in a frighteningly short time and no-one will give diddly squat that you know it litterally inside out. Rob Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21735
In article <01bf99ea$b3e094a0$2a3b2bd1@speedy>, "M R Wheeler" <intell-a-sys@iquest.net> wrote: > I am evaluating MaxPlus 9.5 and am finding that often the software can not > seem to locate the dongle during the build process on larger designs. The > software give me a license error message. Also, when selecting the Quartus > fitter, I am getting internal errors (contact Altera, who never has a > clue). Both problems occur on two different computers. Just wonder if > anyone else is using this version yet. > > We are compiling for 10K30 just fine but can reliably crash the Quartus fitter with certain designs. "Our" Altera FAE is fully aware that this is so. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21736
In article <8bta6v$qkc@catapult.gatech.edu>, Anshuman Sharma <gte600f@prism.gatech.edu> wrote: > I am designing a processor that runs the calculator game "worm". I have > designed it in VHDL and I am going to use a Flex10k part to synthesize > it. I want help with the VGA display. Basically if anyone can help me find > something on how I can build a VGA module that will interact with my > datapath and the game as a whole. The XSOC FPGA CPU has a VGA display. You'll find details here: www.fpgacpu.org/xsoc Leon -- Leon Heller, G1HSM Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824 Email: leon_heller@hotmail.com Web: http://www.geocities.com/SiliconValley/Code/1835 Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21737
MK Yap wrote:
>
>
[snip]
> I have been struggling with this for quite some time. Is there a good way
> for coding bidirection signals so that there is no logic contention? When to
> drive the signal & when to tristate it?
> ELSIF (MClk'event AND MClk='0') THEN
> RdDone <= '0';
> WrtHold <= '0';
> RAM_Data <= (OTHERS=>'Z'); --- (1)
You have Z-assignments inside a clocked process.
That is not good. These should be placed in an
asyncronus process.
Create a clocked process, containing the data to RAM
and one asyncronus process which will do the data output,
and handling the tristate.
Something like this....
Process(cp) -- Clocked Output to port
Begin
if rising_edge(cp) then
data_int <= data_to_RAM;
end if;
End Process;
Process(data_int, direction_to_RAM) -- Tristate control
Begin
If direction_to_RAM = '1' Then
data_iob <= data_int;
Else
data_iob <= 'Z';
End If;
End Process;
Process(data_iob) -- Read data from port
Begin
data_in <= data_iob;
End Process;
process(cp) -- return zero during write, else RAM data
begin
if rising_edge(cp) then
if direction_to_RAM='1' then
data_from_RAM<='0';
else
data_from_RAM<=data_in;
end if;
end if;
end process;
Well, I have not really checked the code but it looks OK.
Hope it helps
/Jonas
Article: 21738This is a multi-part message in MIME format. --------------E48B7AAADCC3B79468E7BEDC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, why do the FPGA tools does not recognize the array model of a ram as a memory bits and so synthesize it to memory cores when a reset operation is assumed? For example, I've two dual port memory models " That can be found on the opencores CVS" one that sets all memory bits to zero upon reset and the other does not care about memory initialization. Thanks Jamil Khatib OpenIP Organization http://www.openip.org OpenIPCore Project http://www.openip.org/oc/ OpenCores Project http:///wwwopencores.org --------------E48B7AAADCC3B79468E7BEDC Content-Type: application/x-unknown-content-type-vhd_auto_file; name="dpmem.vhd" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dpmem.vhd" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gDQotLSBDb3B5cmlnaHQgSmFtaWwgS2hh dGliIDE5OTkNCi0tIA0KLS0NCi0tIFRoaXMgVkhETCBkZXNpZ24gZmlsZSBpcyBhbiBvcGVu IGRlc2lnbjsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yDQotLSBtb2RpZnkgaXQg YW5kL29yIGltcGxlbWVudCBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIE9wZW5pcCBHZW5l cmFsIFB1YmxpYw0KLS0gTGljZW5zZSBhcyBpdCBpcyBnb2luZyB0byBiZSBwdWJsaXNoZWQg YnkgdGhlIE9wZW5JUCBPcmdhbml6YXRpb24gYW5kIGFueQ0KLS0gY29taW5nIHZlcnNpb25z IG9mIHRoaXMgbGljZW5zZS4NCi0tIFlvdSBjYW4gY2hlY2sgdGhlIGRyYWZ0IGxpY2Vuc2Ug YXQNCi0tIGh0dHA6Ly93d3cub3BlbmlwLm9yZy9vYy9saWNlbnNlLmh0bWwNCi0tDQotLQ0K LS0gQ3JlYXRvciA6IEphbWlsIEtoYXRpYg0KLS0gRGF0ZSAxNC81Lzk5DQotLQ0KLS0gdmVy c2lvbiAwLjE5OTkxMjI0DQotLQ0KLS0gVGhpcyBmaWxlIHdhcyB0ZXN0ZWQgb24gdGhlIE1v ZGVsU2ltIDUuMkVFDQotLSBUaGUgdGVzdCB2ZWNvcnMgZm9yIG1vZGVsIHNpbSBpcyBpbmNs dWRlZCBpbiB2ZWN0b3JzLmRvIGZpbGUNCi0tIFRoaXMgVkhETCBkZXNpZ24gZmlsZSBpcyBw cm92ZWQgdGhyb3VnaCBzaW11bGF0aW9uIGJ1dCBub3QgdmVyaWZpZWQgb24gU2lsaWNvbg0K LS0gDQotLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTElCUkFSWSBpZWVlOw0KVVNF IGllZWUuc3RkX2xvZ2ljXzExNjQuQUxMOw0KDQpVU0UgaWVlZS5zdGRfbG9naWNfc2lnbmVk LkFMTDsNCg0KDQoNCi0tIER1YWwgcG9ydCBNZW1vcnkgY29yZQ0KDQoNCg0KRU5USVRZIGRw bWVtIElTDQpnZW5lcmljICggQUREX1dJRFRIOiBpbnRlZ2VyIDo9IDggOw0KCQkgV0lEVEgg OiBpbnRlZ2VyIDo9IDgpOw0KICBQT1JUICgNCiAgICBjbGsgICAgICA6IElOICBzdGRfbG9n aWM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSB3cml0ZSBjbG9jaw0KICAg IHJlc2V0ICAgIDogSU4gIHN0ZF9sb2dpYzsgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIFN5c3RlbSBSZXNldA0KICAgIFdfYWRkICAgIDogSU4gIHN0ZF9sb2dpY192ZWN0 b3IoYWRkX3dpZHRoIC0xIGRvd250byAwKTsgIC0tIFdyaXRlIEFkZHJlc3MNCiAgICBSX2Fk ZCAgICA6IElOICBzdGRfbG9naWNfdmVjdG9yKGFkZF93aWR0aCAtMSBkb3dudG8gMCk7ICAt LSBSZWFkIEFkZHJlc3MNCiAgICBEYXRhX0luICA6IElOICBzdGRfbG9naWNfdmVjdG9yKFdJ RFRIIC0gMSAgRE9XTlRPIDApOyAgICAtLSBpbnB1dCBkYXRhDQogICAgRGF0YV9PdXQgOiBP VVQgc3RkX2xvZ2ljX3ZlY3RvcihXSURUSCAtMSAgIERPV05UTyAwKTsgICAgLS0gb3V0cHV0 IERhdGENCiAgICBXUiAgICAgICA6IElOICBzdGRfbG9naWM7ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBXcml0ZSBFbmFibGUNCiAgICBSRSAgICAgICA6IElOICBzdGRf bG9naWMpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBSZWFkIEVuYWJsZQ0K RU5EIGRwbWVtOw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQVJDSElURUNU VVJFIGRwbWVtX3YxIE9GIGRwbWVtIElTDQoNCg0KDQogIFRZUEUgZGF0YV9hcnJheSBJUyBB UlJBWSAoaW50ZWdlciByYW5nZSA8PikgT0Ygc3RkX2xvZ2ljX3ZlY3RvcihXSURUSCAtMSAg RE9XTlRPIDApOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1lbW9yeSBUeXBlDQogIFNJR05BTCBkYXRhIDogZGF0YV9hcnJheSgwIHRvICgyKiogYWRk X3dpZHRoKSApOyAgLS0gTG9jYWwgZGF0YQ0KDQoNCg0KICBwcm9jZWR1cmUgaW5pdF9tZW0o c2lnbmFsIG1lbW9yeV9jZWxsIDogaW5vdXQgZGF0YV9hcnJheSApIGlzDQogIGJlZ2luDQoN CiAgICBmb3IgaSBpbiAwIHRvICgyKiogYWRkX3dpZHRoKSBsb29wDQogICAgICBtZW1vcnlf Y2VsbChpKSA8PSAob3RoZXJzID0+ICcwJyk7DQogICAgZW5kIGxvb3A7DQoNCiAgZW5kIGlu aXRfbWVtOw0KDQoNCkJFR0lOICAtLSBkcG1lbV92MQ0KDQogIFBST0NFU1MgKGNsaywgcmVz ZXQpDQoNCiAgQkVHSU4gIC0tIFBST0NFU1MNCg0KDQogICAgLS0gYWN0aXZpdGllcyB0cmln Z2VyZWQgYnkgYXN5bmNocm9ub3VzIHJlc2V0IChhY3RpdmUgbG93KQ0KICAgIElGIHJlc2V0 ID0gJzAnIFRIRU4NCiAgICAgIGRhdGFfb3V0IDw9IChPVEhFUlMgPT4gJ1onKTsNCiAgICAg IGluaXRfbWVtICggZGF0YSk7DQoNCiAgICAgIC0tIGFjdGl2aXRpZXMgdHJpZ2dlcmVkIGJ5 IHJpc2luZyBlZGdlIG9mIGNsb2NrDQogICAgRUxTSUYgY2xrJ2V2ZW50IEFORCBjbGsgPSAn MScgVEhFTg0KICAgICAgSUYgUkUgPSAnMScgVEhFTg0KICAgICAgICBkYXRhX291dCA8PSBk YXRhKGNvbnZfaW50ZWdlcihSX2FkZCkpOw0KICAgICAgZWxzZQ0KICAgICAgICBkYXRhX291 dCA8PSAoT1RIRVJTID0+ICdaJyk7ICAgIC0tIERlZnVhbHQgdmFsdWUNCiAgICAgIEVORCBJ RjsNCg0KICAgICAgSUYgV1IgPSAnMScgVEhFTg0KICAgICAgICBkYXRhKGNvbnZfaW50ZWdl UihXX2FkZCkpIDw9IERhdGFfSW47DQogICAgICBFTkQgSUY7DQogICAgRU5EIElGOw0KDQoN Cg0KICBFTkQgUFJPQ0VTUzsNCg0KDQpFTkQgZHBtZW1fdjE7DQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCi0tIFRoaXMgQXJjaGl0ZWN0dXJlIHdhcyB0ZXN0ZWQgb24g dGhlIE1vZGVsU2ltIDUuMkVFDQotLSBUaGUgdGVzdCB2ZWN0b3JzIGZvciBtb2RlbCBzaW0g aXMgaW5jbHVkZWQgaW4gdmVjdG9ycy5kbyBmaWxlDQotLSBJdCBpcyBTeW50aGVzaXplZCB1 c2luZyBYaWxpbnggV2ViZml0dGVyDQotLQ0KLS0gDQotLSBUaGUgdmFyaWFibGUgcmVzdWx0 X2RhdGEgaXMgdXNlZCBhcyBhbiBpbnRlcm1lZGlhdGUgdmFyaWFibGUgaW4gdGhlIHByb2Nl c3MNCi0tIA0KDQpBUkNISVRFQ1RVUkUgZHBtZW1fdjIgT0YgZHBtZW0gSVMNCg0KDQoNCiAg VFlQRSBkYXRhX2FycmF5IElTIEFSUkFZIChpbnRlZ2VyIHJhbmdlIDw+KSBPRiBzdGRfbG9n aWNfdmVjdG9yKFdJRFRIIC0xIERPV05UTyAwKTsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNZW1vcnkgVHlwZQ0KICBTSUdOQUwgZGF0YSA6IGRhdGFf YXJyYXkoMCB0byAoMioqIGFkZF93aWR0aCkgKTsgIC0tIExvY2FsIGRhdGENCg0KDQotLSBJ bml0aWFsaXplIHRoZSBtZW1vcnkgdG8gemVyb3MgDQogIHByb2NlZHVyZSBpbml0X21lbShz aWduYWwgbWVtb3J5X2NlbGwgOiBpbm91dCBkYXRhX2FycmF5ICkgaXMNCiAgYmVnaW4NCg0K ICAgIGZvciBpIGluIDAgdG8gKDIqKiBhZGRfd2lkdGgpIGxvb3ANCiAgICAgIG1lbW9yeV9j ZWxsKGkpIDw9IChvdGhlcnMgPT4gJzAnKTsNCiAgICBlbmQgbG9vcDsNCg0KICBlbmQgaW5p dF9tZW07DQoNCiANCkJFR0lOICAtLSBkcG1lbV92Mg0KDQogIFBST0NFU1MgKGNsaywgcmVz ZXQpDQoNCiAgICB2YXJpYWJsZSByZXN1bHRfZGF0YSA6IHN0ZF9sb2dpY192ZWN0b3IoV0lE VEggLTEgIGRvd250byAwKTsNCg0KICBCRUdJTiAgLS0gUFJPQ0VTUw0KDQotLSBpbml0IGRh dGFfb3V0DQoNCg0KICAgIC0tIGFjdGl2aXRpZXMgdHJpZ2dlcmVkIGJ5IGFzeW5jaHJvbm91 cyByZXNldCAoYWN0aXZlIGxvdykNCiAgICBJRiByZXNldCA9ICcwJyBUSEVODQogICAgICBy ZXN1bHRfZGF0YSA6PSAoT1RIRVJTID0+ICdaJyk7DQogICAgICBpbml0X21lbSAoIGRhdGEp Ow0KDQogICAgICAtLSBhY3Rpdml0aWVzIHRyaWdnZXJlZCBieSByaXNpbmcgZWRnZSBvZiBj bG9jaw0KICAgIEVMU0lGIGNsaydldmVudCBBTkQgY2xrID0gJzEnIFRIRU4NCiAgICAgIElG IFJFID0gJzEnIFRIRU4NCiAgICAgICAgcmVzdWx0X2RhdGEgOj0gZGF0YShjb252X2ludGVn ZXIoUl9hZGQpKTsNCiAgICAgIGVsc2UNCiAgICAgICAgcmVzdWx0X2RhdGEgOj0gKE9USEVS UyA9PiAnWicpOyAgICAtLSBEZWZ1YWx0IHZhbHVlDQogICAgICBFTkQgSUY7DQoNCiAgICAg IElGIFdSID0gJzEnIFRIRU4NCiAgICAgICAgZGF0YShjb252X2ludGVnZVIoV19hZGQpKSA8 PSBEYXRhX0luOw0KICAgICAgRU5EIElGOw0KICAgIEVORCBJRjsNCg0KZGF0YV9vdXQgPD0g cmVzdWx0X2RhdGE7DQoNCg0KRU5EIFBST0NFU1M7DQoNCg0KRU5EIGRwbWVtX3YyOw0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gVGhpcyBBcmNoaXRlY3R1cmUgd2Fz IHRlc3RlZCBvbiB0aGUgTW9kZWxTaW0gNS4yRUUNCi0tIFRoZSB0ZXN0IHZlY3RvcnMgZm9y IG1vZGVsIHNpbSBpcyBpbmNsdWRlZCBpbiB2ZWN0b3JzLmRvIGZpbGUNCi0tIEl0IGlzIFN5 bnRoZXNpemVkIHVzaW5nIFhpbGlueCBXZWJwYWNrDQotLQ0KLS0gVGhpcyBpcyB0aGUgc2Ft ZSBhcyBkcG1lbV92MSBidXQgd2l0aG91dCB0aGUgWiBzdGF0ZQ0KLS0gaW5zdGVhZCB0aGUg b3V0cHV0IGdvZXMgdG8gYWxsIDEncyBkdXJpbmcgcmVzZXQgYW5kIA0KLS0gd2hlbiBSRSA9 IDANCg0KQVJDSElURUNUVVJFIGRwbWVtX3YzIE9GIGRwbWVtIElTDQoNCg0KDQogIFRZUEUg ZGF0YV9hcnJheSBJUyBBUlJBWSAoaW50ZWdlciByYW5nZSA8PikgT0Ygc3RkX2xvZ2ljX3Zl Y3RvcihXSURUSCAtMSBET1dOVE8gMCk7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWVtb3J5IFR5cGUNCiAgU0lHTkFMIGRhdGEgOiBkYXRhX2FycmF5 KDAgdG8gKDIqKiBhZGRfd2lkdGgpICk7ICAtLSBMb2NhbCBkYXRhDQoNCg0KDQogIHByb2Nl ZHVyZSBpbml0X21lbShzaWduYWwgbWVtb3J5X2NlbGwgOiBpbm91dCBkYXRhX2FycmF5ICkg aXMNCiAgYmVnaW4NCg0KICAgIGZvciBpIGluIDAgdG8gKDIqKiBhZGRfd2lkdGgpIGxvb3AN CiAgICAgIG1lbW9yeV9jZWxsKGkpIDw9IChvdGhlcnMgPT4gJzAnKTsNCiAgICBlbmQgbG9v cDsNCg0KICBlbmQgaW5pdF9tZW07DQoNCg0KQkVHSU4gIC0tIGRwbWVtX3YzDQoNCiAgUFJP Q0VTUyAoY2xrLCByZXNldCkNCg0KICBCRUdJTiAgLS0gUFJPQ0VTUw0KDQoNCiAgICAtLSBh Y3Rpdml0aWVzIHRyaWdnZXJlZCBieSBhc3luY2hyb25vdXMgcmVzZXQgKGFjdGl2ZSBsb3cp DQogICAgSUYgcmVzZXQgPSAnMCcgVEhFTg0KICAgICAgZGF0YV9vdXQgPD0gKE9USEVSUyA9 PiAnMScpOw0KICAgICAgaW5pdF9tZW0gKCBkYXRhKTsNCg0KICAgICAgLS0gYWN0aXZpdGll cyB0cmlnZ2VyZWQgYnkgcmlzaW5nIGVkZ2Ugb2YgY2xvY2sNCiAgICBFTFNJRiBjbGsnZXZl bnQgQU5EIGNsayA9ICcxJyBUSEVODQogICAgICBJRiBSRSA9ICcxJyBUSEVODQogICAgICAg IGRhdGFfb3V0IDw9IGRhdGEoY29udl9pbnRlZ2VyKFJfYWRkKSk7DQogICAgICBlbHNlDQog ICAgICAgIGRhdGFfb3V0IDw9IChPVEhFUlMgPT4gJzEnKTsgICAgLS0gRGVmdWFsdCB2YWx1 ZQ0KICAgICAgRU5EIElGOw0KDQogICAgICBJRiBXUiA9ICcxJyBUSEVODQogICAgICAgIGRh dGEoY29udl9pbnRlZ2VSKFdfYWRkKSkgPD0gRGF0YV9JbjsNCiAgICAgIEVORCBJRjsNCiAg ICBFTkQgSUY7DQoNCg0KDQogIEVORCBQUk9DRVNTOw0KDQoNCkVORCBkcG1lbV92MzsNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --------------E48B7AAADCC3B79468E7BEDC Content-Type: application/x-unknown-content-type-vhd_auto_file; name="dpmem2clk.vhd" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dpmem2clk.vhd" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotLSBUaXRsZSAgICAgIDogR2VuZXJlaWMgc3lu Y2hyb25vdXMgRHVhbCBwb3J0IG1lbW9yeQotLSBQcm9qZWN0ICAgIDogTWVtb3J5IENvcmVz Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLS0gRmlsZSAgICAgICAgOiBEUE1FTTJDTEsu VkhECi0tIEF1dGhvciAgICAgIDogSmFtaWwgS2hhdGliICA8a2hhdGliQGllZWUub3JnPgot LSBPcmdhbml6YXRpb246IE9wZW5JUENvcmUgUHJvamVjdAotLSBDcmVhdGVkICAgICA6IDIw MDAvMDMvMjkKLS0gTGFzdCB1cGRhdGUgOiAyMDAwLzAzLzI5Ci0tIFBsYXRmb3JtICAgIDog DQotLSBTaW11bGF0b3JzICA6IE1vZGVsc2ltIDUuMkVFIC8gV2luZG93czk4ICYgWGlsaW54 IG1vZGVsc2ltIDUuM2EgWEUNCi0tIFN5bnRoZXNpemVyczogTGVvbmFyZG8gLyBXaW5kb3dz TlQgJiBYaWxpbnggd2ViZml0dGVyDQotLSBUYXJnZXQgICAgICA6IEZsZXgxMEtFDQotLSBE ZXBlbmRlbmN5ICA6IAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0tIERlc2NyaXB0aW9u OiBHZW5lcmVpYyBzeW5jaHJvbm91cyBEdWFsIHBvcnQgbWVtb3J5DQotLSAgICAgICAgICAg ICAgICAgICAgICAgIDogU2VwZXJhdGUgcmVhZCBhbmQgd3JpdGUgY2xvY2tzCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KLS0gQ29weXJpZ2h0IChjKSAyMDAwIEphbWlsIEtoYXRpYgot LSANCi0tIFRoaXMgVkhETCBkZXNpZ24gZmlsZSBpcyBhbiBvcGVuIGRlc2lnbjsgeW91IGNh biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yDQotLSBtb2RpZnkgaXQgYW5kL29yIGltcGxlbWVu dCBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIE9wZW5pcCBHZW5lcmFsIFB1YmxpYw0KLS0g TGljZW5zZSBhcyBpdCBpcyBnb2luZyB0byBiZSBwdWJsaXNoZWQgYnkgdGhlIE9wZW5JUENv cmUgT3JnYW5pemF0aW9uIGFuZA0KLS0gYW55IGNvbWluZyB2ZXJzaW9ucyBvZiB0aGlzIGxp Y2Vuc2UuDQotLSBZb3UgY2FuIGNoZWNrIHRoZSBkcmFmdCBsaWNlbnNlIGF0DQotLSBodHRw Oi8vd3d3Lm9wZW5pcC5vcmcvb2MvbGljZW5zZS5odG1sDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KLS0gUmV2aXNpb25zICA6Ci0tIFJldmlzaW9uIE51bWJlciA6IDENCi0tIFZl cnNpb24gICAgICAgICAgICAgIDogICAxLjANCi0tIERhdGUgICAgICAgICAgICAgOiAgIDI5 dGggTWFyIDIwMDANCi0tIE1vZGlmaWVyICAgICA6ICAgSmFtaWwgS2hhdGliIChraGF0aWJA aWVlZS5vcmcpDQotLSBEZXNjY3JpcHRpb24gOiAgICAgICBDcmVhdGVkDQotLQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCmxpYnJhcnkgaWVlZTsgDQp1c2UgaWVlZS5zdGRf bG9naWNfMTE2NC5hbGw7IA0KdXNlIGllZWUuc3RkX2xvZ2ljX3Vuc2lnbmVkLmFsbDsgDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tIFN5bmNocm9ub3VzIER1YWwgUG9ydCBN ZW1vcnkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmVudGl0eSBEcG1lbTJjbGsgaXMN CiAgDQogIGdlbmVyaWMgKA0KICAgIEFERF9XSURUSCAgICAgICAgIDogICAgIGludGVnZXIg ICA6PSA0OyAgLS0gQWRkcmVzcyB3aWR0aA0KICAgIFdJRFRIICAgICAgICAgICAgIDogICAg IGludGVnZXIgICA6PSA4OyAgLS0gV29yZCBXaWR0aA0KICAgIGNvcmV0eXBlICAgICAgICAg IDogICAgIGludGVnZXIgICA6PSAwKTsgIC0tIG1lbW9yeSBidWxkaW5nIGJsb2NrIHR5cGUN CiAgDQogIHBvcnQgKA0KICAgIFdjbGsgICAgICAgICAgICAgIDogaW4gIHN0ZF9sb2dpYzsg IC0tIHdyaXRlIGNsb2NrDQogICAgV2VuICAgICAgICAgICAgICAgOiBpbiAgc3RkX2xvZ2lj OyAgLS0gV3JpdGUgRW5hYmxlDQogICAgV2FkZCAgICAgICAgICAgICAgOiBpbiAgc3RkX2xv Z2ljX3ZlY3RvcihBRERfV0lEVEggLTEgZG93bnRvIDApOyAgLS0gV3JpdGUgQWRkcmVzcw0K ICAgIERhdGFpbiAgICAgICAgICAgIDogaW4gIHN0ZF9sb2dpY192ZWN0b3IoV0lEVEggLTEg ZG93bnRvIDApOyAgLS0gSW5wdXQgRGF0YQ0KICAgIFJjbGsgICAgICAgICAgICAgIDogaW4g IHN0ZF9sb2dpYzsgIC0tIFJlYWQgY2xvY2sNCiAgICBSZW4gICAgICAgICAgICAgICA6IGlu ICBzdGRfbG9naWM7ICAtLSBSZWFkIEVuYWJsZQ0KICAgIFJhZGQgICAgICAgICAgICAgIDog aW4gIHN0ZF9sb2dpY192ZWN0b3IoQUREX1dJRFRIIC0xIGRvd250byAwKTsgIC0tIFJlYWQg QWRkcmVzcw0KICAgIERhdGFvdXQgICAgICAgICAgIDogb3V0IHN0ZF9sb2dpY192ZWN0b3Io V0lEVEggLTEgZG93bnRvIDApKTsgIC0tIE91dHB1dCBkYXRhDQogIA0KZW5kIERwbWVtMmNs azsgDQoNCmFyY2hpdGVjdHVyZSBkcG1lbV9hcmNoIG9mIERwbWVtMmNsayBpcw0KICANCiAg dHlwZSBEQVRBX0FSUkFZIGlzIGFycmF5IChpbnRlZ2VyIHJhbmdlIDw+KSBvZiBzdGRfbG9n aWNfdmVjdG9yKFdJRFRIIC0xIGRvd250byAwKTsgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWVtb3J5IFR5cGUNCiAgc2lnbmFsICAgZGF0YSAgICAg ICA6ICAgICBEQVRBX0FSUkFZKDAgdG8gKDIqKkFERF9XSURUSCkgLTEpOyAgLS0gTG9jYWwg ZGF0YQ0KICBjb25zdGFudCBJREVMT1VUUFVUIDogICAgIHN0ZF9sb2dpYyA6PSAnWic7ICAt LSBJREVMIHN0YXRlIG91dHB1dA0KICANCmJlZ2luICAtLSBkcG1lbV9hcmNoDQogIA0KICAt LSBwdXJwb3NlOiBSZWFkIHByb2Nlc3MNCiAgLS0gdHlwZSAgIDogc2VxdWVudGlhbA0KICAt LSBpbnB1dHMgOiBSY2xrDQogIC0tIG91dHB1dHM6IA0KICBSZVByb2MgICAgICAgICAgICAg IDogICAgIHByb2Nlc3MgKFJjbGspDQogIGJlZ2luICAtLSBwcm9jZXNzIFJlUHJvYw0KICAg IA0KICAgIGlmIFJjbGsnZXZlbnQgYW5kIFJjbGsgPSAnMScgdGhlbiAgIC0tIHJpc2luZyBj bG9jayBlZGdlDQogICAgICBpZiBSZW4gPSAnMScgdGhlbg0KICAgICAgICBEYXRhb3V0ICAg ICAgICAgICAgICAgICAgICAgICA8PSBkYXRhKGNvbnZfaW50ZWdlcihSYWRkKSk7IA0KICAg ICAgZWxzZQ0KICAgICAgICBEYXRhb3V0ICAgICAgICAgICAgICAgICAgICAgICA8PSAob3Ro ZXJzID0+IElERUxPVVRQVVQpOyANCiAgICAgIGVuZCBpZjsgDQogICAgICANCiAgICBlbmQg aWY7IA0KICBlbmQgcHJvY2VzcyBSZVByb2M7IA0KICANCiAgLS0gcHVycG9zZTogV3JpdGUg cHJvY2Vzcw0KICAtLSB0eXBlICAgOiBzZXF1ZW50aWFsDQogIC0tIGlucHV0cyA6IFdjbGsN CiAgLS0gb3V0cHV0czogDQogIFdyUHJvYyAgICAgICAgICAgICAgOiAgICAgcHJvY2VzcyAo V2NsaykNCiAgYmVnaW4gIC0tIHByb2Nlc3MgV3JQcm9jDQogICAgDQogICAgaWYgV2Nsaydl dmVudCBhbmQgV2NsayA9ICcxJyB0aGVuICAgLS0gcmlzaW5nIGNsb2NrIGVkZ2UNCiAgICAg IGlmIFdlbiA9ICcxJyB0aGVuDQogICAgICAgIA0KICAgICAgICBkYXRhKGNvbnZfaW50ZWdl cihXYWRkKSkgICAgICA8PSBEYXRhaW47IA0KICAgICAgZW5kIGlmOyANCiAgICAgIA0KICAg IGVuZCBpZjsgDQogIGVuZCBwcm9jZXNzIFdyUHJvYzsgDQogIA0KZW5kIGRwbWVtX2FyY2g7 IA0KDQoNCgoKCgoK --------------E48B7AAADCC3B79468E7BEDC--Article: 21739
This is a multi-part message in MIME format. --------------9D26ACEF6E5B27AA3E63F9C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the responses. We are using Virtex in this case. So, we will not get a DRC error in the backend flow, but our RESET signal is not really using a global net. Our timing did get alot better, but I guess it was because of other changes we made. Thanks for clearing this up. Regards, Tom Peter Alfke wrote: > It depends on the Xilinx family: > > In XC4000 and all its derivatives ( incl. Spartan and SpartanXL) you can > use the global nets for anything you might want. > > In Virtex and its derivatives ( incl. Spartan-II) you can use the global > clock nets *ONLY* as clocks. > If you were to use them for other purposes, the routing would actually use > the normal routing channels. So this would be self-defeating. > > Peter Alfke, Xilinx Applications > ========================================= > Tom McLaughlin wrote: > > > All, > > If I interpret the datasheet, it says that the 4 global clock nets in a > > Xilinx Virtex device can only be used for clocks. Before we read this, > > we implemented a reset signal using one of the global clock buffers and > > global clock nets. We did not get any errors in synthesis or place and > > route. We have done gate level simulations on the netlist and it > > simulates fine. However, the Xilinx doc clearly states that, "Four > > global buffers drive the four primary global nets that in turn drive any > > clock pin." > > > > So, the question remains: > > > > Can we use the global nets for global signals other than clocks??? > > > > Tom --------------9D26ACEF6E5B27AA3E63F9C4 Content-Type: text/x-vcard; charset=us-ascii; name="tomm.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom McLaughlin Content-Disposition: attachment; filename="tomm.vcf" begin:vcard n:McLaughlin;Tom tel;fax:314-935-7302 tel;work:314-935-7198 x-mozilla-html:FALSE url:http://www.arl.wustl.edu/~tomm org:Washington University;Applied Research Lab version:2.1 email;internet:tomm@arl.wustl.edu title:Research Associate adr;quoted-printable:;;One Brookings Drive=0D=0ACampus Box 1045-ARL;St. Louis;MO;63130;USA x-mozilla-cpt:;0 fn:Tom McLaughlin end:vcard --------------9D26ACEF6E5B27AA3E63F9C4--Article: 21740
Hi everyone. I have a very simple question regarding the ALTERA LPMs. I am currently using the ALTERA FLEX10K100 series for a project at work and I would like to use some of ALTERA's LPMs in pipelined form in order to speed up my design. My question: Assuming I want only one PIPELINE stage, where is it introduced in the macro? At the output stage, so that the macro is composed of a combinational circuit followed by a register? Is this general for all of ALTERA's macros? Your help is greatly appreciated. Thanks in advance. Nestor Caouras Tel.: (514) 356-0634 Fax.: (514) 356-0165 email: nestor@stansync.comArticle: 21741
Jamil Khatib wrote: > Hi, > why do the FPGA tools does not recognize the array model of a ram as a > memory bits and so synthesize it to memory cores when a reset operation > is assumed? I am not aware of any FPGA memory resources (block, distributed) that include reset capability. To implement this, the synthesis tool is forced to use discreet Flip Flops. Try removing the reset function... Regards Eric FriedrichsArticle: 21742
Allan Herriman <allan.herriman.hates.spam@fujitsu.com.au> wrote: : And don't worry, due to the secret nature of the Xilinx bitstreams, I : have no practical way of working out what your design does. Uploading it to a Virtex chip - and then treating its pins as the outputs from a black box - could give you a practical method of determining the function ;-) -- __________ |im |yler The Mandala Centre http://mandala.co.uk/ tt@cryogen.com When I gave her the ring, she gave me the finger.Article: 21743
Jamil Khatib wrote: > why do the FPGA tools does not recognize the array model of a ram as a > memory bits and so synthesize it to memory cores when a reset operation > is assumed? Ummm... If I understand your question correctly, there are two issues here: 1. Why do FPGA tools not correctly synthesize the array model of RAM? 2. Why can I not initialize the contents of RAM using a global reset signal. To answer #1: Basically, synthesis tools are still not mature enough to "transparently" take advantage of special FPGA/ASIC features like RAM (but also DLL/PLL's, CAM, etc.). There are several synthesis tools that will accept an array and synthesize it into RAM (Synplify comes to mind), but many more do not (Quartus, FPGA Express, etc.). Further, the tools that do synthesize an array have limitations when it comes to actual use. These limitations come mostly from the different RAM architectures found in many FPGA's (and sometimes in the same FPGA, a.la. Virtex & Spartan 2). While they still synthesize an array into RAM, it isn't always as transparent as we would like. Take a look at the Free-RAM core at The Free-IP Project (http://www.free-ip.com). This is basically a dual port ram core that is portable across FPGA Express (Xilinx), Quartus (Altera), and Model SIM. To do this, the Free-RAM core takes the lowest common denominator of features across all architectures and puts them under a single VHDL entity (actually, a series of them that are interchangeable). This sounds like a relatively easy thing to do, but as you can see from the VHDL code, it's not as trivial as one would think! To answer #2: You cannot initialize the contents of RAM using a reset signal because they just aren't wired that way. Neither Xilinx or Altera have a mechanism to reset the contents of RAM (any type of RAM) using any reset signal (global reset or otherwise). This is just like using a standard off the shelf RAM chip-- there isn't a reset signal for those either. What Altera and Xilinx have done, however, is provide a way to initialize the contents of RAM to any arbitrary value during the normal FPGA programming process. In other words, the initial contents of all RAM is included in the programming bitstream. This allows the RAM to be initialized to a specific value and used as a ROM (or something else). Unfortunately, I have no experience initializing RAM like that-- other than I know that it can be done and have seen it done. I'll have to learn how to soon, however, since it's recently come up on a new core design... Hope that helps! David Kessner davidk@free-ip.com http://www.free-ip.com/Article: 21744
As I recall the sequence was XC2000 - (I have forgotten) XC3000 - only drive clocks XC4000 - drive anything Virtex - only drive clocks Is there a paper on the research behind this? > Peter Alfke wrote: > > > It depends on the Xilinx family: > > > > In XC4000 and all its derivatives ( incl. Spartan and SpartanXL) you can > > use the global nets for anything you might want. > > > > In Virtex and its derivatives ( incl. Spartan-II) you can use the global > > clock nets *ONLY* as clocks.Article: 21745
In article <8bv4us$7st$1@nnrp1.deja.com>, rob_dickinson@my-deja.com wrote: >In article <8btl68$kjh$1@jetsam.uits.indiana.edu>, >galexand@sietch.bloomington.in.us (Greg Alexander) wrote: >> In article <8bt2io$rnp$1@nnrp1.deja.com>, rob_dickinson@my-deja.com >wrote: >> >Having read most of this thread I have the following global comments. >> > >> >1)If you just want to play then surely you can understand that >company >> >A or X have better things to do than to be bothered with even a few >> >hundred people going "your" route. >> >> Total disagreement. As I've said before, most people competent in the >> field learned most of what they knew going in just playing around. The >> more hobbyists playing with it today the more companies buying hte >things >> tomorrow. I think Linux's commercial success proves that -- I don't >think >> managers picked it because htey liked it, I think managers picked it >> because their employees said "I know and like Linux, it'll do the job >and >> if it doesn't we'll make it." > > >Greg >I'm about to disapoint you. >FPGA's are inevitably designed by many people in such a manner that >they can be maintained by other people over many years and probably >ported easily to newer devices. The ability to "hack" at or near the >bitstream level will not impress many people and I can assure you that >decisions to invest 10,000 (say) man hours because "Greg played with >bitstreams at home" will not cut it at all. If it was "Greg is bloody >good at VHDL simulation using VITAL and does the job in half the time" >then you probably will still not influence the decision making but you >will get paid more than the next guy. >Yes one guy can probably write good code for FPGA's on his own, doing >it some strange weird way because X let him do it at the bitstream >level, but you might go under a bus and you will almost definitely >change companies during the lifetime of the #CODE#. You are therefore >only usefull to a company if you are competent with the tools which the >next guy can use. >The more hobyists using VHDL (which is free from the right places) the >better, the more people coming through degrees who still know what a >counter or state machine is at the gate level, even better. A thorough >knowledge of the routing architecture at any level is almost useless, >Vertex will be almost completely superceeded in a frighteningly short >time and no-one will give diddly squat that you know it litterally >inside out. As easily as you dismiss my approach to learning, people who have been through my approach to learning completely dismiss anything learned your way as being inadequate and cloudy. *shrug* Bias can go both ways and it doesn't make either side right -- but if there are two sides you shouldn't be so sure yours is the only way. I maintain that you don't know anything if you don't know how it works -- you can't learn how FPGAs in general work if you don't look in depth at at least one example and looking in edpth at the Vertex chip won't make you any stupider when you see the foobar chip -- if anything, it'll make you smarter because you'll see the historical basis for decisions and you'll see neat innovations rather than just an entirely new system. If you'll never learn ANY of the chips then I continue to maintain that you know plenty to get most jobs done, but not enough for extreme excellence, which is sometimes demanded.Article: 21746
I'm trying to understand the difference between antifuse, SRAM and flash based FPGAs. I have 3 questions and any comments on any of these would be much appreciated. 1) Antifuse is purportedly cheaper, lower power, higher performance. Why is this? If this is true - how much cheaper, lower power etc? 2) Other than military/aerospace, what applications are antifuse FPGAs used for? Aren't SRAM FPGAs much better because they're many times reprogrammable? 3) Who is the best antifuse vendor? Thanks in advance for your help. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21747
Hi, I recommend you to visit http://www.optimagic.com/ . It has a lot of device-independent information... I'm not an expert, but I'll try to answer you... > 1) Antifuse is purportedly cheaper, lower power, > higher performance. Why is this? If this is true > - how much cheaper, lower power etc? The resistance of a "shorted" gate is much lower that when a S-RAM cell is used, thus less power. Also the you use less die area for an anti-fuse that for a SRAM control cell. > 2) Other than military/aerospace, what > applications are antifuse FPGAs used for? Aren't > SRAM FPGAs much better because they're many times > reprogrammable? SRAM needs to be "booted". In some applications it is a big disadvantage. > 3) Who is the best antifuse vendor? I only know Actel (... but that does not make it the best ;-) > Thanks in advance for your help. > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 21748
No, there is no published research paper. The decisions depend on the priorities seen at the time of family inception: Generality is obviously nice, but burdens the clock tree with a lot of extra capacitance, whether the destinations are activated or not. Single-mindedness reduces capacitive loading, and thus clock delay and clock skew, which are important parameters at clock rates > 200 MHz. Also, the improved quality of the additional interconnect allows us to restrict the global clock lines to their original purpose. Clock distribution quality has a higher importance today than it had years ago, especially since the DLL can effectively eliminate the clock delay. Clock skew thus takes on a new significance, and clock skew is drastically improved by using the global nets as clocks only. Hope this is convincing. Peter Alfke, Xilinx Applications Tim wrote: > As I recall the sequence was > > XC2000 - (I have forgotten) > XC3000 - only drive clocks > XC4000 - drive anything > Virtex - only drive clocks > > Is there a paper on the research behind this? > > > Peter Alfke wrote: > > > > > It depends on the Xilinx family: > > > > > > In XC4000 and all its derivatives ( incl. Spartan and SpartanXL) you > can > > > use the global nets for anything you might want. > > > > > > In Virtex and its derivatives ( incl. Spartan-II) you can use the > global > > > clock nets *ONLY* as clocks.Article: 21749
Noticed new Xilinx app note on "SEU mitigation design techniques for XQR4000XL" which might be of interest: http://www.xilinx.com/xapp/xapp181.pdf -- Tom Burgess Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.ca
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