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
Patrick Mueller wrote: > > I am searching for a synthesizable 8B/10B Encoder/Decoder for a > FibreChannel Project. > Has anybody VHDL or AHDL code for that? > > Thanks > > Patrick Mueller > > email: no_spam_pbmuelle@stud.ee.ethz.ch ( remove no_spam_ ) Hi Patrick, Seagate used to support a VHDL FCAL template design which they provided to fibre channel designers for free. I am uncertain where (if) that code is located on the web. If you can't locate the code, and no-one else can provide it for you send me an e-mail - I probably have 8B/10B RTL at home on my PC somewhere. If you opt to design the 8B/10B yourself, "Fibre Channel Gigabit Communications and I/O for Computer Networks" by Alan F. Benner from McGraw-Hill has an excellent section on implementation as partitioned into 5B/6B and 3B/4B submodules. If I remember properly, the implementation is not that difficult, testing it may be the real challenge ;-) Warm Regards, rickcArticle: 9576
I am in the market for a stand alone development board for a FLEX6000 part. All I can find are FLEX 10K boards, does anyone know if there is a FLEX6000 based board out there? Brian Carlson Staff Engineer Ericsson Inc.Article: 9577
Please I want some hints and guidelines for selecting FPGA or pDSP for some applications and the trade-offs involved ( ie power consumption, speed, design flexibility ,etc) thanks in advanceArticle: 9578
Thanks. Yes, I've written a paper about it and submitted it to ICCD '98 a few days ago. I'll send you a copy via email. I just didn't want to send a paper to a newsgroup. James Stine wrote: > Hi, > > It sounds like you have an intersting idea. You should write a paper about > it This way, your peers can read your material and use it to aid in the > development of the field. Take care. > > james stine > jes6@lehigh.edu > > Vitit Kantabutra wrote: > > > I believe I have a new radix-4 CORDIC algorithm for computing sine and > > cosine. Unlike previously known algorithms, mine doesn't need extra > > iterations and doesn't involve non-constant multiplicative factors. > > However, it does require a slow iteration on rare occasions. I also > > designed a Xilinx-based prototype of the new part of the circuit. Please > > contact me if interested.Article: 9579
ems@see_signature.com (ems) wrote: > on an unrelated point, i recall from another post that you're using a > lot of xilinx parts in your application. i would have thought that > orca would be a significantly better choice, particularly for a > 1000-device system. can you tell us why you chose xilinx over orca? I am using Orca and not Xilinx. I avoided mentioning this in the bitstream discussion to avoid taking an additional branch in the thread. I kind of considered "xilinx" to be a generic term for LUT-based FPGAs. The same way "kleenex" is often a generic term for facial tissue. Lucent is just as protective of its bitsream as Xilinx. I'm not opposed to using Xilinx, but have found that Orca is almost always better for my applications. The only major complaint I have about Orca chips is the lack of I/O registers. In order to get predictable Tco, setup and hold times, I sometimes have to do hand-optimized mapping and placement. This is an example of why it would be helpful to have access to software internals. If I had access to the Orca mapping algorithm I could probably hack it to make the I/O optimizations. Also, the Orca preference file format leaves a lot to be desired. Xilinx has (had?) a much better way to specify timing constraints. (I think xilinx is now using the same Neocad-based system as Lucent.) It wouldn't take too much hacking to fix this either. Just adding wild cards would be a good first step. -- Don Husby <husby@fnal.gov> Phone: 630-840-3668 Fermi National Accelerator Lab Fax: 630-840-5406 Batavia, IL 60510Article: 9580
I can't give you the answers you are looking for, but here are some general comments based on my experience of doing similar low power designs in Xilinx FPGAs, also running at very slow clocks: First, there is the static Icc and there is the dynamic Icc. I assume you must know this, but not all FPGAs are fully CMOS. The full-CMOS ones should draw only microamps statically. The others will draw milliamps, or more. Next, on the dynamic Icc front, BY FAR the biggest factor is whether you can gate clocks. If you design your FPGA in the "recommended" way (i.e. use the global clock net for everything that might be clocked, and use clock-enable inputs to decide what actually gets clocked) then your Icc will be perhaps 10x or 50x higher than it will be if you can do things the "obvious" way, and feed a clock only to those circuits which actually need it. This is a simple fact in VLSI design and there is no way around it. The problem with gating clocks in FPGAs is that the delays in the various muxes etc can skew the clock enough to screw things up. I once did a XC3064 design whose static Icc was about 100uA and whose dynamic Icc varied between about 2mA and about 30mA, according to how much of the internal circuit was clocked. I was doing a lot of clock gating, including doing a virtual "sleep mode" by gating the inputs to the ACLK and GCLK global clock drivers. As I say above, I had some problems with gating the clocks not producing a reliable design but since this was a prototype for an ASIC (in which you can gate clocks as much as you want, provided you don't do stupid things) this didn't matter. Next, ripple counters draw much less power than the "doing it properly" sync counters one is supposed to use in an FPGA; the reason is obvious if you look at what gets clocked at what frequency. Next, and other things being equal, smaller geometry should give you a smaller dynamic Icc, per MHz, and of course so will a lower supply voltage. So a newer, faster, device should draw less mA per MHz. Finally, you have your output pin capacitance to charge and discharge. You can easily calculate how much power this will cost you. Waggling 70 PCB tracks at 2MHz might be very expensive. >Alright all you FPGA reps. I would really like some hard comparison >numbers on >power consumption of FPGAs. I know these are design dependent, but there >have to be some comparison numbers out there somewhere. I would really >like to see some numbers on SRAM vs. ACTEL and Quick Logic. > >I am doing a design I would like to keep in a 5K gate device. The >highest clock is 2Mhz, and I wil be wiggling maybe 70 lines. The device >will be burst processing and only will be on for perhaps 25% of the >time. There are perhaps 10 16 bit counters internal to the device. The >design will all be 3.3V > >What kind of power numbers can I expect from > >ACTEL: >Quick Logic: >Lucent: >XILINX: >ATMEL: >Altera: Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 9581
Dear all, I've reserved a double for two nights, 15 & 16. Is anyone interested in sharing the room and save $55 per night ? -Arrigo -- Arrigo Benedetti o e-mail: arrigo@vision.caltech.edu Caltech, MS 136-93 < > phone: (626) 395-3695 Pasadena, CA 91125 / \ fax: (626) 795-8649Article: 9582
HELP!
Over the next two days I'm putting together one of those Trip Reports
for the recent SNUG'98 and IVC/VIUF'98 conferences. And, as usual, I
like to write these reports as collaborative efforts. So I'd like to
ask your help. Could you please e-mail me what you thought about
either or both conferences? What was hot? What was not? What's
the best quote you (over)heard from someone there? (Please say
who said what and in what context.) What's the most interesting
paper, talk, panel, hallway conversation you partook in & why was
it so interesting/useful? What was the best/worst/most interesting
product announcement or secret NDA thing you heard?
If you wrote a trip report, could you e-mail me a copy of it, please?
OF COURSE, as always, I'll keep all sources anonymous; what I'm
interested in is sharing common useful information. I go to great
lengths "clean up" anything I get that might give away who told
me what -- it's the info/opinions/ideas that are useful -- not
who said/has them.
Please, tell me what you saw and your reactions so I can do my job
as an EDA consumer advocate. It's personally important to me that
my Trip Reports reflect what you're really experiencing as an
engineer trying to design chips with today's EDA tools. Thanks. :^)
- John Cooley
the ESNUG guy
============================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 6000+ other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Article: 9583I'd like to make an ISA add-in card based on an FPGA. It will include a small state machine to watch for data patterns on some lines (i.e., when 0x5F is immediately followed by 0x4C, then process the next five characters, etc.) However, from time to time I'd like to be able to dynamically upload a new, completely different state machine from the computer. Does anybody make a device that will support this partial reprogramming? I've heard that Altera has some rudimentary support in a few of their FPGAs, but that it's seriously difficult to work with. Thanks to their symmetry, I'd think that CPLDs with good interconnect would make this easy (as long as I leave a few CLBs unused, to be filled in later). With all the reconfigurable computing research lately, there's got to be something...? Thanks for any leads, - Scott NOsSPAMbronson@opentv.com (either follow up to this newsgroup or repair my E-mail address (sbronson) to reply. Spammers are a real nuisance).Article: 9584
Don Husby wrote: > ...snip... > Also, the Orca preference file format leaves a lot to be desired. Xilinx > has (had?) a much better way to specify timing constraints. (I think xilinx > is now using the same Neocad-based system as Lucent.) > It wouldn't take too much hacking to fix this either. Just adding wild cards > would be a good first step. > > -- > Don Husby <husby@fnal.gov> Phone: 630-840-3668 > Fermi National Accelerator Lab Fax: 630-840-5406 > Batavia, IL 60510 I am just now working with file based timing constraints on the Xilinx M1 (Neocad) software and it does take wildcards. They use * for any number of chars and ? for any one char. I also like the Orca parts. I have done one design with them pre-Neocad. The ODS tools did a fair job of routing, but the manual design editor was unusable. Not that I would ever use if for anything other than viewing. But one of my biggest frustrations with all of these tools is the inability to gain visbility into what the tools have done. The only useable design analysis tools is the timing analyser. And that only tells you that something is wrong, not much about what is wrong with it. Rick Collins redsp@writeme.comArticle: 9585
Am looking for a software configurable diplexer for use in radio transceivers. Have not seen articles or publications outlining FPGA or ASIC devices that can be used as diplexers in radio transceivers. If you know of such a device, please respond to jcummXing@alexandria.adroit.Ycom Please delete the X and Y from this address. Sure would appreciate any information on this. Jon CummingsArticle: 9586
I am currently doing a USB implementation in Altera 10K. Actually USB can be implemented with a state machine instead of a microcontroller. And yes there is a higher speed clock in the design in that the bit detection needs to resolve a +- .25 bit jitter and that means the clock/data recovery needs to be done at 48 MHz but that section of the circuit is very small. Most of the design can be in 12 MHz. Rick Collins <redsp@writeme.com> wrote: >part these days. Do you know if the design would have to run at a higher >rate to be able to process any part of the bit stream in hardware? Or >could the design be done at a 12 MHz clock rate? > >Rick Collins > >redsp@writeme.com > > muzo WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>Article: 9587
Rob, I have 2 Cypress ISR devices on my board. About 3 months ago when we started the programming process we could only use a 386 or some 486 computers to program the devices. It turned out to be the ISR cable. The local Cypress FAE replaced the cable and the computers we've tried so far program the parts ok. We created simple configuration files for the ISR program to do the following: program part one and read part two, read part one and program part two, program both part, read both parts. This is do to the 100 times programming limit, we only program the part we need to change. Overall I am happy with the performance of the part and the new ISR cable. Bill Brown Rob Semenoff <robert_semenoff@phoenix.com> wrote in article <01bd52b7$26e6e1c0$cd037a86@rsemenoff.phoenix.com>... > Hi, > I would like to know if anyone else has been using the cypress ISR > (in-circuit reprogrammable) CPLDs and would have any comments on their > download cable > device programmer and programming the devices in general. > One thing I have found is that the error messages from the programming > software are > innaccurate, but I won't be able to try programming a device until I can > get a > prototype board built - and I don't want to commit to the cypress part in > my design > if it turns out their system is flaky. > > Any comments appreciated, > > -Rob >Article: 9588
Hello, I am currently doing a project with an XC4000E interfacing with PC parallel port. Inside the M1 tools there are options for CMOS or TTL. What should I choose when interfacing with an old type, SPP parallel port? Regards, David HoArticle: 9589
This is a multi-part message in MIME format.
--------------7FD492498504514E57BD8E1E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Alright all you FPGA reps. I would really like some hard comparison
numbers on
power consumption of FPGAs. I know these are design dependent, but there
have to be some comparison numbers out there somewhere. I would really
like to see some numbers on SRAM vs. ACTEL and Quick Logic.
I am doing a design I would like to keep in a 5K gate device. The
highest clock is 2Mhz, and I wil be wiggling maybe 70 lines. The device
will be burst processing and only will be on for perhaps 25% of the
time. There are perhaps 10 16 bit counters internal to the device. The
design will all be 3.3V
What kind of power numbers can I expect from
ACTEL:
Quick Logic:
Lucent:
XILINX:
ATMEL:
Altera:
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: richard@associatedpro.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
--------------7FD492498504514E57BD8E1E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Schwarz
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Richard Schwarz
n: Schwarz;Richard
org: Associated Professional Systems
adr: 3003 Latrobe Court;;;Abingdon;MD;21009;USA
email;internet: aps@associatedpro.com
title: President
tel;work: 410.569.5897
tel;fax: 410.661.2760
tel;home: 410.515.3883
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------7FD492498504514E57BD8E1E--
Article: 9590
This is a multi-part message in MIME format.
--------------C6B34283B1B33A63E87009F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
No problem at all Paul. Thanks again for your understanding. :-)
Richard
Paul wrote:
> Richard,
>
> Whether or not you were referring to me about the numerous complaints
> you've received, I want to apologize now for those two messages that I
> did post. I should have left those issues in the past, where they
> belonged.
>
> From what you've said, my guess is, my experience was a rare one, and
> that usually APS has much better success shipping their product. I
> understand that I asked for a special date for delivery of the APS kit,
> and I asked this around Christmas time, and I realize that this is
> probably what messed things up for everybody. I can tell from the
> frustration of your last message that this is the point you're trying to
> make.
>
> And although this is the first I've heard of it, your offer to refund
> shipping costs I think is a sincere offer, an attempt to set things
> right. The offer's enough for me; I'm not interested in the refund.
>
> I'm just hoping that if you'll accept my public apology for my public
> complaints, that we can put the whole matter behind us.
>
> Sincerely,
> -Paul
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: richard@associatedpro.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
--------------C6B34283B1B33A63E87009F1
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Schwarz
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Richard Schwarz
n: Schwarz;Richard
org: Associated Professional Systems
adr: 3003 Latrobe Court;;;Abingdon;MD;21009;USA
email;internet: aps@associatedpro.com
title: President
tel;work: 410.569.5897
tel;fax: 410.661.2760
tel;home: 410.515.3883
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------C6B34283B1B33A63E87009F1--
Article: 9591Magnus Homann wrote: > Rick Collins <redsp@writeme.com> writes: > > Interesting observation. I did a partial E1 interface in an XC5204 last > > year and it only took about half the part. I didn't need to detect the > > framing bits. That was external, but I had to build the shift registers, > > the frame and time slot counters and even handle the tristate buffering > > for the half time slot of the signalling data. And of course I had to have > > an interface for the DSP which was talking to this chip. > > Excuse me, but I would think the framing was the absolute hardest part > of the interface chip. > > Homann > -- > Magnus Homann Email: d0asta@dtek.chalmers.se > URL : http://www.dtek.chalmers.se/DCIG/d0asta.html > The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html The framing is just a shift register with a comparator attached. When the right combination of bits occures, the comparator signals the event. A small state machine coupled with the frame counter indicates if you are in sync or out of sync. The shift register may need to be a large number of bits though. I believe the sync pattern is the first 4 bits from each frame which goes through a repetitive pattern. One algorithm would use just a 4 bit shift register with counters. You shift all incoming bits through until you see the frame 1 pattern. You then count bits to the next frame and see if you have the frame 2 pattern. If yes, you repeat for the 3rd frame, 4th frame... If you don't have the correct pattern at any point you start over with the first frame pattern. When you see the complete master frame pattern several times, you asssume that you are in sync. Any misses in the pattern and you are out of sync and start over hunting. This will not give you a minimum lockup time, but the hardware is minmal; 4 bit shift register and comparator, 8 bit bit counter, 4 bit frame counter and a small state machine. I believe that most chips take a second or so to lockup to the sync pattern. So they may be doing exactly this. Is there a better way to do this? Rick Collins redsp@writeme.comArticle: 9592
Philip Freidin wrote: > In article <351733A5.EAEB3FA0@writeme.com> redsp@writeme.com writes: > > > >I have looked at the data book for the dual port RAM feature and I don't > >completely understand how it is intended to work or why they only > >implement one bit in a CLB instead of two. > > I believe that it works just as it is documented. One port has both read > and write capability, the other port is read only. Absolutely > simultaneous reads and writes are possible. There is no contention on > address match. There is no interference on read timing between the two > ports. There is a delay from write on one port to read on the other of > the same address, which is both expected and unavoidable due to the > reality of the way the universe works. This is how it appears to the user, but obviously both ports are written at the same time. Otherwise you can't read a RAM that you have never written to. The only way to allow reads and writes without contention is to design the RAM with dual access to each location. This requires a lot more real estate than a simple RAM. Your comment about a delay on write on one port and read on the other is not clear. If I can read write one port simultaneously, why can't I read write different ports simultaneously? What does the universe have to do with this? > >The architecture shows two address inputs. One is the write address to > >both F/G generators and the read address to the F generator. The other > >address input is just for read on the F generator. They share a clock, WE > >signal and data input, while they have separate data outputs. > > The underlying hardware is two LUT/RAMs, each is 16 x 1, and they have > separate read and write address decoders. The write decoders are slaved > together for dual port mode. The read decoders are kept sepparate. > > >So the question is: if you can read and write at the same time, then why > >do you need two function generators to implement a single bit? When you > >write, you must always write to BOTH function generators. So to have > >simultaneous reads and writes, the G function generator must internally > >support simultaneous reads and writes with the read data appearing at the > >output during the entire write cycle (unless the same address is being > >accessed so that the output data will change just after the clock edge). > > Here's a better way of looking at it. Given that you start with LUTs that > are basically loaded at config time, and are ROMs, what minimal hardware > must you add to make them writeable during FPGA operation. Answer is XC4000. > > Given that you have LUTs that can be used as RAM, what minimal hardware > can you add so that the write is synchronous. Answer is XC4000E. > > Given that you are tearing up the guts of the CLB anyway to make the RAM > write synchronous, what other features that would be valuable to customers > could be added, yet require almost no other hardware, and by-the-way, > must still be backward compatible to the XC4000 bitstream. The answer is > dual port the CLB RAM, by joining the address lines for the write > decoder (when in dual port mode), while keeping the read decoders still > connected to their respective address pins. The only advantage I can see with the addressing scheme they used is that it does not require an extra multiplexer in the address path. But then I don't think the details of the block diagrams that Xilinx publishs are accurate enough to allow you to tell what impact this would have. > In traditional dual port RAMS (like IDT, Cypres, TI, ...) there tends to > be a single decoder that is used for both reading and writing, and it > uses a structure that involves bit lines, word lines, and sense > amplifiers. To dual port this type of memory, you duplicate everything > except the actual storage cell. > > The dual port RAMs I am describing here (in the XC4000E/EX/XL/XV) start > off with separate read and write decoders, and dont have bit lines, word > lines, or sense amps. I am curious as to what it does have. Obviously it must duplicate the decoding. Other than the storage cells, what else is there? > Note that the ORCA product copied this architecture. > > >So, why bother with the F generator doing a parallel read? Why not make > >the CLB a TWO bit ram block instead of a one bit ram block? Is it a > >routing issue somehow? Is it too hard to route both addresses to both ram > >blocks? Are there not enough inputs to allow two data bits in? What was > >the limitation? Surely it would have been better to have a two bit dual > >port ram than a single bit dual port ram? > > What it basically comes down to is that there are constraints such as > bit-stream compatibility with prior generations, together with a very > different basic memory cell and read/write topology onto which dual port > was added. I am not clear as to why one design would be bit stream compatible and the other not. My point about the memory cell is that the function generator that has different read and write address ports MUST already be a fully dual port memory. Why not make them both fully dual port and have it be two bits wide? > for further info, you could look up patent 5631577, on the IBM patent > server http://patent.womplex.ibm.com What does this patent cover, dual port memory or its use in an FPGA? > >Rick Collins > >redsp@writeme.com > > Philip FreidinArticle: 9593
In article <6f8gd7$eib$1@info1.fnal.gov> husby@fnal.gov (Don Husby) writes: >fliptron@netcom.com (Philip Freidin) wrote: >> Note that the ORCA product copied this architecture. > >Also note that they seem to have done better in their next >generation (OR3Txxx) which uses all of the LUT bits for >RAM instead of 1/2 the bits. Their new PFU can be >eight 4LUTS, or four 5LUTS, or a 32x4 memory. In these devices, the dual port is done as 1 read port, and 1 write port. This allows for a 32x4 memory in a PFU with eight 4-input LUTS. This certainly is an improvement if you want to build FIFO's or uni-directional mailboxes. It does not work for the multiple read port requirements of things like register files in CPU type data paths, or mailboxes, where you want to look at the content that you have written. You can obviously write the data into two such RAMs, and use independent read addresses, in which case the dual port bits per LUT is just like the XC4000E type products. >I can't remember if Xilinx also fixed this in their new >generation, and can't seem to find any literature at their >web site. Xilinx has added blocks of dual port SRAM sepparate, and additional to the LUT base SRAM in their new Virtex family, which you can read about in their Q1 98 XCELL magazine. >Don Husby <husby@fnal.gov> Phone: 630-840-3668 >Fermi National Accelerator Lab Fax: 630-840-5406 >Batavia, IL 60510 Philip FreidinArticle: 9594
In article <6f9939$40k$1@info1.fnal.gov> husby@fnal.gov (Don Husby) writes: > >I am using Orca and not Xilinx. > ..... >I'm not opposed to using Xilinx, but have found that Orca is almost >always better for my applications. The only major complaint I have about >Orca chips is the lack of I/O registers. In order to get predictable Tco, >setup and hold times, I sometimes have to do hand-optimized mapping >and placement. > >This is an example of why it would be helpful to have access to software >internals. Or have tools that just let you specify the requirements in your design source. Xact and M1 let you do this. > If I had access to the Orca mapping algorithm I could probably >hack it to make the I/O optimizations. > >Also, the Orca preference file format leaves a lot to be desired. Xilinx >has (had?) a much better way to specify timing constraints. (I think xilinx >is now using the same Neocad-based system as Lucent.) The code that Xilinx and Lucent are using branched when Xilinx acquired Neocad 3 years ago. The result for Xilinx is now called M1 (for merged release 1), and it has the advantages of both tool sets. M1 supports all the TimeSpec language of the Xact sw, together with several quite nice new features. >Don Husby <husby@fnal.gov> Phone: 630-840-3668 >Fermi National Accelerator Lab Fax: 630-840-5406 >Batavia, IL 60510 Philip FreidinArticle: 9595
I'm considering USB support for a hardware project I'm currently doing, but I'm not sure where to look for the information I need. I would appreciate if anyone could point me in the right direction - like: What tools do I need to do the programming on the PC side? Also - what kind of size of the USB core could you expect for a FLEX10K implementation, when a secondary CPU is available to share the workload? Regards, Rune Baeverrud muzo wrote in message <351979c3.89867021@news1.walltech.com>... >I am currently doing a USB implementation in Altera 10K. Actually USB can be >implemented with a state machine instead of a microcontroller. And yes there is a >higher speed clock in the design in that the bit detection needs to resolve a +- >.25 bit jitter and that means the clock/data recovery needs to be done at 48 MHz >but that section of the circuit is very small. Most of the design can be in 12 >MHz. > >Rick Collins <redsp@writeme.com> wrote: >>part these days. Do you know if the design would have to run at a higher >>rate to be able to process any part of the bit stream in hardware? Or >>could the design be done at a 12 MHz clock rate? >> >>Rick Collins >> >>redsp@writeme.com >> >> > >muzo > >WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>Article: 9596
In article <35188CBE.2DD97143@writeme.com> redsp@writeme.com writes: >Philip Freidin wrote: >> I believe that it works just as it is documented. One port has both read >> and write capability, the other port is read only. Absolutely >> simultaneous reads and writes are possible. There is no contention on >> address match. There is no interference on read timing between the two >> ports. There is a delay from write on one port to read on the other of >> the same address, which is both expected and unavoidable due to the >> reality of the way the universe works. > >This is how it appears to the user, but obviously both ports are written at the >same time. Think of it this way: there is a LUT RAM (16 x 1), and it has a write address decoder, and a read address decoder. The address input lines of the two decoders are tied together. You can therefore only read or write one location at a time, and when you write to an address, the read decoder will be reading from the same location, so when the memory cell changes to the new value, it is already being read, so the output will update to the new value. An acurate model of this for the XC4000E would be 16 flip flops, with the outputs all going to a 16 to 1 mux (the read decoder), and the D and CLK inputs all tied together, and the write address goes to a 4 line to 16 line decoder, these 16 decoded signals going to the CE inputs of the flip flops. When the clock comes along, only one of the flip flops is updated. This is how single port RAM is implemented. Now take two of these LUT RAMs, and when you want a dual port mode, connect the second RAMs write address to the write address of the first RAM. Now when you write, the data is written into both SRAMs, and the first one (with the read address still connected to write address) will read the value out as soon as the memory cell is updated. In the second LUT, the read address is independent. It can be watching the same address, or some other address. >Otherwise you can't read a RAM that you have never written to. Well, you can, but you get junk. >The only way to allow reads and writes without contention is to design >the RAM with dual access to each location. This requires a lot more real >estate than a simple RAM. But is inherently what was already there in the XC4000 (in terms of read and write decoders), before dual port was added. >Your comment about a delay on write on one port and read on the other is >not clear. I was just referring to the pass through delay. It is about 1 or 2 nanoseconds from the time the cell has been updated to the new value is available on the output of the read port, assuming the read address is monitoring the address being written to. >If I can read write one port simultaneously, why can't I read write >different ports simultaneously? Because one port is a read/write port (the address input is used for both) and the other port is read only, because the writing is done from the first port. >The only advantage I can see with the addressing scheme they used is that it >does not require an extra multiplexer in the address path. But then I don't >think the details of the block diagrams that Xilinx publishs are accurate enough >to allow you to tell what impact this would have. The diagram on pagfe 4-185 of the 1/98 Xilinx data book shows the structure with sufficient detail. >> The dual port RAMs I am describing here (in the XC4000E/EX/XL/XV) start >> off with separate read and write decoders, and dont have bit lines, word >> lines, or sense amps. >I am curious as to what it does have. Obviously it must duplicate the decoding. >Other than the storage cells, what else is there? See detailed description at the top of this message. >> What it basically comes down to is that there are constraints such as >> bit-stream compatibility with prior generations, together with a very >> different basic memory cell and read/write topology onto which dual >> port was added. >I am not clear as to why one design would be bit stream compatible and >the other not. The issue with bitstream compatibility has more to do with how many bits of the bitstream are available to activate new functionality, without changing the bitstream, rather than with the architecture of dual port. Each new function in a CLB requires some config bits to select whether or not it is activated. One of the most heavy uses of config bits is the selector muxes that select signals from the routing channels, and feed them into the CLB. There is no way to add additional input pins (to be used as dual port address pins) to a CLB without planning for it from the beginning. One of the goals of the XC4000E product was to be bitstream compatible with the prior generation products, so additional inputs were not an option. >My point about the memory cell is that the function generator that has >different read and write address ports MUST already be a fully dual port >memory. Why not make them both fully dual port and have it be two bits >wide? As described above, while the read and write structures are separate, they share the 4 address signals. To make them independent would require 4 more inputs to the CLB. >> for further info, you could look up patent 5631577, on the IBM patent >> server http://patent.womplex.ibm.com >What does this patent cover, dual port memory or its use in an FPGA? Dual Port memory in the XC4000E FPGA >> >Rick Collins >> >redsp@writeme.com Philip FreidinArticle: 9597
fliptron@netcom.com (Philip Freidin) wrote: > In article <6f9939$40k$1@info1.fnal.gov> husby@fnal.gov (Don Husby) writes: > > In order to get predictable Tco, > > setup and hold times, I sometimes have to do hand-optimized mapping > > and placement. > > > > This is an example of why it would be helpful to have access to software > > internals. > Or have tools that just let you specify the requirements in your > design source. Xact and M1 let you do this. You can do this in the Orca software too, but specifying the requirements doesn't necessarily mean you'll meet them. Unfortunately, the software writers haven't yet implemented the optimization algorithm that would help in this particular case. If I had access to the software internals, I could, possibly, implement it on my own. -- Don Husby <husby@fnal.gov> Phone: 630-840-3668 Fermi National Accelerator Lab Fax: 630-840-5406 Batavia, IL 60510Article: 9598
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
===========================================================
| C A L L F O R P A R T I C I P A N T S |
===========================================================
| |
| (WoTUG 21) |
| |
| Architectures, Languages and Patterns |
| for Parallel and Distributed Applications |
| |
| 5-8 April 1998 |
| University of Kent at Canterbury, UK |
| |
| <http://www.hensa.ac.uk/parallel/groups/wotug/wotug21/> |
| |
===========================================================
If you haven't already registered, please check out the WoTUG-21 web site
for the final timetable and academic programme (papers and the Java Threads
Tutorials).
We believe a really strong programme has been put together that should be
of cosiderable interest to all who are working with parallel systems, be
they researchers, developers or users. Please help us bring this to the
attention of as wide an audience as possible.
Invited speakers now include David May (who kicked these ideas into life),
Peter Thompson (Chair of the 1355 Association), Graham Nice (Alex Computer
Systems, Montreal, Canada) and Roger Gook (Embedded Solutions Ltd.).
Industrial applications include the use of occam (on a DSP chip) for
radar-based fluid level monitoring in oil tankers worldwide (Norway),
concurrent graphics engines programmed in Java (Deutsche Telekom) and
fault-tolerant avionics in satellites (Brazil).
There are a clutch of papers from Oxford on new extensions and models for CSP,
some specifically for hardware specification and design, plus a new tool for
verification support. There is Handel-C, an occam derived language for
hardware/software co-design (also from Oxford), backed up with Industrial
support.
Another hot topic is the efficient construction of future parallel hardware
just using commodity processors (like the Alpha, SPARC, Pentium and SHARC)
and commodity interconnect (like Fast Ethernet and High-Speed 1355 links and
routers). This seems to be an idea whose time has come, given the independent
work reported from CERN, Nottingham-Trent, Southampton and Twente ... and
the disappearance of most proprietary parallel architecture.
There's an extensive review of a number of parallel system design environments
(from Russia). And finally, occam lives on on modern architectures, both in
the JavaPP ideas presented in the tutorials and in the ever more efficient
targetings to modern processors (including SMP and NoW architectures) being
reported formally and informally in the late-nite sessions.
Why not be there? On-line registration from the web-site is available now!
Many thanks,
Peter Welch.
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
Article: 9599Try www.spec.com they are a company working under an SBIR (small business innovation and research (?)) grant. They supply radiation hardened FPGAs ... but I would imagine that it is at a price. I have no affiliation with these guys, just found them on the web one day while looking for ECL gate arrays. (They are supplied by www.dyna.com if you're interested.) Regards, Dave dwh@ovro.caltech.edu Stephen King wrote in message <01bd5324$d36ff5e0$1d3872c1@sk_ii.crl.co.uk>... >We are looking to encode a complicated algorithm onto either an FPGA or >ASIC for space applications. > >We are interested to know of any space qualified: > >1.) FPGAs, > >2.) Low volume ASIC processes (e.g. laser programmable, shared wafer etc), > >3.) Conventional ASIC processes. > >Thanks for you help in this matter. > >-- >Stephen King >CRL >sking@crl.co.uk
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