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
Eric Ryherd <"vauto@tiac.net"@tiac.net> wrote in article <6q7ef1$av1@news-central.tiac.net>... > > However, I recommend using VAutomations V8-microRISC CPU Er, Eric, are you at all affiliated with VAutomation in any way that you would 'recommend' your...oops, their ;-) product over any other?Article: 11376
Evan, I'm sure you know what you talking about. But I guarantee you that graphics chip vendors are avoiding any & all ring3/ring0 transitions. I've worked at enough. All drivers written by the chip vendor are memory mapped in chipset (BX, LX, Triton,....etc). The OS is not even involved in determining whether to transfer the info to main memory or onto the PCI bus. Alternatively, you could use the DDK from Microsoft and have the OS determine whether to access the pci bus. With all that said, the graphics chip will do most of the transferring anyway by mastering the pci bus and reading the data from main memory. The goal is to get the request command to the graphics chip ASAP. The fastest way to do this is to get the OS out of the way. All the above applies to 3d graphics. AS I think about it, you could very well have the OS involved in 2d graphics. Most applications will not have speed issues with 2d graphics so the having the OS performing virtual addressing onto the pci bus will not be a big deal. In 3d, you are moving vast amounts of data (polygons & textures) where any latency will slow down the 3d rendering. If you still disagree....I've not doubt you know what you are talking about. I really can't say anymore so I won't respond further on this. Besides, we are getting out of the realm of this newsgroup. All the Best !! Al ems wrote: > > On Thu, 06 Aug 1998 09:05:29 -0700, alz <alz@lanminds.com> wrote: > > >> i can't think of any specific ring 3/ring 0 transitions which have a > >> significant (or any) impact on a user. however, there are issues > >> related to scheduling information transfers between the driver and the > >> user (at interrupt time, for example). > > > > > >For computer graphics the ring3/ring0 transition is significant. Every > >graphics chip company around avoids ring3/ring0 transitions in their > >drivers. > > it doesn't matter what sort of chip or board you're putting on the > bus. the vast majority of windows pci drivers will not require the use > of signalling mechanisms, which would involve ring0/ring3 transitions, > between the driver and the user. > > the only point in most drivers, after initialisation, at which a > transition occurs, is when a hardware interrupt arrives (and the S3 > card in my test system doesn't even generate interrupts). your ring 0 > driver will receive control fairly quickly, and will then schedule > some sort of information transfer to the user code. this will involve > another transition, but this is part of the normal scheduling > mechanisms and so isn't relevant. in short, ring0/ring3 transitions > simply aren't relevent, whether or not you're using interrupts. > > what you're thinking about may be the issue of virtualising the PC > display. there are circumstances in which the OS will create multiple > virtual copies of physical display memory, and will then trap any > accesses to this memory, so that display drivers can pretend that they > have exclusive control over the display. this isn't an issue with pci > drivers, and you still need the ddk, or an equivalent, to write your > pci driver. > > evanArticle: 11377
Rickman wrote: > One source of variation that you left out is changes (over the > lifetime > of a part) in the detail design and techology of a part. Xilinx > published an app note on this and indicated that they reserve the > right > to alter the internal workings of a part to make it more > manufacturable. > So even if you make the logic delay dominate over routing delay, the > logic delay of any given portion of the chip may be greatly > accelerated. > > For example, they may reduce the feature size of the part and end up > making the H block much faster than the F or G blocks relative to the > old design. The new part will still meet spec, but some paths of your > design may become much faster than the others. > > As you point out, implementing this circuit in an FPGA is most likely > a > testbench. But it is a pretty poor testbench for this particular > circuit. > > But all of our comments are relative to the Xilinx. I don't know the > Altera 10K so well, but don't they have much more deterministic > routing? > This may make it more pratical if the routing delay dominates. > Here is the Xilinx Applications spin on this subject: I agree with most of the cautious remarks. Trying to use an FPGA ( or actually any other non-specialized device ) to create a fixed delay is hopeless. Temperature, voltage, processing tolerances and potential chip redesigns will cause the delay to vary by a factor of 4 to 10. ( Altera is in the same boat as Xilinx ). There are, however cases where it is possible to rely on on-chip delays: differentiating a clock edge, or doubling a clock by differentiating both edges can be made to work reliably, if the generated "glitch" is deliberately made long, and is used in a reasonable way ( not routed all over the chip ). As a last resort, when no digital solution is available, such a design can be made to work reliably. Another application is in a feedback loop, where you use a variable number of gate delays to compensate for a specific delay. If this is designed in an adaptive way, it will obviously be reliable, as long as the range is appropriately defined. Phase-locked-loop and delay-locked-loops are becoming popular for "eliminating" on-chip clock delays, and such circuits are more or less analog and asynchronous in nature. So, don't throw out the baby with the bathwater. But you have to be real smart when using asynchronous tricks. Truly synchronous designs are always preferrable, but sometimes they cannot solve the problem. Peter Alfke, Xilinx ApplicationsArticle: 11378
alz wrote: > Paul, > > Check out www.plda.com They have a very easy to implement pci core. > The core is limited to Altera devices only. > > Al > Along those lines, does anybody have experience with Eureka Technology cores? (www.eurekatech.com) We are also evaluating them... Darrell Ray Senior Logic Design Engineer Blue Wave Systems Email: dray@mizarinc.com 2410 Luna Rd Phone: 972.277.4605 Carrollton, TX 75006 Fax: 972.277.4666Article: 11379
> the vast majority of windows pci drivers ..... > this isn't an issue with pci > drivers, and you still need the ddk, or an equivalent, to write your > pci driver. Sorry to be so pesky, but why do you specify "PCI" driver? Aside from PCI configuration (which is done by the BIOS before any O/S is loaded) how is it any different than, say an ISA or EISA driver? Aside from a BIOS call to get the table of PCI boards and find your device ID so you can get the interrupt and address.... A PCI device appears at an I/O address and/or a memory address, these addresses aren't special for PCI. It may have an interrupt, which means you put a vector at the appropriate spot in the interrupt vector table, again, nothing special for PCI. DMA is done by programming the PCI card (if it supports master mode) specific to the chip being used....not particulary particular to PCI, but particular to the chip....but again, these are just registers in either memory or I/O space....nothing special to PCI. AustinArticle: 11380
I am trying to determine the most secure way of implementing proprietary algorithms. It seems to me you could either code the alorithm into a ROM image of a microcontroller, or burn a PLD. In either case I suppose a hacker or anyone who wanted to "reverse-engineer" the design (for whatever reason) could always grind the packaging away and physically view the fusemap, although I have no idea how easy or difficult this would be. (Anyone hacked a cell phone before ? ) Right now I like the PLD approach just for simplicity reasons but I haven't found any vendor hype about about any type of device anti-read features, (except for the Atmel smart card chips, but they do not have a general purpose external interface like an MCU or PLD). Any input, including vendor plugs are welcomed. Rgds,Article: 11381
Hi All, I found a good reading about the USB interface. So please, check this url http://www.angelfire.com/ok/jpbelin/TOPPAGE.html Hope this will help. Please, add it in your bookmark. PepitoArticle: 11382
Please visit and comment on my Electronics and Electrical Engineering pages located at: http://www.users.globalnet.co.uk/~metad/eee.htm Containing: Introduction to EEE Resources (over 100 web links) Employment Statistics and newspaper excerpts Engineering Poems, Quotations and Jokes EEE at Glasgow University In addition my homepage (http://www.users.globalnet.co.uk/~metad/) contains: A section about me My CV A James Bond Section A guestbook 500+ cool links in the "new look" bookpage Cool background MIDI and graphics Literary quotations Photo Album Awards Page Poems... Basically, something for everyone! PLEASE VISIT VIA MY MAIN HOMEPAGE ADDRESS! Please send you comments via the guestbook or by Email (containing your full name and Email and webpage addresses) and visit via http://www.users.globalnet.co.uk/~metad/. Thanks Scott Johnston metad@globalnet.co.ukArticle: 11383
To Everyone Who Responded: Thanks to everyone who responded to my plea for information about FPGA PCI cores information. I received some good and varied information about these cores and what to do with them and without them. The information I received makes me think that my silicon vendor choice will be critical and the design effort will be moderately difficult. When I make my decision about which vendor to select, do my design and gain some experience with the design, I will post another message to let everyone know how it went. I would like to see more information posted about FPGA PCI designs as I have found out that FPGA PCI designs are about to start taking off more and more. Again, thanks everyone. -Simon Ramirez Consultant/Contractor 407-365-8928 s_ramirez@msn.comArticle: 11384
A big fat NO! ems wrote in message <35bd9e48.6963996@news.dial.pipex.com>... ><previous thread snipped> > >Has anyone managed to do any successful complex asynchronous design in >an FPGA? Presumably the various async processor research projects are >prototyping on FPGAs. > >Or, alternatively, does anyone know of an FPGA which guarantees >minimum propagation delays? > >Evan >Article: 11385
Wade D. Peterson wrote: > > >> > 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. > >> <snip> > >hamming codes or a tmr which has similar characteristics. in this case a reed-solomon > >could would be used, but is inconvenient since it's a block code. data shows that > >these sort of chips do have multiple bit errors and it's not just a theoretical thing. > > >another consideration is the circuit design of the cell. excluding access > >transistors, a 4-T storage cell should be used. if a 2-T + 2-R configuration is used, > >where the value of R is EXTREMELY high (as in commercial SRAMs), then a single heavy > >ion strike can cause a tad of leakage resulting in a 'stuck bit' with obvious > >implications on error correcting coding schemes. again, this is seen in real data. > > >what does this mean for fpga? well, it depends on the device architecture and > >layout. for devices with sram the work previously done for discrete sram chips needs > >to be applied, carefully, both in circuit design and layout. Very interesting - can those with experience in Radiation Enginnering, bring a more terestial level to this, and quantify the difference in Radiation levels - on the earths surface ? - in Jumbo Jets ? - and in Orbit ? My understanding of this is that you still get radiation hits at gnd level, just not as many of them. What is statistically significant depends on your point of view. I also recall seeing something about Radiation triggering LATCHUP - how do the redundant engineering approaches handle that problem :-) - jgArticle: 11386
In article <01bdc263$8ce4d600$cd037a86@rsemenoff.phoenix.com>, "Robert Semenoff" <robert_semenoffNOSPAM@phoenix.com> wrote: >I am trying to determine the most secure way of implementing >proprietary algorithms. >It seems to me you could either >code the alorithm into a ROM image of a microcontroller, or >burn a PLD. In either case I suppose >a hacker or anyone who wanted to "reverse-engineer" the design (for >whatever reason) could always grind the packaging away and >physically view the fusemap, although I have no idea how easy >or difficult this would be. (Anyone hacked a cell phone before ? ) > >Right now I like the PLD approach just for simplicity >reasons but I haven't found >any vendor hype about about any type of device >anti-read features, (except for the Atmel smart card chips, >but they do not have a general purpose external interface >like an MCU or PLD). >Any input, including vendor plugs are welcomed. > >Rgds, Here's a vendor plug, from Actel. Antifuse is the most secure method of implementing digital functions in silicon. Please see the attached Acrobat document.Article: 11387
>>>>>>>>> Stupid PDF file binary (1000 lines) deleted by Archive OwnerArticle: 11388
>>>>>>>> UUENCODE DELETED BY ARCHIVE OWNERArticle: 11389
>>>>>>>> UUENCODE DELETED BY ARCHIVE OWNERArticle: 11390
>>>>>>>> UUENCODE DELETED BY ARCHIVE OWNERArticle: 11391
jim granville <Jim.Granville@xtra.co.nz> wrote: >Very interesting - can those with experience in Radiation Enginnering, >bring a more >terestial level to this, and quantify the difference in Radiation levels >- on the earths surface ? >- in Jumbo Jets ? >- and in Orbit ? > My understanding of this is that you still get radiation hits at gnd >level, just >not as many of them. > What is statistically significant depends on your point of view. > I also recall seeing something about Radiation triggering LATCHUP - how >do the >redundant engineering approaches handle that problem :-) I'm by no means a radiation expert. However, I was over at CERN in Switzerland a couple of months ago (CERN is a big 'atom smasher', among other things), and in their lobby they had a really cool operating 'cosmic ray' detector. This thing was about 10' x 20' in size, and it showed that at ground level you would get about 1 or 2 hits every 10 seconds or so (over the entire area). I'm not sure if that thing was even detecting the same kind of particles that whack microchips, but I suppose you could scale these numbers down to a die size. Wade Peterson Silicore Corporation www.silicore.netArticle: 11392
Marc Heuler wrote: > I want to implement a Gray code counter (16 bit) in ABEL HDL for the > Lattice 1016 device. > > Are there gray-code-counter examples on the net? Here is the equation for converting Binary to Gray code. Qn (Gray ) = Qn(binary) XOR Qn+1 ( binary). In other words, you just XOR any binary output with the next more significant binary output. Hope that helps a little. Viele Grüße, ( yes, we can do umlauts and eszets :-) Peter Alfke, Xilinx ApplicationsArticle: 11393
I want to implement a Gray code counter (16 bit) in ABEL HDL for the Lattice 1016 device. Are there gray-code-counter examples on the net?Article: 11394
This sounded like a hoax. Taking a look, I found that although it
_sounds_ like one, it somehow makes sense. After all, there are
several things that work, even if we cannot explain them. Users of
wishing-wands are an example. They do find water, but nobody knows
or can proof how it works.
Anyway, I'm thinking of ordering one of their glass wands. It's not
a lot of money if it can do what they claim.
Any opinions?
Surfin'
On 5 Aug 1998 09:18:33 GMT, info@NO-SPAMcleanfood.com wrote:
> Hello, everybody,
>
> Let me tell you about a new approach to free your food of viruses,
> bacteria, fungus, etc.
>
> We produce Polarizers. These are wands made of rock-crystal glass.
> They deactivate the poisonous influence of pathogenes like viruses,
> bacteria, spores, fungus and eggs of intestinal worms, which can be
> found in food supplies. In *your* food supplies.
>
> http://www.cleanfood.com
>
> You will also find that the Polarizer is a simple, easy to use
> device.
>
> Take a look, it's a surprising, effective and cheap approach to
> deactivate the pathogenes in your food.
>
>
> Clean Food Corp.
> http://www.cleanfood.com
>
>
> Please remove the obvious when replying via email. If you don't eat,
> you may consider this message off-topic. Sorry for that.
Article: 11395On 7 Aug 1998 21:28:13 GMT, "Austin Franklin" <dark6room@ix.netcom.com> wrote: >Sorry to be so pesky, but why do you specify "PCI" driver? Aside from PCI >configuration (which is done by the BIOS before any O/S is loaded) how is >it any different than, say an ISA or EISA driver? just for convenience, i guess. when writing VxDs (for Win9x), there are 2 categories of hardware devices - plug'n'play and legacy. it just happens that most p'n'p devices are on PCI. people in the VxD newsgroup tend to refer to their drivers as PCI drivers, or PC(mcia)-card drivers, or whatever, rather than as pnp drivers. a pnp driver uses a microsoft VxD called the CM (configuration manager) to provide its basic services, such as finding out what resources the device requires, and making sure that there are no resource conflicts. the CM itself relies on various other (microsoft) VxDs to do such things as enumerating all the devices on a given bus, loading drivers when required, and so on. in principle, there are only minor differences between a pnp driver for PCI and, for example, a PC-card. legacy drivers for, for example, an old ISA card are very different. >Aside from a BIOS call to >get the table of PCI boards and find your device ID so you can get the >interrupt and address.... >A PCI device appears at an I/O address and/or a memory address, these >addresses aren't special for PCI. It may have an interrupt, which means >you put a vector at the appropriate spot in the interrupt vector table, > <snip> you could, in principle, ignore the CM/pnp services, and write a legacy driver for a PCI card, using bios services as you suggest (you have to do this for win3.x). this comes up occasionally in the newsgroup, but the suggestion is normally shouted down quickly. evanArticle: 11396
On Fri, 07 Aug 1998 09:02:23 -0700, Al Zimmerman <alz@RayCast.com> wrote: > But I guarantee you that >graphics chip vendors are avoiding any & all ring3/ring0 transitions. my point was that there weren't any to avoid. >Alternatively, you could use the DDK from Microsoft >and have the OS determine whether to access the pci bus. you have to use the ddk, or equivalent, to write your driver. this is unrelated to the memory window issue. >With all that said, the graphics chip will do most of the transferring >anyway by mastering the pci bus and reading the data from main memory. >The goal is to get the request command to the graphics chip ASAP. The >fastest way to do this is to get the OS out of the way. that's the point of having a memory window. >Most applications will >not have speed issues with 2d graphics so the having the OS performing >virtual addressing onto the pci bus will not be a big deal. there's no virtual addressing overhead. the OS sets up the processor's page tables during initialisation, and translation is automatic. all system memory, with one minor exception, must be accessed as virtual memory. evanArticle: 11397
On 8 Aug 1998 00:32:13 GMT, "Robert Semenoff" <robert_semenoffNOSPAM@phoenix.com> wrote: >I am trying to determine the most secure way of implementing >proprietary algorithms. In the past, I have always assumed that the 'hide it away' approach to security in fpgas was the only one available. However, I recently came accross a much more interesting approach. It is possible to use the inherent volatility of sram-based fpgas as an asset to security. If you programme the design into the device in the factory, battery back it up to keep it in-situ for normal use, then fit tamper sensors on the casework of your product (microswitches, tilt switches whatever). These tamper sensors need to 'evaporate' the design by resetting the device. In this way an attack on the product will find nothing of a proprietory nature. This approach can be taken further as regards any microprocessor program storage or whatever. I agree, this approach is not appropriate for many applications, but it just goes to show that there are many ways to skin a cat! Graeme Durant HELION Technology Limited Programmable Logic Solutions Cambridge, UK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.heliontech.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 11398
Hello This is Abhay Joshi from Solution Machines, Ahmedabad, India We are a solutions company actively focussed on ASIC DESIGN services. We have a team of engineers who are working on the SYNTHESIZABLE CORE DEVELOPMENT OF USB and FIREWIRE IEEE1394 We are looking at a fulltime ASIC XDESIGN / VERILOG consultant to be based at Ahmedabad. Remuneration not a constraint at all. Luxurious Accomodation will be offered over and above an attractive ESOP arrangement. Excellent Opportunity to lead a team of dynamic engineers, make the products silicon proven and head the Hardware Modeling Profit Centre. Job might involve spending some time in the heart of Silicon Valley. Pls visit our site www.solutionmachines.com for more info on SolMac Send in your resume immediately on solmac@ad1.vsnl.net.in or ajjoshi@hotmail.com Regards Abhay Joshi -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member ForumArticle: 11399
Marc Heuler wrote: > I want to implement a Gray code counter (16 bit) in ABEL HDL for the > Lattice 1016 device. > > Are there gray-code-counter examples on the net? Yesterday I provided the simple binary-to-Gray conversion algorithm. But here comes a warning: Do not just hang this XOR on the binary counter outputs. Then the binary asynchronous weird codes ( going from 7 to 8 with unknown codes happening in-between ) are just passed through to the Gray side. Instead, re-synchronize the Gray outputs with the counter clock, and you will have no problem. Of course, that's easier in a flip-flop rich architecture, like (hm) Xi... :-) Peter Alfke, Xilinx Applications
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