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 131075

Article: 131075
Subject: Re: A Challenge for serialized processor design and implementation
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 9 Apr 2008 14:56:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 9 Apr., 22:51, rickman <gnu...@gmail.com> wrote:
> On Apr 8, 5:30 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
> > Re Quad Serial memory devices, and execute in place :
> > I see SST have just released a Quad device as well.
> > $1.16/10K for 16MBit
>
> > Good news, and bad news :
>
> > Good news: 80MHz nibble rate. They also added 8 & 16 bit address modes,
> > to the default 24 bit.
> > Bad News: These short-jump modes _are_ signed relative,
> > BUT they do NOT cross page boundaries. (ie Just like the 8048...)
>
> > So, the idea falls short of being usable in relocatable code.
>
> > Pity, as a memory-opcode jump is a good way to save some bandwidth
>
> > Why make something signed relative, but then have it page-wrap ?
>
> > - was this a bug, maybe they intended it to work properly, but found
> > an oops, and changed the data to match the silicon ?
>
> I knew there was something fundamentally wrong with the idea of a very
> slow processor in an FPGA executing from an external memory chip.  I
> figured out what it is.  Using even *less* real estate inside the FPGA
> and by adding only two, very inexpensive chips, I can add an
> *external* processor and (optionally) a serial memory chip to
> interface with the FPGA through a serial port such as SPI, I2C or
> custom.  Rather than try to implement a full processor in minimal
> gates, isn't it easier and more effective to use a serial control to
> allow an external processor to control the FPGA, while matching the
> size and cost to the job?
>
> Even 32 bit flash based ARM chips are available for less than the cost
> of the serial memory.

;) I am doing myself exactly this
A3P060 3.5
AT45DB161D 1.0
ATmega88 0.8
==========
;)

but there is still room and need for low FPGA estate serial engine
at least i think so

Antti





Article: 131076
Subject: Re: A Challenge for serialized processor design and implementation
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 10 Apr 2008 10:08:01 +1200
Links: << >>  << T >>  << A >>
rickman wrote:
> On Apr 8, 5:30 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>Re Quad Serial memory devices, and execute in place :
>>I see SST have just released a Quad device as well.
>>$1.16/10K for 16MBit
>>
>>Good news, and bad news :
>>
>>Good news: 80MHz nibble rate. They also added 8 & 16 bit address modes,
>>to the default 24 bit.
>>Bad News: These short-jump modes _are_ signed relative,
>>BUT they do NOT cross page boundaries. (ie Just like the 8048...)
>>
>>So, the idea falls short of being usable in relocatable code.
>>
>>Pity, as a memory-opcode jump is a good way to save some bandwidth
>>
>>Why make something signed relative, but then have it page-wrap ?
>>
>>- was this a bug, maybe they intended it to work properly, but found
>>an oops, and changed the data to match the silicon ?
> 
> 
> I knew there was something fundamentally wrong with the idea of a very
> slow processor in an FPGA executing from an external memory chip.  I
> figured out what it is.  Using even *less* real estate inside the FPGA
> and by adding only two, very inexpensive chips, I can add an
> *external* processor and (optionally) a serial memory chip to
> interface with the FPGA through a serial port such as SPI, I2C or
> custom.  Rather than try to implement a full processor in minimal
> gates, isn't it easier and more effective to use a serial control to
> allow an external processor to control the FPGA, while matching the
> size and cost to the job?

Yes, Of course;
That's the litmus test ALL soft-CPU choices must face.

It is nearly always better to use a dedicated Microcontroller IF one
is available that fits.
(and mop the 'other stuff' up in the (now hopefully smaller) FPGA)

The range of dedicated controllers is also expanding all the time.
Ethernet and USB are becoming small incremental adders.

I see the serial CPU as something more of a paper exercise,
that 'defines the numbers' :
How small can it be, and how slow ?
What chips are out there, that support such a design ?

Quad-SPI devices are relatively new, and give another
pincount/bandwidth design point.

FPGA vendors need to include them on their configuration memory
support list, for faster config times.

SST claim they target Execute in place with their device. I've asked SST 
for some examples of that, and for examples of a design that actually 
uses their strange wraping-relative-jumps :)

-jg







Article: 131077
Subject: Specifying strict setup constraint in ISE
From: Wojciech Zabolotny <wzab@ise.pw.edu.pl>
Date: Wed, 9 Apr 2008 22:36:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi All,

I need to specify the strict setup time for the group of signals.
It can be relatively high, but I need very low skew between the signals.
In Quartus for Altera FPGAs I can define it with the sdc contraints as
follows:

set_max_delay -from [get_ports MY_BUS[*]] -to [get_registers *] 6.000
set_min_delay -from [get_ports MY_BUS[*]] -to [get_registers *] 5.000 

With the constraints above the code compiles and opperates correctly.

However in Xilinx ISE:
TIMEGRP "MY_BUS_GRP" OFFSET = IN 6 ns BEFORE "SYS_CLK"
does not allow me to specify both the minimal and maximal setup time...

As the result, I get the implementation, where for one signal the setup
time is equal to 5.99 ns, but for the other - e.g. only 3ns .
Because the signals are then oversampled at high frequency it results in
the unacceptable skew...

