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
Jacob W Janovetz wrote:
>
> "Mark Purcell" <map@NOSPAM_transtech-DSP.com> writes:
>
> >Try using the STD_LOGIC_UNSIGNED library, this has '+' function defined for
>
> >std_logic_vectors (Also, you should remove the quotes from the "1" I
> >think...)
>
> Actually, the quotes stay. ("1" is can be a STD_LOGIC_VECTOR of
> length 1, '1' is just a STD_LOGIC or bit)... The operator will
> automatically extend the shorter vector).
>
> Cheers,
> Jake
This depends on the compiler. I ported some code from Orcad to Metamor
and had to change all single element vector constants to single element
constants (i.e. "1" to '1').
--
Rick Collins
rickman@XYwriteme.com
remove the XY to email me.
Article: 11326
"Mark Purcell" <map@NOSPAM_transtech-DSP.com> wrote:
>Does anyone know of a portable way to converting a std_logic_vector to
>an integer value (such as the v1d2int function in Viewlogic) so that it may
>be used in a comparison? A little off-topic I know, but I'm trying to
>evaluate some FPGA synthesis tools with a large VHDL file.
>Thanks in advance,
>Mark Purcell
>Remove NOSPAM_ from email address.
FYI - Here's some code that I use for that. The inspiration came from
Richard Schwartz:
Wade Peterson
Silicore Corporation
----------------------------------------------------------------------
-- Module name: INTRCONV.VHD
--
-- Description: Package converts INTEGER to STD_LOGIC_VECTOR and
-- vice-versa.
--
-- History: Project complete: APR 28, 1998 WD Peterson
--
----------------------------------------------------------------------
----------------------------------------------------------------------
-- Load the IEEE 1164 library and make it visible.
----------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
----------------------------------------------------------------------
-- Package declaration.
----------------------------------------------------------------------
package SLV2INTPAK is
function SLVECT2INT( VECT: std_logic_vector; SIZE: integer )
return integer;
function INT2SLVECT( INT_VALUE: integer; SIZE: integer )
return std_logic_vector;
end SLV2INTPAK;
----------------------------------------------------------------------
-- Package definition.
----------------------------------------------------------------------
package body SLV2INTPAK is
------------------------------------------------------------------
-- Standard_logic_vector to integer conversion.
------------------------------------------------------------------
function SLVECT2INT( VECT: std_logic_vector; SIZE: integer )
return integer is
variable RESULT: integer range ((2**size)-1) downto 0 ;
begin
RESULT := 0;
for i in 0 to (SIZE-1) loop
if( VECT(i) = '1' ) then
RESULT := RESULT + 2**i;
end if;
end loop;
return RESULT;
end SLVECT2INT;
------------------------------------------------------------------
-- Integer to standard_logic_vector conversion.
------------------------------------------------------------------
function INT2SLVECT( INT_VALUE: integer; SIZE: integer )
return std_logic_vector is
variable RESULT: std_logic_vector( (size-1) downto 0 );
begin
for i in 0 to (SIZE-1) loop
if( ((INT_VALUE/(2**i)) rem 2) = 0 ) then
RESULT( i ) := '0';
else
RESULT( i ) := '1';
end if;
end loop;
return RESULT;
end INT2SLVECT;
end SLV2INTPAK;
-----------------------------------------------------
Wade D. Peterson | TEL: 612.722.3815 FAX 5841
Silicore Corporation |-------- INTERNET ---------
3525 E. 27th St. No. 301 | http://www.silicore.net
Minneapolis, MN 55406 | peter299@maroon.tc.umn.edu
---------------- Committed to Quality ---------------
Article: 11327I'm looking for some documentation (vhdl-code) about "multi-stage" or serial (8 bit x 8 bit) multiplyer. I have to implement a 8x8-multiplyer in an FPGA with clk-frequency of 40MHZ. Thanks Anton. __________________________________________________________________ Anton Scherer MICROSWISS-Center Aargau Steinackerstrasse 5 CH-5210 Windisch Switzerland phone : ++41-56-462-46-11 fax : ++41-56-462-46-15 email : mailto://a.scherer@fh-aargau.ch www : http://www.microswissag.ch ___________________________________________________________________Article: 11328
Vantis has recently released a -5 speed grade for the lower density M5 devices (M5-128, 192, and 256). These devices will do 200MHz bi-phase clocking will no feedback. Scott On Tue, 4 Aug 1998 06:11:13 +0900, "Park, DongHwan" <limelite@soback.kornet21.net> wrote: >Hello... > >(Please excuse my English...) > > I'm developing high speed analog-to-digital >converter board using Rambus DRAM(RDRAM) as >data storage device. I'm planning to use fast >CPLD or FPGA for RDRAM controller. One problem >is that the device used as RDRAM controller >must operates on both rising and falling edge >of clock signal(dual-edge clocking or bi-phase >clocking), because RDRAM operates so. > Mach5 devices from Vantis support dual-edge >clocking but their maximum operating frequency >is 125MHz(I need at least 200MHz). > > Please help me to find out adequate device >for RDRAM control, high speed CPLD or FPGA >supporting dual-edge clocking, or ASIC chips >already made for RDRAM control, any device >will do... > > Thanks in advance... Be a nice day... > >- limelite - > > >Article: 11329
> > "Austin Franklin" <darkroo5m@ix.netcom.com> wrote: > > >Wade D. Peterson <peter299@maroon.tc.umn.edu> wrote in article > ><6p8nqs$2ij$1@news1.tc.umn.edu>... > >> Silicore Corporation now has a VHDL 8-bit RISC uC core for FPGA > >> available. The processor is compatible with the industry standard > >> 'PIC' processors. For more information see <www.silicore.net>. > > >$10,000 for a PIC processor that takes up 80% of an OR2CA15-4 FPGA? It > >would seem more prudent to buy a far less expensive exteral PIC processor Ø >and a smaller/cheaper FPGA to do the same job. Ø I just finished a C54 binary compatible core in an Actel FPGA and I can tell you it is very simple and very small. Although I did not implement any peripherals with the exception of the parallel I/O port the whole design synthesis to a mere 590 modules of an Actel 1460 FPGA (69%). Also I only have 16 registers. Using a 3200DX or the throbbing 54SX family will make an interesting project! The nice thing about the PIC is not only that it is simple to implement in hardware it has a very good free available software suite. This will make the validation process a lot easier. > > >Does anyone else think this is a real step backwards? Not really in a lot of application you want to develop your own core, in my case I added coding to protect against radiation induced errors. HansArticle: 11330
Simon, My opinions are worth what you paid for them !! You will need pci drivers. After checking out every software driver commercially available, I've found www.tetradyne.com to be the easiest and most straightforward. If you're target is 5.0V PCI (desktop) then stay away from Altera. If you're target is 3.3V PCI then one of Altera's AMPP partners has the easiest to use PCI core around. Check out www.plda.com. This core is a whole lot easier to use than the one you will purchase from Altera. Quicklogic offers a free PCI core, but it is absolutely the hardest to use core you will ever find. Don't waste your time. I have however successfully designed my own pci design and have it work with quicklogic But it doesn't sound like you want to start from scratch. Xilinx offers both 5.0V PCI & 3.3V PCI devices. They also offer a pci core that is already in layout for each device. You cannot change the pinout. The target core is pretty straightforward, but their master core was designed with a goal to put more control signals than there are transistors in a Pentium. I know Lucent has a pci core, but I have just not found their technology to be as fast as Xilinx. So I can't comment further. ACtel has cores available, but I find their technology to be slow Al Simon Ramirez wrote: > > To the Newgroup: > I am doing a board level design that uses four FPGAs, two of which > implement PCI interfaces. I am still doing the block diagram of the whole > board and have not started my FPGA designs yet. > In order to expedite my designs, I have decided to look into PCI cores > from various vendors, including the FPGA vendors themselves. They all claim > that their designs are the best and that the competitors' designs have flaws > in either the cores or the silicon. I attribute most of the bad-mouthing to > just plain and simple sales hype, since I have asked some of the FAEs/Sales > Reps for proof to back up their bad-mouthing claims about the competitors, > and none of them can come up with any. > I am favoring cores from FPGA vendors as oppsed to non-aligned vendors > for several reasons, which I won't get into here but will if you ask. I > also favor VHDL and Verilog based designs, although I will not exclude > schematic based or mixed designs if there are good reasons to pick such a > design. > But I am wondering if any of you have had any experience, good and/or bad > with PCI Initiator and Target cores (and silicon) from any of the FPGA > vendors. If you have, please respond back to this group or better yet, > respond back to me personally at: > Simon Ramirez > Consultant/Contractor > 770-752-5109 > simon.ramirez@l-3com.com (work) > s_ramirez@msn.com (home) > Thank you very much. > -SimonArticle: 11331
I'm considering moving some of my boards to the PCI interface. Can you recommend a PCI interface chip to do simple IO. My application is little more than a DIO board with interrupts. > Have you considered using any of the off the shelf PCI interfaces? They > are vastly cheaper, and much faster to implement...Article: 11332
On 4 Aug 1998 14:44:05 GMT, "Mark Purcell" <map@NOSPAM_transtech-DSP.com> wrote: >Thanks, I'll have a good look there. I don't know if you wrote this before or after Dave Farrance's answer, but you shouldn't (for synthesis) be rolling your own solution. The IEEE's 'to_integer' (in numeric_std) or Synopsys's 'conv_integer' (std_logic_arith) are the most portable solutions. If you look in numeric_std (which you'll certainly have somewhere) you'll find a formal definition of how 'to_integer' should be written. However, these are built-in functions, and if you write your own, you run the risk that the synthesiser may not implement your own equivalent efficiently. EvanArticle: 11333
On Sun, 26 Jul 1998 02:10:51 GMT, Eddie Ng <ngeddie@tor.shaw.wave.ca> wrote: >Dear All, > I'm using Altera FLEX 10K series FPGA right now and I need to >implement an delay element that would do ideally pure delay or >not-too-bad inertial delay. Much like a series of even-numbered >inverters in series to introduce propagation delay but with accurate >delay time, preferrably "programmable" or "parameterizable". > I'm using it to implement an asynchronous micropipeline structure in >which delay is added on the control signals to match/exceed the delay on >the bundled data lines to meet the bundled contrains. I love these threads - it always gives somebody the opportunity to tell you that asynchronous design is impossible and shouldn't be done.. :) I've been looking through the literature on FPGA micropipelines recently, but I haven't yet found any useful discussion on delay elements (apart from the obvious - ie. FPGAs aren't the right way to go, and delays are very difficult). Given that you have to use an FPGA, your only option appears to be to guess minimum delays. Presumably you already know how to do this but, if you don't, Xilinx's (don't know about Altera's) official guesstimate (IIRC) goes as follows: (1) take maximum delay in *the fastest available* part in your technology (in case the manufacturer has shipped you fast parts to fill a slow part order) (2) subtract 10% for tester calibration (3) subtract 10% for VCC variation (4) subtract 30% for temperature variation (5) subtract 40% for process variation This gives you a best-case delay of 34% of the worst-case delay, ie. a spread of 3-1 if you're actually using the fastest part, and considerably worse if you're using a slow part. It also ignores routing delays (you may end up placing by hand, to keep routing delays at a small percentage of logic delays). But, of course, these figures give you a die-to-die variation, and your design is on a single die. You can therefore, more-or-less, ignore these figures. In your position, I would be inclined to start with a guess that delay spread on a single die (whatever the process variation happens to be) is only about 20% total, and then to test your resulting design over VCC and temperature, until you have something that works over a number of different devices, modifying your initial guess as you go. If you get a failure, you simply increase the length of your delay chains until it works. You could parameterise the delay length in, for example, a VHDL generate, but this will have an obvious impact on your ability to do hand-placement. Obviously, nobody's going to guarantee any of this, but it's probably good enough for academic work :) (at least until the next die shrink...) The next problem is that the delay variation directly impacts your achievable speed. However, an on-die variation of 20% might allow you to run fairly close to maximum speed, whereas if you use the 'official' die-to-die variation then you could run at 20% or less of maximum speed. But there is another solution, which is *much* better. Your work is obviously only a testbench, which will require custom silicon to reach its full potential. Nobody's going to expect you to correctly implement a delay element in an FPGA, so why don't you have a black-box delay, which is *clocked*? You have a high-speed external clock doing your delays for you. This allows you to concentrate on the real problems, and not on generating accurate delays, which is an (admittedly very complex) silicon implementation detail. Good luck - and if you have any interesting results don't forget to post them here (or you can mail me minus the 'nospam') - EvanArticle: 11334
The synthesis part of this was a worry. I'm now using the CONV_INTEGER function without problems that I'm aware of, but I'll have a look at the IEEE 'to_integer' function too. Thanks. Mark. Remove NOSPAM_ from email address. ems <ems@nospam.riverside-machines.com> wrote in article <35c834c0.93649756@news.dial.pipex.com>... > On 4 Aug 1998 14:44:05 GMT, "Mark Purcell" > <map@NOSPAM_transtech-DSP.com> wrote: > > >Thanks, I'll have a good look there. > > I don't know if you wrote this before or after Dave Farrance's answer, > but you shouldn't (for synthesis) be rolling your own solution. The > IEEE's 'to_integer' (in numeric_std) or Synopsys's 'conv_integer' > (std_logic_arith) are the most portable solutions. If you look in > numeric_std (which you'll certainly have somewhere) you'll find a > formal definition of how 'to_integer' should be written. However, > these are built-in functions, and if you write your own, you run the > risk that the synthesiser may not implement your own equivalent > efficiently. > > Evan > >Article: 11335
nospam_ees1ht@ee.surrey.ac.uk (Hans) wrote: >Not really in a lot of application you want to develop your own core, in my >case I added coding to protect against radiation induced errors. >Hans I'd like to hear more about coding to protect against radiation induced errors. Could you elaborate on that? Is this a redundancy thing? Wade Peterson Silicore Corporation, www.silicore.netArticle: 11336
Thanks. I have tried this type of approach, but I think the synthesis part may have trouble, and my compiler didn't like it much either! I've recently started to use CONV_INTEGER to do this and so far it seems OK. Regards, Mark. Remove NOSPAM_ from email address. Wade D. Peterson <peter299@maroon.tc.umn.edu> wrote in article <6q8k4i$nqm$1@news1.tc.umn.edu>... >---------------------------------------------------------------------- >-- Module name: INTRCONV.VHD >-- >-- Description: Package converts INTEGER to STD_LOGIC_VECTOR and >-- vice-versa. >-- >-- History: Project complete: APR 28, 1998 WD Peterson >-- >---------------------------------------------------------------------- <snipped for brevity>Article: 11337
Andy Peters wrote: > But motors also require amplifiers and drivers and other thing beyond > the FPGA, which I agree is the relatively easy part. Many of the purpose-built controllers require a separate driver too, especially for bigger motors. > The other issues regarding motors includes acceleration/deceleration > curves, increasing motor speed and going through resonances (which > could cause the motor to stall), dealing with stalling and > overtorquing, microstepping, power control so you can shut off the > high voltage and maintain position and not waste power, and so forth. Exactly why I said one should have a background in motion control before attempting to do his own design. The electromechanical pitfalls are many! However, if one understands these, the digital implementation of the controller is not all that difficult as far as digital design goes. > I thought controlling motors was *really* easy, until the local > mechanical engineer disabused me of that notion. See, those mechies are still worth a little something! -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 11338
Scherer Anton wrote: > I'm looking for some documentation (vhdl-code) about "multi-stage" or > serial (8 bit x 8 bit) multiplyer. > I have to implement a 8x8-multiplyer in an FPGA with clk-frequency of > 40MHZ. > Eventually I'll have a tutorial about multiplying in FPGAs on my website. Unfortunately, I can't point you to that yet. If you just need to use a multiplier and you don't really care how it works, use the multipliers in the FPGA vendor's library (for xilinx you will need to pick up the core generator, which is free for the asking). Most of the major FPGA vendors have 8x8 multipliers available as optimized macros or cores in signed and unsigned flavors. These cores can be instantiated in your VHDL code. Since these are generally relatively placed, and are always optimized for the FPGA architecture, you will get better performance and density out of these than out of generic VHDL code.-- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 11339
In article <6q9lol$q2c$1@news1.tc.umn.edu>, peter299@maroon.tc.umn.edu says... > >nospam_ees1ht@ee.surrey.ac.uk (Hans) wrote: > >>Not really in a lot of application you want to develop your own core, in my >>case I added coding to protect against radiation induced errors. >>Hans > >I'd like to hear more about coding to protect against radiation >induced errors. Could you elaborate on that? Is this a redundancy >thing? Correct, it is very simple, in my case I changed each FF to three FF with a majority voting system on the output. Thus if any FF is changed due to radiation effects (e.g. heavy protons) the majority voting system will output the correct value (majority is always right??). The possibility of two FF being hit at the same time or before the FF is used is relative small. Adding these extra two FF is done automatically by most synthesis tools (Actel, Synplicity, Synopsys). I am also adding a simple Hamming FEC code to the code memory, because I need 5 parity bits for this scheme I had to steal 1 bit from the 12 bits instruction word. For this I used the highest register bits (since I only have 16 registers anyway) and remapped the literal/control operations to 3 bits, all this because I want to fit the code in either a 16 bits or two 8 bits EEPROMS (easier to make a testboard :-)). Hans. > >Wade Peterson >Silicore Corporation, www.silicore.net >Article: 11340
FPGA `99: Call for Papers
Seventh ACM International Symposium on
Field-Programmable Gate Arrays
DoubleTree Hotel, Monterey, California
February 21-23, 1999
As we reach the end of the 1990s, rapidly increasing speed and capacity have
made FPGAs a standard implementation target for digital logic. Advancements
in FPGA architectures proceeds unabated, and larger, faster devices enable
new, innovative applications that continue to stress designers and
their tools. For FPGA `99, we are soliciting submissions describing novel
research and development in the following (and related) areas of interest:
FPGA Architecture: Logic block & routing architectures, I/O structures and
circuits, new commercial architectures, Field-Programmable Interconnect
Chips and Devices (FPIC/FPID), Field-Programmable Analog Arrays (FPAA).
CAD for FPGAs: Placement, routing, logic optimization, technology mapping,
system-level partitioning, logic generators, testing and verification.
CAD for FPGA-based accelerators.
Interactions: between CAD, architecture, applications, and programming
technology.
Applications: Innovative use of FPGAs, exploitation of FPGA features,
novel circuits, high-performance and low-power/mission-critical
applications, DSP techniques, uses of reconfiguration, FPGA-based cores.
FPGA-based computing engines: Compiled accelerators, reconfigurable
computing, adaptive computing devices, systems and software.
Fast prototyping for system level design, Multi-Chip Modules (MCMs), logic
emulation.
Authors are invited to submit PDF (preferred) or postscript of their paper
(12 pages maximum) by October 2, 1998 via E-mail to fpga99@xilinx.com.
Alternatively, authors may submit a 3.5" floppy disk containing the pdf
or postscript file or 22 copies of their paper to the program chair.
Notification of acceptance will be sent by December 1, 1998. The authors of
the accepted papers will be required to submit the final camera-ready copy by
December 15, 1998. A proceedings of the accepted papers will be published by
ACM, and included in the Annual ACM/SIGDA CD-ROM Compendium publication.
Address questions to:
Steve Trimberger
Program Chair, FPGA `99
Xilinx, Inc.
2100 Logic Dr.
San Jose, CA 95124-3450 USA
phone: (408) 879-5061
fax: (408) 559-7114
fpga99@xilinx.com
General Chair: Sinan Kaptanoglu, Actel
Finance Chair: Jason Cong, UCLA
Program Chair: Steve Trimberger, Xilinx
Publicity Chair: Scott Hauck, Northwestern U.
Program Committee
Om Agrawal, Vantis Ray Andraka, Andraka Consulting
Michael Butts, Quickturn Jason Cong, UCLA
Eugene Ding, Lucent Carl Ebeling, U. of Washington
Scott Hauck, Northwestern U. Brad Hutchings, BYU
Sinan Kaptanoglu, Actel David Lewis, U. of Toronto
Fabrizio Lombardi, Texas A&M Wayne Luk, Imperial College
Margaret Marek-Sadowska, UCSB Peter Moceyunas, Synopsys
Jonathan Rose, U. of Toronto Gabriele Saucier, INPG
Martine Schlag, UCSC Herman Schmit, CMU
Tim Southgate, Altera Steve Trimberger, Xilinx
John Wawrzynek, UCB Martin Wong, UT at Austin
Sponsored by ACM SIGDA, with support from Xilinx, Altera, Lucent and Actel.
Please visit <http://www.ece.nwu.edu/~hauck/fpga99> for more information.
Article: 11341> You will need pci drivers. After checking out every software driver > commercially available, I've found www.tetradyne.com to be the easiest > and most straightforward. Wouldn't you need O/S drivers? There is nothing specific about a PCI driver over any other device (ISA, EISA etc) driver, except you need to get the boards address from the O/S or the BIOS... I'm curious why you call it PCI driver... Thanks, AustinArticle: 11342
Philip Freidin <fliptron@netcom.com> wrote in article <fliptronEx2xFw.B35@netcom.com>... > In article <01bdbe2a$97d9d020$31cab7c7@drt3> "Austin Franklin" <dark9room@ix.netcom.com> writes: > > ... stuff on floorplanning I/O removed ... > > > >Geeze, and it just so happens, I do this exact service for many of my > >clients (floorplanning and I/O pin placement/locking), so if interested in > >soliciting some outside help, please feel free to e-mail me. (Does this > >constitute a commercal announcement ;-) > >Austin Franklin > >darkroom@ix.netcom.com > > Sure does :-) > > You could have saved your self this flame by giving a pointer to > www.fliptronics.com/fp1.html which talks about logic floorplanning, and > makes no reference to the current topic of I/O floorplanning. > > Having fun ... > Next time, I'll give you equal billing in my 'advertising' ;-)Article: 11343
http://myweb.vector.ch/olwagner/Article: 11344
What do you know about using the XC4000XL IOB delay element as a pure delay element. Its not *directly* accessible, but I suppose you could program the IOB as a latch and keep the clock active. What is the range of the delay in ns. over various parts? Is this really supported? Anyone have any experience with this? Bruce NeppleArticle: 11345
>>I'd like to hear more about coding to protect against radiation >>induced errors. Could you elaborate on that? Is this a redundancy >>thing? >Correct, it is very simple, in my case I changed each FF to three FF with a >majority voting system on the output. Thus if any FF is changed due to >radiation effects (e.g. heavy protons) the majority voting system will output >the correct value (majority is always right??). The possibility of two FF being >hit at the same time or before the FF is used is relative small. Adding these >extra two FF is done automatically by most synthesis tools (Actel, Synplicity, >Synopsys). That's pretty clever. Never heard of that before. Any idea what they call that technique? I looked in my synthesis package manual, but didn't see anything. >I am also adding a simple Hamming FEC code to the code memory, >because I need 5 parity bits for this scheme I had to steal 1 bit from the 12 >bits instruction word. For this I used the highest register bits (since I only >have 16 registers anyway) and remapped the literal/control operations to 3 >bits, all this because I want to fit the code in either a 16 bits or two 8 bits >EEPROMS (easier to make a testboard :-)). > Hans Do you use external EEPROMS? Any reason why you didn't stick those into the FPGA? Wade Peterson Silicore Corporation www.silicore.netArticle: 11346
Austin, You're right !! Technically it is a O/S driver. I called it pci for there are utilities set to specifically target the pci bus. I like to stay away from any Microsoft DDK and avoid the ring 3 to ring 0 transition every time I want to access the pci bus. If you know how to write your own VxD or Kernel Mode driver... then you probably don't need to purchase a set of utilities. If you use the DDK from Microsoft you will have to context switch every time you call your driver. Al Austin Franklin wrote: > > > You will need pci drivers. After checking out every software driver > > commercially available, I've found www.tetradyne.com to be the easiest > > and most straightforward. > > Wouldn't you need O/S drivers? There is nothing specific about a PCI > driver over any other device (ISA, EISA etc) driver, except you need to get > the boards address from the O/S or the BIOS... I'm curious why you call it > PCI driver... > > Thanks, > > AustinArticle: 11347
Austin, You're right !! Technically it is a O/S driver. I called it pci for there are utilities set to specifically target the pci bus. I like to stay away from any Microsoft DDK and avoid the ring 3 to ring 0 transition every time I want to access the pci bus. If you know how to write your own VxD or Kernel Mode driver... then you probably don't need to purchase a set of utilities. If you use the DDK from Microsoft you will have to context switch every time you call your driver. Al Austin Franklin wrote: > > > You will need pci drivers. After checking out every software driver > > commercially available, I've found www.tetradyne.com to be the easiest > > and most straightforward. > > Wouldn't you need O/S drivers? There is nothing specific about a PCI > driver over any other device (ISA, EISA etc) driver, except you need to get > the boards address from the O/S or the BIOS... I'm curious why you call it > PCI driver... > > Thanks, > > AustinArticle: 11348
Austin, You're right !! Technically it is a O/S driver. I called it pci for there are utilities set to specifically target the pci bus. I like to stay away from any Microsoft DDK and avoid the ring 3 to ring 0 transition every time I want to access the pci bus. If you know how to write your own VxD or Kernel Mode driver... then you probably don't need to purchase a set of utilities. If you use the DDK from Microsoft you will have to context switch every time you call your driver. Al Austin Franklin wrote: > > > You will need pci drivers. After checking out every software driver > > commercially available, I've found www.tetradyne.com to be the easiest > > and most straightforward. > > Wouldn't you need O/S drivers? There is nothing specific about a PCI > driver over any other device (ISA, EISA etc) driver, except you need to get > the boards address from the O/S or the BIOS... I'm curious why you call it > PCI driver... > > Thanks, > > AustinArticle: 11349
Austin, You're right !! Technically it is a O/S driver. I called it pci for there are utilities set to specifically target the pci bus. I like to stay away from any Microsoft DDK and avoid the ring 3 to ring 0 transition every time I want to access the pci bus. If you know how to write your own VxD or Kernel Mode driver... then you probably don't need to purchase a set of utilities. If you use the DDK from Microsoft you will have to context switch every time you call your driver. Al Austin Franklin wrote: > > > You will need pci drivers. After checking out every software driver > > commercially available, I've found www.tetradyne.com to be the easiest > > and most straightforward. > > Wouldn't you need O/S drivers? There is nothing specific about a PCI > driver over any other device (ISA, EISA etc) driver, except you need to get > the boards address from the O/S or the BIOS... I'm curious why you call it > PCI driver... > > Thanks, > > Austin
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