Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hello
An application question.
I want to design a Tristate buffer for a data bus. dinb is the input
data port of a BlockRAM
dataDSP is the bus of a DSP controller.
Isn't it possible to create the tristate buffer in the way I quoted at
the bottom of this article ???
It doesn't work.
What's wrong ??
WRITING to BlockRAM
-----------------------------
...
if (cs = '0') then
dinb <= data_DSP;
else
dinb <= (others=>'Z');
Thanks for any help.
Tobias Möglich
Article: 65101I was wondering if anyone has a reference design I could peak at. I just need something simple to demonstrate a working RocketIO with a XC2VP50 chip and the Virtex-II Pro FF1152 PROTO Board. As of right now, our design evaluates the gt_custom block and was configured using the architecture wizard. We have supplied the block with the five correct input clocks as specified (with REFCLK running and 50MHZ). We also set the parameter TXINHIBIT to high, which should cause TXP = 0 and TXN = 1, but both seem to be at ground. Any help, suggestions or simple reference designs would be greatly appreciated. Best Regards, T. Justin CampbellArticle: 65102
Alex Rast wrote:
>>>interfaces? I'm quite surprised that there aren't more
>>>testing/prototype systems available for these kinds of hardware, which
>>>must surely be extremely common.
>>
>>One reason may be that simulation is commonly used
>>for design verification of synchronous logic.
>
>
> That's a nice thought, but sooner or later, simulation must give way to
> actual testing. There's only so much you can confirm through simulation,
> and at some point, you have to try the real hardware and see what it
> actually does. I must also point out that there are certain types of
> circuits that are difficult, sometimes even impossible, to simulate, not to
> mention others that may be easy to set up but take forever to run even on
> fast machines. Simulation is an important and valuable first step, but IMHO
> it would take a rather credulous engineer to put his entire trust in the
> siumulation results.
Of course the hardware functions and embedded firmware must
be somehow tested during alpha and beta production.
The question you asked is why few vendors cover this
requirement and I believe that design verification
using simulation and the high quality of pcb fabrication
is part of the reason.
I used to work for a start-up company named Summmation
that made a modular test system that did just what what
you are asking for. Nobody bought it.
The reason was that by the time our development was
complete, the quality of circuit boards and digital
components had improved much more than we expected.
Testing moved up to standard interfaces like
ethernet, PCI, usb, rs232 etc. Most of these
were easily covered by a PC host and the need
for an intermediate test system quickly went away.
-- Mike Treseler
Article: 65103"Sumit Gupta" <do_not_reply_to_this_addr@yahoo.com> wrote in message > Look at > http://www.c-nit.net > for a Spartan-II board. > Sumit > > "x86asm" <isaac_8e@hotmail.com> wrote in message > news:45YOb.12249$7JB1.3852@news04.bloor.is.net.cable.rogers.com... > > Hi guys, I was wondering if there were any good starter kits you know of > > and where I am able to purchase them, I want to dip into VHDL a bit and Dear Sumit, you already posted to this newsgroup that you have a protoboard for sale as you have noticed your posting hasnt got any replies. Trying to push your ad for your board again, doesnt make it better for your sales. The previous replies to the original poster where good ones, specially the $99 offer from Avnet looks really good, you get 2 boards for $99 (50,000 gates and 200,000 gates FPGAs). Also it defenetly is possible to start without buing a board by using some free simulator. Now to the original poster - the $49 Kits are usually PLD kits, they are probably nice too, but if your budget allows for $99 - $149 price then you should look for some board with 200,000 gates FPGA on board. There are several such offerings, digilent is $99, this avnet offer is $99 most other 200,000 gate boards are little more than $99. there are many 100,000 gates board for around $99 (that c-nit board is just one of them). About the avnet promo offer (compressd info accesible here) http://xilinx.openchip.org/forum/viewtopic.php?t=2 I tried to buy it, the "checkout" was kind ok, but then I got to a page that told me that they will contact me, what hasnt happened yet. So cant tell if the offer is still valid and what are required qualifications. Anyway you should do some shopping before buying there are lots of nice kits available. AnttiArticle: 65104
I just finished a small design which uses the Rocket IO as a transceiver only. I use the GT_ETHERNET macro for a 2 byte data path.the device is a V2P7 Are you getting the DCM (which i am assuming you are using to generate your clks) to lock ? simulation is tricky ..you have to provided the TXRESET and RXRESET after the DCM has locked. And u have to run the simulation for a good length of time before things settle down. I use Active HDL for my simulations and XST for synthesis. I can send you a copy of verilog file if you think it will be useful. let me know ...also it will be great if you can mention other issues u see with it, as I am also new to RIOs. good luck, adarsh "Timothy Campbell" <tcampbel@uvm.edu> wrote in message news:bujtos$gq6$1@news.btv.ibm.com... > I was wondering if anyone has a reference design I could peak at. I just > need something simple to demonstrate a working RocketIO with a XC2VP50 > chip and the Virtex-II Pro FF1152 PROTO Board. As of right now, our > design evaluates the gt_custom block and was configured using the > architecture wizard. We have supplied the block with the five correct > input clocks as specified (with REFCLK running and 50MHZ). We also set > the parameter TXINHIBIT to high, which should cause TXP = 0 and TXN = 1, > but both seem to be at ground. > > Any help, suggestions or simple reference designs would be greatly > appreciated. > > Best Regards, > T. Justin CampbellArticle: 65105
sorry...i mean i use the rocket IO as receiver onlyArticle: 65106
Each individual Xilinx FPGA is 100% functionally and performance tested ( at high temperature and low Vcc). We drive tens of millions of test vectors at hundreds of different device configurations, trying to test every little part of the device. We may not reach exactly 100%, but we are extremely close to it. This is a large effort, and it is based on almost 20 years of experience with our parts, and on intimate knowledge of all their features. If any device misses one test, it gets scrapped. That's the way we do it at Xilinx, and I am convinecd other manufacturers do it similarily. The days of "incoming inspection" by the customer are long gone... I do not quite understand what BrakePiston wants to achieve. Maybe he can elaborate... Peter Alfke Mike Treseler wrote: > > BrakePiston wrote: > > Hi there, I am trying to gain a deeper understanding of the way > > testing is conducted on FPGA devices. I am interested in BIST testing > > for dynamic faults, not manufacturing testing. > > FPGA *devices* are tested at the factory. > The FPGA design function is tested using simulation. > Dynamic faults are eliminated by using > synchronous design style and by meeting static timing requirements. > > > > My question is: how exactly can you apply a test vector (or even just > > a 1 or 0) to an interconnect line? Can you just connect the output of > > a LUT to the wire and observe the output? > > In theory you can shift any pattern you like into the boundary scan > registers on any compliment device. In practice, this requires lots > of software to do anything useful. Here we license boundary scan software, > but use it only in production for the purpose of > finding solder opens and shorts on circuit boards. > > > I am asking this because of all the documentation I have read, nobody > > mentions where they get the test vectors from. > > > > Am i just being stupid and failing to see the obvious here? > > I expect that the number of people actually doing functional test > of fpgas using boundary scan vectors is near zero. It would be > very difficult and very slow. > > -- Mike TreselerArticle: 65107
Note: I may be wrong, but I believe the constraints I refer to were newly introduced in ISE 6.1, so this might not be valid for earlier versions. etrac wrote: > Jonathan > The SDRAM datasheets announce a Data presence from -2.1 > to 2.7ns on rising edge. The fpga synchronizes Data directly in the > IOB but how can I know the pad timing ? Nevertheless I have tried to > change the IOB attributes (FAST, 24mA, DELAY=NONE, LVTTL). The SDRAM > clock is much better when I have 24mA, but the result is the same :( Once you've "pen and papered" your timing as Peter suggests, you might want to look into the "OFFSET OUT" constraint in the constraint guide. This allows you to give minimum "clock to off-chip" delays. The router will then take into account clock skew AND pad delays. To constrain your inputs, use the "OFFSET IN" constraint. If your delays are already minimal, it may not help, but at least you'll know. Of course, you still have to take all board delays into account yourself, which is why it's important to pen-and-paper first. > "Verilog USER" > I already have a Digital Clock Manager (DCM) on my > 2x clock. I think one of its function is to deskew the clock. Do you > mean I must have a feedback from the clock ? I mean another pin which > is dedicated to feedback the SDRAM clock. > > I have only one DCM that generates the clock for the internal > controller and the external sdram. Do you think this may cause a > problem ? I have checked at the oscilloscope and sdram clock is > synchronized with the fpga oscillator. Is that mean the DCM works > correctly ? More knowledgeable people please correct me if I'm wrong, because I've been struggling with this myself, but my understanding of the situation is... The DCM needs a feedback to deskew. What it does is change the phase of its output clocks until its input clock and feedback clock are in phase. What this means is that if you feed the SDRAM clock into the feedback, and the oscillator clock into the clock input (look into using the "FEEDBACK" constraint for clocks that go off-chip before feeding a DCM CLKFB pin; I haven't seen a difference in my designs, but it seems like a good constraint to have, and it forces you to be aware of the feedback delay), the DCM will shift its CLK0 output (and all other multiples) until (if your board feedback path is properly matched) the clock edge at the SDRAM pins is in phase with the oscillator clock. For this to be true, CLK0's edge has to be generated [Feedback path delay] before the oscillator edge. Of course, this is fine if you stay whithin this single clock domain, but you have to be careful about reading back from the SDRAM. The data should be getting generated in phase with the oscillator, but it takes time for it to reach the chip. This is compounded by the fact that your next CLK0 edge comes less than one period after the SDRAM clock (at the memory pins) which generated the data. -- Pierre-Olivier -- to email me directly, remove all _N0SP4M_ from my address --Article: 65108
Tobias Möglich wrote: > An application question. > I want to design a Tristate buffer for a data bus. dinb is the input > data port of a BlockRAM Are you sure that you're allowed to feed 'Z' into the input of a blockRAM? Why don't you simply have a mux if you have multiple data sources? If I recall correctly, recent Xilinx devices only have true tri-state for their IOBs anyway, and this is otherwise really implemented using muxes (performance issues), so I don't think internal tri-states are really possible. -- Pierre-Olivier -- to email me directly, remove all _N0SP4M_ from my address --Article: 65109
Thanks Bob. Actually I need to do both. However, right now I'm at the simulation stage. I'm writing a program in C that will automatically implement changes to a particular design involving 9 FPGAs. So it has to call the XILINX tools and coordinate the operation and debugging of the system. I had asked a few companies to do a board with 9 FPGAs for me but few responded positively and the only estimate I got costs 50000 euros. This was a bit over my budget so I decided not to try the implementation as yet. But If I can get such a board I would add the implementation to my objectives. Bob Perlman <bobsrefusebin@hotmail.com> wrote in message news:<pnao001vajgongu23hui0qmgdhv41jof7b@4ax.com>... > On 19 Jan 2004 10:55:15 -0800, pbrowne0@excite.com (Patrick Browne) > wrote: > > >Thanks for responding. What I mean is that I have 9 designs, each > >desined for a different chip, but each chip must interact with the > >others. Therefore, to simulate this environment I need to run an > >implementation and simulation for each chip and have the outputs of > >the chips interacting with one another. Since XILINX's Project Manager > >only loads one chip's design at a time, I would need to have many > >instances of it running at once and to have them interact with one > >another. It is a real time system so the response time, and > >communication between chips are crucial. > > Do you want to: > > 1) simulate the FPGAs on a computer > > 2) emulate the desired functions in actual hardware > > 3) both? > > For (1), you can use virtually any HDL simulator. As Mike suggested, > you have a (top-level) module for each FPGA, and another top-level > module that ties them all together. > > For (2), you build a board with multiple FPGAs, or buy a board; the > Dini Group makes stuff like this. > > I'm not sure what any of this has to do with Xilinx Project Manager. > > Bob Perlman > Cambrian Design WorksArticle: 65110
ALuPin@web.de (ALuPin) wrote in message news:<b8a9a7b0.0401200001.4932f845@posting.google.com>...
> Hi again,
>
> sorry I have made an mistake in my MACRO:
> Now I can execute the MACRO correctly, but nevertheless
> the output of the RAM structure is 'X' in the simulation,
> that is no initialization has be made on the RAM.
>
> Kind regards
> Andres Vazquez
> G & D
> System Development
>
> cd H:/EDA/Altera/USB/Packetfile_Ctrl/simulation/modelsim
> vlib modelsim_work
> vmap work modelsim_work
> vsim TB_CHECK_TRANSFER
> vcom -93 -work work {D:/Programme/QuartusII/eda/sim_lib/220pack.vhd}
> vcom -explicit -work work
> {D:/Programme/QuartusII/eda/sim_lib/220model.vhd}
> vcom -work work {D:/Programme/QuartusII/libraries/vhdl93/altera_mf/altera_mf_components.vhd}
> vcom -93 -work work {D:/Programme/QuartusII/eda/sim_lib/altera_mf.vhd}
> vcom -work work {H:/EDA/Altera/USB/Check_Transfer/CHECK_TRANSFER.vhd}
> vcom -work work {H:/EDA/Altera/USB/Check_Transfer/simulation/modelsim/TB_CHECK_TRANSFER.vhd}
> view signals
> view wave
> vsim work.TB_CHECK_TRANSFER
> run 15000ns
It is difficult to pinpoint the cause without seeing the design and
the vectors. For a start make sure that the input signals(waveforms)
being fed into the memory have the correct timing requirements, and if
there is an enable signal it has been set to the right value. Also if
the memory is being simulated as part of a larger circuit, simulate
the memory as a separate project and verify that ir works before
simulating the whole circuit. Hope this helps.
- Subroto Datta
Altera Corp.
Article: 65111Hello Given two values, compare_value and change_value, is it possible to simultaneously update all values within a fifo that equal compare_value to change_value without having to devote a number of clock cycles proportional to the depth of the fifo? The memory storage need not be a fifo, but that is how it should function when reading and writing to it. Also, a value will only be pulled off the fifo when another values is inserted, thus ensuring that the fifo will always remain full. The simultaneous update of the values will only happen at the time that a new value is inserted. I am currently using an Altera Stratix 1S10, and could take advantage of one or more of its features, but I'm hoping for a solution that is not device dependent. Thanks in advance for any help or suggestions that may lead to a solution to this problem. PatrickArticle: 65112
Jerome wrote: > I have tried to apply your advices, but I still have the some bit > errors on my SDRAM modules. Have you checked the SDRAM modules with an analyzer to see if the error has nothing to do with the FPGA? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 65113
Hello, Yes, you can do this in a single cycle. Is this a homework question? :) You never know these days! Instead of "clock cycles proportional to the depth" you will end up with "hardware proportional to the depth". Also, I think you would have a hard time using any kind of RAM to implement the FIFO. This sounds "expensive"... I prefer the brute force method. You could start by designing a FIFO using standard D flip flops, using the same type of design model that is used with RAMs (circular buffer with two pointers, move the pointers, not the data -- otherwise the problem gets more complicated). You would then add an identity comparator and some muxing logic for each FIFO word. When you present compare_value, the change value, and some kind of enable signal, all words are evaluated concurrently and updated at the next rising edge of the clock. Eric Patrick Klacka wrote: > > Hello > > Given two values, compare_value and change_value, is it possible to > simultaneously update all values within a fifo that equal > compare_value to change_value without having to devote a number of > clock cycles proportional to the depth of the fifo? > > The memory storage need not be a fifo, but that is how it should > function when reading and writing to it. Also, a value will only be > pulled off the fifo when another values is inserted, thus ensuring > that the fifo will always remain full. The simultaneous update of the > values will only happen at the time that a new value is inserted. I am > currently using an Altera Stratix 1S10, and could take advantage of > one or more of its features, but I'm hoping for a solution that is not > device dependent. > > Thanks in advance for any help or suggestions that may lead to a > solution to this problem. > > PatrickArticle: 65114
Tobias Möglich <Tobias.Moeglich@gmx.net> wrote in message news:<400D78FD.DDF392BD@gmx.net>... > Hello > > An application question. > I want to design a Tristate buffer for a data bus. dinb is the input > data port of a BlockRAM > dataDSP is the bus of a DSP controller. > Isn't it possible to create the tristate buffer in the way I quoted at > the bottom of this article ??? > It doesn't work. > What's wrong ?? > > WRITING to BlockRAM > ----------------------------- > > ... > if (cs = '0') then > dinb <= data_DSP; > else > dinb <= (others=>'Z'); > Read the data sheet. Does the target device support internal tristate busses? -aArticle: 65115
Peter Alfke <peter@xilinx.com> writes: > If any device misses one test, it gets scrapped. > That's the way we do it at Xilinx, Really? It doesn't get used for an EasyPath design? It thought the point of EasyPath was that you could sell devices that don't pass full functional test.Article: 65116
Patrick Klacka wrote: > > Given two values, compare_value and change_value, is it possible to > simultaneously update all values within a fifo that equal > compare_value to change_value without having to devote a number of > clock cycles proportional to the depth of the fifo? Save some sort of CRC hash with each value push. Apply correction(hash) when a value is popped. > The memory storage need not be a fifo, but that is how it should > function when reading and writing to it. Also, a value will only be > pulled off the fifo when another values is inserted, thus ensuring > that the fifo will always remain full. That would mean only the first fifo location is ever used. Maybe you mean a two port buffer. -- Mike TreselerArticle: 65117
Rene Tschaggelar <none@none.none> wrote in message news:<22121bd70e95748cc78f4729260a05bb@news.teranews.com>... > > have a look at http://www.ebv.com for the Altera parts. Thanks for the address. I've called them: same problem as with "Spoerle" 1. They only sell to companies, not to private persons. 2. Their minimum package quantity is in general 30-90. But I don't want to order some 50 FPGAs, 10$ each. Is it impossible to buy a single altera FPGA chip without founding a company?? PatrickArticle: 65118
Patrick, you seem to be describing a Content-Addressable Memory ( a CAM), which is notoriously difficult to implement and inefficient, especially when it is to operate at a high rate. Think about how you can (or cannot) compare and modify the content of multiple locations simultaneously... Peter Alfke, Xilinx Applications ============================== Patrick Klacka wrote: > > Hello > > Given two values, compare_value and change_value, is it possible to > simultaneously update all values within a fifo that equal > compare_value to change_value without having to devote a number of > clock cycles proportional to the depth of the fifo? > > The memory storage need not be a fifo, but that is how it should > function when reading and writing to it. Also, a value will only be > pulled off the fifo when another values is inserted, thus ensuring > that the fifo will always remain full. The simultaneous update of the > values will only happen at the time that a new value is inserted. I am > currently using an Altera Stratix 1S10, and could take advantage of > one or more of its features, but I'm hoping for a solution that is not > device dependent. > > Thanks in advance for any help or suggestions that may lead to a > solution to this problem. > > PatrickArticle: 65119
"Kelvin @ SG" wrote: > Try out these few constraints, I don't understand NGDBuild allows space in > the LOC while not in the signal name. Try this: NET "out_sig" LOC = " B 2 "; -- Phil HaysArticle: 65120
Tobias, I suggest you step back figure out what you really want to achieve. A tristate bus is just one particular method to multiplex data onto lines. You can do that with a multiplexer, the way most designers do it. Xilinx used to have real 3-state lines, but we have converted them to multiplexers, even when the software still "thinks" it is generating 3-state lines. 3-state lines are just a tool to achieve something, and not the best tool nowadays, when speed counts. Multiplexers achieve the same result, and are faster and offer better control. Peter Alfke, Xilinx Applications ================== Tobias Möglich wrote: > > Hello > > An application question. > I want to design a Tristate buffer for a data bus. dinb is the input > data port of a BlockRAM > dataDSP is the bus of a DSP controller. > Isn't it possible to create the tristate buffer in the way I quoted at > the bottom of this article ??? > It doesn't work. > What's wrong ?? > > WRITING to BlockRAM > ----------------------------- > > ... > if (cs = '0') then > dinb <= data_DSP; > else > dinb <= (others=>'Z'); > > Thanks for any help. > > Tobias MöglichArticle: 65121
Offset constraints have been around for a while, not new. Anyway, if you
register
your I/O at the IOB, then the offset constraint isn't going to do anything for
you except
tell you when a flip-flop got pushed out of the IOB or that you set the drive
strength/slew
rate wrong.
SDRAM can be tricky, especially if you don't have external terminations.
Higher slew
rates and drive strengths can result in some nasty reflections that will sink
even the most
carefully executed FPGA design. Use the minimum drive strength consistent with
your
timing analysis. If possible use external terminations on the lines to the
SDRAM (you can
use DCI, but I've found that in addition to pushing the limits on package power
dissipation,
it is also slows the I/O down too much for SDRAM, especially without doing
stuff with the
DCM).
PO Laprise wrote:
> Once you've "pen and papered" your timing as Peter suggests, you might
> want to look into the "OFFSET OUT" constraint in the constraint guide.
> This allows you to give minimum "clock to off-chip" delays. The router
> will then take into account clock skew AND pad delays. To constrain
> your inputs, use the "OFFSET IN" constraint. If your delays are already
> minimal, it may not help, but at least you'll know. Of course, you
> still have to take all board delays into account yourself, which is why
> it's important to pen-and-paper first.
>
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 65122at Tue, 20 Jan 2004 18:58:56 GMT in <400D7A70.4090108@flukenetworks.com>, mike.treseler@flukenetworks.com (Mike Treseler) wrote : >Alex Rast wrote: > >>>>interfaces? I'm quite surprised that there aren't more >>>>testing/prototype systems available for these kinds of hardware, >>>>which must surely be extremely common. >>>> >>>One reason may be that simulation is commonly used >>>for design verification of synchronous logic. >>> >> That's a nice thought, but sooner or later, simulation must give way >> to actual testing. ... Simulation is an >> important and valuable first step, but IMHO it would take a rather >> credulous engineer to put his entire trust in the siumulation results. > >Of course the hardware functions and embedded firmware must >be somehow tested during alpha and beta production. > >The question you asked is why few vendors cover this >requirement and I believe that design verification >using simulation and the high quality of pcb fabrication >is part of the reason. I see a major weakness in relying on this approach : namely, that it assumes there should be no significant discrepancies between the understanding you have after reading data sheets, manuals, etc. as to how specific pieces of hardware and software work, and how they *actually* work. Many components have all sorts of undocumented idiosyncracies that place constraints on how you use them, and most software has both such idiosyncracies and bugs. If you made your design assuming a certain part would work in a certain way, or with certain timings, voltages, etc., and in fact it actually doesn't, although there would have been no way for you to know this in advance through the documentation that was available, you can easily end up with a board that doesn't work in spite of it passing simulation. PCB fab may be high reliability these days, but I think the kinds of problems you're trying to iron out in testing are the design flaws that you wouldn't have been able to catch ahead of time. These are not things that PCB fab has much to do with because the layout houses and the board fabricators are simply going to follow your schematic. >I used to work for a start-up company named Summmation >that made a modular test system that did just what what >you are asking for. Nobody bought it. > >The reason was that by the time our development was >complete, the quality of circuit boards and digital >components had improved much more than we expected. It sounds as if your system was designed mostly to catch actual hardware errors that crop up because of manufacturing defects, not those that happen because your design wouldn't have worked as it was, through no fault of your own. Is this the case? Notwithstanding, I would also be prepared to believe that many modern engineers *are* willing to put the kind of blind trust in their designs to assume that the kinds of problems I'm talking about aren't going to happen. >Testing moved up to standard interfaces like >ethernet, PCI, usb, rs232 etc. Most of the high-speed, standard interfaces are themselves complex, with numerous subtleties as well as requirements which mean that there's a considerable likelihood that if your system has one of these interfaces, it may not work out of the gate on your first revision unless you were lucky and managed to do everything perfect. I like standard interfaces, especially during later-stage testing when the low-level details of your board are debugged, but in the early stages of testing, you can be going around in circles because the standard interface isn't working, perhaps because of some obscure, undocumented behaviour of one of the components in your design. In addition, these interfaces take time to design and may require complex drivers. The net result is that it can take months to get to a point where you're able to test anything at all. I think my central point is : It would be nice to assume your design is perfect, and will work flawlessly, but in the real world, no engineer knows everything, and it's more likely it won't work at first. You're going to have to get some data about how the hardware *really* works, then refine your design. This is where I see a gap in available testing devices. -- Alex Rast ad.rast.7@nwnotlink.NOSPAM.com (remove d., .7, not, and .NOSPAM to reply)Article: 65123
You might want to look at www.digilentinc.com They have several boards under $150.00 and they're all supported by Webpack Anna x86asm wrote: > Hi guys, I was wondering if there were any good starter kits you know of > and where I am able to purchase them, I want to dip into VHDL a bit and > try out my creations on a FPGA, nothing too fancy as I'm no engineer, > just a hobbyist :) I saw one on Xilinx's online store for ~$50 US is > that a good choice?Article: 65124
Eric's statement is correct. When we have a customer who has a "frozen" design, and wants to buy large quantities of FPGAs at a significantly lower price, we create a program that compares the error file with that customer's specific design, and, if the failure does not affect that user's design in any way, the part gets specially marked and sold into that application. That's called EasyPath, since it offers an easy path to lower cost, without any timing differences nor the need to re-verify the design ( as was required by the now obsolete old Xilinx Hardwire and also by the not-so-old Altera alternative, two methods that really change the chip completely and offer a "functional alternative" with the possibility of nasty timing surprises ). I did not mention this, becauseEasyPath is a special case, and a fairly new development. All these "cheap" variations make the FPGA non-reconfigurable and must, therefore, be described as special cases ... Peter Alfke, Xilinx Applications =========================== Eric Smith wrote: > > Peter Alfke <peter@xilinx.com> writes: > > If any device misses one test, it gets scrapped. > > That's the way we do it at Xilinx, > > Really? It doesn't get used for an EasyPath design? It thought the > point of EasyPath was that you could sell devices that don't pass full > functional test.
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