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
I added a variable to calculate a time for a wait statement in a testbench and am not getting this error from ModelSim... Signal arm_command is read by the VITAL process but is NOT in the sensitivity list This is the line of code producing the error... WaitTime := (ARM_command.RelTime - (now - CurrentTime)); I follow this up with a check for negative values before using in the wait. ARM_command is a signal and WaitTime and CurrentTime are variables. And of course all these objects are of type time. This same calculation done directly in the wait statement gives no error. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58926
"Pacbell User" <dont_reply@dont_reply.com> wrote in message news:<sSgXa.472$gC7.418@newssvr23.news.prodigy.com>... > I would like to contribute a multi-cycle (slow, but area-compact) > (Hehe, someone else already released a pipelined integer-divider, > to the opencores.org repository. Gence I'm marketing my divider as > 'compact'!) > I am reading through the FAQ, and one part has me a bit confused... > > === > > The 'licensing' portion -- I understand that the 'GPL' license > is fairly restrictive in that it forces derivative works to be > distributed in documented *AND* modifiable form. > > My goal is to let *anyone* use my integer-divider as they see > fit. If they want to use it in a closed commercial project, that's > fine. It seems like a GPL-release cannot be used in a closed > project, is that correct? > > So under which license should I release my divider? LGPL, BSD, etc.?!? Look at some other IP cores (perhaps some of mine) at OpenCores. I faced the same problem that you are facing, I wanted to protect myself but not limit the usage of any of my IP cores. So I created my own "license". It's on top of each of my files ... Best Regards, rudi -------------------------------------------------------- www.asics.ws --- Solutions for your ASIC/FPGA needs --- ----------------- FPGAs * Full Custom ICs * IP Cores --- FREE IP Cores --> http://www.asics.ws/ <-- FREE IP CoresArticle: 58927
Pacbell User wrote: > The 'licensing' portion -- I understand that the 'GPL' license > is fairly restrictive in that it forces derivative works to be > distributed in documented *AND* modifiable form. LGPL will not really help you here and I am not really sure how you would apply it to a hardware design in any case. Can you LGPL license hardware designs and treat the situation is if you were linking against a library thus being ok with binary distribution? Does that really work? I personally prefer the GPL over most other licenses however in this case either having no license or a BSD style one will probably suffice. Jon.Article: 58928
Your design should fit going from the 9500 to the 9500xl. The 9500xl actually has more function block fanin (36 to 54!) so I would think that there should be no fitting issues. The only architectural features lost are macrocell feedback and wire-anding in the AIM. The loss of macrocell feedback should be made up for by the additional FB inputs. The loss of wire-anding would cause your PTerm requirements to increase. Perhaps if you were near the maximum utilization for this it would not fit. You may want to try contacting the Xilinx hotline. They are willing to try fitting close designs. Arthur atali@cygrp.com (Aare Tali) wrote in message news:<a8b3964d.0308020956.1e3b61be@posting.google.com>... > I hope Google won't eat the first reply, so here's an addition to it, > some parts of fitter report are below: > > news@rtrussell.co.uk wrote in message news:<bgdmcf$73u$1@nntp0.reith.bbc.co.uk>... > > I have a design (admittedly making heavy use of the device resources) > > which successfully fits into an XC9536 but not an XC9536XL. This is > > something I hadn't anticipated when migrating to the newer part. Is > > this to be expected, and is it likely that by tweaking any fitter > > options (or otherwise) I will be able to get the design to fit ? > > > > I am using Xilinx Foundation F4.2i, Build 3.1.196. > > > > Richard. > > http://www.rtrussell.co.uk/ > > > cpldfit: version E.33 Xilinx Inc. > Fitter Report > Design Name: iw Date: 4- 1-2003, > 4:17AM > Device Used: XC95144XL-5-TQ144 > Fitting Status: Successful > > **************************** Resource Summary > **************************** > > Macrocells Product Terms Registers Pins Function > Block > Used Used Used Used Inputs > Used > 143/144 ( 99%) 558 /720 ( 77%) 100/144 ( 69%) 111/117 ( 94%) 415/432 > ( 96%) > > PIN RESOURCES: > > Signal Type Required Mapped | Pin Type Used > Remaining > ------------------------------------|--------------------------------------- > Input : 58 58 | I/O : 104 > 5 > Output : 44 44 | GCK/IO : 2 > 1 > Bidirectional : 8 8 | GTS/IO : 4 > 0 > GCK : 1 1 | GSR/IO : 1 > 0 > GTS : 0 0 | > GSR : 0 0 | > ---- ---- > Total 111 111 > > *********************Function Block Resource > Summary*********************** > Function # of FB Inputs Signals Total O/IO > IO > Block Macrocells Used Used Pt Used Req > Avail > FB1 18 53 53 67 12/0 > 15 > FB2 18 53 53 57 7/0 > 15 > FB3 18 51 51 87 14/0 > 15 > FB4 18 51 51 71 0/1 > 15 > FB5 18 52 52 83 8/0 > 14 > FB6 18 52 52 72 1/7 > 13 > FB7 18 51 51 66 0/0 > 15 > FB8 17 52 52 55 2/0 > 15 > ---- ----- ----- > ----- > 143 558 44/8 > 117 > > So, in dense design you can't rely on Xilinx tools only, I was always > 1-2 cells over 144 when I was playing with options, so I had to > constrain things myself...Article: 58929
Austin Lesea <Austin.Lesea@xilinx.com> wrote: ... : If you havce 90nm/.35u (no reason why it can't be done), you lose all your : speed and area by having to drive the huge .35u transistors (makes for a : more expensive die). Austin, just for interest, is there any document showing the schematics of such a mixed voltage output stage? I think driving the PMOS of the output stage is quite tricky, without sacrificing to much current. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 58930
On Mon, 04 Aug 2003 09:46:48 -0700, Austin Lesea wrote: > Rick, > > It has to do with the foundires. > > What do you offer as your lowest cost standard CMOS process? > > .18/.35 was really popular (and still is). > > .15/.35 was the half-step between .18 and .13. > > .13/.25 is the dominat process right now (3.3V is a tough push, and has to > be done carefully, and 5V is definitely gone) > > 90nm/.25u is what we are in for Spartan 3, so there has to be a reason > (like all those three letter companies that offer standard CMOS > processes....) > > If you havce 90nm/.35u (no reason why it can't be done), you lose all your > speed and area by having to drive the huge .35u transistors (makes for a > more expensive die). Are you saying that you lose all of the speed and area over the whole die or just for the IO section? If it's just the IO that would be OK in a part like this. A part aimed at the 5V interface market doesn't need fast IOs because the clock rates in that world are low. It does need the logic and RAM density of a modern part, if it wasn't any denser than an old .18u part then you might as well stick with the older part or live with external level shifting transceivers.Article: 58931
Hello, Is there a way to put a ready developed VHDL code into binary form, so that other can use, but not read it? Of course there is such a way, because the IP vendors live from that :-). Does anyone know how to do this with the Xilinx ISE 5.x environment? thanks in advance for any help. Guenter (guenter.wolpert@t-online.de)Article: 58932
Sergey, The JSHUTDOWN command will do just fine. If your design has dll and/or ram, you may want to make sure you reset them. You can automate the shutdown sequence with the XSVF player. Generate an SVF file with iMPACT or by hand, then convert the SVF fiel to XSVF file and play the XSVF file with XSVF. Please take a look at XAPP058 for the XSVF player and converter and XAPP503 for detailed format on SVF. Regards, Wei Serg_Y wrote: > Does it mean that figure 6. in xapp139 (Device configuration flow > diagramm) has error? The "Reconfigure path" trough "Shundown sequence" > is available or not? > > under "shutdown sequence" i mean the process described on p14 XAPP139 > > [ from XAPP139 > 1. Load the CFG_IN instruction into the JTAG instruction register. > Next, go to the SHIFT-DR > .... > COR (Configuration Option Register) with the SHUTDOWN bit = 1 > .... > ] > > the described process does not need access to PROG > > -------------------- > > Thanks. > Sergey.Article: 58933
Pankaj Rodey wrote: > I have a querry regarding CPLD, we are using. It is XC9536XL and > XC9572TQ100 Xilinx CPLDs. > I tried to develop a simple divide by two scheme, with a T flip flop, > with T pin tied high and clock given to flip flop through one of the > global clock I/O pins of CPLD. It is expected to get pulses of half > the frequency at Q output of the flip flop, with Q output toggling at > every positive edge of clock. However, I get some pulses of > continually varying frequency at the output pin. > The devices I used are, XILINX WEBPACK ISE 4.2 as HDL editor, Impact > tool for program download. > Kindly guide me as to the possible sources this ambiguity. Why not try a D flip-flop with the not-Q output connected back to the D input. JonArticle: 58934
Uwe, Circuits to do this are considered proprietary. I could do a search on google for level shifters, but you can, too. Austin Uwe Bonnes wrote: > Austin Lesea <Austin.Lesea@xilinx.com> wrote: > ... > > : If you havce 90nm/.35u (no reason why it can't be done), you lose all your > : speed and area by having to drive the huge .35u transistors (makes for a > : more expensive die). > > Austin, > > just for interest, is there any document showing the schematics of such a > mixed voltage output stage? I think driving the PMOS of the output stage is > quite tricky, without sacrificing to much current. > > Bye > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 58935
This is left as an exercise for those who already know how to design these circuits, If you don't, then it is not my place to instruct. Austin "B. Joshua Rosen" wrote: > On Mon, 04 Aug 2003 09:46:48 -0700, Austin Lesea wrote: > > > Rick, > > > > It has to do with the foundires. > > > > What do you offer as your lowest cost standard CMOS process? > > > > .18/.35 was really popular (and still is). > > > > .15/.35 was the half-step between .18 and .13. > > > > .13/.25 is the dominat process right now (3.3V is a tough push, and has to > > be done carefully, and 5V is definitely gone) > > > > 90nm/.25u is what we are in for Spartan 3, so there has to be a reason > > (like all those three letter companies that offer standard CMOS > > processes....) > > > > If you havce 90nm/.35u (no reason why it can't be done), you lose all your > > speed and area by having to drive the huge .35u transistors (makes for a > > more expensive die). > > Are you saying that you lose all of the speed and area over the whole die > or just for the IO section? If it's just the IO that would be OK in a part > like this. A part aimed at the 5V interface market doesn't need fast IOs > because the clock rates in that world are low. It does need the logic and > RAM density of a modern part, if it wasn't any denser than an old .18u > part then you might as well stick with the older part or live with > external level shifting transceivers.Article: 58936
If you ever looked at a software stack, you will find that one of the most CPU intensive operation during the handling of an IP packet is the checksum calculation. Most software stacks will do this in assembly. Now if you could do this in hardware, this should save the host CPU a bunch of time. The other thing is that networking switches employ hardware lookup (using CAM) to decide which port an incoming network frame should go out. A router could probably use a similar scheme to route a packet, avoiding a routing table in software(software means slow.) If you are paranoid about speed, then you could have your hardware forming the ACK packets, while handling the incoming packet (to ack) Note that you can create an ACK packet as soon as the sequence number of a TCP segment is seen - you dont have to wait to see the whole segment (as a software implementation) All the optimizations, short cuts, parallelizations that you could think of in a hardware implemenation should be fun, and all that. However, from a pratical point of view, when you are dowloading files from a computer halfway across the world, you don't really need a very fast stack, because the download site doesn't care if you can ack a TCP segment in 1 or 10 seconds. Not to mention the fact that your packet will traverse 10 routers to get there. You do your best to get the packet as fast as you could out of your box, but it's the networking equipment you have no control of that will slow you down. erik.coenders@philips.com (Erik Coenders) wrote in message news:<f5fc2c9a.0307310717.4d340e4a@posting.google.com>... > Hi, > > As a study for a project I need to investigate the possibility of > implementing a tiny TCP/IP stack and tiny MAC controller on FPGA. This > stack is capable to transfer some data packets directly into S(D)RAM > without help of the microcontroller. Thus a simple communication via > Ethernet from the desktop PC is required for download/upload to/from > the memory. > > The FPGA board is attached to an Ethernet PHY device such as DP83847A. > In this case a MAC controller was implemented in FPGA but the FPGA > utilitization is too high. There is less room available for other > blocks. My intention is to build a small TCP/IP stack and MAC blocks > in the FPGA and the transaction between FPGA/Ethernet PHY and the > desktop PC has to kept as simple as possible. Thus no heavy/extensive > protocol is needed. > > The questions raised are: > 1. What is the minimum TCP/IP function set required to do simple file > transfer and etc.? > 2. Is it possible to perform all tasks only in FPGA without help of > the microprocessor? > 3. Are there any resources (VHDL code and C program on PC) available > on this topic? > > I will welcome all comments and suggestions. please feel free to write > us at erik.coenders@philips.com Thank you all.Article: 58937
Jon Masters wrote: > Hi, > > Can someone tell me if there is a Xuart Lite driver for Linux already > and where I might find the patches before I continue with writing one? > Hi Jon, I got my UARTlite driver for uClinux working just yesterday, still a couple of bugs but expect to iron them out today. You are welcome to try it in PPC linux if you wish - just send me an email or check it out of the uClinux CVS tree - it should be in there by now. In principle it should drop straight into Linux. Cheers, John -- Microblaze uClinux web site http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinuxArticle: 58938
Laurent,
You could build a charge pump with 2 diodes and 2 caps driven
with a square wave from your 3.3V FPGA IO. Well, you wanted cheap!
HTH, Syms.
Amontec Team <laurent.gauch@www.DELALLCAPSamontec.com> wrote in message news:<3f2e6c8c$1@news.vsnet.ch>...
> Hi,
>
> I have to connect a LCD-I2C to my FPGA.
> My LCD can be supplied only with 5V, and I have only a 3.3V.
>
> Do you know a low cost step-up dc-dc converter solution.
>
> I only need 2 mA as output current.
>
> Regards,
> Laurent
Article: 58939Austin Lesea <Austin.Lesea@xilinx.com> wrote: : Uwe, : Circuits to do this are considered proprietary. : I could do a search on google for level shifters, but you can, too. The basic concept is clear for me. An Open Collector/OpenDrain as switch and a pullup resistor ( in the discret case) or a depletion NMOS( in the integrated case) as load. But to get that at speed at low current ... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 58940
Hi everyone, A few months ago I posted announcing the existence of the porting effort to get uClinux on the Microblaze soft-core processor. Things have come a long way since then, so here's an update on the project status. More information can be found on the project web site: http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux News: - Core kernel port is complete. - A TTY/console driver for the UARTLite is done and mostly functional. - The kernel boots to an interactive shell. - The /proc filesys can be mounted and queried. - Busybox utils build but are not tested yet. - Xilinx has mentioned the uClinux port in an official publication (http://www.xilinx.com/xapp/xapp477.pdf). - The project website has been revised. Up-to-date sources are hosted on the uClinux anonymous CVS - cvs.uclinux.org Regards, John -- Dr John Williams, Research Fellow, Reconfigurable Computing, School of ITEE University of Queensland, Brisbane, Australia Ph : (07) 3365 8305Article: 58941
The URL would be too long. It's patent 6,601,126, and is available at <http://patft.uspto.gov/netahtml/srchnum.htm> There was an EE Times (and other CMP websites) article about this story. <http://www.eet.com/semi/news/OEG20030801S0043> This sounds fishy to me. I've personally worked on SoC designs using only uni-directional busses with various asynchronous peripherals - well before the time this patent was filed. I'd like to see PalmChip try to enforce this patent. The EET article also mentions that FPGAs have been using this kind of technology for a while. Here are some of the "claims" of the patent: "1. An on-chip interconnection system, comprising: a single semiconductor integrated circuit (IC); a plurality of uni-directional buses disposed in the IC; a peripheral-bus (p-bus) included in the plurality of uni-directional buses and that uses a simple non-pipelined protocol and supports both synchronous and asynchronous slave peripherals; a p-bus controller connected to the p-bus and constituting an only bus-master, and including a centralized address decoder for generating a dedicated peripheral select signal, and providing for a connection to synchronous and asynchronous slave peripherals, and further providing for an input/output (I/O) backplane that allows a processor to configure and control any of its slave peripherals; and an m-bus included in the plurality of uni-directional buses, and for providing a direct memory access (DMA) connection from any said slave peripherals to a main memory and permits peripherals to transfer data directly without processor intervention. 2. The on-chip interconnection system of claim 1, wherein, there are included no tri-stated-buses, and no bi-directional buses. 3. The on-chip interconnection system of claim 1, wherein, each signal has only a single buffer driver. 4. The on-chip interconnection system of claim 1, wherein, any broadcast signals are re-driven by simple buffers with no extra control logic."Article: 58942
John Williams wrote: > I got my UARTlite driver for uClinux working just yesterday Scary stuff indeed John! I was going through the serial driver code recently and realised this is not going to be a trivial patch because there is no standard support for describing odd register offsets like with the XuartLite in serial.c. Certainly I will try your driver and submit any patches and so forth. > still a couple of bugs but expect to iron them out today. I will check out your source from work and take a look tomorrow but please do keep me posted of any and all bugs so I can help you out. > You are welcome to try it in PPC linux if you wish I most certainly do. Should save me some time since I have a kernel booting now on the Insight board and falling over after it tries to flush the ring buffer to a non-existent serial console. I am actually really pleased because prior to this there were a whole host of memory management issues which would not go away and still there are spurious and unexplaned Machine Checks that e.g. NetBSD just ignore. > In principle it should drop straight into Linux. If not I am certainly not bothered in fixing that since you are saving me another day of grind before being able to use this system! I was looking at the Microblaze stuff earlier thinking someone must have already solved this problem and avoided buying the 16550 for Linux. The other implementations I have seen rely on the 16550 which is all very well but in this case the plan is to use the funky Xuartlite. Once you get past the alignment issues it is actually ok talking to it - I have low level non-interrupt drivers for ppc_md and so forth but need a full interrupt driven driver via the xintc controller which there is already working in our hardware design... > http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux Is this a University related project perchance? Having just graduated from my second University I am finally looking at PhDs in embedded real time systems - the hope is to tie my commercial and part time study together with some of this tech. Jon.Article: 58943
For Xilinx FPGAs, you can distrubute IP cores in Xilinx binary database format (.ngo files). Take a look at 'edif2ngd' command. Jim Wu jimwu88NOOOOOSPAM@yahoo.com Guenter Wolpert <guenter.wolpert@t-online.de> wrote in message news:4r0xgrxg.fsf@linux.local... > Hello, > > Is there a way to put a ready developed VHDL code into binary form, > so that other can use, but not read it? > > Of course there is such a way, because the IP vendors live from that :-). > > Does anyone know how to do this with the Xilinx ISE 5.x environment? > > thanks in advance for any help. > > Guenter (guenter.wolpert@t-online.de) > > >Article: 58944
Hi Jon, Jon Masters wrote: > I was going through the serial driver code recently and realised this is > not going to be a trivial patch because there is no standard support for > describing odd register offsets like with the XuartLite in serial.c. > Certainly I will try your driver and submit any patches and so forth. Yeah I had a few tough moments figuring out the alignment and dealing with pointer aliasing and stuff - seems to be mostly figured out now. The uartlite is a funny thing, on the surface it looks like a fully featured uart, but when I delved a bit deeper there are some idiosyncracies that make it just that bit more tricky - like the interrupt generation, for example. > I most certainly do. Should save me some time since I have a kernel > booting now on the Insight board and falling over after it tries to > flush the ring buffer to a non-existent serial console. > I am actually really pleased because prior to this there were a whole > host of memory management issues which would not go away and still there > are spurious and unexplaned Machine Checks that e.g. NetBSD just ignore. OK cool. What is the status of V2Pro/PPC linux these days from a user perspective? > I was looking at the Microblaze stuff earlier thinking someone must have > already solved this problem and avoided buying the 16550 for Linux. Yeah I'll avoid the 16550 for as long as possible, for simple console stuff the uartlite should be fine. >> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux > > Is this a University related project perchance? Yep - see my post a few lines down. uClinux plus RTAI real-time extensions is the OS for our reconfigurable computing research platform. Cheers, JohnArticle: 58945
Hi Simon,
A colleague and I tried this with the following results: With the
older CS8900 card (10-base, used in the original Nios Ethernet Kit),
everything worked without errors. However, in the newer daughter card
(LAN91C111) we saw the same behavior.
This is really due to how we reset the two chips. With the original
Ethernet Kit, we would boot the MAC into "promiscuous mode" to receive
all packets, whether they were intended for our Nios board or not.
Primarily for reasons of efficiency (fewer interrupts, less CPU
overhead), we disabled promiscuous mode during bootup in the LAN91C111
driver. For applications such as nedk_bridge (where we just blindly
pass packets between the two Ethernet MACs), this causes some of the
packets to be igored, leading to the behavior you saw.
To get around this, call "set promiscuous" routine that is built into
our low-level MAC driver (lan91c111.c). Here is the modification to
nedk_bridge.c:
int main(void)
{
int result;
globals g; // How polite we are, the globals aren't really
global!
int i;
// Snip: code to reset each Ethernet MAC & do error check
// Set promiscuous "on" for "lan91c111_0"
nr_lan91c111_set_promiscuous(na_lan91c111_0,0,1);
// Set promiscuous "on" for "lan91c111_1"
nr_lan91c111_set_promiscuous(na_lan91c111_1,0,1);
// Rest of the code un-changed....
...
}
Good luck with your project.
Jesse Kempa
Altera Corp.
jkempa at altera dot com
"Simon Graham" <sgra070@xtra.co.nz> wrote in message news:<Ud0Xa.104068$JA5.2273965@news.xtra.co.nz>...
> Hi,
>
> I'm trying to use stacked 100Mbit ethernet modules with the Nios Development
> Kit (Apex 20K) to create a secure firewall/bridge device for a university
> project.
>
> However, I can't even get the example application included with the kit,
> "nedk_bridge.c" to work.
>
> I have the nedk_bridge program running on the Apex board. Each ethernet
> module is connected via crossover cable to a PC. I then try doing a simple
> ping from one PC to the other and view the results using the Ethereal packet
> sniffer:
>
<snip>
> The 1st PC sends the ARP request, the 2nd PC receives it, replies to the
> request, but the 1st PC never recieves the reply. The Nios for some reason
> never sends the final packet. If I initiate the ping from the other PC, the
> same thing happens - the first three packets are sent, but the last one is
> dropped.
>
> Is the Nios even capable of functioning for the purpose I want to use it
> for? I noticed that the Nios always initializes the ethernet modules in
> half-duplex mode. Altera themselves give frustratingly little info about
> this.
>
> I am using Quartus II 2.2, SOPC builder 2.52 (Nios CPU version 2.1), and
> Nios EDK 2.0 (LAN91C111 modules).
>
> Thanks,
>
> Simon
Article: 58946I added a variable to calculate a time for a wait statement in a testbench and am not getting this error from ModelSim... Signal arm_command is read by the VITAL process but is NOT in the sensitivity list This is the line of code producing the error... WaitTime := (ARM_command.RelTime - (now - CurrentTime)); I follow this up with a check for negative values before using in the wait. ARM_command is a signal and WaitTime and CurrentTime are variables. And of course all these objects are of type time. This same calculation done directly in the wait statement gives no error. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58947
Amontec Team wrote: > > Hi, > > I have to connect a LCD-I2C to my FPGA. > My LCD can be supplied only with 5V, and I have only a 3.3V. > > Do you know a low cost step-up dc-dc converter solution. > > I only need 2 mA as output current. Look around for a simple charge-pump circuit. RobArticle: 58948
>Not "all", just one extra per Vcco power/ground pin pair is all that is required >to reduce ground bounce by another 20% (roughly). The IO is set to a strong >standard (ie GTL, PCI, CMOS 24 mA, etc.) and set to a logic '0'. The pin is >connected to the ground plane just like a ground pin. Adding pins past the >first leads to a very small improvement (not worth it). Does it do any good to use a similar setup for power? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 58949
>The other thing is that networking switches employ hardware lookup >(using CAM) to decide which port an incoming network frame should go out. >A router could probably use a similar scheme to route a packet, >avoiding a routing table in software(software means slow.) How does that table/CAM get initialized? I'd suggest putting hacks like that on the back burner until the initial code is working. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
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