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
z80@ds.com (Peter) wrote:
> Impressive.
> But unless I am wrong, this is based on the Newton-Raphson method
> ((N/a)+a)/2 with a fixed number of iterations. That is what the
> unrolled loop is about. So the accuracy depends strongly on the
> initial guess.
I don't know, it could be Newton-Raphson. It's based on an
algorithm for long-hand square roots that my Father taught
me when I was but a wee child: "Multiply by 2 and shift left
one digit." Fortunately, this works in base 2 as well as base
10. There's no initial guess -- the alogorithm consumes exactly
two bits and produces exactly 1 result bit for each iteration.
The "Unrolled version" is simply an asynchronous implementation
of the loop with some FPGA-based optimization for the initial
two iterations.
A schematic representation of the (asynchronous) algorithm
can be found at
http://eseserver1.fnal.gov/eseproj/trigger/sqrt16.pdf
(Sorry about the text formatting on my original post. The
news poster seems to have wrapped all of my lines together.
I don't really write code like that.)
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 8626There are now a lot of IP cores makers around, that make business on providing cores for the system-on-a-chip. Does anybody produce FPGA cores, since FPGA is also part of system often. Does it possible at all? -- Dmitry Cherniavsky, ASIC designer. MailTo:cdm@javad.ruArticle: 8627
Austin Franklin wrote: > > I hear a lot about porting designs to other technologies, yet I > personally have never done that....and...I don't know anyone who has > either. I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe > it is as prevelant as the proponents of portable design methodologies > have like 'us' to believe... I agree that the number of people using the portability of HDLs is small, but we are out here. We started our design in an Orca 2C40, migrated to a Xilinx XC4062XL for more "leg-room," moved to a Chip Express gate array for initial shipping volume, and will ultimately be targeting a standard cell process for minimum piece price. Our design is Schematic capture for block connectivity only and VHDL below that. We use component instantiation for clock buffers only. Our system clock is 28.6 MHz, so we don't have PCI's 66 MHz speeds to deal with, but we do have 13 DMA channels including video and audio feeds. We made no code changes going from Orca to Xilinx and only had to change the clock buffers going from Xilinx to Chip Express. (We had to add the clock buffer instantiations to ease the Chip Express synthesis process.) No one can argue that a good schematic design will be smaller AND faster then an HDL design. If we had used schematics, we possibly could have stayed in the 2C40, however, our migration to Chip Express and the follow-on standard cell would have been significantly harder and more time consuming. I don't have the time or the desire to develop a generic symbol set into which I could plug all of the possible libraries I may use. Also, since we knew that our ultimate target was an ASIC, an HDL was a natural choice. We just happened to benefit from that choice when we had to move from Orca to Xilinx. What it comes down to is use the appropriate tool for the job. You don't use a hammer to pound a screw. Don't use an HDL if speed or gate count are your primary concerns. Don't use a schematic if portability (or arguably) time-to-market is what you need. If you need all of the above, good luck! ToddArticle: 8628
Ryan Herbst wrote: > It has come to my attention that the 4000E series xilinx > have a series problem when it comes to using the ram elements. > > It is my understanding that if the write clock signal is held high > for more than a millisecond, permanent damage to the device can be > caused. Hold it ! It's not that bad.Our documentation just got overly careful in warning the user that: "...excessive current and even damage to the larger devices if many CLBs are configured as edge-triggered RAM". This problem exists only on XC4000E devices. It is fixed on all XC4000EX and XC4000XL devices. The problem on XC4000E stems from a dynamic node in the write circuitry. After the active write edge, the addressing and data lines in the RAM are not held at a dc level, but can float. This does not affect the write operation in any way, but it can result in poorly defined cross-current when the input to an inverter drifts through the half-supply-voltage range. The max current per inverter is something like 100 microamps ( I will post the exact value later, right now I quote from memory ). Each CLB has 18 of such nodes ( difficult to explain why 18, please believe me ). For a short while ( milliseconds ) after parking write clock at the "forbidden" level, each CLB configured as a synchronous RAM can thus conduct up to 1.8 mA, but he current disappears again as the nodes drift away from the "bad" voltage. There is no local problem with this current. Transistors and metal can carry that current forever, and the localized heating is minuscule. The problem comes when large numbers of CLBs are used this way. An XC4010 has 400 CLBs, If each one were configured as a synchronous RAM ( a perverse assumption of a meaningless design, but it is the worst-worst case ) then the dc current could be as high as 720 mA = 3.6 W. But it would last only a fraction of a second each time.. Well, you might exercise this circuit again and again. That's why we are cautious. On bigger parts, under the same unrealistic assumptions, the total current would be proportionally larger. That's why the data book issues that infamous warning. We should have said: "100 CLBs can conduct up to 180 mA i.e. up to one watt for a limited time". Instead we chose to say: "Don't do this, it might hurt the device". Sometimes it is wise to isolate the user from the gory details, sometimes it is unwise. You be the judge. Anyhow, the XC4000EX and XC4000XL don't have this floating node and tolerate, therefore, any clock High and Low time. I hope this clarified the situation, I will follow this up with a later e-mail giving you the exact number. The peak current is clearly determined by the transistor geometry. The duration depends on leakage current and thus temperature. Peter Alfke, Xilinx ApplicationsArticle: 8629
Hello, Is anyone doing a synchronous DRAM interface in an FPGA? If so, at what speeds? This is for ASIC prototyping only, so FPGA cost is not a big issue. Anybody got some Orca -20's or Xilinx -01's lying around? :-) SDRAMs are rated at speeds up to 100 MHz. When my boss tells me he wants to do this in an FPGA, I just look at him funny. ToddArticle: 8630
It's often called the "schoolbook" algorithm. -- C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-FAQ Book: ISBN 0-201-84519-9. Want Software? Algorithms? Pubs? http://www.infoseek.com husby@fnal.gov wrote in message <884797100.345767949@dejanews.com>... >z80@ds.com (Peter) wrote: > >> Impressive. >> But unless I am wrong, this is based on the Newton-Raphson method >> ((N/a)+a)/2 with a fixed number of iterations. That is what the >> unrolled loop is about. So the accuracy depends strongly on the >> initial guess. > >I don't know, it could be Newton-Raphson. It's based on an >algorithm for long-hand square roots that my Father taught >me when I was but a wee child: "Multiply by 2 and shift left >one digit." Fortunately, this works in base 2 as well as base >10. There's no initial guess -- the alogorithm consumes exactly >two bits and produces exactly 1 result bit for each iteration. >The "Unrolled version" is simply an asynchronous implementation >of the loop with some FPGA-based optimization for the initial >two iterations. > >A schematic representation of the (asynchronous) algorithm >can be found at > http://eseserver1.fnal.gov/eseproj/trigger/sqrt16.pdf > >(Sorry about the text formatting on my original post. The >news poster seems to have wrapped all of my lines together. >I don't really write code like that.) > >-------------------==== Posted via Deja News ====----------------------- > http://www.dejanews.com/ Search, Read, Post to UsenetArticle: 8631
Does anyone know if it is possible to program a Flex10k device through a parallel port following the schematics in the byteblaster datasheet without using a byteblaster cable, or we must necessarily employ a byteblaster cable ? In other words, I'm asking if the byteblaster is a simple cable or it has some associated circuitry. Thank you.Article: 8632
On 12 Jan 1998, Eric Lo wrote: > Date: 12 Jan 1998 09:58:57 GMT > From: Eric Lo <mflo@cse.cuhk.edu.hk> > Newsgroups: comp.arch.fpga > Subject: VHDL to GigaOps >=20 > How can I transfer VHDL to GigaOps Board? How can I interface it?? > I have found in the GigaOps homepage, however, I can't nothing useful. >=20 > Thanks >=20 > --=20 >=20 > +------------------------------------------------------------------+ > Eric, Lo Man Fai =BFc=A4=E5=BD=F7 One way to solve the problem is as follows (roughly) : 1. From the .lnk file produce a .vhd and .xnf using XGEN and XCNT programs. This contains the interface design. (you may need to make changes in the variable names which is restricted to some length. ex : host_rd_data is too long...) 2. Using Xilinx Foundation, generate a macro of the interface. 3. Write user code in .vhd and convert that into macro. 4. Connect the macros (interface & design) in the schematic. 5. Convert the schematic to edn/edif netlist format and using subsequent tools convert it to a .bit file. I hope this helps. -HamidArticle: 8633
Hi,
I am relatively new to VHDL and FPGAs in general and have a bit of a
problem.
I was told that it is possible to use a schematic entry macro from
within VHDL,
but I am unable to get this to work. The particular macro which I want
to use
is an 8 bit counter (CC8CLE). I define the interface and instantiate the
counter
in VHDL and then synthesise a macro from the VHDL code, all this seems
to
work. However, when I then use this macro back in schematic entry and
try and
comile it I get the following error :
ERROR:basnu - logical block "U1/CNT" of type "cc8cle" is unexpanded.
My guess is that my specification of the interface to the counter is not
right,
but I do not know how else to specify it.
I am using Foundation 1.3.
The VHDL code is I am trying to get to work is:
-- vhdl test
library IEEE;
use IEEE.std_logic_1164.all;
entity test4 is
port (
D_IN: in STD_LOGIC_VECTOR(0 to 7);
L_IN: in STD_LOGIC;
CE_IN: in STD_LOGIC;
C_IN: in STD_LOGIC;
CLR_IN: in STD_LOGIC;
Q_OUT: out STD_LOGIC_VECTOR(0 to 7);
CEO_OUT: out STD_LOGIC;
TC_OUT: out STD_LOGIC
);
end test4;
architecture test4_arch of test4 is
component
cc8cle port ( D: in STD_LOGIC_VECTOR(7 downto 0);
L: in STD_LOGIC;
CE: in STD_LOGIC;
C: in STD_LOGIC;
CLR: in STD_LOGIC;
Q: out STD_LOGIC_VECTOR(7 downto 0);
CEO: out STD_LOGIC;
TC: out STD_LOGIC);
end component;
begin
CNT: cc8cle port map (D=>D_IN,
L=>L_IN,
CE=>CE_IN,
C=>C_IN,
CLR=>CLR_IN,
Q=>Q_OUT,
CEO=>CEO_OUT,
TC=>TC_OUT);
end test4_arch;
Any help wold be greatly appreciated. Thanks.
Remek.
Article: 8634Ivan wrote: > Does Atmel cary any larger EEPROMS (larger than 256K)? I also saw > that Atmel has a programmer for the EEPROMS. Are there > schematics/software available for the ones who would like to build it > themselves? > > Thanks, Ivan > > >In article <34B33324.7BFA@netas.com.tr>, > > Yekta Ayduk <yekta@netas.com.tr> wrote: > >> > >> Do serial EEPROMS exist for Xilinx configuration in the market to > >> replace Xilinx OTP PROMS? > > > >Atmel makes them, for more details check out : > > > >http://www.atmel.com/atmel/products/prod182.htm > > > >Martin Mason > >Atmel Corp. > > > >-------------------==== Posted via Deja News ====----------------------- > > http://www.dejanews.com/ Search, Read, Post to Usenet Check out the cost of those EEPROMS. They look more expensive than standard UV and Flash parts in the parallel arrangement. Depending on board space and cost constraints, you might want to consider using a standard parallel part and a cheap PLD to serialize it. There are advantages to that approach for debugging too. Xilinx has an app note outlining this approach, along with the PLD code (ABEL). See http://www.xilinx.com/apps/config.htm App note XAPP079 (PDF format). Good luck. John Moore Cisco SystemsArticle: 8635
Billy Bagshaw (bill@highwater.co.uk) wrote: : Hi all, : I'm looking at Jam. Has anyone any advice. I downloaded the kit but : it would not decompress. (I've fallen at the first hurdle). Which jam ? Jam the the Prolifics transaction tool ? (http://jam.prolifics.com/) Jam the make replacement ? (http://www.perforce.com/jam/jam.html) Jam the JTAG language ? (http://www.altera.com/jam) (Why didn't they pick a different name for the JTAG stuff ??) Graeme Gill.Article: 8636
Nova's Constellation FLEX 10K Development Board, and Altera's MAX+PLUS II software, combine to offer logic designers unprecedented simplicity and flexibility. The 3.5" x 3.8" circuit card currently supports FLEX 10K devices from the 10K20 up to the 10K100A, and should accommodate future FLEX devices such as the 10K130 and 10K180. The PC/104 form factor brings the power of programmable logic to the widespread markets of embedded PC systems and desktop PC's. The stackable PC/104 architecture gives designers access to gate capacities in excess of 500,000 gates! Many Constellation users are integrating Constellation boards directly into their products and systems. One customer application requires the Constellation board to be plugged into a PC ISA slot. Two electronic systems are then physically connected through the Constellation board via ribbon cables. The FLEX device provides custom signal processing logic while the PC acts as the man-machine interface. Another customer is presently designing the Constellation board into an embedded PC/104 system for use with their data communications products. Other customers are using Constellation boards for ASIC prototyping and logic verification. These customers typically implement their logic designs in Constellation boards so they can perform real-time, real-world testing of their products before committing the design to an ASIC. Likewise, several colleges and universities are using Constellation boards for research and senior projects. Applications include hardware accelerated algorithms, parallel processing, and custom logic development. Large gate capacities combined with fast and flexible configuration methods, have made the Constellation board the logic designers choice. Some customers are combining AMPP Megafunctions with Constellation boards, to provide immediate solutions to their needs. For example, one customer uses Nova's Bit Synchronizer Megafunction and a Constellation FLEX 10K20 board to provide critical timing synchronization when testing communications products at low signal to noise ratios. Constellation is also ideal for developing, testing and demonstrating Megafunctions and soft cores. The price and availability of Constellation boards offer quick and cost effective access to PLD hardware. The design, debug, layout, fabrication and test, of a circuit card similar to Constellation, would typically cost thousands of dollars in NRE and take several weeks, if not months, to complete. Many designers don't have access to the manufacturing technologies required to fabricate boards using devices with 0.0197" pin spacing. Nova Engineering's Constellation FLEX 10K boards are fabricated using state-of-the-art manufacturing equipment, are fully tested and can be purchased for under $500, with next day delivery. Each board also includes ISA design examples and C source code to accelerate PC/104 and ISA designs. Educational and quantity discounts are available. Constellation development boards have been shipped to customers all over the U.S., Canada, Italy, Norway, Sweden, and Japan. Customer satisfaction appears to be very high. (Example: www.acte.no/freecore/nova.htm). Constellation customers include companies such as Seagate Technologies, Altima Corp., Cleveland State University, Epson R&D, Motorola, Intel, Escort Corp. (a.k.a. Cincinnati Microwave), Caterpillar, San Francisco Telecom, IOWave , and many more. A few customers have even upgraded their MAX+PLUS II software to the full featured Magnum package, so they can maximize their use of Constellation. Please call us at 1-800-341-NOVA or visit our Constellation web page at: www.nova-eng.com/constellation.html for the latest technical information and pricing. ---------------------------- Paul Krotchen Nova Engineering 5 Circle Freeway Cincinnati, Ohio 45246 Email: paulk@novaengr.com Voice: 513.860.3456 ext102 Fax: 513.860.3535 Web: www.nova-eng.com ----------------------------Article: 8637
Actually, Byteblaster is made with a 74LS744 and 4-5 registers. Thanks Gianluca ÀÌ(°¡) <69jgas$5ld@deun23.corp.newmont.com> ¸Þ½ÃÁö¿¡¼ ÀÛ¼ºÇÏ¿´½À´Ï´Ù... >Does anyone know if it is possible to program a Flex10k device through a >parallel port following the schematics in the byteblaster datasheet without >using a byteblaster cable, or we must necessarily employ a byteblaster cable >? >In other words, I'm asking if the byteblaster is a simple cable or it has >some associated circuitry. > >Thank you. > > >Article: 8638
Gianluca wrote: > > Does anyone know if it is possible to program a Flex10k device through a > parallel port following the schematics in the byteblaster datasheet without > using a byteblaster cable, or we must necessarily employ a byteblaster cable > ? > In other words, I'm asking if the byteblaster is a simple cable or it has > some associated circuitry. > > Thank you. We made our own byteblaster from a datasheet (not sure if it is the same as the one you have) and it is very simple. A 74HCT244 is the only IC involved and a few resistors. Pennies to make when the one from Altera cost ~120 pounds sterling. The only problem we had was that when we daisy chained several 10K devices together, we got write failures which were dependent upon the I/O card we were using. This was strange because the 244 fully isolates the 10K devices from the I/O port. We found that older I/O cards could program at least 5 devices, whilst a modern card could only manage about 2. Steve. -- ****************************************************************** * Steve Emm, Philips Semiconductors, Southampton, U.K. * * email: steve.emm@soton.sc.philips.com (seri: semm@ukpsshp1) * * tel : +44 1703 316544 (fax : +44 1703 316303) * ******************************************************************Article: 8639
Hal Murray wrote: > > In article <01bd1c3f$fa791ac0$6aef1fce@przebienda.acromag.com>, "Louis Przebienda" <lprzebienda@acromag.com> writes: > > If you are using something like a well mounted power brick > your best bet is probably one of the magic voltage-watcher > chips. I gave up on RC time-delay kludges ages ago. > Yes we gave up on RC and have been using the Texas TL7705 for 10+ years! In small amounts they cost us £0.28 = about 45 cents. And that's here in the U.K. They un-reset Td after VCC reaches 4.55V where Td can be varied with an external capacitor. -- _________________________________________________________________________ Dr. Richard Filipkiewicz phone: +44 171 700 3301 Algorithmics Ltd. fax: +44 171 700 3400 3 Drayton Park email: rick@algor.co.uk London N5 1NU EnglandArticle: 8640
Checkout the freecore home page for the circuit! try http://193.215.128.3/freecore/ The page is well worth a look if you use Altera EPLD products Paul D.H. Chung wrote > Actually, Byteblaster is made with a 74LS744 and 4-5 registers. > > Gianluca wrote > >Does anyone know if it is possible to program a Flex10k device through a > >parallel port following the schematics in the byteblaster datasheet without > >using a byteblaster cable, or we must necessarily employ a byteblaster > cableArticle: 8641
On Thu, 15 Jan 1998 19:00:41 +0900, "D.H. Chung" <dhchung@soback.kornet.nm.kr> wrote: Yes, but my Byteblaster is made with a LS244, 7 resistors and 2 capacitors. Good luck, Victor Levandovsky >Actually, Byteblaster is made with a 74LS744 and 4-5 registers. > >Thanks > >Gianluca ÀÌ(°¡) <69jgas$5ld@deun23.corp.newmont.com> ¸Þ½ÃÁö¿¡¼ ÀÛ¼ºÇÏ¿´½À´Ï´Ù... >>Does anyone know if it is possible to program a Flex10k device through a >>parallel port following the schematics in the byteblaster datasheet without >>using a byteblaster cable, or we must necessarily employ a byteblaster >cable >>? >>In other words, I'm asking if the byteblaster is a simple cable or it has >>some associated circuitry. >> >>Thank you. >> >> >> > >Article: 8642
Does anybody have synopsys libraries for the Xilinx 6200? Also, has anybody booted the XC6200 using a serial PROM and then switched it into parallel mode to reconfigure when it is running? Can you describe any tricks that are necessary to get this to work correctly? (I haven't tried it yet, but I want to know if there are any snafus that I can avoid.) Herman ------------------------------------------------ Herman Schmit, Ph.D., Research Engineer Department of Electrical and Computer Engineering Carnegie Mellon University 5000 Forbes Ave., Pittsburgh PA 15213 Tel: (412) 268-6470 FAX: (412) 268-3204 email: herman@ece.cmu.eduArticle: 8643
> I was told that it is possible to use a schematic entry macro from
> within VHDL,
......
> comile it I get the following error :
>
> ERROR:basnu - logical block "U1/CNT" of type "cc8cle" is unexpanded.
>
> My guess is that my specification of the interface to the counter is not
> right,
> but I do not know how else to specify it.
You dont say what your schematic port names are, but problem might be the expantion of VHDL array port names matching schemtic port names.
By default this is :
(cell cc8cle (celltype GENERIC) (view view_1 (viewType NETLIST)
(interface
(port (rename D_7 "D<7>") (direction INPUT))
(port (rename D_6 "D<6>") (direction INPUT))
(port (rename D_5 "D<5>") (direction INPUT))
........
You can change this to :
(cell cc8cle (celltype GENERIC) (view view_1 (viewType NETLIST)
(interface
(port D7 (direction INPUT))
(port D6 (direction INPUT))
(port D5 (direction INPUT))
........
which might be what your schematic netlists to.
By adding the following after the component declaration in your VHDL.
attribute macrocell : Boolean;
attribute macrocell of cc8cle : component is true;
See also the section Synthesis Attributes in vhdl_mug.hlp
Article: 8644In article <34B90D3F.A75@ids.net>, Ray Andraka <no_spam_randraka@ids.net> wrote: >what is inside the function. I continue to believe that a well laid out >schematic is much more readable than HDL code. I will admit that it is >easier to put comments on an HDL design (but I also think they are more >necessary there). Hear, hear! completely in concurrence... This depends quite heavily on one's choice of schematic pkg, of course. For instance, one of my colleagues frequently has more lines of explanatory text on his schematics than drawn line segments. But, they're still easier to see through (for me) than pages of VHDL... >as with schematics. In both cases, the development of a heirarchical >library of lower level functions speeds the design process in subsequent >projects. Again, some thought given to the structure of schematic libraries and their extension, goes a long way to making abstraction just as useful in schematic capture as it is for an HDL... >I've always found it a bit amusing to observe that the electronics >design industry is pushing away from a graphical design methodology >(schematics) while most other disciplines are flocking toward graphical >user interfaces. Two further points: One sees that HDL tools are laying graphical assists on top of the text-based tools (FSM tools, Summit's block diagrammer, etc.). Secondly, its horses for courses - use each as it might seem appropriate, and that means for me that I don't want GUI tools stuffed down my throat either, like this lemming-like march towards NT. FWIW, Arnim. -- Arnim Littek arnim@actrix.gen.nz Actrix Networks Ltd. fax +64-4-801-5335 uucp/PPP/SLIP/BBS accounts tel +64-4-801-5225Article: 8645
philip typed here, possibly a tad too fast: : >: I believe that Richards problems with rampant clock skews are because he : >: is not using Xilinx global clock buffers. rk writes: : >Me types here, possibly too early in the morning, slightly insulted. :-) philip lands nicely on his feet: : No insult was intended. I'm sorry. It was meant as humor, since I knew : you were using Actel chips. oops, sorry, thought it was a nasty-gram directed at me for someone elses clock skews. and comments like that are not good for business! perhaps next time put a smiley on - it would help, esp. when it's early in the a.m.! as for actel, it is *EASY* to get into clock skew trouble. with the a1020's you had to be a bit careful and for good solid hold times it sometimes pays to go in with chipedit and move some stuff around, esp. w/ wide temp range. and ppl still do designs with the old a1020 2.0 stuff. but with their newer clock designs they do really really well. i heavily loaded them (day job) with some long shift registers and they always worked well - both in simulation and in temp testing: -55C to +125C. but with act 3 and separate i/o clock network, again, gotta watch that skew. the major source of clock skew problems is when people new to the fpga architectures do board design in an fpga and assume that a wire on the chip is like a track on a pcb. can't see any delay elements there and it does look good even when not on a global net on the schematic. another way ppl get into trouble is with running a non-global clock into a soft macro such as a parallel counter or a shift register. rk babbles on: : >so, i can repeat my question, possibly the fpga manufacturers can answer: : >do the models that they supply model clock skew in the logic simulation : >accurately enough for timing analysis? philip replies: : I suspect that the answer will be no, because the timing information that : the place and route tools that I am familiar with, only report worstcase : delays, and usually for the situation that generates longest delays, : which is high temp, and low voltage. Skews that are derived from such : info are not the worst case, which is when a long clock delay is at its : worst, while simultaneously, some other clock delay is at better than its : worst. The situation is exacerbated by the issue that you are doing stuff : at (I believe) low temperature, for which the FPGA timing analyzers do : not report temperature based delay info. rk replies to philip: as for the back annotation of clock skews into the logic simulators, perhaps peter or stu or john or hans [philly hans, not england hans] (listed in no particular order) can answer. if i get some time, i'll try the actel -> viewsim path. if i get a real lot of time (prob. in 15 years when kids leave the house), i'll do the q-logic -> viewsim path, as i just finished my first q-logic pasic3 design. now, from my simulation experience, i have found that clock skew is w.c. at high volt, low-temp case, best process. and with at least actel static timing analysis tools (timer or dtanalyze) the temperature, voltage, process corner is selectable for analysis. also, you can specify whether you want max or mins reported. for max the tsu is included; for mins it is not. for min the th is reported and included, for max it is not. IIRC (somebody with a better memory please chime in), tskew used to be reported and included in the calculations. i just ran a sim in 3.1.1 update 1 and didn't see the skew reported. anyways, it's not that bad to have the static timing analyzer report all of the clock delays to each of the clock pins to determine max skew, for each given condition. also, with limited experience w/ spde (q-logic), it seemed not too bad to set the conditions. details of calculations i can't comment on yet. philip finshes up: : Sorry again for the un-intended insult. rk adds: np, worst-things have happenned. glad it all worked out quickly, who needs hassles here? that's what day jobs are for :-) -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 8646
rk chimed in: : > and as stu pointed out, the designs are : > more portable, austin replies: : I hear a lot about porting designs to other technologies, yet I : personally have never done that....and...I don't know anyone who has : either. I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe : it is as prevelant as the proponents of portable design methodologies : have like 'us' to believe... rk wisecracks: ... nor quite as easy unless care is taken up front to make hdl code portable, esp. when switching synthesis tools and architectures. but it will be interesting to find out. i remember, back in the '80s, when we were into writing portable c code, they told us how easy it was ... ... and i did as much coding as possible, secretly in pascal. austin continues: : And...why aren't schematics portable? Mine are (for the most part...). : I make hierarchical one bit symobols for elements like flops, I/O : elements etc, and these are all that has to change from technology to : technology. I've developed an entire library of different combinations : or elements and pin counts for I/O elements (say 16 bit bi-directional : flop in, tri-state out...) and for registers and counters and tri-state : buffers and muxes and... Random logic is a bit more difficult, but you : can do a global change on the symbol named AND3B2 to what ever the new : technology name is...it really does't take that long. rk agrees and disagrees: i've done stuff like that too - although not for performance driven designs. another benefit is that it lets you use a single set of tools for design like a good macro generator (big fan of them). then just replace primitive hard macros and you're in there. more or less. but the architectural differences can hurt you, in my opinion. either in time for tuning, size of circuit, or for circuit speed. for example, for an xor tree (important for pci) you can design a simple tree of xor gates, logically correct. but an implementation tuned to the architecture can be much faster by taking into account the fpga 'module' resources. i've seen the output of a good macro generator and it would be tough to beat, if possible, in quality (i.e., final circuit speed) although i hate to admit it. and other architecures with good-sized sram blocks could do table lookup algorithms which wouldn't mesh well with a gate by gate translation. programmable clock signal polarity for flip-flops: if an architecture doesn't support that directly, compensating for that by making a logical equivalent would have hold time problems when the real solution would be to use either the inverted clock tree if available or a separate clock tree. of course you could design a logically equivalent circuit and only use 1 edge but you burn more power in the clock distribution network. another factor is the available function in the i/o cells: i have seen the following for storage in the i/o: zip, two latches, two flip-flops w/ enables, only an input flip-flop, some with feedback into the array so you can use unused pins modules for logic, etc.. in schematics this would have to be hand tuned. would a good hdl synthesis tool take this into account and do the shuffling around for the designer? i would hope so. it would have to to make things high quality and portable and shield the designer from the architecture. another case would be the availability of f-f's with negative outputs. some architectures got 'em, some don't. again, the virual hard macro library here would work logically but not for maximum performance, unless a netlist optimizer could pick up the slack and combine things appropriately. a last example would be counters: some architectures you can do real compact, high-speed, low-power ripple counters - some architectures don't let you and make you drive a whole column of clocks. some architectures are better at decoding terminal counts of 0000...000 than 1111...111 so it would favor down counters rather than up. so state assignment can be critical. are the hdl tools good enough to take this into account? is there still room for good humanoid gate-slingers? :-) i've heard a bunch of ppl say no - they haven't used a schematic in ages and get upset at the thought of using schematics. even to hook up reasonably sized blocks implemented in hdl. -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 8647
It is true some people would rather "picture" the design than to read behavioral code. Although I agree HDL is far more efficient I do like to get a structural idea of what is going on in my code. My preference is to have a top level schematic instantiating lower level macros in either HDL or Schematic depending on the timing requirements. In article <34bebc3d.0@news.actrix.gen.nz>, Arnim Littek <arnim@atlantis.actrix.gen.nz> wrote: >In article <34B90D3F.A75@ids.net>, >Ray Andraka <no_spam_randraka@ids.net> wrote: >>what is inside the function. I continue to believe that a well laid out >>schematic is much more readable than HDL code. I will admit that it is >>easier to put comments on an HDL design (but I also think they are more >>necessary there). > >Hear, hear! completely in concurrence... > >This depends quite heavily on one's choice of schematic pkg, of course. >For instance, one of my colleagues frequently has more lines of >explanatory text on his schematics than drawn line segments. But, >they're still easier to see through (for me) than pages of VHDL... For some reason, I never found comments in schematic to be very useful. But in HDL they certainly help when you inherit a design done by another engineer. HDL is definitely easier to upgrade. > >>as with schematics. In both cases, the development of a heirarchical >>library of lower level functions speeds the design process in subsequent >>projects. > >Again, some thought given to the structure of schematic libraries and >their extension, goes a long way to making abstraction just as useful >in schematic capture as it is for an HDL... > >>I've always found it a bit amusing to observe that the electronics >>design industry is pushing away from a graphical design methodology >>(schematics) while most other disciplines are flocking toward graphical >>user interfaces. > >Two further points: > >One sees that HDL tools are laying graphical assists on top of the >text-based tools (FSM tools, Summit's block diagrammer, etc.). > >Secondly, its horses for courses - use each as it might seem appropriate, >and that means for me that I don't want GUI tools stuffed down my >throat either, like this lemming-like march towards NT. I believe it depends on how the options are implemented in the GUIs. In FPGA Express it is extremely difficult to add, for example, pin locations. However, I consider synplicity to be one step ahead since most of the options (almost none) are available in the GUIs. Basically, all you have to do is to press the RUN button. Hernan Saab > >FWIW, > >Arnim. >-- >Arnim Littek arnim@actrix.gen.nz >Actrix Networks Ltd. fax +64-4-801-5335 >uucp/PPP/SLIP/BBS accounts tel +64-4-801-5225Article: 8648
The /bin directory of Max+PlusII(only for workstaion version), you can find the utility called genmem, which generate VHDL/Verilog HDL model for memories Altera supports. You can only use EABs when you are implementing CSFIFO(actually you can but you need huge logic cells to create this, which depends on the size of memory you want)with Altera device but you can have HDL model for those memories implemented in EAB. So you can use this file when you want to go ASIC. Thanks D.H. Greg Hoffman ÀÌ(°¡) <34BC0CDE.1914@adichi.com> ¸Þ½ÃÁö¿¡¼ ÀÛ¼ºÇÏ¿´½À´Ï´Ù... >I'd like to know if there's any way, using a 10K50 part, to compile a >CSFIFO block into the part and not let it use the EABs. What I need to >do is generate a register-only implementation of the FIFO for later >compatibility with an ASIC process. > >Also, is there any way to generate a VHDL/EDIF/Verilog output file >without all of those delay cells? > >Thanks, >Greg Hoffman >hoffman@adichi.comArticle: 8649
Herman Schmit wrote:
>
> Does anybody have synopsys libraries for the Xilinx 6200?
We do have. The libraries for Synopsys DC are included in the
SunOs-version of XACTStep 6000.
>
> Also, has anybody booted the XC6200 using a serial PROM and then
> switched it into parallel mode to reconfigure when it is running? Can
> you describe any tricks that are necessary to get this to work
> correctly? (I haven't tried it yet, but I want to know if there are
> any snafus that I can avoid.)
Sorry, but I never tried this!
Hope that helps.
Frank
____________________________________________________________________
LOOK AT OUR WEB SERVER: http://xputers.informatik.uni-kl.de
Frank Gilbert | University of Kaiserslautern
mailto:gilbert@informatik.uni-kl.de | Dept. of Computer Science
fax: ++49/0 631 205 2640 | Germany
..._/ _/ _/_/_/ _/ _/ _/_/_/ _/_/_/ _/_/_/ _/_/ ....._/
..._/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ ......._/_/
..._/ _/_/_/ _/ _/ _/ _/_/_/ _/_/_/ _/_/ ._/_/_/_/_/
._/_/ _/ _/ _/ _/ _/ _/ _/ _/ ...._/_/
_/ _/ _/ _/_/ _/ _/_/_/ _/ _/ _/_/ ....._/
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