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
And the 8x clock is syncrhonized to the incoming bitstream how? Andy fp wrote: > Peter Alfke wrote: > > Are you re-inventing the receive portion of a UART? > > Peter Alfke > > > > On Nov 1, 8:43 am, "fp" <fpga002...@yahoo.com> wrote: > > > I am working on a 'de-serializer' with Xilinx DCM. The single-bit > > > input stream is sampled by an 8X clock. After 8 bits are stored the > > > register, it activates a single-clock 'done' signal to inform the > > > 1X system to retrieve the data. The data, of course, should only be > > > read once. > > > > > > I am thinking using a flag register to interface the two systems. The > > > register is controlled by the 8X clock. The done signal sets the flag > > > and the 1X system resets the flag after read. Since DCM is used, > > > presumably there is no meta-stability issue. > > > > > > Please comment whether this approach is feasible or provide pointer to > > > some reference designs. > > > > > > Thanks in advance. > > > > > > S. C. > > In UART, the system clock rate is much higher than the serial input and > the system can do 'oversampling'. The situation is reverse in my > application, in which the serial input rate is much higher (and > that's why a DFS and 8X clock is used).Article: 111326
Does anyone know of something more like a "how to" or real design guidelines for designing rad-hard systems, for system/board-level (ADC, DAC, power supplies, etc) design, as well as for FPGA and ASIC hardware? I've found a lot of information around that gave specific numbers about some chips, but I wasn't able to actually understand what the reports were saying. I know that for an FPGA, I should either use a flash or antifuse based chip, or otherwise use a chip with configuration CRC checking and reloading, but how do I select parts like power supplies, ADC/DACs, and RAMs? Even if my FPGA or ASIC design is solid, I'm worried that I'm going to end up shooting myself in the foot on the rest of the system. And for FPGAs and ASICs, what are the design considerations? How would I implement a voting circuit for triple-redundancy in general? And how would I avoid the possability of an error in the voting circuit? Also, if anyone knows of any good books, papers, courses/classes/training, or even consultants, please let me know. Thanks, MikeArticle: 111327
Please save us from guessing. Describe what you really want to do, and what the relevant frequencies are. Otherwise we are all wasting our time. Peter Alfke ================== On Nov 1, 8:43 am, "fp" <fpga002...@yahoo.com> wrote: > I am working on a 'de-serializer' with Xilinx DCM. The single-bit > input stream is sampled by an 8X clock. After 8 bits are stored the > register, it activates a single-clock 'done' signal to inform the > 1X system to retrieve the data. The data, of course, should only be > read once. > > I am thinking using a flag register to interface the two systems. The > register is controlled by the 8X clock. The done signal sets the flag > and the 1X system resets the flag after read. Since DCM is used, > presumably there is no meta-stability issue. > > Please comment whether this approach is feasible or provide pointer to > some reference designs. > > Thanks in advance. > > S. C.Article: 111328
Ben Jones wrote:
> For the smaller "building block" components, I'd say that's not much of an
> issue at all. After all, how many different interfaces can you think of for
> an accumulator or shift register? Most of the differences between vendors
> seem to be superficial (e.g. naming) at that level.
> The problem I have with
> these low-level blocks is that they go against the basic principle of
> abstraction; instead of hiding complex functions behind simple interfaces,
> they do the exact opposite. And they hold back designers by perpetuating the
> "TTL 7400" design mentality.
A netlist of familiar blocks will always
be the starting point for some. But this
is a self-limiting design method because
it does not scale well and is hard to simulate.
A designer that sticks with it will
eventually learn how describe the same
output ports with HDL and simulation.
About all a vendor can do about this
is to provide some non-trivial examples
that show how to make the RTL viewer draw
the schematics to an HDL spec. (hint)
The biggest roadblock to portability
are the RAM and FIFO blocks that are not
describable in RTL because of asynchronous
arbitration. I would much prefer to do
my own arbitration *and* infer a simpler block.
>> Can you list any 'standard' function IP where the code can be portable
>> and in fact is portable across FPGA vendors without touching the code?
I can. A synch fifo using one read port and one
write port from an inferred dpram.
> BTW I'm not sure how much of this I really fervently believe in, just trying
> to illuminate the issue a bit.
Me too.
> I would only say it's a question inertia, rather than malice. On a related
> note, what do engineers hate more - risk of vendor lock-in, or breaking of
> backwards compatibility?
Ay, there's the rub.
Those who write portable code want it all portable.
Those cursed with a crusty but popular design will pray
for a part that covers all the old gizmos.
-- Mike Treseler
Article: 111329Andy wrote: > In my younger days designing state machines in PALs, we did not have > the luxury of pre-synchronizing every asyncrhonous input in its own > flop. > > So we handled asynchronous inputs slightly differently. > > We constrained the state machine and state mapping such that there was > only, ever two destination states based on an asynchronous input at any > given time, and both of those destinations had to be adjacent on a K > map (for those of you too young to know, that means the two states > differed in only one bit, and that one bit becomes the "syncrhonizer"). > Sometimes it was in a loop/branch scenario, where one destination was > the current state, and one the adjacent next state, or sometimes it was > two new destination states, both adjacent to each other. Oddly enough, > those two destination states (so long as they are the only possible > destinations) don't have to be adjacent to the current state. > > The primary benefit of this was that the syncrhonizer register could > pull extra duty in other parts of the state machine as just another > state bit, or even as a syncrhonizer for another input. AND-OR arrays > have their advantages when it comes to overcoming glitches due to > simultaneous input changes that kill LUT based logic. > > For example in the Mongo Lander FSM, if Idle and Fire_Retro_Rockets are > adjacent states on the Kmap, then the one register that differs between > them is the synchronizer, and so long as sufficient timing slack is > reserved for MS settling, no separate synchronizer is needed. Note that > because other transitions in the state machine are not based on async > inputs, they need not be adjacent on the Kmap. > > In an environment where we had to manually assign state encodings > anyway, and registers were at a premium, this technique worked very > reliably, so long as there was sufficient slack to allow for MS to > settle out (i.e. we did not have the equivalent of a second flop > behind the syncrhonizing flop) for a reasonable MTBF. > > In today's design environment, we rarely manually assign states, and > registers are plentiful, so this technique is rarely employed. Also, > separately synchronizing asynchronous inputs is more easily auditable > in code reviews than the old adjacent-state approach. > Yup, BTDT many times over back in the days when a 22V10 was an awesome part compared to the rest of what was available. It still occasionally comes in useful where latency is a concern.Article: 111330
Mike I do not doubt that you can design your own asynchronous arbitration logic, but is that what you want to spend your time on? Ditto with Hamming-code error correction, and Ethernet controllers and PCIexpress. And do you want to stop us from "hardening" these functions, where they take a tenth of the area, and some run twice as fast as the soft equivalent? And do you think the many less experienced users want to do this? Sorry for the rhetorical question... Peter Alfke, Xilinx Applications On Nov 1, 11:16 am, Mike Treseler <mike_trese...@comcast.net> wrote: > > The biggest roadblock to portability > are the RAM and FIFO blocks that are not > describable in RTL because of asynchronous > arbitration. I would much prefer to do > my own arbitration *and* infer a simpler block. > >Article: 111331
Hi group, I have issues with Impact from ISE webpack 8.2 / linux... XP install is ok but difficult to use because it freeze during synth & par. Impact/linux (+ jungo windrvr6) was ok only one time (I have time for 1 or 2 download), but after an other hang I tried to change to xusbdfwu.zip (1023 edition from xilinx ftp area), but did not make a backup... So, I need that file : xusbdfwu.hex from a fresh ISE webpack linux install, 1021 edition. It is located there : $(Xilinx)/bin/lin/xusbdfwu.hex. For now, I can't download again ISE from Xilinx (because low band width at this time...) thanks for the mailArticle: 111332
Steve, Answers inline. "Steve" <sgfallows@gmail.com> wrote in message news:1162329119.728585.8530@h48g2000cwc.googlegroups.com... >I have a EDK based design with 8 MB of external flash memory on the PLB > via the plb_emc core. This is for a Virtex II Pro using EDK/ISE 7.1i, > latest service packs. The flash is addressed at 0xFF800000 - > 0xFFFFFFFF. Thus our plan is to have the processor reset vector in the > flash and execute directly from flash. > > I am able to successfully use the XPS flash programming tool to burn > the flash on my board in most cases I have tried. It reports the CFI > info properly. However I have observed these failures (that seem to me > to be related). > > 1. If I try to burn a full 8MB image, I get an immediate parameter > check that the file is larger than the flash. I have carefullly > examined the file and it is exactly 8MB (8388608 bytes). If I make it > 16 bytes smaller and use an offset of 0 it burns OK. > > 2. Using the "16 bytes less than 8MB" image, if I set the offset to > 16, the burn fails with the error message below about not erasing > correctly. Offsets between 0 and 15 (inclusive) work correctly (except > as noted in number 4). > I believe both issues 1 and 2 were bugs in the tool that were fixed in EDK 8.2i. > 3. Using a 256KB image, I can burn it at any offset (well I think so > - I haven't tried them all :) ) up to 0x7BFFFF. This is up to but not > including the last byte of the flash address space. If I use an offset > of 0x7C0000 (This is the configuration I really need, a 256K image at > the high end of flash address space. I must include the reset vector.) > it fails with the error message below. > Most likely same issue as above. > 4. With either size image, the offset seems to be modulo 4 i.e. > offsets of 0, 1, 2, and 3 all start at the first byte of the flash > address space. I suppose this is not necessarily wrong, but it is > unexpected. > What is your flash bus width? If your flash is 16-bits wide, you can only program in 16-bits at a time (and hence offsets 1 and 3 do not make sense. If it is 32-bits, offsets 1,2,3 do not make sense. > The error message reported is: > Flashwriter Application reported and error: The flash block erase > operation errored out! > > I opened a web case with Xilinx and was told this: > 0xFFFFFFFF is hard-coded for the reset vector and cannot be accessed. > It cannot be overwritten. That is why you are getting this error. > This is the wrong conclusion. > This seems wrong to me. I say this for the following reasons: > > 1. I can load an FPGA design with BRAM at address 0xFFFFFFFC and then > write any value I want to that address using a simple PPC program. > > 2. I can load an FPGA design with Flash at address 0xFFFFFFFC and the > program that location successfully with my own test code running on the > PPC > > 3. If I load an FPGA design that places the flash at 0x08000000, the > XPS tool errors out in the same way as I described in the original > problem statment. It reports an error trying to erase blocks, if the > programming range includes the last 32 bit word. > > Does anyone have any insight or experience that could help here? > > Thanks, > Steve > Hopefully, EDK 8.2i is an option available to you. thanks,Article: 111333
Peter Alfke wrote: > Please save us from guessing. Describe what you really want to do, and > what the relevant frequencies are. Otherwise we are all wasting our > time. > Peter Alfke > ================== > On Nov 1, 8:43 am, "fp" <fpga002...@yahoo.com> wrote: > > I am working on a 'de-serializer' with Xilinx DCM. The single-bit > > input stream is sampled by an 8X clock. After 8 bits are stored the > > register, it activates a single-clock 'done' signal to inform the > > 1X system to retrieve the data. The data, of course, should only be > > read once. > > > > I am thinking using a flag register to interface the two systems. The > > register is controlled by the 8X clock. The done signal sets the flag > > and the 1X system resets the flag after read. Since DCM is used, > > presumably there is no meta-stability issue. > > > > Please comment whether this approach is feasible or provide pointer to > > some reference designs. > > > > Thanks in advance. > > > > S. C. Thanks for your replies. This is just an exercise for myself. Currently I am trying to learn the design of high-speed serial interface. Before looking at the nasty analog aspects, such as clock skew and signal integrity issues, I would like to first to understand the operation the digital part. Let me just assume that system clock is 25 MHz and the serial input is synchronized at 200 MHz.Article: 111334
Peter Alfke wrote:
> Mike I do not doubt that you can design your own asynchronous
> arbitration logic, but is that what you want to spend your time on?
No. I would probably waste a tick, and synch things up.
> Ditto with Hamming-code error correction, and Ethernet controllers and
> PCIexpress. And do you want to stop us from "hardening" these
> functions, where they take a tenth of the area, and some run twice as
> fast as the soft equivalent?
No. I was talking about RAM functions.
> And do you think the many less experienced users want to do this?
With your existing tools.
-- Mike Treseler
Article: 111335Mike, the RAM-support circuits (FIFO controller and ECC) each take about a tenth of the area and run twice as fast as you (or anybody else) could design them in the fabric. We do our best to eliminate the inefficiency of programmable logic in those fairly standardized functions where flexibility is hardly needed. That's how we improve performance and reduce chip size. You know that of course... Peter Alfke On Nov 1, 11:52 am, Mike Treseler <mike_trese...@comcast.net> wrote: > Peter Alfke wrote: > > Mike I do not doubt that you can design your own asynchronous > > arbitration logic, but is that what you want to spend your time on?No. I would probably waste a tick, and synch things up. > > > Ditto with Hamming-code error correction, and Ethernet controllers and > > PCIexpress. And do you want to stop us from "hardening" these > > functions, where they take a tenth of the area, and some run twice as > > fast as the soft equivalent?No. I was talking about RAM functions. > > > And do you think the many less experienced users want to do this?With your existing tools. > > -- Mike TreselerArticle: 111336
Hi Just to clear up any confusion as to what I wanted in the first place. I was looking to use a dual port ram with different address and data widths on side a and b. I have checked with Synplicity and it is currently not possible to infer a ram of this type. So you need to use Coregen instead. Apparently they are looking at implementing it in a future release. CheersArticle: 111337
Is there a flash adc with a plcc package, anything above 24MHz minimum sample rate will suit me. tnxArticle: 111338
Peter Alfke wrote: > Andy, neat idea... > Gray-coded counters are popular for the same reason. > Peter Alfke K-map co-ordinates are gray coded anyway, so adjacent states on a K-map are by definition a single bit change apart for that very reason :) I remember implementing a gray code counter to capture asynchronous events against an arbitrary timing window some *cough* time ago. Cheers PeteS > > On Nov 1, 9:13 am, "Andy" <jonesa...@comcast.net> wrote: >> In my younger days designing state machines in PALs, we did not have >> the luxury of pre-synchronizing every asyncrhonous input in its own >> flop. >> >> So we handled asynchronous inputs slightly differently. >> >> We constrained the state machine and state mapping such that there was >> only, ever two destination states based on an asynchronous input at any >> given time, and both of those destinations had to be adjacent on a K >> map (for those of you too young to know, that means the two states >> differed in only one bit, and that one bit becomes the "syncrhonizer"). >> Sometimes it was in a loop/branch scenario, where one destination was >> the current state, and one the adjacent next state, or sometimes it was >> two new destination states, both adjacent to each other. Oddly enough, >> those two destination states (so long as they are the only possible >> destinations) don't have to be adjacent to the current state. >> >> The primary benefit of this was that the syncrhonizer register could >> pull extra duty in other parts of the state machine as just another >> state bit, or even as a syncrhonizer for another input. AND-OR arrays >> have their advantages when it comes to overcoming glitches due to >> simultaneous input changes that kill LUT based logic. >> >> For example in the Mongo Lander FSM, if Idle and Fire_Retro_Rockets are >> adjacent states on the Kmap, then the one register that differs between >> them is the synchronizer, and so long as sufficient timing slack is >> reserved for MS settling, no separate synchronizer is needed. Note that >> because other transitions in the state machine are not based on async >> inputs, they need not be adjacent on the Kmap. >> >> In an environment where we had to manually assign state encodings >> anyway, and registers were at a premium, this technique worked very >> reliably, so long as there was sufficient slack to allow for MS to >> settle out (i.e. we did not have the equivalent of a second flop >> behind the syncrhonizing flop) for a reasonable MTBF. >> >> In today's design environment, we rarely manually assign states, and >> registers are plentiful, so this technique is rarely employed. Also, >> separately synchronizing asynchronous inputs is more easily auditable >> in code reviews than the old adjacent-state approach. >> >> Andy >> >> Brian Davis wrote: >>> Bob Perlman wrote: >>>> on Halloween night, not a single person dressed as metastability >>>> showed up at my door for candy >>> We had four houses' worth of candy-filled bowls lined up on >>> one long table, which caused many of the evening's spectres >>> to exhibit distinct signs of metastability during the confectionary >>> selection process. >>> Unlike FPGA's, the resolution time seemed inversely proportional >>> to the calendar age of the synchronizer :) >>> Also, I don't recall anyone mentioning it, but Bob's handy dandy >>> guide to planetary landing FSM's seems quite topical of late: >>> http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html >>> Brian >Article: 111339
Mike, Wow. Not a small request. A few suggestions: 1. Read all papers from MAPLD, RADECS, NSREC, and SELSE. 2. Get an IEEE subscription to their e-library and read all the single event effects papers 3. Read all the online information from Xilinx 4. Take the TMR Tool(tm) class from Xilinx: this is the only automatic tool which has been tested in a particle beam and shown to actually WORK. TMR Tool creates a functionally correct TMR with triplicated voters for all feedback paths automatically. (Not a trivial task, and easy to mess up and fail if you do it by hand) 5. Ask your local Xilinx FAE to present the SEU modules for V43 and V5 to you. If the above seems a bit daunting, well, it is. Continuing, 6. Search USPTO site for all patents on "single event upset" patents for circuit techniques for mitigation (if you are an IC designer, so you don't infringe on Xilinx patents). Some links: http://klabs.org/mapld05/index.htm http://www.selse.org/selse2.org/index.html http://www.crhc.uiuc.edu/SELSE/ http://www.radecs.org/ http://www.nsrec.com/ http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=al_rosettapartners or http://tinyurl.com/ya2wx3 http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=Software%2F8.1i+Windows&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=al_soft_vs_hard or http://tinyurl.com/yj5yh5 http://www.xilinx.com/products/silicon_solutions/market_specific_devices/aero_def/capabilities/radiation_effects.htm ...to show but a very few. Oh, and google for "Austin Lesea" "soft error" (only 157 things there to read). Austin MikeD wrote: > Does anyone know of something more like a "how to" or real design > guidelines for designing rad-hard systems, for system/board-level (ADC, > DAC, power supplies, etc) design, as well as for FPGA and ASIC > hardware? > > I've found a lot of information around that gave specific numbers about > some chips, but I wasn't able to actually understand what the reports > were saying. I know that for an FPGA, I should either use a flash or > antifuse based chip, or otherwise use a chip with configuration CRC > checking and reloading, but how do I select parts like power supplies, > ADC/DACs, and RAMs? Even if my FPGA or ASIC design is solid, I'm > worried that I'm going to end up shooting myself in the foot on the > rest of the system. > > And for FPGAs and ASICs, what are the design considerations? How would > I implement a voting circuit for triple-redundancy in general? And how > would I avoid the possability of an error in the voting circuit? > > Also, if anyone knows of any good books, papers, > courses/classes/training, or even consultants, please let me know. > > Thanks, > Mike >Article: 111340
"MikeD" <mmdst23@gmail.com> wrote in message news:1162408476.090547.148460@i42g2000cwa.googlegroups.com... > Does anyone know of something more like a "how to" or real design > guidelines for designing rad-hard systems, for system/board-level (ADC, > DAC, power supplies, etc) design, as well as for FPGA and ASIC > hardware? > > I've found a lot of information around that gave specific numbers about > some chips, but I wasn't able to actually understand what the reports > were saying. I know that for an FPGA, I should either use a flash or > antifuse based chip, or otherwise use a chip with configuration CRC > checking and reloading, but how do I select parts like power supplies, > ADC/DACs, and RAMs? Even if my FPGA or ASIC design is solid, I'm > worried that I'm going to end up shooting myself in the foot on the > rest of the system. > > And for FPGAs and ASICs, what are the design considerations? How would > I implement a voting circuit for triple-redundancy in general? And how > would I avoid the possability of an error in the voting circuit? > > Also, if anyone knows of any good books, papers, > courses/classes/training, or even consultants, please let me know. > I would say the best place to find help, courses and consultants is the yearly MAPLD conference, there you will find all the SEU junkies :-) http://www.klabs.org/mapld/index.htm Hans www.ht-lab.com > Thanks, > Mike >Article: 111341
Questions: Are the 25 MHz and 200 MHz phase-coherent, or is there a drift between the frequencies? Does the 8-bit word have a start-bit? What is the encoding scheme, I suppose NRZ (High=1, Low=0) Is the data stream continuous? These questions are somewhat interdependent. Food for thought...The learning is yours Peter Alfke On Nov 1, 11:47 am, "fp" <fpga002...@yahoo.com> wrote: > Peter Alfke wrote: > > Please save us from guessing. Describe what you really want to do, and > > what the relevant frequencies are. Otherwise we are all wasting our > > time. > > Peter Alfke > > ================== > > On Nov 1, 8:43 am, "fp" <fpga002...@yahoo.com> wrote: > > > I am working on a 'de-serializer' with Xilinx DCM. The single-bit > > > input stream is sampled by an 8X clock. After 8 bits are stored the > > > register, it activates a single-clock 'done' signal to inform the > > > 1X system to retrieve the data. The data, of course, should only be > > > read once. > > > > I am thinking using a flag register to interface the two systems. The > > > register is controlled by the 8X clock. The done signal sets the flag > > > and the 1X system resets the flag after read. Since DCM is used, > > > presumably there is no meta-stability issue. > > > > Please comment whether this approach is feasible or provide pointer to > > > some reference designs. > > > > Thanks in advance. > > > > S. C.Thanks for your replies. This is just an exercise for myself. > Currently I am trying to learn the design of high-speed serial > interface. Before looking at the nasty analog aspects, such as clock > skew and signal integrity issues, I would like to first to understand > the operation the digital part. Let me just assume that system clock > is 25 MHz and the serial input is synchronized at 200 MHz.Article: 111342
Ray Andraka gave the pertinent answer to your question. The rest of us meandered about... Peter On Nov 1, 12:11 pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > Just to clear up any confusion as to what I wanted in the first place. I > was looking to use a dual port ram with different address and data widths > on side a and b. I have checked with Synplicity and it is currently not > possible to infer a ram of this type. So you need to use Coregen instead. > Apparently they are looking at implementing it in a future release. > > CheersArticle: 111343
I remember the birth of the 22V10 (it's an AMD product, not MMI's) It had the gestation period of an elephant, and it almost killed the design engineers. Too complicated... Times have changed. Peter Alfke On Nov 1, 11:28 am, Ray Andraka <r...@andraka.com> wrote: .Yup, BTDT many times over back in the days when a 22V10 was an awesome > part compared to the rest of what was available. It still occasionally > comes in useful where latency is a concern.Article: 111344
Jon Elson <elson@pico-systems.com> wrote: ... > Maybe I made a mistake, but this product uses a pretty small FPGA > by today's standards. I can get the XC2S50-something-TQ144C for > $12, I know how to mount it to a board myself, etc. A number of the > newer stuff is in packages I at least am not so sure I can handle. At digikey, a XC3S100E-4TQG144C costs 7.45EUR and is configurable by cheap SPI flash... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 111345
"fp" <fpga002006@yahoo.com> wrote in message news:1162410422.770786.26720@k70g2000cwa.googlegroups.com... > > > Thanks for your replies. This is just an exercise for myself. > Currently I am trying to learn the design of high-speed serial > interface. Before looking at the nasty analog aspects, such as clock > skew and signal integrity issues, I would like to first to understand > the operation the digital part. Let me just assume that system clock > is 25 MHz and the serial input is synchronized at 200 MHz. > XAPP224 XAPP671 Also, Antti has done something with the MGTs involving oversampling. He posted it here a while back. HTH, Syms. p.s. BTW, there's nothing nasty about analog projects and SI aspects, some of us make a reasonably decent living out of this type of engineering! ;-)Article: 111346
<nnn> wrote in message news:4548ffa9_1@mk-nntp-2.news.uk.tiscali.com... > Is there a flash adc with a plcc package, anything > above 24MHz minimum sample rate will suit me. > tnx > You know this is comp.arch.fpga, right? ;-) Anyway, go search for yourself :- http://www.interfacebus.com/ I doubt anyone would make a high speed ADC in a PLCC package, this type of package has awful SI properties. HTH, Syms.Article: 111347
Symon wrote: > "fp" <fpga002006@yahoo.com> wrote in message > news:1162410422.770786.26720@k70g2000cwa.googlegroups.com... > > > > > > Thanks for your replies. This is just an exercise for myself. > > Currently I am trying to learn the design of high-speed serial > > interface. Before looking at the nasty analog aspects, such as clock > > skew and signal integrity issues, I would like to first to understand > > the operation the digital part. Let me just assume that system clock > > is 25 MHz and the serial input is synchronized at 200 MHz. > > > > XAPP224 XAPP671 > > Also, Antti has done something with the MGTs involving oversampling. He > posted it here a while back. > HTH, Syms. > p.s. BTW, there's nothing nasty about analog projects and SI aspects, some > of us make a reasonably decent living out of this type of engineering! ;-) Thanks for your help. "Nasty" means hard and good money :) .Article: 111348
maxascent wrote: > Hi > > Just to clear up any confusion as to what I wanted in the first place. I > was looking to use a dual port ram with different address and data widths > on side a and b. I have checked with Synplicity and it is currently not > possible to infer a ram of this type. So you need to use Coregen instead. > Apparently they are looking at implementing it in a future release. Coregen would be overkill to create the RAM. As Mr. Andraka mentioned, just instantiate the primitives. Way easier.Article: 111349
Uwe Bonnes wrote: >Jon Elson <elson@pico-systems.com> wrote: >... > > >>Maybe I made a mistake, but this product uses a pretty small FPGA >>by today's standards. I can get the XC2S50-something-TQ144C for >>$12, I know how to mount it to a board myself, etc. A number of the >>newer stuff is in packages I at least am not so sure I can handle. >> >> > >At digikey, a XC3S100E-4TQG144C costs 7.45EUR and is configurable >by cheap SPI flash... > > Way too small, if I interpret the # of blocks correctly. The XCS30 has 576 LUT cells, the XC3S100E has only 240. I don't think you can compare them exactly, but if I'm interpreting the numbers right, it means that what fits snugly in the XCS30 is far away from fitting in the XC3S100E. Jon
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