Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 111325

Article: 111325
Subject: Re: De-serializer using Xilinx DCM
From: "Andy" <jonesandy@comcast.net>
Date: 1 Nov 2006 10:55:12 -0800
Links: << >>  << T >>  << A >>
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
Subject: Rad-hard (neutron/SEU and space) tutorial?
From: "MikeD" <mmdst23@gmail.com>
Date: 1 Nov 2006 11:14:36 -0800
Links: << >>  << T >>  << A >>
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: 111327
Subject: Re: De-serializer using Xilinx DCM
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Nov 2006 11:16:35 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 01 Nov 2006 11:16:40 -0800
Links: << >>  << T >>  << A >>
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: 111329
Subject: Re: Spectre of Metastability Update
From: Ray Andraka <ray@andraka.com>
Date: Wed, 01 Nov 2006 14:28:39 -0500
Links: << >>  << T >>  << A >>
Andy 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
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Nov 2006 11:33:03 -0800
Links: << >>  << T >>  << A >>
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
Subject: can someone post or email xusbdfwu.hex (1021) from linux ISE 8.2 webpack
From: rponsard@gmail.com
Date: 1 Nov 2006 11:36:14 -0800
Links: << >>  << T >>  << A >>
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 mail


Article: 111332
Subject: Re: XPS Flashwriter tool errors on last location in flash
From: "Vasanth Asokan" <nospam@xilinx.com>
Date: Wed, 1 Nov 2006 11:39:32 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: De-serializer using Xilinx DCM
From: "fp" <fpga002006@yahoo.com>
Date: 1 Nov 2006 11:47:02 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 01 Nov 2006 11:52:05 -0800
Links: << >>  << T >>  << A >>
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: 111335
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Nov 2006 11:59:00 -0800
Links: << >>  << T >>  << A >>
Mike, 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 Treseler


Article: 111336
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Wed, 01 Nov 2006 14:11:40 -0600
Links: << >>  << T >>  << A >>
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.

Cheers

 

Article: 111337
Subject: Need flash adc with plcc format?
From: <nnn>
Date: Wed, 1 Nov 2006 20:12:20 -0000
Links: << >>  << T >>  << A >>
Is there a flash adc with a plcc package, anything
above 24MHz minimum sample rate will suit me.
tnx



Article: 111338
Subject: Re: Spectre of Metastability Update
From: PeteS <peter.smith8380@ntlworld.com>
Date: Wed, 01 Nov 2006 21:01:34 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Rad-hard (neutron/SEU and space) tutorial?
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 01 Nov 2006 13:35:41 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Rad-hard (neutron/SEU and space) tutorial?
From: "Hans" <hans64@ht-lab.com>
Date: Wed, 01 Nov 2006 21:35:48 GMT
Links: << >>  << T >>  << A >>

"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
Subject: Re: De-serializer using Xilinx DCM
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Nov 2006 13:58:29 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Nov 2006 14:01:48 -0800
Links: << >>  << T >>  << A >>
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.
> 
> Cheers


Article: 111343
Subject: Re: Spectre of Metastability Update
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Nov 2006 14:08:15 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Need just a few 5V Spartan
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Wed, 1 Nov 2006 22:38:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: De-serializer using Xilinx DCM
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 1 Nov 2006 22:58:47 -0000
Links: << >>  << T >>  << A >>
"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
Subject: Re: Need flash adc with plcc format?
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 1 Nov 2006 23:06:21 -0000
Links: << >>  << T >>  << A >>
<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
Subject: Re: De-serializer using Xilinx DCM
From: "fp" <fpga002006@yahoo.com>
Date: 1 Nov 2006 15:08:34 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 01 Nov 2006 23:09:16 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Need just a few 5V Spartan
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Wed, 01 Nov 2006 17:32:17 -0600
Links: << >>  << T >>  << A >>


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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search