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
Go to: start|settings|control-panel|system|advanced|environment-variables set the LM_LICENSE_FILE to point to c:\flexlm\license.dat for user variables and system variables. Install IPX/SPX network protocol in windows2k. Dave Feustel wrote: > > I am having *zero* success getting the Flexlm licensing process > for Modelsim to work on my Windows 2000 Pro SP1 Dell > system. This in spite of generous help from Model Technology. > The first attempt to access Modelsim after each install results in a > flexlm error message (latest is 'can't find license file') and an > invalidated license. > > This happens both with Webpack Modelsim and also the > full version of Modelsim on CDROM delivered directly from Model. > > To say that attempting to use Modelsim under these conditions > is getting old fast would be a serious understatement. > > Does the Flexlm licensing and license validation procedure actually > *work* on Windows 2000? -- ___ ___ / /\ / /\ / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ /__/ / Victoria, Australia, Down-Under /__/\/\/ \ \ / http://home.iprimus.com.au/rjshaw \ \/\/ \__\/ \__\/Article: 33726
Kamal Patel wrote: > > That is correct Robert. The ISE GUI ... I hope that batch files still will work. -- Phil HaysArticle: 33727
1ns sounds pretty high for just loading differences. Make sure your clock is clean and stable, also if you have lots of outputs toggling on the same bank as the clock input, you might move them. For experimentation purposes, perhaps you can hold those outputs constant to see if the skew improves. Also, what is the resolution of your test setup, it might be exaggerating the skew. Anyway, I have come to avoid depending on the edges being aligned (the case where we had a problem had on the order of 500ps skew, partly because of greatly unequal loading, partly because of clock jitter we could do nothing about). Changing the UCF generally isn't going to help the situation. The problem comes about in the design because you are moving data between clock domains on edges that are supposed to be aligned. You'll have to change your design to make sure data is stable on both sides of the transition where you cross clock domains. There are a number of ways to do it. You might refer to Peter Alfke's (Xilinx) app note on synchronizing data. It is intended for asynch interfaces, but the mehtods apply here just as well. Cary McCormick wrote: > Hi folks, > I'm using a DLL in a SpartanII design and have discovered with lab > experimentation that lo and behold, the /4 output lags the edge of the x1 > output by about 1ns. I'm certain that I'm using the DLL correctly (BUFGs on > both outputs, feedback comes from BUFG'd x1 output) and I imagine that the > phase difference is due entirely to loading differences since the /4 clock > is *much* more heavily loaded than the x1 clock. > So, given that we're kind of stuck with this (what's the point of BUFG's > anyway if this happens?) how can I design with this? Will the Design Manager > (using 3.1) check for setup problems? Any design tricks that the gurus can > share on this matter?? Safety precautions I can add to the UCF file?? > Thanks!! > > Cary McCormick -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33728
Maybe the following will give you some insight
http://www.fpga-faq.com/archives/16150.html#16156
On 31 Jul 2001 11:54:54 -0700, kathy_n_brian@hotmail.com (Kathy & Brian) wrote:
>I simply want to use the Length Count value within the bitstream to
>determine exactly how many bits need to be clocked in to fully program
>the device. I've thoroughly searched this group and Xilinx support
>for a clear explanation of the Length Count field, but I have yet to
>find a satisfactory explanation on the true meaning of Length Count.
In a nutshell:
For XC2K, 3K, 4K, and Spartan chips, the loading of the FPGA is
controlled primarily by the framing of the data. In the background, a
counter is counting CCLK cycles, and matching it against the Length
count field. A rather useful diagram that I would like you to look at
is not included in the Spartan data sheet that I have
http://www.xilinx.com/partinfo/ds060.pdf
but you could look at Figure 48 in
http://www.xilinx.com/partinfo/4000.pdf
which is the same logic that the Spartans use.
When the chip is "FULL" as a result of having received enough frames,
the "Full" signal goes high. Providing that the length count value is greater
than the number of CCLK cycles needed to get to the FULL state, when
the length count is matched by the CCLK clock counter, the signal
"Length Count" goes high. See fig 48, AND gate on left side. Then over the
next few CCLK cycles, the startup state machine releases GSR, enables
the I/Os, and issues DONE.
While not totally satisfying, may I suggest the following:
Take the PROMSIZE number from the data sheet:
DS060.pdf, page 4-29, which is 249168.
Add 2 bytes of 0xFF at the end of the bitstream
When you do your configuration, supply enough CCLK
cycles to clock in the 249168 bits, AND the extra 16 '1' bits.
Check that Done is high.
> For an XCS30XL running in Slave Serial mode, BitGen calculates a
>Length Count value of 249161. This value places the "end" of the
>bitstream 2 bits beyond the Postamble. I would expect Length Count to
>be either 249159 (number of bits from start to end of Postamble) or
>249163 (add 4 bits for Start-Up phase). What is the purpose of this 2
>bit difference?
The Xilinx SW has had many attempts at getting these numbers right,
and there seems to always be a case where it is off by 1 or 2. The above
algorithm will always work, and what vetrans use (or something like it)
when they want to get on with their lives, and have had enough of trying
to figure out what the optimal number is.
FYI the underlying cause of the problem is that bitstreams can be loaded
either serially or in parallel, and you DO NEED at least 1 or 2 clocks after
DONE has gone high for config to have actually finished, for some startup
options, including the default.
Figure 47 in the 4000.PDF file shows this sequence, but this figure is missing
from the Spartan data sheet. The default is shown as CCLK_NOSYNC, and
you can see that if you stop clocking CCLK as soon as you see DONE, (at
time C1), you end up with a chip that has DONE high, but I/Os are still
tri-stated, and GSR is still asserted.
Give it 1 extra clock, and you have a chip for which DONE is high, and I/Os
are active, and async paths through the chip work, but clocked stuff doesn't
because GSR is still asserted. Two extra clocks and the chip is live. My
suggestion of 16 extra, is because I know it will work, and it doesn't hurt.
Another fly in this ointment is parallel load. For example if the FULL and
Length Count occur on the second last bit of the byte being shifted inside
the FPGA. You know you gave it all the data it needs, but infact it needs
one more byte of 0xFF so that it will generate enough clocks to finish the
startup sequence.
One extra Safety Note: If you set Length Count to a value less than the
number of CCLKs that are needed to get to FULL, you will be disappointed,
because the comparator of Length Count to the CCLK counter will only
be valid for 1 CCLK cycle. Then the counter continues, and it will take
2^24 more clocks before it matches Length Count again.
When you get to use Virtex chips, all this is irrelevant.
> There is a support question (Answer Record #7912) that explains
>how the Length Count is calculated by BitGen, but it raises even more
>questions. It states that the Length Count value = (PROM size - 7).
>Why subtract 7? Why derive Length Count from the PROM size at all
>(the PROM size includes an unknown quantity of fill bits!)? The
>calculation presented does indeed match my bitstream file contents.
>However, since the Length Count value does not have any useful
>relationship to the actual number of configuration bits (due to the
>unknown number of fill bits), it cannot be used by a microprocessor to
>clock in the correct number of bits! The only solution that I see is
>to add some arbitrary number (7 would probably make the most sense) to
>Length Count to ensure that "enough" bits are clocked in. This seems
>like such a hack.
Yep. Just what I am recommending :-)
> Does anybody know why Xilinx doesn't simply set Length Count equal
>to the exact number of bits necessary to completely program the
>device? Or 4 more (for the Start-Up phase)? This would seem to make
>so much more sense!
Hope the above shed some light on the issue.
Philip Freidin
Philip Freidin
Fliptronics
Article: 33729I have painful experience when obtaining license from ModelSim and Xilinx ISE Foundation, espeically Xilinx. It is difficult to imagine we pay so much for the software in exchange for such poor service Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3B69B802.B5C06920@flukenetworks.com>... > Dave Feustel wrote: > > > > Does the Flexlm licensing and license validation procedure actually > > *work* on Windows 2000? > > I can testify that validation works on win2k. > My license server is elsewhere on the network. > I assume you have set a path for > LM_LICENSE_FILE or MGLS_LICENSE_FILE > > (Start, Settings, ControlPanel, > System, Advanced, Environment . . .) > > > --Mike TreselerArticle: 33730
> Second, JUST BECAUSE THE SYSTEM IS DESIGNED TO RUN AT "ONLY" 30 MHZ DOES > NOT MEAN YOU DO NOT HAVE A SIGNAL-INTEGRITY PROBLEM. Read the Johnson > book. It's the edge rates that get you, not the clock speed. You are absolutely right about that! The CCLK has a very slow frequency, 8MHz, but the edge rate is sub-nanosecond! I have run into quite a few PCB layouts that have CCLK running all over the place, Ts etc....and the company wonders why the boards don't reliably configure. The other thing is, they don't believe it when I tell them that is their problem...but a few capacitors and resistors, cuts and jumps...and the thing configures perfectly reliably. I don't know if Xilinx has an application note on exactly this, and CCLK routing, but if it doesn't, I'd strongly urge one!Article: 33731
> I was merely making the observation that cost and size of company do not > determine the quality of a design. I would absolutely agree with that. > I do > realize the that large designs do not necessarily use many pips. In fact, for > high performance designs, I try to minimize the number of pips crossed. One thing is nagging me about this... I believe I was reading that the intention of this "test" was to maximize the number of pips/resources used on a single chip...and that seemed to induce failure. I may not be saying that correctly, but follow me...my head is still on vacation. Pips are quite resistive, and they also will degrade the signal... I seem to remember a time ago, when you could only go through so many pips without having to be "re-powered". Might there be an internal EMI issue, heat issue or general signal integrity issue causing these failures? I didn't read that they were hard failures, or that they were even tested for hard failures after a failure was found? The tools might be causing the problem, not taking into account actual signal integrity issues in the chip... Just a though... The numbers just seem way too high to me too...and I'd have to say I've shipped many tens of thousands of FPGAs, with VERY dense, fast designs, and not seen anything remotely like this...Article: 33732
Hi, gurus:
For a school project, I should implement within the next three months
a basic, but prefereably not very basic, CPU = microprocessor on a
PLCC84 cased Xilinx Spartan XCS05-3 running @ 10MHz, or even faster.
The design should meet, or exceed, the following requeriments:
- Speed
- Make it fit on the FPGA
- Should write our own compiler ("our" assembler -> bitsteram)
- Instructions: 8 bits long
- Data: 4 bits long
So, would some of you, please, help me with some starting points, as
links, textbooks, vhdl code, etc...?
I am sure most of you, guys, could give good advice on the subject.
Please reply to jaime.aranguren@ieee.org
Thanks a lot, in advance
Article: 33733;-)) Iam sorry, I think I was a little bit impulsive. But there is (better was) a good reason for this. A guy in our company was trying to get a Flex10K working with a very simple design, but without success for one week. Then, he and me got together to fight the problem. After almost two days, we did, and 90% of the problem was our fault, but the behaviour of the undefined pins (DRIVING a signal) fooled us a lot. :-( Anyway, every information is appreciated. Thank you. Again, Iam sorrry about the LOUD reaction. You say you can do all designs with Quartus? Also Flex10k?? AFAIK this is not possible? Regards FalkArticle: 33734
The load is a track (2.5cm) to a connector with a FET probe (0.7pF||100k ohm). We have tested with different frequency, so it is not the reflection. "Andy Peters <andy [@] exponentmedia com >" <".> wrote in message news:FFga7.1224$B.115611@newsread1.prod.itd.earthlink.net... > "Sune G. Krohn" wrote: > > > > I can't get a signal out of Xilinx Virtex-II 2V100 and 2V40 with a correct > > duty cycle. > > > > I only see this problem in 1.5 and 2.5 voltages mode. > > > > I also see the problem on Xilinx Virtex-II Evaluation Kit with a 2V40. > > > > As output I use OBUF_LVCMOS15_F_16 for 1.5 V and OBUF_LVCMOS33_F_16. > > > > With a frequency about 100MHz is the duty cycle about 35/65. In the test I > > run the clock through a FF to make a 50/50 duty cycle and with no luck. > > > > It is always the high pulse that a shorter than the low, even if I invert > > the signal. > > > > We have asked Xilinx's Technical Support Office United Kingdom every day for > > two weeks and they can't answer the question they just ask irrelevant > > questions. For instance, they ask my to do an IBIS simulation on their > > Evaluation Kit with their chip. > > What's the signal's load? That's why they want you to do an IBIS sim... > > -andyArticle: 33735
In article <3B5F015E.E3DBFF54@xilinx.com>, Peter Alfke <peter.alfke@xilinx.com> writes: >This is a tricky problem, and it is common to all BGAs not just Xilinx devices, >but programmable logic may offer a solution: >You want to have significant Icc, and then you want to observe whether there is >a Vcc gradient on the internal supply. >I would reconfigure the chip with a bunch of distributed local oscillators ( odd >number of inverting CLBs feeding back in a loop), and you can then observe the >relative frequency of these oscillators. If one is significantly slower than the >others, it indicates a missing Vcc connection. Interesting suggestion. But now I'm curious. How are BGAs actually built? I see what looks like a small PCB. Is that a 1 layer board with simple traces from each ball to the correponding bonding pad? Or are there power and ground planes to reduce lead inductance? If so, wouldn't that mostly mask a missing pwr/gnd connection? -- These are my opinions, not necessarily my employeers. I hate spam.Article: 33736
Ray Andraka wrote: > > Yes. The problem is in the di/dt caused by very fast edges on the signals. You > can help it out some be selecting the low slew rate drive and setting the output > currents at the lowest possible values consistent with what you are driving. You > can also intentionally skew outputs if you have a higher clock available to > minimize the number of outputs changing at once. Isn't it possible to add some kind of passive low-pass filter to copensate for these fast edges ? And BTW, would you have some reference about suche PCB issues (a book for example). Thank you for your help. Steven > > Steven Derrien wrote: > > > Is this also a strong issue when the system is clocked below 1MHz ? > > (sorry I have very little knowledge of PCB layout issues) > > > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.comArticle: 33737
Jaime Andres Aranguren Cardona wrote:
>
> For a school project, I should implement within the next three months
> a basic, but prefereably not very basic, CPU = microprocessor on a
> PLCC84 cased Xilinx Spartan XCS05-3 running @ 10MHz, or even faster.
>
> The design should meet, or exceed, the following requeriments:
> - Speed
> - Make it fit on the FPGA
> - Should write our own compiler ("our" assembler -> bitsteram)
> - Instructions: 8 bits long
> - Data: 4 bits long
>
> So, would some of you, please, help me with some starting points, as
> links, textbooks, vhdl code, etc...?
>
> I am sure most of you, guys, could give good advice on the subject.
>
> Please reply to jaime.aranguren@ieee.org
No - post here, read here.
You should first decide on the size of memory available, i.e. how
many words can be addressed as instruction, how many as data, are
they separate spaces (must be if you are making data memory 4 bit
units and code memory 8 bit units).
Look up the instruction sets and architecture of some classic
simple computers. The 8008 will be instructive, as will the 8080,
6502, 6800. Don't forget the PDP8. The 8080 was the first real
general purpose CPU. The 6502 architecture was better suited to
controllers than computing. The 6800 was also a good
architecture, but less useful than the 8080 IMO. The 8008 was
effectively a crippled subset of the 8080.
You can do a lot with a 4 bit instruction word - I built such a
machine in 1964. If you don't want to implement multi-word
instructions you need to make the instructions context sensitive,
but that leads to complexity.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@XXXXworldnet.att.net)
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:uce@ftc.gov (for spambots to harvest)
Article: 33738"Steven Derrien" <sderrien@irisa.fr> wrote in message news:3B6A5BD6.C5208CDE@irisa.fr... > > > Ray Andraka wrote: > > > > Yes. The problem is in the di/dt caused by very fast edges on the signals. You > > can help it out some be selecting the low slew rate drive and setting the output > > currents at the lowest possible values consistent with what you are driving. You > > can also intentionally skew outputs if you have a higher clock available to > > minimize the number of outputs changing at once. > > Isn't it possible to add some kind of passive low-pass filter to > copensate for these > fast edges ? > > And BTW, would you have some reference about suche PCB issues (a book > for example). > The standard text is Johnson and Graham's 'High-Speed Digital Design'. There is also a new text, whose title escapes me at the moment.Article: 33739
How can 500ps of clock skew cause this kind of trouble? The clock to out time plus some routing should always be greater than this? How did you measure the skew (skew matching of IO cells, equal routing to IO cells) Regards FalkArticle: 33740
"Andy Peters > > david garnett wrote: > > > > The BurchED Spartan board is only two layer, > > That's good to know. > > If it were me, I'd do at least four layers - top and bottom for signal, > middle two for VCC and GND. BTW, just to get an idea, let's say I m an inexperienced PCB designer and that I want to have my own PCB board for a specific app. (let's say a 4 layers board with a SPII-pq208, SRAM, and and ethernet controller + transceiver) i'd need around 100 sample of them (so it's very low volume) 1) I could can ask for PCB designer services, to design the layout and handle the production but then it's likely to be expensive (price range ?) 2) I can do the layout on my own using for ex Orcad, since i am inexperienced do I have a chance to succeed (I mean to get a working board) and if so how long will it take ? and in such a case how much it would cost ? Thanks, steven app an > > -andyArticle: 33741
"Peter Ormsby" <faepetedeletethis@mediaone.net> writes: > Wow. Bite my head off. > Sorry! Didn't mean to come across like that - just wanted to point out that there was more than one of us who'd been caught out! > I think there's some confusion on the tools. I'm sorry I didn't > specify I waas speaking of Quartus. Unless you're designing MAX3000 > or MAX7000, there's no reason to be using MAX+PLUS II anymore. > Or Flex10K, Acex 1K, (or indeed Max 9000 or any of the older stuff). Max is still used for highish density designs, although the fitter has been ported from Quartus. > In any case, the default behaviour "out-of-the-box" for Quartus is to > have the unused pins configured as inputs (tristated). You don't need > to delve into the menus if you don't want to. Is that nice enough > default behaviour? > Just right! > I was just trying to show you how to change the default settings if > you wanted to. Too much information, I guess. > Fair enough, I just wanted to make sure the Max Plus II *default* behaviour was clear to people. Cheers, MartinArticle: 33742
Steven Derrien <sderrien@irisa.fr> writes: <snip> > And BTW, would you have some reference about suche PCB issues (a book > for example). > You could have a look at some of the docs written by Doug Brooks at http://www.ultracad.com/articles.htm There is also a signal integrity forum on freelists.org... and many more useful documents scattered around the web. > Thank you for your help. > Not at all! Cheers, Martin > Steven > > > > Steven Derrien wrote: > > > > > Is this also a strong issue when the system is clocked below 1MHz > > >? (sorry I have very little knowledge of PCB layout issues) > > >Article: 33743
On Fri, 03 Aug 2001 08:24:50 GMT, CBFalconer <cbfalconer@yahoo.com>
wrote:
>Jaime Andres Aranguren Cardona wrote:
>>
>> For a school project, I should implement within the next three months
>> a basic, but prefereably not very basic, CPU = microprocessor on a
>> PLCC84 cased Xilinx Spartan XCS05-3 running @ 10MHz, or even faster.
>>
>> The design should meet, or exceed, the following requeriments:
>> - Speed
>> - Make it fit on the FPGA
>> - Should write our own compiler ("our" assembler -> bitsteram)
>> - Instructions: 8 bits long
>> - Data: 4 bits long
>>
>> So, would some of you, please, help me with some starting points, as
>> links, textbooks, vhdl code, etc...?
>>
>> I am sure most of you, guys, could give good advice on the subject.
>>
>> Please reply to jaime.aranguren@ieee.org
>
>No - post here, read here.
>
>You should first decide on the size of memory available, i.e. how
>many words can be addressed as instruction, how many as data, are
>they separate spaces (must be if you are making data memory 4 bit
>units and code memory 8 bit units).
>
>Look up the instruction sets and architecture of some classic
>simple computers. The 8008 will be instructive, as will the 8080,
>6502, 6800. Don't forget the PDP8. The 8080 was the first real
>general purpose CPU. The 6502 architecture was better suited to
>controllers than computing. The 6800 was also a good
>architecture, but less useful than the 8080 IMO. The 8008 was
>effectively a crippled subset of the 8080.
>
>You can do a lot with a 4 bit instruction word - I built such a
>machine in 1964. If you don't want to implement multi-word
>instructions you need to make the instructions context sensitive,
>but that leads to complexity.
A micro with a 4 bit instruction and 8 bit data sounds very much like
a low end (12 bit) PIC, such as the 16C5x or 12C508 etc.
A free VHDL core exists for a basic PIC, a quick serach should find
it.
Mike
Article: 33744
"Rick Collins" <spamgoeshere4@yahoo.com> wrote in message
news:3B67A4B4.29694DFF@yahoo.com...
> I am adding some code to a verilog design for debug and I need to access
> signals in a remote portion of the design. I have been told that there
> is a way to do this in the form of
> "top_level.mid_level.low_level.signal_name" where the level names are
> module instance names. This works ok in simulation, but I can't get it
> to work in synthesis. We are using Synplify. Is this not supported by
> this tool? Is this not supported by any synthesis tool?
Don't know of a synthesis tool which supports this...
If you want to access the signal in hardware, you need to make an
explicit
connection through the module ports.
If the signal access is just for debug, then you can hide the code from
the synthesis tool by using synthesis directives (comments which control
synthesis) e.g. enclose the remote signal access with the following
comments
/* synthesis translate_off */
<unsynthesisable debug code>
/* synthesis translate_on */
B
HDL, FPGA, PCB, Perl and Tcl training from Esperan
The World's Leading Methodology Training Company for
Electronic
Design
http://www.esperan.com
Article: 33745Have a look here http://www.mindspring.com/~tcoonan/ Regards FalkArticle: 33746
Hi Steven,
I had a simmilar problem with my own board (for Altera ACEX) also with
bad ground (because of saving money for two layer... the wrong decision).
I connected the printer port (long cable) to communicate via ECP with
a PC and got wrong data when to many bits switched. I think this led
to a 'ground bounce'.
One dirty solution (for me) was: Becaus I worked with a clock at 24 MHz
and ECP is below 1 MHz I switched the data lines one after the other.
If your clock is higher than the access time of the RAM you could try to
split the switching outputs.
Martin
--
Whant to see the evolution of a Java processor?
http://www.jopdesign.com
"Steven Derrien" <sderrien@irisa.fr> schrieb im Newsbeitrag
news:3B697EF9.E5BDF155@irisa.fr...
> Hi,
>
> We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org)
> to a VHDL targeted to the BurchEd Spartan II board
> (http://www.burched.com)
>
> We plan to make our work freely available, but are currently stuck on
> a problem. The design is a 16 CPU-SOC which interfaced to a parallel
> port.
>
> We have somes on-chip blockrams which serves as ROM, and off-chip
> asynchronous
> SRAM whiwh serves as main memory. Our problem is that we get frequent
> errors when accessing the off-chip SRAM banks. Generally a single bit
> wrong in a 16 bit data word every 200-300 access.
>
> All simulation (RTL,gate-level,post place and route) went fine.
> Right now, our system is clocked at 1Mhz far below its maximum
> frequency.
> Besides, the SRAM Write Enable command output signal is registered
> (although not in a IOB register) to avoid glitches which could cause
> wrong write operations.
>
> All IOB are configured with SLOW slew-rate and drive 12mA (default IOB
> config)
>
> We have been beating our heads on this problem for almost a week now,
> are there any experts around there to offer some tips/ideas/advices ?
>
> Thanks,
>
> Steven
Article: 33747Falk, No problem. I understand the frustration of problems like that. I've been there myself. As far as device support, the latest release of Quartus supports almost everything except MAX3000 and MAX7000 (yes, it supports FLEX 10K and ACEX 1K). Here's the link (device support is almost at the bottom of this page): http://www.altera.com/products/software/quartus2/qts-index.html Here's the fancy marketing stab at the same information. http://www.altera.com/literature/sg/dtsg.pdf The reason I'm including this second link is that the brochure indicates that there is going to be a "Web Edition" of Quartus that's free (like the MAX+PLUS II baseline). Altera is also adding support for some small APEX 20KE devices to the free software too. -Pete- <Falk> wrote in message news:ee71bc7.7@WebX.sUN8CHnE... > ;-)) > Iam sorry, I think I was a little bit impulsive. But there is (better was) a good reason for this. A guy in our company was trying to get a Flex10K working with a very simple design, but without success for one week. Then, he and me got together to fight the problem. After almost two days, we did, and 90% of the problem was our fault, but the behaviour of the undefined pins (DRIVING a signal) fooled us a lot. :-( > > Anyway, every information is appreciated. Thank you. > Again, Iam sorrry about the LOUD reaction. > > You say you can do all designs with Quartus? Also Flex10k?? AFAIK this is not possible? > > Regards > FalkArticle: 33748
Austin Franklin wrote: > > I was merely making the observation that cost and size of company do not > > determine the quality of a design. > > I would absolutely agree with that. > > > I do > > realize the that large designs do not necessarily use many pips. In fact, > for > > high performance designs, I try to minimize the number of pips crossed. > > One thing is nagging me about this... I believe I was reading that the > intention of this "test" was to maximize the number of pips/resources used > on a single chip...and that seemed to induce failure. I may not be saying > that correctly, but follow me...my head is still on vacation. Pips are > quite resistive, and they also will degrade the signal... I seem to > remember a time ago, when you could only go through so many pips without > having to be "re-powered". Might there be an internal EMI issue, heat issue > or general signal integrity issue causing these failures? I didn't read > that they were hard failures, or that they were even tested for hard > failures after a failure was found? The tools might be causing the problem, > not taking into account actual signal integrity issues in the chip... Just > a though... This is what I was trying to get at. If I were seeing this high a rate of failures, I'd want to know why and I want to know exactly what the failure was so that I could be absolutely sure I wasn't the cause of my own pain. I was trying to get him to state whether these were hard fails or soft errors, but it is apparent that once they isolate to a chip they replace it without ever digging further. We are also not privy to what if anything the FPGA vendor has found. I also recall there being a limit to the number of pips you can transit before redriving a signal, at least for the 3K and 4K parts. I don't remember if the virtex switch boxes repower the signal or not (the tristate long lines do, where they didn't in 4K). IIRC, the software normally will keep you from going through too many without a redrive. If he is creating the test patterns in FPGA editor, I could see where he might be exceeding that limit and thus causing his own pain. Also, there has been mention of signal integrity issues in FPGAs with smaller geometries. I know tht several of the vendors have been looking at the routing software to arrange the routing to reduce crosstalk between runs. Crosstalk has been observed in commercial FPGAs (I believe there was a paper at FPGA'2000 documenting this and discussing routing algorithms to reduce it), but those were on designs specifically tailored to induce crosstalk. Perhaps a densely routed test pattern might also induce the crosstalk especially if there are long parallel runs. Without knowing more of the details, which are apparently proprietary to his customer, all we can do is to speculate on why he is experiencing such high failure rates. If the problems were hard defects and occurred at the claimed frequency, I still think all of us who do FPGA designs day in day out would be tripping over the issue multiple times. The fact is we are not. If it were my problem, I'd want to get to the bottom of it to know why I am seeing such a high failure rate when others are apparently not. That means determining if it is a hard defect (which means pinpointing the defect to a particular node), and if not determining exactly what conditions are causing a soft error. I'd certainly enlist the vendor's help, but I wouldn't throw it over the wall and just write it off as poor yield until I knew what was going on. > > > The numbers just seem way too high to me too...and I'd have to say I've > shipped many tens of thousands of FPGAs, with VERY dense, fast designs, and > not seen anything remotely like this... -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33749
As I have posted before
Take a look at http://www.fpgacpu.org - good source of material.
Veronica
Jaime Andres Aranguren Cardona wrote:
> Hi, gurus:
>
> For a school project, I should implement within the next three months
> a basic, but prefereably not very basic, CPU = microprocessor on a
> PLCC84 cased Xilinx Spartan XCS05-3 running @ 10MHz, or even faster.
>
> The design should meet, or exceed, the following requeriments:
> - Speed
> - Make it fit on the FPGA
> - Should write our own compiler ("our" assembler -> bitsteram)
> - Instructions: 8 bits long
> - Data: 4 bits long
>
> So, would some of you, please, help me with some starting points, as
> links, textbooks, vhdl code, etc...?
>
> I am sure most of you, guys, could give good advice on the subject.
>
> Please reply to jaime.aranguren@ieee.org
>
> Thanks a lot, in advance
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