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
Yep, received a reply directly from VCC just after I posted this mail, tried to cancel the message but my computer crashed!!!!! - oh the wonders of service pack 4 Many thanks anyway John Schewel wrote: > The Virtual Workbench release had been delayed due to a delivery problem > on BG352 Virtex FPGAs by Xilinx. > > The problem has been corrected according to our sources. We have been > informed production of this virtex package is on schedule now. > > The VW-300 is being assembled this week. We are sorry for the delay. > > -- > > Best Regards, > John Schewel, VP Marketing & Sales > Virtual Computer Corp. -- Bio-Inspired Architectures Department of Electronics University of York, UK http://www-users.york.ac.uk/~dwb105Article: 16926
In article <376849CB.306CB265@vcc.com>, jas@vcc.com says... > The Virtual Workbench release had been delayed due to a delivery problem > on BG352 Virtex FPGAs by Xilinx. I would like to ask another question about VCC's products. VCC's web pages advertised in February/March that VCC is going to bring to market a daughter card for H.O.T. II that has Virtex XCV300. At the moment I cannot find any information on your web pages concerning this daughter card. What is the situation with this card at the moment? Does VCC have any plans to bring that Virtex daughter card to market? What will be the schedule? I am just a little worried since the main reason for purchasing the H.O.T. II was the fact that this Virtex Card should have come to market soon... BR, Kalle Palomäki, Tampere University of TechnologyArticle: 16927
that was our initial plan as well until the VW came out. Not too sure oth= er than I received a mail about a Hot III PCI board. Best contact info@vcc.com - they've been a great help to me before "Kalle Palom=E4ki" wrote: > In article <376849CB.306CB265@vcc.com>, jas@vcc.com says... > > The Virtual Workbench release had been delayed due to a delivery prob= lem > > on BG352 Virtex FPGAs by Xilinx. > > I would like to ask another question about VCC's products. VCC's web > pages advertised in February/March that VCC is going to bring to market= a > daughter card for H.O.T. II that has Virtex XCV300. At the moment I > cannot find any information on your web pages concerning this daughter > card. What is the situation with this card at the moment? Does VCC have= > any plans to bring that Virtex daughter card to market? What will be th= e > schedule? > > I am just a little worried since the main reason for purchasing the > H.O.T. II was the fact that this Virtex Card should have come to market= > soon... > > BR, > Kalle Palom=E4ki, Tampere University of Technology -- Bio-Inspired Architectures Department of Electronics University of York, UK http://www-users.york.ac.uk/~dwb105Article: 16928
Jack Greenbaum <jack@mesa.greenbaum.org> wrote: > Tim Tyler <tt@cryogen.com> writes: >> Say I am implementing a lattice-gas automata in order to simulate >> turbulent fluid flow through a confined space. What earthy use are >> counters or addition and subtraction primitives to me? [...] > Perhaps you'd be interested in some of the purpose-built CA machines > that have been presented at FCCM. This one looks appropriate: > Margolus, N., "An FPGA Architecture for DRAM-based Systolic > Computation," FCCM 1997, pp 2-11. http://www.fccm.org/preprog97.txt contained the only information I could find about this - it was not sufficient for me to be able to say if the approach would be useful or not. I'm interested in CAM-style architectures, though. "Unfortunately", my current designs require a small quantity of housekeeping to be performed by a serial program (currently written in Java) which continuously monitors the automata, and is capable of reading from and writing to a small number of cells while these are in active operation. This suggests to me a hybrid architecture, with an ordinary serial machine (e.g. a PC) connected to the programmable logic via a PCI bridge - rather than a "pure" CAM approach, with a custom machine devoted purely to automata acceleration. -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com Inertia makes the world go 'round.Article: 16929
Gidday there, I'm trying some old fashioned digital design, rather than this VHDL business, and I'm trying to find some programs to do factoring of logic. In university I used 'cnd' from a guy at Michigan State. However, I can't find that any more. Any hints would be appreciated. Oh, and I can't seem to get 'espresso' to compile on linux. Joshua Lamorie Systems Designer Xiphos Technologies Inc.Article: 16930
Hi everybody, sorry for spreading this message into several newsgroups, but I'm looking for DS2 and E2 (yes, that's _2_!) framer chips (or FPGA cores) and don't really know where to start. Search engines didn't come up with something useful, but maybe someone out there in usenet land has a good tip (besides Transwich)? Stefan -- Stefan Wimmer Cellware Broadband Email sw@cellware.de Rudower Chaussee 5 WWW http://www.cellware.de/ 12489 Berlin, Germany Visit my private Homepage: Love, Electronics, Rockets, Fireworks! http://www.geocities.com/CapeCanaveral/6368/Article: 16931
Hi everyone, I am trying out the free version of the Actel Desktop (my main tool is Orcad Express). Top level design is schematic. I followed the recommended procedure for adding an ActGen macro, but the CDB compiler gives the warning "Warning block INV has no view specified and will be ignored" for all the hard macros (the name INV could be any other hard macro used in the module) inside the ActGen module. And when I try to compile the design via Synplicity, the ActGen macros are essentially ignored. It is as if the hard macros inside the ActGen module are treated as hierarchical modules. Any suggestions? Thanks in advance. Sung.Lim@jhuapl.eduArticle: 16932
Zetex offers some interesting Field Programmable Analog Arrays: http://www.fas.co.uk/ Motorola had an switched-capacitor FPAA effort going for a while, but it got canned along with their FPGA family. There's an FPAA FAQ and other info available at: http://www.eecg.toronto.edu/~vgaudet/fpaa/faq.html regards, tom Sandro Wefel wrote: > > Ray Andraka wrote: > > > FPGAs don't have analog elements, but there is no reason you can't use > > them in conjunction with external ADC's, DAC's, PLL's and RF > > components. The FPGA itself is a strictly digital circuit. > > There are some mixed mode FPGA's from the Fraunhofer Institute > of Microelectronic Circuits and Systems Dresden Germany. They > have an analog and digital core and also analog and digital ports. > The problem: there aren't synthesis tools. A simulation tool > for such AFPGAs was part of my diplom thesis and solved > in conjunction with SPICE (not VHDL). > > To contact the FHG watch > http://www.imsdd.fhg.de/ims-dd-e.html > > Regards > Sandro Wefel Tom Burgess -- Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.caArticle: 16933
I see Actel have announced their new proASIC family. This is billed as a cheap (programmable) alternative to using gate arrays. This sounds familiar - Xilinx/Altera have similar product offerings. But it's different in that it's 1) flash-based, and 2) a fine-grained sea-of-gates architecture. Does anyone know why this choice of technology & architecture should prove superior - or even the equal - of those of the 2 big boys ? Because to me "flash-based" means CPLDs, "sea-of-gates FPGA" means Motorola, Toshiba, Xilinx 8K (and what happened to them?). So this product is definitely going against the grain (sorry! couldn't resist!).Article: 16934
http://www.sidsa.com/fipsoc.htm This place something you might want to look at. -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 16935
Daryl Bradley wrote: > that was our initial plan as well until the VW came out. Not too sure other > than I received a mail about a Hot III PCI board. > > Yes we are working on a HOTIII, board prices will range from $995 to $4995. The Virtex daughter board was taken off the site because we were thinking of just offering the daughter board with the HOTIII. We have PCBs in house for the daughter boards and we will build some just as soon as we get some !@#$%^&* parts. The Virtex daughter board will be $4995 for a V800. The pricing on the HOTIII will be _something_ like $995 for V100 $1995 for V300 and $4,995 for V800. Of course all these boards have one meg configuration caches and use the high speed Virtex parallel configuration port (PCP). Each board has 4 meg of fast SRAM (15ns or faster). All the above is advanced information and subject to change at any time. Thanks -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 16936
Hi All, What is the difference between *.bit, *.ubt and *.rbt files. Which one to use to configure the FPGA? Cheers.Article: 16937
PRESS RELEASE - FOR IMMEDIATE RELEASE Silicore Corporation Announces New IP Core Standard for System-On-A-Chip June 21, 1999 - 36th DAC / New Orleans, LA USA. Silicore Corporation announced today a design reuse standard for off-the-shelf IP cores. The new standard is called the WISHBONE INTERCONNECTION FOR IP CORES, and is intended to make IP core integration easier for system-on-a-chip users. The WISHBONE interconnect is a portable and flexible interface for use with semiconductor IP cores. It defines a common, logical interface between IP cores. This improves the portability and reliability of the system components, and results in faster time-to-market for the end user. Previously, IP cores used non-standard interconnection schemes that made them difficult to integrate. They required the end user to create substantial amounts of custom glue logic to connect each of the cores together. By adopting a standard interconnection scheme, they can be integrated more quickly and easily by the end user. The WISHBONE standard can be used with soft, firm and hard IP cores. Furthermore, it can be used with any target architecture (such as FPGA or ASIC devices), and is independent of any hardware description, synthesis, router, layout or other development tools. It is a high performance interconnect where speed is limited only by the IC semiconductor technology. Wade Peterson, President and CEO of Silicore, stated that: "Our research has shown that a major impediment to IP core integration is the lack of a standard, logical interface between cores. The WISHBONE interconnect solves this problem by forming common data exchange formats and bus cycles. We were heavily influenced by the traditional microcomputer buses such as VMEbus and PCI bus, which have served the industry very well for many years. Essentially, WISHBONE forms a microcomputer bus that is tailored to the needs of system-on-a-chip." Peterson also stated that: "We believe that the industry needs this, and have gone ahead and made WISHBONE available on a no cost basis. We are doing this as a public service to our customers and the IP core industry as a whole. Furthermore, it will improve the quality of our own products, as well as to foster cooperation among the users and suppliers of other IP cores." Silicore will be releasing products based on WISHBONE in 3Q/99. For more information, and copies of the WISHBONE specification, see the Silicore web site at http://www.silicore.net, or contact: Wade Peterson at 612-722-3815 or by e-mail at: peter299@maroon.tc.umn.edu.Article: 16938
Hi Sung, Your problem is you probably did not quite follow the directions for placing an ACTgen block. If you run ACTgen from inside of DesignView it will automatically create a symbol under the Place menu Symbol command. When the dialog box comes up you will see VBACTgen and the symbol will be under this heading. Place the symbol from this menu as it is now part of your components to select from. If you created the ACTgen macro outside of DesignView you can still add it as VHDL source it is just that the macro is made from primitive elements from the Actel libraries thus they have "no view", ie. they have no lower level schematic or anything to describe them (this is probably what you did). When this gets passed to the synthesis tool the macro will be treated as regular structural VHDL and be synthesized along with the rest of your schematic (if you are doing a mixed design with schematics and VHDL). Should you be doing a design that is only composed of schematic elements then you should use the "Generate EDIF" command from the Tools menu. There is no need to synthesize your design if it is purely schematic to get to an EDIF for place and route. Hope this helps. Regards, Mike Lee Sung H. Lim wrote in message <37692592.E8D289CC@jhuapl.edu>... >Hi everyone, > >I am trying out the free version of the Actel Desktop (my main tool is >Orcad Express). Top level design is schematic. I followed the >recommended procedure for adding an ActGen macro, but the CDB compiler >gives the warning >"Warning block INV has no view specified and will be ignored" for all >the hard macros (the name INV could be any other hard macro used in the >module) inside the ActGen module. And when I try to compile the design >via Synplicity, the ActGen macros are essentially ignored. It is as if >the hard macros inside the ActGen module are treated as hierarchical >modules. Any suggestions? Thanks in advance. > >Sung.Lim@jhuapl.edu > > >Article: 16939
On Thu, 17 Jun 1999 02:09:42 -0700, Eugene Grayver <egrayver@janet.ucla.edu> wrote: >I am repeating my post since no one had the answer last time. Does >anyone know >the die sizes of the xilinx XC4000 series FPGAs? I need them for a >comparative >study. I don't know myself, but you might want to have a look at http://www.chipsupply.com. They will let you look at die maps online, but you have to fill in an online form for them to send you a password. Hope this helps Dave. -- REPLACE "NOJUNK" in address with "david.storrar" to reply Development Engineer | Marconi Electronic Systems | Tel: +44 (0)131 343 4282 RCS | Fax: +44 (0)131 343 4091Article: 16940
Yeah, I heard that there was a minor?!?!?!?!?! well oky, bit of a nightmare problem getting parts from Xilinx at the moment. Steven Casselman wrote: > Daryl Bradley wrote: > > > that was our initial plan as well until the VW came out. Not too sure other > > than I received a mail about a Hot III PCI board. > > > > > > Yes we are working on a HOTIII, board prices > will range from $995 to $4995. The Virtex daughter > board was taken off the site because we were thinking > of just offering the daughter board with the HOTIII. > We have PCBs in house for the daughter boards and we will build some just > as soon as we get some !@#$%^&* parts. The Virtex > daughter board will be $4995 for a V800. The pricing on the > HOTIII will be _something_ like $995 for V100 > $1995 for V300 and $4,995 for V800. Of course > all these boards have one meg configuration caches and use > the high speed Virtex parallel configuration port (PCP). > Each board has 4 meg of fast SRAM (15ns or faster). > > All the above is advanced information and subject to change > at any time. > > Thanks > -- > Steve Casselman, President > Virtual Computer Corporation > http://www.vcc.com -- Bio-Inspired Architectures Department of Electronics University of York, UK http://www-users.york.ac.uk/~dwb105Article: 16941
Ingo- Sorry, but vhdl2sym.exe does not support the creation of bars over pin names in the symbols it creates. You have to edit the symbol after generation. Regards, -Jim Ingo Purnhagen wrote: > Sorry, forgot my real name; damned Outlock ;-) !!! > > Hi newsgroup, > I have a simple (?) problem using VHDL and Viewlogic. After declaration of > an entity I use VHDL2SYM.EXE to create a symbol for ViewDraw. It works fine, > but I want to have an active low signal (signalname with overline) in my > schematic. > I have no idea how to realize it in VHDL . Any suggestions? > > -- > Ingo Purnhagen > OHB-System GmbH > Universitaetsallee 27-29 > D-28359 Bremen > Telefon: 0421-2020-702 > Telefax: 0421-2020-610 > mailto:Purnhagen@ohb-system.de > http://www.ohb-system.de -- -------------------------------------------------------- James R. Kipps FPGA Marketing Manager jkipps@viewlogic.com Phone: (508) 303-5246 --------------------------------------------------------Article: 16942
Suprisingly, we have no problem getting hold of V1000/BG560. They cost a bit though. >============ Bill Blyth http://www.alphadata.co.uk ============ Daryl Bradley wrote in message <376A146C.D582D32E@ohm.york.ac.uk>... >Yeah, I heard that there was a minor?!?!?!?!?! well oky, bit of a nightmare >problem getting parts from Xilinx at the moment. > > > >Steven Casselman wrote: > >> Daryl Bradley wrote: >> >> > that was our initial plan as well until the VW came out. Not too sure other >> > than I received a mail about a Hot III PCI board. >> > >> > >> >> Yes we are working on a HOTIII, board prices >> will range from $995 to $4995. The Virtex daughter >> board was taken off the site because we were thinking >> of just offering the daughter board with the HOTIII. >> We have PCBs in house for the daughter boards and we will build some just >> as soon as we get some !@#$%^&* parts. The Virtex >> daughter board will be $4995 for a V800. The pricing on the >> HOTIII will be _something_ like $995 for V100 >> $1995 for V300 and $4,995 for V800. Of course >> all these boards have one meg configuration caches and use >> the high speed Virtex parallel configuration port (PCP). >> Each board has 4 meg of fast SRAM (15ns or faster). >> >> All the above is advanced information and subject to change >> at any time. >> >> Thanks >> -- >> Steve Casselman, President >> Virtual Computer Corporation >> http://www.vcc.com > >-- > >Bio-Inspired Architectures >Department of Electronics >University of York, UK >http://www-users.york.ac.uk/~dwb105 >Article: 16943
In fact, I'd suggest NOT using the overbar convention. Some tools may not process the name correctly. The overbar has to be translated into 'some' other character, per se, because one can not have an overbar in a text file ;-) They used to translate it to a tilde. After YEARS of fighting with tool vendors to all come up with ONE convention for active low signals, and getting no where, I got smart and came up with a convention that doesn't use the overbar. It can be any textual convention you want, but I personally use "SIGNAL_L", and it seems to work fine thru all my tools. Austin Franklin austin@darkroom.com Jim Kipps <jkipps@viewlogic.com> wrote in article <376A421A.737B7038@viewlogic.com>... > Ingo- > > Sorry, but vhdl2sym.exe does not support the creation of bars over pin names > in the symbols it creates. You have to edit the symbol after generation. > > Regards, > -Jim > > Ingo Purnhagen wrote: > > > Sorry, forgot my real name; damned Outlock ;-) !!! > > > > Hi newsgroup, > > I have a simple (?) problem using VHDL and Viewlogic. After declaration of > > an entity I use VHDL2SYM.EXE to create a symbol for ViewDraw. It works fine, > > but I want to have an active low signal (signalname with overline) in my > > schematic. > > I have no idea how to realize it in VHDL . Any suggestions? > > > > -- > > Ingo Purnhagen > > OHB-System GmbH > > Universitaetsallee 27-29 > > D-28359 Bremen > > Telefon: 0421-2020-702 > > Telefax: 0421-2020-610 > > mailto:Purnhagen@ohb-system.de > > http://www.ohb-system.de > > -- > -------------------------------------------------------- > James R. Kipps FPGA Marketing Manager > jkipps@viewlogic.com Phone: (508) 303-5246 > -------------------------------------------------------- > > >Article: 16944
Hi,
I've asked this question once before, but it is important (to me) so
here goes again.
I have this freeware Verilog PIC CPU core
(www.mindspring.com/~tcoonan) that I like to play with. I have a
nagging issue related to memories and clocks/instruction. If you know
about the PIC, then you know that it has seperate program and data
memories. My current model uses 2 clocks per instruction because I'm
using "standard" synchronous memories and I can't seem to figure out
how to do everything that needs doing in terms of memory cycles with 1
clock per instruction. I'd like to offer 1 clock/instruction! The
real PIC actually has 4 internal "phases". wheew.. that was a lot to
say. For example, the PIC allows you to execute the following code:
incf counter1, counter1
incf foo, foo
incf bar, bar
The above means that the increment instruction fetches the data memory
locations indicated (these "registers" are really from the internal
data memory or "register file" that is potentially big, on the order
of 1024 8-bit words), increments them (in my ALU) and rewrites the new
value back into the data memory. Seems like I need 2 cycles, yes?
On the instruction side, I think I can operate on 1 clock per
instruction by concurrently loading my PC register *AND* the Address
port of my synchronous ram. So, the problem appears to be reduced to:
How can I provide a portable memory to do a read/modify/write in
only one cycle?
I don't think a "standard" synchronous memory can do this. Here are
some alternatives I know of, but I would like to hear any insights
others can offer. Here's my thinking and comments to date:
1) First; Ideally, I want to stay in standard Verilog - no custom
memory designs or floorplanning can be used. No
non-synchronous multiple clock edge techniques, no
latches, can be used (i'm trying to do something very
portable and flexible).
2) Synchronous memories are the convenient, area-efficient cells
that people will have access to either in ASICs or in FPGAs,
so perhaps, the price to pay for this is, sadly, to
require 2 clocks/instruction. This is my current status.
3) Use a "register file" and just synthsize the flip-flops. This
*can* offer the read/modify/write feature. Obviously, this
is only practical for a dozen or two data memory locations.
yes? I have always assumed that delcaring something like
reg [7:0] data_memory[0:511] and synthesizing, would
be crazy, whereas reg[7:0] data_memory[0:31] might be
a reasonable thing to do if it buys us 1 clock/instruction.
If I go with #3, then one suggestion that I have heard, is to use
something like Module Compiler. I don't like this because of point
#1. Has anyone done a register file and come up with RTL techniques
that lead to decent speed area? Or, should I simply declare the 2-D
memory, synthesize it and move on. OR, am I missing something
altogether!
That's it. I hope someone out there has had a similar issue and can
help me! (I'll be at DAC next week if anyone would actually like to
discuss this sort of thing..)
tom coonan
tcoonan@mindspring.com
www.mindspring.com/~tcoonan
Article: 16945"Thomas A. Coonan" wrote: ...SNIP... > say. For example, the PIC allows you to execute the following code: > > incf counter1, counter1 > incf foo, foo > incf bar, bar > > The above means that the increment instruction fetches the data memory > locations indicated (these "registers" are really from the internal > data memory or "register file" that is potentially big, on the order > of 1024 8-bit words), increments them (in my ALU) and rewrites the new > value back into the data memory. Seems like I need 2 cycles, yes? > > On the instruction side, I think I can operate on 1 clock per > instruction by concurrently loading my PC register *AND* the Address > port of my synchronous ram. So, the problem appears to be reduced to: > > How can I provide a portable memory to do a read/modify/write in > only one cycle? > > I don't think a "standard" synchronous memory can do this. Here are > some alternatives I know of, but I would like to hear any insights > others can offer. Here's my thinking and comments to date: If you are referring to synchronous memory inside the FPGA or ASIC, then I believe you are wrong about the read/modify/write capability. In a Xilinx part, for example, an address can be presented which will cause the data to be read from a memory location. This data can then be processed and fed back into the data in port. If you have the write signal asserted on the next rising edge of the clock the new data will be written into the same location. You could even use different addresses on the read and write by using a dual port ram. Or if you multiplex the address, you can still use different addresses on read and write by clocking the read data into an output register on the falling edge of the clock and changing the address with the clock as well. You will need to be very careful about timing of the multiplexer in this case. If it changes too quickly, you will not meet the address setup/hold times on the ram. > 1) First; Ideally, I want to stay in standard Verilog - no custom > memory designs or floorplanning can be used. No > non-synchronous multiple clock edge techniques, no > latches, can be used (i'm trying to do something very > portable and flexible). As I outlined above, you can do a very portable design that will work with many (but not all) manufacturers. I know that you can do this with Xilinx and Lucent parts. I would be willing to bet that there are many ASIC devices that provide such a single or dual port ram as well. > 2) Synchronous memories are the convenient, area-efficient cells > that people will have access to either in ASICs or in FPGAs, > so perhaps, the price to pay for this is, sadly, to > require 2 clocks/instruction. This is my current status. They are convenient and should work in one clock cycle. Perhaps you think that it can only do one thing at a time. But the ones I have seen will always do a read of whatever address in on the address pins and will also do a write when the write enable pin is asserted. > 3) Use a "register file" and just synthsize the flip-flops. This > *can* offer the read/modify/write feature. Obviously, this > is only practical for a dozen or two data memory locations. > yes? I have always assumed that delcaring something like > reg [7:0] data_memory[0:511] and synthesizing, would > be crazy, whereas reg[7:0] data_memory[0:31] might be > a reasonable thing to do if it buys us 1 clock/instruction. I aggre that this is the least efficient approach. But I am pretty sure that you don't need to do this. I am not a big user of VHDL or Verilog since I don't like being isolated from the hardware. But I don't see any reason why this won't work. I know that the hardware supports it. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 16946
Thomas A. Coonan wrote in message <376a5a2c.694032145@news.mindspring.com>... > The real PIC actually has 4 internal "phases". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >On the instruction side, I think I can operate on 1 clock per >instruction by concurrently loading my PC register *AND* the Address >port of my synchronous ram. So, the problem appears to be reduced to: > > How can I provide a portable memory to do a read/modify/write in > only one cycle? You mention that the PIC has four internal phases - that means the instruction cycle is not one clock cycle. Yes, the PIC can do a read-modify-write in one instruction execution cycle. But they divide the clock by four (those four phases) to do all of the work, so it really takes four clock cycles to do anything. What happens inside the PIC is that data is read during phase Q2 and written back during phase Q4. So the memory does NOT have to do a R/M/W in only one cycle. -- a ------------------------------------------ Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters@noao.edu NY Knicks in '99: "Ya gotta believe!"Article: 16947
Dear Valued CoolRunner Customer, We are pleased to inform you of a change in ownership of the CoolRunner product family. Philips Semiconductors has elected to sell its CoolRunner Programmable Logic business to Xilinx Inc. This sale includes the CoolRunner XPLA and the CoolRunner 22V10 devices. The CoolRunner product family will benefit from dedicated and expanding support due to the new arrangement. Xilinx intends to keep and enhance the CoolRunner product line. In the near term, the primary goal during the transition is maintaining the same level of service and support you have come to expect of the CoolRunner product group. Philips Semiconductors and Xilinx are grateful for your understanding and patience in this time of transition. If you have any questions, please feel free to call us at 1-888-COOLPLD or email your questions to coolpld@abq.sc.philips.com. Sincerely, Xilinx Inc. and the CoolRunner product groupArticle: 16948
Rickman <spamgoeshere4@yahoo.com> wrote: >"Thomas A. Coonan" wrote: >...SNIP... >> say. For example, the PIC allows you to execute the following code: >> >> incf counter1, counter1 >> incf foo, foo >> incf bar, bar >> >> The above means that the increment instruction fetches the data memory >> locations indicated (these "registers" are really from the internal >> data memory or "register file" that is potentially big, on the order >> of 1024 8-bit words), increments them (in my ALU) and rewrites the new >> value back into the data memory. Seems like I need 2 cycles, yes? >> >> On the instruction side, I think I can operate on 1 clock per >> instruction by concurrently loading my PC register *AND* the Address >> port of my synchronous ram. So, the problem appears to be reduced to: >> >> How can I provide a portable memory to do a read/modify/write in >> only one cycle? >> >> I don't think a "standard" synchronous memory can do this. Here are >> some alternatives I know of, but I would like to hear any insights >> others can offer. Here's my thinking and comments to date: > >If you are referring to synchronous memory inside the FPGA or ASIC, then >I believe you are wrong about the read/modify/write capability. In a >Xilinx part, for example, an address can be presented which will cause >the data to be read from a memory location. This data can then be >processed and fed back into the data in port. If you have the write >signal asserted on the next rising edge of the clock the new data will >be written into the same location. You could even use different >addresses on the read and write by using a dual port ram. Or if you >multiplex the address, you can still use different addresses on read and >write by clocking the read data into an output register on the falling >edge of the clock and changing the address with the clock as well. You >will need to be very careful about timing of the multiplexer in this >case. If it changes too quickly, you will not meet the address >setup/hold times on the ram. That would be good news. I thought that the synchronous RAMs register the address and the rw control on the clock ege. So that if you drive the address and rw in one cycle, you won't get the result of your read until the next cycle. Remember my example that had 3 read/modify/writes of 3 different addresses in 3 cycles. I'll review the synchronous RAM data sheets for my ASIC vendor and also for XILINX Virtex. The DPRAM is an idea.. I know both my ASIC vendor and XILINX Virtex have those. > > >> 1) First; Ideally, I want to stay in standard Verilog - no custom >> memory designs or floorplanning can be used. No >> non-synchronous multiple clock edge techniques, no >> latches, can be used (i'm trying to do something very >> portable and flexible). > >As I outlined above, you can do a very portable design that will work >with many (but not all) manufacturers. I know that you can do this with >Xilinx and Lucent parts. I would be willing to bet that there are many >ASIC devices that provide such a single or dual port ram as well. > > >> 2) Synchronous memories are the convenient, area-efficient cells >> that people will have access to either in ASICs or in FPGAs, >> so perhaps, the price to pay for this is, sadly, to >> require 2 clocks/instruction. This is my current status. > >They are convenient and should work in one clock cycle. Perhaps you >think that it can only do one thing at a time. But the ones I have seen >will always do a read of whatever address in on the address pins and >will also do a write when the write enable pin is asserted. > > >> 3) Use a "register file" and just synthsize the flip-flops. This >> *can* offer the read/modify/write feature. Obviously, this >> is only practical for a dozen or two data memory locations. >> yes? I have always assumed that delcaring something like >> reg [7:0] data_memory[0:511] and synthesizing, would >> be crazy, whereas reg[7:0] data_memory[0:31] might be >> a reasonable thing to do if it buys us 1 clock/instruction. > >I aggre that this is the least efficient approach. But I am pretty sure >that you don't need to do this. > >I am not a big user of VHDL or Verilog since I don't like being isolated >from the hardware. But I don't see any reason why this won't work. I >know that the hardware supports it. > >-- > >Rick Collins > >rick.collins@XYarius.com > >remove the XY to email me. > > > >Arius - A Signal Processing Solutions Company >Specializing in DSP and FPGA design > >Arius >4 King Ave >Frederick, MD 21701-3110 >301-682-7772 Voice >301-682-7666 FAX > >Internet URL http://www.arius.comArticle: 16949
Thomas A. Coonan <tcoonan@mindspring.com> wrote in message news:376a5a2c.694032145@news.mindspring.com... > I've asked this question once before, but it is important (to me) so > here goes again. > > I have this freeware Verilog PIC CPU core > (www.mindspring.com/~tcoonan) that I like to play with. I have a > nagging issue related to memories and clocks/instruction. If you know > about the PIC, then you know that it has seperate program and data > memories. My current model uses 2 clocks per instruction because I'm > using "standard" synchronous memories and I can't seem to figure out > how to do everything that needs doing in terms of memory cycles with 1 > clock per instruction. I'd like to offer 1 clock/instruction! The > real PIC actually has 4 internal "phases". wheew.. that was a lot to > say. [SNIP] We've solved all of the problems in our VHDL PIC processor. It runs at 1 clock per instruction, is 100% PIC code compatible, and uses a synchronous memory that allows the read-modify-write operations. We've completely documented how the core works (including complete descriptions of the internal components and the portable memory interface) in our SLC1655 technical reference manual. We did our implementation in VHDL, but the circuit descriptions in the manual are pretty generic, and will apply to Verilog(tm) as well. If you want to see how we did it you can download the from our website at http://www.silicore.net. -- Wade D. Peterson Silicore Corporation 3525 E. 27th St. No. 301, Minneapolis, MN USA 55406 TEL: (612) 722-3815, FAX: (612) 722-5841 URL: http://www.silicore.net/ E-MAIL: peter299@maroon.tc.umn.edu
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