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
"Keith R. Williams" wrote: > Fuses? The problem then moves to test, but it's been done. Fuses are ugly: 1. take lots of current to blow (big drivers) 2. are not good for keeping a secret ( easily detected ) 3. are inherently one-time-programmable, which does not sit well with the basic concept of our FPGAs Peter AlfkeArticle: 43126
If you use the DLL or DCM to eliminate the clock delay inside the FPGA, and you register the data in the IOB, and you have a reasonable pc-board, you will have no problem. You might use clock forwarding (source-synchronous clocking), i.e. send the clock with the data, but this is not necessary at your "low" speed. Peter Alfke, Xilinx Applications ================================ Bert Wibble wrote: > Hello all, > > Does anyone have any experience in driving external high speed devices > from an > FPGA, in particular a DAC ? > To put some flesh around this, I am attempting to drive a 10bit DAC > from an > FPGA at 160MHz. The DAC and the FPGA share a common clock - but at > this speed > their exact phase allignment is not known. > Internal to the FPGA (Xilinx), I am using a DLL/clock net to lock the > internal > clock to the external one. > I am also happy with the idea that there will be a delay spread of the > data through the FPGA IOB/pad combo. > > My question is - does anyone have any useful ideas on how I can > guarantee to > meet the setup and hold times of my DAC given the uncertainties of the > clock > delays ? > There seems to be very little information around on this topic - is > this > another "black art" area ? > > Thanks in advance, > BertArticle: 43127
I'll post a summary if anybody is interested. Occasionally, I try to point out to marketing people that they are damaging their reputation by spamming. Occasionally it works. Often they "just don't get it". They seem to be able to rationalize that their stuff isn't spam. I assume they think it has to be porn or swindle to count as spam. That's the sort of response I got when I asked them where they got my email address. (I'm pretty sure they harvested it from here.) Anybody read/view the video? What company are they pushing? Anybody got any contacts in their marketing dept? ... -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 43128
In article <3CE13DB0.F6A37653@xilinx.com>, Peter.Alfke@xilinx.com says... > > > "Keith R. Williams" wrote: > > > Fuses? The problem then moves to test, but it's been done. > > Fuses are ugly: Crypto stuff tends to be ugly. Batteries have their ugly side too (flammability, waste hazard, PO'd customers...). > 1. take lots of current to blow (big drivers) True, though it is possible. > 2. are not good for keeping a secret ( easily detected ) It's done for cryptographically strong data (e.g. private keys) in FIPS 140-1 level-4 crypto equipment. Secrets are a pretty big deal in this application. > 3. are inherently one-time-programmable, which does not sit well with the basic > concept of our FPGAs A OTP key doesn't preclude a modified bitstream. The bitstream generator must know about it, of course. The key could even be blown at module test before shipment to company X under contract Y. Ugly, to be sure, but possible. The only issue I see here is whether or not customers are willing to pay for security. Of course, the question becomes, how much security at what cost? Xilinx has made a stab at it. ...been on all sides of this one. ---- Keith (not speaking for IBM)Article: 43129
Sean wrote: > I'm convinced there is an anti-electical engineering field that passes > through the lab at regular intervals :) > <snip> Have you tried the idea of: o Defining the outputs to be open-drain assign od_out = od ? 1'bz : 1'b0; o Setting them to LVTTL-16ma o Using strong-ish pullups at about 330-470R. The actual value depends on the capacitive loading of the ISA data bus. 470R & 50pF would give ~25nsec to 3.5V. o Then maybe the Peter A. accelerated o/d trick. For further investigation I'd suggest: (1) Taking the output of the internal FPGA register used for your test to some external pins so you can check that the writes are doing what you think they are. (2) If you're not already using one then get hold of a digital storage 'scope (DSO) to check the voltage levels of the outputs and their timing wrt IORD*. A logic analyser timing trace would do as long as the LA's inputs had variable thresholds.Article: 43130
Neil Franklin <neil@franklin.ch.remove> wrote in message news:<6ubsbjlqzk.fsf@chonsp.franklin.ch>... > > That open source programmers accept non-supported stuff is a new thing > in FPGA development circles. They have still got to get used to our > different culture. Give them a bit of time and they will digest it. > Yep, hopefully. The extent of my FPGA experience has been a little work on video processing with the XC4000 and Spartan II families. I'm mostly a software guy.. I started a GUI for embedded systems a while ago (http://picogui.org) and among other things I wanted to experiment with a hardware version of its rendering pipeline, that could do things like compositing and primitive sorting in real time. But I'm also a fan of reconfigurable computing.. and of course I like to generalize everything :) > Try the following stuff: ... > Looking at how long your project will take (just defining your > language and how to split it CPU/FPGA), I will most likely have > that already finished before you get around to doing it. > > It has been on my project list for about 1 year, and now that my > job change is through, I can start off doing it. > > http://neil.franklin.ch/Projects/VirtexTools/ > Very nifty! I had actually seen your work a few days ago, but didn't know whether it was still active. Also, I knew about JBits, but was under the impression it could only modify the LUTs and BRAMs in existing designs, not route new ones. If JBits can in fact to routing, it sounds like a good interim solution to use until you reverse engineer the bitstream so we can have faster and open tools. --MicahArticle: 43131
Sean wrote: > > I'm convinced there is an anti-electical engineering field that passes > through the lab at regular intervals :) > > Anyway, here's a little history. When I at first couldn't even get > the bus working the PCI33_5 standard to work it appeared we had no > problems with voltage levels. Everything was at 3.3V which should > have been enough for the ISA bus, but our erros clearly indicated we > were getting stuck at zero errors beause all of our erroneous data was > values that could be derived from the input simply by dropping some of > the 1's to 0's. However, we could never see these ourselves. This is > why I decided to add the 4.7k ohm pull-up resistors so the bus would > go to a full 5V. This worked, and the bus began to operate. Last > week (well, two weeks ago now), I had finished the project but was > messing around with it some more and discovered that now it worked > without the pull-up resistors. I haven't bothered to look at it with > a scope lately since the last time I did it we couldn't see anything > that should have been causing abnormal operation in the first place. > > Two weeks ago I also discovered that LVTTL doesn't work at all. I had > originally switched from LVTTL to PCI33_5 because I was basing my core > off of one from a part at Mesa Electronics, in which they used > PCI33_5. (They were also trying to assign slew rate and drive current > via the contraint file, but I don't think that's possible with > PCI33_5, only with the LVTTL io buffers). Anyway, I just stuck with > the PCI33_5 since I knew someone else had gotten the bus working using > it. > > The LVTTL not working is a mystery to me though. The behavior it > exhibits is this. I have a C++ programming writing and reading a > value into the FPGA. It reports the success or failure of each write > and read (whether it read the same thing it just wrote into the FPGA) > into a file along with the the value of each write and read > transaction. I'm doing 8-bit transactions at the moment so I > basically just have a counter that counts from 0 - 255 and writes and > reads the value. As I said, the implementation using PCI33_5 works > fine, success every time. However, the LVTTL log file is a string of > all failures except for the first one. This is because the LVTTL port > always gives me a value of zero on a read, and the first test value is > always a zero so it says it is correct. Of course, it doesn't help to > have a port that only lets the PC read in a zero regardless of the > actual data value. Occasionlly, no more than once through each run, I > will see something other than a zero on one of the PC reads, but it's > never the correct value anyway, so it still results in an error. > These are just noteworthy merely because it's not just a zero. > > This occurs even when I have the pull-up resistors to 5V on the bus so > it can't be merely a voltage level issue. I wouldn't expect that > anyway since it's for the most part a consistant zero on the port and > not some random derivative of the input value with some random stuck > at zero faults. > > I also know it's not my logic as I use the same VHDL and C++ code for > both tests, I just synthesize one using PCI33_5 and one using LVTTL. > > I guess my only other course of action is to try and delve in with the > oscilloscope again. It didn't really tell me anything useful last > time so I have my doubts. > > If I knew the drive current that PCI33_5 uses though I may not even > have to worry about the LVTTL though. So if anyone knows what the > standard drive current on a PCI33_5 output buffer is I'd be grateful, > since I can't seem to find it anywhere :) > I would guess you've got a borderline timing problem. ISA is really not that problematic... Something like violating setup/hold times on the bus maybe? I suppose you resynchronise all input signals in your FPGA - ISA may be asynchronous to your local clock. BTW, if you want 5V levels use a level converter (the safe way) or use pull-ups with *open drain* pins (the quick and dirty way). You may even drive the pin up to 3.3V and then release it to float to 5V by pull-up. I think i've seen a Xilinx appnote on that topic. Kind regards, IwoArticle: 43132
I do not have the statistics about what users do with our parts, nobody really has. That's the beauty of FPGAs; users can do anything they please, without telling us about it ( life support equipment being explicitly excluded, see one of the first pages of our data book). So I don't know this for sure, but I venture to guess that there are more people who have voiced opinions here about battery reliability and alternate security solutions, than there are designers who have actually used the free encryption we offer. Security was often "very important" while it was not available, but then turned into a big yawn when it became available. Maybe that's just human nature... Peter Alfke, Xilinx ApplicationsArticle: 43133
Greetings, I'm a bit new to all this... why doesn't the Quartus II support the "loop <body> end loop;" loop?? Is there a way to do something like this? I've got several signals, in different orders, that I want to be sensitive to. Any suggestions? Thanks!Article: 43134
Yes the other way in C is to have functions that run in parallel like threads. The compiler must be smart enough to infer real parallel hardware. Also if you take the list operator and define the behavior as fully parallel then C does not seem sequential. Steve "news.bellatlantic.net" <vze3qgji@verizon.net> wrote in message news:tr0E8.13475$Q87.4354@nwrddc02.gnilink.net... > There's a big difference between having the programmer specify the > parallelism, vs. hoping someday someone will figure out algorithms so that a > compiler that can find it. Many man-years have been spent trying to make > compilers that can find the inherent parallelism in a program, and so far > only some loop-level parallelism can be exploited. Adding features to a > language like fork and join with explicitly stated synchronization will get > you to useful parallelism far sooner than waiting for the compiler that does > it automatically. -StanArticle: 43135
As FPGAs get more popular people will just get together and figure out the bitstream anyway. So why not just publish the whole thing and get it over with? All your doing is making people jump through hoops. With the little information already published people are already making tools. Imagine if Intel had you encrypt all your programs because some people were afraid of having their programs decompiled? The software world would be in the stone age. And that is where we are as far as programming FPGAs. Maybe someone at GNU will start hacking away. I don't think it would take much. Steve "Peter Alfke" <Peter.Alfke@xilinx.com> wrote in message news:3CE03B81.B6624D70@xilinx.com... > 1. > It might make some users feel vulnerable that their design can be > reverse-engineered and then slightly modified to hide the rip-off. > > 2. > It might expose Xilinx to unreasonable and unsupportable user questions, > especially when they painted themselves into a corner. And he who sells the > chips ultimately is stuck with the cry for help... > > Peter Alfke >Article: 43136
Ted Bronson wrote:
>
> I'm a bit new to all this... why doesn't the Quartus II
> support the "loop <body> end loop;" loop?
> I've got several signals, in different orders, that I
> want to be sensitive to.
Quartus II does place and route on completed designs.
It is *very* limited for HDL design entry and
has *no* provisions for HDL simulation.
It does have a good schematic editor.
If you want to do HDL design entry you will need
to learn Verilog or VHDL and get HDL simulation
and synthesis tools.
-- Mike Treseler
Article: 43137In article <37ce351d.0205141037.b48f444@posting.google.com>, Micah Dowty <micahjd@users.sourceforge.net> wrote: >Very nifty! >I had actually seen your work a few days ago, but didn't know whether >it was still active. Also, I knew about JBits, but was under the >impression it could only modify the LUTs and BRAMs in existing >designs, not route new ones. If JBits can in fact to routing, it >sounds like a good interim solution to use until you reverse engineer >the bitstream so we can have faster and open tools. It can modify the PiPs as well, giving complete control, and there is a high level module to do routing. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 43138
John Williams <j2.williams@qut.edu.au> writes: > things about the bitstream format. In particular, we found a simple > method that could, in principle, be used to reverse engineer the > bitstream. Or more precisely, reverse engineer the relationship between > a placed and routed design, and the corresponding bitstream. The idea > of actually developing a tool to do the constrained routing etc just > makes my head hurt. For Virtex it is a bit simpler. The JBits docs actually show exactly how many wires and PIPs the routing consists of. And the library allows discovering them individually. For an _partial_ sketch (no hex and long lines), derived soley from that docu, no experimentation yet, see this: http://neil.franklin.ch/Projects/VirtexTools/Virtex-CLB-PIPs > Anyway let me know if you are really interested to hear more about the > bitstream stuff. Allways interested here. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Make your code truely free: put it into the public domainArticle: 43139
In article <MPG.174b1a664828c90198979e@enews.newsguy.com>, Keith R. Williams <krw@btv.ibm.com> wrote: >> 2. are not good for keeping a secret ( easily detected ) > >It's done for cryptographically strong data (e.g. private keys) in FIPS >140-1 level-4 crypto equipment. Secrets are a pretty big deal in this >application. Then again, look at the massive physical packaging to maintain that level of security in the IBM 4758 (Is this what you are referring to?). Also, I thought that they used SRAM, simply because it is much easier to zero out the contents when the physical tamper-sensor is disturbed, keeping the SRAM bits from being burned in by the use of occasional data moves. I wonder what sort of ram-keeper/ram-saver is used in the Virtex II mechanism? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 43140
That's pretty much what I was figuring. You would be able to program software objects in any existing language, and hardware or software objects in the new language. Existing software languages could use a shared library to send/recieve messages with other objects (software or hardware) and native message sending support could be used where applicable (in languages like Objective C). The new language would compile each object to software and to hardware. The decision of which objects to implement in hardware could be made automatically (by available FPGA space and software CPU utilization) or hinted by the programmer. Each software/hardware object would share a relatively low speed message passing bus, plus there could be some way to do faster direct data transfer. This could be done between hardware components by directly routing wires between the objects, and it could be done between hardware and software objects using DMA. I would prefer to stay away from .NET, for a few reasons... - For software-only components any language should work - For the software/hardware components, I haven't seen a language that really satisfies the requirements fully - I'm an open source geek, I'd rather not use a microsoft product :) That said, I'll be thinking about the design of this language. Since it needs to be easy to use for non-EE software people, there needs to be an easy way to specify sequential operation, but parallel operations must be intuitive enough that the programmer doesn't overlook them. Handel-C fits this bill, but besides the problem of it being proprietary, it doesn't support the dynamically loaded objects and message passing. Maybe what we need is something like a Handel-C++. On Mon, 13 May 2002 15:05:43 -0600, Jim Granville wrote: > The best 'horizon' approach would be > > - A language that is inherently parallel and capable of HW description > (More than one language support would be good : some problems suit > some languages better than others). > > - A three way path for that language, to allow > a) Run on a PC/ARM/PPC etc HW, ie Hard core with maximal resource b) > Run on a soft-core, ie FPGA core with minimal resource c) Run in FPGA > HW > > Some discussion on Java in FPGA's is already underway, another > pathway would be to implement .NET MSIL in FPGA/Softcore combination. > > .NET is new, but already looks a more stable pivot point than Java > flavours, > and .NET has good language support already - See > > http://msdn.microsoft.com/vstudio/partners/language/default.asp > > This would lead to .NET core(s) in FPGA, with key code sections chosen > as > FPGA-Macros, running as a system. > > jgArticle: 43141
In article <3CE161BB.801C40DB@xilinx.com>, Peter.Alfke@xilinx.com says... > I do not have the statistics about what users do with our parts, nobody really has. Are FAEs encouraged to feed back such requirements? How about cost sensitivity to real solutions? Fuses are cheap, by the dozen. However, if there are billions unused, then the dozen used get expensive. > That's the beauty of FPGAs; users can do anything they please, without telling us > about it ( life support equipment being explicitly excluded, see one of the first > pages of our data book). The first time I saw the "life support" issue was when perusing a Nat- Semi databook some thirty years ago. I thought it strange, until I thought about it a few microseconds. > So I don't know this for sure, but I venture to guess that there are more people who > have voiced opinions here about battery reliability and alternate security solutions, > than there are designers who have actually used the free encryption we offer. I've dealt with batteries. What a PITA! I'd be more wary about PO'd customers than a few stealing the products. When it's crypto stuff, the customer's data is far more important than my design. The tables turn. > Security was often "very important" while it was not available, but then turned into > a big yawn when it became available. Honestly, it's of no concern for the FPGA application I've had. I can see where it's a nice feature. Don't get me wrong, I'm not complaining about Xilinx' design point. It seems to be a cheap solution to at least part of the problem. Anything more complex could cost everyone. I don't think that's the right answer for the market. My only point is that there are solutions to this problem, though perhaps not simple. Similar things have been done (though I don't know about the IP status). > Maybe that's just human nature... True. "I want it, and I want it free" is human nature. "I need it and now" is definitely PHB nature. ;-) ---- Keith (not speaking for IBM)Article: 43142
micahjd@users.sourceforge.net (Micah Dowty) writes: > Neil Franklin <neil@franklin.ch.remove> wrote in message news:<6ubsbjlqzk.fsf@chonsp.franklin.ch>... > > > > That open source programmers accept non-supported stuff is a new thing > > in FPGA development circles. They have still got to get used to our > > different culture. Give them a bit of time and they will digest it. > > mostly a software guy.. I started a GUI for embedded systems a while > ago (http://picogui.org) I have heard of its name, but never looked into its details. > and among other things I wanted to experiment > with a hardware version of its rendering pipeline, An open source graphics accelerator, nice. > also a fan of reconfigurable computing.. and of course I like to > generalize everything :) What hacker doesn't? ;-) > > http://neil.franklin.ch/Projects/VirtexTools/ > > I had actually seen your work a few days ago, but didn't know whether > it was still active. Not yet active. Waiting for the 3rd milestone of the PDP-10 before I really start on it. To follow current state of activity look at: http://neil.franklin.ch/Projects/VirtexTools/Logfile (freshly updated, just now) And for the PDP-10 project that is competing with it for my time look at: http://neil.franklin.ch/Projects/PDP-10/Logfile > Also, I knew about JBits, but was under the > impression it could only modify the LUTs and BRAMs in existing > designs, not route new ones. My entire PDP-10 clone FPGA CPU is written using only JBits. YOu can look at the source at: http://neil.franklin.ch/Projects/PDP-10/pdp10.java Limit is presently, that you need an empty bitfile to modify (programming is debugging an empty file, and so ...), and there are only XCV300/800/1000 coming with JBits. No Spartan-II compatible sizes. > If JBits can in fact to routing, it > sounds like a good interim solution to use until you reverse engineer > the bitstream so we can have faster and open tools. It can and it is. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Make your code truely free: put it into the public domainArticle: 43143
> I'm a bit new to all this... why doesn't the Quartus II > support the "loop <body> end loop;" loop?? When synthesizing VHDL loops inside a process will result in the logic inside the loop being repeated as many time as the code is looped. So if you loop a statement which generates and adder 16 times, it will generally create 16 adders. So an unconditional loop will keep generating new hardware, which wont fit in a any device. Suggesting an alternative way of implementing your function would be easier if you posted the code you have now, but I think that a process with the right sensitivity lis (and no loops) might be the soltion. (A process with a sensitivity list will loop everytime one of the signals in the sensitivity list changes) Dines -- --------------------------------------------------- Dines Justesen | dines@aub.dk | www.aub.dk/~dines ---------------------------------------------------Article: 43144
On Tue, 14 May 2002 14:34:37 -0600, Neil Franklin wrote: >> If JBits can in fact to routing, it >> sounds like a good interim solution to use until you reverse engineer >> the bitstream so we can have faster and open tools. > > It can and it is. > Sounds like it would be useful to have an intermediate format that could be fed into a JBits-based tool or into your open tools. Are there already any good formats for this? --MicahArticle: 43145
Do not pay attention to the names of the signals, they refer to something else. In fact Xilinx guys confirmed that the bug is real and will be fixed in fall. Tullio Kevin Brace wrote: > > Have you simulated your design after synthesizing it with FPGA Compiler > II? > I feel like it won't function at all because according to Stuart > Sutherland's Verilog HDL Quick Reference Guide > (http://www.sutherland-hdl.com/on-line_ref_guide/vlog_ref_top.html), > bufif1's syntax will be the following. > > bufif1 (1_output, 1_input, 1_control) > > This is what you got in your code. > > bufif1 buf_D_0 (LocData[0], D_OUT[0], LocDir); > > I think it should be instead, > > bufif1 buf_D_0 (D_OUT[0], LocData[0], LocDir); > > ... -- Tullio Grassi ====================================== Univ. of Maryland - Dept. of Physics College Park, MD 20742 - US Tel +1 301 405 5970 Fax +1 301 699 9195 ======================================Article: 43146
Hi,
Verilog allows a construct to pass parameters to lower level modules:
//////////////////////////////////////
parameter
PARAM1 = 128;
defparam
my_lower_module.PARAM1 = PARAM1;
//////////////////////////////////////
that works as long as inside my_lower_module
PARAM1 is defined again.
This can be repeted for several modules down the hierarchy,
and is very useful for heavy hierarchical designs.
I've had problems using it with XST (ISE4.2).
It looks like XST selects the value randomly along
the hierarchy, rather than at the top level.
Anybody had similar problems ?
--
Tullio Grassi
======================================
Univ. of Maryland - Dept. of Physics
College Park, MD 20742 - US
Tel +1 301 405 5970
Fax +1 301 699 9195
======================================
Article: 43147Peter Alfke wrote: > > "Keith R. Williams" wrote: > > > Fuses? The problem then moves to test, but it's been done. > > Fuses are ugly: > 1. take lots of current to blow (big drivers) > 2. are not good for keeping a secret ( easily detected ) > 3. are inherently one-time-programmable, which does not sit well with the basic > concept of our FPGAs > > Peter Alfke On a more up-to-date front than fuses, has Xilinx looked at this : http://www.viragelogic.com/products/compilers/novea/index.jsp http://www.viragelogic.com/products/datasheets/NOVeA_family_datasheet.pdf They claim TSMC process compatible, and : # NOVeA is a non-volatile memory that can be reprogrammed multiple # times. Additionally, this memory can be embedded into a SoC and can be # fabricated in a state-of-the-art, leading edge standard logic process # with no additional process steps. Integrating NOVeA will help reduce # overall system costs, increase performance and security and greatly # decrease the time to market. This is not large capacity, so not suited to the whole bitstream, but does look a candidate for security, and serial numbering applications. Xilinx could even use this to put another spin on their Yield-Recovery offerings of 'Device does not fully pass test' pathways :) ie Turn the FPGA into a Hard Drive in nature, with 'bad sector' mapping. -- oops, now it's in the public domain, I can't patent this. -jgArticle: 43148
Jim, Yup. Been there, done that. No news. Nothing there. Austin Jim Granville wrote: > Peter Alfke wrote: > > > > "Keith R. Williams" wrote: > > > > > Fuses? The problem then moves to test, but it's been done. > > > > Fuses are ugly: > > 1. take lots of current to blow (big drivers) > > 2. are not good for keeping a secret ( easily detected ) > > 3. are inherently one-time-programmable, which does not sit well with the basic > > concept of our FPGAs > > > > Peter Alfke > > On a more up-to-date front than fuses, has Xilinx looked at this : > > http://www.viragelogic.com/products/compilers/novea/index.jsp > > http://www.viragelogic.com/products/datasheets/NOVeA_family_datasheet.pdf > > They claim TSMC process compatible, and : > # NOVeA is a non-volatile memory that can be reprogrammed multiple > # times. Additionally, this memory can be embedded into a SoC and can be > # fabricated in a state-of-the-art, leading edge standard logic process > # with no additional process steps. Integrating NOVeA will help reduce > # overall system costs, increase performance and security and greatly > # decrease the time to market. > > This is not large capacity, so not suited to the whole bitstream, but > does look a candidate for security, and serial numbering applications. > > Xilinx could even use this to put another spin on their Yield-Recovery > offerings of 'Device does not fully pass test' pathways :) > > ie Turn the FPGA into a Hard Drive in nature, with 'bad sector' > mapping. > -- oops, now it's in the public domain, I can't patent this. > > -jgArticle: 43149
HI;
Thanks for reading this. I have been trying to program a sartan II chain.
I am using the following to build the prom file...
# Created 2002/05/14 17:35:20
BeginProm
Type Serial
Format MCS-86
FillValue FF
Info MaxAddress 0x000CBD73
Devices FullCustom XC18V04 XC1704L
BeginChain
StartAddress 0x00000000
Direction UP
Info EndAddress 0x000CBD73
Info Size 0x000CBD74
File "C:\dram_top.bit"
File "C:\dram_top.bit"
File "C:\dram_top.bit"
File "C:\pci_top.bit"
File "C:\dram_top.bit"
EndChain
EndProm
There are 5 spartan IIs chained together as : prom, prom,
dram,dram,dram,pci,dram
I can see data appearing to load into the spartans when they try to config.
I have no problem loading thre spartans or proms from the DLC7 paralell
cable.and it says the proms verify OK.
Questiuon:
Do I set the cclk or jtag clk option when making a bit stream for use in
the prom. I Am using master slave mode or at least trying to. How does
the promgen utility lknow how to break the bit files up to go in the right
prom, do I load them in the same order as I would using the JTAG loader to
load the individual spartans?
Thanks
any help is appreciated.
C.W. Thomas
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