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
For my scenario it makes sense to regenerate the clock with a DDR IOB register because I want the clock to be source-synchronous with the data/controls. What would be the best way to check the delay on the clock before I implement the regeneration? I'd like to compare this value with the clock to pad values found in Timing Analyzer's data sheet report for the corresponding data/controls. If I find the outgoing clock pad in FPGA Editor and select the net going into it and then right click the net and go to properties and then the pins tab, the tool gives me some delay values but I'm not 100% sure how to read them. Here is what I'm seeing: Name Type Delay(ns) B13.O Input 7.252ns AD17.I Output Driver BUFGCTRL_... Input 0.757ns Pin B13 is rx_clk and pin AD17 is tx_clk. I'm assuming I'd just sum the two delays to get the total routing delay for this outgoing clock, but I wanted to double-check if that's indeed correct. It seems it would make sense, where the 0.757ns delay is from the driver (tx_clk) to the input of the BUFG, and the 7.252ns is from the output of the BUFG to the rx_clk pad.Article: 119401
I'm still running visio 2000, but those shape are build in already to the stock libraries so I assume 2003 should have them already. I do remember they were a pain to find though. I guess I think more like a schematic (PADS, OrCAD etc) person than a MS Visio person. On 5/17/2007 5:11 PM, The digits of Richard Henry's hands composed the following: > Does anyone know of a location from which to download simple logic > symbol shapes for Visio (and gate, or gate, etc)? >Article: 119402
> And they are all very sharp independent of fanout? Pretty much, yes. Routing architectures these days are fully buffered. Every time you switch from one wire to another, you get re- buffered. The average active fanout of a wire is pretty low. Back in the days of pass-transistor based architectures, you could get some bad loading effects, but not anymore. - PaulArticle: 119403
glen herrmannsfeldt wrote: > Peter Alfke wrote: > > (snip) > >> Never thinkof the cable as a lumped capacitance. It is a transmission >> line with distributed C and L plus some series resistance causing >> losses , but I don't believe the losses will bother you much. > > In case of low frequencies and high source impedance the cable > can be treated as lumped capacitance. This was always true > for magnetic phonograph cartridges, designed for 47K load > using 50 ohm coax cable. > > It is also true for analog telephones with 600 ohm source/load > impedance and 100 ohm twisted pair cable. For telephone lines > the capacitance would cause a decrease at higher (4kHz) audio > frequencies. To correct for that in long runs series inductors > (called loading coils) are placed in the line at regular intervals. > The result is better response out to 4kHz, but it drops like a > rock after that. They have to be removed for DSL to work. > > It was also true for the metalization layers of integrated > circuits above about 0.8 micron feature size. Converting the > tools to use a distributed capacitance model slowed down the > conversion to 0.8 micron and below circuitry. > > The above only work where the wavelength is much longer > than the cable length. > > -- glen > Where a line is significantly longer than some fraction [1] of a transition time (the shortest of rise or fall time) it should be treated as a transmission line. For the newest parts, that's less than an inch. The above works on long lines simply because the signal is in a transition state at one point on the line and *not* in a transition state much further back; put colloquially, the transition does not 'see' both points simultaneously. [1]. There is no agreement on what constitutes 'relatively long'. Personally, I use a quarter of the effective transition time length as a red flag, but I always check to see what the effective current / voltage gradient on the line is anyway. Cheers PeteSArticle: 119404
> One other question Paul ... do the Altera/Xilinx parts have any > problems with cut thru power (top and bottom transistors on at same > time) in any worst case situations related to setup violations, clock > rate, or fanout? I wouldn't call it a problem, no. You shouldn't see the power supply collapsing due to this effect. But short-circuit current during switching is non-neglible. It is a big enough effect that we model it precisely in the Quartus power models -- a simple 1/2*C*V^2*t model is insufficient to achieve the level of accuracy we aim for. And the short-circuit current will be influenced by the fanout of each individual routing wire. While this would appear to contradict my previous posting on sharp edges, it doesn't -- even a somewhat slowed down edge in the routing is still fairly sharp, and by the time it reaches the D input of the flop will be significantly sharpened. Regards, - PaulArticle: 119405
On May 17, 5:58 pm, Paul Leventis <paul.leven...@gmail.com> wrote: > But short-circuit current during switching is non-neglible. It is a > big enough effect that we model it precisely in the Quartus power > models -- a simple 1/2*C*V^2*t model is insufficient to achieve the mucho thanks ... JohnArticle: 119406
Hi, I have a design where I have implemented a simple band pass filter found to be working even on hardware in the loop cosimulation. Now i have a problem since i am pretty new to simulink, I do not know how am i suppose to port this design into the XTREME DSP development kit IV. I know i need to use the ADC and DAC blocks in the design but not sure where to put it or what steps to take. Can anyone help me with this, at least to tell me in brief the steps to take and what to modify in the design.? ThanksArticle: 119407
On 17 mai, 06:27, "Ben Jones" <ben.jo...@xilinx.com> wrote: > "James" <j...@j.com> wrote in messagenews:2007051705160950878-j@jcom... > > Notice below that I have an input ep_in. Well, on some cells I don't need > > that input because the number of eprobs is zero. However, if I set > > num_eprobs to 0, ep_in becomes std_logic_vector(-1 downto 0). > > Really you should try comp.lang.vhdl, since this isn't really anything > specific to FPGA technology. :) > > > Is there some way to disable the ep_in port when num_eprobs is 0? If not, > > does anyone have any clever ideas on how to get around this? > > Get around what? A std_logic_vector(-1 downto 0) is perfectly OK, it just > has no elements. It's a "null range", and it's very useful in exactly this > situation. > > If you dislike it, or one of your tools doesn't support it, you could write > yourself a max function and do > > ep_in : in std_logic_vector(max(num_eprobs*precision-1, 0) downto 0); > > But you shouldn't need to. > > Cheers, > > -Ben- a very simple solution is to create special cell without this signal and at each time you can call this component instead of the other using generate, A.Article: 119408
I need some help making sure I constrain a design properly. The input clock to the front end logic runs at 312 MHz. This is input to a DCM that produces clocks on CLK0, CLK90, and CLKDV (div by 8). I am using Xapp861 as an oversampler example so I use both edges of the CLK0 and CLK90 clocks. Data is clocked in on 8 phases by using these clocks (see the app note if you want details). Anyways, after some logic, I eventually end up with recovered data bits on the CLK0 rising edge. I clock these bits into an 8-bit shift register, using the CLK0 clock, to make a byte of recovered data...essentially deserializing the input data. I am forwarding these bytes on to another module. That module clocks in bytes using the CLKDV clock...which is CLK0 / 8. So the byte register running at 312 MHz in the front end is input to a shift register running at 39 MHz. The front end byte register is constantly shifting in bits at 312. And the slower logic is constantyl shifting in the bytes at 39 MHz. I have built the design with a Chipscope ILA core included that I monitor logic with. I can set a parameter to include Chipscope or not. If I use it, I can't run at 312 MHz due to the limitations of Chipscope. So I set the input clock to as high as I can to pass timing and everything works as I expect. The fastest I have used so far is 250 MHz. However, if I don't use Chipscope and crank up the clock to 312 MHz, I get errors (incorrect recovered data bytes). These are the timing constraints that I am using. This is for the 250 MHz case. I change the values for other clock speeds. ##CLK0 Constraint NET "*clkgen_clock0_out_i*" TNM_NET = "clk_0"; TIMESPEC "TS_clk_0" = PERIOD "clk_0" 250MHz HIGH 50 % INPUT_JITTER 70 ps; ##CLK90 Constraint NET "*clkgen_clock90_out_i*" TNM_NET = "clk_90"; TIMESPEC "TS_clk_90" = PERIOD "clk_90" "TS_clk_0" PHASE + 1 ns HIGH 50 % INPUT_JITTER 70 ps; ##CLKDV Constraint NET "*clkgen_clock0_div8_out_i*" TNM_NET = "clk_0_div"; TIMESPEC "TS_clk_0_div" = PERIOD "clk_0_div" "TS_clk_0" / 8 HIGH 50 % INPUT_JITTER 70 ps; My concern is that I need to constrain paths between the front end byte that interfaces to the slower end logic. However, since the CLKDV is derived from the DCM I thought that the CLK0 and CLKDV would be phase aligned and I could be assured that even though the front end byte is changing at 312 MHz (or whatever the fast clock is) it is safe to use the CLKDV to clock those bits in at 1/8th the fast clock speed. Am I wrong? Do I need more specific constraints? Jeez, this ended up being longer and more confusing than I had first thought. I hope it makes sense. Thanks in advance!Article: 119409
ok bummer... probably need to find the maker of the board for replacement of chip or something.. thanks guys ..sigh "austin" <austin@xilinx.com> wrote in message news:f2i61n$out2@cnn.xilinx.com... > Ken, > > Seriously: any evidence of smoke or damage to the package, and it is > all over. It is dead. We call it "electrical over-stress" which is a > polite way of saying "you blew its brains out." > > AustinArticle: 119410
On May 17, 4:50 pm, Hawker
<Hawker{removethispa...@ashevillecommunity.org> wrote:
> I'm still running visio 2000, but those shape are build in already to
> the stock libraries so I assume 2003 should have them already.
> I do remember they were a pain to find though. I guess I think more like
> a schematic (PADS, OrCAD etc) person than a MS Visio person.
>
> On 5/17/2007 5:11 PM, The digits of Richard Henry's hands composed the
> following:
>
>
>
> > Does anyone know of a location from which to download simple logic
> > symbol shapes for Visio (and gate, or gate, etc)?- Hide quoted text -
>
> - Show quoted text -
I remember them from earlier versions available at a previous
employer. Maybe I should ask IT for an upgrade.
Or maybe it's just M$ following the evolutionary path of all their
software from the BS/CS users to the MBA users.
Article: 119411scada wrote: > I have Visio 2003, a search for gates bought it all up. > > > "Richard Henry" <pomerado@hotmail.com> wrote in message > news:1179436266.635156.169680@n59g2000hsh.googlegroups.com... > >>Does anyone know of a location from which to download simple logic >>symbol shapes for Visio (and gate, or gate, etc)? >> > > > Bill Gates??Article: 119412
On May 15, 8:14 pm, Dima <Dmitriy.Bek...@gmail.com> wrote:
> Veeresh,
>
> > I suppose you have two outputs a clk out, and one more signal i.e,
> > control signal. And the edge on control signal has to be kept at a
> > time gap from rising edge of the clock. If control signal is generated
> > w.r.t same clock, clk to output delay constraint can be used.
> > Otherwise sample this signal again with the same clock, and use clk to
> > o/p delay constraint.
>
> Yes, that is what my circuit looks like. Can you show me how I would
> specify this constraint? I googled it but didn't find particular
> information on it.
> Right now I have this in my UCF. I constrained the latch delay to 4.9
> ns, just a bit under 5 ns clock (200 MHz).
>
> ######
> Net "*/my_core/CLK" TNM_NET = dp_clk;
> TIMEGRP "RISING_DP_CLK" = RISING dp_clk;
> TIMEGRP "DP_LATCH" = LATCHES("*/my_core/my_core/accumulate<*>");
> TIMESPEC TS_DP_LATCH = FROM "RISING_DP_CLK" TO "DP_LATCH" 4.9 ns
> DATAPATHONLY;
> ######
>
> Thanks
>
> Dmitriy
Hi,
I normally use constraint editor in ISE's IDE. If you double click
Xilinx constraint editor, there is a tab- "ports". In that, "clock to
tab" button will take u to a window where delay, and the net name can
be specified. tool will generate constraint syntax by it self, and
write it to your ucf file.
Please check if this helps
Regards,
Veeresh
Article: 119413
On May 15, 8:14 pm, Dima <Dmitriy.Bek...@gmail.com> wrote:
> Veeresh,
>
> > I suppose you have two outputs a clk out, and one more signal i.e,
> > control signal. And the edge on control signal has to be kept at a
> > time gap from rising edge of the clock. If control signal is generated
> > w.r.t same clock, clk to output delay constraint can be used.
> > Otherwise sample this signal again with the same clock, and use clk to
> > o/p delay constraint.
>
> Yes, that is what my circuit looks like. Can you show me how I would
> specify this constraint? I googled it but didn't find particular
> information on it.
> Right now I have this in my UCF. I constrained the latch delay to 4.9
> ns, just a bit under 5 ns clock (200 MHz).
>
> ######
> Net "*/my_core/CLK" TNM_NET = dp_clk;
> TIMEGRP "RISING_DP_CLK" = RISING dp_clk;
> TIMEGRP "DP_LATCH" = LATCHES("*/my_core/my_core/accumulate<*>");
> TIMESPEC TS_DP_LATCH = FROM "RISING_DP_CLK" TO "DP_LATCH" 4.9 ns
> DATAPATHONLY;
> ######
>
> Thanks
>
> Dmitriy
Hi,
INST "Q.PAD" TNM = "outputs";
TIMEGRP "outputs" OFFSET = OUT 10 ns AFTER "clk" HIGH ;
this state that all nets grouped as outputs will have a clk to o/p
delay of 10ns w.r.t rising edge of clk .
Article: 119414Hmm just continuing to hijack this thread. Is it possible to do a readback after i have programmed the chip? I wish to check if the design configured into the chip is the same as the one from the readback. This way I know that if there is an error, it is confirmed there nothing i can do. KenArticle: 119415
On May 17, 6:53 pm, cs_post...@hotmail.com wrote: > On May 16, 11:20 pm, mohan <kulka...@math.net> wrote: > > > i am using altera cpld.using quartus 2 tool to programme it through > > byte blaster cable. > > I have installed drivers for the cable.made connections intact. > > i am getting error as "Unable to scan device." > > My assusmption was may be because of loose contacts this error was > > coming.but connections are intact.supply are proper,still i cann't > > programme cpld. > > is there any possibility of jtag port of cpld being damaged? > > i had programmed the cpld through the same method.but today i am not > > able to programme it,nor erase cpld.what the functionality cpld do > > have stored in it,still there. > > Of course it's possible. It's not at all common with some types of > devices to blow some of their I/O's while others and the core remain > apparently functional. > > But I doubt it's the most probable problem. Much more likely > something is strange with your board, programmer connection, or > computer configuration. > > The logic thing to do in an industry environment would be to try > another board/device with the same programmer setup. I take it you > don't have another available? Thanks for the reply. But i have cheked the connections.thery are intact.i think that might be problem of jtag port being damaged. can i use xilinx parallel IV cable to download in altera cpld.Article: 119416
Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes: > In news:hWW2i.1605$4Y.801@newssvr19.news.prodigy.net timestamped Thu, > 17 May 2007 07:22:50 -0400, "KJ" <kkjennings@sbcglobal.net> posted: > "[..] > > [..] > 1. Simulation allows for zero propogation delays through logic > 2. The logic type most commonly used (i.e. std_logic) allows signals to be > 'unknown'. > > Neither of these two things model the real world behaviour of anything at > all....and yet they are both powerful aids for designing logic properly and > are 'good' things from a design perspective. > > [..]" > > > Hi, > > How can zero delays or std_logic be useful? > Because they allow you to create a simulation of your circuit at a level of abstraction removed from those details. If you follow a standard synchronous design template, you can then use a synthesiser to get a netlist that does the same thing as your simulations. Lots of us do it all the time :-) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 119417
M Ihsan Baig <mirzamihsan@hotmail.com> writes: > Hello, Is there any expert who can guide me about the following > problem: > > I need video system with following main specifications. > 1) Input : standard video formats File formats, or camera sourced video? > 2) compression: MPEG4/MPEG2 etc. > 3) Output: RS232 You must be working with pretty small frames and/or frame rates to expect to get the compressed video down RS232! Even 320x240x10fps @ 8bpp = 5.8Mbits/sec. You'd be wanting a compression ratio of about 50x to get that down 115kbps RS232, which I guess is feasible with H.264. What's the application? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 119418
Hi, I was wondering if anyone had any experience with using Synopsys' DesignWare libraries in a Precision RTL FPGA flow? I am especially interested in the automatic conversion of DW RAM devices to Altera blocks, but I am also curious about the use of the other components as well (arbiters, fifos, etc.). I assume the specific components will be instantiated (and simulated) using a black box methodology, but what happens after that, how do I push these components all the way down to my FPGA? Thanks, -- Edmond Cot=E9Article: 119419
In news:1179331157.808046.24310@y80g2000hsf.googlegroups.com
timestamped 16 May 2007 08:59:17 -0700, Anne L. Atkinson posted:
"I am currently working on a NASA program focused on the development
of
Radiation-Hardened Electronics for Space Environments (RHESE). One
portion of the sub-project I am working in support of is aimed at
developing reconfigurable modular spare electronic parts for avionics
systems.
An ultimate goal of this sub-project is to reduce the total number of
spare parts that must be flown on a mission by having spares that are
reconfigurable such that, for example, they could function as a DSP or
microprocessor or microcontroller at any given time (just one specific
application at any given time)."
When I had originally read the second paragraph it had not seemed to me
that the type of spare items (e.g. "a DSP or
microprocessor or microcontroller") are to be so restricted as to be
only MicroBlazes; PicoBlazes; and some as yet undecided DSPs listed
further down in
news:1179331157.808046.24310@y80g2000hsf.googlegroups.com for Path
2. Though you mentioned spare copies of what are already planned for a
spacecraft, I suspect that this could be a narrower view than
necessary: e.g. gyroscopes or other parts can eventually become noisy
(or even completely useless) so some leftover unused logic could
conceivably be used to apply extra filtering (or extra computational
power for a more advanced control law) instead of simply providing a
replacement of part of the originally designed electronics. Of course,
we could spend forever thinking of every possible alternative way to
exploit something.
If you plan to reduce the number of spare devices on board by using
reconfigurable spare devices, you run the risk that you will need more
physical spares than you actually launched. Of course, this could
also happen without reconfigurable spare devices.
" (And one obvious question here is --
exactly what specific functionality is desired from the
microprocessor, microcontroller, or DSP that this part will implement?
- that does not seem to be entirely clear yet on this project - when I
pose those questions, I don't get answers. That's a bit frustrating
(to me anyhow), but for now, that is just how it is!)
[..]
Also, since "path 1" will require a lot more time and effort for in-
house design / development to implement the desired functionalities,
I am thinking that "path 2" may provide for a good initial
demonstration of capabilities (in general, since at current there do
not seem to be specifics with regard to the desired capabilities!),
with the hopes that "path 1" can be pursued over a longer period of
time with a greater degree of focus on the _specific_ capabilities and
characteristics that are ultimately decided upon.
[..]
I wish I could provide more specifics on exactly what specific
functionality is desired from the microprocessor, microcontroller, or
DSP that this part will implement... As I said, that is currently a
frustration of mine, and I know that makes it tough to provide insight
on the best development path. I am hoping that as the process of
specifying appropriate development platforms progresses, the
performance and other characteristics of the platforms specified will
help the folks here work towards more clarity on the specifics of what
they need."
I empathize with discontentment arising from questions being
unanswered. E.g. on April 13th, 2007 and May 15th, 2007 I asked the
main tutor for my Ph.D. would we be able to obtain papers such as
T. Vladimirova and D. Zheng, "Reconfigurable System-on-a-Chip Based
Computing Platform for Small Satellites", "Proceedings of the 1st
Annual ESA Workshop on Spacecraft Data Systems and Software", SDSS
2005, ESTEC, Noordwijk, The Netherlands, 17-20 October 2005 and
others listed on
WWW.EE.Surrey.ac.UK/SSC/G11/P5/
and
T. Vladimirova, P. Davies, M. Sweeting, "Reconfigurable Computing
for Micro-Satellites", DASIA 2006 listed on
WWW.Eurospace.org/dasia2006_programme_update_31_07_06.pdf
and I am unfortunately still waiting.
"I've been tasked with evaluation of potential development platforms
for these modular spares. This is a bit "out of the box" for me -- my
background is primarily in system software development -- I'm not a
hardware designer -- but, this has been very interesting and I'm
trying to learn and do my best at it."
I wish success for the project. The longest of my degrees so far was for
computer science. I am not exactly perfect myself, see e.g.
news:f2hoij$v4e$1@newsserver.cilea.it
"After spending some time trying to spin-up on reconfigurable
hardware / systems through books (a colleague lent me a copy of
The_Design_Warrior's_Guide_to_FPGAs_ by Clive "Max" Maxfield which has
been a very good tutorial / reference - I recommend it!)"
I am not familiar with Clive Maxfield.
" papers, and
google searches, my current thoughts are towards a "dual path"
development plan:
Path 1: Use a cutting edge platform in the genre of what Clive "Max"
Maxfield refers to as a "Field Programmable Node Array (FPNA)" in the
above mentioned book in an attempt to get the most flexible end
product from the standpoint of reconfigurability, power consumption,
board/device size,"
I am unfamiliar with the term ""Field Programmable Node Array (FPNA)"".
" and a novel approach to provision of radiation
tolerance."
If it would not be illegal copyright infringement to do so, could you
please reveal what this approach is?
" Current plan here is to use a platform and associated
development toolset provided by a small start-up company -- so
relatively high risk, but good potential benefits if it all comes
together well."
Do you have a particular "small start-up company" in mind, or do you
simply associate new technology as outside the realm of established
companies?
"Path 2: [..] which uses:
1) MicroBlaze soft core to implement microprocessor functionality
2) PicoBlaze soft core to implement microcontroller functionality
3) ??? some soft core provided through the above development tools
(or from some other source?) to implement DSP functionality"
What if someone wanted to use a different instruction set processor?
E.g. someone in NASA uses a Silicon Laude 8051 clone,
WWW.SiliconLaude.com
(Robert F. Jarnot, "Re: 8051 IP core with JTAG debugger for FPGA?",
comp.arch.fpga, Thu, 23 Feb 2006 13:33:10 -0800, Message-ID:
<dtl9mo$b6b$1@nntp1.jpl.nasa.gov> ), and someone else in NASA uses a
completely different instruction set.
"Path 2: Target a Xilinx FPGA-based platform of some type - from what
looking through information / references on the Xilinx web site, I'm
thinking of possibly using a combination of Xilinx's ISE and EDK
development tools to develop a reconfigurable platform [..]"
Xilinx is not the only manufacturer of FPGAs. In what way is using
extremely buggy software (whether from Xilinx or another supplier of
buggy software for FPGAs) not risky?
"[..]
So I have some questions / concerns, on which I hope some folks with
more knowledge of this arena can help give me insight:
* Am I going down reasonable paths to pursue the end goals here? I
have a little wellspring of doubt about all my thoughts since hardware
specs / design is not something in which I have experience (plus it's
just kinda my nature to doubt and worry!!! ;) :) ). I'd appreciate
any insight, positive or negative, on this point."
It is good to be skeptical.
"* I was going to try to contact a Xilinx field engineer to ask about
the viability of a Xilinx-FPGA based platform, and if that is viable,
to get recommendations on appropriate platforms / development boards /
development tools / IP cores to work towards the desired end-goal
functionality;"
Perhaps you are not skeptical. Which company do you suspect an
employee of Xilinx would recommend?
" however, from looking through the Xilinx web site
(which provides a lot of excellent reference information -- it's
almost overwhelming to a newby in this arena like me!) "
Be wary of the information concerning GEO on Slide 27 of
WWW.Xilinx.com/products/milaero/MilAero.pdf
[VII Testing - SEFI2
* MTBF calculations for POR+JCFG SEFI at different orbits
. POR SEFI is worse case ; JTAG is better than SelectMAP
Orbit Altitude Inclination Upset Rate MTBF
(km) (degrees) (SEU/device/day)
(Years/Event)
LEO 400 51.6 2.33E-06 2,185
LEO 800 22.0 9.87E-06 277
Polar 833 98.7 5.44E-06 503
Const. 1,200 65.0 2.74E-05 100
GEO 36,000 0.0 2.00E-06 1,369]
as GEO is actually not a relatively safe location for electronics
(especially when it is not part of the Earth's magnetosphere during
solar maximum!).
Slide 36 of
WWW.Xilinx.com/products/milaero/MilAero.pdf
contains something which is plainly untrue:
"TMR Overview
* Triplication Technique is called TMR (Triple
Module Redundancy)
. Logic is triplicated INSIDE the FPGA
* Don.t have to do this by hand anymore!!! TMRTool
. Single Point Failures are eliminated
. TMR analysis includes:
* Throughput Logic
* Feedback Logic w/ voters
* Output voting"
as confessed on Slide 36:
"[..]
* We can.t PREVENT SEUs and SETs...
* We can only MITIGATE their effects...
[..]"
I.e. a single point failure is not eliminated: where the winning
decision of a voting system is determined is a single point of
failure. One approach (which is still not perfect) (which is not
mentioned on that slide which is concerned with TMR inside one FPGA)
is to use three FPGAs as voters and for the component which is to
decide the winning value of the vote, to use a component in which
greater confidence in its resistance to radiation is justified (e.g. a
one time field programmable gate array), e.g. a checker of a safer
technology is mentioned in e.g. Cheung Ed;
William I. Clement; and Ray Bietry, "Reconfigurable Avionics for
Hubble Servicing Missions", MAPLD 2003,
Klabs.org/richcontent/MAPLDCon03/papers/p/p11_cheung_p.pdf
and seems to be shown on Slide 57 of
WWW.Xilinx.com/products/milaero/MilAero.pdf
(unfortunately the Cheung; Clement; and Bietry paper and another MAPLD
paper did not contain anything positive about Single Event Transients
(for which one might deliberately use clocks out of phase for voters
as in the spatial voting scheme reviewed in Blum; Delgado-Frias;
"Schemes for Eliminating
Transient-Width Clock Overhead From SET-Tolerant Memory-Based
Systems", "IEEE TRANSACTIONS ON NUCLEAR SCIENCE", VOL. 53, NO. 3, JUNE
2006) and I received no response to my complaints (but a strict subset
of the email addresses I tried bounced)).
Prof. William H. Sanders boasted during a lecture (this webpage does
not go into enough detail to show the boast:
WWW.IET.UniPi.It/dottinformazione/Formazione/OffForm2006/Sanders/Validating.html
) that many years ago he had convinced people of NASA's that some
reliability problem could be satisfactorily tackled. In his solution,
voters or similar checkers were used but at least in the lecture he
had not addressed the issue of a failure in a checker so I raised this
issue. He has responded in the lecture that of course the issue of who
checks the checker is an unsolvable problem and so he would have much
simpler (and hence hopefully less prone to obscure, complicated
errors) logic as a checker than the logic it checks.
WWW.Xilinx.com/bvdocs/appnotes/xapp181.pdf
contains many more techniques, none of which is perfect as perfection
is not possible if any arbitrary fault is possible.
Always be sceptical of the context in which something is claimed,
e.g. from Slide 4 of both
WWW.Xilinx.com/products/milaero/MilAero.pdf
and
WWW.Xilinx.com/esp/mil_aero/collateral/presentations/radiation_effects.pdf
:"Rad-Tolerant vs Military
* Rad-Tolerant devices = Military Devices +
. Epitaxial Substrate Wafer (2 microns)
* Used for latch-up immunity
[..]"
but from other slides such as Slide 65 of
WWW.Xilinx.com/products/milaero/MilAero.pdf
:"[..]
Solution: Use of epitaxial substrate => Virtex II is immune to SEL
upto LET > 160 Mev.cm2/mg"
I was surprised at home much attention is given to neutrons on
WWW.Xilinx.com/esp/mil_aero/collateral/presentations/radiation_effects.pdf
but by Slide 80 I remembered that that file is also relevant to aircraft.
In news:1179331157.808046.24310@y80g2000hsf.googlegroups.com
timestamped 16 May 2007 08:59:17 -0700, Anne L. Atkinson posted:
"[..] Where would I
find good points of contact to ask questions and get advice on
potential platforms / development tools, etc. to begin determining the
best selections for a "path 2" platform?
[..]"
John Williams has already advised you in
news:464B9365.9040105@itee.uq.edu.au
of NASA employee Richard B. Katz's website for MAPLD. I am sure that
Richard B. Katz would love to help you. However, I am not convinced
that everything which is accepted for MAPLD is of high quality.
Dr. Tanya Vladimirova is a pleasant person to speak to and might also
be willing to help you.
I may be willing to help you, as part of my Ph.D., and quite possibly I
will not need money from you as I already receive funding from a scholarship.
However, I might not know what you need an assistant to know.
In news:1179342111.272834.71290@u30g2000hsc.googlegroups.com
timestamped 16 May 2007 12:01:51 -0700, Manny <mloulah@hotmail.com>
posted:
"Historically, anti-fuse technology was the major player in RHESE
applications but can't offer in-field reconfigurability."
Perhaps suitability for space should be more important than
reconfigurability. Various factors affecting a reconfigurable FPGA
such as temperature can not be expected to be the same on the
engineering model as on the board on orbit so plenty of problems could
result from delicate timing violations.
" It might be
worthwhile to check out the very recent FLASH-based FPGAs from Actel."
Someone in the European Space Agency advised against Flash (much as
one would be wary of EEPROM) but I do not know of what that person
would recommend to use.
"Though significantly sparser than their SRAM counterparts (no built-in
special function ASIC blocks e.g. DSP MACs), if you'r willing to
compromise on this by having a reconfigurable DSP loosely coupled with
FLASH FPGA accelerator, you might be able to pull off a decent match
to what you seek. Still this means that you guys have to develop the
whole reconfigurable platform with its supporting tools; a non-trivial
task I reckon."
Maybe.
Regards,
Nicholas Paul Collin Gloster
Article: 119420On May 17, 11:01 pm, motty <mottobla...@yahoo.com> wrote: > I need some help making sure I constrain a design properly. The input > clock to the front end logic runs at 312 MHz. This is input to a DCM > that produces clocks on CLK0, CLK90, and CLKDV (div by 8). I am using > Xapp861 as an oversampler example so I use both edges of the CLK0 and > CLK90 clocks. Data is clocked in on 8 phases by using these clocks > (see the app note if you want details). Anyways, after some logic, I > eventually end up with recovered data bits on the CLK0 rising edge. > > I clock these bits into an 8-bit shift register, using the CLK0 clock, > to make a byte of recovered data...essentially deserializing the input > data. I am forwarding these bytes on to another module. That module > clocks in bytes using the CLKDV clock...which is CLK0 / 8. So the > byte register running at 312 MHz in the front end is input to a shift > register running at 39 MHz. The front end byte register is constantly > shifting in bits at 312. And the slower logic is constantyl shifting > in the bytes at 39 MHz. > > I have built the design with a Chipscope ILA core included that I > monitor logic with. I can set a parameter to include Chipscope or > not. If I use it, I can't run at 312 MHz due to the limitations of > Chipscope. So I set the input clock to as high as I can to pass > timing and everything works as I expect. The fastest I have used so > far is 250 MHz. However, if I don't use Chipscope and crank up the > clock to 312 MHz, I get errors (incorrect recovered data bytes). > These are the timing constraints that I am using. This is for the 250 > MHz case. I change the values for other clock speeds. > > ##CLK0 Constraint > NET "*clkgen_clock0_out_i*" TNM_NET = "clk_0"; > TIMESPEC "TS_clk_0" = PERIOD "clk_0" 250MHz HIGH 50 % INPUT_JITTER 70 > ps; > > ##CLK90 Constraint > NET "*clkgen_clock90_out_i*" TNM_NET = "clk_90"; > TIMESPEC "TS_clk_90" = PERIOD "clk_90" "TS_clk_0" PHASE + 1 ns HIGH 50 > % INPUT_JITTER 70 ps; > > ##CLKDV Constraint > NET "*clkgen_clock0_div8_out_i*" TNM_NET = "clk_0_div"; > TIMESPEC "TS_clk_0_div" = PERIOD "clk_0_div" "TS_clk_0" / 8 HIGH 50 % > INPUT_JITTER 70 ps; > > My concern is that I need to constrain paths between the front end > byte that interfaces to the slower end logic. However, since the > CLKDV is derived from the DCM I thought that the CLK0 and CLKDV would > be phase aligned and I could be assured that even though the front end > byte is changing at 312 MHz (or whatever the fast clock is) it is safe > to use the CLKDV to clock those bits in at 1/8th the fast clock > speed. Am I wrong? Do I need more specific constraints? > > Jeez, this ended up being longer and more confusing than I had first > thought. I hope it makes sense. > > Thanks in advance! I did not research the DCM lately, so perhaps someone can correct me if I am misinformed... but I have heard rumors that for example if one uses the CLK0 and CLK2X outputs, that the outputs are phase coherent but may have significant clock skew that is a function of their respective clock loading. If this is true, perhaps the same can be said for CLK0 and CLKDV. A back-annotated timing sim may or may not reveal this. ---------- Question When chipscope was not used and errors were detected, was chipscope removed or just not exercised? If it was removed, then that would tend to support the clock skew loading theory. I suspect that if it is clock skew, one would have to change the method of how the data is transferred to the slower clock domain. My 2 cents. -NewmanArticle: 119421
"Edmond Coté" <edmond.cote@gmail.com> wrote in message news:1179497392.123886.151610@u30g2000hsc.googlegroups.com... Hi, I was wondering if anyone had any experience with using Synopsys' DesignWare libraries in a Precision RTL FPGA flow? I am especially interested in the automatic conversion of DW RAM devices to Altera blocks, but I am also curious about the use of the other components as well (arbiters, fifos, etc.). I assume the specific components will be instantiated (and simulated) using a black box methodology, but what happens after that, how do I push these components all the way down to my FPGA? From what I understand from the manual, Precision supports a wide range of the datapath and logic DesignWare modules. If you use a non-supported module then you will end up with a blackbox. You then need to provide the RTL/EDIF for this block before going to P&R. If Precision can translate all your Designware blocks then you can of course use the Altera primitive libraries for any simulation, however, if you get any blackboxes then as far as I know the only option you have is to use VCS but I might be wrong, Hans www.ht-lab.com Thanks, -- Edmond CotéArticle: 119422
Hi http://code.google.com/p/fpga-retro/downloads/list there is the distribution archive for the one chip MSX project would be fun to convert it for some xilinx board, :) I have been hunting for those VHDL code for ages, all links ended dead somewhere, but with heavy searching the archive was found too. AnttiArticle: 119423
fpga_toys@yahoo.com wrote: (snip) > Metastability can occur any where we have a feedback path in logic, > but it's best understood in terms of FF's. It's generally defined as > an event when a FF continues to oscillate longer than a clock period. The way I think of it is that most people want to put some logic between FFs to get something done. They then want to clock the circuit reasonably fast. The result is that the margin available for metastability to resolve might be 1/5 of a clock cycle. I don't think I would design closer than that. Adding one extra FF gives one complete cycle for it to resolve, or five times as long. (snip) > This is the state we are in with a synchronous system with setup > violations, as the OP specifically questions about. As any number of > inputs to FF's hover around the metastable input voltage, the amount > of oscillation will increase, and increase dynamic power as a > result ... the amount of power increase depends directly on the system > design. If you are close enough to worry about setup times, then you have no margin left for temperature or voltage tolerance. Even without metastability the system could easily fail. (snip) -- glenArticle: 119424
HT-Lab wrote: > From what I understand from the manual, Precision supports a wide range of > the datapath and logic DesignWare modules. If you use a non-supported mod= ule > then you will end up with a blackbox. You then need to provide the RTL/ED= IF > for this block before going to P&R. That's what I would assume, but does it make any sense. If you specify a specific adder in the middle of your datapath, how does Precision accurately resolve its timing (pre-PNR)? The other option that I can think of, is that Precision automatically converts all the DW blackboxes to its own primitives, but that is a flat out guess.. > If Precision can translate all your Designware blocks then you can of cou= rse > use the Altera primitive libraries for any simulation, however, if you get > any blackboxes then as far as I know the only option you have is to use V= CS > but I might be wrong, That shouldn't be an issue, you can find the DesignWare blocks somewhere in $SYNOPSYS/dw and compile them yourself. -- Edmond Cot=E9
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