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
Thomas Stanka <Thomas.Stanka@de.bosch.com> wrote: > And its no problem to use multiple versions in different directories Then are they really the same file? Or are they separate copies of a file which was once the same file? > The only problem I see is to have multiple versions of the same file in > the same directory. Yes. As Allan points out, you can do that in ClearCase by using the full pathname to the version. And that works with labels too, which is quite neat. I'd still rather not have to use it though. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 34101
The are the other disc for the model Sim also it must use the hardware key contact to the parallel port. Paul Teagle ¼g¤J¡G > I had a ME related problem a while ago (look back for some archive > material - Xilinx solution 9253 was most appropriate). > > Basically, it was a problem with the path. Be careful how you attempt to > modify the autoexec.bat file. You have to use the system utilities to > modifiy, not just a text editor on the autoexec.bat files. There's registry > issues involved. > > I've now got a problem with the ModelSim package not finding the design. Oh > well... > > -- > Paul T. > > "jimmy" <jimmy_siu_@hongkong.com> wrote in message > news:9lat2j$o7l7@imsp212.netvigator.com... > > Dear all, > > I want to install the xilinx 3.3i ISE under winme platform. After the > > successful installation and re-boot the computer, I can't find the project > > navigator in the programs file on the start up menu. Also I cannot find > this > > file on the xilinx directory. Also I have added the path on the > autoexec.bat > > file , it still not work too. > > So can you give some suggestions to me to overcome this problem. > > Thank you very much > > > >Article: 34102
khoi ha wrote: > > I am looking for a vendor that develop synthesizable VHDL floating point > add, subtract, multiply and divide for Xilinx FPGA. go to www.annapmicro.com they sell optimized netlists, if you're looking for vhdl sources have a look to http://www.opencores.org http://flex.ee.uec.ac.jp/~yamaoka/vhdl/index.html Steven > > Thanks1 > Khoi HaArticle: 34103
This is a multi-part message in MIME format. --------------02C1E8FAFDD6E7EDBA50DC20 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Matthias, <p>Please see below: <p>Matthias Fuchs wrote: <blockquote TYPE=CITE>Hi, <p>I have a little question about containing my SpartanII design that uses <br>DLLs and some signals that should be constrained against a simple clock <br>and some against the doubled clock. Here ist the VHDL code for the DLL <br>section: <p> I_dll_int : CLKDLL <br> port map( <br> clkin => LCLK, <br> clkfb => clklocal, <br> locked => dll_locked_int, <br> rst => reset, <br> clk2x => clk2x_prebuf, <br> clk0 => clk1x_prebuf <br> ); <p> local : BUFG <br> port map ( <br> I => clk1x_prebuf, <br> O => clklocal <br> ); <p> double : BUFG <br> port map ( <br> I => clk2x_prebuf, <br> O => clkdouble <br> ); <p> I_dll_zbt : CLKDLL <br> port map ( <br> clkin => LCLK, <br> clkfb => MEM_CLK5, <br> locked => dll_locked_ext, <br> rst => reset, <br> clk2x => MEM_CLK <br> ); <p>"I_dll_int" and "local" and "double" are used to generate clklocal and <br>clkdouble for use inside the FPGA. since LCLK is feed with 33MHz, <br>clkdouble should have 66MHz. ... This is working ! <p>Next, "I_dll_zbt" is a DLL that doubles LCLK to 66MHZ, but the feedback <br>loop is external, since this clock is used by some ZBT synchronous <br>SRAMs.</blockquote> I am assuming that the MEM_CLK signal goes straight through an OBUF to a pin, which feeds the ZBTRAM clock and the clkfb input to the DLL? It should not be used to clock the data going out to the ZBTRAM. <blockquote TYPE=CITE> <p>All signals in capitals are FPGA pins. How do I have to constrain the <br>control, address and data signals for my ZBT RAMs ? <p>My 33MHZ clock input has a period constraint in the .ucf file. This <br>seems to be right. <br>NET "lclk" PERIOD = 30ns;</blockquote> If you are using the latest tools (3.1SP#) then the tools will automatically insert the correct constraint onto the downstream nets - but the constraint must be applied at the net connecting the IPAD to the IBUFG, or the IBUFG into the DLL. This way all OFFSET constraint will be correctly analysed - when referenced back to the input clock. <blockquote TYPE=CITE> <p>I figured out that I can constrain the BUFG as well, but not for the <br>doubled clock. Why ? Why not ? <br>#NET "double" PERIOD = 15ns; <br>NET "local" PERIOD = 30ns; <br> </blockquote> Provided that 'double' is still in existence in the design netlist, this should work. <blockquote TYPE=CITE> <br>I have seen the following lines in an example. I get errors because <br>"local" does not exist any more in the implementation. Why ? Is it <br>essential ? <br>#NET "double" TNM=c2x; <br>#NET "local" TNM=c1x; <br>#TIMESPEC TS10= FROM: c2x: TO: c1x: 15ns; <br>#TIMESPEC TS11= FROM: c1x: TO: c2x: 15ns;</blockquote> If you cover both the clock nets with a Period constraint, you don't need to do this, as the downstream period constraint will analyse the path for you. This is purely for explicitly constraining the clock domains. The reason this may not work any more is due to the PERIOD constraint already containing synchronous instances on the 'local' net. <p>Another way to do this would be to have the following: <p>NET local TNM = c1x; <br>TIMESPEC TS_CLKIN = PERIOD c1x 15ns; <br>TIMESPEC TS01 = FROM c1x TO c2x 15ns; <br> <p>Besides from the code above, you should be using: <p>NET clklocal PERIOD = 33MHZ; <br>NET clkdouble PERIOD = 66MHZ; <blockquote TYPE=CITE> <p>This is my real problem ! How can I constain my zbt RAMs datalines <br>against the doubled clock (MEM_CLK) ? The only thing that runs through <br>without errors is the following (using LCLK and not MEM_CLK). <br>NET mem_d<*> OFFSET = IN : 7 : AFTER : lclk; <br>NET mem_d<*> OFFSET = OUT : 7.5 : BEFORE : lclk;</blockquote> Without seeing the design I cannot comment. You need to use 'clkdouble' anyhow, since MEM_CLK is only for the ZBTRAM and FB input to the DLL. However, what you have written would also work above since LCLK is input to the DLL. MEM_CLK is not a valid clock for inclusion into the OFFSET constraint. <p>Please refer to XAPP132 for more information about building Clock Mirrors. <p>Dave <br> </html> --------------02C1E8FAFDD6E7EDBA50DC20 Content-Type: text/x-vcard; charset=us-ascii; name="dhawke.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Hawke Content-Disposition: attachment; filename="dhawke.vcf" begin:vcard n:Hawke;David Hawke tel;cell:(+44) 778 875 5002 tel;work:(+44) 870 7350 517 x-mozilla-html:TRUE org:<br><img src="http://www.xilinx.com/images/smvirtex.gif" alt="Xilinx"> version:2.1 email;internet:dhawke@xilinx.com title:XILINX Field Applications Engineer adr;quoted-printable:;;Xilinx Northern Europe=0D=0ABenchmark House;203 Brooklands road;Weybridge;; x-mozilla-cpt:;2672 fn:David Hawke end:vcard --------------02C1E8FAFDD6E7EDBA50DC20--Article: 34104
Rick, Thank you. All inputs are placed in the hopper for the next go around. The multiplier, the internal reconfiguration access, as well as many other "new" features on Virtex II were the results of such inputs. Austin Rick Filipkiewicz wrote: > Austin Lesea wrote: > > > Why would you want to flip the width under logic control? > > > > How would you deal with the "unused" bits after flip? > > > > Austin > > > > Rick Filipkiewicz wrote: > > > > > > > I have a situation where one set of BRAMs lie between memory & the PCI.. > I'd like to be able to build a single device which can handle any > combination of 64/32-bit DRAM & 64/32-bit PCI. Clearly for economy reasons > the packaging might change but that would then just (?) be a question of > running the flow again from MAP ->. > > So its not very ``dynamic'' in that it's not required to vary cycle-by-cycle > but more a run-time option.Article: 34105
BLAPP (Buffer and Level Adapter for Parallel Port) is a simple design
for safely interfacing a PC parallel port to circuits with low
voltage (CMOS) signals. It offers a fair amount of protection, and
uses only standard parts. The reason for the design was a need for
interfacing with newer FPGA families. In the hope that it will be
useful to some:
http://ce.et.tudelft.nl/~reinoud/blapp/README.html
- Reinoud
(Spam goes to wanabe, mail to wanadoo!)
Article: 34106The RAM has no idea that you present it with 13 bits, it assumes the word-width that it is configured for. So you must just throw away the bits you don't need. Don't expect the RAM to pack the data for you. How could it? Peter Alfke ============= spyng wrote: > thanks all, > I found the docs in ug002.pdf. > (I was looking at the data sheet for V2 and block ram :( and they are > not there) > and run a sim, it work as I have expected. > > just cursious, so the block ram can be see as a 18K x 1 bit memory, > and if I have a data width of 13. > it is going to pack the data in [12:0], [25:13], [38:26] ...... > and not as a 16 bit block, and have the last 3 bit ignore? > > thanks > spyng > > brimdavis@aol.com (BriMDavis) wrote in message news:<20010813225155.01553.00000107@mb-ci.aol.com>... > > spyng wrote: > > > > > >so how are the memory access from both side. > > > > > >port a : addr[0] = [12:0] of data b location 0 > > >port a: addr[1] = [25:13] of data b location 0 > > >.. > > >.. > > >port a: addr[1022] = [12:0] of data b location 511 > > >port a : addr[1023 = [25:0] of data b location 511 > > > > > For a COREGEN created dual port blockram, if you still have > > version 1.0 of the COREGEN dual port RAM datasheet (COREGEN 2.1i), > > see figure 6 for a nice picture showing where all the bits go > > from each port (note the little-endian mapping of the narrow port > > data to the wider port). Unfortunately, that very useful diagram > > isn't in the latest version of the COREGEN datasheet. > > > > If you can use the COREGEN blockram, by all means do so, as it > > hides the gory details of a variable-width block ram memory > > that spans multiple block ram's. > > > > ----------------------------------------------------------- > > > > If you can't use the COREGEN memory, make sure you understand > > where all the bits go before you slap together your own version > > from the primitives... > > > > When you spread the data across multiple DP block RAM's, it's very > > important to realize that word N on the wide side, as created by > > concatenating the outputs of each block RAM sequentially, is > > composed of interspersed bit fragments of words M, M+1, etc., > > from the narrow side. > > > > This makes for some interesting bit indexing to reassemble the > > memory words, and also makes it impossible to do byte writes > > from the wider port. > > > > I posted some notes on this (for Spartan-II) a while back at: > > > > http://groups.yahoo.com/group/fpga-cpu/message/234 > > "How NOT to build variable width dual port Block RAMs" > > > > > > Summary from this post: > > (pertaining to a "roll your own" 512x32/1Kx16) > > " > > 1) If a variable width dual-port block RAM spans more > > than one block RAM, the output bits of the wider port > > need shuffling to assemble the proper output data word, > > beyond the usual big-endian vs. little-endian swaps. > > > > 2) If you need byte write enables on the RAM, you can't > > use the variable width dual port feature. ( If you can > > live with word writes on the wider port, you're OK. ) > > > > 3) To use byte write enables, both ports need to be at > > the same port width ( 8 bits or narrower ). > > > > COREGEN notes: > > I looked at the coregen EDIF output for a 1Kx16 / 512x32 > > block RAM; it does the output bit shuffling for you, but > > always builds a little-endian output word on the wider port. > > > > Also, it doesn't allow for byte write enables, which is why > > I didn't use COREGEN in the first place. > > " > > > > BrianArticle: 34107
Rotem, Nallatech have just released the Benblue-II DIME module which can be populated with upto two XC2V10000 FPGAs. For more information check out www.nallatech.com. cheers Robert -----Original Message----- From: Rotem Gazit [mailto:rotemg@mysticom.com] Posted At: 01 August 2001 06:47 Posted To: fpga Conversation: Vitex-II prototyping board Subject: Vitex-II prototyping board I'm looking for a prototyping board containing 3 (or more) XC2V6000 FPGAs. Thanks, Rotem.Article: 34108
Hi Yoram, Nallatech do a wide range of FPGA boards ranging from Spartan-II upto the latest Virtex-II devices.They also provide user friendly software to allow you to implement your design very quickly. Check out the web page www.nallatech.com regards, Robert -----Original Message----- From: yoram@puc.cl (Yoram Rovner) [mailto:yoram@puc.cl] Posted At: 06 August 2001 20:33 Posted To: fpga Conversation: I NEED TO BUY A FPGA BOARD Subject: I NEED TO BUY A FPGA BOARD Hello: I need an advice on which fpga board buy. Somebody could tell me which one has best software, documentation support, etc. Thanks Yoram Rovner yoram@puc.clArticle: 34109
Anyone know how to assign pins to bussed pads? ex: OPAD16, IPAD16, IOPAD16 etc... Can't seem to figure out how to do this anywhere in the sparse documentation. Thanks, Dave.Article: 34110
Harjo Otten schrieb: > > > And stop gating your clocks, please! > > About gating clocks....... Why not, and how not to ???? > > I've got a design and my compiler also says something about gated clocks. > I've checked where these 'gated clocks' were used, and it seems to be in a > clock-selector circuit (It's a serial port design, with a clock selector for > the baud rate). The design works well, so I've never paid much attention to > it and besides that, I haven't got the slightest idea on how to solve these > gated clocks. Any hints ??? Use clock enable instead. This is a save and clean method, works for highest frequencies, uses dedicated CLB ressources (CE input, and saves so other ressources) and is ABSOLUTLY glitch free. The story behind "not using gated clocks" is long and Iam too young to tell them at all. For your baud rate clock selector. You need to define a progamable counter which outputs a singe pulse every N cycles. Use this pulse as your clock enable. -- MFG FalkArticle: 34111
Mark wrote: > > Well after further searching on the internet I was able to find a site that > seems to be the maintainers of the LPM library. And at the following URL > http://www.edif.org/lpmweb/more/vhdl.htm they have a downloadable VHDL > library for the LPM library. I will try this and see if it works with > Xilinx Foundation. ----- lpm style code will work with Xilinx parts for some synthesizers. See the earlier comp.lang.vhdl thread: "Re: RAM - VHDL - Altera,..." --Mike TreselerArticle: 34112
Hello, I am trying to model the delay on a bidirectionnal data signal between a FPGA and a synchronous SRAM chip for a testbench, what I want to model is - the clock to output time of the FPGA Data pins + PCB routing delay - the SRAM data access time + PCB routing delays for unidirectional it's easy, i just do something like RAM_Clk <= FPGA_Clk after T_cko+T_pcb NS; but for bidirectionnal port I'm stuck, I tried various things like TOP : FPGA port map ( ... DQ => FPGA_DQ, ... ) MEM : RAM port map ( ... DQ => RAM_DQ, ... ) followed by RAM_DQ <= Transport FPGA_DQ after T_cko+T_pcb Ns; FPGA_DQ <= Transport RAM_DQ after T_ram+T_pcb Ns; But i get UUUUUUUU as value for these signals during simulation. any idea of what's wrong ? Thanks, stevenArticle: 34113
I have been following this thread and also the thread Xilinx BRAM failures. We have been experiencing a high fallout rate using the Virtex -E component. We are seeing hard failures and have isolated to the cell level. We have been working to get failure analysis done at Xilinx but it has been a slow process. We have also sent components back for retest at Xilinx that were not isolated to a cell level, these components are failing the functional tests at Xilinx.(No conclusion drawn here as I don't know what the failing mechanism is yet) One of the devices that isolated to a hard failure to the cell level did not fail the functional test at Xilinx and we are waiting on test results on the rest. Xilinx has stated that no one else is having problems with the Virtex - E parts but it sounds like some other folks are . I will go back up in the thread ,as I recall another individual stated that they had sent a part in for analysis but did not know the results. The BRAM failure thread ended with a person - achlys4now making the statement that Xilinx has recalled stock from distributors for rescreening. Something about metal particle defects shorting routing channels around BRAMs. I have sent that person an email but have not heard back.I don't know if this is true or not. If anyone has any helpful information please pass along. regards,joe Austin Franklin wrote: > > I may be talking out of my hat, but it seems that most posters are > > missing one point. We all my have done a lot of designs and we may have > > worked with a lot of chips, but Joshua's application exercises many > > chips with many different designs each and every time. If he does not > > find the "hidden" defects, his customers will find them. In your > > designs, you may have a few iterations of a given design, but you likely > > have many, many fewer than 100. Even those will have a lot of > > commonality. So if you don't exercise all of your boards with a lot of > > different and possibly "exotic" designs, you may not see anything like > > the defect rates Joshua is talking about. > > I'm not missing what he said...I just don't buy it, since it hasn't been > proven with any reasonable certainty. There has been no mention of the > errors being hard...and that makes me suspicious. I really only buy things > like this when they stand up to peer review (or make sense ;-), and since I > can't see the tests, the conditions, or the failures. > > These "errors" he is seeing may be caused by some uncharacterized issue, > like I stated in another post, or some tool problem allowing > routes/conditions that should not be done. Not actual part failure. I > don't know, and I am not willing to accept conclusions as such without > proper information. The subject that he (Joshua) brought it up IS > interesting.. I am not saying that this is the case here, but I found quite > a number of times, in similar circumstances, that a claim is made, and the > conclusion is erroneous.Article: 34114
Allan, I would be interested in knowing what the outcome of the failing device was. Also who are you dealing with at Xilinx? Wondering if it is a different group than I have been dealing with on the failures we are seeing. regards - joe c. Allan Herriman wrote: > On Wed, 01 Aug 2001 10:13:05 +1200, Jim Granville > <jim.granville@designtools.co.nz> wrote: > [snip] > > We've had failures here of a similar nature. The fault was definitely > inside the FPGA, and would only occur for one particular route. > Re-routing the design (i.e. making it use different resources inside > the FPGA) would make the fault disappear. > > That route worked fine on other boards. > > The design (in the area that was failing) was completely synchronous, > and met the timing requirements comfortably. The failure wasn't > affected by clock speed or temperature variations, so I'm fairly sure > it wasn't speed related. > > The board that failed had been x-rayed as part of its regular > manufacturing inspection, and was believed to have all required power > connections to the FPGA intact. > > Xilinx asked for the relevant part to be returned for analysis. I'm > not sure what the final conclusion was, but I could chase it up if > anyone is interested. > > Regards, > Allan.Article: 34115
Philip, I didn't know about that BRAM feature. Neat! -andy Philip Freidin wrote: > > One of the best features of the BRAM is that the two ports DO NOT have to be > the same width. There are many applications where you want to do rate > conversion, and one of the common ways is with changing the width of the > data. i.e. Data arrives at 100MHz, byte wide, and is passed on to the next > section 32 bits wide at 25MHz. Since these are real dual port memories, > the clocks for the A and B ports can be different, so the ports can even be > in different clock domains. Normal domain crossing issues still apply. > Could also be used in a serial to parallel to serial conversion scheme, > since you can set a port to 1 bit wide. This lets you combine SerDes > functions with buffer/FIFO functions in the same block. > > As for the original question, the mapping of where the data goes, > this is documented on page 117 of > > "Virtex-II Platform FPGA User Guide" > > which is document ug002.pdf at > > http://www.xilinx.com/products/virtex/handbook/ug002.pdf > > (it's 11.5 MBs) > > or just get the section you need: > > http://www.xilinx.com/products/virtex/handbook/ug002_ch2_blockram.pdf > > (300 KB) > > For other docs, see > > http://www.xilinx.com/products/virtex/handbook/index.htm > > On Mon, 13 Aug 2001 18:06:00 GMT, "Andy Peters <andy [@] exponentmedia" <".> > com"> wrote: > >I would imagine that the ports need to be the same width, and of course > >your memory depth will be the same on both ends. > > > >If you need to, for whatever reason (and I've needed to, actually), have > >the memories "look" different on each side, you'll have to design some > >logic to make it do so. > > > >-andy > > > >spyng wrote: > >> > >> hi all, > >> I have a question regarding dual port ram with different data width. > >> > >> I have a dual port ram configure as > >> port A 1024x13 > >> port b 512x26 > >> > >> so how are the memory access from both side. > >> > >> port a : addr[0] = [12:0] of data b location 0 > >> port a: addr[1] = [25:13] of data b location 0 > >> .. > >> > >> port a: addr[1022] = [12:0] of data b location 511 > >> port a : addr[1023 = [25:0] of data b location 511 > >> > >> is this rigth? > >> any one know where is this in the virtex 2 manual? > >> > >> thank > >> spyng > > Philip Freidin > FliptronicsArticle: 34116
I have a PLD circuit which requires a clock signal. I'm thinking it'd be really nice if I could use some of the otherwise unused gates (along with a cap and a couple of resistors) to generate the clock. Is this a bad idea, doomed to failure or is this sort of thing done all the time? With respect to timing circuits in general, can PLDs be used in place of discreet logic gates? In this particular case I'm using a Lattice ispLSI1016E. thanks, ericArticle: 34119
While the total memory is 18K bits, you can only get at 16K of it in the 1,2, and 4 bit wide modes. See the fig on page 117. The data is not packed/unpacked as you ask (below). The width is fixed at design time as 1, 2, 4, 9, 18, or 36 bits. If what you want is 13 bits, then you will have to select the 18 bit path, which is 2 x (8 + 1) . While 2 of these bits are described as parity, the reality is they are no different to the other 16 bits of the 18 bit wide path. you can choose any 13 of the 18 for your application. The remaining 5 bits will be unused/ignored (wasted). Side note: if one port is 1, 2, or 4 bits wide, and the other is 9, 18, or 36 bits wide, the "parity bits" will only be accessable on the port that is 9/18/36 bits wide. On 14 Aug 2001 06:46:42 -0700, ospyng@yahoo.com (spyng) wrote: >just cursious, so the block ram can be see as a 18K x 1 bit memory, >and if I have a data width of 13. >it is going to pack the data in [12:0], [25:13], [38:26] ...... >and not as a 16 bit block, and have the last 3 bit ignore? >thanks >spyng Philip Freidin FliptronicsArticle: 34120
There is a list of various FPGA development boards on The Programmable Logic Jump Station at the following link. http://www.optimagic.com/boards.html aelmousa@yahoo.com (Ali) wrote in message news:<4eede02c.0108140256.6fd35d23@posting.google.com>... > Hello All, > > I am looking for reasonably priced development boards that use FPGAs. > The boards should be for application development and not for testing > purposes. They should use the PCI bus interface in a PC. I am not > interested in going into the details of programming the PCI interface > if an FPGA is used for that purpose. > > It is preferable to have parts of the PCB board available for in-house > circuit additions also. Memory subsytem is not very important on the > board. > > Any help with knowledge of availability of such boards, vendor > addresses, web pointers, prices etc will be greatly appreciated. > > Thank you. > > AliArticle: 34121
You should be able to do this in the UCF file. You will need to know the exact name of each signal though. It will look something like this: net "bus_name[0]" loc=a12; net "bus_name[1]" loc=b12; net "bus_name[2]" loc=c8; net "bus_name[3]" loc=d5; One way to get the final output names (might not have "[ ]" ) is to run the design without the "loc" constraints, bring up the result in the FPGA editor, and then poke around the I/O cells to see what the final names look like. The .PAD file is probably also useful. Here are two lines from one of my .PAD files: | io_c13 (L01P_1) | OUTPUT | C13 | LVTTL | 12 | SLOW | | | io_d12 (L02P_1) | OUTPUT | D12 | LVTTL | 12 | SLOW | | Here are the two lines from my .UCF FILE NET io_d12 LOC = D12; NET io_c13 LOC = C13; While not a bus, it at least shows the syntax Philip On 14 Aug 2001 09:16:53 -0700, dpariseau@compuserve.com (David Pariseau) wrote: >Anyone know how to assign pins to bussed pads? >ex: OPAD16, IPAD16, IOPAD16 etc... > >Can't seem to figure out how to do this anywhere >in the sparse documentation. > >Thanks, > >Dave. Philip Freidin FliptronicsArticle: 34122
Anyone out there have a working NetScape filter for this stuff ? A good list of source addresses to exclude e.g. nowhere.com ?Article: 34123
Rick Filipkiewicz wrote: > Anyone out there have a working NetScape filter for this stuff ? > > A good list of source addresses to exclude e.g. nowhere.com ? Well, how about if I give a plug for newsguy? http://www.newsguy.com/ I have free access to the pacbell (my isp) nntp server, but I never use it. Instead, I pay for newsguy. Because, well, pacbell has there head up ... Newsguy, and the other hand, is a professional organization that really knows how to run a news server. I never see that porno stuff, nor any of the recent "hipcrime" stuff. It is worth every penny (and it really is not very many pennies). -- My real email is akamail.com@dclark (or something like that).Article: 34124
Eric Inazaki wrote: > > I have a PLD circuit which requires a clock signal. I'm thinking it'd > be really nice if I could use some of the otherwise unused gates (along > with a cap and a couple of resistors) to generate the clock. > Is this a bad idea, doomed to failure or is this sort of thing done all the > time? Somewhere in-between :-) Low Frequency RC oscillators, of 2/3 terminal design, are impractical in CPLD due to lack of pin hysteresis. For low Freq sources, we use HEF4541, available in SO14. For medium Freq, a TinyLogic single gate makes a good osc source. You can quite safely build a 3 terminal OSC, (for higher precision), using an external TinyLogic gate and a PLD 'gate'. These solutions also keep the Icc down. At higher freqs, > appx 5MHz, it is possible to construct 2/3 terminal osc, with care. You need to do your own margin testing. Better may be to removce the R's and C's entirely: We have designed completely buried oscillators in the ATMEL ATF150X family of cpld, using a chain of foldbacks. I am not used to Lattice, but the Atmel devices have an option for a single inverter in the 'corner of a macrocell', that can be used for simple tasks, without loosing the whole macrocell. The foldback delay is 2.8nS/5.5nS for low/High power MC switch, so the lowest Freq from a single block OSC of 15 foldbacks in series, is 6MHz and 12MHz. This will of course vary with Vcc, Temperature and Process changes, but many designs do not care too much about the clock freq. You can also chain these Foldback's as delay lines. > With respect to timing circuits in general, can PLDs be used in > place of discreet logic gates? If you mean RC timing, like 4528, 4093, 40106, HC14, then no. If you mean counter chains, like 4060/4040 then yes. > In this particular case I'm using a > Lattice ispLSI1016E. > > thanks, > eric ======= 80x51 Tools & PLD IP Specialists ========= = http://www.DesignTools.co.nz
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