How can I solve this problem?
Using OFFSET IN AFTER is problematic, as I'd need to adjust all
constraints if the period of the clock changes :-(.
-- 
TIA & Regards,
Wojtek


Article: 131078
Subject: Re: Specifying strict setup constraint in ISE
From: Peter Alfke <alfke@sbcglobal.net>
Date: Wed, 9 Apr 2008 16:53:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 3:36=A0pm, Wojciech Zabolotny <w...@ise.pw.edu.pl> wrote:
> Hi All,
>
> I need to specify the strict setup time for the group of signals.
> It can be relatively high, but I need very low skew between the signals.
> In Quartus for Altera FPGAs I can define it with the sdc contraints as
> follows:
>
> set_max_delay -from [get_ports MY_BUS[*]] -to [get_registers *] 6.000
> set_min_delay -from [get_ports MY_BUS[*]] -to [get_registers *] 5.000
>
> With the constraints above the code compiles and opperates correctly.
>
> However in Xilinx ISE:
> TIMEGRP "MY_BUS_GRP" OFFSET =3D IN 6 ns BEFORE "SYS_CLK"
> does not allow me to specify both the minimal and maximal setup time...
>
> As the result, I get the implementation, where for one signal the setup
> time is equal to 5.99 ns, but for the other - e.g. only 3ns .
> Because the signals are then oversampled at high frequency it results in
> the unacceptable skew...
>
> How can I solve this problem?
> Using OFFSET IN AFTER is problematic, as I'd need to adjust all
> constraints if the period of the clock changes :-(.
> --
> TIA & Regards,
> Wojtek

There is no way any FPGA (or other IC) can guarantee a combinatorial
plus routing delay to be 5 ns min, 6 ns max. Just normal ambient
temperature and Vcc variations exceed these tolerances, You may
perhaps be able to make the delays track (which is what you seem to be
after) but absolute delay precision is out of the question,
Now, if you register these values in a register driven by a global
clock, the Qs may have very little delta delay,
BTW, in my book, "set-up time" is a timing requirement on the D-input
of a register or flip-flop, never a physical delay. Maybe that's the
difference between the two manufacturers...
Peter Alfke, Xilinx

Article: 131079
Subject: Re: Serial Transmission w/o 8B/10B encoding
From: shakith.fernando@gmail.com
Date: Wed, 9 Apr 2008 18:28:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 5:12 am, Peter Alfke <pe...@xilinx.com> wrote:
> On Apr 9, 10:05 am, shakith.ferna...@gmail.com wrote:
>
>
>
> > On Mar 31, 11:57 am, "TC" <no...@nowhere.com> wrote:
>
> > > "Dave" <dhsch...@gmail.com> wrote in message
>
> > >news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.com...
>
> > > > On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
> > > >> <shakith.ferna...@gmail.com> wrote in message
>
> > > >>news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com...
>
> > > >> > Hi,
>
> > > >> > We have developed a High Speed on FPGA using the MGT/RocketIO to
> > > >> > generate high speed signals. Also we receive the high speed signals
> > > >> > using the MGT. Due to the nature of the application, we require a pure
> > > >> > signal without encoding (We have switched off the 8B/10B encoding in
> > > >> > the MGT). The problem is that it effects the clock recovery accuracy
> > > >> > in the received signal as there might not be  good DC balance in the
> > > >> > signal. Which in turn effects the data received. And MGT is a black
> > > >> > box to us.
>
> > > >> > Two options-
> > > >> > 1. Another encoding mechanism such that we have pure signal and good
> > > >> > clock recovery.
> > > >> > 2. Or is there a parameter in MGT to improve the clock recovery.
>
> > > >> > We are looking for some solution around this problem.
>
> > > >> > Our setup:
> > > >> > FPGA - Xilinx Virtex II Pro
> > > >> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > > >> > Software - ISE 9.1i
>
> > > >> > Best Regards
> > > >> >Shakith
>
> > > >> The clock recovery circuitry requires that there be a minimum number of
> > > >> received edges per unit time. Otherwise, the recovered clock edges will
> > > >> drift with respect to the data stream.
>
> > > >> If you don't use some type of encoding (e.g. 8B/10B), or you don't insure
> > > >> that your raw data ALWAYS provides this minimum edge density requirement,
> > > >> then the clock/data recovery circuitry will not work.
>
> > > >> Bob
>
> > > > Perhaps a scrambler/descrambler using LFSR's would help alleviate any
> > > > edge density or DC bias problems by randomizing the data a bit? I'm
> > > > not sure if it would guarantee correct reception, but it may help.
>
> > > You don't say why you need a "pure" signal (no coding). I could assume that
> > > you are trying to eliminate the overhead of coding (with 8b10b you only get
> > > an effective data bandwidth of 80%).
>
> > > You didn't say whether or not you MUST have a DC-balanced signal. Are your
> > > transmitters AC-coupled to the receivers? If yes, the you must have a
> > > DC-balanced signal and coding IS required.
>
> > > You also don't mention your clocking requirements. Do you have a common
> > > (distributed) reference clock, or are the reference clocks independant?
>
> > > Typical clock recovery circuits assume plesio-synchronous operation. This
> > > means the the reference clocks can be independent but must be within +/- XYZ
> > > PPM (parts-per-million) of each other. For a receiver to track the
> > > transmitter the receiver must recover the clock (and data) from the
> > > transmitted bit stream. At high speeds this is done using PLLs. For the PLLs
> > > to perform well they require frequent edges in the transmitted bit stream.
>
> > > Without a coded bit-stream you can't have DC-balance and you can't gaurantee
> > > frequent edges for the PLL. So if you really can't have a coded bit-stream
> > > then you must have a distributed (common) reference clock and you cannot use
> > > AC-coupling.
>
> > > If you are trying to minimize the overhead of coding look at other coding
> > > methods like 64b/66b codes. These are more efficient but still have the
> > > benefits of DC-balanced tranmission and frequent clock edges.
>
> > > Note that another benefit of 8b10b is the ability to align your symbols. How
> > > are you going to know the boundaries of a byte, a packet, etc., without a
> > > coded stream and use of non-data symbols (control symbols)? If you have
> > > independent reference clocks how are you going to avoid underrun and overrun
> > > of the reciever withouth control symbols (i.e. insertion and removal of idle
> > > characters)? Do you need any form of closed-loop flow control, error
> > > signalling, etc.? If yes, how are you going to do this without control
> > > symbols?
>
> > > TC
>
> > Thanks...we also noticed a new problem
> > When we run our implementation on FPGA, there is loss of data on the
> > non-active part of the signal. Its set to be 20180bits, but the number
> > of bits received is less than that. The loss of data is not consistent
> > either. But this doesn't appear in simulation in Modelsim. One reason
> > could be the fact that the DC Balance is not there. But does it affect
> > the data recovery from serial to parallel?
> > Another option is use an external modulator chip on the receiver
> > signal to achieve DC balance and the use the new modulated signal on
> > MGT and decode it  inside the FPGA.
>
> > Our setup:
> > MGT Speed - 2 Gpbs
> > FPGA - Xilinx Virtex II Pro
> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > Software - ISE 9.1i
>
> You are running into a fundamental limitation. What you receive is NRZ
> data, High for 1, Low for 0 (or something similar). You know that a
> High level of a certain duration means three ones in a row, but the
> receiver needs a clock to separate the bits. It gets this clock from
> its own PLL oscillator that is being kept alive and accurate by re-
> synchronizing itself from any transitions in the data stream. That's
> why you must have a transition quite often. Maybe you can run for 70
> bits without a transition, but after tht, the PLL oscillator will
> drift and will not partition the incoming data stream properly.
> Sorry for this basic explanation, maybe everybody understands all this
> already.
> Peter Alfke

ahhhhh
Thanks..
Now I get it..
So in long streams, its unable to partition the data to recover the
exact bits..
hmm, I guess one solution is use an external scrambler/encoder on the
signal to achieve data balance. then do descrambling/decoding inside
the fpga to get the correct data..

Cheers
Shakith


Article: 131080
Subject: Re: Specifying strict setup constraint in ISE
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 09 Apr 2008 19:24:56 -0700
Links: << >>  << T >>  << A >>
Wojciech Zabolotny wrote:
> Hi All,
> 
> I need to specify the strict setup time for the group of signals.
> It can be relatively high, but I need very low skew between the signals.
> In Quartus for Altera FPGAs I can define it with the sdc contraints as
> follows:
> 
> set_max_delay -from [get_ports MY_BUS[*]] -to [get_registers *] 6.000
> set_min_delay -from [get_ports MY_BUS[*]] -to [get_registers *] 5.000 
> 
> With the constraints above the code compiles and opperates correctly.
> 
> However in Xilinx ISE:
> TIMEGRP "MY_BUS_GRP" OFFSET = IN 6 ns BEFORE "SYS_CLK"
> does not allow me to specify both the minimal and maximal setup time...
> 
> As the result, I get the implementation, where for one signal the setup
> time is equal to 5.99 ns, but for the other - e.g. only 3ns .
> Because the signals are then oversampled at high frequency it results in
> the unacceptable skew...
> 
> How can I solve this problem?
> Using OFFSET IN AFTER is problematic, as I'd need to adjust all
> constraints if the period of the clock changes :-(.

When signals are absolutely critical to be low skew as in oversampling 
or otherwise very high speed designs, I and many others resort to using 
manual placement and often constrained routes.  If the routing is 
regular, often one constrained route can cover a multitude of signals.

Constrained routing is an advanced feature that requires some work 
inside FPGA Editor to generate the constraints.  Solid knowledge of the 
physical workings around the IOBs and signal routing boxes helps 
significantly.  Much of that knowledge comes from "poking around" inside 
the chip trying different routes both automated and manual.

There are some application notes on wide, very high speed buses that use 
the physical constraints to tie down how things behave coming into the 
chip.  How precise you get depends on how extreme your design goals are.

- John_H

Article: 131081
Subject: Re: Xilinx FFT C-sim model
From: "Marty Ryba" <martin.ryba.nospam@verizon.net>
Date: Thu, 10 Apr 2008 03:00:18 GMT
Links: << >>  << T >>  << A >>
"Pete" <petersen.curt@gmail.com> wrote in message 
news:c85cbe7c-8693-498b-96bb-093b8c244ae3@8g2000hsu.googlegroups.com...
> I've noticed that the Xilinx FFT bit-accurate c simulation calls are
> very very slow.  Anyone else notice this?
<snip>
> The program is single-threaded right now, and I intend to write a
> multi-threaded version soon.  But first, I decided to use a profiler
> on my single-threaded code to see what kind of speedup I should
> expect.  I wasn't very surprised to find that 99% of my execution time
> was taking place inside the xilinx_ip_xfft_v5_0_bitacc_simulate()
> function.  I WAS surprised to find that 55.6% of that function's
> execution time is being spent in malloc() and free() calls.  I have
> some nice call graphs and an excel spreadsheet I'd be willing to share
> if someone from Xilinx would like to take a look.
> Petersen Curt

I don't have direct experience with the Xilinx simulation, but a couple 
observations:
-- malloc() and free() don't belong in an FFT core; most optimized DSP 
library calls make the user pre-build the "twiddle factors" table (via an 
API call) and then the FFT routine can reuse that without needing to 
recreate it every time. Saves a lot of CPU-expensive sine() and cosine() 
calls as well. Xilinx could easily alter their API to provide that 
functionality.

-- Bit-true emulation is expensive since you no longer can call the IEEE-754 
functions built into your FPU in the microprocessor core but have to do 
everything the "hard way".

     I've done one simulation using the Matlab Fixed Point Toolbox. It 
worked, and was pretty close to the Blackfin DSP I was emulating, but it ran 
10 times slower than the floating point implementation. One problem with the 
Fixed Point Toolbox is that they only provide an "example" code that 
implements a radix-two transform. If you don't do it exactly that way, 
you'll have to code the FFT routine yourself. I was using a radix-4 
algorithm on the Blackfin, and some of the source code was in assembler. I 
truncated and rounded my results after the FFT and did the other critical 
calculations in the Toolbox. Maybe Xilinx could generate a reference FFT 
function for the Matlab toolbox, but that might give away some IP on their 
implementation. 



Article: 131082
Subject: Re: Serial Transmission w/o 8B/10B encoding
From: Peter Alfke <alfke@sbcglobal.net>
Date: Wed, 9 Apr 2008 20:43:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 6:28=A0pm, shakith.ferna...@gmail.com wrote:
> On Apr 10, 5:12 am, Peter Alfke <pe...@xilinx.com> wrote:
>
>
>
> > On Apr 9, 10:05 am, shakith.ferna...@gmail.com wrote:
>
> > > On Mar 31, 11:57 am, "TC" <no...@nowhere.com> wrote:
>
> > > > "Dave" <dhsch...@gmail.com> wrote in message
>
> > > >news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.co=
m...
>
> > > > > On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:=

> > > > >> <shakith.ferna...@gmail.com> wrote in message
>
> > > > >>news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.=
com...
>
> > > > >> > Hi,
>
> > > > >> > We have developed a High Speed on FPGA using the MGT/RocketIO t=
o
> > > > >> > generate high speed signals. Also we receive the high speed sig=
nals
> > > > >> > using the MGT. Due to the nature of the application, we require=
 a pure
> > > > >> > signal without encoding (We have switched off the 8B/10B encodi=
ng in
> > > > >> > the MGT). The problem is that it effects the clock recovery acc=
uracy
> > > > >> > in the received signal as there might not be =A0good DC balance=
 in the
> > > > >> > signal. Which in turn effects the data received. And MGT is a b=
lack
> > > > >> > box to us.
>
> > > > >> > Two options-
> > > > >> > 1. Another encoding mechanism such that we have pure signal and=
 good
> > > > >> > clock recovery.
> > > > >> > 2. Or is there a parameter in MGT to improve the clock recovery=
.
>
> > > > >> > We are looking for some solution around this problem.
>
> > > > >> > Our setup:
> > > > >> > FPGA - Xilinx Virtex II Pro
> > > > >> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > > > >> > Software - ISE 9.1i
>
> > > > >> > Best Regards
> > > > >> >Shakith
>
> > > > >> The clock recovery circuitry requires that there be a minimum num=
ber of
> > > > >> received edges per unit time. Otherwise, the recovered clock edge=
s will
> > > > >> drift with respect to the data stream.
>
> > > > >> If you don't use some type of encoding (e.g. 8B/10B), or you don'=
t insure
> > > > >> that your raw data ALWAYS provides this minimum edge density requ=
irement,
> > > > >> then the clock/data recovery circuitry will not work.
>
> > > > >> Bob
>
> > > > > Perhaps a scrambler/descrambler using LFSR's would help alleviate =
any
> > > > > edge density or DC bias problems by randomizing the data a bit? I'=
m
> > > > > not sure if it would guarantee correct reception, but it may help.=

>
> > > > You don't say why you need a "pure" signal (no coding). I could assu=
me that
> > > > you are trying to eliminate the overhead of coding (with 8b10b you o=
nly get
> > > > an effective data bandwidth of 80%).
>
> > > > You didn't say whether or not you MUST have a DC-balanced signal. Ar=
e your
> > > > transmitters AC-coupled to the receivers? If yes, the you must have =
a
> > > > DC-balanced signal and coding IS required.
>
> > > > You also don't mention your clocking requirements. Do you have a com=
mon
> > > > (distributed) reference clock, or are the reference clocks independa=
nt?
>
> > > > Typical clock recovery circuits assume plesio-synchronous operation.=
 This
> > > > means the the reference clocks can be independent but must be within=
 +/- XYZ
> > > > PPM (parts-per-million) of each other. For a receiver to track the
> > > > transmitter the receiver must recover the clock (and data) from the
> > > > transmitted bit stream. At high speeds this is done using PLLs. For =
the PLLs
> > > > to perform well they require frequent edges in the transmitted bit s=
tream.
>
> > > > Without a coded bit-stream you can't have DC-balance and you can't g=
aurantee
> > > > frequent edges for the PLL. So if you really can't have a coded bit-=
stream
> > > > then you must have a distributed (common) reference clock and you ca=
nnot use
> > > > AC-coupling.
>
> > > > If you are trying to minimize the overhead of coding look at other c=
oding
> > > > methods like 64b/66b codes. These are more efficient but still have =
the
> > > > benefits of DC-balanced tranmission and frequent clock edges.
>
> > > > Note that another benefit of 8b10b is the ability to align your symb=
ols. How
> > > > are you going to know the boundaries of a byte, a packet, etc., with=
out a
> > > > coded stream and use of non-data symbols (control symbols)? If you h=
ave
> > > > independent reference clocks how are you going to avoid underrun and=
 overrun
> > > > of the reciever withouth control symbols (i.e. insertion and removal=
 of idle
> > > > characters)? Do you need any form of closed-loop flow control, error=

> > > > signalling, etc.? If yes, how are you going to do this without contr=
ol
> > > > symbols?
>
> > > > TC
>
> > > Thanks...we also noticed a new problem
> > > When we run our implementation on FPGA, there is loss of data on the
> > > non-active part of the signal. Its set to be 20180bits, but the number=

> > > of bits received is less than that. The loss of data is not consistent=

> > > either. But this doesn't appear in simulation in Modelsim. One reason
> > > could be the fact that the DC Balance is not there. But does it affect=

> > > the data recovery from serial to parallel?
> > > Another option is use an external modulator chip on the receiver
> > > signal to achieve DC balance and the use the new modulated signal on
> > > MGT and decode it =A0inside the FPGA.
>
> > > Our setup:
> > > MGT Speed - 2 Gpbs
> > > FPGA - Xilinx Virtex II Pro
> > > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > > Software - ISE 9.1i
>
> > You are running into a fundamental limitation. What you receive is NRZ
> > data, High for 1, Low for 0 (or something similar). You know that a
> > High level of a certain duration means three ones in a row, but the
> > receiver needs a clock to separate the bits. It gets this clock from
> > its own PLL oscillator that is being kept alive and accurate by re-
> > synchronizing itself from any transitions in the data stream. That's
> > why you must have a transition quite often. Maybe you can run for 70
> > bits without a transition, but after tht, the PLL oscillator will
> > drift and will not partition the incoming data stream properly.
> > Sorry for this basic explanation, maybe everybody understands all this
> > already.
> > Peter Alfke
>
> ahhhhh
> Thanks..
> Now I get it..
> So in long streams, its unable to partition the data to recover the
> exact bits..
> hmm, I guess one solution is use an external scrambler/encoder on the
> signal to achieve data balance. then do descrambling/decoding inside
> the fpga to get the correct data..
>
> Cheers
> Shakith


Article: 131083
Subject: Re: Serial Transmission w/o 8B/10B encoding
From: Peter Alfke <alfke@sbcglobal.net>
Date: Wed, 9 Apr 2008 20:48:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 6:28=A0pm, shakith.ferna...@gmail.com wrote:
> On Apr 10, 5:12 am, Peter Alfke <pe...@xilinx.com> wrote:
>
>
>
> > On Apr 9, 10:05 am, shakith.ferna...@gmail.com wrote:
>
> > > On Mar 31, 11:57 am, "TC" <no...@nowhere.com> wrote:
>
> > > > "Dave" <dhsch...@gmail.com> wrote in message
>
> > > >news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.co=
m...
>
> > > > > On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:=

> > > > >> <shakith.ferna...@gmail.com> wrote in message
>
> > > > >>news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.=
com...
>
> > > > >> > Hi,
>
> > > > >> > We have developed a High Speed on FPGA using the MGT/RocketIO t=
o
> > > > >> > generate high speed signals. Also we receive the high speed sig=
nals
> > > > >> > using the MGT. Due to the nature of the application, we require=
 a pure
> > > > >> > signal without encoding (We have switched off the 8B/10B encodi=
ng in
> > > > >> > the MGT). The problem is that it effects the clock recovery acc=
uracy
> > > > >> > in the received signal as there might not be =A0good DC balance=
 in the
> > > > >> > signal. Which in turn effects the data received. And MGT is a b=
lack
> > > > >> > box to us.
>
> > > > >> > Two options-
> > > > >> > 1. Another encoding mechanism such that we have pure signal and=
 good
> > > > >> > clock recovery.
> > > > >> > 2. Or is there a parameter in MGT to improve the clock recovery=
.
>
> > > > >> > We are looking for some solution around this problem.
>
> > > > >> > Our setup:
> > > > >> > FPGA - Xilinx Virtex II Pro
> > > > >> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > > > >> > Software - ISE 9.1i
>
> > > > >> > Best Regards
> > > > >> >Shakith
>
> > > > >> The clock recovery circuitry requires that there be a minimum num=
ber of
> > > > >> received edges per unit time. Otherwise, the recovered clock edge=
s will
> > > > >> drift with respect to the data stream.
>
> > > > >> If you don't use some type of encoding (e.g. 8B/10B), or you don'=
t insure
> > > > >> that your raw data ALWAYS provides this minimum edge density requ=
irement,
> > > > >> then the clock/data recovery circuitry will not work.
>
> > > > >> Bob
>
> > > > > Perhaps a scrambler/descrambler using LFSR's would help alleviate =
any
> > > > > edge density or DC bias problems by randomizing the data a bit? I'=
m
> > > > > not sure if it would guarantee correct reception, but it may help.=

>
> > > > You don't say why you need a "pure" signal (no coding). I could assu=
me that
> > > > you are trying to eliminate the overhead of coding (with 8b10b you o=
nly get
> > > > an effective data bandwidth of 80%).
>
> > > > You didn't say whether or not you MUST have a DC-balanced signal. Ar=
e your
> > > > transmitters AC-coupled to the receivers? If yes, the you must have =
a
> > > > DC-balanced signal and coding IS required.
>
> > > > You also don't mention your clocking requirements. Do you have a com=
mon
> > > > (distributed) reference clock, or are the reference clocks independa=
nt?
>
> > > > Typical clock recovery circuits assume plesio-synchronous operation.=
 This
> > > > means the the reference clocks can be independent but must be within=
 +/- XYZ
> > > > PPM (parts-per-million) of each other. For a receiver to track the
> > > > transmitter the receiver must recover the clock (and data) from the
> > > > transmitted bit stream. At high speeds this is done using PLLs. For =
the PLLs
> > > > to perform well they require frequent edges in the transmitted bit s=
tream.
>
> > > > Without a coded bit-stream you can't have DC-balance and you can't g=
aurantee
> > > > frequent edges for the PLL. So if you really can't have a coded bit-=
stream
> > > > then you must have a distributed (common) reference clock and you ca=
nnot use
> > > > AC-coupling.
>
> > > > If you are trying to minimize the overhead of coding look at other c=
oding
> > > > methods like 64b/66b codes. These are more efficient but still have =
the
> > > > benefits of DC-balanced tranmission and frequent clock edges.
>
> > > > Note that another benefit of 8b10b is the ability to align your symb=
ols. How
> > > > are you going to know the boundaries of a byte, a packet, etc., with=
out a
> > > > coded stream and use of non-data symbols (control symbols)? If you h=
ave
> > > > independent reference clocks how are you going to avoid underrun and=
 overrun
> > > > of the reciever withouth control symbols (i.e. insertion and removal=
 of idle
> > > > characters)? Do you need any form of closed-loop flow control, error=

> > > > signalling, etc.? If yes, how are you going to do this without contr=
ol
> > > > symbols?
>
> > > > TC
>
> > > Thanks...we also noticed a new problem
> > > When we run our implementation on FPGA, there is loss of data on the
> > > non-active part of the signal. Its set to be 20180bits, but the number=

> > > of bits received is less than that. The loss of data is not consistent=

> > > either. But this doesn't appear in simulation in Modelsim. One reason
> > > could be the fact that the DC Balance is not there. But does it affect=

> > > the data recovery from serial to parallel?
> > > Another option is use an external modulator chip on the receiver
> > > signal to achieve DC balance and the use the new modulated signal on
> > > MGT and decode it =A0inside the FPGA.
>
> > > Our setup:
> > > MGT Speed - 2 Gpbs
> > > FPGA - Xilinx Virtex II Pro
> > > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > > Software - ISE 9.1i
>
> > You are running into a fundamental limitation. What you receive is NRZ
> > data, High for 1, Low for 0 (or something similar). You know that a
> > High level of a certain duration means three ones in a row, but the
> > receiver needs a clock to separate the bits. It gets this clock from
> > its own PLL oscillator that is being kept alive and accurate by re-
> > synchronizing itself from any transitions in the data stream. That's
> > why you must have a transition quite often. Maybe you can run for 70
> > bits without a transition, but after tht, the PLL oscillator will
> > drift and will not partition the incoming data stream properly.
> > Sorry for this basic explanation, maybe everybody understands all this
> > already.
> > Peter Alfke
>
> ahhhhh
> Thanks..
> Now I get it..
> So in long streams, its unable to partition the data to recover the
> exact bits..
> hmm, I guess one solution is use an external scrambler/encoder on the
> signal to achieve data balance. then do descrambling/decoding inside
> the fpga to get the correct data..
>
> Cheers
> Shakith
Thats the way when you cannot use the simplest method, called 8B10B,
where 10 bits are used to transmit the content of 8 data bits.
Transceivers often include the necessary encoder/decoder, and DC
balancing is automatically included. The penalty is a 25% loss in
throughput ( e.g. only 2.5 Gbps from a 3,125 Gbps channel.
Scrambling is populat with the telephone people.
Peter Alfke, Xilinx

Article: 131084
Subject: Re: 32 bit multiplier
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 10 Apr 2008 16:11:54 +1200
Links: << >>  << T >>  << A >>
VIPS wrote:
> Hi All
> 
> This application I am  looking at requires 17 tera bytes of
> multiplication per second. Which in an FPGA  means 40K FPGAs. What I
> want to know is how many 32x32 Mults can you fit into an ASIC today
> Standard Cell or Custom ASIC. Also what kind of speeds can I  get.

You could also do the calculations for : http://www.mathstar.com/
and once you have the Multiplier count, the data bandwidth to
keep all these fed will be important as well.

-jg


Article: 131085
Subject: Re: MIG/Corgen to XPS core insertion
From: xenix <lastval@gmail.com>
Date: Wed, 9 Apr 2008 23:45:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
any help on that plz?

regards
xenix

Article: 131086
Subject: Re: Xilinx CPLD programming tool under Linux
From: Habib Bouaziz-Viallet <habib@rigel.systems>
Date: 10 Apr 2008 07:08:47 GMT
Links: << >>  << T >>  << A >>
Le Wed, 09 Apr 2008 20:32:53 +0000, Uwe Bonnes a écrit:

> Habib Bouaziz-Viallet <habib@rigel.systems> wrote:
>> Le Wed, 09 Apr 2008 12:49:43 -0400, DJ Delorie a écrit:
> 
>> > Habib Bouaziz-Viallet <habib@rigel.systems> writes:
>> >> I'm wondering if a basic tool already exist to program Xilinx CPLD
>> >> (XC95144 and so) under Linux (preferably with the old Parralle cable III)
>> > 
>> Hi !
>> It's always a pleasure to speak with you M. Delorie
>> > Doesn't ISE itself have such a tool?
> 
>> I'm working with WebPack ISE and i guess that the programming tools
>> (ImpACT) is a native MS-Windows tool and did not work under GNU/Linux.
>> I'm building a parallel cable for my own so i did not already test it.
> 
> Use impact with 
> http://rmdir.de/~michael/xilinx/
> 
> Don't bother with the windriver kernel module...

Hi !

Please correct me if i'm wrong.

Building this library allows us (Linux user's) to program Xilinx devices
with impact (in command line) and usb or parrallel cable III.

I will try this next week (time to build my own parrallel cable III)

PS :
Although the DJ Delorie solution (xapp058) requires more work, I would go
more deeply later.


Many thanks, Habib.

-- 
HBV

Article: 131087
Subject: Re: Disable optimisation - Ring oscillator
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 10 Apr 2008 01:33:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 9 Apr., 00:52, Franck Y <franck...@gmail.com> wrote:
> I have a project where i have to implement a ring oscillator (3 not
> gates) [...]
> which seems that
> quartus has optmised 'a little too much' since i want to see the
> delay.

You can't even really call that optimization.
You seen, in an FPGA you do not have individual not and nor gates.
You have 4 input lookup tables. Even in an ASIC technology there is
a technology mapping step involved, that tries to find a
representation
in the target technology for your technology independant
specification.

While it would be possible to map your desing 1 to 1 to the FPGA
technology
in general that is not possible, so the tool does not even try.
Instead it is
looking for netlist portion (not individual gates) that can be
represented by
the FPGAs ressources.

In your case it finds an obvious match: The whole circuit can be
represented by
a single LUT. Of course it chooses that representation. This is not an
overly aggressive
optimization, it is a necessary step to find a realizable netlist at
all.

The solution to your problem is a technology dependant representation:
Instantiate
LUT primitives. You can even manually place them to increase the
delay.

Kolja Sulimma

Article: 131088
Subject: Re: Xilinx CPLD programming tool under Linux
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Thu, 10 Apr 2008 08:36:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
Habib Bouaziz-Viallet <habib@rigel.systems> wrote:
...
> PS :
> Although the DJ Delorie solution (xapp058) requires more work, I would go
> more deeply later.

If you like to go the SVF way, urjtag  (look on sourceforge) can play SVF on
many adapters. 

Bye 

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 131089
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: Thu, 10 Apr 2008 13:24:44 +0200
Links: << >>  << T >>  << A >>
Jon Elson posted:
|-------------------------------------------------------------------|
|"[..]                                                              |
|                                                                   |
|[..] Proving you can                                               |
|correct corruption from a hit anywhere on a chip, while running ANY|
|program, at any time, seems like fantasy."                         |
|-------------------------------------------------------------------|

Correct. Xilinx did (and probably still does) have an admission on
its website that a level of risk must always be accepted, no matter
what is done to combat single-event effects.

Regards,
Colin Paul Gloster,
unemployed and hungry

Article: 131090
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: Thu, 10 Apr 2008 13:26:17 +0200
Links: << >>  << T >>  << A >>
Austin posted:
|------------------------------------------------------------------------|
|"[..]                                                                   |
|                                                                        |
|[..] they can be tested                                                 |
|by reconfiguring to flip bits while operating. One heck of a lot cheaper|
|than using a proton beam, or neutron beam .... and more complete (we    |
|have folks who flip each bit, one by one, and prove their system meets  |
|its requirements)."                                                     |
|------------------------------------------------------------------------|

Logical testing will not match checking whether real radiation respects
your model of the system. One transient can defeat the outcome of clocked
triply modularly redundant voters.

Sincerely,
Colin Paul Gloster,
unemployed and cold

Article: 131091
Subject: Re: system level language: why all this fuss about
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: Thu, 10 Apr 2008 13:29:51 +0200
Links: << >>  << T >>  << A >>
Karl posted:
|---------------------------------------------------------------------|
|"why all this fuss  about the need for new system level languages and|
|higher abstraction...systems were also heterogeneous in the past but |
|only few experts did implement them...hardware and software designers|
|were working apart. [..]                                             |
|                                                                     |
|[..]"                                                                |
|---------------------------------------------------------------------|

Is anything new? I refer you to J. Robert Heath, B. D. Carroll,
Terry T. Cwik, "CDL - A tool for concurrent hardware and software
development", "Proceedings of the 14th conference on Design Automation",
1977.

Regards,
Colin Paul Gloster,
unemployed and hungry

Article: 131092
Subject: Re: Specifying strict setup constraint in ISE
From: Gabor <gabor@alacron.com>
Date: Thu, 10 Apr 2008 05:56:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 10:24 pm, John_H <newsgr...@johnhandwork.com> wrote:
> Wojciech Zabolotny wrote:
> > Hi All,
>
> > I need to specify the strict setup time for the group of signals.
> > It can be relatively high, but I need very low skew between the signals.
> > In Quartus for Altera FPGAs I can define it with the sdc contraints as
> > follows:
>
> > set_max_delay -from [get_ports MY_BUS[*]] -to [get_registers *] 6.000
> > set_min_delay -from [get_ports MY_BUS[*]] -to [get_registers *] 5.000
>
> > With the constraints above the code compiles and opperates correctly.
>
> > However in Xilinx ISE:
> > TIMEGRP "MY_BUS_GRP" OFFSET = IN 6 ns BEFORE "SYS_CLK"
> > does not allow me to specify both the minimal and maximal setup time...
>
> > As the result, I get the implementation, where for one signal the setup
> > time is equal to 5.99 ns, but for the other - e.g. only 3ns .
> > Because the signals are then oversampled at high frequency it results in
> > the unacceptable skew...
>
> > How can I solve this problem?
> > Using OFFSET IN AFTER is problematic, as I'd need to adjust all
> > constraints if the period of the clock changes :-(.
>
> When signals are absolutely critical to be low skew as in oversampling
> or otherwise very high speed designs, I and many others resort to using
> manual placement and often constrained routes.  If the routing is
> regular, often one constrained route can cover a multitude of signals.
>
> Constrained routing is an advanced feature that requires some work
> inside FPGA Editor to generate the constraints.  Solid knowledge of the
> physical workings around the IOBs and signal routing boxes helps
> significantly.  Much of that knowledge comes from "poking around" inside
> the chip trying different routes both automated and manual.
>
> There are some application notes on wide, very high speed buses that use
> the physical constraints to tie down how things behave coming into the
> chip.  How precise you get depends on how extreme your design goals are.
>
> - John_H

If you can generate the required phase relationship with
your clock signal (to the sampling flip-flops) instead of
playing with the input delay to the flop D, it is fairly
simple to have a low skew sampling when you use the IOB
flip-flops.  Then the only routing that comes into play is
the clock, and this can be adjusted using DCM resources.
This assumes you don't insert the delay element in each
IOB between the pin and the D.  Newer Virtex parts also
have variable input delay elements that can help to remove
residual skew, but for a 1 ns window this should not be
necessary.

Article: 131093
Subject: Re: Xilinx CPLD programming tool under Linux
From: Habib Bouaziz-Viallet <habib@rigel.systems>
Date: 10 Apr 2008 13:15:33 GMT
Links: << >>  << T >>  << A >>
Le Thu, 10 Apr 2008 08:36:35 +0000, Uwe Bonnes a écrit:


> If you like to go the SVF way, urjtag  (look on sourceforge) can play SVF on
> many adapters.
Ok thanks Uwe !
> 
> Bye 
>



-- 
HBV

Article: 131094
Subject: Re: 32 bit multiplier
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 10 Apr 2008 07:12:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 9 Apr., 00:58, Peter Alfke <pe...@xilinx.com> wrote:

> Slightly off-topic: Here is a civilian research application at CERN,
> where 120 Virtex 4FX devices "digest" and pre-process a thousand data
> streams of 2.5 Gbps each.
> I was peripherally involved, and I helped write the press release...http://biz.yahoo.com/prnews/080404/aqf063.html?.v=35
> I even got to walk around in the tunnel.
> Peter Alfke, Xilinx

So that's why Volker Lindenstruth is hosting the FPL this year.
I worked on something like the predecessor of that beast in 1995.
Processing 100.000 data streams at 10MHz.

Kolja Sulimma

Article: 131095
Subject: Re: Specifying strict setup constraint in ISE
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 10 Apr 2008 16:27:47 +0100
Links: << >>  << T >>  << A >>
"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:ef-dnWJb2Lr752DanZ2dnUVZ_remnZ2d@comcast.com...
>
> When signals are absolutely critical to be low skew as in oversampling or 
> otherwise very high speed designs, I and many others resort to using 
> manual placement and often constrained routes.  If the routing is regular, 
> often one constrained route can cover a multitude of signals.
>
> Constrained routing is an advanced feature that requires some work inside 
> FPGA Editor to generate the constraints.  Solid knowledge of the physical 
> workings around the IOBs and signal routing boxes helps significantly. 
> Much of that knowledge comes from "poking around" inside the chip trying 
> different routes both automated and manual.
>
Good advice. May I also recommend some reading for the OP?

directed routing site:xilinx.com

HTH., Syms. 



From webmaster@nillakaes.de Thu Apr 10 09:02:41 2008
Path: flpi142.ffdc.sbc.com!flpi104.ffdc.sbc.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin2!goblin.stu.neva.ru!feed.cnntp.org!news.cnntp.org!not-for-mail
Message-Id: <47fe3a1e$0$583$6e1ede2f@read.cnntp.org>
From: Thorsten Kiefer <webmaster@nillakaes.de>
Subject: clock instanciation
Newsgroups: comp.arch.fpga
Date: Thu, 10 Apr 2008 18:02:41 +0200
User-Agent: KNode/0.10.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 28
Organization: CNNTP
NNTP-Posting-Host: 2974a2e3.read.cnntp.org
X-Trace: DXC=b2OSkjN=b3WA[F0hKihbFPWoT\PAgXa?QaW[_@WQ]BhS1P5d:S1^>6SdlT:^LKmYjZm?>\ITh57oXVJ@RQDmEb[W
X-Complaints-To: abuse@cnntp.org
Xref: prodigy.net comp.arch.fpga:143516
X-Received-Date: Mon, 21 Apr 2008 19:21:05 EDT (flpi142.ffdc.sbc.com)

Hi,
in my book it's written that the clock
has to instactiated like this :

architecture Behavioral of fftest is
        constant T : time := 20ns;
...
begin
...
        --clock
        process
        begin
                clk <= '0';
                wait for T/2;
                clk <= '1';
                wait for T/2;
        end process
...
end Behavioral;

But I get the error messages :
2x "Wait for statement unsupported."

Spartan3, Xilinx ISE 9.2....

Best Regards
Thorsten


Article: 131096
Subject: Re: clock instanciation
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 10 Apr 2008 17:05:48 +0100
Links: << >>  << T >>  << A >>

"Thorsten Kiefer" <webmaster@nillakaes.de> wrote in message 
news:47fe3a1e$0$583$6e1ede2f@read.cnntp.org...
> Hi,
> in my book it's written that the clock
> has to instactiated like this :
>
Hi Thorsten,
Your book is talking about simulation. You can't synthesise that code, 
because the FPGA can't implement delays like that. You need an external 
clock for synthesis that connects to your design through an input port.
HTH., Syms. 



From webmaster@nillakaes.de Thu Apr 10 09:21:39 2008
Path: flpi142.ffdc.sbc.com!flpi104.ffdc.sbc.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin1!goblin.stu.neva.ru!newsfeed.datemas.de!feed.cnntp.org!news.cnntp.org!not-for-mail
Message-Id: <47fe3e96$0$583$6e1ede2f@read.cnntp.org>
From: Thorsten Kiefer <webmaster@nillakaes.de>
Subject: Re: clock instanciation
Newsgroups: comp.arch.fpga
Date: Thu, 10 Apr 2008 18:21:39 +0200
References: <47fe3a1e$0$583$6e1ede2f@read.cnntp.org> <ftldt6$2ra$1@aioe.org>
User-Agent: KNode/0.10.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 31
Organization: CNNTP
NNTP-Posting-Host: 2974a2e3.read.cnntp.org
X-Trace: DXC=65NH5f3M3dQm5517_1kbUXWoT\PAgXa?QaW[_@WQ]BhS1P5d:S1^>6SdlT:^LKmYjZDY4c_O@`cXWSR5>dB75[i_
X-Complaints-To: abuse@cnntp.org
Xref: prodigy.net comp.arch.fpga:143518
X-Received-Date: Mon, 21 Apr 2008 19:21:38 EDT (flpi142.ffdc.sbc.com)

Symon wrote:

> 
> "Thorsten Kiefer" <webmaster@nillakaes.de> wrote in message
> news:47fe3a1e$0$583$6e1ede2f@read.cnntp.org...
>> Hi,
>> in my book it's written that the clock
>> has to instactiated like this :
>>
> Hi Thorsten,
> Your book is talking about simulation. You can't synthesise that code,
> because the FPGA can't implement delays like that. You need an external
> clock for synthesis that connects to your design through an input port.
> HTH., Syms.

OK,
I found the pin, now another question. This is also for simulation only:
reset <= '1', '0' after T/2;

I tried to convert that like that :
        process
        begin 
                reset <= '1';
                wait until falling_edge(clk);
                reset <= '0';
        end process;
But that would run forever, right ?
Is it possible to abort a process after 1 execution ?

--TK


Article: 131097
Subject: Re: clock instanciation
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 10 Apr 2008 09:37:25 -0700
Links: << >>  << T >>  << A >>
Thorsten Kiefer wrote:

> OK,
> I found the pin, now another question. This is also for simulation only:
> reset <= '1', '0' after T/2;
> 
> I tried to convert that like that :

No synthesis code is required for reset or clock
other than the input port declarations.
Some testbench process can wiggle it
however you like.


          -- Mike Treseler

Article: 131098
Subject: Re: clock instanciation
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 10 Apr 2008 18:01:04 +0100
Links: << >>  << T >>  << A >>
"Thorsten Kiefer" <webmaster@nillakaes.de> wrote in message 
news:47fe3e96$0$583$6e1ede2f@read.cnntp.org...
>
> OK,
> I found the pin, now another question. This is also for simulation only:
> reset <= '1', '0' after T/2;
>
> I tried to convert that like that :
>        process
>        begin
>                reset <= '1';
>                wait until falling_edge(clk);
>                reset <= '0';
>        end process;
> But that would run forever, right ?
> Is it possible to abort a process after 1 execution ?
>
> --TK
>
  generate_reset : process
  begin
    reset <= '1';
    wait for 10 ns;
    reset <= '0';
    wait ;   --  ***YOU NEED THIS***
  end process generate_reset;



Article: 131099
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been
From: austin <austin@xilinx.com>
Date: Thu, 10 Apr 2008 11:34:03 -0700
Links: << >>  << T >>  << A >>
Colin,

It is a question of completeness.

Logically going through every bit, is 100% functionally complete.

Sitting in a proton beam is "waiting for Godot" -- how long must you
wait to check enough bits to achieve the required coverage?

It becomes a matter of "too many dollars to keep the lights on."
(Beam testing is horribly power hungry, and very expensive, eg TSL is
$250K for a session, not including the airplane tickets, hotel rooms,
people, rental cars...).

Additional system testing in a beam is highly desired, but the goals are
not for functional completeness, but to cover whatever might have been
missed bu flipping 100%, one by one, every configuration bit.

XTMR Tool(tm) software can not be broken by a single radiative event,
nor by a single bit flip (as verified by NASA, JPL, CERN, etc....).

Our flow triplicates the voters, so that every feedback path gets a full
TMR.  A failure in a voter is "voted" out by the other two voters.

That is why we have so many designers using this flow:

  it   just   works.

Austin

Colin Paul Gloster wrote:
> Austin posted:
> |------------------------------------------------------------------------|
> |"[..]                                                                   |
> |                                                                        |
> |[..] they can be tested                                                 |
> |by reconfiguring to flip bits while operating. One heck of a lot cheaper|
> |than using a proton beam, or neutron beam .... and more complete (we    |
> |have folks who flip each bit, one by one, and prove their system meets  |
> |its requirements)."                                                     |
> |------------------------------------------------------------------------|
> 
> Logical testing will not match checking whether real radiation respects
> your model of the system. One transient can defeat the outcome of clocked
> triply modularly redundant voters.
> 
> Sincerely,
> Colin Paul Gloster,
> unemployed and cold



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