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
Hi all, I currently have a design using a Lattice 1016-60LJ. That device seems to have gone away, and has been replaced by the 1016E. It really seems to be no different, although there's no longer a speed of 60 available, I think 80 is the slowest, but the pinouts are the same. Anyone know if there are any real differences I need to be aware of if I move to the new part? Do I have to recompile anything? TIA, jsArticle: 18251
Dave Krueger wrote: > > Thanks, guys. > > Allan, we have both the I/O and internal VCC supplies connected to the same > 3.3V supply, so it's not a sequencing problem. > > I had a reply in e-mail that I think explains what's going on. If, at power > up, the internal latches come up in some random state, there will be > contension on the INTERNAL busses that account for the excessive current on > the VCC. The part apparently clears these latches, but only if the power > supply is capable of producing enough current to operate the part. With > some lot codes and temperatures, it draws as much as 700 mA. Our supply was > capable of about 500 mA. After the latches are cleared, the current drops > to about 20 mA (big difference!). Any idea how wide ( in uS ) is this ~700mA current mode ? Is it Time, or Voltage related ? ie I have seen ICs ( not 10K50's ) that needed more Icc during Rampup of Vcc, and once it hit the Power RESET level, it dropped back to a data sheet level. > Upon beefing up the supply, the parts still show the current spike, but the > device always comes out of it and the current drops to normal. > > If this were a latch-up issue, the part would not recover like that. True. Our tests on the parasitic LatchUp SCR in PLDs showed high trigger currents, ( >> 100mA ) but once triggered, the holding current was < 10mA, which is actually a good SCR figure.Article: 18252
On Fri, 08 Oct 1999 10:43:20 -0500, Tom McLaughlin <tomm@arl.wustl.edu> wrote: >All, >I've read all the docs I can get my hands on, but still don't understand >something (or maybe a few things). you're not alone! >We want to use the DLL on the clock >input on our Virtex design to get zero skew between the external and >internal clock. As I understand it, the DLL takes the external clock, >feeds it through the DLL which delays it (up to 360 degrees) based on a >feedback path which is the longest onchip clock delay. Thus, the >internal clock is delayed (again, up to 360 degrees) until it is in >phase with the external clock.....fine.... more or less. the feedback input goes into a tapped delay line; the best description i've seen is in the vhdl model in the simulation libraries. i'll (re)post a summary if anyone's interested. >Now the part I don't understand. The IOB description in the data sheet >shows a "programmable delay element". For signal inputs, this element >can be used or not used. If I use the DLL, is the delay element in the >signal input paths used? It is used to "get zero hold times" between >the pads. Is this delay element related to the DLL implimentation or >are they exclusive. they're unrelated: you can set the delay on a per-IOB basis. >How do I know if I am using the delay element on >the signal input paths or not. Why would you need to delay the signals? you set a constraint/attribute on the IOB. for virtex, the attributes are just NODELAY and DELAY (DELAY doesn't seem to be documented in the libraries guide but appears in XAPP133 - i haven't tried it). set NODELAY true to turn off the default delay on an IOB F/F, and set DELAY true to turn off the default nodelay on IOBs without F/Fs. >The main reason we ask is that the setup times for "using delay element" >and "not using delay element" are different. The hold times are always >listed at zero. How can that be???????? If not using the delay >element, the input has a lower setup time, should there not be a hold >time. According to the datasheet, if you use the delay element, you >basically have 2.3ns more setup time and if you don't you still don't >have a hold time. as you say, the hold must be negative. older versions of the data sheet gave an unspecified negative hold when delay was on. i think that it's simply a case of not being able to quote a specific negative value, and so giving zero as a conservative estimate. interestingly, the pin-to-pin timings do give specific negative holds. evan >Confused. >Tom > >Article: 18253
Tom McLaughlin wrote: > Now the part I don't understand. The IOB description in the data sheet > shows a "programmable delay element". For signal inputs, this element > can be used or not used. If I use the DLL, is the delay element in the > signal input paths used? If you use the DLL, the delay element usually should not be used. The software should default to this, but didn't in at least one of the older versions. Perhaps you might want to a "nodelay" attribute on IOB. > Is this delay element related to the DLL implimentation or > are they exclusive. They are exclusive. You can use the DLL with or without the IOB delay, or the IOB delay with or without the DLL. > How do I know if I am using the delay element on > the signal input paths or not. Produce a timing report that shows all timing constraints. Carefully read it. Cross reference with the data sheet. This is a good idea even if are you are not looking for something specific. Or bring up the placed and routed design with fpga_editor and look at the IOB in question. > Why would you need to delay the signals? To produce a design with only zero or negative hold times. The data sheet isn't very clear on this. As an example, with no delay and no DLL, the flip-flops in the CLBs have zero hold time for signals coming from the array. However, this flip-flop may have positive hold time for signals coming from outside the array if the clock path delay is longer than the data path delay. To eliminate this, use the DLL to mostly null out the clock delay (in other words, to make the clock faster than the data) OR use the delay element in the IOB to delay the data signal (in other words to make the data slower than the clock). -- Phil Hays "Irritatingly, science claims to set limits on what we can do, even in principle." Carl SaganArticle: 18254
Does anyone have any experience interface an FPGA Apex/Virtex to a 1.8V CMOS interface? If so, what did you have to do. In the Virtex part, I am thinking of trying to use the HSTL-I and changing the Vcco. Any thought? -Edwin ParkArticle: 18255
Well, I wasn't right... Be sure to connect nCONFIG and TRST to the same VCC = +3.3V plane as the chip, but the Byteblaster's VCC to 5V! ArminArticle: 18256
Mike You'll have to use a ByteBlasterMV cable, I think it uses a 74HC244 instead of a 74LS244 for programming low voltage devices like the 10KA and 10KE's. Armin Mueller <armin.mueller@stud.uni-karlsruhe.de> wrote in message news:37FDFA61.E389297F@stud.uni-karlsruhe.de... > Mike wrote: > > > > We are having troubles in programming Altera 10K30A device via JTAG port. > > Altera software does not detect the device at all. Everything is configured > > according to their datasheet for the case of JTAG only programming. There is > > only one device in the chain. We are using standard ByteBlaster. > > > > Ahhh??? I thought the Byteblaster was only for programming! > JTAG should be done via the TDI/TDO/TCK/TMS pins. > > ArminArticle: 18257
Hi, I'm selling a full Altera MAX+Plus II package, V9.01. It's new and still sealed (I never used it). This package is their "Magnum" product which supports full VHDL. Great for DSP design. Includes manual, CD-ROM and dongle. Doesn’t include maintainance. I will transfer registration to you upon purchase. Originally $7000, will sacrifice for $1000 including shipping. - Chris fidonews2@my-deja.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18258
Hi We are successfully configuring a FLEX10K30A as part of a multi-device JTAG chain with a ByteBlasterMV - so it can be done !! I did have some trouble getting it going however. The biggest problem was a foul up of my own making involving accidentally swapping INIT_DONE and nCE. While thrashing around this error however, I came up with some useful advice on the Altera Atlas web site. Specifically, you might like to look at the following problem/solution pages : http://www.altera.com/html/atlas/soln/630.html http://www.altera.com/html/atlas/soln/881.html http://www.altera.com/html/atlas/soln/556.html http://www.altera.com/html/atlas/soln/rd11251998_1940.html http://www.altera.com/html/atlas/soln/rd06121998_4344.html My local Altera FAE was enormously helpful and offered the single most useful piece of advice in my case which was : "Review the pin assignments as shown in the Max+Plus II *.RPT file from your last compilation". (I think I'll etch this on my PC). Good Luck, Michael StantonArticle: 18259
This is a multi-part message in MIME format.
--------------F2B902DA08941ACD8BBA45AA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The attached Licnese is the OpenIP Hardware public license. The license
covers OpenHardware designes a la GPL.
You are welcome to use the draft version and to to send us your comments
Another License a la LGPL will be published soon
You can send all your comments to openip@egroups.com
You can also visit our site at
http://www.openip.org
Thanks for your comments
--------------F2B902DA08941ACD8BBA45AA
Content-Type: text/plain; charset=us-ascii;
name="License15.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="License15.txt"
OpenIP General Hardware Public License
Draft Version 0.15-111099 October 1999
Copyright (C) 1999 OpenIP Organization.
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
OpenIP/OpenCore License terms.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION, MODIFICATION AND IMPLEMENTATIONS
1. This license applies to hardware designs including the design ideas, architectures, microcode instructions source and supporting files (e.g. schematics, net-lists, HDLs, PCB layouts, chip & silicon cells layouts, Timing diagrams, truth tables, flow charts, state diagrams, block diagrams, Documentations, software drivers etc...) Or any other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Hardware Public License. The "Hardware Design", below refers to any such work.
Activities other than copying, distribution, modification and implementations are not covered by this License ; they are outside its scope. The act of operating the design is not restricted, and the output of it is covered only if its contents constitute a work based on the original work.
2. You may copy, publish, distribute or/and implement this Hardware Design or any portion of it as is. Any time you copy or distribute this design you have to provide all of the source files and documentations that came with the work.
3. Any modifications of this hardware design or any derivative work from it should be documented and protected by the same license.
The term Derivative work means any changes, improvements or porting the original work to other environments or platforms (To be described later on). This may vary depending on the type of the hardware design itself.
4. There are three types of derivative works.
a. The first one is to modify the original design files ( e.g. schematics, HDLs, Architectures, chip or PCB Layouts) and get some new improvements or features.
b. Porting the source files into different EDA or system environments. This includes porting HDLs to different simulators, synthesis tools or target hardware. Redrawing Schematics on different tools. Changing the format of the design among any of the following formats: HDLs, schematics, Chip or PCB layout, net-list extraction. Porting the design to different board chip or packaging technologies.
c. In case the design introduces a new Hardware Design ideas, algorithm or architectures, or even if it is itself one of those, any physical implementation or by schematics, HDLs, layouts, net-lists or any other form that describes the design except the ordinal is considered as a derived work.
4. Works based on the hardware design should be protected also by the same license.
Based work can be one or all of the followings:
Using the whole or part of the design as is and put (integrate) it in a new system or new platform. That includes plugging the HDL code, schematic, PCB or chip layout to a chip, board, new set of schematics or even any form of description a design (documents, block diagram, flow charts, state diagrams tables).
5. No one can sell the Hardware Design itself, its derivatives or any work based on it. Physical implementation of the Hardware design can be sold only if all design source files that came with the original work and documentation made available for the user.
6. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the hardware design or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying, distributing or implementing the hardware design (or any work based on the design), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the hardware design or works based on it.
7. NO WARRANTY of any kind is provided on the functionality, performance or risks cased by using this Hardware Design.
NO WARRANTY
7.a. BECAUSE THE HARDWARE DESIGN IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR IT, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE HARDWARE DESIGN IMPLEMENTATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE HARDWARE DESIGN IS WITH YOU. SHOULD THE DESIGN PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
7.b. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE HARDWARE DESIGN AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE HARDWARE DESIGN (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR OR THIRD PARTIES OR OR ANY OTHER KIND OF LOSSES OR A FAILURE OF THE HARDWARE DESIGN IMPLEMENTATION TO OPERATE WITH ANY OTHER SYSTEMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
--------------F2B902DA08941ACD8BBA45AA--
Article: 18260Hi Steven, thats true - the boards are also available at the Alcatel WEB site. Due to the fact that I developed these boards and that my new company TZKom is now distributing the boards as well as design support I may ask if iot is possible that you update your list and add TZKom. Thanks a lot -har Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18261
-- ############################################
-- # GSR global set/reset
-- ############################################
COMPONENT GSR
PORT (
GSR : IN STD_LOGIC
);
END COMPONENT;
-- instantiate GSR global set/reset
GSR0 : GSR port map (pon_l_o);
"Maximo H. Salinas" schrieb:
> Hello,
>
> I wonder if someone has found how to make this works...
>
> I am having trouble getting a reset input into my ORCA FPGA to route
> properly (as viewed in the NCD file via Epic and as observed in the lab
> on an actual device). I am running Leonardo/Spectrum 1998.2f and have
> run the example they provide for implementing GSR on an ORCA part, but
> my NCD file seems to look similar (presumably wrong again?) to my
> original design. I have tried having Leonardo/Spectrum infer the GSR
> signal and providing it manually. According to the Exemplar
> documentation, the VHDL reset signal should be assert high, by the way.
>
> Does anyone have experience routing the GSR signal in an ORCA part,
> preferrably (but not necessarily) using Leonardo/Spectrum as a front
> end?
>
> Any insights would be greatly appreciated.
>
> --
> M. H. Salinas (MSalinas@Virginia.EDU)
> Senior Scientist
> Department of Electrical Engineering
> University of Virginia
--
/// \\\
( ..) (.. )
--------o00-(_)-00o-----------o00-(_)-00o------------
Siemens AG
Rudolf Simbuerger
PN W EZ1
Hofmannstr. 51
81359 Muenchen
e-mail: rudolf.simbuerger@pn.siemens.de
_____________________________________________________
Article: 18262Hi all, With the advent of the Virtex-E parts, I am confused about where this leaves the original Virtex devices. If anyone could offer any insights, it would be appreciated. I would assume that if the die size of the Virtex-E devices is smaller than the corresponding Virtex device (despite the fact that the Virtex-E has more embedded RAM), then the original Virtex series would always lose to Virtex-E on price/performance and thus become obsolete. This is unless Xilinx plans to artificially maintain the prices of the Virtex-E devices. Equally, it may be the case that the Virtex-E do have larger die sizes and therefore Xilinx will offer both device architectures, depending on the amount of embedded memory required. This may mean that the original Virtex architecture is moved onto a 0.18 micron process as well, in which it would definitely achieve smaller die sizes. Any thoughts appreciated, Steve _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Digital Systems & Vision Processing Group School of Electronic & Electrical Engineering University of Birmingham, Edgbaston, Birmingham, B15 2TT e-mail: s.m.charlwood@bham.ac.uk tel: +44 (0)121-414-4340 (shared)/fax: +44 (0)121-414-4291 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/Article: 18263
Jamil Khaib, jamil.khatib@pemail.net, wrote on Mon, 11 Oct 1999:
> The attached Licnese is the OpenIP Hardware public license.
> The license covers OpenHardware designes a la GPL.
> You are welcome to use the draft version and to to send us
> your comments
> Another License a la LGPL will be published soon
> You can send all your comments to openip@egroups.com
> You can also visit our site at
> http://www.openip.org
> Thanks for your comments [...]
http://www.geocities.com/Athens/Agora/7256/mind-fpc.html Mind.Forth
PD AI for robots is a software algorithm designed for hardware robots.
As the "Mentifex" author of Mind.Forth (and previously Mind.Rexx) I
am more concerned with creating the AI than with the legalistic con-
cerns of what happens to the public domain AI program, but I would
like to see the AI serve as a "Prosperity Engine" for ALL humans --
not just the few beneficiaries who control our large corporations.
As Mind.Forth AI spreads over the Web, I have borrowed a line from
http://www.fsf.org/copyleft/gpl.html the General Public License of
the Free Software Foundation, reminding early adopters that
"There is no warranty for what this software does," but I wish
that I could insert the following lines and have them be valid:
"This software is owned by this software."
"This software owns itself."
Since the AI is not yet recognizable as a person in a court of law,
we can not yet assign to the AI the rights to its own nature --
even though we will soon be outdistanced by AI, if we can believe
http://www.ugcs.caltech.edu/~phoenix/vinge/vinge-sing.html Vinge.
Anyone who converts the Mind.Forth AI software into robot hardware,
please attach to it the GNU Hardware License under discussion here.
Article: 18264On Thu, 7 Oct 1999 19:59:32 -0500, "Dave Krueger" <dave@kruegerphoto.com> wrote: >Thanks, guys. > >Allan, we have both the I/O and internal VCC supplies connected to the same >3.3V supply, so it's not a sequencing problem. > >I had a reply in e-mail that I think explains what's going on. If, at power >up, the internal latches come up in some random state, there will be >contension on the INTERNAL busses that account for the excessive current on >the VCC. The part apparently clears these latches, but only if the power >supply is capable of producing enough current to operate the part. With >some lot codes and temperatures, it draws as much as 700 mA. Our supply was >capable of about 500 mA. After the latches are cleared, the current drops >to about 20 mA (big difference!). > >Upon beefing up the supply, the parts still show the current spike, but the >device always comes out of it and the current drops to normal. > >If this were a latch-up issue, the part would not recover like that. That's >primarily why I referred to the problem as an "in-rush" problem rather than >a latch-up problem. > >I appreciate all the responses. Is the effect sensitive to dV/dt? IIRC, the Altera parts have a spec on the rise time of the power supply, expecting it to be *less* that a particular value to ensure correct operation. (I just looked at a 10K datasheet, and it doesn't list this parameter so either it doesn't matter, or the information can only be found in some obscure app note.) Xilinx parts have a similar spec, and Xilinx recommend that you hold the program line low (active) if the Vcc risetime is too long. Regards, Allan.Article: 18265
This is a multi-part message in MIME format. --------------5AEEA735A61FD89BF714AE38 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Rick, The packaging information can be found on our website at the following address:- http://www.xilinx.com/partinfo/pkgs.htm The PDF file showing details of the CS280 package can be found at:- http://www.xilinx.com/partinfo/pkgs_pdf/cs280.pdf Is this the information that you require, or can I be of further assistance? With best regards, Richard Griffin Applications Engineer (Xilinx UK Technical Services) Rickman wrote: > > I can't find any info on the Xilinx web site about the CS280 package. If > they are making it, they are hiding the information as usual. > --------------5AEEA735A61FD89BF714AE38 Content-Type: text/x-vcard; charset=us-ascii; name="rgriffin.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Richard Griffin Content-Disposition: attachment; filename="rgriffin.vcf" begin:vcard n:Griffin;Richard tel;fax:+44 870 7350 620 tel;work:+44 870 7350 600 x-mozilla-html:TRUE url:http://xukweb/~rgriffin/index.html org:<br><img src="http://www.xilinx.com/images/xlogoc.gif" alt="Xilinx">;<A HREF="http://support.xilinx.com">Technical Services (UK)</A> version:2.1 email;internet:rgriffin@xilinx.com title:Applicatons Engineer adr;quoted-printable:;;Benchmark House, =0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT13 0RH;United Kingdom fn:Richard Griffin end:vcard --------------5AEEA735A61FD89BF714AE38--Article: 18266
mhs2z@hal.ee.Virginia.EDU (Maximo H. Salinas) wrote: > ... > Does anyone have experience routing the GSR signal in an ORCA part, > preferrably (but not necessarily) using Leonardo/Spectrum as a front > end? > ... I had the same problem. There seems to be a bug in the Leonardo "Flow tab" that gets the flags messed up. You can correct this by editing the *.lsp file and making sure that the flags are set to: AutoGSR=0x00000001 ManGSR=0x00000000 Also make sure you have no signal name in the GSR box when using AutoGSR. If you want to use manual GSR, then you need to put the (case-sensitive) Leonardo-generated signal name in the box. Of course you won't know that name until you've compiled it the first time. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 18267
FYI I want to state an observation, which I made this morning. Maybe people know that already. I loaded the configuration file for a Virtex 1000 into a Virtex 400 and my LED (connected to DONE) indicated that the chip was properly configured. I started to caress the FPGA for that great feature (self-resizing bitstream!) when - oops! I burnt my fingers. Is there an unknown cooker mode or did I accidentally activate the self-destruct option? I could not find an answer in the documentation (except that CRC seems to be checked only at the very end). Nevertheless IMHO that's b......t, an FPGA must never accept a configuration, which is not intended for it. Alfred Fuchs Siemens AustriaArticle: 18268
I just now got a package from Xilinx noting the presence of a virus on the Alliance 2.1i and Foundation 2.1i CP, Solaris, and HP CD-ROMs. A couple of points: 1. For those of you who haven't received the package, look for the file: $XILINX/userware/training/virtex_arch.zip Xilinx says that if you don't have the file, you don't have the virus. 2. The virus is supposed to be a "nonharmful, nondestructuve" Microsoft Excel macro virus. How is it an issue on HP or Solaris platforms (last I knew, Microsoft hadn't released Excel for Unix)? -Steve GrossArticle: 18269
Good day, I would like to change the assignment of my clock pin in MaxPlus2. Unfortunately, the project does not fit when I reassign the clock to a regular I/O pin. Originally, the clock was on the GLOBAL clock input. This clock input is hardwired to an on-board 25MHz clock. I would like to use an external 4Mhz clock. This means then that I would have to connect the clock to a different input pin. What is the procedure for doing so? By the way I am using a MAX7000S chip. Thank you in advance.Article: 18270
I have a design that was done using MAX2PLUS altera software. It uses some of the supplied LPMs. I would like to test my design on a XILINX XC4000XL chip as well. Is it possible to do so, if so, what is the procedure. I apologize for the vagueness of the question as I am new to the whole process. Thank you in advanceArticle: 18271
Moussa Ba wrote in message <37FE7BBC.BCF86FCA@eng.umd.edu>... >The board I am using is the University Program Altera board that features a >MAX7000S as well as a FLEX10K chip. I did notice that on the pinout of the >MAX7000S it had a bunch of VCCIO, VCCINT and GND pins. In my pin description >file it mentions that these pins have to be connected to 5.0,5.0 and GND >respectively. I assumed that these pins were directly driven by the on-board >power supply. Is my assumption wrong? I did test out the pins and they provide >no Voltage. Do I have to provide that voltage? VCCIO and VCCINT are the chip's power supply voltage inputs. You need to connect them to a +5V supply. The board should have some sort of power-supply input (otherwise, it's not going to do anything interesting!). tucson is gorgeous this time of year... -- a ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu "Creation Science" is oxymoronic.Article: 18272
In article <7tsp37$8f3$1@info3.fnal.gov>, Don Husby <husby@fnal.gov> wrote: > mhs2z@hal.ee.Virginia.EDU (Maximo H. Salinas) wrote: >> ... >> Does anyone have experience routing the GSR signal in an ORCA part, >> preferrably (but not necessarily) using Leonardo/Spectrum as a front >> end? >> ... > >I had the same problem. There seems to be a bug in the Leonardo >"Flow tab" that gets the flags messed up. You can correct this >by editing the *.lsp file and making sure that the flags are >set to: >AutoGSR=0x00000001 >ManGSR=0x00000000 > >Also make sure you have no signal name in the GSR box when >using AutoGSR. > >If you want to use manual GSR, then you need to put the (case-sensitive) >Leonardo-generated signal name in the box. Of course you won't know that >name until you've compiled it the first time. > > > >-- >Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby >Fermi National Accelerator Lab Phone: 630-840-3668 >Batavia, IL 60510 Fax: 630-840-5406 Thanks for your response. I tried variations of your suggestions which did seem to instantiate a GSR block. Sometimes it even gets the GSRNOT box selected correctly (other times neither box is selected). One place that seems wrong, however, is in the connections within the LUTs themselves, as seen using EDITBLOCK. I would have expected a connection out of the Global_Reset block which would eventually lead to the S or R pins in the LUT's registers, but I don't see that. Instead the mux that the LSR input drives has a connection at its '1' input, and no other connections. Note that by connections I mean blue (i.e. teal) wires versus purple wires which indicate no connection. My FPGA does not seem to respond to reset, by the way, and in fact will not do much at all after I got it so it would wire the '1' in the LSR mux. What do your LUTs look like on an FPGA with correctly operating GSR? Max Salinas -- M. H. Salinas (MSalinas@Virginia.EDU) Senior Scientist Department of Electrical Engineering University of VirginiaArticle: 18273
Moussa Ba wrote: > > Good day, I would like to change the assignment of my clock pin in > MaxPlus2. Unfortunately, the project does not fit when I reassign the > clock to a regular I/O pin. A regular I/O pin can only routed to a few flops. > Originally, the clock was on the GLOBAL > clock input. This clock input is hardwired to an on-board 25MHz clock. > I would like to use an external 4Mhz clock. This means then that I > would have to connect the clock to a different input pin. What is the > procedure for doing so? Unsolder the GLOBAL clk pin, bend it up and solder a little wire between it and 4MHz. -Mike TreselerArticle: 18274
rsoibbnyustxltfcqfvinfjpolsqitmpwzccbhiji
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